After a systematic overview of how to actually deploy a K8S project, we conclude this series by looking at an overview of the Kubernetes cluster and summarizing some of the deeper features.

Docker container complete course

Kubernetes overview

Below is an overview of the k8S structureAs you can see, some of these functional modules are not present in this article:

l ConfigMap

Used to store user profile definitions through Volume projection technology, which is also a way to mount volumes. This approach not only enables the application to be reused, but also enables more flexible functionality through different configurations. When creating containers, users can package applications as container images and configure injection through environment variables or external mount files.

l Secret

The Secret object type is used to hold sensitive information, such as passwords, OAuth tokens, and SSH keys. Putting this information in Secret is more secure and flexible than putting it in Pod definitions, container images, and ConfigMap. Secret is a standard K8S resource object that is used in much the same way as ConfigMap. At the same time, we can control the access to Secret to prevent confidential data from being accessed

l PV

PVC is the implementation method of persistent data volume in Kubernetes. It is the core function of StatefulSet and the necessary means of Pod persistence. Kubernetes decouples function points through PV and PVC.

In addition to the content mentioned in this article, the Content of the Kubernetes cluster is far more complex than we have seen so far, and there is much more to explore.

Here, we do a summary of these deep functions, but also a deep study of Kubernetes combing.

Kubernetes components

The server (host) we usually use in the development process is called Node Node in Kubernetes cluster.

At the same time in Kubernetes there is one or more Master nodes control multiple host computer cluster, the whole Kubernetes core scheduling function is basically on the Master node.

The main functionality of Kubernetes consists of five major components:

  1. Kubelet: installed on the Node to control the container in the Node to complete the Kubernetes scheduling logic
  2. ControllerManager: The core management component of the controller pattern we talked about above, managing the controller logic in all Kubernetes clusters
  3. API Server: The service handles the API requests in the cluster. The kubectl we’ve been writing is actually the requests sent to the API Server, which will be processed and forwarded internally
  4. Scheduler: Responsible for Kubernetes service scheduling. For example, the controller only controls the scheduling of pods. The final scheduling logic is done by the Scheduler and sends requests to Kubelet for execution
  5. Etcd: Kubernetes is a distributed database storage project developed by CoreOS and eventually acquired by RedHat as part of Kubernetes. It stores all the configuration information in the Kubernetes cluster, such as the name, IP, secret, configMap, etc. It relies on its own consistency algorithm to ensure fast and stable return of various configuration information in the system, so this is a core component of Kubernetes and Heart

Customization function

In addition to a variety of powerful component capabilities, Kubernetes also provides users with a great deal of freedom.

To achieve this high degree of freedom, Kubernetes provides users with three public interfaces:

L Container Networking Interface (CNI) : defines the connection mode of all the networks in Kubernetes cluster. The entire network is implemented through this Interface. As long as it implements this interface plug-ins, all the features of the network can be as Kubernetes cluster network configuration of the plugin, its internal include hosting routing table configuration, 7 layer network, packet forwarding, and so on have a wide variety of widgets, these widgets can also optional, users can according to your requirements free customization of these features

L CSI (Container Storage Interface) defines some specifications for cluster persistence. As long as the Storage function of this Interface is implemented, CRI (Container Runtime Interface) : In the Kubernetes container runtime, such as the default Docker configuration in the cluster container runtime, users are free to choose any other container projects that implement this interface, such as the previously mentioned Containerd and RKT

Here’s an interesting point: CRI.

The default container of Kubernetes is Docker, but due to the competition in the early stage of the project, Docker actually does not meet the CRI specification defined by Kubernetes. What should I do then?

In order to solve this problem, Kubernetes wrote a component called DockerShim for Docker, namely Docker shim, which is used to convert the CRI request specification into the OCI specification for Docker to operate Linux (yes, that is the OCI foundation specification mentioned in part 2). However, this feature is always maintained by the Kubernetes project. Whenever Docker releases a new feature, Kubernetes will maintain the DockerShim component.

Therefore, the recent news that Kubernetes will remove the DockerShim component in next year’s v1.20 means that from next year’s new version, Kubernetes will no longer support the update of Docker containers.

But it probably doesn’t matter to us normal developers, and the worst that can happen is that we need to switch from Docker to another container image supported by Kubernetes.

However, according to the information released by each cloud platform during this period, these platforms will provide corresponding conversion measures. For example, we still provide Docker images, and the platform will convert these images into other images when releasing operation and maintenance. Or these platforms will maintain a DockerShim to support Docker, there are solutions.

In this section, we take a look at Kubernetes’ architecture diagram:Through a series of learning, as an ordinary programmer, have to praise Google to encode it deep and far, the framework of because of too much only because of decoupling of components, and also provides such a large degree of freedom, had to say we type, the development team encountered in the learning process of a technical framework of depth.

But there is a downside to this excessive freedom.

In the deployment process, the complexity of Kubernetes cluster is very high, the deployment of a Kubernetes framework to meet the needs of the production environment is more difficult, online there are specialized Kubernetes production environment cluster deployment script, visible Kubernetes system is huge.

In the process of learning, kinD or Minikube can be used to simulate a Kubernetes cluster locally in the form of Docker, but there is still a gap between this level of learning and the production environment.

conclusion

This series of articles, a detailed description of our movable type grid development team in the process of heaven encountered several difficult to chew immortal.

From the development of cloud platform to the specific use of K8S, I explained the transition and evolution of a cloud platform step by step, from the initial virtual machine, to the prototype of PaaS, to Docker containerization, and finally to Kubernetes.

People’s memory is dependent on the precursor nodes, just through an article to Kubernetes involved in those technical points and a variety of difficult to remember the terms clearly explained clearly is obviously impossible, our idea is to let everyone understand the evolution process of the whole cloud ecology step by step, so as to finally understand the whole project.