[TOC]

Multiple Web services access share the IngressGateway

background

Shared ingressgateway

First of all, for IngressGateway, the current industry consensus is to share ingressGateway, which is sufficient for the early stage, but it needs to ensure that ingressGateway can not be a single point, and ingressGateway can deploy multiple load balancing.

Therefore, an IngressGateway needs to support different service access. For IngressGateway, Gateway resources are configured with the same port and protocol, and different hosts are configured in the corresponding VirtualService. Finally, route to different services through the Hosts of VirtualService.

If you specify different hosts, the VirtualService has different routing rules that do not conflict

Unified Domain name Access

The other is unified domain name gesture access. Inside K8S, when creating a Service, a record is added to kube-DNS by default. Then, other services can be accessed from Pod by using the Service name.

However, if you want to be able to customize the domain name, so that the access container, access isTIO and no access isTIO have the same access attitude, you need to be able to customize the domain name, of course, this custom domain name must be resolved first, kube-DNS can configure private DNS and upstream DNS. And we have made relevant optimization for this DNS in K8S cluster.

In an existing K8S cluster, the default custom domain name given when a service is created is written to bind9 in the engine room, as well as to our external DNS resolution server, so that the domain name can be resolved within and outside the cluster. This domain is eventually resolved to the LVS, and then underneath the LVX is the Ingress, which is the load balancer at seven layers, and then routed through seven layers.

If it is other special custom domain name, then need operation and maintenance manual configuration, also through dnsPod and bind9, and finally resolve LVS, and then carry out layer 7 routing

After Istio is connected, to maintain the original unified domain name access mode, the customized domain name must be resolved to the LVS, which is the ingress gateway of Istio and routed through host. Therefore, when the client requests HTTP processing, it must carry the Host for routing.

At this point, it is the same as K8S ‘existing domain name management posture, but the LVS of custom domain name resolution are different, one LB LVS, one IStio ingressGateway LVS.

In ISTIO, VirtualService is used to configure routes and hosts is used to distinguish routes

Program & practical operation

Verify on the local MAC

ingressgateway

Kubectl get SVC - n istio - system | grep istio - ingressgateway istio - ingressgateway NodePort 10.233.13.102 < none > 80:31380/TCP,443:31390/TCP,8081:31381/TCP,31499:31499/TCP,31400:31400/TCP,15011:32636/TCP,8060:32041/TCP,15030:31210/TCP ,15031:32538/TCP 25dCopy the code

For service ONE:

Hello – a web service

1. The deployment configuration of service 1 is as follows:

apiVersion: v1 kind: Service metadata: name: hello-web labels: app: hello-web spec: ports: - name: http-web port: 12345 selector: app: hello-web --- apiVersion: extensions/v1beta1 kind: Deployment metadata: name: hello-web-v1 spec: replicas: 1 template: metadata: labels: app: hello-web version: v1 spec: containers: - name: hello-web image: Wudebao5220150 / webserver: 1.0.0 imagePullPolicy: IfNotPresent ports: - containerPort: - 12345Copy the code

kubectl apply -f <(istioctl kube-inject -f hello-web.yaml)

2. The gateway and route configurations are as follows:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: hello-web-gateway
spec:
  selector:
    istio: ingressgateway # use Istio default gateway implementation
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*.hello-web.com"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: hello-web
spec:
  hosts:
  - "www.hello-web.com"
  gateways:
  - hello-web-gateway
  http:
  - match:
    - uri:
        exact: /hello
    route:
    - destination:
        port:
          number: 12345
        host: hello-web
Copy the code

kubectl apply -f hello-web-gateway.yaml

Requests whose hosts is www.hello-web.com are routed to the specified HTTP match. Here is the entry point. The route after the entry point is distinguished by hosts, and detailed rules for the downstream Cluster are implemented by HTTP match

For service TWO:

Wudebao – a web service

1. The deployment configuration of service 2 is as follows:

apiVersion: v1 kind: Service metadata: name: wudebao-web labels: app: wudebao-web spec: ports: - name: http-web port: 54321 selector: app: wudebao-web --- apiVersion: extensions/v1beta1 kind: Deployment metadata: name: wudebao-web spec: replicas: 1 template: metadata: labels: app: wudebao-web version: v1 spec: containers: - name: wudebao-web image: Wudebao5220150 / webServer-v2 :1.0.0 imagePullPolicy: IfNotPresent Ports: -containerPort: 54321Copy the code

kubectl apply -f <(istioctl kube-inject -f wudebao-web.yaml)

2. The gateway and route configurations are as follows:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: wudebao-web-gateway
spec:
  selector:
    istio: ingressgateway # use Istio default gateway implementation
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*.wudebao-web.com"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: wudebao-web
spec:
  hosts:
  - "www.wudebao-web.com"
  gateways:
  - wudebao-web-gateway
  http:
  - match:
    - uri:
        exact: /wudebao
    route:
    - destination:
        port:
          number: 54321
        host: wudebao-web
Copy the code

kubectl apply -f wudebao-web-gateway.yaml

Requests whose hosts is www.wwudebao-web.com are routed to the specified HTTP match. Here is the entry point. The route after the entry point is distinguished by hosts, and detailed rules for the downstream Cluster are implemented by HTTP match

Key points:

  1. The Gateway server port must be handled carefully. Name and number cannot be defined randomly. Name has a fixed format and number must be configured in ingressGateway

  2. Hosts under the VirtualService spec, which can be specified arbitrarily, such as a real domain name

    • The host is set to be the same as the domain name to be accessed, and then the client can route through host when making HTTP requests with host
    • You also need to be able to ensure that K8S can resolve the custom domain name

  3. The VirtualService route destination host is the service that is actually routed to the cluster

    • Generally, you can directly use the service name under the same namespace
    • Preferably FQDN, write the fully qualified domain name

  4. If only ingressGateway is used, services can be accessed by external requests without Sidecar, but some of isTIO’s service-specific routing policies and rules cannot be applied

    • Therefore, when deploying, Sidecar will have to inject the Envoy proxy

Final visit:

IP: Port. Host and URI are different. Route to different services through Host:

The curl 172.31.36.68:31380 / hello - H"Host: www.hello-web.com"The -v curl 172.31.36.68:31380 / wudebao - H"Host: www.wudebao-web.com"  -v

Copy the code

In this way, access requests of multiple Web services are simultaneously met, and different hosts are routed to different back-end services

Welcome to follow my wechat official account: Linux server system development, and we will vigorously send quality articles through wechat official account in the future.