00 Why We Should Learn Kubernetes Technology #

Kubernetes is an open-source distributed container orchestration and resource management system developed by Google. Due to its lengthy English terminology, the community has defined an abbreviation for it: K8s. Since its release in 2014, it has become the hottest open-source project in the GitHub community. Because cloud-native technologies based on K8s have become the de facto standard technology stack for enterprise digital transformation. Domestic enterprises have followed suit and started planning to implement K8s clusters as the default infrastructure for enterprise application deployment. However, there is no particularly good tool to implement this cloud-native technology in practice. In most cases, we must combine the actual situation of the enterprise to deploy enterprise applications. Of course, although this sounds simple, when we actually start the deployment, technical personnel will find that the knowledge that can be found online to solve practical application deployment and deployment problems is fragmented and it is difficult to systematically solve them. Therefore, taking advantage of this opportunity, the author, with confidence in preaching cloud-native technology, will explore with you the various technical details and practical decision-making strategies for implementing K8s, so that K8s users can confidently cope with the deployment of container cluster orchestration technology.

Before learning K8s technology, I would like to summarize several problems that the community has encountered during the learning process:

Multiple choices: The K8s system is a cluster system that focuses on container application management. Its components are generally deployed on control nodes (master nodes) and compute nodes (agent nodes) based on their functions. For the control nodes, they mainly include an etcd cluster, a controller manager component, a scheduler component, and an API server component. For the compute nodes, they mainly include a kubelet component and a kubelet-proxy component. Beginners will find that the number of K8s components is not particularly large, so why does it give the impression of being difficult to install? It is important to emphasize that even in 2020, our basic software and hardware infrastructure cannot guarantee that the installation is the most optimal configuration, and there is still a need for system engineers to solve some compatibility issues. Therefore, when you install these K8s system components on physical machines or virtual machines, it cannot be guaranteed to be the most optimal deployment configuration. For this reason, when you as a user create a new cluster deployment plan, you need to make many choices to optimize it.

In addition, the deployment of enterprise business systems depends not only on K8s but also on networks, storage, and other components. We know that the container model is based on a single machine design and did not consider the communication problem of large-scale containers across multiple hosts at the beginning. The network between Pods has only defined interface standards, and the specific implementation relies on third-party network solutions. Up until now, you still need to make choices, choosing suitable network and network storage solutions.

It is important to note that perfect container network solutions have not yet emerged. It needs to be chosen based on your existing environment and underlying hardware. However, many books and materials currently only introduce the most popular open-source solutions, and they do not take responsibility for whether these solutions can run better in your system. This brings a lot of pain to system operators. Even now, I still encounter many development and operation personnel who struggle with these choices when maintaining K8s systems. Yes, open-source community solutions are driven by multiple motivations and have competition, so we cannot hastily choose a container network and then stop caring about its development. Today’s optimal network solution may no longer be the best in half a year. The same applies to choosing container storage solutions.

Difficult troubleshooting: The K8s community currently provides various maintenance tools, including ansible, containerized versions, desktop versions, and other cloud-native deployment tools. Each tool is not something that can be easily familiarized with just a few lines of code, and users need to invest a lot of effort to learn and experiment. Due to the diversity of underlying systems, you will encounter various problems, such as a low version of the container engine Docker, the absence of the time synchronization component NTP, and container networks not being compatible with the underlying networks. When any of these issues occur, you need to troubleshoot them. In addition, the system environment of enterprises is already very complex, and in many scenarios, there is no internet connection available for searching information. It is difficult to troubleshoot even if all the logs are collected and analyzed.

You may feel that this is due to the infrastructure of the company not being well-built, and hiring an expert to take a look may be a solution. Users do want to solve these problems, but both commercial and open-source solutions only consider the troubleshooting of the core components of K8s. There is no systematic learning available for troubleshooting in aspects such as application containers, clusters, hosts, networks, storage, monitoring logs, continuous integration and deployment, etc. Moreover, there is a new major version of the K8s cluster every quarter. For enterprise users, how can the K8s components be smoothly updated without affecting the business? This is where the headache comes from. When unpredictable problems occur, how can we troubleshoot and efficiently solve them? This is the problem that this series of columns will explore with you. Multiple Scenarios: In the early application orchestration scenarios, the main goal was to smooth out peak loads and efficiently utilize idle resources. One of the often undisclosed operational secrets is that the average utilization rate of production servers does not exceed 20%. This is not due to incompetence but rather because in the event of peak usage, the server system needs to be able to handle it smoothly, leaving room for capacity. With the introduction of containers, the number of processes that can be deployed on a server has increased from 3-4 to 20-40, thanks to the ability of container processes to isolate themselves from each other. This is the greatest advantage of container applications.

Some knowledgeable technical architects in the community have used the analogy of comparing containerization to renting a single apartment versus living in a partitioned room with multiple tenants. This analogy vividly describes the concept. With the increasing diversity of application scenarios, when dealing with sudden increases in traffic, the K8s orchestration system is used as a tool for elastic scaling, quickly increasing the number of processes to handle the traffic. In addition to traditional microservice deployment requirements, the introduction of Service Mesh technology for hybrid deployment has also brought new requirements for traffic orchestration to K8s. Furthermore, the FaaS framework Openfaas in the Serverless scenario has also brought new opportunities and challenges to K8s. Many stateful middleware services, such as database clusters, have also been migrated to K8s clusters and received positive feedback from practice.

Nowadays, K8s has become the standard infrastructure solution for application release management in enterprise digital transformation. Faced with so many demanding scenarios, can we solve all these requirements with a single container orchestration cluster? Obviously not. In reality, many application clusters are managed by multiple cluster systems to address management and optimization concerns. Deploying multiple clusters in different regions has brought many challenges to operations and maintenance. This is the headache caused by managing multiple clusters in different scenarios.

The above problems are only the key issues encountered by the author in communication with customers over the years. In the actual process, we may encounter many non-K8s-related problems that we have to compromise on in order to implement container orchestration clusters. These are experiences that we need to pay attention to and summarize during our learning process.

Column Features #

• Starting from practical scenarios and organizing technical details from the perspective of users
• Providing a complete knowledge system as a reference for K8s users
• Considering the universality of each chapter, enabling more people to make informed choices on problem-solving solutions that suit them

What you will gain #

Through this column, you will gain a comprehensive understanding of the principles and techniques of K8s components and learn about the combination process of distributed systems, combined with the ideology of cloud native open source. In order to solve possible problems in daily scenarios, you can also gain exclusive practical understanding and problem-solving approaches in separate chapters, allowing you to deduce and learn some architectural thinking models. The author has also selected detailed explanations of K8s components, allowing curious users to continuously understand the principles of these components and their internal implementations, enabling you to have a more accurate grasp of these components. It is believed that you also have the opportunity to participate in the development of K8s and write more components to replace them.

Column structure #

In the process of writing this series of articles, I tried to avoid copying a lot of reference materials from the Internet, and instead help everyone build up the experience of building a production-ready system from scratch. Because the content involved is too scattered, it is easy for readers to lose focus. Therefore, I focus on discussing several key points encountered in production deployment.

In the first part, I want to talk about the optimization of K8s components and the issues that need attention in the installation process. Many books have already discussed this area in great detail. However, what I have seen in these books is only the process, without explaining why they are designed this way. This was a very painful experience for me when I was learning K8s back then. This time, I want to help everyone clear the learning obstacles in this area.

In the second part, we need to discuss configurations. The most important thing about a complex system itself is to familiarize yourself with the configuration information of various components. If the configuration is incorrect, no matter how you debug it, you will not get good results, so understanding the various options in this area is also very important. Although this area may be boring, it must be mastered. I will try to describe this content using kubectl.

In the third part, I will share the architecture of network traffic. I think this area is of great concern to many users. Because each network solution also involves configuration, load testing, selection, there are still many things to pay attention to.

In the fourth part, we will discuss the storage selection for business applications. Network storage solutions have developed to this day, and the most famous one is Ceph. However, if you directly start with the Ceph solution without proper timing, you will immediately fall into the pit of operating Ceph. In fact, there are many container storage solutions, and you need to choose the right solution based on your needs. Of course, within an enterprise, everyone needs a unified container storage solution that can support all requirements. I think this is a deviation from understanding the business. A more user-friendly approach should be specialized and dedicated. This will definitely bring various solutions, which can also be solved. Using K8s to orchestrate and manage various storage is a natural development of the business.

In the fifth part, we will focus on the security configuration of the K8s cluster. Installing K8s is a medium-sized task, and the security configuration and optimization of K8s is even more important. There are countless open-source tools in this area, and we need to learn and master the core methodologies and sort out the toolchain we need to deal with container security practices.

Finally, I hope that you can quickly immerse yourself in the learning process of K8s, and let us explore and implement secure and reliable K8s container orchestration clusters together.

Column author #

Xiao Deshi, an evangelist for enterprise-level container technology, and a developer in multiple top international open-source project communities such as Docker/Kubernetes/OpenShift. Former CTO of a container cloud startup called Shuren Cloud. Currently, conducting technical research and evangelism in the field of container technology, Kubernetes, and other distributed systems.

Target audience #

All operations and development engineers, system engineers, DevOps engineers, and IT engineers who want to understand containers and technology can come and take a look. Because cloud-native technology has been widely used in Chinese enterprises, we need to learn and gain a deeper understanding of this technology. In order to accurately understand this technology, this series is most suitable for employees at various stages of application within enterprises and technology enthusiasts.