A tentative study of 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 overviewas 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 ObjectsKubernetes 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 will introduce the concept of label:The label is well understood to be the addition of a set of key/value tags that can be used for search or association, and the service and Replicationcontroller are associated with the pod via a 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 Componentsas 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 The number of copies defined by Replicationcontroller 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 FlowThe 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.

A tentative study of Kubernetes (I.)