概览

1. 控制面组件 (Control Plane / Master Node)

负责全局的决策和状态管理。

• kube-apiserver: 集群的统一入口。所有的交互（无论是通过命令行工具 kubectl 还是内部各组件之间的通信）都必须经过 API Server。在后续的安全视角中，这里通常是最高价值的攻击面之一，因为只要能向它发送未授权的恶意指令，就能接管集群。
• etcd: 高可用的键值存储数据库。它保存了集群的所有配置数据和实时状态信息。如果未经授权读取了 etcd 的数据，集群内的各类凭证（Secret）都会暴露。
• kube-scheduler: 负责资源调度。它会监听新创建但尚未分配目标节点的任务，并根据资源需求（CPU、内存限制）将其分配到最合适的节点上。
• kube-controller-manager: 负责维护集群的“期望状态”。K8s 是声明式的，当你声明需要 3 个应用实例时，如果某个节点宕机导致只剩 2 个，控制器会立刻发现差异，并在健康的节点上重新拉起一个新的实例。

2. 数据面组件 (Worker Node)

负责运行实际的业务代码和容器。

• kubelet: 运行在每个节点上的核心代理（Agent）。它直接与 API Server 保持通信，接收指令并调用本机的容器引擎，确保分配到该节点的容器处于正确的运行状态。
• kube-proxy: 负责节点上的网络路由规则。它维护着系统的 iptables 或 IPVS 规则，实现集群内部的服务发现和流量负载均衡。
• Container Runtime: 容器运行时环境（如 containerd 或 Docker），负责真正拉取镜像并启动容器进程。

基础资源对象 (K8s Objects)

在 K8s 中，所有的操作都是通过声明式的配置文件（通常是 YAML 格式）来定义资源对象。以下是最基础的三个概念：

• Pod (最小调度单元): K8s 不直接管理容器，而是管理 Pod。一个 Pod 可以包含一个或多个紧密相关的容器。它们共享网络命名空间（即共享同一个 IP 和端口空间）和存储卷。例如，主容器运行业务代码，而同一 Pod 内的另一个辅助容器负责收集日志。
• Deployment (部署控制器): 开发者通常不会直接创建 Pod。Deployment 用于管理无状态应用，它控制着 Pod 的副本数量、滚动更新以及版本回滚。
• Service (服务发现): 因为 Pod 的生命周期是短暂的（销毁重建后 IP 会变），如果直接通过 IP 访问 Pod 是不可靠的。Service 提供了一个稳定的虚拟 IP 和 DNS 名称，将流量自动路由并负载均衡到后端的多个动态 Pod 上。

设计理念

API 设计原则

所有 API 都应该是声明式，API 对象是彼此互补且可组合的

低层 API 根据高层 API 的控制需要设计

• 目的在于减少冗余并提高代码和逻辑的重用性。

尽量避免简单封装

• 不要存在外部 API 无法显式感知的内部隐藏机制。内部隐藏机制是非常不利于系统长期维护的设计方式。

API 操作复杂度应与对象数量成正比

• 通过控制复杂度，保证整个系统随着规模的不断扩大，性能不会迅速衰退到无法使用的地步。

API 对象状态不能依赖于网络连接状态

• 在分布式环境下，为了应对网络的不稳定和分区容错，必须保证 API 对象的状态不与底层的网络连接状态强绑定。

尽量避免操作机制依赖于全局状态

• 在分布式系统中，保证全局状态的实时强同步是非常困难且代价极高的。