Five minutes of K8S practice - Istio gateway
Five minutes of K8S practice - Istio gateway
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