1. K8s 架构基础：Master 节点组件、Worker 节点组件、etcd、kube-apiserver、kube-scheduler、kube-controller-manager、kubelet、kube-proxy
Kubernetes 集群由 Master 节点（控制平面）和 Worker 节点（数据平面）组成。理解各组件的职责与协作关系，是后续学习 OPA 准入控制与调度器参数调优的前提。
1.1 集群组件总览
下表列出核心组件及其所属节点类型：
| 组件名称 | 所属节点 | 核心职责 |
|---|---|---|
| kube-apiserver | Master | 所有 API 请求的入口，认证/授权/准入控制 |
| etcd | Master | 集群状态持久化存储（键值数据库） |
| kube-scheduler | Master | 为 Pod 选择最优 Worker 节点 |
| kube-controller-manager | Master | 运行各类控制器（Deployment、Node、Endpoint 等） |
| kubelet | Worker | 管理节点上的 Pod 和容器生命周期 |
| kube-proxy | Worker | 维护节点网络规则，实现 Service 负载均衡 |
| 容器运行时 | Worker | 实际运行容器（containerd、CRI-O 等） |
1.2 Master 节点组件详解
1.2.1 kube-apiserver
- 唯一入口：所有组件（kubectl、scheduler、controller-manager、kubelet）均通过 apiserver 通信。
- 认证与授权：支持 TLS 客户端证书、Bearer 、Webhook 等多种认证方式；授权模式包括 RBAC、ABAC、Node 等。
- 准入控制（Admission Control）：在请求持久化到 etcd 之前，执行一系列准入插件（如
MutatingAdmissionWebhook、ValidatingAdmissionWebhook）。OPA 正是通过 Webhook 模式集成到这一环节。 - 水平扩展：可部署多个实例，通过负载均衡对外提供服务。
1.2.2 etcd
- 分布式键值存储：基于 Raft 共识算法，保证强一致性。
- 存储内容：所有集群对象（Pod、Service、ConfigMap、Secret 等）的完整状态。
- 性能关键：etcd 的读写延迟直接影响 apiserver 响应速度，调度器参数调优时需关注 etcd 的
--quota-backend-bytes和磁盘 IO。
1.2.3 kube-scheduler
- 调度决策：监听未调度的 Pod，通过 过滤（Predicates） 和 打分（Priorities） 两阶段选出最佳节点。
- 可扩展性：支持调度策略配置（
--policy-config-file）和调度器扩展（Extender / Scheduler Framework）。 - 参数调优：
--percentage-of-nodes-to-score、--bind-timeout-seconds等参数影响大规模集群的调度吞吐。
1.2.4 kube-controller-manager
- 控制器集合：包含 Node Controller、Replication Controller、Endpoint Controller、Service Account Controller 等数十个控制器。
- 状态修复：持续对比当前状态与期望状态，执行创建、删除、更新操作。
- 高可用：通过
--leader-elect实现主备选举，避免脑裂。
1.3 Worker 节点组件详解
1.3.1 kubelet
- 节点代理：每个 Worker 节点上运行的核心 agent。
- Pod 生命周期管理：接收 apiserver 下发的 PodSpec，调用容器运行时创建/删除容器。
- 健康检查：定期执行 Liveness、Readiness、Startup 探针，上报节点与 Pod 状态。
- 资源监控：通过 cAdvisor 集成采集 CPU、内存、磁盘等指标。
1.3.2 kube-proxy
- 网络代理：维护节点上的 iptables 或 IPVS 规则，实现 Service 的 ClusterIP、NodePort、LoadBalancer 转发。
- 模式选择：
userspace（已弃用）、iptables（默认）、ipvs（高性能推荐）。 - 会话保持：支持
service.spec.sessionAffinity配置。
1.4 组件协作流程（内联 SVG）
下图展示一个 Pod 创建请求从用户提交到容器运行的完整路径：
1.5 关键设计原则
核心原则：所有组件仅通过 kube-apiserver 与 etcd 交互，不直接通信。这种“松耦合”架构使得每个组件可以独立升级、扩展或替换。
- 声明式 API：用户提交期望状态（YAML/JSON），控制器不断调和至该状态。
- 最终一致性：除 etcd 外，各组件缓存数据，允许短暂不一致。
- 可插拔准入：准入 Webhook 机制允许 OPA、Kyverno 等策略引擎在不修改核心代码的前提下注入安全策略。
1.6 组件通信端口一览
| 组件 | 默认端口 | 协议 | 用途 |
|---|---|---|---|
| kube-apiserver | 6443 | HTTPS | 客户端与集群交互 |
| etcd | 2379 / 2380 | gRPC | 客户端通信 / 集群内部通信 |
| kube-scheduler | 10259 | HTTPS | 健康检查与指标 |
| kube-controller-manager | 10257 | HTTPS | 健康检查与指标 |
| kubelet | 10250 | HTTPS | apiserver 与 kubelet 通信 |
| kube-proxy | 10249 | HTTP | 指标与健康检查 |
安全提示：在生产环境中，应使用网络策略（NetworkPolicy）限制组件间非必要端口访问，并启用 TLS 双向认证。
1.7 组件依赖关系（内联 SVG）
下图展示各组件的启动依赖与数据流向：
常见误区：初学者常误认为 kubelet 直接调用 kube-scheduler 或 etcd。实际上 kubelet 只与 apiserver 通信，调度器也只通过 apiserver 读取 Pod 和节点信息。理解这一“中心化 API”模式是掌握 K8s 架构的关键。