In the previous issue of  k8s-Service Grid Practice-Configuring Mesh,  we explained how to configure Mesh requests within the cluster. Istio can also handle traffic outside the cluster, which is our common gateway.

picture

In fact, it is similar to the k8s introduction to practical use - using Ingress. Ingress is a method of exposing internal services.

Just using Istio-gateway will be more flexible.

picture

Here is a function comparison chart. It can be clearly seen that Istio-gateway supports more functions. If it is a medium and large enterprise and has already used Istio, it is more recommended to have Istio-gateway and use the same control plane. Manage internal and external network traffic.

Create Gateway

Before starting, first create an Istio-Gateway resource:

apiVersion: networking.istio.io/v1alpha3  
kind: Gateway  
metadata:  
  name: istio-ingress-gateway  
  namespace: default  
spec:  
  servers:  
    - port:  
        number: 80  
        name: http  
        protocol: HTTP  
      hosts:  
        - 'www.service1.io'  
  selector:  
    app: istio-ingressgateway #与现有的 gateway 关联  
    istio: ingressgateway
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.

The matching label in the selector selector can be associated with the gateway that comes when we install Istio.

# 查看 gateway 的 label
k get pod -n istio-system
NAME                                    READY   STATUS
istio-ingressgateway-649f75b6b9-klljw   1/1     Running

k describe pod istio-ingressgateway-649f75b6b9-klljw -n istio-system |grep Labels
Labels:           app=istio-ingressgateway
1.
2.
3.
4.
5.
6.
7.

picture

This Gateway will install this component when we first install Istio.

The meaning of this configuration is that the gateway will proxy all requests accessed through the domain name www.service1.io.

After that, we need to use the gateway just now to bind the service of our service. At this time, we need to use VirtualService:

apiVersion: networking.istio.io/v1alpha3  
kind: VirtualService  
metadata:  
  name: k8s-combat-istio-http-vs  
spec:  
  gateways:  
    - istio-ingress-gateway # 绑定刚才创建的 gateway 名称 
  hosts:  
    - www.service1.io
http:
- name: default  
  route:  
    - destination:  
        host: k8s-combat-service-istio-mesh  #service 名称
        port:  
          number: 8081  
        subset: v1
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.

This is the same as the VirtualService configuration used for Mesh internal traffic we talked about before.

The meaning here is that traffic passing through www.service1.io and istio-ingress-gateway will enter this virtual service, but all requests will enter the subset: v1 group.

This grouping information can be found in the previous section:

apiVersion: networking.istio.io/v1alpha3  
kind: DestinationRule  
metadata:  
  name: k8s-combat-service-ds  
spec:  
  host: k8s-combat-service-istio-mesh  
  subsets:  
    - name: v1  
      labels:  
        app: k8s-combat-service-v1  
    - name: v2  
      labels:  
        app: k8s-combat-service-v2
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.

After that, we can get the response by accessing this domain name. At the same time, we open the Pod of k8s-combat-service-istio-mesh service and check the log. We will find that all requests enter v1. If this restriction is not needed, set subset: v1 Just delete it.

curl  http://www.service1.io/ping
1.

Local host needs to be configured: 127.0.0.1 www.service1.io

picture

Another point is that we need to get the external IP of the gateway before we can bind the IP to the domain name www.service1.io (host, or domain name management console).

If you are using the kubernetes cluster that comes with docker-desktop, just use 127.0.0.1 and it will be bound by default.

If you are using minikube to install it, you need to use minikube tunnel to manually bind a local IP to the service for the LoadBalancer type. For details, please refer to the document: https://minikube.sigs.k8s.io/docs/tasks/loadbalancer

If it is used in a production environment, the cloud service provider will automatically bind an external IP.

principle

picture

The process of this access request is similar to the kubernetes Ingress process mentioned before, except that the gateway is a service routed through VirtualService, and many routing rules can be customized in this VirtualService.

Summarize

The service grid Istio is basically finished. The traces, logs, and metrics related to Telemetry will be updated in the operation and maintenance chapter and will also be related to Istio. Interested friends can continue to pay attention.

All the source code of this article can be accessed here: https://github.com/crossoverJie/k8s-combat