Kubernetes Ingress Combat

The content of this section:

• Service Discovery and load balancing
• Ingress Combat

First, service discovery and load balancing

In the previous installation deployment Kubernetes cluster, it was simple to demonstrate that pod and Service,kubernetes implemented service discovery and load balancing for containers within the Kubernetes cluster through service resources. Service is one of the Kubernetes services discovery and load balancing.

Currently, load balancing in kubernetes can be broadly divided into the following mechanisms, each of which has its own specific application scenario:

• Service: Provides cluster internal load balancing directly with service and provides external access with lb provided by cloud provider
• Ingress Controller: Provides cluster internal load balancing with service, but provides external access via custom lb
• Service load Balancer: Run the load Balancer directly in the container to implement bare metal's service load Balancer
• Custom load Balancer: Self-balancing and replacement of kube-proxy, generally used in physical deployment kubernetes to facilitate access to the company's existing external services

1. Service

A service is an abstraction of a set of pods that provide the same functionality, and provides them with a unified portal. With services, applications can easily implement service discovery and load balancing, and implement 0 downtime upgrades for applications. The service uses the label to select the backend of the services, usually with replication controller or deployment to ensure the back-end container is running properly. The Pod IP and port lists for these matching tags comprise endpoints, which is the responsibility of the Kube-proxy to balance the service IP load to these endpoints.

There are four types of service:

1. Clusterip: Default type, automatically assigns a virtual IP that can be accessed only cluster internal
2. Nodeport: A port is bound on a clusterip basis for the service on each machine so that the service can be accessed through the <nodeip>:nodeport
3. LoadBalancer: Based on Nodeport, create an external load balancer with the cloud provider and forward the request to the <nodeip>:nodeport
4. Externalname: Forwards the service through the DNS CNAME record to the specified domain name (set by Spec.externlname). Requires a Kube-dns version above 1.7.

Alternatively, you can add existing services to the Kubernetes cluster as a service, simply by not specifying the label selector when you create service, but by manually adding endpoint to it after service creation.

The service solves the problem of services discovery and load balancing, but it has some limitations on its use, such as

• Supports only 4-layer load balancing and No 7-tier functionality
• For external access, the Nodeport type needs to be externally built with additional load balancing, while LoadBalancer requires kubernetes to run on the supported cloud provider.

2. Ingress and Ingress Controller profile

(1) Ingress

Ingress is a new resource introduced to address these limitations, primarily used to expose services outside of cluster, and to customize access policies for services. For example, you want to use a load balancer to implement different sub-domains to different services access:

foo.bar.com--|                 | foo.bar.com s1:80              | 178.91.123.132  |  --|                 | Bar.foo.com s2:80

It is possible to define ingress:

apiversion:extensions/v1beta1kind:ingressmetadata:  name:testspec:  rules:  - Host: Foo.bar.com    http:      paths:      - backend:          servicename:s1            -  Host:bar.foo.com    http:      paths:      - backend:          servicename:s2          

Note: The ingress itself does not automatically create a load balancer, and cluster needs to run a ingress controller to manage the load balancer based on the ingress definition.

The community now offers a reference implementation of Nginx and GCE

Simply put, ingress is accessing the cluster's portal from outside the Kubernetes cluster, forwarding the user's URL request to a different service. Ingress equivalent to Nginx, Apache and other load Balancer direction proxy server, which also includes the rule definition, that is, the URL of the routing information, the routing information is refreshed by the ingress controller to provide.

(2) Ingress Controller

Ingress controller can essentially be understood as a monitor, ingress controller by constantly working with the kubernetes API, real-time perception of backend service, pod and other changes, such as adding and reducing pods, Service increase and decrease etc; When these changes are obtained, the Ingress Controller then builds the configuration with the ingress below, then updates the reverse proxy load balancer and refreshes its configuration to achieve service discovery.

Second, ingress actual combat

Before using the ingress resource, it is necessary to understand the following several things first. Ingress is a beta version of resource, not yet before kubernetes1.1. You need a ingress controller to implement Ingress, simply creating a ingress doesn't make any sense.

The community now offers a reference implementation of Nginx and GCE. Of course there are other implementations, open-source Nginx and Nginx Plus developed the corresponding ingress controller.

• Gce/gke will deploy a ingress controller on the master node. You can deploy any of your custom ingress controllers in one pod. You must correctly annotate each ingress, such as running multiple ingress controllers and shutting down GLBC
• In a non-gce/gke environment, you need to deploy a controller in the pod.

(1) Load balancing with Nginx and Nginx Plus ingress Controller for Kubernetes

Https://github.com/nginxinc/kubernetes-ingress/tree/master/examples/complete-example

[Email protected] nginx_ingress]# Kubectl create-f nginx-ingress-Rbac.yaml[[email protected] nginx_ingress]# kubectl Create-F default-server-Secret.yaml Secret"Default-server-secret"Created[[email protected] nginx_ingress]# kubectl Create-F nginx-ingress-Rc.yamlreplicationcontroller"NGINX-INGRESS-RC"Created[[email protected] nginx_ingress]# Kubectl get pods-L-app=nginx-ingress-o wide NAME ready STATUS restarts age IP Nodenginx-ingress-rc-rs1vh1/1Running0575172.30.87.4   172.16.7.151# view pod logs [[email protected] nginx_ingress]# kubectl logs Nginx-ingress-rc-rs1vhi0924 -: -:37.663514       1Main.go: -] Starting NGINX ingress controller Version1.0.0 ./ the/ -  -: -:Panax Notoginseng[Notice] -# -: Signal Process startedI0924 -: -:37.975349       1Event.go:218] Event (v1. Objectreference{kind:"Secret", Namespace:"default", Name:"Default-server-secret"Uid:"4e2d9567-9f5a-11e7-9acc-005056b7609a", Apiversion:"v1", Resourceversion:"1019701", Fieldpath:""}): Type:'Normal'Reason'Updated'The default server Secret default/default-server-Secret was updated ./ the/ -  -: -:Panax Notoginseng[Notice] -# -: Signal process started ./ the/ -  -: -: -[Notice] -# -: Signal process started ./ the/ -  -: -: -[Notice] the# the: Signal process started ./ the/ -  -: -: -[Notice] -# -: Signal Process startedI0924 -: -:38.073475       1Event.go:218] Event (v1. Objectreference{kind:"Ingress", Namespace:"Kube-system", Name:"Traefik-web-ui"Uid:"5d604da9-9f61-11e7-9acc-005056b7609a", Apiversion:"Extensions", Resourceversion:"1024008", Fieldpath:""}): Type:'Normal'Reason'addedorupdated'Configuration forkube-system/traefik-web-UI was added or updated ./ the/ -  -: -: -[Notice] -# -: Signal Process startedI0924 -: -:38.100887       1Event.go:218] Event (v1. Objectreference{kind:"Ingress", Namespace:"default", Name:"traefik-ingress"Uid:"5d693739-9f61-11e7-9acc-005056b7609a", Apiversion:"Extensions", Resourceversion:"1024009", Fieldpath:""}): Type:'Normal'Reason'addedorupdated'Configuration forDefault/traefik-ingress was added or updated

(2) Configure the service to be tested

Deployment of two services Nginx 1.7 and Nginx 1.8:

ApiVersion:v1kind:Servicemetadata:name:frontendspec:ports:-Port: theTargetport: theselector:app:nginx1-7---Apiversion:apps/v1beta1kind:Deploymentmetadata:name:nginx1-7-Deploymentspec:replicas:2template:metadata:labels:app:nginx1-7spec:containers:-Name:nginx Image:nginx:1.7.9Ports:-Containerport: the

Nginx1-7.yaml

ApiVersion:v1kind:Servicemetadata:name:my-Nginxspec:ports:-Port: theTargetport: theselector:app:nginx1-8---Apiversion:apps/v1beta1kind:Deploymentmetadata:name:nginx1-8-Deploymentspec:replicas:2template:metadata:labels:app:nginx1-8spec:containers:-Name:nginx Image:nginx:1.8Ports:-Containerport: the

Nginx1-8.yaml

[Email protected] nginx_ingress]# kubectl create-f nginx1-7"frontend"  "nginx1-7-deployment"-F nginx1-8" My-nginx "  "nginx1-8-deployment" created

(3) Create ingress

Suppose these two services are exposed to the outside of the cluster. To create a ingress:

[Email protected] nginx_ingress]# vim test-ingress.yamlapiVersion:extensions/v1beta1kind: Ingressmetadata:  name:testspec:  rules:  - host:n17.my.com    http:      paths:      - backend:          servicename:nginx1-7            - Host: N18.my.com    http:      paths:      - backend:          servicename:nginx1-8             the

Create Ingress:

[Email protected] nginx_ingress]# kubectl create-f test-"test"  created[[ Email protected] nginx_ingress]# kubectl get ingname              HOSTS                                  ADDRESS   PORTS     agetest n17.my.com              , n18.my.com                                    52s

Open the client's/etc/hosts, configure the correspondence between 172.16.7.151 and n17.my.com,n18.my.com, and then access the corresponding service in the browser to n17.my.com or n18.my.com.

If you want to modify the access rules, modify the Test-ingress.yaml, use the Kubectl replace-f update.

Kubernetes Ingress Combat