Kubernetes Design Architecture

Official Document: HTTPS://WWW.KUBERNETES.ORG.CN/DOC-11

The Kubernetes cluster contains the node agent Kubelet and master components (APIs, scheduler, etc), all based on a distributed storage system. The following diagram is an architectural diagram of the kubernetes.

Kubernetes node

In this system architecture diagram, we divide the service into services running on the work nodes and the services that make up the cluster-level dashboard.

The Kubernetes node has the services required to run the application container, all of which are controlled by master.

Docker is of course running on each node. Docker is responsible for all the specific image downloads and container runs.

The kubernetes consists mainly of the following core components:

• ETCD preserves the state of the whole cluster;
• Apiserver provides the only portal for resource operations and provides mechanisms for authentication, authorization, access control, API registration, and discovery;
• Controller Manager is responsible for maintaining the status of the cluster, such as fault detection, automatic expansion, rolling updates, etc.
• Scheduler is responsible for the scheduling of resources, according to the scheduled scheduling strategy to the pod scheduling to the corresponding machine;
• Kubelet is responsible for the maintenance of the container life cycle, but also responsible for the management of volume (CVI) and Network (MLM);
• The Container runtime is responsible for image management and the real operation of pods and containers (CRI);
• Kube-proxy is responsible for providing service discovery and load balancing of cluster internal to the service;

In addition to the core components, there are some recommended add-ons:

• Kube-dns is responsible for providing DNS services for the entire cluster
• Ingress Controller provides extranet access for services
• Heapster provides resource monitoring
• Dashboard provides GUI
• Federation provides a cluster across availability zones
• Fluentd-elasticsearch provides cluster log collection, storage and query

Layered architecture

Kubernetes design concept and function is actually a Linux-like layered architecture, as shown in

• Core layer: Kubernetes The most core functions, providing APIs to build high-level applications, internally provide plug-in application execution environment
• Application tiers: Deployment (stateless, stateful, batch, cluster, etc.) and routing (Service discovery, DNS resolution, etc.)
• Management: System metrics (such as metrics for infrastructure, containers, and networks), automation (such as auto-scaling, dynamic provision, etc.) and policy Management (RBAC, Quota, PSP, networkpolicy, etc.)
• Interface layer: Kubectl command-line tool, client SDK, and cluster Federation
• Ecosystem: an ecosystem of large container cluster management scheduling on top of the interface layer can be divided into two categories
  • Kubernetes external: Log, monitor, configuration management, CI, CD, Workflow, FaaS, OTS application, Chatops, etc.
  • Kubernetes internal: CRI, MLM, CVI, mirrored Warehouse, Cloud Provider, configuration and management of the cluster itself, etc.

Kubelet

Kubelet is responsible for managing pods and the containers above them, images mirroring, volumes, etc.

Kube-proxy

Each node also runs a simple network proxy and load balancer (see the Services FAQ) (PS: official English). As defined in the Kubernetes API (see the Services Doc) (PS: official English), some simple TCP and UDP transmissions can be done in a variety of terminals, in the form of polling.

The service endpoint is currently supported through DNS or environment variables (docker-links-compatible and kubernetes{foo}_service_host and {foo}_service_port variables). These variables are parsed by the ports that the service agent manages.

Kubernetes Control Panel

The Kubernetes Control Panel can be divided into several sections. Currently they are all running on a master node, however in order to achieve high availability, this needs to change. The different parts collaborate to provide a unified view of the cluster.

Etcd

The persistence state of all master exists in one instance of ETCD. This can store configuration data well. With watch (Observer) support, changes in the coordination of parts can be quickly detected.

Kubernetes API Server

The API service provides services for the Kubernetes API (PS: official English). This service attempts to have crud characteristics by putting all or most of the business logic into a two-part component. It primarily handles rest operations, verifying that these objects are updated (and eventually stored) in ETCD.

Scheduler

The scheduler binds an unscheduled pod to a node through the binding API. The scheduler is pluggable, and we look forward to supporting multi-cluster scheduling, and in the future even want to support user-defined schedulers.

Kubernetes Control Management Server

All other cluster-level features are currently under the responsibility of the control Manager. For example, the endpoint object is created and updated by the endpoint controller. These can eventually be separated into different parts to allow them to be plugged in and out on their own.

Replicationcontroller (PS: Official English) is a mechanism built on a simple pod API. Once implemented, we eventually plan to turn this into a generic plug-in mechanism.

Kubernetes Design Architecture