K8s series (I) – Knowledge graph

An overview of the

Kubernetes(K8s), as the most well-known container choreography tool at present, is called the “operating system” in the Cloud Native era. It is necessary skills for research and development, operation and maintenance, and products to be familiar with and use it. This article summarizes the K8s knowledge graph from the development history, installation and operation, resources, storage, network, security, management, future prospects and other aspects of about 680 knowledge points, aiming to help you better understand the K8s related knowledge, for business, operation and maintenance, innovation to lay a solid foundation.

The full version links: www.processon.com/view/link/6…

Noun shorthand

PV: Persistent Volume

PVC: Persistent Volume Claim SA: Service Account HA: High Available HPA: Horizontal Pod Autoscaler VPA: Vertical Pod Autoscaler PSP: Pod Security Policy PDB: Pod Disruption Budget CRD: Custom Resource Definition CSI: Container Storage Interface CNI: Container Network Interface CRI: Container Runtime Interface OCI: Open Container Initiative CNCF: Cloud Native Computing Foundation

1. Development historyHistory

As Docker gained a foothold in container technology, it challenged the interests of other players on multiple occasions, including Google, RedHat, CoreOS, Microsoft, and others. In the early days of the Docker project, Google made an open source production verification Container lMCTFY (Let Me Container That For You). But Docker’s rise is overwhelming. Docker has absolute authority and discourse power in the container world. Google overpaid Docker, and Docker’s tech boss and co-founder Solomon Hykes, also an idealist, ignored the offer.

Frustrated, Google launched a Cloud Native Computing Foundation (CNCF) with other open source infrastructure players such as RedHat and CoreOS.

Borg is Google’s most core and low-level technology, hosted by the CNCF Foundation, also known as Kubernetes.

In October 2017, Docker unexpectedly announced that it would build Kubernetes into its flagship Docker Enterprise edition, marking the end of a nearly two-year “scheduling war”.

Twitter stopped using Apache Mesos after May 2019 and Aliyun stopped supporting Docker Swarm after July 2019.

Kubernetes democratizes the architecture throughout the community: at every level from API to container runtime, the Kubernetes project exposes extensible plug-in mechanisms for developers, encouraging users to code into every phase of the Kubernetes project. In this overall atmosphere of encouraging secondary innovation, the Kubernetes community has experienced unprecedented development since 2016. More importantly, unlike the previous paas-oriented route of “package and release”, this time the container community is flourishing with the “contention of a hundred schools of thought” completely centered on Kubernetes project.

2. The architectureArchitecture

Kubernetes follows a very traditional client/server architecture. Clients can communicate with Kubectl through RESTful interfaces or directly using kubectl to cluster with Kubernetes. There is not much difference between the two. The latter simply encapsulates and provides the RESTful apis provided by Kubernetes. Each Kubernetes cluster is composed of a group of Master nodes and a series of Worker nodes. The Master node is mainly responsible for the state of the storage cluster and the allocation and scheduling of resources for Kubernetes objects.

Master (Control Plane)

As the Master node that manages the state of the cluster, it is responsible for receiving client requests, scheduling the execution of the container, and running the control loop to migrate the state of the cluster to the target state. The Master node consists of the following four components:

kube-apiserver: It is responsible for processing requests from clients (Client-go, Kubectl). Its main function is to provide RESTful interfaces externally, including read requests for viewing cluster status and write requests for changing cluster status. It is also the only component that communicates with etCD cluster.

Etcd: is a key value database with both consistency and high availability, can be used as a backend database to store all Kubernetes cluster data.

Kube-scheduler: Component on the master node that monitors newly created PODS that do not specify running nodes and selects nodes for pods to run on. Scheduling decisions consider resource requirements for individual pods and Pod collections, hardware/software/policy constraints, affinity and anti-affinity specifications, data location, interference between workloads, and deadlines.

Kube-controller-manager: Components that run controllers on the master node. Logically, each controller is a separate process, but to reduce complexity, they are all compiled into the same executable and run in a single process. The tuning process of the corresponding controllers is triggered by the list-Watch event event, which includes: Node Controller, Replication Controller, Endpoint Controller, ServiceAccount/Token Controller, etc.

Node (Worker)

Kubelet: agent of the working node, responsible for specific container life cycle management, container management according to the information obtained from ETCD, and report pod running status, etc.

Kube-proxy: kube-proxy is a simple network access proxy and also a Load Balancer. It is responsible for assigning requests for access to a service specifically to pods of the same class of labels on the work node. Kube-proxy essentially implements Pod mapping by manipulating firewall rules (iptables or IPVS).

Container-runtime: Kubernetes supports multiple container runtime environments: Docker, Containerd, Cri-O, RKtlet, and any implementation Kubernetes CRI(Container runtime Interface).

3. Install and runInstall & Run

K8s installation can be done by manually downloading binary packages (github.com/kubernetes/…) You can also install the cluster environment using a third-party tool package. The latter is recommended.

Currently commonly used third-party tools are Minikube, Kubeadm, Kind, K3S.

Minikube is suitable for lightweight, single-node local cluster environment construction, beginners can choose; Kubeadm is suitable for building a complete K8s master/ Node multi-node cluster environment. Kind is characterized by deploying K8s into Docker containers. K3S is suitable for building a cluster environment on lightweight, IoT and other miniature devices.

4. The resourcesResources

In K8s, resource objects can be categorized into two types: Workloads and Controllers.

Workloads include: Pod, Deployment, StatefulSet, Service, ConfigMap, Secret, DaemonSet, Job/CronJob, HPA, Namespace, PV/PVC, Node, etc. Resources are classified according to requirements and features.

Controllers mainly include: Node Controller, Replication Controller, Namespace Controller, ServiceAccount Controller, Service Controller, Endpoint Controller, etc., mainly Reconcile the Actual values of various types of resources to the expected values in the automatic control of resources.

All the resources to GET through the REST API calls kube – apiserver/POST/PATCH/REPLACE/DELETE resources control (add and DELETE), need to satisfy the interface of authentication, authorization and access control. The kubectl command is an official client-side command line tool that encapsulates the REST API call kube-apiserver. All resources are persisted to etCD backend storage through Kube-Apiserver. Therefore, in production practice, high availability deployment of Kube-Apiserver and ETCD should be ensured to prevent single point of failure.

5. StorageStorage

Data generated by containers in pods needs to be stored persistently, especially for StatefulSet services, which can be stored locally or over the network via PV/PVC so that Container applications can still use the previous data after reconstruction. If persistent storage is not required, you can use ephemeral-Volume (emptyDir) temporary storage volumes where the data is cleared over the life of the Pod.

PersistentVolume (PV) is an abstraction of the underlying shared storage, which is defined as a resource. The PV is manually created or dynamically provided by the administrator and interconnects with the Container Storage Interface (CSI) through a plug-in mechanism. For example, GlusterFS, iSCSI, GCE, and AWS public cloud.

A PVC(PersistentVolumeClaim) makes a claim on a storage resource. Just as a Pod consumes a Node resource, a PVC consumes a PV and both need to be in the same namespace. A Bound can be completed only when a specific SC(StorageClass) or Label Selector is matched. You can set a policy to automatically delete the PV resources bound to a PVC when it is deleted, and reclaim storage resources in a timely manner.

6. The networkNetwork

A basic principle of K8s network model design is that each Pod has an independent IP address, namely ip-per-POD model, and it assumes that all PODS are in a flat network space that can be directly connected. So regardless of whether containers are running in the same Node or not, they are required to be directly accessible via each other’s IP.

In fact, IP in K8s is allocated in Pod units, and a container within a Pod shares a network protocol stack. However, Docker’s native port mapping access mode will introduce the complexity of port management, and the IP address and port seen by visitors are different from the actual binding of service providers. Because NAT will change the source/target address, it is difficult for the service itself to know the real IP address and port exposed to the outside.

Therefore, K8s has the following requirements on the cluster network:

• All containers can communicate with other containers without NAT.
• All nodes can communicate with all containers without NAT.
• The IP of the container is the same as the IP seen by the visitor;

K8s abstracts a set of container applications with the same functionality into services and provides a uniform access address. You can use ClusterIP, NodePort, and LoadBalancer to communicate with each other in a cluster. Network policies such as Ingress and Egress are used to control the access traffic to and from containers.

7. The schedulingScheduler

The Kube-Scheduler (KuBE-scheduler) plays an important role in K8s cluster as a “link”. “link” means that it receives the Pod created by Controller Manager and selects an appropriate Node for it. “Boot down” means that the Kubelet server process on the selected Node takes over for the “second half” of the Pod lifecycle.

The default scheduling flow provided by K8s is divided into the following two steps:

• The pre-selection scheduling process: the candidate nodes meeting the requirements are screened out by multiple Predicates.
• Determine the optimal Node: On the basis of the first step, XXX Priority strategy is adopted to calculate the score of each candidate Node, and the one with the highest score will be selected as the target Node.

In addition, the Pod can be set by Affinity or anti-affinity, which indicates that the Pod is deployed to the relevant Node set in a preferred or mandatory manner. Taint/Tolerations, in contrast, allows Node to resist the deployment of certain pods. Taint works with Tolerations to ensure that pods aren’t scheduled to inappropriate nodes. A single Node can apply multiple taints, and Node does not accept Pod scheduling that does not tolerate taints. Tolerations are attributes of pods that allow (but are not mandatory) pods to be scheduled to nodes that match Taint.

Tips: Taint is a Node attribute and Affinity is a Pod attribute.

Safe 8.Security

K8s implements cluster security Control through a series of mechanisms, including Authentication, Authorization, Admission Control, Secret, and Service Account. All resources in K8s are accessed and changed through the REST API of K8s API Server. Therefore, three methods are used in Authentication Authentication:

• HTTPS: CA + SSL
• HTTP Token
• HTTP Base

Authorization modes include: Attribute-based Access Control (ABAC), role-based Access Control (RABC) and Webhook, among which RBAC is widely used in production practice. Role-based control includes Role, RoleBinding, and ClusterRoleBinding. The former two control resources in a namespace, while the latter two control resources at the cluster level or in a specified namespace.

After passing the authentication and authorization levels, an Admission Control chain of resources, PODS, and other add-ons is required for verification. A successful API Server response is achieved only after all the chains of Control have been opened.

K8s component Kubectl, Kubelet uses Service Account (SA) named default for secure communication with API Server by mounting Secret named Token to container directory. Access with the corresponding Token for security authentication.

In addition, K8s provides the PSP(PodSecurityPolicy) mechanism to control Pod/Container security policies with finer granularity. It includes control of host, user, group, privilege, and Linux Capabilities. A securityContext in a Pod/Container can be created only if it matches the corresponding policy.

9. ExtensionExtensions

With the development of K8s, the resource objects such as Pod, RC, Service, Deployment and ConfigMap built into the system can no longer meet the diversified business, operation and maintenance requirements of users, so it is necessary to expand the API. K8s currently provides two mechanisms to extend the API:

• CRD extension: reuse K8s API Server, need to provide CRD Controller;
• API Aggregation Layer: Users are required to write additional API servers for finer grained control of resources;

In fact, API Aggregation mainly uses Kube-proxy to request resources from different paths and then forwards them to a user-defined API Service handler for processing.

In addition, K8s adopts the plug-in mechanism of out-of-tree mode to support the extension of infrastructure components without affecting the trunk branch code, including: CSI, CNI, CRI, Device Plugins, etc., abstract out the underlying interfaces in the way of plug-ins. Users only need to implement specific interfaces to connect their infrastructure capabilities to K8s.

Management of 10.Management

K8s provides a cluster management mechanism with different dimensions, Including Node blocking (Cordon), uncordon (drain), PDB active expulsion protection, resource usage control (Requests /limits), Metrics Server monitoring collection, Log, Audit Audit, etc. Cluster administrators can also use the aforementioned Affinity, Taints/Tolerations, Label, Annotation, and other mechanisms to address cluster diversity management needs.

In addition, high availability (HA) deployment should be considered for cluster operation. Multiple copies of HIGH availability (HA) deployment can be adopted from etCD, Master component, and BIZ container to ensure stable cluster operation.

11. The toolTools

K8s provides the client tool Kubectl for users to use, this tool almost integrated with all the API Server can process, the specific use of the common commands listed in the figure, all commands refer to the official documentation.

For complex business types, the Kustomize toolkit is recommended for flexible handling of YAML files. Kustomize is installed by default in the kubectl command in older versions of K8s and does not need to be installed separately.

In addition, K8s officially recommends using Helm, a package management tool, to achieve rapid CI/CD deployment, rollback and grayscale release by packaging applications with different versions, environments and dependencies as Chart.

12. Future outlookOngoing & Future

The API, resources, fields and tools involved in this article may have been Deprecated due to the rapid development of the K8s project. Please refer to the latest official version.

At present, Kubernetes has been fully involved in the Internet, AI, blockchain, financial and other industries, it can be expected that in the future there will be more and more industries began to use Kubernetes, and the industry practice will be more in-depth.

At present, K8s community supports Windows Container, GPU, VPA vertical expansion, Cluster Federation combined with multiple clusters, edge computing, machine learning, Internet of Things and other aspects of development, promoting the implementation of more cloud native products. Maximize the power and value of the cloud.

PS: Please pay attention to the public account “Straw Life” for more articles.

The resources

1. Kubernetes official documentation
2. Kubernetes Definitive Guide: From Docker to Kubernetes Practice in Full touch (4th edition)
3. www.padok.fr/en/blog/min…
4. Segmentfault.com/a/119000003…
5. www.cnblogs.com/lioa/p/1262…
6. Blog.csdn.net/dkfajsldfsd…