This article will briefly introduce the core concepts of Kubernetes . Because these definitions can be found in the Kubernetes documentation, the article also avoids long boring text introductions. Instead, we'll use some diagrams (some of which are animations) and examples to explain the concepts. We found that some concepts (such as Service) were difficult to fully understand without the aid of diagrams. Where appropriate, we also provide links to the Kubernetes documentation for further study.
DockOne will hold Kubernetes technical training in Beijing on March 23, 2018. The training content includes: the principle and basic operation of Docker container; container network and storage analysis; detailed explanation of Kubernetes architecture and design concept; Kubernetes resource object usage instructions; Analysis of open interfaces CRI, CNI, and CSI in Kubernetes; Kubernetes monitoring, network, log management; detailed explanation of the development process of container applications, etc. For details, please click the link to view .
Let's get started.
What is Kubernetes?
Kubernetes (k8s) is an open source platform for automating container operations including deployment, scheduling, and scaling across clusters of nodes. If you've ever used Docker container technology to deploy containers, think of Docker as a low-level component used inside Kubernetes. Kubernetes not only supports Docker, but also Rocket, another container technology.
With Kubernetes you can:
- Automated container deployment and replication
- Scale up or down containers at any time
- Organize containers into groups and provide load balancing between containers
- Easily upgrade new versions of application containers
- Provides container resiliency, replaces a container if it fails, etc...
In fact, with Kubernetes , you can deploy a full cluster of multiple layers of containers (frontend, backend, etc.) with just one deployment file with a single command:
$ kubectl create -f single-config-file.yaml
kubectl is a command line program that interacts with the Kubernetes API. Now introduce some core concepts.
cluster
A cluster is a set of nodes, which can be physical servers or virtual machines, on which the Kubernetes platform is installed. The figure below shows such a cluster. Note that the figure is simplified to emphasize core concepts. A typical Kubernetes architecture diagram can be seen here .
You can see the following components in the above figure, using special icons to represent Service and Label:
- Under
- Container
- Label(
) (label) - Replication Controller
- Service(
) (service) - Node
- Kubernetes Master (Kubernetes master node)
Under
Pods (green boxes above) are arranged on nodes and contain a set of containers and volumes. Containers in the same Pod share the same network namespace and can communicate with each other using localhost. Pods are ephemeral, not persistent entities. You may have these questions:
- If Pods are ephemeral, how can I persist container data to survive restarts? Yes, Kubernetes supports the concept of volumes , so persistent volume types can be used.
- Do you manually create Pods? If you want to create multiple copies of the same container, do you need to create them one by one? You can manually create a single Pod, but you can also use the Replication Controller to create multiple copies using the Pod template, which is described in detail below.
- If the Pod is ephemeral, the IP address may change on restart, so how can I correctly and reliably point from the frontend container to the backend container? At this time, you can use Service, which will be described in detail below.
Lable
As shown, some Pods have Label( ). A Label is a key/value pair attached to a Pod to pass user-defined properties. For example, you might create a "tier" and "app" label, label the front-end Pod container with Label ( tier=frontend, app=myapp ), and label the back-end Pod with Label ( tier=backend, app=myapp ). Then you can use Selectors to select Pods with specific Labels and apply Service or Replication Controller to them.
Replication Controller
Do you manually create Pods? If you want to create multiple copies of the same container, do you need to create them one by one? Can you assign Pods to logical groups?
The Replication Controller ensures that a specified number of Pod "replicas" are running at any one time. If you create a Replication Controller for a Pod and specify 3 replicas, it will create 3 Pods and monitor them continuously. If a Pod does not respond, the Replication Controller replaces it, keeping the total at 3. As shown in the animation below:
If the previously unresponsive Pods come back, and there are now 4 Pods, the Replication Controller will terminate one of them to keep the total at 3. If the total number of replicas is changed to 5 during operation, the Replication Controller will immediately start 2 new Pods, guaranteeing a total of 5. Pods can also be scaled down this way, a feature useful when performing rolling upgrades . When creating a Replication Controller, you need to specify two things:
- Pod Templates : Templates used to create Pod replicas
- Label : The label of the Pod that the Replication Controller needs to monitor.
Now that some replicas of the Pod have been created, how to balance the load on these replicas? What we need is Service.
Service
If Pods are ephemeral, the IP address may change on restart, how can I correctly and reliably point from the frontend container to the backend container?
A Service is an abstraction that defines a set of Pods and policies for accessing those Pods . Service finds the Pod group by Label. Because Services are abstract, they are often not visible in diagrams, which makes the concept more difficult to understand. Now, suppose there are 2 backend Pods, and the backend Service is defined with the name 'backend-service' and the lable selector as ( tier=backend, app=myapp ). The Service of the backend-service will accomplish the following two important things:
- A DNS entry for the local cluster will be created for the Service, so the front-end Pod only needs to look up the hostname 'backend-service' in DNS to resolve the IP address available to the front-end application.
- Now the frontend has got the IP address of the backend service, but which of the 2 backend pods should it access? The Service provides transparent load balancing between these 2 background Pods and will distribute requests to either of them (as shown in the animation below). This is done through a proxy (kube-proxy) running on each Node. More technical details here .
下述动画展示了Service的功能。注意该图作了很多简化。如果不进入网络配置，那么达到透明的负载均衡目标所涉及的底层网络和路由相对先进。如果有兴趣，这里有更深入的介绍。
有一个特别类型的Kubernetes Service，称为'LoadBalancer'，作为外部负载均衡器使用，在一定数量的Pod之间均衡流量。比如，对于负载均衡Web流量很有用。
Node
节点（上图橘色方框）是物理或者虚拟机器，作为Kubernetes worker，通常称为Minion。每个节点都运行如下Kubernetes关键组件：
- Kubelet：是主节点代理。
- Kube-proxy：Service使用其将链接路由到Pod，如上文所述。
- Docker或Rocket：Kubernetes使用的容器技术来创建容器。
Kubernetes Master
集群拥有一个Kubernetes Master（紫色方框）。Kubernetes Master提供集群的独特视角，并且拥有一系列组件，比如Kubernetes API Server。API Server提供可以用来和集群交互的REST端点。master节点包括用来创建和复制Pod的Replication Controller。
下一步
Now that we have a basic understanding of the core concepts of Kubernetes, you can further read the Kubernetes User Manual . The user manual provides quick and complete learning documentation.
If you can't wait to try Kubernetes, you can use Google Container Engine . Google Container Engine is a managed Kubernetes container environment. After a simple registration/login, you can try the examples above. Link to original text
: Learn the Kubernetes Key Concepts in 10 Minutes Wen, currently working at IBM, senior software engineer, responsible for system testing of IBM WebSphere business process management software. Worked for VMware in the quality assurance of desktop virtualization products. Strong interest in virtualization, middleware technology, business process management.