Kubernetes架构与原理深度分析报告

一、核心设计理念

1、声明式API

用户通过YAML/JSON定义资源期望状态（如Deployment副本数3），系统通过控制器持续比对实际状态与期望状态差异，驱动集群向目标收敛。

示例：当Pod意外终止时，ReplicaSet控制器检测到实际副本数不足，立即创建新Pod补齐数量。

2、分层架构

采用控制平面（决策层）与数据平面（执行层）分离设计，通过APIServer作为唯一通信枢纽，实现组件松耦合。

二、架构组件详解

1、控制平面（Control Plane）

APIServer：集群网关，处理所有REST请求并写入etcd，支持认证/授权（如RBAC）。

Scheduler：基于资源需求、亲和性等策略选择节点，调度过程分为预选（Filter）和优选（Score）两阶段。

Controller Manager：包含Deployment/Node等控制器，通过List-Watch机制监听资源变化。

etcd：分布式键值库，存储集群所有配置和状态数据，采用Raft协议保证一致性。

2、工作节点（Node）

Kubelet：节点代理，管理Pod生命周期（如挂载存储卷、执行健康检查）。

Kube-Proxy：维护iptables/IPVS规则，实现Service的负载均衡。

容器运行时：Docker/containerd负责镜像拉取和容器启停。

三、关键工作流程示例

案例：应用部署的全链路

1、提交Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 2
  template:
    spec:
      containers:
      - name: nginx
        image: nginx:1.14

kubectl apply提交后，APIServer校验并存入etcd。

2、控制器响应

Deployment Controller创建ReplicaSet，ReplicaSet Controller确保存在2个Pod副本。

3、调度执行

Scheduler选择满足条件的Node，更新Pod的nodeName字段至etcd，目标节点Kubelet调用容器运行时启动容器。

4、服务暴露

创建Service时，Kube-Proxy自动配置iptables规则，将请求轮询转发至后端Pod（如172.17.0.3:80→172.17.0.4:80）。

四、网络通信模型

1、Pod内部：共享网络命名空间，容器通过localhost直接通信。

2、跨节点Pod：通过CNI插件（如Calico）建立Overlay网络，Pod IP全局可达。

3、Service到Pod：ClusterIP通过kube-proxy转换为Pod IP，默认使用iptables DNAT规则。

五、生产环境优化建议

1、高可用部署

APIServer：3节点负载均衡，启用
--enable-aggregator-routing。

etcd：SSD存储+定期快照备份（ETCDCTL_API=3 etcdctl snapshot save）。

2、性能调优

控制器：调整
--concurrent-deployment-syncs提高并发处理能力。

调度器：自定义优先级函数实现拓扑感知调度。