屏杜趾曰1. k8s 架构

K8s 采用传统的主从架构（Master-Slave 架构），由 Master 和 Node 节点组成：

Master 节点：承担集群管理职责，协调集群内的所有活动。例如应用的启动、调整、升级等。

Node 节点：作为 Kubernetes 集群的工作单元，可以是虚拟机或实体机。每个节点配备有 Kubelet（监控每个节点的状态，并与 Master 节点沟通，执行 Master 下达的任务），同时，每个 Node 节点还需运行容器运行环境（如 docker，以支持镜像的运行）。

简化的架构图如下所示：

[此处为图片1]

完整的架构图如下所示，其中 Node 中的 pod 可以视为承载应用程序的容器，例如运行 Java 的一个微服务 jar 包，其他组件将在后续详细说明。

[此处为图片1]

2. Master 节点

Master节点相当于整个k8s的核心

[此处为图片1]

Master 节点又称为控制平面组件，即上图中红色标记的部分。Master 节点通常由以下部分构成：

kube-apiserver：提供 RESTful API 接口，供用户、kubectl 工具、其他组件及外部系统调用。它是无状态的，支持水平扩展，通常部署多个实例以确保高可用性。

etcd：一个分布式的键值存储库，保存集群的所有配置数据和状态信息（如节点、Pod、Service 等对象的状态，配置文档）。所有组件通过 apiserver 访问 etcd，不直接操作。通常部署多节点，使用 Raft 协议确保一致性。

kube-scheduler：负责 Pod 的分配，确定新生成的 Pod 应该部署在哪一个 Node 上。

kube-controller-manager（图中 c-m）：运行控制器过程，确保集群的实际情况与预期相符。这可能听起来有些抽象，但实际上可以将其比作一个管家，它持续监控集群的“实际情况”，并努力使其与用户设定的“预期”一致。例如，我希望我的集群中有 3 个 nginx pod 正常运行（通过配置文件指定），若其中一个 pod 出现故障，kube-controller-manager 就会启动一个新的 pod，流程如下：

1. c-m 从 apiserver 获取“预期状态”（例如 replicas: 3）
2. 从 apiserver 获取“当前状态”（例如目前仅有 2 个 Pod 运行）
3. 如果两者不符 → 执行相应操作（例如创建 1 个新的 Pod）
4. 更新 apiserver 的状态记录
5. 稍作休息，然后重复上述 1～5 步骤

cloud-controller-manager（图中 c-c-m）：充当 Kubernetes 与基础云平台（如 AWS、Azure、阿里云等）之间的“翻译”和“中介”，专门处理需与云供应商 API 交互的功能。

3. Node 节点

既然了解了 Master 节点，那么 Node 节点是什么呢？Node 节点（也可称作 Worker 节点），是实际“执行应用”的工作者。在现实中，Node 节点可以是一台物理服务器，也可以是一台虚拟机（每个 Node 节点严格对应一个“计算实例”），但需注意，Node 节点并不是容器（Node 是容器运行的宿主）。下图中，红色框内的内容即为 Node 节点。

[此处为图片1]

Node 节点主要包含以下几个组件：

kubelet：负责与 Master 交流、接收调度指令、调用容器运行时启动或结束 Pod，并定期向 api-server 报告节点和容器的健康状况。执行探测，挂载卷，配置网络等任务。每个 node 都必须安装一个 kubelet。

Container Runtime（容器运行时）：依据 kubelet 的命令，下载镜像、创建/启动/停止容器，管理容器的生命周期。简单来说，你可以把它想象成一个 docker，能够运行各种镜像。

kube-proxy：在每个 Node 上维护网络规则（如 iptables 或 IPVS），将请求流量（Service 的流量）转发至后端 Pod。每个 Node 都需要运行 kube-proxy，因为如果一个容器无法与外界通信，那它就失去了意义。

cAdvisor：自动检测并收集当前 Node 节点上所有容器（包括 Pod 内的容器）的资源消耗和性能指标，如 CPU、内存、磁盘 I/O、网络带宽等。

4. 命名空间

k8s 集群在搭建完成后，需向多个部门或小组提供使用。在我们的开发与生产流程中，不同小组很可能使用相同名称的资源（比如应用、服务），并且各小组所需的计算资源量可能不一，同时各小组的权限也存在差异（比如开发团队无权访问生产环境）。为解决这些问题，k8s 引入了命名空间（namespace）的概念（默认命名空间为 default），命名空间具有以下优势：

• 资源隔离
  不同命名空间内的资源名称可以相同（例如，两个命名空间中均可存在名为 web-app 的 Deployment）。
• 避免资源命名冲突
• 限制资源使用（配合 ResourceQuota 和 LimitRange 使用）
• 权限管理（RBAC）
  可以为不同的命名空间设定不同的访问权限。例如：开发团队仅能访问 dev 命名空间，而运维团队则可访问 prod。
• 环境隔离
  将开发（dev）、测试（test）、预发布（staging）、生产（prod）环境分别部署在不同的命名空间中，有助于管理。
• 简化管理
  可以依据命名空间批量操作资源（如删除整个命名空间及其所有资源）。
• 日志、监控、网络策略等也可根据命名空间维度进行配置