A preliminary study on Kubernetes (i.)

Kubernetes is Google's Open source container cluster management system. It is built on Docker technology and provides a whole set of functions, such as resource scheduling, deployment operation, service discovery, expansion and contraction capacity, for containerized applications, which can be regarded as Mini-paas platform based on container technology. The purpose of this article is to comb the architecture, concepts, and basic workflows of kubernetes, and to describe how to use kubernetes by running a simple sample application. General overview  As shown in my preliminary reading of the document and the source code after the overall overview, basically can be from the following three dimensions to understand kubernetes. Manipulating objects  Kubernetes opens the interface in a restful form, with three user-operable rest objects:

• pod: Is the most basic deployment dispatch unit of Kubernetes, which can contain container, which logically represents an instance of an application. For example, a Web site application is built from the front end, back end, and database, and these three components will run in their own containers, so we can create pods with three container.

• Service: Is the route agent abstraction of the pod, which is used to resolve the discovery of services between pods. Because the operating state of the pod can be changed dynamically (such as switching machines, terminating in the process of shrinking, etc.), the access terminal cannot access the service provided by the Pod by writing dead IP. The introduction of the service is designed to ensure that the dynamic changes to the pod are transparent to the access side, which only needs to know the address of the service to provide the proxy by service.

• Replicationcontroller: is a copy abstraction of Pod, which solves the problem of expansion and contraction of pod. In general, distributed applications need to replicate multiple resources for performance or high availability, and dynamically scale based on load conditions. With Replicationcontroller, we can specify that an application requires several copies, Kubernetes will create a pod for each copy, and ensure that the actual number of pods is always equal to the number of copies (for example, when a pod is currently down, Automatically creates a new pod to replace).

As you can see, the service and Replicationcontroller are just abstractions built on the pod, and ultimately in the pod, how do they relate to the pod? This introduces the concept of label: The label is a good understanding of the pod plus a set of key/value tags that can be used for search or association, and the service and Replicationcontroller are associated with the pod by label. As shown, there are three pods with the label "App=backend", and when creating service and Replicationcontroller you can specify the same label: "App=backend", and then through the label selector mechanism, They are associated with these three pods. For example, when another frontend pod accesses the service, it is automatically forwarded to one of the backend pods. Functional components  As shown in the official documentation for the cluster architecture diagram, a typical master/slave model. Master runs three components:

• apiserver: As the entrance of the kubernetes system, it encapsulates the additions and deletions of core objects, which are provided to external customers and internal component calls in a restful interface. The rest objects it maintains are persisted to ETCD, a distributed, strongly-consistent key/value store.

• Scheduler: Responsible for the resource scheduling of the cluster, assigning the machine to the new pod. This part of the work is divided into a component, which means that it is easy to replace it with other schedulers.

• Controller-manager: Responsible for the implementation of various controllers, there are currently two categories:
• • Endpoint-controller: Periodically correlate the service and POD (the association information is maintained by the endpoint object), ensuring that service-to-pod mappings are always up-to-date.
  • Replication-controller: Periodically correlate replicationcontroller and pods to ensure that the number of copies Replicationcontroller defined is always the same as the number of pods actually running.

Slave (called Minion) runs two components:

• Kubelet: Responsible for the control of Docker containers, such as Start/stop, monitor operation status. It periodically obtains pods assigned to the native from Etcd, and starts or stops the appropriate containers based on pod information. It also receives Apiserver HTTP requests to report the status of the pod.

• Proxy: Responsible for providing the agent for the pod. It periodically obtains all the service from ETCD and creates an agent based on the service information. When a customer pod accesses another pod, the access request is forwarded by the native proxy.

Work Flow  The three most basic operating objects in Kubernetes are mentioned above: Pod, Replicationcontroller, and service. The following separate from their object creation, through the time series diagram to describe the interaction between the various components of kubernetes and their workflow.

Using the example

Finally, let's go into combat mode, where a simple stand-alone example (all components running on a single machine) is designed to get through the basic process.

Build the Environment

In the first step, we need to kuberntes the binary executables of each component. The following two ways are available:

• Download the source code to compile yourself:

1. git clone https://github.com/GoogleCloudPlatform/kubernetes.git
2. CD Kubernetes/build
3. ./release.sh

• Directly download the tar file that has been compiled and packaged:

1. wget https://storage.googleapis.com/kubernetes/binaries.tar.gz

Compile your own source code needs to install the Golang, after compiling in the Kubernetes/_output/release-tars folder can be packaged files. The direct download does not require the installation of additional software, but may not have the latest version. In the second step, we also need the ETCD binary executable file, which is obtained by the following way:

1. wget https://github.com/coreos/etcd/releases/download/v0.4.6/etcd-v0.4.6-linux-amd64.tar.gz
2. Tar xvf etcd-v0.4.6-linux-amd64.tar.gz

In the third step, you can start each component: ETCD

1. CD ETCD-V0.4.6-LINUX-AMD64
2. ./etcd

Apiserver

1. ./apiserver \
2. -address=127.0.0.1 \
3. -port=8080 \
4. -portal_net= "172.0.0.0/16" \
5. -ETCD_SERVERS=HTTP://127.0.0.1:4001 \
6. -machines=127.0.0.1 \
7. -v=3 \
8. -logtostderr=false \
9. -log_dir=./log

Scheduler

1. ./scheduler-master 127.0.0.1:8080 \
2. -v=3 \
3. -logtostderr=false \
4. -log_dir=./log

Controller-manager

1. ./controller-manager-master 127.0.0.1:8080 \
2. -v=3 \
3. -logtostderr=false \
4. -log_dir=./log

Kubelet

1. ./kubelet \
2. -address=127.0.0.1 \
3. -PORT=10250 \
4. -hostname_override=127.0.0.1 \
5. -ETCD_SERVERS=HTTP://127.0.0.1:4001 \
6. -v=3 \
7. -logtostderr=false \
8. -log_dir=./log

Create pod
Once you've set up your environment, you're ready to submit the pod. First, the pod description file is written and saved as Redis.json:

2. {
4. "id": "Redis",
6. "Desiredstate": {
8. "Manifest": {
10. "Version": "V1beta1",
12. "id": "Redis",
14. "Containers": [{
16. "Name": "Redis",
18. "Image": "Dockerfile/redis",
20. "Imagepullpolicy": "Pullifnotpresent",
22. "Ports": [{
24. "Containerport": 6379,
26. "Hostport": 6379
28. }]
30. }]
32. }
34. },
36. "Labels": {
38. "Name": "Redis"
40. }
42. }

Then, through the command-line tool, Kubecfg commits:

1. ./kubecfg-c Redis.json Create/pods

After submission, check the pod status via kubecfg:

2. #./kubecfg List/pods
4. ID Image (s) Host Labels Status
6. ----------          ----------          ----------          ----------          ----------
8. Redis Dockerfile/redis 127.0.0.1/name=redis Running

Status is running that the pod is already running in the container, and you can use the Docker PS command to view the container information:

2. # docker PS
4. container id        image                      COMMAND                 CREATED              STATUS               PORTS                     names  
6. Ae83d1e4b1ec dockerfile/redis:latest "redis-server/etc/r seconds ago up seconds K8s_redis.caa18858_redis.default.etcd_1414684622_1b43fe35

Create Replicationcontroller

2. {
4. "id": "Rediscontroller",
6. "Apiversion": "V1beta1",
8. "Kind": "Replicationcontroller",
10. "Desiredstate": {
12. "Replicas": 1,
14. "Replicaselector": {"name": "Redis"},
16. "Podtemplate": {
18. "Desiredstate": {
20. "Manifest": {
22. "Version": "V1beta1",
24. "id": "Rediscontroller",
26. "Containers": [{
28. "Name": "Redis",
30. "Image": "Dockerfile/redis",
32. "Imagepullpolicy": "Pullifnotpresent",
34. "Ports": [{
36. "Containerport": 6379,
38. "Hostport": 6379
40. }]
42. }]
44. }
46. },
48. "Labels": {"name": "Redis"}
50. }},
52. "Labels": {"name": "Redis"}
54. }

Then, through the command-line tool, Kubecfg commits:

1. ./kubecfg-c Rediscontroller.json Create/replicationcontrollers

After submission, check the Replicationcontroller status via kubecfg:

1. #./kubecfg List/replicationcontrollers
2. ID Image (s) Selector replicas
3. ----------          ----------          ----------          ----------
4. Rediscontroller Dockerfile/redis Name=redis 1

At the same time, 1 pods will be created automatically, even if we deliberately delete the Pod,replicationcontroller will also guarantee the creation of 1 new pods.

A preliminary study on Kubernetes (i.)