(2023.08.13 Sun @KLN)
(2023.08.19-20 Sat补 @KLN)
Kubernetes, aka K8S，是一个开源的容器部署和管理平台，用于对容器的统筹(orchestration)、容器运行时间(runtime)、以容器为中心的架构统筹、负载均衡(load balancing)、自修复机制(self-healing mechanism)和服务发现。K8S架构，或K8S应用部署架构、K8S客户端服务器架构，用于在host cluster之间生成(compose)、扩展(scale)、部署和管理应用容器。
部署K8S直接生成一个集群(cluster)。
一个k8s集群包括：
- 一系列工作机(work machine)或节点(nodes)构成，节点运行容器化应用(containerised applications)。每个集群有至少一个节点。每个节点可以是虚拟机也可以是物理机。Pods运行在节点之上，pods是应用负载的组成部分。
- 控制平面(control plane)：用于管理集群中的节点及其中的pods，生产环境中control plane通常运行在多个电脑之上，一个集群运行多个节点，用以提供容错和高可用性
Kubernetes的架构如下
k8s architecture
控制平面CP
CP是用于管理集群的中枢，比如任务调度(scheduling)、检测和回应集群事件(包括启动新pod等)。CP还要维护配置文件数据和所有K8S对象的状态信息，确保集群按配置运行。
CP可在集群中的任何机器上运行；经验上为了简便，设置脚本仅在集群的一台机器上启动，且该机器上不运行容器。使用kubeadm可在多机器上启动CP以实现高可用功能。
CP由如下几个部分组成：
- kube-apiserver
- etcd
- kube-scheduler
- kube-controller-manager
- cloud-controller-manager
kube-apiserver
API server用于暴露k8s集群的API，是k8s CP的前端。用户从集群外只能通过api server连接到集群，apiserver扮演gateway的角色，在用户和pod、服务之间建立起管道。k8s API server的主要实现方式是kube-apiserver。kube-apiserver被设计成可横向扩展(scale horizontally)，即可部署更多实例(instances)。可运行kube-apiserver的多个实例并在不同实例间调控流量(balance traffic)。
etcd
K8S需要一个高效的分布式数据库用于支援其分布式特性，而etcd就是这个数据库。etcd是key-value形式的存储系统，存储集群的配置数据和集群状态信息，用于保证集群状态一致。etcd可以在外部设置，但通常作为K8S CP的一部分。
etcd基于Raft共识(consensus)算法存储集群状态数据。Raft算法中定义三种角色，即leader、candidate和follower，通过选出leader达成共识。etcd在K8S集群中扮演了single source of truth(SSOT)角色，对来自CP的查询做出相应，从各容器中获得状态参数。etcd还存储了ConfigMaps、subnets和Secrets扥配置信息和集群状态信息。
kube-scheduler
调度器为每个计算节点存储资源使用数据；判断集群是否健康；决定新容器是否应该被部署以及部署在何处。调度器考虑集群健康度包括pod的资源需求如CPU和内存，还要选择计算节点、调度任务、保证数据本地化、保证服务品质等
调度器用于监视新创建且未被分配节点的pod，并为其分配运行节点。
分配节点的考虑因素包括
- 个体和集体的资源需求
- 限制：硬件、软件和政策
- 数据本地性(data locality)
- 工作负载间的干扰(inter-workload interference)
- 截止日期(deadline)
kube-controller-manager
controller manager用于运行控制器进程。逻辑上，每个控制器是一个独立进程，但为了降低复杂度，controller manager被编译成单独的二进制程序并在单独进程中进行。
k8s中有多种控制器，比如
- node控制器：当node宕机，node控制器用于通知集群并响应
- job控制器：监控一次性任务(one-off task)并创建pod运行这些任务直到完成
- EndpointSlice控制器：Populates EndpointSlice objects (to provide a link between Services and Pods).
- ServiceAccount控制器：为新的命名空间创建默认的ServiceAccounts
cloud-controller-manager
负责针对云的控制逻辑(cloud-specific control logic)。cloud controller manage可将集群与云服务器API相连，并将仅和云交互的组件隔离开(separates out the components that interact with that cloud platform from components that only interact with the cluter)。
云管理器仅工作在有云供应商的环境中，如果咋本地运行k8s且不连接云平台，则集群不需要云管理器。对比kube controller manager，云控制器manager在逻辑上联合了若干独立的控制链路(control loop)并整合成一个独立的二进制程序成为单独进程。cloud controller manager可横向扩展以提高性能或容错。
下面的控制器依赖于云供应商：
- node控制器：检测cloud provider以决定是否在节点停止响应后删除节点
- 路由控制器：在底层云中设定路由
- 服务控制器(service controller)：创建、更新、删除cloud provider load balancers
节点Node
集群必须有至少一个计算节点。节点连接了应用、网络连接、计算和存储资源。节点可以是云原生虚拟机(cloud-native VM)或数据中心的服务器。节点为k8s提供了runtime环境，维护pod的正常运行。
节点包括
- kubelet
- kube-proxy
- 容器runtime
kubelet
节点中的中介，确保容器运行在pods之中。kubelet确保由PodSpecs描述的容器都正常和健康的运行。kubelet不管理未经k8s创建的容器。
kube-proxy
kube-proxy是集群中每个节点上运行的网络代理，实现了部分K8S Service中的概念。kube proxy在节点上维护网络规定(maintain network rules on nodes)。这些网络规则允许pod与集群内外的网络会话(network session)。
除了负责网络代理，kube-proxy还有负载均衡器功能，为UDP和TCP提供路由。
kube proxy使用了操作系统的packet filtering layer。
Container runtime
容器runtime负责运行容器。k8s支持container runtimes比如containerd、CRI-O，以及其他K8S CRI (container runtime interface)
Pods
一个pod代表了应用的一个单一实例(instance)，也是K8S中最基础和重要的单元。Pod有一个容器组成或与容器紧密耦合(tightly coupled)。Pod的生命周期中会连接持久化存储数据提供有状态应用(stateful application)。Pods可横向自扩展(horizontal autoscaling)，即可实现运行实例的增减。还可实现滚动更新和金丝雀部署(rolling update & canary deployments)。
Pod运行于节点之上，因此可以通过localhost网络连接共享内容、存储和连接其他pods。容器可以在多台机器上扩展，pods也是。每个节点上课运行多个pods，每个pod可包含多个容器。
Pod是K8S生态系统的核心管理单元。pod分组机制(pod grouping mechanism)弱化了虚拟化和容器化之间的差别，保证了可以同时运行互相依赖的进程。
创建备份(replica sets)可实现在runtime条件的pods扩展。pod和备集都可以被暴露给外部或内部消费者。
Reference
1 kubernetes点io
2 kubernetes 架构及应用场景，微信公众号架构师大咖
网友评论