Kubernets Learning Road (1)--Concept Summary

First, write in the top

In 16 began to hear the k8s, then dokcer very fire, at that time also studied a part, also known as Docker, follow-up no use scene, so did not continue in-depth study. As the architecture of microservices becomes more and more process, the k8s application scenario is more appropriate. The company recently prepared to use k8s to do micro-service architecture, and k8s technology has matured, many companies have been in the production of large-scale use, so intends to learn k8s. Today, through the official documents of k8s, found that the cost of learning is still relatively large, k8s components are more, belong to the heavyweight, and the official documents are not friendly, not good to find things. So, here to share the learning process, at the same time record the study notes, convenient for later review.

Second, the core concept introduction

1.master

K8s Cluster Management node, responsible for managing the cluster and providing access to the resource data of the cluster. With the ETCD Storage service (optional), run the API server process, the Controller Manager service process, and the scheduler service process, which associates the work node nodes. Kubernetes API Server provides a key service process for the HTTP rest interface, which is the only entry for all resources in the Kubernetes, such as add, delete, change, and check. is also the ingress process of cluster control; Kubernetes controller manager is the Automation control Center for all Kubernetes resource objects, and Kubernetes schedule is the process responsible for resource scheduling (pod scheduling).

Component:

• Kube-apiserver:apiserver is responsible for providing restful Kubernetes API service, it is the unified entrance of the System Management Directive, any operation that increases and deletions the resources should be handed over to apiserver processing and then submitted to ETCD.
• Kube-controller-manager: If Apiserver is doing "front desk" work, then controller manager is responsible for "backstage". Each resource generally has a controller, and controller manager is responsible for managing those controllers. For example, we create a pod through Apiserver, and when the pod is created, Apiserver's task is done. And the back of the pod to ensure that the status of the same as we expected the responsibility of the Controller manager to ensure that
• Kube-scheduler:scheduler's job is to be responsible for dispatching pods to the right node. If scheduler is seen as a black box, its input is a pod and a list of multiple node, and the output is a bundle of pods and a node that will deploy the pod to this node. Kubernetes currently provides a scheduling algorithm, but also retains the interface, users can define their own scheduling algorithm according to their own needs.

2.node

node is the service node that runs pods in the Kubernetes cluster architecture, which can be physical machines, virtual machines, cloud hosts, and so on. By default Kubelet will register himself with master, and once node is included in the cluster management, Kubelet will periodically report its own intelligence to master, including operating system, Docker version, machine resources, etc. If node does not escalate information over a specified time, it will be judged by master as "missing", marked as not ready, and then Master will trigger pod transfer.

Component:

• Kubelet: Responsible for the creation of pod-to-container, start-stop and other tasks
• Kube-proxy: An important component for implementing communication and load balancing mechanisms for kubernetes service
• Docker engine (Dockerdo): Docker engines, responsible for the creation and management of native containers

3.pod

Pod is the basic operating unit of Kubernetes, each pod has a root container (Pause container), the state of the pause container represents the state of the entire container group, other business containers share the pause IP, pod ip, shared pause mount volume, This simplifies network problems and file sharing issues between different containers in the same pod.

Characteristics:

1. Kubernetes cluster, the same host or different host pod requires TCP/IP to communicate directly, so the use of virtual two layer network technology, such as Flannel,openvswitch (OVS), so that in the same cluster, different host pod IP is the IP of different IP segments, all pod IPs in the cluster are unique and can communicate directly between different pods.
2. There are two types of pods: normal pod and static pod. The static pod is not dispatched and created by K8s and is started directly on a specific node machine via a specific file. The normal pod is created and dispatched by K8s, and the data is stored in the ETCD.
3. The Pod IP and the specific container port (containnerport) make up a specific communication address, the endpoint. There can be more than one container in a pod, there can be multiple ports, like the pod IP, there are multiple endpoint.
4. Pod volume is defined on the pod and is mounted to its own file system by various containers, and can be used to implement back-end storage functions with Distributed file systems.
5. Event events in the pod can be used to troubleshoot problems, and you can view the corresponding events by kubectl describe pod xxx.
6. Each pod can set a limit on the computing resources on the server it can use, typically CPU and memory. K8s typically 1 per thousand CPU configuration as the smallest unit, in M, is an absolute value, that is, 100m for a core machine or 48 core machine is the same size. The memory quota is also an absolute value, in bytes per byte.
7. Two parameters for a resource quota:

• Requests: The minimum number of requests for this resource, the system must meet the requirements.
• Limits: The maximum allowable usage of this resource, and when the amount is exceeded, k8s will kill and restart the pod.

4.Replication Controller

The Replication controller, called RC, is used to manage a copy of the pod, ensuring that a specified number of pod copies exist in the cluster. If the number of replicas in the cluster is greater than the specified number, the number of extra containers that are outside the specified number is stopped, and conversely, containers with fewer than a specified number are started and the quantity is guaranteed to be constant. Replication Controller is the core of elastic scaling, dynamic expansion and rolling upgrades.

5. Label

Any API object in Kubernetes is identified by a label, and the essence of the label is a series of Key/value key-value pairs, where key is specified by the user itself. Labels can be attached to various resource objects, such as node, Pod, Service, RC, and so on, a resource object can define any number of labels, and the same label can be added to any number of resource objects. The label is the basis for running the replication controller and service, and they are associated with the pod running on node with a label.

Characteristics:

1. A label is a key-value pair that can be attached to any object, such as NODE,POD,SERVICE,RC. Label and resource objects are many-to-many relationships where a label can be added to multiple objects, and an object can also define multiple labels.
2. The role of label is mainly used to achieve granular, multi-dimensional resource grouping management for resource allocation, scheduling, configuration, deployment and other tasks.
3. Label popular understanding is "tags", through the filter filter the specified object, to do the specific operation. K8s uses a label Selector (tag Selector) to filter the resource object for the specified label, similar to a conditional query (where statement) in an SQL statement.
4. The Label selector has two expressions based on equality and set-based representations that can be combined using multiple conditions:

• Based on the equation: Name=redis-slave (Match name=redis-slave resource object); Env!=product (matches all resource objects that do not have a label env=product)
• Based on the collection: name in (redis-slave,redis-master), name not in (Php-frontend) (matches all resource objects that do not have a label name=php-frontend)

Usage Scenarios

1. The Kube-controller process uses the label selector defined on the resource object RC to filter the number of pod copies to be monitored, so that the number of replicas remains the expected number.
2. The kube-proxy process selects the corresponding pod through the service's label selector, automatically establishes the request-forwarding routing table for each service to the corresponding pod, thus realizing the service's intelligent load balancing mechanism.
3. Kube-scheduler implements pod-directed scheduling: defines a specific label for node and uses the Nodeselector tag scheduling policy in the pod definition file.

6. Deployment

Deployment is a concept introduced by Kubernetes 1.2 to solve the problem of pod orchestration. It is a higher-level API object that manages replicasets and pods, and provides features such as declarative updates. The official recommendation is to use deployment to manage replicasets instead of using replicasets directly, which means that you may never need to manipulate replicaset objects directly.

It is characterized by the ability to always know the progress of pod deployment, that is, the creation of pods, scheduling, binding nodes, start the process of container completion of the progress display. By describing the cluster state you expect in Deployment, the Deployment controller will incrementally update the current cluster state to the desired cluster state at a controlled speed. Deployment's main duties are also to ensure the number and health of pods, and the 90% function is exactly the same as the replication controller, which can be seen as a new generation of replication controllers. However, it has new features outside of the replication controller:

　　　　Replication controller Full functionality : Deployment inherits the full functionality of the Replication controller described above.

　　　　Event and Status View : You can view the upgrade details progress and status for deployment.

　　　　 rollback: When a pod image or related parameter is upgraded, a rollback operation can be used to roll back to the previous stable version or to the specified version.

　　　　Release Notes : Each operation on the deployment can be saved and given subsequent possible rollback use.

　　　　pause and start : For each upgrade, you can pause and start at any time.

　　　　multiple upgrade Scenarios : Recreate----Delete all existing pods and recreate the new one; Rollingupdate----rolling upgrades, incrementally replacing policies, while rolling upgrades support additional parameters such as setting the maximum number of unavailable pods, minimum upgrade interval, and so on.

Usage Scenarios

1. Create a Deployment object to generate the corresponding replica set and complete the process of creating the pod copy.
2. Check the status of the deployment to confirm that the deployment action is complete (the number of pod replicas is up to the expected value).
3. Update deployment to create a new pod (for example, a mirrored upgrade scenario).
4. If the current deployment is unstable, fallback to the previous deployment version.
5. Suspends or restores a deployment.

7.Service

The service defines the logical set of pods and the policies that access the collection, which is an abstraction of the real service. The service provides a unified access portal for services, as well as service proxies and discovery mechanisms that correlate multiple pods of the same label, and users do not need to know how the background pod is running.

Characteristics:

• Service An application services abstraction that defines the pod logical collection and the policies that access the Pod collection.
• Service Agent Pod Collection external performance is for an access portal, assigning a cluster IP address, requests from this IP will load-balance forwarding containers in the backend pod.
• Service selects a set of pods via lable selector.

For an external system to access the service, you need to understand the three IPs in the configuration file:

• The IP address of node Ip:node nodes, Nodeip is the physical NIC IP address of each node in the cluster, is a physical network of real existence, kubernetes nodes outside the cluster to access a node in kubernetes or TCP/IP services, Communication via NODEIP is required.
• Pod ip:pod IP address, pod IP is the IP address of each pod, the Docker engine is allocated according to the IP segment address of the Docker0 Bridge, is a virtual two layer network, one pod container in the cluster accesses the container in another pod, is through pod IP, and the real TCP/IP traffic flows through the network card where node IP resides.
• Cluster IP:
  1. The service's cluster IP is a virtual IP (created by a virtual network) that acts only on the service object and is managed and assigned by the Kubernetes IP address (from the cluster IP address pool).
  2. The Cluster IP cannot be ping because there is no entity network object to respond to.
  3. Cluster IP with service port composed of specific communication end eloquence with the basis of TCP/IP communication, belonging to the Kubernetes cluster, outside the cluster access to the IP and port needs additional processing.
  4. The communication between node IP, Pod IP, Cluster IP in k8s cluster takes k8s own special routing rule, which is different from traditional IP routing.

Within the Kubernetes cluster, the communication between Node IP network, Pod IP and cluster IP network is based on a special routing rule designed by Kubernetes himself. 8.Namespace

Namespaces assign objects to different namespace logically, can be different projects, users, and other differentiated management, and set control policies, so as to achieve multi-tenancy. Namespaces are also known as virtual clusters.

9, Volume

In the design implementation of Docker, the data in the container is temporary, that is, when the container is destroyed, the data is lost. If you need to persist data, you need to use a Docker data volume to mount the files or directories on the host to the container. In Kubernetes, when the pod is rebuilt, the data is lost, and kubernetes is also mounted on the data volume to provide the persistence of the pod data. Kubernetes data volumes are extensions to Docker data volumes, and kubernetes data volumes are pod-level and can be used to implement file sharing for containers in pods. Currently, the types of data volumes supported by Kubernetes are as follows:

1) Emptydir

2) Hostpath

3) GCE Persistent Disk

4) AWS Elastic Block Store

5) NFS

6) ISCSI

7) Flocker

8) GlusterFS

9) RBD

Ten) Git Repo

One) Secret

Persistent Volume Claim

) Downward API

Local data volumes

Emptydir, Hostpath These two types of data volumes, can only be used for the local file system. The data in the local data volume will only exist on one machine, so the data will be lost when the pod is migrated. The purpose of this type of volume is: File sharing between containers in pod, file system for shared host.

Emptydir

If the pod is configured with a Empydir data volume, it will exist during the pod's lifetime, and when the pod is assigned to node, the Emptydir data volume will be created on node and mounted in the pod container. As long as the pod exists, the Empydir data volume will exist (the container delete will not cause the Empydir data volume to lose data), but if the pod is terminated (pod is deleted), the Empydir data volume will be deleted and permanently lost.

Empydir data volumes are ideal for file sharing of containers in pods. Pod design provides a good container combination of the model, the container between the roles, through the shared file directory to complete the interaction, such as through a full-time log collection container, in each pod and business container combination, to complete the log collection and summary.

Hostpath

The Hostpath data volume allows the file system on the container host to be mounted to the pod. If the pod needs to use some files on the host, you can use Hostpath.

Network data volumes

Kubernetes provides a number of types of data volumes to integrate with third-party storage systems, including some very popular distributed file systems, as well as storage support provided on the IaaS platform, which are distributed across the network and share file systems, so we call this type of data volume a network data volume.

Network data volumes can meet the persistent demand of data, pod is configured to use network data volumes, each time the pod is created, the remote file directory of the storage system is attached to the container, the data in the data volume will be saved for a long time, even if the pod is deleted, just remove the mounted data volume. The data in the data volume is still stored on the storage system, and the same data volume is still mounted when the new pod is created. Network data volumes include the following: NFS, Iscisi, GlusterFS, RBD (Ceph block Device), Flocker, AWS Elastic Block Store, GCE persistent Disk

Persistent Volume and persistent Volume Claim

Understanding each storage system is a complex matter, especially for ordinary users, and sometimes there is no need to care about a variety of storage implementations, only to be able to store data securely and reliably. Kubernetes provides the persistent Volume and persistent Volume claim mechanism, which is the storage consumption mode. Persistent volume is a data volume created by the system administrator configuration (currently supports Hostpath, GCE persistent Disk, AWS Elastic Block Store, NFS, ISCSI, GlusterFS, RBD) , it represents a kind of storage plug-in implementation, and for ordinary users, through the persistent Volume claim can request and obtain the appropriate persistent Volume, without the need to perceive the backend storage implementation. Persistent Volume and persistent Volume claim are in fact similar to pod and node,pod consumption node resources, persistent Volume claim consume persistent Volume resources. Persistent Volume and persistent Volume claim are interrelated and have a complete life cycle management:

1) Prepare: The system administrator plans or creates a batch of persistent Volume;

2) Binding: When a user declares a storage request by creating a persistent Volume claim, Kubernetes discovers a storage request, it finds the persistent Volume (minimum satisfying policy) that meets the criteria. Find the right binding on, can not find it has been in a waiting state;

3) Use: When creating pod, use persistent Volume Claim;

4) Release: When the user deletes the persistent Volume claim bound on persistent Volume, persistent Volume enters the release state, where persistent Volume remains in the previous Persis Tent Volume claim data, the status is not available;

5) Recovery: Whether the persistent volume need to be recycled to use again. The recycle policy can be manual or kubernetes automatically (NFS and Hostpath only)

Information data volumes

There are some data volumes in kubernetes that are used to convey configuration information to the container, which we call the information data volume, such as secret (handling sensitive configuration information, passwords, tokens, etc.), downward API (which tells the container pod via environment variables), Git Repo (Download the Git repository into the pod) is to save the pod information as a file and then mount it to the container as a data volume, and the container can read the file to get the appropriate information.

Continuous update ....

Kubernets Learning Road (1)--Concept Summary