【AI 总结】Kubernetes 架构

Kubernetes 架构 | AI 总结

Kubernetes 集群由控制平面和工作节点（Node）构成，每个集群至少需一个工作节点运行 Pod。工作节点托管应用负载的 Pod，控制平面管理集群中的工作节点和 Pod。生产环境中，控制平面通常跨多台计算机运行，集群多节点运行以实现容错和高可用。

控制平面组件

  1. kube-apiserver
    • 是控制平面组件，负责公开 Kubernetes API，处理请求，是控制平面的前端。
    • 设计考虑水平扩缩，可部署多个实例并平衡流量，主要实现为 kube-apiserver。
  2. etcd
    • 一致且高可用的键值存储，作为 Kubernetes 所有集群数据的后台数据库。
    • 使用 etcd 作为后台数据库时，需制定数据备份计划，官方文档有其深入知识。
  3. kube-scheduler
    • 监控新创建、未指定运行节点的 Pod，选择节点让 Pod 运行。
    • 调度决策需考虑多种因素，如 Pod 资源需求、软硬件及策略约束、亲和性及反亲和性规范等。
  4. kube-controller-manager
    • 运行控制器进程，从逻辑上每个控制器是单独进程，但为降低复杂性，编译到同一可执行文件并在同一进程运行。
    • 包含多种控制器，如 Node 控制器（节点故障时通知响应）、Job 控制器（监测 Job 对象并创建 Pod 运行任务）等。
  5. cloud-controller-manager
    • 嵌入特定云平台控制逻辑，使集群连接云提供商 API，分离与云平台和集群交互的组件。
    • 仅运行云平台特定控制器，如 Node 控制器（检查云平台确定节点是否删除）、Route 控制器（设置底层云架构路由）等，非云环境集群可不包含。

节点组件

  1. kubelet：在集群每个节点运行，保证容器在 Pod 中运行，接收 PodSpec 并确保容器运行且健康，不管理非 Kubernetes 创建的容器。
  2. kube-proxy：节点上的网络代理，实现 Service 概念部分功能，维护节点网络规则以实现网络会话与 Pod 通信，若网络插件提供等效功能可不用。
  3. 容器运行时：管理容器执行和生命周期，使 Kubernetes 有效运行容器，支持 containerd、CRI-O 等及其他 Kubernetes CRI 实现。

插件（Addons）

插件借助 Kubernetes 资源（如 DaemonSet、Deployment）实现集群功能，命名空间域资源属 kube-system 命名空间，主要包括：

  1. DNS：多数集群必备，为 Kubernetes 服务提供 DNS 记录，容器自动将其纳入 DNS 搜索列表。
  2. Web 界面（仪表盘）：通用 Web 用户界面，方便用户管理集群应用和集群本身，进行故障排除。
  3. 容器资源监控：收集容器时序度量值存入集中数据库，提供数据浏览界面。
  4. 集群层面日志：将容器日志数据保存到集中日志存储，提供搜索和浏览接口。
  5. 网络插件：实现容器网络接口（CNI）规范，为 Pod 分配 IP 并实现 Pod 间通信。

在 Kubernetes (K8s) 集群中，DNS（通常由 CoreDNS 实现）是一项核心的基础设施服务，它的主要作用是服务发现（Service Discovery）。

简单来说，它的工作原理和意义如下：

1. 为什么需要它？

在 K8s 中，Pod 的 IP 地址是动态的（重启后会变）。为了让一个应用能稳定地找到另一个应用，我们通常使用 Service。DNS 的作用就是将 Service 的名字 自动解析成它对应的 Cluster IP。

2. 它如何工作？

  • 自动注册：当你创建一个 Service 时，K8s 会自动在集群的 DNS 系统中添加一条记录。
  • 自动配置：集群中运行的每一个容器，其 /etc/resolv.conf 文件都会被 K8s 自动配置，指向集群内部的 DNS 服务器。
  • 透明访问：应用只需要通过 Service 的名称（例如 my-service）就能访问对方，而不需要关心背后的 IP 地址。

3. 常见的域名格式

在集群内部，你可以使用完整的域名（FQDN）来访问服务，格式通常为：
<服务名>.<命名空间>.svc.cluster.local

例如：

  • 如果你的服务叫 mysql，在同一个命名空间下，直接访问 mysql 即可。
  • 如果在不同的命名空间（如 dev），则可以通过 mysql.dev 访问。

总结

它是 “多数集群必备” 的插件。没有 DNS，Pod 之间就只能通过不稳定的 IP 地址通信，这会让集群的管理和微服务架构变得极其困难。

架构变种

  1. 控制平面部署选项：有传统部署（组件直接在专用机器 / 虚拟机运行，多为 systemd 服务）、静态 Pod（组件为静态 Pod，由特定节点 kubelet 管理，kubeadm 常用）、自托管（控制平面在集群内作为 Pod 运行，由 Kubernetes 原语管理）、托管 Kubernetes 服务（云平台管理控制平面组件）四种方式。
  2. 工作负载调度说明：小或开发集群中控制平面组件与用户工作负载可能同节点；大生产集群常将节点专用于控制平面组件；部分组织在控制平面节点运行关键组件或监控工具，调度因集群大小、性能要求等不同。
  3. 集群管理工具：如 kubeadm、kops、Kubespray 等，各有不同部署和管理方法及组件布局。
  4. 定制和可扩展性：可部署自定义调度器（协同或替换默认）、扩展 API 服务器（通过 CustomResourceDefinition 和 API 聚合）、利用 cloud-controller-manager 实现云平台与 Kubernetes 深度集成，方便组织按需调整集群。
K8s
#K8s #架构
【AI 总结】Kubernetes 架构
https://blog.lllllan.cn/k8s/concepts/architecture/
作者
lllllan
发布于
2026年1月8日
许可协议