目录
2.3 Controller Manager：集群的"管家"
3.3 Container Runtime：真正的"搬砖工"
从Node到Pod到Container：一口吃透K8s资源层次
你是否遇到过Pod一直卡在Pending状态、Worker节点突然失联、Master宕机后整个集群抓瞎的崩溃时刻？Kubernetes架构看似复杂，其实只要理解了这几个核心组件，你也能成为"集群急救医生"。本文将从原理到实战，吃透K8s的核心神经系统。
一、Kubernetes架构全景图：大脑与四肢的协作
想象一下，Kubernetes集群就像一个精密运转的工厂：
- • 控制平面（Control Plane） = 工厂的管理层（总经理、调度员、财务总监）
- • 工作节点（Worker Node） = 工厂的生产车间
- • Pod = 车间里的生产线
- • Container = 生产线上的具体工人
先来看一张ASCII架构图，让你对整体结构一目了然：
┌─────────────────────────────────────────────────────────────────┐
│ 控制平面 (Control Plane) │
│ ┌─────────────────┐ │
│ │ API Server │ ← 所有请求的"总闸门" │
│ └────────┬────────┘ │
│ ┌──────────────────┼──────────────────┐ │
│ ▼ ▼ ▼ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Scheduler │ │ etcd │ │ Controller │ │
│ │ (调度器) │ │ (数据存储) │ │ Manager │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ ▲ │
└──────────────────────────────────────────────────────┼──────────┘
│
┌──────────────────────────────────┘
│ HTTPS (6443端口)
▼
┌─────────────────────────────────────────────────────────────────┐
│ 工作节点 (Worker Node) │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Kubelet │ │
│ │ (节点的"监工"，汇报状态) │ │
│ └─────────────────────────┬───────────────────────────────┘ │
│ │ │
│ ┌────────────────┼────────────────┐ │
│ ▼ ▼ ▼ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Kube Proxy │ │ Pod 1 │ │ Pod 2 │ │
│ │ (网络代理) │ │ ┌─────────┐ │ │ ┌─────────┐ │ │
│ └─────────────┘ │ │Container│ │ │ │Container│ │ │
│ │ └─────────┘ │ │ └─────────┘ │ │
│ └─────────────┘ └─────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Container Runtime (containerd/Docker) │ │
│ │ 真正运行容器的"搬砖工" │ │
│ └─────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
💡 效率技巧：记住这张图，面试时画出来，面试官会觉得你"有点东西"。
二、控制平面：集群的大脑
控制平面是整个Kubernetes集群的"大脑"，负责做出所有决策。如果大脑挂了，整个集群就会陷入"植物人"状态——虽然节点还在运行已有的Pod，但无法进行任何新的调度操作。
2.1 API Server：所有请求的"总闸门"
API Server是Kubernetes的"门面担当"，所有操作（无论是kubectl命令、控制器还是调度器）都必须通过它。
它的核心职责：
- 1. 认证与授权：验证你是谁，你能做什么
- 2. 数据校验：检查你提交的YAML有没有语法错误
- 3. 状态存储：把资源定义写入etcd
- 4. 事件通知：告诉其他组件"有新活儿了"
# 示例：通过API Server创建Pod的请求流程
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
spec:
containers:
- name: nginx
image: nginx:1.21
ports:
- containerPort: 80
⚠️ 避坑警告：API Server默认监听6443端口，千万不要直接暴露到公网！2023年就有团队因为把API Server暴露在公网，结果被黑客挖矿，账单直接飙到几万刀。
查看API Server状态的命令：
# 检查API Server是否健康
curl -k https://localhost:6443/healthz
# 查看API Server的日志
kubectl logs -n kube-system kube-apiserver-<节点名>
# 查看当前API Server的端点
kubectl get endpoints kubernetes -o yaml
2.2 Scheduler：Pod的"红娘"
Scheduler的职责很简单：给Pod找一个合适的Node安家。
它的工作流程就像相亲：
- 1. 过滤阶段（Filtering）：排除不符合条件的节点（比如资源不够、有污点）
- 2. 打分阶段（Scoring）：给剩下的节点打分，选出最优解
- 3. 绑定阶段（Binding）：把Pod和Node"绑定"在一起
Scheduler调度流程：
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ 过滤阶段 │ ──▶ │ 打分阶段 │ ──▶ │ 绑定阶段 │
└─────────────┘ └─────────────┘ └─────────────┘
│ │ │
▼ ▼ ▼
排除不符合的 给剩余节点 更新Pod的
节点（如内存 打分排序 nodeName字段
不足、有污点） （资源余量、 写入etcd
亲和性等）
💡 效率技巧：Scheduler支持自定义调度策略，你可以根据业务需求编写自己的调度器。比如让GPU任务优先调度到带GPU的节点。
查看Scheduler日志：
# 查看Scheduler的调度决策日志
kubectl logs -n kube-system kube-scheduler-<节点名> | grep "Scheduling"
# 查看Pod的调度事件
kubectl describe pod <pod-name> | grep -A 10 Events
2.3 Controller Manager：集群的"管家"
Controller Manager是一堆控制器的集合，每个控制器负责一种资源的状态维护：
| 控制器 | 职责 | 类比 |
|---|---|---|
| Deployment Controller | 维护Deployment的期望副本数 | 人力资源经理 |
| ReplicaSet Controller | 确保Pod副本数正确 | 生产线班长 |
| Node Controller | 监控节点健康状态 | 车间主任 |
| Service Controller | 管理Service的Endpoints | 前台接待 |
| EndpointSlice Controller | 维护EndpointSlice | 通讯录管理员 |
这些控制器的核心逻辑都是一个无限循环：
观察当前状态 ──▶ 对比期望状态 ──▶ 执行调整操作 ──▶ 回到观察
▲ │
└───────────────────────────────────────────────┘
幽默一刻：Controller Manager就像一个强迫症晚期的管家，看到Deployment说要3个Pod，实际只有2个，立马给你创建一个；看到节点失联了，立马把上面的Pod标记为需要重新调度。它永远不会累，也永远不会下班。
2.4 etcd：唯一的"真理之源"
etcd是Kubernetes的"记忆中枢"，所有集群状态都存储在这里。它是整个集群的Single Source of Truth。
etcd存储的关键数据：
- • 所有API对象（Pod、Service、Deployment等）
- • 集群配置信息
- • 节点状态信息
- • 密钥和敏感数据（如果启用了加密）
etcd数据层次结构（简化版）：
/registry/
├── pods/
│ ├── default/
│ │ └── nginx-pod
│ └── kube-system/
│ └── coredns-xxx
├── deployments/
│ └── default/
│ └── my-app
├── nodes/
│ ├── node-1
│ ├── node-2
│ └── node-3
└── configmaps/
└── default/
└── app-config
⚠️ 避坑警告：etcd是集群的"命门"！如果etcd数据损坏或丢失，整个集群的状态就全没了。务必做好etcd的定期备份！
# 备份etcd数据
ETCDCTL_API=3 etcdctl snapshot save backup.db \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key
# 恢复etcd数据
ETCDCTL_API=3 etcdctl snapshot restore backup.db \
--data-dir=/var/lib/etcd-backup
三、工作节点：干活的"打工人"
如果说控制平面是大脑，那工作节点就是四肢。它们负责真正运行容器化的应用。
3.1 Kubelet：节点的"监工"
Kubelet运行在每个工作节点上，是节点的"监工"，负责：
- 1. 接收指令：从API Server接收PodSpec（Pod定义）
- 2. 管理容器：通过Container Runtime启动、停止容器
- 3. 健康检查：执行livenessProbe和readinessProbe
- 4. 状态上报：定期向API Server汇报节点和Pod状态
Kubelet工作流程：
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ 监听API │ │ 调用CRI │ │ 上报状态 │
│ Server │ ──▶ │ 创建容器 │ ──▶ │ 到API │
└─────────────┘ └─────────────┘ └─────────────┘
│ │ │
▼ ▼ ▼
获取Pod定义 containerd/ 节点状态
解析PodSpec Docker执行 Pod状态
容器操作 容器状态
查看Kubelet状态：
# 查看Kubelet服务状态
systemctl status kubelet
# 查看Kubelet日志
journalctl -u kubelet -f
# 查看节点详细信息
kubectl describe node <node-name>
💡 效率技巧：如果Pod状态一直是ContainerCreating，多半是Kubelet和Container Runtime之间的通信出了问题。检查/var/log/pods/目录下的日志能快速定位问题。
3.2 Kube Proxy：网络的"交警"
Kube Proxy负责实现Kubernetes的Service网络，是集群内部的"交警"，指挥流量该往哪走。
它的核心职责：
- 1. 维护网络规则：在节点上配置iptables/IPVS规则
- 2. 实现Service：把Service的虚拟IP映射到后端Pod
- 3. 负载均衡：在多个Pod之间分发流量
Service流量转发示意图：
用户请求
│
▼
┌───────────────┐
│ Service IP │ 10.96.0.1:80
│ (虚拟IP) │
└───────┬───────┘
│
▼
┌───────────────┐
│ Kube Proxy │ iptables/IPVS规则
│ (负载均衡) │
└───────┬───────┘
│
┌───┴───┐
▼ ▼
┌──────┐ ┌──────┐
│ Pod1 │ │ Pod2 │
│:8080 │ │:8080 │
└──────┘ └──────┘
Kube Proxy的三种模式：
| 模式 | 原理 | 适用场景 |
|---|---|---|
| iptables | 使用iptables规则转发 | 默认模式，小规模集群 |
| ipvs | 使用IPVS内核模块 | 大规模集群，性能更好 |
| userspace | 用户空间代理（已废弃） | 不推荐 |
# 查看Kube Proxy使用的模式
kubectl get configmap kube-proxy -n kube-system -o yaml | grep mode
# 查看当前节点的iptables规则（查看Service转发）
iptables -t nat -L KUBE-SERVICES -n | head -20
3.3 Container Runtime：真正的"搬砖工"
Container Runtime是真正运行容器的组件，Kubelet通过CRI（Container Runtime Interface）与它通信。
主流Container Runtime对比：
| Runtime | 特点 | 现状 |
|---|---|---|
| Docker | 最流行，生态丰富 | Kubernetes 1.24+ 移除dockershim |
| containerd | 轻量、高效，Docker底层也用 | 推荐使用 |
| CRI-O | 专为K8s设计，红帽主推 | OpenShift默认 |
CRI调用流程：
Kubelet ──CRI(gRPC)──▶ containerd ──▶ runc ──▶ Linux容器
│
▼
containerd-shim
(管理容器生命周期)
查看Container Runtime信息：
# 查看节点使用的Runtime
kubectl get nodes -o wide
# 查看containerd状态
systemctl status containerd
# 使用crictl查看容器（containerd的CLI工具）
crictl ps
crictl pods
crictl logs <container-id>
⚠️ 避坑警告：Kubernetes 1.24版本正式移除了dockershim，如果你还在用Docker作为Runtime，要么升级到containerd，要么安装cri-dockerd适配器。
四、Scheduler调度全流程：从Pod到运行的奇妙旅程
让我们详细拆解一个Pod从创建到运行的完整调度流程：
Pod调度全流程时序图：
用户 kubectl API Server etcd Scheduler Kubelet Container Runtime
│ │ │ │ │ │ │
│ 1.提交YAML │ │ │ │ │ │
│─────────────▶│ │ │ │ │ │
│ │ 2.创建Pod │ │ │ │ │
│ │───────────────▶│ │ │ │ │
│ │ │ 3.写入etcd │ │ │ │
│ │ │──────────────▶│ │ │ │
│ │ │ │ │ │ │
│ │ │ 4.返回成功 │ │ │ │
│ │ │◀──────────────│ │ │ │
│ │◀───────────────│ │ │ │ │
│◀─────────────│ │ │ │ │ │
│ │ │ 5.通知Watcher│ │ │ │
│ │ │───────────────┼─────────────▶│ │ │
│ │ │ │ │ │ │
│ │ │ │ 6.查询未调度Pod │ │
│ │ │◀──────────────┼──────────────│ │ │
│ │ │ │ │ │ │
│ │ │ 7.过滤+打分 │ │ │ │
│ │ │ │ (选择最佳节点) │ │
│ │ │ │ │ │ │
│ │ │ 8.绑定Pod到节点 │ │ │
│ │ │◀──────────────┼──────────────│ │ │
│ │ │ │ │ │ │
│ │ │ 9.写入etcd │ │ │ │
│ │ │──────────────▶│ │ │ │
│ │ │ │ │ │ │
│ │ │ 10.通知目标节点的Kubelet │ │ │
│ │ │───────────────┼──────────────┼──────────────▶│ │
│ │ │ │ │ │ │
│ │ │ │ │ 11.调用CRI创建容器 │
│ │ │ │ │──────────────▶│ │
│ │ │ │ │ │ │
│ │ │ │ │ 12.启动容器 │ │
│ │ │ │ │───────────────┼───────────────▶│
│ │ │ │ │ │ │
│ │ │ │ 13.上报状态 │ │ │
│ │ │◀──────────────┼──────────────┼───────────────┼───────────────│
│ │ │ │ │ │ │
│ │ │ 14.更新Pod状态 │ │ │
│ │ │──────────────▶│ │ │ │
关键时间点：
| 阶段 | 耗时 | 说明 |
|---|---|---|
| 1-4 | < 100ms | API Server写入etcd |
| 5-9 | < 1s | Scheduler调度决策 |
| 10-14 | 2-30s | 拉取镜像+启动容器 |
💡 效率技巧：Pod调度时间通常小于1秒，但如果镜像很大，拉取镜像可能占大部分时间。使用镜像缓存或本地镜像仓库能显著加速启动。
五、etcd深度解析：为什么它是集群的"命门"
etcd是CoreOS开发的分布式键值存储，使用Raft共识算法保证数据一致性。它是Kubernetes的"大脑皮层"，没有它，集群就失忆了。
etcd的核心特性
etcd架构图：
┌─────────────────────────────────────────┐
│ etcd Cluster │
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ │ Node 1 │◀─▶│ Node 2 │◀─▶│ Node 3 │
│ │(Leader) │ │(Follower│ │(Follower│
│ └────┬────┘ └─────────┘ └─────────┘
│ │ │
│ ▼ 写入请求 │
│ ┌─────────┐ │
│ │ WAL日志 │ ← 持久化存储 │
│ └─────────┘ │
│ │ │
│ ▼ │
│ ┌─────────┐ │
│ │ BoltDB │ ← 键值数据存储 │
│ └─────────┘ │
└─────────────────────────────────────────┘
etcd的关键数据指标：
- • 写入延迟：< 10ms（本地SSD）
- • 读取延迟：< 1ms
- • QPS：10,000+（单节点）
- • 数据一致性：强一致性（Linearizable Read）
Raft共识算法简介
Raft是etcd使用的分布式一致性算法，核心思想是**"少数服从多数"**：
Raft节点状态转换：
┌─────────────┐
│ Follower │◀────────────────┐
│ (跟随者) │ │
└──────┬──────┘ │
│ 选举超时 │
▼ │
┌─────────────┐ 发现更高任期 │
│ Candidate │─────────────────┘
│ (候选人) │
└──────┬──────┘
│ 获得多数票
▼
┌─────────────┐
│ Leader │
│ (领导者) │
└─────────────┘
幽默一刻：Raft就像一个班级选班长。Follower是普通学生，Candidate是举手说"我要当班长"的人，Leader就是选出来的班长。如果班长失联了（心跳超时），大家重新选举。如果同时有多个人举手，就按"谁先举手谁优先"的规则来。
etcd高可用配置
⚠️ 避坑警告：etcd集群节点数必须是奇数！因为Raft需要多数派同意才能写入，偶数节点既不能提高容错能力，又浪费资源。
| 节点数 | 可容忍故障 | 说明 |
|---|---|---|
| 1 | 0 | 单点，仅测试使用 |
| 3 | 1 | 生产环境最低配置 |
| 5 | 2 | 大型集群推荐 |
| 7 | 3 | 超大规模集群 |
# 查看etcd集群健康状态
ETCDCTL_API=3 etcdctl endpoint health \
--endpoints=https://192.168.1.10:2379,https://192.168.1.11:2379,https://192.168.1.12:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key
# 查看etcd集群成员
ETCDCTL_API=3 etcdctl member list -w table
# 查看etcd数据库大小
ETCDCTL_API=3 etcdctl endpoint status -w table
六、高可用方案：Master节点不能"单点故障"
生产环境的Kubernetes集群必须实现高可用，否则Master一挂，整个集群就"脑死亡"了。
高可用架构图
K8s高可用架构（3 Master节点）：
┌─────────────┐
│ Load │
│ Balancer │ ← 可以是云LB、Nginx、Keepalived
│ (VIP) │
└──────┬──────┘
│
┌───────────────┼───────────────┐
│ │ │
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Master 1 │ │ Master 2 │ │ Master 3 │
│ ┌─────────┐ │ │ ┌─────────┐ │ │ ┌─────────┐ │
│ │API Server│ │ │ │API Server│ │ │ │API Server│ │
│ └─────────┘ │ │ └─────────┘ │ │ └─────────┘ │
│ ┌─────────┐ │ │ ┌─────────┐ │ │ ┌─────────┐ │
│ │Scheduler│ │ │ │Scheduler│ │ │ │Scheduler│ │
│ │(Active) │ │ │(Standby) │ │ │(Standby) │ │
│ └─────────┘ │ │ └─────────┘ │ │ └─────────┘ │
│ ┌─────────┐ │ │ ┌─────────┐ │ │ ┌─────────┐ │
│ │Controller│ │ │ │Controller│ │ │ │Controller│ │
│ │(Active) │ │ │(Standby) │ │ │(Standby) │ │
│ └─────────┘ │ │ └─────────┘ │ │ └─────────┘ │
│ ┌─────────┐ │ │ ┌─────────┐ │ │ ┌─────────┐ │
│ │ etcd │◀│▶│ │ etcd │◀│▶│ │ etcd │ │
│ │(Leader) │ │ │ │(Follower│ │ │ │(Follower│ │
│ └─────────┘ │ │ └─────────┘ │ │ └─────────┘ │
└─────────────┘ └─────────────┘ └─────────────┘
关键高可用组件
| 组件 | 高可用方案 | 说明 |
|---|---|---|
| API Server | 多实例+负载均衡 | 无状态，可水平扩展 |
| Scheduler | 多实例+Leader Election | 同一时间只有一个工作 |
| Controller Manager | 多实例+Leader Election | 同一时间只有一个工作 |
| etcd | Raft集群（3/5/7节点） | 强一致性存储 |
Leader Election机制：
Scheduler和Controller Manager通过Kubernetes的Lease API实现Leader Election：
# 查看当前的Leader
kubectl get leases -n kube-system
# 查看Scheduler的Leader
kubectl get leases kube-scheduler -n kube-system -o yaml
# 查看Controller Manager的Leader
kubectl get leases kube-controller-manager -n kube-system -o yaml
💡 效率技巧：如果你看到多个Scheduler或Controller Manager都在"工作"，那一定是Leader Election出了问题，赶紧检查！
七、实战：排查Pod卡在Pending的问题
Pod卡在Pending是最常见的K8s问题之一。让我们用学到的架构知识来排查。
排查流程图
Pod Pending排查流程：
开始排查
│
▼
┌─────────────────┐
│ kubectl describe│
│ pod <name> │
└────────┬────────┘
│
▼
查看Events
│
┌────┴────┐
▼ ▼
有错误信息 无错误信息
│ │
▼ ▼
根据错误 检查资源
排查 │
┌────┴────┐
▼ ▼
资源不足 节点问题
│ │
▼ ▼
扩容节点 检查污点
或清理Pod 和标签
常见Pending原因及解决方案
# 1. 查看Pod详细状态和事件
kubectl describe pod <pod-name>
# 2. 常见错误1：没有可调度的节点（No nodes are available）
# 原因：资源不足、污点不匹配、节点选择器不匹配
# 解决：
kubectl top nodes # 查看节点资源使用
kubectl get nodes --show-labels # 查看节点标签
kubectl describe node <node-name> # 查看节点污点
# 3. 常见错误2：PVC未绑定
# 原因：StorageClass问题、PV不足
# 解决：
kubectl get pvc # 查看PVC状态
kubectl describe pvc <pvc-name> # 查看PVC事件
# 4. 常见错误3：镜像拉取失败
# 原因：镜像不存在、认证失败、网络问题
# 解决：
kubectl get events --field-selector reason=FailedPullImage
# 5. 查看Scheduler日志
kubectl logs -n kube-system -l component=kube-scheduler
实战案例：Pod一直Pending
# 场景：部署了一个Pod，但一直Pending
$ kubectl get pod my-app-xxx
NAME READY STATUS RESTARTS AGE
my-app-xxx 0/1 Pending 0 5m
# 第一步：查看Pod事件
$ kubectl describe pod my-app-xxx
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 30s default-scheduler 0/3 nodes are available:
1 node(s) had taint {node-role.kubernetes.io/master: },
2 node(s) didn't match Pod's node affinity.
# 诊断结果：
# 1. 1个Master节点有污点，不允许调度普通Pod
# 2. 2个Worker节点的标签不匹配Pod的nodeAffinity
# 解决方案：
# 方案1：移除Pod的nodeAffinity限制
# 方案2：给节点打上正确的标签
kubectl label nodes node-1 app-tier=frontend
# 验证
$ kubectl get pod my-app-xxx
NAME READY STATUS RESTARTS AGE
my-app-xxx 1/1 Running 0 10s
⚠️ 避坑警告：Master节点默认有node-role.kubernetes.io/master:NoSchedule污点，普通Pod不会被调度到Master上。如果你测试环境节点少，可以移除这个污点，但生产环境千万别这么干！
文末三件套
1. 【源码获取】
关注此系列获取后续更新，后台回复'k8s'获取链接。
2. 【思考题】
一个Pod卡在Pending状态，可能的原因有哪些？
点击查看答案
- 1. 资源不足：节点CPU/内存不够
- 2. 污点不匹配：Pod不能容忍节点的污点
- 3. 节点选择器不匹配：nodeSelector/nodeAffinity条件不满足
- 4. PVC未绑定：持久卷声明无法绑定
- 5. 网络插件问题：CNI插件未就绪
- 6. Scheduler异常：调度器本身出现故障
- 7. 镜像拉取失败：虽然这通常是ContainerCreating状态，但有时也会表现为Pending
3. 【系列预告】
- • 下一篇：容器网络与存储 —— 搞懂CNI和CSI，让你的Pod畅通无阻
- • 后续篇：调度策略深度解析 —— 从NodeAffinity到PodTopologySpread
- • 进阶篇：GitOps实践 —— 用ArgoCD实现声明式持续交付
总结
今天我们深入剖析了Kubernetes的核心架构：
| 组件 | 角色 | 关键记忆点 |
|---|---|---|
| API Server | 总闸门 | 所有请求必经之地，6443端口 |
| Scheduler | 红娘 | 给Pod找Node，<1秒完成调度 |
| Controller Manager | 管家 | 维护期望状态，强迫症晚期 |
| etcd | 大脑 | 所有状态存储，<10ms写入延迟 |
| Kubelet | 监工 | 节点上的Agent，管理容器生命周期 |
| Kube Proxy | 交警 | 实现Service网络，iptables/IPVS |
| Container Runtime | 搬砖工 | containerd/Docker，真正运行容器 |
关键数据回顾：
- • 支持最大节点数：5000+（单个集群）
- • Pod调度时间：< 1秒
- • etcd写入延迟：< 10ms
掌握这些核心组件的工作原理，你就能在集群出问题时快速定位根因，成为真正的"集群急救医生"。
本文是云原生系列第3篇，如果觉得有帮助，欢迎点赞、收藏、转发！
标签： Kubernetes, etcd, Scheduler, APIserver, K8s架构, 控制平面, 高可用
扫一扫
119
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
