从宏观上来看 Kubernetes 的整体架构，包括 Master、Node 以及 etcd。

Master 即主节点，负责控制整个 Kubernetes 集群。它包括 API Server、Scheduler、Controller 等组成部分。它们都需要和 etcd 进行交互以存储数据。

• API Server：主要提供资源操作的统一入口，这样就屏蔽了与 etcd 的直接交互。功能包括安全、注册与发现等。
• Scheduler：负责按照一定的调度规则将 Pod 调度到 Node 上。
• Controller：资源控制中心，确保资源处于预期的工作状态。
• Node 即工作节点，为整个集群提供计算力，是容器真正运行的地方，包括运行容器、kubelet、kube-proxy。
• kubelet：主要工作包括管理容器的生命周期、结合 cAdvisor 进行监控、健康检查以及定期上报节点状态。
• kube-proxy：主要利用 Service 提供集群内部的服务发现和负载均衡，同时监听 Service/Endpoints 变化并刷新负载均衡。

• Deployment 是用于编排 Pod 的一种控制器资源，我们会在后面做介绍。这里以 Deployment 为例，来看看架构中的各组件在创建 Deployment 资源的过程中都干了什么。

  首先是 kubectl 发起一个创建 deployment 的请求

  • apiserver 接收到创建 deployment 请求，将相关资源写入 etcd;之后所有组件与 apiserver/etcd 的交互都是类似的
  • deployment controller list/watch 资源变化并发起创建 replicaSet 请求
  • replicaSet controller list/watch 资源变化并发起创建 Pod 请求
  • scheduler 检测到未绑定的 Pod 资源，通过一系列匹配以及过滤选择合适的 Node 进行绑定
  • kubelet 发现自己 Node 上需创建新 Pod，负责 Pod 的创建及后续生命周期管理
  • kube-proxy 负责初始化 Service 相关的资源，包括服务发现、负载均衡等网络规则

  至此，经过 Kubernetes 各组件的分工协调，完成了从创建一个 deployment 请求开始到具体各 Pod 正常运行的全过程。

  Pod

  在 Kubernetes 众多的 API 资源中，Pod 是最重要和基础的，是最小的部署单元。

  首先我们要考虑的问题是，我们为什么需要 Pod?Pod 可以说是一种容器设计模式，它为那些“超亲密”关系的容器而设计，我们可以想象 servelet 容器部署 war 包、日志收集等场景，这些容器之间往往需要共享网络、共享存储、共享配置，因此我们有了 Pod 这个概念。