Shulou(Shulou.com)06/03 Report--

Overview of Kubernetes

Kubernetes is an open source container orchestration engine for Google, which supports automated deployment, large-scale scalability, and application containerization management. When deploying an application in a production environment, multiple instances of the application are usually deployed to load balance application requests.

In Kubernetes, we can create multiple containers and run an application instance in each container, and then manage, discover and access this group of application instances through the built-in load balancing policy, and these details do not need to be manually configured and processed by operation and maintenance personnel.

Characteristics of Kubernetes

Portable: supports public cloud, private cloud, hybrid cloud, multiple cloud (multi-cloud)

Extensible: modular, plug-in, mountable, combinable

Automation: automatic deployment, automatic restart, automatic replication, automatic scaling / expansion

Background

Ingress is a rule that maps how services within the cluster bridge the gap and expose the outside world where customers can use it. In this article, the author will help you understand the driving forces behind the Ingress pattern.

I don't know if you have noticed a strange phenomenon, although Kubernetes Ingress API is still in the bata state, many companies have used it to expose Kubernetes services. Engineers working on the project say Kubernetes Ingress API is increasingly likely to take off its beta tag.

In fact, Kubernetes Ingress API has been in the beta state for several years and began to enter this stage in the fall of 2015, to be exact. However, the long beta phase gives Kubernetes contributors time to refine the specification and align it with already built implementation software (HAProxy, NGINX, Traefik, etc.), thus standardizing API to reflect the most common and required functions.

Note: the version of Traefik used in this article is 1.x

In a production environment, we often need to control external entry into the cluster from the Internet, which happens to be the responsibility of Ingress.

The main purpose of Ingress is to expose HTTP and HTTPS from outside the cluster to the services running in the cluster. This is similar to how Ingress controls how external traffic is routed to the cluster. Next, let's give a practical example to illustrate the concept of Ingress more clearly.

First, imagine that there are several microservices (small applications that communicate with each other) in your Kubernetes cluster. These services can be accessed within the cluster, but we want our users to be able to access them from outside the cluster. Therefore, what we need to do is to use a reverse proxy to associate each HTTP (S) route (for example, service.yourdomain.com) with the corresponding backend and load balance between different instances of the service (for example, pod). At the same time, because the nature of the Kubernetes is constantly changing, we want to track changes at the service backend so that we can reassociate these HTTP routes to the new Pod instance when new Pod is added or removed

Using Ingress resources and the associated Ingress Controller, you can achieve the following goals:

Point your domain app.domain.com to microservice applications in your private network

Point the path domain.com/web to the microservice web in your private network

Point your domain backend.domain.com to the microservice backend in your VPC, and load balance among multiple instances of the microservice (Pod)

Now you understand the importance of Ingress. It helps to direct HTTP routes to specific microservices in the Kubernetes cluster.

However, traffic routing is not the only function of Ingress in Kubernetes. For example, Ingress can also be configured to load balance traffic to your application, terminate SSL, execute name-based virtual hosts, distribute traffic between different services, set service access rules, and so on.

Kubernetes has a special Ingress API resource that supports all of the above functions. However, it is useless to simply create an Ingress API resource. You need another Ingress Controller. Currently, Kubernetes supports many Ingress controller, such as Contour, HAProxy, NGINX, and Traefik.

In this article, I will use Traefik Ingress Controller to create an Ingress. It can realize the functions of modern HTTP reverse proxy and load balancer, thus simplifying the deployment of micro-services. In addition, Traefik provides strong support for Docker, Marathon, Consul, Kubernetes, Amazon ECS and other systems and environments.

Traefik is useful for more flexible systems such as Kubernetes. In Kubernetes, services need to be added, deleted or upgraded several times a day, and Traefik can listen to the service image repository / choreographer API and immediately generate or update routes, so your micro-service can connect with the outside world without manual configuration.

In addition, Traefik supports multiple load balancing algorithms, Let's Encrypt's HTTPS (supports wildcard certificates), circuit breakers, WebSoket, GRPC and multiple monitoring programs (Rest, Prometheus, Statsd, Datadog, InfluxDB, etc.). For more information about the features available in Traefik, please refer to its official documentation:

Https://docs.traefik.cn/

Ingress resources

Before starting the tutorial, let's briefly discuss how Ingress resources work. The following is an example of Ingress that implicitly uses Nginx Ingress Controller.

ApiVersion: extensions/v1beta1kind: Ingressmetadata: name: ingress-example annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec: rules:-http: paths:-path: / microservice1 backend: serviceName: test servicePort: 80

The above Ingress manifest contains a series of HTTP rules that specify how controller routes traffic.

Optional host. If no host is specified (as shown above), this rule applies to all inbound HTTP traffic that passes through the specified IP address. If a host (such as yourhost.com) is provided, the rule applies only to that host.

A list of paths (for example, / microservice1) that points to the associated backend defined by serviceName and servicePort.

A backend. The HTTP (and HTTPS) request to Ingress will match the host and path of the given rule and then route it to the back-end service specified in that rule.

In the above example, we configured a backend called "test" that will receive all traffic from the / microservice path. However, we can also configure a default backend that will serve any user requests that do not conform to the path in the specification. At the same time, if no rules are defined, Ingress routes all traffic to the default backend. For example:

ApiVersion: extensions/v1beta1kind: Ingressmetadata: name: test-ingressspec: backend: serviceName: defaultbackend servicePort: 80

In this example, all traffic is forwarded to the default backend defaultbackend. Now that we understand the basic concepts of Ingress resources, let's look at some concrete examples.

Step 0: preparation

As we said above, defining an Ingress resource doesn't work unless you use Ingress Controller. In this tutorial, we set Traefik to Ingress Controller in the Kubernetes cluster.

To complete the tutorial, you need to make the following preparations:

A running Kubernetes cluster.

An installed command line tool, kubectl. And configured to communicate with the cluster.

Please note: the following examples all assume that you are running a Kubernetes cluster using Minikube on local computing.

Step 1: enable RBAC

First, we need to grant some permissions to Traefik to access the Pod, endpoint, and services running in the cluster. To do this, we will use ClusterRole and ClusterRoleBinding resources. However, you can also use the least privileged method for RoleBindings within the scope of the namespace. In general, this is the preferred approach if the namespaces of the clusters do not change dynamically and Traefik cannot monitor the namespaces of all clusters.

Let's create a new ServiceAccount that provides Traefik with the identity in the cluster.

ApiVersion: v1kind: ServiceAccountmetadata: name: traefik-ingress namespace: kube-system

To create a ServiceAccount, save the above manifest in traefik-service-acc.yaml and run:

Kubectl create-f traefik-service-acc.yamlserviceaccount "traefik-ingress" created

Next, let's create a ClusterRole with a set of permissions that will be applied to Traefik ServiceAccount. ClusterRole,Traefik allows you to manage and monitor resources in all namespaces in the cluster, such as services, endpoint, secret, and Ingress.

Kind: ClusterRoleapiVersion: rbac.authorization.k8s.io/v1beta1metadata: name: traefik-ingressrules:-apiGroups:-"" resources:-services-endpoints-secrets verbs:-get-list-watch-apiGroups:-extensions resources:-ingresses verbs:-get-list-watch

Save this specification to the file traefik-cr.yaml and run:

Kubectl create-f traefik-cr.yamlclusterrole.rbac.authorization.k8s.io "traefik-ingress" created

Finally, to enable these permissions, we should bind ClusterRole to Traefik ServiceAccount. You can do this using ClusterRoleBinding manifest:

Kind: ClusterRoleBindingapiVersion: rbac.authorization.k8s.io/v1beta1metadata: name: traefik-ingressroleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: traefik-ingresssubjects:- kind: ServiceAccount name: traefik-ingress namespace: kube-system

Save this specification to traefik-crb.yaml and run the following command:

Kubectl create-f traefik-crb.yamlclusterrolebinding.rbac.authorization.k8s.io "traefik-ingress" createdStep 2: deploy Traefik to the cluster

Next, we will deploy Traefik to the Kubernetes cluster. The official Traefik documentation supports three types of deployment: using Deployment objects, using DaemonSet objects, or using Helm Chart.

In this tutorial, we will use Deployment manifest. Deployment has many advantages over other options. For example, they ensure better scalability and provide good support for rolling updates.

Let's take a look at Deployment manifest:

Kind: DeploymentapiVersion: extensions/v1beta1metadata: name: traefik-ingress namespace: kube-system labels: k8s-app: traefik-ingress-lbspec: replicas: 1 selector: matchLabels: k8s-app: traefik-ingress-lb template: metadata: labels: k8s-app: traefik-ingress-lb name: traefik-ingress-lbspec: serviceAccountName: traefik-ingress terminationGracePeriodSeconds: 60 containers:-image: traefik name : traefik-ingress-lb ports:-name: http containerPort: 80-name: admin containerPort: 8080 args:-api-kubernetes-logLevel=INFO

This Deployment will create a copy of Traefik in the kube-system namespace. The Traefik container will use ports 80 and 8080 specified in this manifest.

Save the manifest to the traefik-deployment.yaml file and run the following command to create the Deployment:

Kubectl create-f traefik-deployment.yamldeployment.extensions "traefik-ingress" created

Now, let's check to see if the Traefik Pod has been created successfully:

Kubectl-namespace=kube-system get podsNAME READY STATUS RESTARTS AGE....storage-provisioner 1 Running 1 Running 3 23dtraefik-ingress-54d6d8d9cc-ls6cs 1 Running 0 1m

As you can see, Deployment Controller starts a copy of Traefik and is running, knock on the stick!

Step 3: create a NodePorts for external access

Let's create a service to access Traefik from outside the cluster. To do this, we need a service that exposes two NodePorts.

Kind: ServiceapiVersion: v1metadata: name: traefik-ingress-service namespace: kube-systemspec: selector: k8s-app: traefik-ingress-lb ports:-protocol: TCP port: 80 name: web-protocol: TCP port: 8080 name: admin type: NodePort

Save the manifest to traefik-svc.yaml and create the service:

Kubectl create-f traefik-svc.yamlservice "traefik-ingress-service" created

Now, let's verify that the service is created:

Kubectl describe svc traefik-ingress-service-- namespace=kube-systemName: traefik-ingress-serviceNamespace: kube-systemLabels: Annotations: Selector: k8s-app=traefik-ingress-lbType: NodePortIP: 10.102.215.64Port: web 80/TCPTargetPort: 80/TCPNodePort: web 30565/TCPEndpoints: 172.17.0.6:80Port: admin 8080/TCPTargetPort: 8080/TCPNodePort: admin 30729/TCPEndpoints: 172.17.0.6:8080Session Affinity: NoneExternal Traffic Policy: ClusterEvents:

As you can see, we now have two NodePorts (web and admin) that are routed to the 80 and 8080 container ports of Traefik Ingress Controller, respectively. "admin" NodePort will be used to access Traefik Web UI, and "web" NodePort will be used to access services exposed through Ingress.

Step 4: visit Traefik

In order to access Traefik Web UI in a browser, you can use "admin" NodePort 30729 (please note that your NodePort value may be different). Because we haven't added any front ends yet, the UI should be empty at this time.

Since we haven't configured Traefik yet, we will receive a response of 404.

Curl $(minikube ip): 30565404 page not foundStep 5: add Ingress to the cluster

Now we have Traefik as the Ingress Controller in the Kubernetes cluster. However, we still need to define Ingress resources and services that expose Traefik Web UI.

First, we create a service:

ApiVersion: v1kind: Servicemetadata: name: traefik-web-ui namespace: kube-systemspec: selector: k8s-app: traefik-ingress-lb ports:-name: web port: 80 targetPort: 8080

Save manifest to traefik-webui-svc.yaml and run:

Kubectl create-f traefik-webui-svc.yamlservice "traefik-web-ui" created

Let's verify that the service has been created:

Kubectl describe svc traefik-web-ui-- namespace=kube-systemName: traefik-web-uiNamespace: kube-systemLabels: Annotations: Selector: k8s-app=traefik-ingress-lbType: ClusterIPIP: 10.98.230.58Port: web 80/TCPTargetPort: 8080/TCPEndpoints: 172.17.0.6:8080Session Affinity: NoneEvents:

As you can see, the ClusterIP of the service is 10.98.230.58, and the designated port is assigned in the manifest.

Next, we need to create an Ingress resource that points to the Traefik Web UI backend:

ApiVersion: extensions/v1beta1kind: Ingressmetadata: name: traefik-web-ui namespace: kube-systemspec: rules:-host: traefik-ui.minikube http: paths:-path: / backend: serviceName: traefik-web-ui servicePort: web

In essence, Ingress routes all requests to traefik-ui.minikube, and the service created in the above steps exposes the Traefik Web UI.

Save the specification to traefik-ingress.yaml and run:

Kubectl create-f traefik-ingress.yamlingress.extensions "traefik-web-ui" created

In order to be able to access Traefik Web UI in the browser through traefik-ui.minikube, we need to add new entries to our / etc/hosts file. The entry will contain the Minikube IP and hostname. You can get the IP address of the minkube instance by running minikube ip, and then save the name of the new host to the / etc/hosts file, as shown below:

Echo "$(minikube ip) traefik-ui.minikube" | sudo tee-a / etc/hosts192.168.99.100 traefik-ui.minikube

You should now be able to access http://traefik-ui.minikube: and view Traefik Web UI in your browser. Don't forget to attach the "admin" NodePort to the host address.

In dashboard, you can click the Health link to view the health of the application:

Step 6: implementing name-based routing

Now, let's demonstrate how to use Traefik Ingress Controller to set up name-based routing for front-end lists. We will use a simple single-page website to create three Deployment and display animal images: bear, hare and moose.

-kind: DeploymentapiVersion: extensions/v1beta1metadata: name: bear labels: app: animals animal: bearspec: replicas: 2 selector: matchLabels: app: animals task: bear template: metadata: labels: app: animals task: bear version: v0.0.1 spec: containers:-name: bear image: supergiantkir/animals:bear ports:-containerPort: 80 -kind: DeploymentapiVersion: extensions/v1beta1metadata: name: moose labels: app: animals animal: moosespec: replicas: 2 selector: matchLabels: app: animals task: moose template: metadata: labels: app: animals task: moose version: v0.0.1 spec: containers:-name: moose image: supergiantkir/animals:moose ports:-containerPort: 80 -kind: DeploymentapiVersion: extensions/v1beta1metadata: name: hare labels: app: animals animal: harespec: replicas: 2 selector: matchLabels: app: animals task: hare template: metadata: labels: app: animals task: hare version: v0.0.1 spec: containers:-name: hare image: supergiantkir/animals:hare ports:-containerPort: 80

Each Deployment will have two copies of Pod, and each Pod will serve the Animal website on containerPort 80.

Let's save these Deployment manifest to animals-deployment.yaml and run:

Kubectl create-f animals-deployment.yamldeployment.extensions "bear" createddeployment.extensions "moose" createddeployment.extensions "hare" created

Now, let's create a service for each Deployment so that Pod can access:

-apiVersion: v1kind: Servicemetadata: name: bearspec: ports:-name: http targetPort: 80 port: 80 selector: app: animals task: bear---apiVersion: v1kind: Servicemetadata: name: moosespec: ports:-name: http targetPort: 80 port: 80 selector: app: animals task: moose---apiVersion: v1kind: Servicemetadata: name: hare annotations: traefik.backend.circuitbreaker: "NetworkErrorRatio () > 0.5" spec: ports: -name: http targetPort: 80 port: 80 selector: app: animals task: hare

Please note that the third service uses circuit breaker annotation. Circuit breaker is a function of Traefik to prevent a failed server from bearing a high load. In this example, we prevent the high load on the server from exceeding 50%. When this condition matches, the CB enters a "tripped" state, in which it responds or redirects to another front end using a predefined HTTP status code.

Save these services manifest to animals-svc.yaml and run:

Kubectl create-f animals-svc.yamlservice "bear" createdservice "moose" createdservice "hare" created

Finally, create an Ingress with three front and rear pairs for each Deployment. Bear.minikube, moose.minikube and hare.minikube will be the front end for us to point to the corresponding back-end services.

The Ingress manifest is as follows:

ApiVersion: extensions/v1beta1kind: Ingressmetadata: name: animals annotations: kubernetes.io/ingress.class: traefikspec: rules:-host: hare.minikube http: paths:-path: / backend: serviceName: hare servicePort: http-host: bear.minikube http: paths:-path: / backend: serviceName: bear servicePort: http-host : moose.minikube http: paths:-path: / backend: serviceName: moose servicePort: http

Save the specification to animals-ingress.yaml and run:

Kubectl create-f animals-ingress.yamlingress.extensions "animals" created

Now, in Traefik dashboard, you can see the front end of each host and the corresponding backend list:

If you edit etc/hosts again, you should be able to access the animal page in your browser:

Echo "$(minikube ip) bear.minikube hare.minikube moose.minikube" | sudo tee-a / etc/hosts

You should use the "web" NodePort to visit specific web pages. For example, http://bear.minikube:

We can also reconfigure the three front ends to provide services under one domain, as follows:

ApiVersion: extensions/v1beta1kind: Ingressmetadata: name: all-animals annotations: kubernetes.io/ingress.class: traefik traefik.frontend.rule.type: PathPrefixStripspec: rules:-host: animals.minikube http: paths:-path: / bear backend: serviceName: bear servicePort: http-path: / moose backend: serviceName: moose servicePort: http-path: / hare backend: serviceName: hare servicePort: http

If you activate this Ingress and use the appropriate path, all three animals can access animals.minikube in one domain. Don't forget to add this field to / etc/hosts.

Echo "$(minikube ip) animals.minikube" | sudo tee-a / etc/hosts

Please note that we are configuring Traefik to remove the prefix from the URL path using traefik.frontend.rule.type annotations. This way we can use the container in the previous example directly. Because of the traefik.frontend.rule.type: PathPrefixStrip rule, you must use http://animals.minikube:32484/moose/ instead of http://animals.minikube:32484/moose

Step 7: achieve traffic distribution

With Traefik, users can use service weights to distribute Ingress traffic among multiple deployment in a controlled manner. This feature can be used for canary releases, which should initially get a small but growing amount of traffic.

Let's use the following manifest to distribute the Traefik between the two microservices:

ApiVersion: extensions/v1beta1kind: Ingressmetadata: annotations: traefik.ingress.kubernetes.io/service-weights: animals-app: 99% animals-app-canary: 1% name: animals-appspec: rules:-http: paths:-backend: serviceName: animals-app servicePort: 80 path: /-backend: serviceName: animals-app-canary servicePort: 80 path: /

Please pay attention to the comments of traefik.ingress.kubernetes.io/service-weights. It specifies how traffic is distributed between the specified back-end services (animals-app and animals-app-canary). Traefik will route 99% of user requests to animals-app deployment-supported Pod and 1% of user requests to animals-app-canary deployment-supported Pod.

For this setting to work properly, some conditions need to be met:

All service backends must share the same path and host.

The total number of requests shared across service backends should total 100%.

Percentage values should be within the range of supported precision, and Traefik currently supports weights of 3 decimal places.

Summary

As you can see, Ingress is a powerful tool for routing external traffic to the corresponding back-end services in the Kubernetes cluster. Users can implement Ingress using many of the Ingress controller supported by Kubernetes. In this tutorial, we focus on Traefik Ingress controller, which supports name-based routing, load balancing, and other common Ingress controller tasks.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.