Kubernetes部署相关概念

本文封面由凯楠📸友情提供

Kubernetes部署相关概念概览

容器运行时（container runtime）：

是负责在计算机操作系统上创建、运行和管理容器的软件组件。它是整个容器化环境中的关键组成部分，与操作系统内核紧密交互，负责管理容器的生命周期、资源隔离、文件系统挂载和网络连接等功能。

Master-Node和Work-Node：

两者角色分别对应着控制节点和工作节点。Kubernetes的核心组件部署在Master管理节点作为Kubernetes的“大脑”，控制整分布式集群的运转。Node节点作为"四肢"，执行Master的操作指令。

控制平面(Control Plane)和数据平面(Data Plane)：

控制平面是管理集群的“大脑”负责决策和全局控制，也被称为管理节点。数据平面是负责运行容器化应用程序的节点，也被称为工作节点。

Kubelet：

运行在每个 Kubernetes 节点上的代理，负责管理该节点上的容器。它与容器运行时通信，确保容器按照 Pod 的规格运行。kubelet 还负责监控容器的状态，并向主控制平面报告节点的状态。

Kubeadm：

Kubernetes 的一个命令行工具，用于在一个或多个节点上启动、初始化或升级 Kubernetes 集群。它提供了一个简化的方式来配置集群，而不必手动执行复杂的步骤。kubeadm 通常用于设置和管理集群的初始化过程。

kubectl ：

Kubernetes 的命令行客户端工具，用于与 Kubernetes 集群进行交互。通过 kubectl，用户可以管理集群、部署和扩展应用、查看集群状态等。kubectl 可以用来执行各种操作，例如创建、删除和更新资源对象（如 Pod、Service、Deployment 等）。

容器运行时（container runtime）

Kubernetes是一个容器编排和管理系统，它的主要任务是在集群中部署、运行和管理容器化应用程序。因此，kubernetes需要一个“容器运行时”来管理容器，以便能够将容器化的应用程序部署和运行在集群中。Docker和Containerd都是常用的“容器运行时”，因此需要在安装kubernetes安装之前进行安装。

需要注意，从Kubernetes v1.20版本开始，Kubernetes官方已经将默认的“容器运行时”从Docker改为Containerd。因此，Kubernetes将同时支持使用Docker和Containerd作为“容器运行时”，将此从docker依赖中解放出来。从v1.24版本开始，docker作为“容器运行时”已经被官方弃用，Containerd成为唯一的“容器运行时”。

Cgroup

是Linux内核的一个功能，用来限制、控制与分离一个进程组的资源（如CPU、内存、磁盘输入输出等）。

Linux namespaces

是对全局系统资源一种封装隔离，使处于不同namespace的进程拥有独立全局系统资源，改一个namespace中系统资源只会影响当前namespace里的进程，对其他namespace中的进程没有影响。

在Kubernetes中，“容器运行时”需要与宿主机的Cgroup和Namespace进行交互，以管理容器的资源。而对于Cgroup的驱动程序，默认使用的是Cgroupfs。需要将三者统一，将/etc/containerd/config.toml文件中的SystemdCgroup改成true。表示使用Systemd驱动。相比于Cgroupfs驱动，可以提高Kubernetes集群资源管理效率和集群性能。

Master-Node和Work-Node

Master-Node又称控制平面(Control Plane)有四大组件apiserver、etcd、controller-manager、scheduler。
Master-Node节点的Cloud Controller Manager组件是云控制管理器，是负责与云平台的API进行交互并提供一致的管理接口方便用户管理他们的程序。
Work-Node节点又称数据平面(Data Plane)有三大组件kubelet、kube-proxy、Container Runtime。

控制平面(Control Plane)和数据平面(Data Plane)

控制平面组件：

kube-apiserver：

是控制平面的入口，处理来自用户、其他组件和外部系统API请求。提供API的服务端实现。

etcd：

分布式键值存储系统，用于存储集群的配置数据、状态和元数据。etcd 提供了持久性存储，确保即使在控制平面组件失败或重启时，集群的状态仍然可恢复。

kube-controller-manager：

运行一系列控制器，负责监控集群的状态，并根据所需的状态调整系统。例如，Node 控制器负责管理节点，Replication Controller 负责确保指定数量的 Pod 实例在集群中运行。

kube-scheduler：

负责决定在哪个节点上启动新的 Pod 实例。它根据节点资源、Pod 调度策略和其他约束来进行决策。

数据平面组件：

kubelet：

在每个节点上运行的代理，负责维护节点上的容器。它通过与控制平面的 kube-apiserver 交互来获取 Pod 规范，并确保 Pod 中的容器按规范运行。

kube-proxy：

负责维护节点上的网络规则，实现 Kubernetes 服务的网络代理。它通过 iptables 或其他实现来确保流量正确路由到集群中的 Pod。

Container Runtime：

负责在节点上运行容器。通过启动和管理容器来满足 Pod 的规范。

控制平面和数据平面的分离使得 Kubernetes 具有高度的可扩展性和灵活性。通过这种架构，可以在不影响整体系统运行的情况下分别扩展控制平面和数据平面的能力。

工作原理

用户通过 kube-apiserver 与控制平面通信，提交集群操作请求。
控制平面组件（etcd、kube-controller-manager、kube-scheduler）负责决策、调度和维护集群状态。
kubelet 接收控制平面的指令，负责在节点上创建、更新和删除容器。
kube-proxy 负责维护节点上的网络规则，实现服务代理。
“容器运行时”负责在节点启动和管理容器。

Kubernetes 容器网络接口（CNI）

Kubernetes 网络的实现不是集群内部自己实现，而是依赖于第三方网络插件。Kubernetes 提供了容器网络接口 CNI（Container Network Interface），具体的网络通信交给 CNI 插件来负责。主要有两种网络插件分别是Flannel网络插件和Calico 网络插件。

Flannel插件

是随着CNI概念的兴起，flannel也是最早实现CNI标准的网络插件（CNI标准也是由CoreOS提出的）。设计目的是为集群中所有节点重新规划IP地址的使用规则，从而使得不同节点上的容器能够获得“同属一个内网”且”不重复的”IP地址，并让属于不同节点上的容器能够直接通过内网IP地址通信。Flannel 实质上是一种“覆盖网络(overlay network)”，是将TCP数据包装在另一种网络包里进行路由转发和通信，目前已经支持UDP、VxLAN、AWS VPC和GCE路由等数据转发方式(此处不展开讲)，默认UDP转发。

Calico 插件

是一种基于 BGP 的、纯三层的、容器间互通的网络方案。 即每个节点上的Pod都拥有唯一的IP地址。这种设计简化了网络管理，同时提供了更直观的网络拓扑。而在多数的虚拟化平台实现中，通常使用二层隔离技术来实现容器的网络，这些二层技术有一些弊端，比如需要依赖VLAN、bridge和隧道等技术。其中 bridge 带来了复杂性，vlan 隔离和 tunnel 隧道则消耗更多的资源并对物理环境有要求，随着网络规模的增大，整体会变得越加复杂。 (此处不展开讲)。