------> 课程视频同步分享在今日头条和B站

首先来一张简结版的K8s架构图

接着来一张详细的K8s架构图

从上面的图可以看出整个K8s集群分为两大部分：

• K8s控制平面
• （工作）节点

让我们具体看下这两个部分做了什么，以及其内部运行的内容又是什么。

控制平面的组件

控制平面负责控制并使得整个K8s集群正常运转。 回顾一下，控制平面包含如下组件：

• ETCD分布式持久化存储 – etcd保存了整个K8s集群的状态；
• API服务器 – apiserver提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；
• 调度器 – scheduler负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；
• 控制器管理器 – controller manager负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；

这些组件用来存储、管理集群状态，但它们不是运行应用的容器。

工作节点上运行的组件

运行容器的任务依赖于每个工作节点上运行的组件：

• Kubelet – 是 Node 的 agent，负责维护容器的生命周期，同时也负责Volume（CSI）和网络（CNI）的管理；
• Kubelet服务代理（kube-proxy） – 负责为Service提供cluster内部的服务发现和负载均衡；
• 容器运行时（Docker、rkt或者其他） – Container runtime负责镜像管理以及Pod和容器的真正运行（CRI）；

附加组件

除了控制平面（和运行在节点上的组件），还要有几个附加组件，这样才能提供所有之前讨论的功能。包含：

• K8s DNS服务器 – CoreDNS负责为整个集群提供DNS服务
• 仪表板（可选） – Dashboard提供GUI，作为高级运维人员，使用kubectl命令行工具管理足矣
• Ingress控制器 – Ingress Controller为服务提供外网流量入口
• 容器集群监控 – Metrics-server为K8s资源指标获取工具; Prometheus提供资源监控
• CNI容器网络接口插件 – calico, flannel（如果没有实施网络策略的需求，那么就直接用flannel，开箱即用；否则就用calico了，但要注意如果网络使用了巨型帧，那么注意calico配置里面的默认值是1440，需要根据实际情况进行修改才能达到最佳性能）

简单概括：

API服务器只做了存储资源到etcd和通知客户端有变更的工作
调度器则只是给pod分配节点（由kubelet来启动容器）
控制管理器里的控制器始终保持活跃的状态，来确保系统真实状态朝API服务器定义的期望的状态收敛

Deployment资源提交到API服务器的事件链

准备包含Deployment清单的YAML文件，通过kubectl提交到Kubernetes。kubectl通过HTTP POST请求发送清单到Kubernetes API服务器。API服务器检查Deployment定义，存储到etcd，返回响应给kubectl，如下图所示：

总的来说，k8s站在所有硬件基础设施之上，屏蔽并抽象了它们，使得对我们使用维护者而言，k8s所带给我们就是一个巨大的资源池，在这里面没有了底层服务器数量等概念，我们只需要关注这个资源池里面还有多少可用的CPU及内存，k8s会选择合适的地方来运行我们的服务。