深入理解Kubernetes架构综合指南_kubernetes kube控制器管理器(1)

最新推荐文章于 2024-06-29 15:06:57 发布

BlackCATdog

最新推荐文章于 2024-06-29 15:06:57 发布

阅读量966

点赞数 14

分类专栏：程序员文章标签： go 学习面试

本文链接：https://blog.csdn.net/BlackCATdog/article/details/138800613

版权

程序员专栏收录该内容

54 篇文章 0 订阅

订阅专栏

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以戳这里获取

在评分阶段，调度程序通过为筛选的工作节点分配分数来对节点进行排名。调度程序通过调用多个调度插件进行评分。最后，将选择排名最高的 worker 节点来调度 pod。如果所有节点的等级相同，则将随机选择一个节点。
选择节点后，调度程序将在 API 服务器中创建绑定事件。表示绑定 Pod 和节点的事件。

这是您需要了解的有关调度程序的狗屎。

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

4. Kube 控制管理器

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

根据官方文件，

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

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

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

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

Deployment controller
Replicaset controller
DaemonSet controller
Job Controller (Kubernetes Jobs)
CronJob Controller
endpoints controller
namespace controller
service accounts controller.
Node controller

以下是您应该了解的有关 Kube 控制器管理器的信息。

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

5. 云控制管理器（CCM）

在云环境中部署 Kubernetes 时，云控制器管理器充当云平台 API 和 Kubernetes 集群之间的桥梁。

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

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

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

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

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

部署负载均衡器类型的 Kubernetes 服务。在这里，Kubernetes 预置了一个特定于云的负载均衡器，并与 Kubernetes 服务集成。
为云存储解决方案支持的容器预置存储卷（PV）。

总体而言**，Cloud Controller Manager 管理** Kubernetes 使用的特定于云的资源的生命周期。

Kubernetes Worker 节点组件

现在，让我们看一下每个工作节点组件。

1. Kubelet

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

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

然后，它通过创建容器将 podSpec 置于所需状态。

简单来说，kubelet 负责以下几点。

创建、修改和删除 Pod 的容器。
负责处理活动、就绪和启动探测。
负责通过读取 Pod 配置并在主机上为卷挂载创建相应的目录来挂载卷。
通过调用 API 服务器来收集和报告节点和 Pod 状态，实现类似和。cAdvisor``CRI

Kubelet 也是一个控制器，用于监视 Pod 的变化，并利用节点的容器运行时来拉取镜像、运行容器等。

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

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

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

下面是静态 Pod 的真实示例用例。

在引导控制平面时，kubelet 将 api-server、scheduler 和控制器管理器作为静态 pod 启动，这些 podSpecs 位于/etc/kubernetes/manifests

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

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

2. Kube 代理

要了解 Kube 代理，您需要对 Kubernetes 服务和端点对象有基本的了解。

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

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

您无法对 ClusterIP 执行 ping 操作，因为它仅用于服务发现，这与可 ping 的 Pod IP 不同。

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

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

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

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

Kube 代理与 API 服务器通信，以获取有关服务（ClusterIP）以及相应的 Pod IP 和端口（端点）的详细信息。它还监视服务和终结点中的更改。

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

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

如果您想了解 kube-proxy IPtables 和 IPVS 模式之间的性能差异，请阅读本文。

此外，你可以通过用 Cilium 替换一个没有 kube-proxy 的 Kubernetes 集群来运行它。

3. 容器运行时

您可能知道 Java 运行时（JRE）。它是在主机上运行 Java 程序所需的软件。同样，容器运行时是运行容器所需的软件组件。

容器运行时在 Kubernetes 集群中的所有节点上运行。它负责从容器注册表中提取映像、运行容器、为容器分配和隔离资源，以及管理主机上容器的整个生命周期。

为了更好地理解这一点，让我们看一下两个关键概念：

**容器运行时接口（CRI）：**它是一组 API，允许 Kubernetes 与不同的容器运行时进行交互。它允许不同的容器运行时与 Kubernetes 互换使用。CRI 定义了用于创建、启动、停止和删除容器以及管理映像和容器网络的 API。
**开放容器计划（OCI）：**它是一组容器格式和运行时的标准

Kubernetes 支持多个符合容器运行时接口（CRI）的容器运行时（CRI-O、Docker Engine、containerd 等）。这意味着，所有这些容器运行时都实现了 CRI 接口并公开了 gRPC CRI API（运行时和图像服务端点）。

那么 Kubernetes 是如何利用容器运行时的呢？

正如我们在 Kubelet 部分所了解到的，kubelet 代理负责使用 CRI API 与容器运行时进行交互，以管理容器的生命周期。它还从容器运行时获取所有容器信息，并将其提供给控制平面。

我们以 CRI-O 容器运行时接口为例。以下是容器运行时如何与 Kubernetes 配合使用的高级概述。

当 API 服务器对 Pod 发出新的请求时，kubelet 会与 CRI-O 守护进程通信，以通过 Kubernetes 容器运行时接口启动所需的容器。
CRI-O 使用 containers/image library 检查并拉取所需的容器映像。
然后，CRI-O 会为容器生成 OCI 运行时规范（JSON）。
然后，CRI-O 启动与 OCI 兼容的运行时（runc）以根据运行时规范启动容器进程。

Kubernetes 集群插件组件

除了核心组件之外，kubernetes 集群还需要插件组件才能完全运行。选择插件取决于项目要求和用例。

以下是您在集群上可能需要的一些常用插件组件。

CNI 插件（容器网络接口）
**CoreDNS（用于DNS服务器）：**CoreDNS 充当 Kubernetes 集群中的 DNS 服务器。通过启用此插件，您可以启用基于 DNS 的服务发现。
**Metrics Server（用于资源指标）：**该插件可帮助您收集集群中节点和 Pod 的性能数据和资源使用情况。
**Web UI（Kubernetes 仪表板）：**该插件使 Kubernetes 仪表板能够通过 Web UI 管理对象。