本文首发于我的公众号 Linux云计算网络（id: cloud_dev），专注于干货分享，号内有 10T 书籍和视频资源，后台回复「1024」即可领取，欢迎大家关注，二维码文末可以扫。
Hi，大家好，欢迎大家和我一起学 K8S，这是系列第 4 篇。
任何技术的诞生，都会经历从架构设计到开发测试的过程，好的技术，往往也会有一套好的架构。架构是个好东西，它能帮助我们站在高处看清楚事物的整体结构，避免过早地进入细节而迷失方向。
上篇文章扫清了 K8S 的一些基本概念，今天这篇文章我们就来看看 K8S 的架构。
先上图：
图中包括两种类型的节点：Master 和 Node，每个节点上运行着多种 K8S 服务。
Master 节点
Master 是 K8S 集群的大脑，运行着如下 Daemon 服务：kube-apiserver、kube-controller-manager、kube-scheduler、etcd 等。
API Server
如果把 K8S 环境看作是一个公司，那 API Server 就是这个公司的基础平台部，是公司最为核心的技术能力输出出口。它对外提供 HTTP/HTTPS REST API，统称 K8S API，可以供各类客户端工具（CLI 或 WebUI）、K8S 其他组件，以及第三方的平台接入。对内提供了 K8S 各类资源（如 Pod、Deployment、Service等）的增删改查和监控等操作，是集群内各个功能模块之间数据交互和通信的中心枢纽。
Controller Manager
Controller Manager 更像是公司的人力资源部，负责统筹公司的人员分布。它管理着 K8S 各类资源的生命周期，保证资源处于预期状态，如果现有状态和预期状态不符，它会自动化执行修正。
Controller Manager 由多种 Controller 组成，包括 Replication Controller、Node Controller、ResourceQuota Controller、Namespace Controller、ServiceAccount Controller、Service Controller、Token Controller 及 Endpoint Controller 等。每种 Controller 都负责一种具体的资源管控流程，而 Controller Manager 正是这些 Controller 的核心管理者。
Scheduler
Scheduler 则像是公司各个部门的项目经理之类的角色，负责将具体的人力放到他们擅长的位置上，知人善用。具体来说，Scheduler 负责将待调度的 Pod 对象按照特定的调度策略绑定到集群中某个合适的节点上，调度策略会综合考虑集群的拓扑结构、节点的负载情况、以及应用对高可用、性能、数据亲和性的需求。
etcd
etcd 是一个高可用的分布式数据库，负责保存 K8S 的配置信息和各种资源的状态信息。当数据发生变化时，etcd 会及时告知集群中的其他组件。
kubectl
kubectl 是 K8S 的 CLI 工具，这是使用 K8S API 建立的一套命令行工具，使用它，可以非常方便地管理 K8S 集群。
Node 节点
Node 是 K8S 集群的具体执行者，也运行着多种服务，如：kubelet、kube-proxy、container runtime、Pod 网络等。Node 可以看作是 Master 的代理，负责处理 Master 下发到本节点的任务，管理 Pod 和 Pod 中的容器，定期向 Master 汇报自身资源的使用情况。
kubelet
kubelet 更像是部门中各个小组的 Leader，对外从 API Server 拿资源，对内负责小组内各种资源的管理，比如从 Master 拿到 Pod 的具体配置信息（image、Volume 等）之后，kubelet 根据这些信息创建和运行容器。
kube-proxy
kube-proxy 则像穿插在公司各个部门之间的接口人，对内和内部人员沟通，对外协调部门之间的各种事宜，展示部门风采。kube-proxy 作用于 Service，通过前面学习，我们知道 Service 是对一组 Pod 的抽象，统一对外提供某种服务，当外部访问 Service 时，实际上是需要访问 Service 所管辖的 Pod 中的容器，kube-proxy 在这里就是负责将访问 Service 的数据流转发到后端的容器，如果有多个副本，kube-proxy 会实现负载均衡。
cAdvisor
cAdvisor 对 Node 上的资源进行实时监控和性能数据采集，包括 CPU 使用情况、内存使用情况、网络吞吐量及文件系统使用情况等。cAdvisor 集成在 kubelet 中，当 kubelet 启动时会自动启动 cAdvisor，一个cAdvisor 仅对一台 Node 机器进行监控。
container runtime
container runtime 是真正运行容器的地方，为容器提供运行环境，主流的三种 container runtime 是 lxc、runc 和 rkt，K8S 都支持它们，但常用的事 runc，原因是 runc 是 Docker 默认的 runtime。在 K8S 的容器应用中，Docker 是主流。
OK，K8S 架构介绍就到此为止。
最后，还是继续送书，容器网络专家倪朋飞写的《K8S 指南》电子书，如有需要后台回复“K8S”（之前回复过就不用回复了）。如需加群学习回复“加群”。
下文我们开始对 K8S 的说明书一探究竟。
我的公众号 「Linux云计算网络」(id: cloud_dev) ，号内有 10T 书籍和视频资源，后台回复 「1024」 即可领取，分享的内容包括但不限于 Linux、网络、云计算虚拟化、容器Docker、OpenStack、Kubernetes、工具、SDN、OVS、DPDK、Go、Python、C/C++编程技术等内容，欢迎大家关注。
