1. Kubernetes架构概述:从宏观到微观的设计哲学
Kubernetes作为容器编排领域的事实标准,其架构设计体现了分布式系统设计的精髓。整个系统采用典型的Master-Worker架构模式,这种设计在分布式系统中非常普遍——比如Hadoop、Spark等大数据框架都采用了类似架构。Master节点负责集群的"大脑"功能,而Node节点则是实际干活的"肌肉"。
重要提示:从Kubernetes 1.20版本开始,dockershim已被标记为废弃,这意味着直接使用Docker作为容器运行时需要额外配置。这是很多初学者容易忽略的兼容性问题。
Master节点包含四个核心组件:API Server、Controller Manager、Scheduler和etcd。它们各自独立又相互协作:
- API Server:集群的"前门",所有交互都必须通过它
- Controller Manager:确保系统始终处于期望状态
- Scheduler:决定Pod应该运行在哪个Node上
- etcd:集群的"记忆中枢",存储所有关键数据
Node节点则包含三个关键组件:
- kubelet:节点上的"监工",负责与Master通信并管理容器
- kube-proxy:网络流量的"交警",处理服务发现和负载均衡
- 容器运行时:实际运行容器的引擎,如containerd或CRI-O
这种架构设计体现了几个关键思想:
- 关注点分离:不同组件职责明确,避免功能重叠
- 声明式API:用户声明期望状态,系统负责实现
- 自我修复:系统持续检测并纠正偏差
- 水平扩展:每个组件都可以独立扩展
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Master节点深度拆解:集群的中枢神经系统
2.1 API Server:集群的唯一入口
API Server是Kubernetes最核心的组件,所有组件间的通信都必须通过它。这就像公司的前台接待处——无论是内部员工还是外部访客,都必须通过前台才能与其他部门交互。
API Server的关键特性包括:
- RESTful API设计:使用标准的HTTP方法(GET/POST/PUT/DELETE等)
- 认证授权机制:支持多种认证方式(证书、令牌、Basic Auth等)
- 准入控制链:可以在请求处理过程中插入自定义逻辑
- 资源版本控制:每个资源对象都有resourceVersion字段用于乐观并发控制
一个典型的API调用流程如下:
- 客户端(kubectl或其他组件)发起请求
- 经过认证(Authentication)、授权(Authorization)和准入控制(Admission Control)
- 持久化到etcd
- 返回响应给客户端
实际经验:生产环境中建议启用--audit-log-path参数记录审计日志,这对安全审计和问题排查非常有用。
2.2 Controller Manager:集群的自动驾驶仪
Controller Manager实际上是一组控制器的集合,每个控制器都是一个独立进程,但为了降低复杂性,它们被编译成单个二进制文件运行。这些控制器就像是集群的"自动驾驶系统",不断检查当前状态是否与期望状态一致。
主要的内置控制器包括:
- Deployment控制器:确保指定数量的Pod副本在运行
- ReplicaSet控制器:维护Pod副本数(通常由Deployment调用)
- StatefulSet控制器:管理有状态应用
- Node控制器:监控Node状态并响应变化
- Service控制器:维护Service与Endpoint的映射关系
控制器的工作模式遵循标准的"观察-分析-行动"循环:
- 通过API Server获取资源对象的期望状态
- 获取实际状态
- 比较两者差异
- 执行必要的操作使实际状态趋近期望状态
2.3 Scheduler:智能调度专家
Scheduler负责决定Pod应该运行在哪个Node上。这就像公司的HR部门,需要根据岗位要求(Pod的资源需求)和员工能力(Node的可用资源)进行最佳匹配。
调度过程分为两个阶段:
-
过滤阶段(Predicates):排除不符合要求的Node
- 检查Node的资源是否足够
- 检查Node是否满足Pod的亲和性/反亲和性规则
- 检查端口冲突等
-
打分阶段(Priorities):对符合条件的Node进行评分
- 资源平衡考量(如选择资源利用率较低的Node)
- 亲和性考量(如优先选择同一区域的Node)
- 其他自定义规则
调度技巧:可以通过设置Pod的priorityClassName来影响调度顺序,高优先级的Pod可以抢占低优先级Pod的资源。
2.4 etcd:集群的记忆核心
etcd是一个分布式键值存储系统,Kubernetes用它来存储所有的集群数据。这就像是集群的"长期记忆",即使所有组件重启,也能恢复到之前的状态。
etcd的关键特性:
- 强一致性:使用Raft协议保证数据一致性
- 高可用:支持多节点部署,容忍部分节点故障
- 快速响应:读写性能优异,适合频繁更新的场景
- 安全:支持TLS加密和基于角色的访问控制(RBAC)
在生产环境中,etcd的部署有几点需要注意:
- 必须使用SSD存储,机械硬盘无法满足性能要求
- 建议部署奇数个节点(3、5或7个)以实现高可用
- 定期备份etcd数据是必须的运维操作
3. Node节点全面解析:工作负载的实际执行者
3.1 kubelet:节点上的全能管家
kubelet是运行在每个Node上的主要"代理",它负责:
- 与API Server通信,获取分配给本节点的Pod清单
- 管理Pod的生命周期(创建/停止/重启容器)
- 定期向Master报告节点和Pod状态
- 执行存活探针和就绪探针检查
kubelet的工作流程:
- 从API Server或本地静态Pod配置获取Pod定义
- 通过容器运行时接口(CRI)与容器运行时交互
- 通过容器网络接口(CNI)配置网络
- 通过容器存储接口(CSI)配置存储
常见问题:如果kubelet报告"ImagePullBackOff"错误,通常是因为镜像拉取失败,可能是镜像不存在或认证问题。
3.2 kube-proxy:服务发现与负载均衡专家
kube-proxy负责维护节点上的网络规则,实现Kubernetes Service概念。它有三种工作模式:
- userspace模式(已淘汰):在用户空间通过iptables重定向到kube-proxy端口
- iptables模式(默认):完全通过iptables规则实现服务发现和负载均衡
- IPVS模式(推荐):利用Linux内核的IPVS功能,适合大规模集群
以iptables模式为例,当创建一个Service时:
- API Server会分配一个Cluster IP(虚拟IP)
- kube-proxy会监听Service和Endpoint变化
- 为每个Service创建iptables规则,将Cluster IP流量转发到后端Pod
3.3 容器运行时:容器实际执行环境
容器运行时是真正运行容器的软件。Kubernetes通过CRI(容器运行时接口)与各种运行时交互。常见的容器运行时有:
- containerd:目前最主流的运行时,Docker也在使用它
- CRI-O:专为Kubernetes设计的轻量级运行时
- Docker(通过dockershim):已废弃,不建议在新环境中使用
容器运行时的主要职责包括:
- 拉取容器镜像
- 管理容器生命周期(创建/启动/停止/删除)
- 管理容器存储
- 管理容器网络(与CNI插件配合)
4. 组件间通信机制:集群的神经网络
4.1 Master组件间通信
Master组件间的通信遵循几个原则:
- API Server是唯一与etcd通信的组件(安全考虑)
- 其他Master组件都通过API Server间接访问集群状态
- 组件间使用gRPC或HTTPs进行通信
典型的通信场景:
- Scheduler通过API Server的watch接口监听未调度的Pod
- Controller Manager通过API Server更新资源状态
- 所有组件都通过API Server将数据持久化到etcd
4.2 Master与Node间通信
Master与Node间的通信路径主要有两条:
-
kubelet主动连接API Server(出站连接,更安全)
- 获取Pod清单
- 报告节点状态
- 接收指令(如执行探针检查)
-
API Server连接到kubelet(用于日志、exec等操作)
- 需要配置--kubelet-certificate-authority参数
- 通常只在需要调试时使用
4.3 Node组件间通信
Node上的组件通信相对简单:
- kubelet通过CRI与容器运行时交互
- kubelet通过CNI插件配置网络
- kube-proxy独立工作,主要通过iptables/IPVS操作
5. 生产环境最佳实践与故障排查
5.1 Master节点高可用部署
生产环境必须部署多Master节点以实现高可用,典型架构:
- 3个或5个Master节点(etcd与Master组件同机部署)
- 使用负载均衡器暴露API Server
- etcd集群跨机架或可用区部署
关键配置参数:
- --etcd-servers:指定所有etcd节点地址
- --apiserver-count:告知API Server集群中有多少个实例
- --endpoint-reconciler-type:确保Endpoint资源正确更新
5.2 常见故障排查指南
-
API Server无响应
- 检查etcd是否健康
- 检查API Server的CPU/内存使用情况
- 查看kube-apiserver日志中的错误信息
-
Pod一直处于Pending状态
- kubectl describe pod
查看事件 - 检查资源是否足够
- 检查是否有污点(taint)或亲和性规则限制
- kubectl describe pod
-
Service无法访问
- 检查Endpoint是否正确(kubectl get endpoints)
- 检查kube-proxy是否正常运行
- 验证iptables/IPVS规则是否正确
5.3 性能调优建议
-
API Server调优
- 增加--max-requests-inflight和--max-mutating-requests-inflight
- 启用--enable-priority-and-fairness特性
- 使用单独的etcd集群处理事件
-
etcd调优
- 设置--quota-backend-bytes防止存储耗尽
- 定期执行etcd碎片整理(defrag)
- 监控etcd的延迟指标
-
kubelet调优
- 调整--image-gc-high-threshold和--image-gc-low-threshold
- 设置--kube-api-qps和--kube-api-burst
- 启用--serialize-image-pulls避免并发拉取镜像
