一、K8s的基本架构

简单来说，Kubernetes（简称 K8s）是一个用于自动化部署、扩展和管理容器化应用程序的开源平台。它的架构遵循主从模式（Master-Slave），主要由 Control Plane（控制平面） 和 Node（工作节点） 两个核心部分组成。

（一） Control Plane（控制平面/主节点）

1. API Server (kube-apiserver
) —— “唯一窗口”

它是集群的网关和枢纽。

• 作用：所有的操作（无论是你执行 kubectl
   命令，还是内部组件互相通信）都必须经过它。

• 特点：它是唯一直接与数据库（etcd）交互的组件。

2. etcd —— “集群账本”

这是一个高可用的键值数据库。

• 作用：存储了集群的所有元数据。比如：现在有多少个 Node？Pod 都跑在哪些 Node 上？配置是什么样的？

• 重要性：如果 etcd 数据丢失，集群就“失忆”了。

3. Scheduler (kube-scheduler
) —— “调度员”

它是集群的决策者。

• 作用：当有一个新的 Pod 需要运行时，它会查看各个工作节点的资源（CPU、内存）使用情况，计算出一个最优解，决定把 Pod 放到哪个节点上。

• 逻辑：它只负责“决定”，具体的“启动”动作由 Node 上的 kubelet 完成。

4. Controller Manager (kube-controller-manager
) —— “调节器”

它是集群的管家，负责维持“期望状态”。

• 作用：它运行着许多控制器（如节点控制器、副本控制器）。

• 例子：如果你设定要运行 3 个 Nginx 副本，突然有一个挂了，控制器会发现“实际状态（2个）”不等于“期望状态（3个）”，从而命令集群再起一个。

这 四个组件通常以静态Pod的形式运行在Master节点上。

什么是静态pod？
在k8s的世界里，绝大多数的Pod都是由Control Plane(控制平面，即Master节点)统一指挥并调度的。但静态Pod是由kubelet(每个节点上的“管家”进程)直接创建并管理的，而不需要API Server的干预。它们的配置文件在Master服务器的/etc/kubernets/manifests/目录下，那里会有etcd.yaml、kube-apiserver.yaml等文件。kubectl会自动扫描该目录下的文件来启动相应的pod。

引申：为什么这样设计？
这是一个“鸡生蛋，蛋生鸡”的问题：如果 Kubernetes 的核心组件（如 API Server、调度器）本身也想跑在容器里，谁来启动它们？

在集群还没完全跑起来的时候，控制平面还没上线，这时候就需要 kubelet 通过“静态 Pod”的方式，先把 API Server、etcd 这些“大脑组件”给拉起来。

“

结论：静态 Pod 主要用于在集群启动阶段托管控制平面组件。静态 Pod 是 K8s 实现“自托管”的关键——用 Pod 来跑 K8s 组件。

Control Plane的高可用

• 高可用性：在生产环境中，通常会部署 3 个或 5 个 Master 节点组成集群，以防止单点故障导致整个集群瘫痪。

• 管理与业务分离：Master 节点通常不运行用户的应用程序。这样做是为了保证管理平面有足够的资源，且不会受到应用程序故障的影响。

（二）Node（工作节点）

工作节点是实际运行应用程序（容器）的地方。一个集群通常有多个 Node。

1. kubelet

• 节点上的代理，负责管理本机 Pod
• 与 apiserver 通信，上报节点状态
• 管理 Pod 生命周期、健康检查

2. kube-proxy

• 维护节点网络规则，实现 Service 负载均衡
• 负责集群内部网络通信、Service 代理

3. 容器运行时（Container Runtime）

• 负责运行容器，如：containerd、Docker、CRI-O

(三) 组件之间协作关系

• 1.用户通过 kubectl
   发送指令给 API Server。

• 2.API Server 将信息存入 etcd。

• 3.Scheduler 发现新任务，挑选一个合适的 Node。

• 4.目标 Node 上的 kubelet 接到指令，调用 Container Runtime 启动容器。

• 5.kube-proxy 配置网络，确保应用可以被访问。

二、K8s中的核心对象与层次

（一）整体层次结构（从上到下）

反应了资源容纳关系

• Cluster（集群）：物理边界（所有的机器、网络、存储）
• Namespace（命名空间）: 逻辑边界（用来隔离团队、项目或环境）
• Workload（工作负载）：一类管理Pod的控制器统称 Deployment StatefulSet DaemonSet Job CronJob
• ReplicaSet / ReplicationController（副本集）：保证副本数量
• Pod（最小调度单元）：逻辑主机（K8s 的最小调度单位，共享网络和存储）。
• Container（容器）：运行环境（真正的业务进程）。
  
  

常见 Workload 及其含义：

1. Deployment

   最常用，管无状态应用（Web、API、微服务） → 保证跑 N 个副本，挂了自动重建，支持更新回滚。

2. StatefulSet

   管有状态应用（数据库、MQ、主从服务） → Pod 名字固定、顺序启动、稳定网络、稳定存储。

3. DaemonSet

   每台机器必须跑一个（监控、日志采集、网络插件） → 加节点自动多一个，删节点自动少一个。

4. Job

   一次性任务（数据导出、计算、备份） → 跑完就结束，不常驻。

5. CronJob

   定时任务（每天备份、每小时统计） → 按时间自动触发 Job。

层级关系：

Workload（控制器） → ReplicaSet → Pod → 容器

• 你操作：Deployment
• 它自动创建：ReplicaSet（管副本数）
• 最终真正运行：Pod
• 里面是：容器

（二）核心对象分类

1. 工作负载型（运行应用）

• Pod：最小调度单元，包含一个或多个容器
• Deployment：管理无状态应用，支持滚动更新、回滚
• StatefulSet：管理有状态应用（有序、稳定网络、持久存储）
• DaemonSet：每个节点只运行一个 Pod
• Job：一次性任务
• CronJob：定时任务

2. 发现与负载均衡型

• Service：为 Pod 提供稳定访问入口与 4 层负载均衡
• Ingress：7 层 HTTP/HTTPS 入口，域名路由

3. 配置与存储型

• ConfigMap：普通配置
• Secret：敏感信息（密码、密钥）
• PersistentVolume--PV：持久化存储
• PersistentVolumeClaim--PVC：存储使用申请

4. 安全与权限

• ServiceAccount：服务账号
• Role/ClusterRole：权限集合
• RoleBinding/ClusterRoleBinding：权限绑定

总结：

“

K8s 以集群为顶层，通过 Namespace 做资源隔离；使用 Deployment 等控制器管理 Pod；Pod 包含容器；通过 Service、Ingress 对外提供访问；用 ConfigMap/Secret/PV/PVC 管理配置与存储，并通过 RBAC 做权限控制。