Kubernetes及其架构

Source: Dev.to

使用 Docker 时遇到的问题

• 单主机资源竞争 – 当一个主机上运行大量容器时，某个消耗过多内存的容器会影响其他容器的性能，甚至可能根据优先级将它们杀掉。
• 没有自动自愈 – 容器崩溃后，应用不可访问，必须手动重启容器。
• 缺乏自动伸缩 – Docker 本身不提供内置的工作负载自动扩容或缩容机制。
• 没有企业级支持 – Docker 本身不包含企业级支持功能。

Kubernetes 如何解决这些问题

Kubernetes 增加了编排能力，能够解决上述限制，提供自动健康检查、伸缩以及对生产环境的强大支持。

Kubernetes 架构

数据平面

• 容器运行时 – 执行容器（例如 Docker、containerd）。类似于 Java 应用的 Java 运行时。
• kube‑proxy – 管理容器与服务之间的网络，执行负载均衡并分配 IP 地址。
• kubelet – 确保分配给其节点的 Pod 正在运行且健康。它与控制平面通信，并使用容器运行时在 Pod 内启动容器。

控制平面

• API Server – 核心组件，也是所有命令的入口。存储对象（如 Pod），并向其他组件公开这些对象。
• Scheduler – 决定每个 Pod 将运行在哪个节点上。它监视未调度的 Pod，评估候选节点，并根据策略和资源可用性选择最佳节点。
• etcd – 分布式键值存储，保存集群的状态和配置信息。
• Controller Manager – 维护集群的期望状态（例如，确保指定数量的副本在运行）。

工作流概览

1. 用户请求 – 用户发送请求（例如 kubectl apply）到 API Server。
2. 持久化状态 – API Server 验证请求并将期望的对象定义存入 etcd。
3. 调度 – Scheduler 检测到没有节点分配的新 Pod，评估可用节点，并将每个 Pod 分配给合适的节点。
4. 节点执行 – 选中节点上的 kubelet 接收分配指令，指示 容器运行时 启动 Pod 的容器。
5. 网络配置 – kube‑proxy 为新创建的 Pod 配置服务路由和负载均衡。
6. 控制循环 – Controller Manager 中的控制器持续监控实际状态并与期望状态对比，必要时触发伸缩或自愈等操作。