Shulou(Shulou.com)06/01 Report--

Introduction to Kubernetes

Kubernetes (K8s) is an open source platform that simplifies manual processes for application management, application deployment, and application scaling, giving users more flexibility to deploy and manage cloud applications.

As a scalable fault-tolerant platform, K8s can be deployed in almost any infrastructure and is perfectly compatible with public clouds, private clouds, hybrid clouds, server clusters, data centers, etc. such as Google Cloud, MS Azure and AWS. Kubernetes 'biggest highlight is its support for container auto-deployment and auto-replication. This is why a lot of cloud microservices infrastructure is deployed on K8s.

II. Origin of K8s

Originally designed and developed by Google engineers, K8s was launched and open-sourced in 2014 and is currently maintained and upgraded by community contributors from software giants such as Microsoft, Red Hat, IBM and Docker.

Google not only open-sourced how the company's entire infrastructure works in containers, but also actively developed Linux container technology to support all Google cloud services. The K8s was designed to handle thousands of containers based on 15 years of experience running production workloads on cloud platforms. Google deploys more than 2 billion containers every week. Before K8s went live, Google deployed containers mainly through its internal development platform Borg. Borg is a large in-house cluster management system that runs numerous applications and cluster tasks, and years of development experience have laid the foundation for K8s technology.

III. Working principle of K8s

K8s is essentially a coordination system for containerized applications distributed across different machines, designed to help developers manage the entire lifecycle of containerized applications and services through K8s predictability, scalability, and high availability, unifying multiple machines into one machine through a higher level of abstraction. This is critical for the operation of large environments.

K8s not only optimizes Docker's image runtime capabilities and container management capabilities, but is also compatible with container engines such as rkt and CoreOS.

The architecture diagram above shows how the K8s works. The diagram contains a set of Master components, including many pods. Pods model "logical hosts" for specific applications. Each Pod contains one or more application containers, storage resources, a unique network IP, and container operational details. A Pod is the smallest atomic unit of a container. In theory, a Pod contains one or more highly coupled applications. Ideally, each Pod contains one container.

Each process contains an API server, a scheduler, and multiple controllers.

The API server is responsible for exposing the K8s API, handling REST operations, and subsequent updates. Scheduler is responsible for matching undeployed pods to the appropriate virtual or physical machines. If there is no suitable machine, the Pod will remain unassigned until a suitable node appears. Master runs other cluster-level functions, creating endpoints, discovering nodes, replication control, etc. through embedded controller. Because the controller design is flexible and extensible, Kube administrators can create their own controllers. Kube monitors the shared state of the K8s cluster through the API server and adjusts the cluster state to ensure that the current state is consistent with the ideal state.

K8s provides features that support unified automation, control, and upgrade of containerized applications, including enterprise-class container deployment, built-in service discovery, auto-scaling, persistent storage, high availability, cluster interoperability, and resource binning.

Relying on these capabilities, the K8s enables support for different application architectures such as monolithic applications, batch applications, and highly distributed microservices applications.

IV. Challenges in K8s monitoring practice

Since launching in 2014, K8s has been revolutionizing container technology and has become a key tool for quickly launching applications in batches. At the same time, challenges arise, and container orchestration is extremely complex.

Although K8s has greatly simplified the operation difficulty of a series of tasks in the container implementation and management process, from scheduling and configuration to automatic state maintenance, there are still challenges in monitoring:

Applications communicating with each other are distributed across different cloud service platforms. K8s is essentially a universal platform on which users can freely deploy applications. Enterprises typically adopt multi-cloud solutions that not only reduce dependence on a single cloud service platform, but also reduce downtime and avoid data loss. But this deployment also presents challenges for real-time data capture and application status monitoring. Continuously migrate applications across dynamic infrastructure. Because applications migrate frequently, it is difficult to be fully visible across all platforms and protocols, which hides system bottlenecks. Many companies have multiple applications running on their infrastructure, so this problem is inevitable. Without a robust monitoring system, users cannot spot potential problems with their apps.

The number and complexity of the monitored objects are enormous: the K8s is made up of many components and is complex, so to monitor the K8s you must monitor all of the following objects:

Cluster capacity and resource utilization: (a) Node: Ensure the status of all K8s nodes and monitor CPU, memory, and hard disk usage;(b) Pod: Ensure that all implemented Pods are healthy;(c) Container: Monitor CPU and memory consumption according to configured consumption caps. Applications: Monitor the performance and availability of applications in the cluster based on request rates, throughput, and error rates. End-user experience: Monitor mobile app and browser performance, optimize load time and availability, and improve customer satisfaction. Supporting infrastructure: As mentioned above, the operating platform of K8s is also very important.

Operational details: All of the core components of the K8s (i.e. kubelet, Kube controller manager, and Kube scheduler) are heavily labeled. These flags determine how the cluster operates and runs, and their initial default values are generally small and suitable for smaller clusters. As clusters grow in size, users need to make adjustments to the cluster in a timely manner and monitor details such as K8s labels and comments.

However, monitoring tools that grab large amounts of data from K8s can affect cluster performance and even cause cluster failures, so a monitoring baseline needs to be determined. When fault diagnosis is required, the baseline value can be adjusted upwards appropriately.

Increase baseline values while deploying more masters and nodes to improve availability. When it comes to large-scale deployments, a cluster dedicated to K8s data can be deployed separately, ensuring that the performance of the primary instance is not affected when creating monitoring events and retrieving monitoring data.

V. Monitor K8s from the source

Like many container orchestration platforms, K8s has basic server monitoring tools. These tools can be adjusted to better monitor the operation of the K8s. The main tools are as follows:

K8s Dashboard: Plug-in tool that displays resource utilization on each K8s cluster and is the primary tool for resource and environment management and interaction. Container probe: container health diagnostic tool. Kubelet: Kubelet runs on every Node, monitoring the health of the container. Kubelet is also the communication channel between the Master and each Node. Kubelet can directly expose personalized metrics data related to container usage in cAdvisor. cAdvisor: Open source, single-node agent responsible for monitoring container resource usage and performance, collecting data on memory, network usage, file system, CPU, etc. of all containers on the machine. cAdvisor is simple and easy to use, but it also has shortcomings: firstly, it can only monitor the utilization of basic resources, and cannot analyze the actual performance of applications; secondly, it does not have long-term storage and trend analysis capabilities. Kube-state-metrics: Polls Kubernetes API and converts Kubernetes structured information into metrics. Metrics server: Metrics server periodically collects metrics data from Kubelet's Summary API and exposes it as metric-api.

The overall monitoring process is as follows:

cAdvisor is installed on all cluster nodes by default and collects metrics data for containers and nodes. Kubelet exposes metrics data through the kubelet API. Metrics determines all available nodes, requests Kubelet API to upload container and node usage data, and then exposes metrics data through Kubernetes aggregation API.

Although the basic tools mentioned above cannot provide detailed application monitoring data, they can help users understand the situation of the underlying host and K8s node.

In general, K8s cluster administrators focus on global monitoring, while application developers focus on application-level monitoring. However, the common appeal of both is to monitor the system and collect data as comprehensively as possible under the premise of controlling input costs. In next week's article, we'll look at two possible surveillance schemes: Prometheus and Sensu. Both solutions provide comprehensive system-level monitoring data to help developers track the performance of K8s critical components, locate failures, and receive early warnings.

This article is translated by Stefan Thorpe.

Translated from Monitoring Kubernetes

Translated from UAVStack Intelligent Operation and Maintenance

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.