Getting started with Kubernetes (K8s)

1. What is Kubernetes

What is Kubernetes?

        First of all, it is a brand-new leading solution for distributed architecture based on container technology. Although this solution is still very new, it is an important result of Google's experience in large-scale application of container technology for more than ten years. To be precise, Kubernetes is an open source version of Borg, Google's secret weapon that has been kept secret for more than ten years. Borg is a well-known large-scale cluster management system used internally by Google. It is based on container technology and aims to automate resource management and maximize resource utilization across multiple data centers. For more than ten years, Google has been managing a large number of application clusters through the Borg system. Since Google employees have signed a non-disclosure agreement, even if they leave the company, they cannot disclose the internal design of Borg, so the outside world has been unable to learn more about it. It was not until April 2015, when the long-rumored Borg paper was made public by Google for the first time along with the high-profile publicity of Kubernetes, that everyone was able to learn more about it. It is precisely because of standing on the shoulders of Borg, the predecessor, and absorbing Borg's experience and lessons in the past ten years, that Kubermetes became a blockbuster as soon as it was open sourced, and quickly dominated the field of container technology.

        Secondly, if our system design follows the design philosophy of Kubermetes, then the underlying code or functional modules in the traditional system architecture that have little to do with the business can immediately disappear from our sight, and we don’t have to worry about load balancers anymore It is no longer necessary to consider the introduction or development of a complex service governance framework, and it is no longer necessary to worry about the development of service monitoring and fault handling modules. In short, using the solution provided by Kubernetes, we not only save no less than 30% of the development cost, but also can focus more on the business itself, and because Kubernetes provides a powerful automation mechanism, the difficulty of later-stage operation and maintenance of the system and Operation and maintenance costs are greatly reduced.

        Then, Kubernetes is - an open development platform. Unlike J2EE, it is not limited to any language and does not define any programming interface, so services written in Java, Go, C++ or Python can be mapped to Kubernetes Services without difficulty, and passed the standard The TCP communication protocol to interact. In addition, since the Kubernetes platform is not intrusive to existing programming languages, programming frameworks, and middleware, existing systems can be easily upgraded and migrated to the Kubernetes platform.

        Finally, Kubernetes is a complete distributed system support platform. Kubermetes has complete cluster management capabilities, including multi-level security protection and access mechanisms, multi-tenant application support capabilities, transparent service registration and service discovery mechanisms, built-in intelligent load balancers, powerful fault discovery and self-healing capabilities, Service rolling upgrade and online expansion capabilities, scalable resource automatic scheduling mechanism, and multi-granularity resource quota management capabilities. At the same time, Kubernetes provides comprehensive management tools that cover all aspects including development, deployment testing, and operation and maintenance monitoring. Therefore, Kubernetes is a brand-new distributed architecture solution based on container technology, and it is a one-stop complete distributed system development and support platform.

        We must first learn some basic knowledge of Kubernetes, so that we can understand the solutions provided by Kubernetes.

        In Kubernetes, Service (service) is the core of the distributed cluster architecture, and a Service object has the following key characteristics.

• Have a uniquely assigned name (such as mysql-server).
• Have a virtual IP (Cluster IP, Service IP or VIP) and port number.
• Able to provide some kind of remote service capability.
• It is mapped to a set of container applications that provide this service capability.

        The service process of Service currently provides external services based on Socket communication, such as Redis, Memcache, MySQL, Web Server, or a specific TCP Server process that implements a specific business. Although a Service is usually provided by multiple related service processes, and each service process has an independent Endpoint (IP+Port) access point, Kubernetes allows us to connect to it through Service (virtual Cluster IP +Service Port) On the specified Service. With the built-in transparent load balancing and fault recovery mechanism of Kubernetes, no matter how many service processes there are in the backend, or whether a service process will be re-deployed to other machines due to a failure, it will not affect our normal service. transfer. More importantly, once the Service itself is created, it will not change, which means that in the Kubernetes cluster, we no longer have to worry about the problem of changing the IP address of the service.

        The container provides a powerful isolation function, so it is necessary to put the group of processes that provide services for the Service into the container for isolation. To this end, Kubernetes has designed a Pod object, packaging each service process into the corresponding Pod, making it a container (Container) running in the Pod. In order to establish the relationship between the Service and the Pod, Kubernetes first attaches a label (Label) to each Pod, labels the Pod running MySQL with name=mysql, and the Pod running PHP with the label name=php, and then gives The corresponding Service defines a label selector (Label Selector). For example, the selection condition of the label selector of MySQLService is name--mysql, which means that the Service will act on all Pods containing name=mysqlLabel. In this way, the association problem between Service and Pod is cleverly solved.

        Speaking of Pod, let's briefly introduce its concept here. First of all, Pod runs in an environment we call a node (Node). This node can be a physical machine, or a virtual machine in a private cloud or a public cloud. Usually hundreds of Pods run on one node. ;Secondly, each Pod runs a special container called Pause, and other containers are business containers. These business containers share the network stack and Volume mount volume of the Pause container, so the communication and data between them Swapping is more efficient, and we can make full use of this feature at design time to put a group of closely related service processes into the same Pod: Finally, it should be noted that not every Pod and the containers running in it can "Mapping" to a Service. Only a set of Pods that provide services (whether internal or external) will be "mapped" into a service.

        In terms of cluster management, Kubernetes divides the machines in the cluster into a Master node and a group of working nodes (Nodes). Among them, a group of processes related to cluster management, kube-apiserver, kube-controller-manager and kube scheduler, are running on the Master node. These processes realize resource management, Pod scheduling, elastic scaling, security control, system monitoring and Error correction and other management functions are fully automatic. As a working node in the cluster, Node runs real applications, and the smallest operating unit managed by Kubernetes on Node. is Pod. The kubelet and kube-proxy service processes of Kubernetes are running on Node. These service processes are responsible for the creation, startup, monitoring, restart, and destruction of Pods, as well as the implementation of load balancers in software mode.

        Finally, let's take a look at the two problems of service expansion and service upgrade in traditional IT systems, and the new solutions provided by Kubernetes. Service expansion involves resource allocation (which node to choose for expansion), instance deployment and startup, etc. In a complex business system, these two problems are basically completed by manual step-by-step operations, which is time-consuming and difficult to guarantee. quality.

        In a Kubernetes cluster, you only need to create a ReplicationController (RC for short) for the Pod associated with the Service that needs to be expanded, and then the expansion of the Service and subsequent Service upgrades and other headaches will be easily solved. Include the following 3 key pieces of information in an RC definition file.

• The definition of the target Pod.
• The number of replicas (Replicas) that the target Pod needs to run.
• The label (Label) of the target Pod to monitor.

        After the RC is created (the system will automatically create the Pod), Kubernetes will filter out the corresponding Pod instances through the Label defined in the RC and monitor their status and number in real time. If the number of instances is less than the defined number of replicas (Replicas), then A new Pod will be created according to the Pod template defined in RC, and then the Pod will be scheduled to start running on the appropriate Node. Until the number of Pod instances reaches the predetermined target. This process is completely automated and requires no human intervention. With RC, the expansion of the service becomes a purely simple numbers game, as long as the number of replicas in the RC is modified. Subsequent Service upgrades will also be done automatically by modifying the RC.

2. Why use Kubernetes

        There are many reasons to use Kubernetes, the most fundamental reason is: IT has always been an industry driven by new technologies. Docker, an emerging containerization technology, has been adopted by many companies. It has become inevitable to move from a single machine to a cluster, and the vigorous development of cloud computing is accelerating this process. Kubernetes is currently the only Docker distributed system solution that is widely recognized and optimistic by the industry. It is foreseeable that in the next few years, a large number of new systems will choose it, no matter whether these systems are running on the local server of the enterprise or hosted on a public server. on the cloud.

        What are the benefits of using Kubernetes?

        First of all, the most direct feeling is that we can develop complex systems "lightly". In the past, more than a dozen people were needed at every turn, and many technical experts in the team needed to work together to design, implement, and operate a distributed system. After adopting the Kubernetes solution, only a small and capable team can easily handle it. In this team, an architect focuses on the refinement of "service components" in the system, several development engineers focus on the development of business code, and a system and operation and maintenance engineer is responsible for the deployment and operation and maintenance of Kubermnetes. "996", this is not because we have done less, but because Kubernetes has already done a lot for us.

        Second, using Kubernetes is embracing the microservice architecture in an all-round way. The core of the microservice architecture is to decompose a huge monolithic application into many small interconnected microservices. A microservice may be supported by multiple instance copies, and the number of copies may change as the system load changes. Tuning, the embedded load balancer plays an important role here. The microservice architecture allows each service to be developed by a dedicated development team, and developers can freely choose development technologies, which is valuable for large-scale teams. In addition, each microservice is developed, upgraded, and expanded independently, so the system It has high stability and rapid iterative evolution capabilities. Many large Internet companies such as Google, Amazon, eBay, and NetFlix have adopted the microservice architecture. This time, Google has directly packaged the infrastructure of the microservice architecture into the Kubernetes solution, giving us the opportunity to directly apply the microservice architecture to solve complex problems. Architectural issues of business systems.

        Then, our system can be "relocated" to the public cloud as a whole anytime and anywhere. The initial goal of Kubernetes is to run on Google's own public cloud GCE, and it will support more public clouds and OpenStack-based private clouds in the future. At the same time, in the Kubernetes architecture solution, the details of the underlying network are completely shielded, and the service-based Cluster IP can seamlessly migrate the system from the physical machine environment to the public cloud without even requiring us to change the runtime configuration file. Or put the Pod copies corresponding to some services in the public cloud during the service peak period to improve the throughput of the system, which not only saves the company's hardware investment, but also greatly improves the customer experience. The 12306 ticketing system of the Ministry of Railways that we are familiar with rented Alibaba Cloud for distribution during the peak period of the Spring Festival.

        Finally, the Kubernetes system architecture has a super horizontal expansion capability. For Internet companies, the scale of users is equivalent to assets. Whoever has more users will win the competition. Therefore, super horizontal expansion capability is one of the key indicators of Internet business systems. Without modifying the code, a Kubernetes cluster can be smoothly expanded from a small cluster containing only a few Nodes to a large-scale cluster with hundreds of Nodes. We can even complete cluster expansion online by using the tools provided by Kubernetes. As long as our microservices are well designed, combined with the linear increase of hardware or public cloud resources, the system can withstand the enormous pressure brought by concurrent access by a large number of users.

3. Kubernetes architecture diagram

        The Kubernetes system is used to manage microservices or containerized applications in distributed node clusters, and it provides zero-downtime deployment, automatic rollback, scaling, and self-healing of containers (including automatic configuration, automatic restart, and automatic replication. Highly elastic infrastructure, and automatic scaling of containers, etc.) and other functions.

        One of the most important design factors of a Kubernetes system is the ability to scale out, that is, adjust the number of replicas of an application to improve availability. Designing a large-scale system and ensuring its runtime is robust, scalable, portable and very challenging, especially when the complexity of the system increases, the architecture of the system will directly affect its operation mode, dependence on the environment and The degree of coupling of related components.

        Microservices are a software design pattern for scalable deployment on clusters. Using this pattern, developers can create small, composable applications that communicate through well-defined HTTP REST API interfaces. Kubernetes is also a program that follows the microservice architecture model. It has elasticity, observability and management functions, and can adapt to the needs of cloud platforms.

        The system architecture design of Kubernetes is very similar to the system architecture design concept of Borg, such as Scheduler scheduler, Pod resource object management, etc. Figure 1-1 shows the general architecture of Kubernetes.

        The Kubernetes system architecture follows the client/server (C/S) architecture. The system architecture is divided into two parts, Master and Node, with Master as the server and Node as the client. The Kubernetes system has multiple Master servers, which can achieve high availability. By default, a Master server can do all the work.

        The Master server is also called the master control node, and it is mainly responsible for the following tasks in the cluster.

• (1) The "brain" of the cluster is responsible for managing all nodes (Node).
• (2) Responsible for scheduling which nodes the Pod will run on.
• (3) Responsible for controlling all states during cluster operation.

        The Node client is also called a working node, and it is mainly responsible for the following tasks in the cluster.

• (1) Responsible for managing all containers (Container).
• (2) Responsible for monitoring/reporting the running status of all Pods.

        The Master server (master control node) is mainly responsible for managing and controlling the entire Kubernetes cluster, making global decisions on the cluster, which is equivalent to the "brain" of the entire cluster. All control commands executed by the cluster are received and processed by the Master server. The Master server mainly includes the following components.

• kube-apiserver component: the HTTP REST API interface of the cluster, which is the entry point for cluster control.
• kube-controller-manager component: an automated control center for all resource objects in the cluster.
• kube-scheduler component: a scheduling service for Pod resource objects in the cluster.

        The Node client (working node) is the working node in the Kubernetes cluster. The work on the Node node is distributed by the Master server. For example, when a Node node goes down, the Master node will transfer the work on it to other Node nodes. superior.

        The Node node mainly includes the following components.

• Kubelet component: responsible for managing tasks such as creation, deletion, start and stop of containers on the node, and communicating with the Master node.
• kube-proxy component: Responsible for communication and load balancing services of Kubernetes services.
• container component: responsible for the basic management service of the container, receiving instructions from the kubelet component.

4. Summary and expansion

4.1. Excellent features of Kubernetes

Kubermetes has the following excellent features.

• Powerful container orchestration capabilities

        It can be said that Kubernetes was developed together with Docker, deeply integrated with Docker, and naturally adapted to the characteristics of containers, and designed powerful container orchestration capabilities, such as container combination, label selection, and service discovery, etc., to meet enterprise-level needs.

• lightweight

        Kubermetes follows the theory of microservice architecture. The entire system is divided into functionally independent components. The boundaries between components are clear, the deployment is simple, and it can easily run in various systems and environments. At the same time, many functions in Kubermetes are pluggable, which can be easily extended and replaced.

• open source

        Kubermetes complies with the trend of open source, attracting a large number of developers and companies to participate and work together to build an ecosystem. At the same time, Kubernetes actively cooperates and develops together with open source communities such as OpenStack and Docker, and both enterprises and individuals can participate in and benefit from it.

At the same time, the Kubernetes system also has the following features:
●Portable: supports public cloud, private cloud, hybrid cloud, and multi-cloud (Multi-cloud).
● Extensible: modular, plug-in, mountable, and combinable.
● Automation: automatic deployment, automatic restart, automatic replication, automatic scaling/expansion.

4.2. Kubernetes and Docker

        Kubernetes and Docker are two complementary technologies. For example, usually people will use Docker for application development, and then use Kubernetes to orchestrate the application in the production environment.

        In such a model, developers write code in their favorite language, and then use Docker to package, test and deliver. But the process of finally running in the test environment or production environment is done by Kubernetes. In terms of operating architecture, assume that a Kubernetes cluster in a production environment is composed of 10 nodes. Then each of the nodes uses Docker as its container runtime (Container Runtime). In other words, Docker is a more low-level technology, which is responsible for operations such as starting and stopping containers; while Kubernetes is a more upper-level technology, which focuses on cluster-wide management, such as deciding which node to run the container on, Decide what is suitable for scaling or upgrading.

        Figure 1.2 illustrates a Kubernetes cluster consisting of multiple nodes with Docker as the container runtime.

        As shown in Figure 1.2, Docker is not the only container runtime supported by Kubernetes. In fact, Kubernetes implements the abstraction of the container runtime based on a series of features (so that it can be compatible with different underlying container runtimes).

        (1) The Container Runtime Interface (CRI) is a standardized abstraction layer used by Kubernetes to interface with third-party container runtimes. In this way, the container runtime is decoupled from Kubernetes, and at the same time it can be supported in a standardized way.

        (2) Runtime Class (Runtime Class) is a new feature introduced in Kubernetes 1.12 and upgraded to beta in version 1.14. It categorizes the different runtimes. For example, gVisor or Kata container runtimes may provide better isolation than Docker and Containerd.

        As of this writing, Containerd has overtaken Docker as the most commonly used container runtime in Kubernetes. It's actually a stripped-down version of Docker, keeping only the parts required by Kubernetes.

        Although mentioned, these underlying technologies will not affect the learning experience of Kubernetes. Operations at the Kubernetes level (commands, etc.) are the same no matter which container runtime is used.

4.3 Why is Kubernetes called K8s

        K8S is based on Google's Borg system (Borg system, a large-scale container orchestration tool used internally by Google) as a prototype, and then rewritten by Go language using Borg's ideas and donated to the CNCF Foundation for open source.

        The name of kubernetes comes from Greek, meaning "helmsman" or "navigator", and K8s is the abbreviation of replacing the eight letters "ubernete" with "8".