【运维干货分享】一份完整的图文手册，理解kubetnetes架构

admin管理员组

文章数量:1439837

【运维干货分享】一份完整的图文手册，理解kubetnetes架构

这是一份完整的手册通过插图的形式去详细解释每个kubernetes组件

你将从这篇文章中了解：

• 1.理解kubernetes架构
• 2.理解kubernetes的基本概念
• 3.学习关于kubernetes架构的组件
• 4.探讨这些组件的工作流程

然后你将发现这份架构指南非常宝贵

什么是kubernetes架构

下面的 Kubernetes 架构图展示了 Kubernetes 集群的所有组件以及外部系统如何连接到 Kubernetes 集群。

关于 Kubernetes，你首先应该了解的也是最重要的一点是，它是一个分布式系统。这意味着它有多个组件分布在网络上的不同服务器上。这些服务器可以是虚拟机或裸机服务器。我们称之为 Kubernetes 集群。

Kubernetes 集群由控制平面节点和工作节点组成。

控制平面

控制平面负责容器编排并维护集群的所需状态。它具有以下组件。

• kube-apiserver
• etcd
• kube-scheduler
• kube-controller-manager
• cloud-controller-manager

一个集群可以有一个或多个控制平面节点。

工作节点

Worker 节点负责运行容器化应用程序。工作节点具有以下组件。

• kubelet
• kube-proxy
• Container runtime

控制平面组件

首先，让我们看一下每个控制平面组件以及每个组件背后的重要概念。

1.kube-apiserver

kube-api 服务器是 Kubernetes 集群的中心枢纽，公开 Kubernetes API。它具有高度可扩展性，可以处理大量并发请求。

最终，用户和其他集群组件通过 API 服务器与集群通信。很少情况下，监控系统和第三方服务会与 API 服务器通信以与集群交互。

因此，当您使用 kubectl 管理集群时，在后端您实际上是通过 HTTP REST API 与 API 服务器进行通信。然而，内部集群组件（如调度程序、控制器等）使用 gRPC 与 API 服务器通信。

API 服务器与集群中其他组件之间的通信通过 TLS 进行，以防止对集群进行未经授权的访问。

Kubernetes api-server 负责以下工作。

• 1.API管理：公开集群API端点并处理所有API请求。 API是版本化的，同时支持多个API版本。
• 2.身份验证（使用客户端证书、不记名令牌和 HTTP 基本身份验证）和授权（ABAC 和 RBAC 评估）
• 3.处理 API 请求并验证 API 对象（如 Pod、服务等）的数据（验证和变更准入控制器）
• 4.它是唯一与 etcd 通信的组件。
• 5.api-server 协调控制平面和工作节点组件之间的所有进程。
• 6.api-server 有一个内置的 apiserver proxy。它是 API 服务器进程的一部分。它主要用于支持从集群外部访问 ClusterIP 服务，即使这些服务通常只能在集群本身内部访问。
• 7.API 服务器还包含一个聚合层，允许您扩展 Kubernetes API 以创建自定义 API 资源和控制器。
• 8.API 服务器还支持监视资源的变化。例如，客户端可以对特定资源建立监视，并在创建、修改或删除这些资源时接收实时通知

安全注意事项：为了减少集群攻击面，保护 API 服务器的安全至关重要。 Shadowserver 基金会进行了一项实验，发现了 380,000 个可公开访问的 Kubernetes API 服务器。

2.etcd

Kubernetes 是一个分布式系统，它需要像 etcd 这样高效的分布式数据库来支持其分布式特性。它既充当后端服务发现又充当数据库。 你可以将其称为 Kubernetes 集群的大脑。

etcd 是一个开源的强一致性、分布式键值存储。那么这意味着什么呢？

• 1.强一致性
• 2.分布式
• 3.键值存储 如果对一个节点进行更新，强一致性将确保它立即更新到集群中的所有其他节点。另外，如果你看看 CAP 定理，实现 100% 可用性、强一致性和分区容错性是不可能的。 ：etcd 被设计为作为集群在多个节点上运行，而不牺牲一致性。
• 3.键值存储：将数据存储为键和值的非关系数据库。它还公开了一个键值 API。该数据存储构建在 BboltDB 之上，BboltDB 是 BoltDB 的一个分支。

etcd 使用 raft 共识算法来实现强一致性和可用性。它以领导者-成员的方式工作，以实现高可用性并承受节点故障。

那么 etcd 如何与 Kubernetes 配合使用呢？

简单来说，当您使用 kubectl 获取 kubernetes 对象详细信息时，您是从 etcd 获取的。此外，当您部署像 pod 这样的对象时，会在 etcd 中创建一个条目。

简而言之，以下是您需要了解的有关 etcd 的信息。

• 1.etcd 存储 Kubernetes 对象的所有配置、状态和元数据（pod、秘密、守护进程集、部署、配置映射、状态集等）。
• 2.etcd 允许客户端使用 Watch() API 订阅事件。 Kubernetes api-server 使用 etcd 的监视功能来跟踪对象状态的变化。
• 3.etcd 使用 gRPC 公开键值 API。此外，gRPC 网关是一个 RESTful 代理，它将所有 HTTP API 调用转换为 gRPC 消息。这使其成为 Kubernetes 的理想数据库。
• 4.etcd 以键值格式存储 /registry 目录键下的所有对象。例如，default命名空间中名为Nginx的pod的信息可以在/registry/pods/default/nginx下找到

此外，etcd 是控制平面中唯一的 Statefulset 组件。

3.kube-scheduler

kube-scheduler 负责在工作节点上调度 Kubernetes Pod。

部署 Pod 时，您可以指定 Pod 要求，例如 CPU、内存、关联性、污点或容忍度、优先级、持久卷 (PV) 等。调度程序的主要任务是识别创建请求并为 Pod 选择最佳节点。满足要求的 Pod。

下图显示了调度程序如何工作的高级概述。

在一个 Kubernetes 集群中，会有多个工作节点。那么调度程序如何从所有工作节点中选择节点呢？

以下是调度程序的工作原理。

• 1.为了选择最佳节点，Kube 调度程序使用过滤和评分操作。
• 2.在过滤过程中，调度程序会找到最适合调度 Pod 的节点。例如，如果有五个具有资源可用性的工作节点来运行 Pod，则它会选择所有五个节点。如果没有节点，则 pod 不可调度并移至调度队列。如果是一个大型集群，假设有 100 个工作节点，那么调度程序不会迭代所有节点。有一个名为 percentageOfNodesToScore 的调度程序配置参数。默认值通常为 50%。因此它尝试以循环方式迭代 50% 以上的节点。如果工作节点分布在多个区域，则调度程序将迭代不同区域中的节点。对于非常大的集群，默认 percentageOfNodesToScore 为 5%。
• 3.在评分阶段，调度程序通过为过滤后的工作节点分配分数来对节点进行排名。调度器通过调用多个调度插件来进行评分。最后，将选择排名最高的工作节点来调度 Pod。如果所有节点的等级相同，则将随机选择一个节点。
• 4.一旦选择了节点，调度程序就会在 API 服务器中创建一个绑定事件。意思是绑定 pod 和节点的事件。

这是您需要了解的有关调度程序的信息。

• 1.它是一个监听 API 服务器中 pod 创建事件的控制器。
• 2.调度程序有两个阶段。调度周期和绑定周期。它们一起称为调度上下文。调度周期选择工作节点，绑定周期将该更改应用于集群。
• 3.调度程序始终将高优先级 pod 放在低优先级 pod 之前进行调度。此外，在某些情况下，Pod 开始在选定节点中运行后，Pod 可能会被驱逐或移动到其他节点。如果您想了解更多信息，请阅读 Kubernetes Pod 优先级指南
• 4.您可以创建自定义调度程序并在集群中与本机调度程序一起运行多个调度程序。部署 Pod 时，您可以在 Pod 清单中指定自定义调度程序。因此，将根据自定义调度程序逻辑做出调度决策。
• 5.调度器有一个可插拔的调度框架。这意味着您可以将自定义插件添加到调度工作流程中。

4.Kube Controller Manager

什么是控制器？控制器是运行无限控制循环的程序。这意味着它连续运行并观察对象的实际和期望状态。如果实际状态和期望状态存在差异，它可以确保 kubernetes 资源/对象处于期望状态。

根据官方文档

在 Kubernetes 中，控制器是控制循环，用于监视集群的状态，然后在需要时进行或请求更改。每个控制器都会尝试使当前集群状态更接近所需状态。

假设您想要创建一个deployment，您可以在清单 YAML 文件中指定所需的状态（声明式方法）。例如，2 个副本、1 个卷挂载、configmap 等。内置的deployment控制器可确保部署始终处于所需状态。如果用户使用 5 个副本更新部署，deployment控制器会识别它并确保所需状态为 5 个副本。

Kube controller manager是管理所有Kubernetes控制器的组件。 Kubernetes 资源/对象（例如 pod、命名空间、作业、副本集）由各自的控制器管理。另外，Kube调度器也是由Kube控制器管理器管理的控制器。

以下是重要的内置 Kubernetes 控制器的列表。

• 1.Deployment controller
• 2.Replicaset controller
• 3.DaemonSet controller
• 4.Job Controller (Kubernetes Jobs)
• 5.CronJob Controller
• 6.endpoints controller
• 7.namespace controller
• 8.service accounts controller
• 9.Node controller

以下是您应该了解的有关 Kube controller manager的信息。

• 1.它管理所有控制器，控制器尝试将集群保持在所需的状态。
• 2.您可以使用与自定义资源定义关联的自定义控制器来扩展 Kubernetes。

5.Cloud Controller Manager (CCM)

当kubernetes部署在云环境中时，Cloud Controller Manager (CCM)充当云平台API和Kubernetes集群之间的桥梁。

这样，核心 kubernetes 核心组件就可以独立工作，并允许云提供商使用插件与 kubernetes 集成。 （例如kubernetes集群与AWS云API之间的接口）

云控制器集成允许 Kubernetes 集群配置云资源，例如实例（用于节点）、负载均衡器（用于服务）和存储卷（用于持久卷）。

云控制器管理器包含一组特定于云平台的控制器，可确保特定于云的组件（节点、负载均衡器、存储等）的所需状态。以下是属于云控制器管理器一部分的三个主要控制器。

• 1.节点控制器：该控制器通过与云提供商 API 对话来更新节点相关信息。例如，节点标记和注释、获取主机名、CPU 和内存可用性、节点健康状况等。
• 2.路由控制器：负责在云平台上配置网络路由。这样不同节点中的 Pod 就可以互相通信。
• 3.服务控制器：它负责为 kubernetes 服务部署负载均衡器、分配 IP 地址等。

以下是云控制器管理器的一些经典示例。

• 1.部署负载均衡器类型的 Kubernetes 服务。这里 Kubernetes 提供了一个特定于云的负载均衡器并与 Kubernetes 服务集成。
• 2.为云存储解决方案支持的 Pod 供应存储卷 (PV)。

总体云控制器管理器管理 kubernetes 使用的特定于云的资源的生命周期。

Kubernetes工作节点组件

Kubelet

Kubelet 是一个代理组件，运行在集群中的每个节点上。 它不作为容器运行，而是作为守护进程运行，由 systemd 管理。

它负责向 API 服务器注册工作节点，并主要使用来自 API 服务器的 podSpec（Pod 规范 - YAML 或 JSON）。 podSpec 定义了应该在 pod 内运行的容器、它们的资源（例如 CPU 和内存限制）以及其他设置，例如环境变量、卷和标签。

然后，它通过创建容器将 podSpec 带到所需的状态。

简单来说，kubelet 负责以下工作。

• 1.创建、修改和删除 Pod 的容器。
• 2.负责处理活跃度、就绪度和启动探测。
• 3.负责通过读取 pod 配置并在主机上创建相应的目录来挂载卷以进行卷挂载。
• 4.通过使用 cAdvisor 和 CRI 等实现调用 API 服务器来收集和报告节点和 Pod 状态。

Kubelet 也是一个控制器，用于监视 pod 更改并利用节点的容器运行时来拉取映像、运行容器等。

除了来自 API 服务器的 PodSpec 之外，kubelet 还可以接受来自文件、HTTP 端点和 HTTP 服务器的 podSpec。 “来自文件的 podSpec”的一个很好的例子是 Kubernetes 静态 Pod。

静态 Pod 由 kubelet 控制，而不是 API 服务器。

这意味着您可以通过向 Kubelet 组件提供 pod YAML 位置来创建 pod。但是，Kubelet 创建的静态 Pod 不受 API 服务器管理。

这是静态 Pod 的真实示例用例。

在引导控制平面时，kubelet 将 api 服务器、调度程序和控制器管理器作为来自位于 /etc/kubernetes/manifests 的 podSpec 的静态 Pod 启动

以下是有关 kubelet 的一些关键内容。

• 1.Kubelet 使用 CRI（容器运行时接口）gRPC 接口与容器运行时通信。
• 2.它还公开一个 HTTP 端点来流日志并为客户端提供执行会话。
• 3.使用CSI（容器存储接口）gRPC 配置块存储卷。
• 4.它使用集群中配置的 CNI 插件来分配 Pod IP 地址并为 Pod 设置任何必要的网络路由和防火墙规则。

kube proxy

要了解 Kube proxy，您需要具备 Kubernetes Service & endpoint objects的基本知识。

Kubernetes 中的服务是一种向内部或外部流量公开一组 Pod 的方法。当您创建服务对象时，它会获得分配给它的虚拟 IP。它被称为 clusterIP。它只能在 Kubernetes 集群内访问。

Endpoint object 包含Service对象下所有Pod组的IP地址和端口。端点控制器负责维护 Pod IP 地址（端点）列表。服务控制器负责配置服务的端点。

您无法 ping ClusterIP，因为它仅用于服务发现，与可 ping 通的 pod IP 不同。

现在我们来了解一下 Kube Proxy。

Kube-proxy 是一个守护进程，作为守护进程集在每个节点上运行。它是一个代理组件，为 Pod 实现 Kubernetes 服务概念。 （一组具有负载平衡功能的 Pod 的单个 DNS）。它主要代理 UDP、TCP 和 SCTP，不理解 HTTP。

当您使用服务 (ClusterIP) 公开 Pod 时，Kube-proxy 会创建网络规则以将流量发送到分组在 Service 对象下的后端 Pod（端点）。这意味着，所有负载平衡和服务发现都由 Kube proxy处理。

那么 Kube-proxy 是如何工作的呢？

kube proxy与 API 服务器通信以获取有关服务 (ClusterIP) 以及相应 pod IP 和端口（端点）的详细信息。它还监视服务和端点的变化。

然后，Kube-proxy 使用以下任一模式来创建/更新规则，以将流量路由到服务后面的 Pod

• 1.iptables:这是默认模式。在 IPTables 模式下，流量由 IPtable 规则处理。这意味着对于每个服务，都会创建 IPtable 规则。这些规则捕获传入 ClusterIP 的流量，然后将其转发到后端 Pod。此外，在此模式下，kube-proxy 会随机选择后端 pod 进行负载均衡。一旦建立连接，请求就会发送到同一个 pod，直到连接终止。
• 2.ipvs:对于服务超过1000个的集群，IPVS提供性能提升。它支持后端以下负载均衡算法。
  • rr ：round-robin ：这是默认模式。
  • lc ：最少连接（打开连接的最小数量）
  • dh ：目标哈希
  • sh ：源哈希
  • sed ：最短预期延迟
  • nq ：从不排队
• 3.Userspace :用户空间（遗留且不推荐）
• 4.Kernelspace: 内核空间：此模式仅适用于Windows系统。

此外，您可以通过将其替换为 Cilium 来运行没有 kube-proxy 的 Kubernetes 集群。

1.29 Alpha 功能：Kubeproxy 有一个新的基于

本文标签： 运维干货分享一份完整的图文手册，理解kubetnetes架构