k8s架构解读

Kubernetes（K8s）是一个开源的容器编排平台，用于管理容器化应用程序。它由 Master 和 Work 节点组成。

k8s 架构组成

Master节点上运行以下主要组件：

Info

除了原生的 kube-controller-manager 外，一般云厂商版本的 k8s 还会有一个 cloud-controller-manager 嵌入了特定于云平台的控制逻辑，允许将你的集群连接到云提供商的 API 之上。

Node节点上运行以下主要组件：

此外，Node节点还可能运行以下可选组件：

kube-apiserver：是K8s API服务器，是集群的控制中心，负责接收来自客户端的请求并对集群状态进行操作。它提供RESTful API，允许用户查看、创建、更新和删除集群资源。
kube-scheduler：K8s调度器，负责将Pod调度到Worker节点上。它会考虑各种因素，例如Pod的资源需求、Node节点的可用资源和Pod的亲和性和反亲和性等。
kube-controller-manager：K8s控制器管理器，负责运行各种控制器，如节点控制器、端点控制器、副本控制器等。这些控制器会不断监视集群状态，并根据需要进行相应的操作。
etcd：K8s的分布式数据存储，用于存储集群状态。它是一个高度可用的键值存储系统，可以确保集群状态的一致性。
kubelet：K8s代理，负责在Node节点上运行Pod。它会根据kube-apiserver的指示创建、启动、停止和管理Pod。
kube-proxy：K8s代理，负责为Pod提供网络服务。它会将Pod的流量路由到相应的Pod实例上。
docker engine：容器引擎，用于运行容器。它负责创建、启动、停止和管理容器。

Master节点上的组件和Node节点上的组件会相互交互以管理集群。例如，kube-scheduler会将Pod调度到Node节点上，然后kubelet会负责在Node节点上运行Pod。kube-proxy会为Pod提供网络服务，并确保Pod之间可以相互通信。

这张图会比上面第一张图更详细，这里会涉及三类接口：CRI、CNI、CSI。

CRI用于定义容器运行时与Kubernetes集群之间通信的标准方式。它提供了一组API，用于管理容器的生命周期，例如创建、运行、停止和删除容器。常见的CRI实现包括Docker、containerd和CRI-O。

CRI的主要优势在于其可移植性，它允许用户在不修改K8s集群的情况下切换不同的容器运行时。

CNI用于定义容器与Pod网络之间通信的标准方式。它提供了一组插件，用于为Pod分配网络资源，例如IP地址、子网和路由。常见的CNI插件包括Flannel、Calico和Weave Net。

CNI使Kubernetes能够与各种网络环境兼容，并为容器提供灵活的网络配置。

CSI用于定义容器与存储系统之间通信的标准方式。它提供了一组API，用于管理容器的存储卷，例如创建、挂载、卸载和删除存储卷。常见的CSI插件包括NFS、GlusterFS和Ceph。

CSI简化了容器存储的管理，并使Kubernetes能够支持各种存储系统。

CRI、CNI和CSI是Kubernetes的关键接口，它们共同实现了容器的运行、网络和存储功能。这三个接口的出现，使Kubernetes更加灵活、可扩展，并能够支持各种应用场景。

通常情况下K8S社区对k8s定义了5层:

如您感觉文章有用，可扫码捐赠本站！(If the article useful, you can scan the QR code to donate))