Millet Porridge

English version of https://corvo.myseu.cn

0%

Istio - Simple Usage (Gateway)

Posted on Edited on In Disqus:
Recently I integrated a K8s system whose Ingress support is incomplete with many features cut, but it supports full-featured Istio. So I researched and tried Istio's features to see whether they meet our needs. I didn't go deep into Istio's internals — just implementing specific features, understanding and using it my own way; corrections welcome.

Background

Recently I integrated a K8s system whose Ingress support is incomplete, with many features cut. However, it supports full-featured Istio, so I researched and tried Istio to see whether its features meet our needs. When integrating the system I didn’t go particularly deep into Istio’s internals — only enough to implement specific features. I may understand and use it according to my own ideas; corrections are welcome.

A Simple Introduction to Istio

Istio is an open, platform-independent service mesh providing traffic management, policy distribution, and telemetry collection.

Looking directly at the diagram, Istio’s function is traffic management within the cluster, with a visualization interface attached. Therefore if Istio provides an external egress, it can act like Ingress: traffic enters from one entrance and is forwarded to different pods.

Simple Usage After Installing Istio

I tested with minikube (1.2.0) and also used it to install Istio (1.6.8).

After Istio Is Installed

1
2
3
4
5
6
7
8
9
kubectl -n istio-system get deploy
NAME                   READY   UP-TO-DATE   AVAILABLE   AGE
grafana                1/1     1            1           13d
istio-ingressgateway   1/1     1            1           14d
istiod                 1/1     1            1           14d
jaeger                 1/1     1            1           13d
kiali                  1/1     1            1           10d
kiali-operator         1/1     1            1           13d
prometheus             1/1     1            1           14d

Istio’s built-in Ingress: after istio is installed, kubectl -n istio-system get deploy istio-ingressgateway shows a built-in ingress. This ingress handles istio’s inbound traffic; it can act as an ordinary Ingress service or as istio’s gateway.

Creating External Services the Ingress Way

This approach comes from the official samples (samples/bookinfo/platform/kube/bookinfo-ingress.yaml) — of all the files, only this one is a kind: Ingress example.

Exposing interfaces with Ingress resources

It’s not quite the same as the ingress services we created before with Nginx or OpenResty, because its gateway service uses Envoy (a service proxy tool written in C++, similar to Nginx). But in istio the ingress configuration changes somewhat:

20210624114132

The configuration adds /* to match paths, and cannot split traffic by prefix like Nginx. I did no further testing, but since Nginx was replaced by Envoy, some configurations are theoretically not interchangeable.

Creating External Services with gateway+vs, ds

The official samples give more of this approach, including how to split traffic and how services call each other. When creating external services we also need to specify the domain, path rules, and backend services. Thus the most minimal configuration is:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
# specify the gateway receiving traffic
---
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: arya-gateway
  namespace:  xxx-group-2
spec:
  selector:
    istio: ingressgateway # use istio default controller
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "arya-python3.istio.xxx.com"

# the virtual-service explains how the gateway's traffic is handled
# you can see prefix paths are allowed for forwarding here; this approach can skip DestinationRule
# and use kubernetes services entirely
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: arya-virtual-service
  namespace:  xxx-group-2
spec:
  hosts:
  - "arya-python3.istio.xxx.com"
  gateways:
  - arya-gateway
  http:
  - match:
    - uri:
        prefix: /static
    route:
    - destination:
        host: prod-arya-python3-static
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host: prod-arya-python3

Distributing Traffic by Proportion

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
# relies on the service distinguishing prod-arya-python3 and stage-arya-python3
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: arya-virtual-service
  namespace:  xxx-group-2
spec:
  hosts:
  - "arya-python3.istio.xxx.com"
  gateways:
  - arya-gateway
  http:
  - match:
    - uri:
        prefix: /static
    route:
    - destination:
        host: prod-arya-python3-static
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host: prod-arya-python3
      weight: 50
    - destination:
        host: stage-arya-python3
      weight: 50

Using VirtualService Together with DestinationRule

Compared with native Services, DestinationRule extends some functionality and can group by service instances. Our current version-based release approach also pairs easily with DestinationRule.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
# the service only selects the application name, no longer distinguishing version numbers
---
apiVersion: v1
kind: Service
metadata:
  name: prod-arya-python3
  namespace: xxx-group-2
spec:
  selector:
    app_name: "arya-python3"
    # app: "arya-python3-v2361"  # version selection no longer needed
  ports:
  - protocol: TCP
    port: 80
    targetPort: 6000
    name: http

---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: arya-virtual-service
  namespace:  xxx-group-2
spec:
  hosts:
  - "arya-python3.istio.xxx.com"
  gateways:
  - arya-gateway
  http:
  - match:
    - uri:
        prefix: /static
    route:
    - destination:
        host: prod-arya-python3-static
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host: prod-arya-python3
        subset: v2361
      weight: 50
    - destination:
        host: prod-arya-python3
        subset: v2418
      weight: 50

# The Service no longer distinguishes version numbers; they go into the DestinationRule instead.
# Different subsets determine traffic direction.
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: arya-destination
  namespace:  xxx-group-2
spec:
  host: prod-arya-python3
  subsets:
  - name: v2361
    labels:
      version: "2361"
  - name: v2418
    labels:
      version: "2418"

Since we use istio, to be able to use some DestinationRule features later, we should follow the latter way — letting DestinationRule’s subsets split the traffic.

The kiali Interface

20210624114851

Summary

From the current research and usage, Istio’s IngressGateway differs somewhat from ordinary Ingress, though many functions can be replaced by it. If a project plans to use Istio from the start, I suggest not using Ingress anymore — adopt the Gateway+VirtualService form directly. Later I should also share some rules achievable with VirtualService and DestinationRule.

Related Posts