【Kubernetes系列】Kubernetes组件介绍

文章目录

• 概述
• Control
• Plane（控制面）
• Node
• Addons（插件）

概述

【Kubernetes系列】Kubernetes组件介绍 - Java技术债务

当部署完 Kubernetes，便拥有了一个完整的集群。

集群是由一组被称作节点（node） 的机器组成， 这些节点上会运行由 Kubernetes 所管理的容器化应用。 且每个集群至少有一个工作节点。

工作节点会托管所谓的 Pods，而 Pod 就是作为应用负载的组件。 控制平面管理集群中的工作节点和 Pods。 为集群提供故障转移和高可用性， 这些控制平面一般跨多主机运行，而集群也会跨多个节点运行。

Control Plane（控制面）

控制面组件会为集群做出全局决策，（比如资源的调度）。 以及检测和响应集群事件，（例如当不满足部署的 replicas 字段时， 要启动新的 pod ）。

控制面组件可以在集群中的任何节点上运行。 然而，为了简单起见，设置脚本通常会在同一个计算机上启动所有控制平面组件， 并且不会在此计算机上运行用户容器。

etcd（分布式的键值对数据存储系统）

etcd 是兼顾一致性与高可用性的键值数据库，可以作为保存 Kubernetes 所有集群数据的后台数据库。Kubernetes 集群的 etcd 数据库通常需要有个备份计划。

如果想要更深入的了解 etcd，请参考 etcd 文档 。

kube-apiserver（API服务器）

组件负责公开 Kubernetes API，负责处理接受请求的工作。 API 服务器是 Kubernetes 控制面的前端。

Kubernetes API 服务器的主要实现是 [kube-apiserver](https://cuizb.top/myblog/article/1663080971#kube-apiserver（API 服务器）)。 kube-apiserver 设计上考虑了水平扩缩，也就是说，它可通过部署多个实例来进行扩缩。 你可以运行 kube-apiserver 的多个实例，并在这些实例之间平衡流量。

kube-scheduler（调度器）

负责监视新创建的、未指定运行节点（node） 的 Pods ， 并选择节点来让 Pod 在上面运行。

调度决策考虑的因素包括单个 Pod 及 Pods 集合的资源需求、软硬件及策略约束、 亲和性及反亲和性规范、数据位置、工作负载间的干扰及最后时限。

kube-controller-manager（控制器管理器）

Kubernetes 控制器管理器是一个守护进程，内嵌随 Kubernetes 一起发布的核心控制回路。 在机器人和自动化的应用中，控制回路是一个永不休止的循环，用于调节系统状态。 在 Kubernetes 中，每个控制器是一个控制回路，通过 API 服务器监视集群的共享状态， 并尝试进行更改以将当前状态转为期望状态。

负责运行控制器 进程。从逻辑上讲， 每个控制器 都是一个单独的进程， 但是为了降低复杂性，它们都被编译到同一个可执行文件，并在同一个进程中运行。

目前，Kubernetes 自带的控制器例子包括副本控制器、节点控制器、命名空间控制器和服务账号控制器等。

这些控制器包括：

• 节点控制器（Node Controller）：负责在节点出现故障时进行通知和响应
• 任务控制器（Job Controller）：监测代表一次性任务的 Job 对象，然后创建 Pods 来运行这些任务直至完成
• 端点控制器（Endpoints Controller）：填充端点（Endpoints）对象（即加入 Service 与 Pod）
• 服务帐户和令牌控制器（Service Account & Token Controllers）：为新的命名空间创建默认帐户和 API 访问令牌

cloud-controller-manager（云控制器管理器）

云控制器管理器（Cloud Controller Manager）允许你将你的集群连接到云提供商的 API 之上， 并将与该云平台交互的组件同与你的集群交互的组件分离开来。嵌入了特定于云平台的控制逻辑。

cloud-controller-manager 仅运行特定于云平台的控制器。 因此如果你在自己的环境中运行 Kubernetes，或者在本地计算机中运行学习环境， 所部署的集群不需要有云控制器管理器。

与 kube-controller-manager 类似，cloud-controller-manager 将若干逻辑上独立的控制回路组合到同一个可执行文件中， 供你以同一进程的方式运行。 你可以对其执行水平扩容（运行不止一个副本）以提升性能或者增强容错能力。

下面的控制器都包含对云平台驱动的依赖：

• 节点控制器（Node Controller）：用于在节点终止响应后检查云提供商以确定节点是否已被删除 节点控制器负责在云基础设施中创建了新服务器时为之 更新 节点（Node） 对象。 节点控制器从云提供商获取当前租户中主机的信息。节点控制器执行以下功能：
  1. 使用从云平台 API 获取的对应服务器的唯一标识符更新 Node 对象；
  2. 利用特定云平台的信息为 Node 对象添加注解和标签，例如节点所在的区域 （Region）和所具有的资源（CPU、内存等等）；
  3. 获取节点的网络地址和主机名；
  4. 检查节点的健康状况。如果节点无响应，控制器通过云平台 API 查看该节点是否已从云中禁用、删除或终止。如果节点已从云中删除， 则控制器从 Kubernetes 集群中删除 Node 对象。
• 路由控制器（Route Controller）：用于在底层云基础架构中设置路由 Route 控制器负责适当地配置云平台中的路由，以便 Kubernetes 集群中不同节点上的容器之间可以相互通信。 取决于云驱动本身，路由控制器可能也会为 Pod 网络分配 IP 地址块。
• 服务控制器（Service Controller）：用于创建、更新和删除云提供商负载均衡器 服务（Service） 与受控的负载均衡器、 IP 地址、网络包过滤、目标健康检查等云基础设施组件集成。 服务控制器与云驱动的 API 交互，以配置负载均衡器和其他基础设施组件。 你所创建的 Service 资源会需要这些组件服务。

Node

Kubernetes 通过将容器放入 Pod 以在节点上运行来运行您的工作负载。节点可能是虚拟机或物理机，具体取决于集群。每个节点都由控制平面管理，并包含运行 Pod 所需的服务。

通常，集群中有多个节点；

节点上的组件包括 kubelet、容器运行时和 kube-proxy。节点组件会在每个节点上运行，负责维护运行的 Pod 并提供 Kubernetes 运行环境。

创建Node的方式

1. 节点上的 kubelet 向控制面执行自注册；
2. 你（或者别的什么人）手动添加一个 Node 对象。

例如使用json创建Node对象：

{
  "kind": "Node",
  "apiVersion": "v1",
  "metadata": {
    "name": "10.240.79.157",
    "labels": {
      "name": "my-first-k8s-node"
    }
  }
}

Kubernetes 会在内部创建一个 Node 对象作为节点的表示。Kubernetes 检查 kubelet 向 API 服务器注册节点时使用的 metadata.name字段是否匹配。 如果节点是健康的（即所有必要的服务都在运行中），则该节点可以用来运行 Pod。 否则，直到该节点变为健康之前，所有的集群活动都会忽略该节点。

说明： Kubernetes 会一直保存着非法节点对应的对象，并持续检查该节点是否已经变得健康。 你，或者某个控制器 必须显式地删除该 Node 对象以停止健康检查操作。

Node 对象的名称必须是合法的 DNS 子域名。

Node的名称唯一性

节点的名称用来标识 Node 对象。 没有两个 Node 可以同时使用相同的名称。 Kubernetes 还假定名字相同的资源是同一个对象。 就 Node 而言，隐式假定使用相同名称的实例会具有相同的状态（例如网络配置、根磁盘内容） 和类似节点标签这类属性。这可能在节点被更改但其名称未变时导致系统状态不一致。 如果某个 Node 需要被替换或者大量变更，需要从 API 服务器移除现有的 Node 对象， 之后再在更新之后重新将其加入。

Node状态

一个节点的状态包含以下信息:

• 地址（Addresses）
  • HostName：由节点的内核报告。可以通过 kubelet 的 -hostname-override 参数覆盖。
  • ExternalIP：通常是节点的可外部路由（从集群外可访问）的 IP 地址。
  • InternalIP：通常是节点的仅可在集群内部路由的 IP 地址。
• 状况（Condition）: conditions 字段描述了所有 Running 节点的状况。
• 容量与可分配（Capacity）: capacity 块中的字段标示节点拥有的资源量。 allocatable 块指示节点上可供普通 Pod 消耗的资源量。
• 信息（Info）: Info 指的是节点的一般信息，如内核版本、Kubernetes 版（kubelet 和 kube-proxy 版本）、 容器运行时详细信息，以及节点使用的操作系统。 kubelet 从节点收集这些信息并将其发布到 Kubernetes API。

可以使用 kubectl 来查看节点状态和其他细节信息：

kubectl describe node <节点名称>

Node心跳

Kubernetes 节点发送的心跳帮助你的集群确定每个节点的可用性，并在检测到故障时采取行动。

对于节点，有两种形式的心跳:

• 更新节点的 .status
• kube-node-lease 名字空间 中的 Lease（租约）对象。 每个节点都有一个关联的 Lease 对象。与 Node 的 .status 更新相比，Lease 是一种轻量级资源。 使用 Lease 来表达心跳在大型集群中可以减少这些更新对性能的影响。 kubelet 负责创建和更新节点的 .status，以及更新它们对应的 Lease。
• 当节点状态发生变化时，或者在配置的时间间隔内没有更新事件时，kubelet 会更新 .status。 .status 更新的默认间隔为 5 分钟（比节点不可达事件的 40 秒默认超时时间长很多）。
• kubelet 会创建并每 10 秒（默认更新间隔时间）更新 Lease 对象。 Lease 的更新独立于 Node 的 .status 更新而发生。 如果 Lease 的更新操作失败，kubelet 会采用指数回退机制，从 200 毫秒开始重试， 最长重试间隔为 7 秒钟。

Node组件

• kubelet kubelet 会在集群中每个节点（node） 上运行。 它保证容器（containers） 都运行在 Pod 中。kubelet 接收一组通过各类机制提供给它的 PodSpecs， 确保这些 PodSpecs 中描述的容器处于运行状态且健康。 kubelet 不会管理不是由 Kubernetes 创建的容器。
• kube-proxy kube-proxy 是集群中每个节点（node） 所上运行的网络代理， 实现 Kubernetes 服务（Service） 概念的一部分。 kube-proxy 维护节点上的一些网络规则， 这些网络规则会允许从集群内部或外部的网络会话与 Pod 进行网络通信。如果操作系统提供了可用的数据包过滤层，则 kube-proxy 会通过它来实现网络规则。 否则，kube-proxy 仅做流量转发。
• Container Runtime（容器运行时） 容器运行环境是负责运行容器的软件。 Kubernetes 支持许多容器运行环境，例如 containerd 、 CRI-O 以及 Kubernetes CRI (容器运行环境接口) 的其他任何实现。

Addons（插件）

插件使用 Kubernetes 资源（DaemonSet、 Deployment 等）实现集群功能。 因为这些插件提供集群级别的功能，插件中命名空间域的资源属于 kube-system 命名空间。

• 联网和网络策略
  • DNS 尽管其他插件都并非严格意义上的必需组件，但几乎所有 Kubernetes 集群都应该有集群 DNS， 因为很多示例都需要 DNS 服务。 集群 DNS 是一个 DNS 服务器，和环境中的其他 DNS 服务器一起工作，它为 Kubernetes 服务提供 DNS 记录。 Kubernetes 启动的容器自动将此 DNS 服务器包含在其 DNS 搜索列表中。
  • Flannel 是一个可以用于 Kubernetes 的 overlay 网络提供者。
  • Weave Net 提供在网络分组两端参与工作的联网和网络策略，并且不需要额外的数据库。
  • … …
• 可视化管理
  • Dashboard（仪表盘） Dashboard 是 Kubernetes 集群的通用的、基于 Web 的用户界面。 它使用户可以管理集群中运行的应用程序以及集群本身， 并进行故障排除。
  • Weave Scope 是一个图形化工具， 用于查看你的容器、Pod、服务等。请和一个 Weave Cloud 账号 一起使用， 或者自己运行 UI。
• 容器资源监控 容器资源监控 将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中， 并提供浏览这些数据的界面。
• 集群层面日志 集群层面日志 机制负责将容器的日志数据保存到一个集中的日志存储中， 这种集中日志存储提供搜索和浏览接口。
• 服务发现 CoreDNS 是一种灵活的，可扩展的 DNS 服务器，可以 安装 为集群内的 Pod 提供 DNS 服务。