Analysis of Kubernetes Application Deployment model (deployment)

Analysis of Kubernetes Application Deployment model (deployment)

[Editor's note] Kubernetes can be used to manage Linux container clusters, accelerate development and simplify O & M (that is, DevOps ). However, at present, the number of articles on Kubernetes on the network is much higher than the actual usage. This series of articles focuses on actual deployment and gives you a quick grasp of Kubernetes. After introducing the principles and concepts that need to be understood before deployment, the author presents the use of the replicaser and Service with a simple nginx Service in this article, by analyzing the cluster IP address and NodePort of the Service, you can understand the network characteristics in this model.

A simple application

After talking about so many principles and concepts, this chapter describes how to deploy a simple application to feel the deployment model of Kubernetes.

Deploy a Kubernetes Cluster

There are dozens of deployment documents for various environments on the kubernetes github site. This article selects the Ubuntu-Based Cluster Deployment Solution. When you do not use a local docker image, make sure that you can access the site gcr. io during deployment.

The Ubuntu-Based Cluster Deployment Solution documentation is detailed, and there are almost no errors according to its steps. Make sure that:

1. Docker version 1.2 + and bridge-utils are installed on all nodes.
2. If you do not have a local docker registry, make sure that the node can access the Internet gcr. io.
3. Make sure that the management node can access all nodes through ssh. For example, ssh gongysh@192.168.0.201 ls

Here, our cluster will adopt the display structure. We will run the cluster management command on the Management node. We will have a service and proxy node, and two pure proxy nodes.

 

First, download the kubernetes code to the management node:

 

$ git clone https://github.com/GoogleCloudPlatform/kubernetes.git

Then perform local build:

cd kubernetes./build/run.sh hack/build-do.sh

Modify the config-default.sh to define the cluster. Several key configurations used in this article are as follows:

gongysh@Fedora20:~/git/kubernetes/cluster/ubuntu$ cat config-default.sh#!/bin/bash# Define all your cluster nodes, MASTER node comes first"# And separated with blank space like <user_1@ip_1> <user_2@ip_2> <user_3@ip_3>export nodes="gongysh@192.168.0.201 gongysh@192.168.0.202 gongysh@192.168.0.203"# Define all your nodes role: a(master) or i(minion) or ai(both master and minion), must be the order sameexport roles=("ai" "i" "i")# Define minion numbersexport NUM_MINIONS=${NUM_MINIONS:-3}# define the IP range used for service portal.# according to rfc 1918 ref: https://tools.ietf.org/html/rfc1918 choose a private ip range here.export SERVICE_CLUSTER_IP_RANGE=192.168.3.0/24# define the IP range used for flannel overlay network, should not conflict with above SERVICE_CLUSTER_IP_RANGE rangeexport FLANNEL_NET=172.16.0.0/16....

Finally, run the cluster build command:

$ cd cluster$ KUBERNETES_PROVIDER=ubuntu ./kube-up.sh

When you see:

Kubernetes cluster is running.  The master is running at:   http://192.168.0.201 ... calling validate-cluster Found 3 nodes.      1NAME            LABELS    STATUS      2192.168.0.201   <none>    Ready      3192.168.0.202   <none>    Ready      4192.168.0.203   <none>    Ready Validate output: Cluster validation succeeded Done, listing cluster services: Kubernetes master is running at http://192.168.0.201:8080 

Indicates that the cluster is successfully built.

Deploy nginx applications

The following figure shows how to install an nginx application with simple static content:

 

First, we use the replicaset to start an nginx Pod with two backups. Then, a Service is mounted to the front. A service can only be accessed within the cluster, and a Service can be accessed by nodes outside the cluster. All the following commands are run on the Management node.

Deploy nginx pod and replicator

See the following table:

 

$ cat nginx-rc.yaml apiVersion: v1 kind: ReplicationController metadata:   name: nginx-controller spec:   replicas: 2   selector:     name: nginx   template:     metadata:       labels:         name: nginx     spec:       containers:         - name: nginx           image: nginx           ports:             - containerPort: 80

 

We have defined an nginx pod replicaser with 2 copies. We use the nginx docker image.

Perform the following operations to create an nginx pod replicaser:

 

$  kubectl -s http://192.168.0.201:8080 create -f nginx-rc.yaml

 

Kubernetes needs to go to gcr. io to download the gcr. io/google_containers/pause image, and then download the nginx image. Therefore, it takes some time for the created Pod to be running.

$  kubectl -s http://192.168.0.201:8080 get podsNAME                     READY     REASON    RESTARTS   AGEnginx-controller-6zr34   1/1       Running   0          48mnginx-controller-njlgt   1/1       Running   0          48m

We can use the describe command to view the nodes assigned to the pod:

$  $ kubectl -s http://192.168.0.201:8080 describe pod nginx-controller-6zr34 2>/dev/null | grep Node:Node:192.168.0.203/192.168.0.203$ kubectl -s http://192.168.0.201:8080 describe pod nginx-controller-njlgt 2>/dev/null | grep Node:Node:192.168.0.201/192.168.0.201

As shown in the table above, the replicaset starts two pods and runs on the host of the 192.168.0.201 and 203 proxy nodes respectively.

Deployment nodes can access the nginx service

Service types include ClusterIP and NodePort. The default value is ClusterIP. services of this type can only be accessed within the cluster. The following table lists the configuration files used in this document:

$ cat nginx-service-clusterip.yaml apiVersion: v1 kind: Service metadata:   name: nginx-service-clusterip spec:   ports:     - port: 8001       targetPort: 80       protocol: TCP   selector:     name: nginx 

Run the following command to create a service:

$ kubectl -s http://192.168.0.201:8080 create -f ./nginx-service-clusterip.yaml  services/nginx-service $ kubectl -s http://192.168.0.201:8080 get serviceNAME                      LABELS                                    SELECTOR     IP(S)           PORT(S)kubernetes                component=apiserver,provider=kubernetes   <none>       192.168.3.1     443/TCPnginx-service-clusterip   <none>                                    name=nginx   192.168.3.91   8001/TCP

 

Verify service accessibility:

The above output tells us that the Cluster IP of this Service is 192.168.3.91, and the port is 8001. The following describes how the PortalNet IP works:

$ ssh 192.168.0.202 curl -s 192.168.3.91:8001  <!DOCTYPE html> 
From the previous deployment of the replicaser, we know that the nginx Pod runs on nodes 201 and 203. We specifically accessed our services from 202 proxy nodes to demonstrate the accessibility of Service Cluster IP addresses on all Cluster proxy nodes.
Deploy an externally accessible nginx service
Next we will create a NodePort Service, which is accessible outside the cluster. The following table lists the configuration files used in this document:
 
$ cat nginx-service-nodeport.yaml apiVersion: v1 kind: Service metadata:   name: nginx-service-nodeport spec:   ports:     - port: 8000      targetPort: 80       protocol: TCP   type: NodePort  selector:     name: nginx 
Run the following command to create a service:
 
$ kubectl -s http://192.168.0.201:8080 create -f ./nginx-service-nodeport.yaml  services/nginx-service-nodeport $ kubectl -s http://192.168.0.201:8080 get serviceNAME                      LABELS                                    SELECTOR     IP(S)          PORT(S)kubernetes                component=apiserver,provider=kubernetes   <none>       192.168.3.1    443/TCPnginx-service-clusterip   <none>                                    name=nginx   192.168.3.91   8001/TCPnginx-service-nodeport    <none>                                    name=nginx   192.168.3.84   8000/TCP
 
Run the following command to obtain the node-level port of the service:
 
$ kubectl -s http://192.168.0.201:8080 describe service nginx-service-nodeport 2>/dev/null | grep NodePortType:NodePortNodePort:<unnamed>32606/TCP
 
Verify service accessibility:
The above output tells us that the node-level port of this Service is 32606. The following describes how the Service works:
 
$ curl 192.168.0.201:32606  <!DOCTYPE html> 
 
IP tables rule parsing on proxy nodes
The following figure shows the table and chain of traffic passing through IPTables.


As you can see, Kubernetes inserts the following four chains in the nat table:
1. KUBE-PORTALS-CONTAINER
This chain is mainly used to map the cluster IP of all service objects and the port to the local port of kube-proxy. For example, the following rule:
-A KUBE-PORTALS-CONTAINER -d 192.168.3.84/32 -p tcp -m comment --comment "default/nginx-service-nodeport:" -m tcp --dport 8000 -j REDIRECT --to-ports 43981
It is prepared for the Cluster IP address of the nginx-service-nodeport service. 192.168.3.84/32 is the Cluster IP address obtained by the Service, and port 8000 is the spec. ports. port specified in the definition file. 43981 is the local port allocated by kube-proxy for this service. The rule means redirect traffic to 192.168.3.84: 8000 to 43981.
2. KUBE-NODEPORT-CONTAINER
The chain Concatenates the NodePort rules of the service type NodePort. For example, the following rule:
-A KUBE-NODEPORT-CONTAINER -p tcp -m comment --comment "default/nginx-service-nodeport:" -m tcp --dport 32606 -j REDIRECT --to-ports 43981
It is prepared for nodeport 32606 of the nginx-service-NodePort service. This indicates that the traffic destined for the local port 32606 is redirected to port 43981, which is the local port allocated by kube-proxy for this service.
3. KUBE-PORTALS-HOST
This chain is also associated with the Cluster IP address and Port rules of each service, such:
 
-A KUBE-PORTALS-HOST -d 192.168.3.84/32 -p tcp -m comment --comment "default/nginx-service-nodeport:" -m tcp --dport 8000 -j DNAT --to-destination 192.168.0.201:43981
 
This rule is similar to KUBE-PORTALS-CONTAINER, except that the traffic comes from local processes.
4. KUBE-NODEPORT-HOST
This chain is associated with the NodePort rules of the service type NodePort. For example, the following rule:
-A KUBE-NODEPORT-HOST -p tcp -m comment --comment "default/nginx-service-nodeport:" -m tcp --dport 30975 -j DNAT --to-destination 192.168.0.201:43981
This rule is similar to KUBE-NODEPORT-CONTAINER, except that the traffic comes from local processes.
Summary
I believe that Docker is not just a container, but a group of Application Deployment-centric technologies, products, and Best Practices ecosystems. Kubernetes has its roots, maturity of documents, and community support in this ecosystem. When deploying Kubernetes, we must first understand the component structure of Kubernetes, the roles they have, and the roles they serve to communicate. It is very important to understand the Kubernetes application model during application deployment. I believe that the concept of replicaset and Service is the core of the Kubernetes model. The replicaset and Service fulfill the high availability requirements of applications. Finally, this article presents the use of the replicaser and Service with a simple nginx Service. In particular, by analyzing the cluster IP address and NodePort of the Service, readers can understand the network characteristics in this model.
Finally, the selection of container technology. This article uses Docker as a container. In fact, Kubernetes also supports rkt containers of CoreOS. The kubelet parameter -- container_runtime is used to select the container technology used.
OpenStack, Kubernetes, and Mesos
Problems encountered during Kubernetes cluster construction and Solutions
For details about Kubernetes, click here
Kubernetes: click here
This article permanently updates the link address: