K8s 长什么样子，一文道清它的整体架构

2020 年我在公众号上分享 K8s 相关的文章的时候属于边学边写，每学会一块内容，记录总结发布在公众号上。如今回看，发现很多内容、知识点写的过于生硬，很多名词不知道是干什么的，就直接翻译了过来，这就导致文字没有温度，内容层次也不够。

所以尝试重新组织语言、文章段落，把 K8s 的这些知识写的更有层次些，让大家更容易读懂，更有温度，不再是觉得对文档的翻译和概念的堆砌。

我整理了以下大致脉络，预计用五篇文章推送给大家。

前三篇理论，后两篇实践，理论篇也会有一些例子，不会让文章内容太枯燥。

本篇文章聚焦 K8s 的整体架构，给大家描绘出 K8s 的大致模样。

本系列使用的源码、YAML 配置、和操作步骤都可以给公众号 「网管叨 bi 叨」发私信【k8s】获得我整理好的在线资料，具体步骤都在这里：

K8s 是什么

Kubernetes（单词太长，后面用 K8s 代替 ）是一个基于容器技术的分布式架构方案，它源自 Google 内部大规模集群管理系统——Borg，自 2015 年开源后得到开源社群的全力支援，IBM、惠普、微软、RedHat 等业界巨头纷纷加入，成为后来的 CNCF 组织（Cloud Native Computing Foundation，云原生计算基金会）首个毕业的项目。

K8s 具备完善的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建负载均衡器、故障发现和自我修复能力、服务滚动升级和线上扩容、可扩展的资源自动调度机制、多粒度的资源配额管理能力。还提供完善的管理工具，涵盖开发、部署测试、运维监控等各个环节。

总结一句话：是一套结合了容器编排和集群调度管理的大规模分布式系统解决方案。

K8s 长什么样子

K8s 不是我们现实可以看到摸到的一个东西，所以初学者看完 K8s 是什么的描述后，可能也是觉得云里雾里。那么这里我就尝试描绘一下 K8s 它到底长什么样子。描述一个解决方案的样貌，其实直白点说就是它的整体架构是什么样的，由哪些核心部分组成，每个部分相互怎么交互这些。

我们先来看一下 K8s 的整体的结构。

K8s 的整体结构

K8s 采用 Master / Work Node（最初称为 Minion，后改名 Node） 的结构，Master Node（主节点）控制整个集群，Work Node（从节点）为集群提供计算能力。使用者可以通过命令行或者 Web 控制台页面的方式来操作集群。

下图可以清楚地表示出 K8s 的整体架构

了解到 K8s 由主节点、工作节点两大部分组成后，接下来我们逐一展开，看看主节点和工作节点分别由哪些组件构成。

主节点

Master 节点是 K8s 集群的大脑，负责向外开放集群的 API，调度和管理整个集群。集群至少要有一个 Master 节点，如果在生产环境中要达到高可用，还需要配置 Master 集群。

下面这张图，描绘出了主节点内部的结构。

Master 主要包含 API Server、Scheduler、Controllers 三个组成部分， 以及用作存储的 etcd ，它用来储存整个集群的状态。

• etcd： 由 CoreOS 开发，是一个高可用、强一致性的键值存储，为 Kubernetes 集群提供储存服务，类似于 zookeper。 它会存储集群的整个配置和状态。主节点通过查询 etcd 以检查节点，容器的现状。

• API Server： kubernetes 最重要的核心元件之一，提供资源操作的唯一入口（其他模块通过 API Server 查询或修改资源对象，只有 API Server 才能直接操作 etcd），并提供认证、授权、访问控制、API 注册和发现等机制。

• Scheduler： 负责资源的调度，按照预定的调度策略将 Pod（k8s 中调度的基本单位）调度到相应的 Node 上，这里说的 Node 就是 Work Node，当然如果是只有一个节点的集群，Master 也会同时作为 Work Node。

• Controllers： 通过 API Server 查询要控制的资源对象的预期状态，它检查其管控的对象的当前状态，确保它们始终处于预期的工作状态，它们的工作包括比如故障检测、自动扩充、减少、滚动更新等。

我们能接触到的控制器有，下面这些：

• Deployment

  StatuefulSet

  Service

  DaemonSet

  Ingress

具体干什么的，放到下篇文章—K8s 面向对象再详细介绍，没错想用 K8s 你也得面向对象，可怕不。到时候会结合着例子一块看。

我们继续看 K8s 的工作节点的内部结构。

工作节点

K8s 集群的工作节点，可以是物理机也可以是虚拟机器。Node 上运行的主要 K8s 组件有 kubelet、kube-proxy、Container Runtime 、Pod 等。

kubelet

K8s 集群的每个工作节点上都会运行一个 kubelet 程序 维护容器的生命周期，它叫接收并执行 Master 节点发来的指令，管理节点上的 Pod 及 Pod 中的容器。同时也负责 Volume（CVI）和网络（CNI）的管理。

每个 kubelet 程序会在 API Server 上注册节点自身的信息，定期向 Master 节点汇报自身节点的资源使用情况，并通过 cAdvisor 监控节点和容器的资源。通过运行 kubelet，节点将自身的 CPU，RAM 和存储等计算机资源编程集群的一部分，相当于是放进了集群统一的资源管理池中，交由 Master 统一调配。

Container Runtime

容器运行时负责与容器实现进行通信，完成像容器镜像库中拉取镜像，然后启动和停止容器等操作， 引入容器运行时另外一个原因是让 K8s 的架构与具体的某一个容器实现解耦，不光是 Docker 能运行在 K8s 之上，同样也让 K8s 的发展按自己的节奏进行。

想要运行在我的生态里的容器，请实现我的 CRI （Container Runtime Interface），Container Runtime 只负责调用 CRI 里定义的方法完成容器管理，不单独执行 docker run 之类的操作。这个也是 K8s 发现 Docker 制约了它的发展在 1.5 后引入的。

Pod

Pod 是 K8s 中的最小调度单元。我们的应用程序运行在容器里，而容器又被分装在 Pod 里。 一个 Pod 里可以有单个容器，也可以有多个容器。没有统一的标准，是单个还是多个，看要运行的应用程序的性质。 不过一个 Pod 里只有一个主容器，剩下的都是辅助主容器工作的。

比如做服务网格 Istio 的 Envoy 网关，就是放在 Pod 的辅助容器运行来实现流量控制的。 这就是 K8s 的容器设计模式里最常用的一种模式：sidecar。顾名思义，sidecar 指的就是我们可以在一个 Pod 中，启动一个辅助容器，来完成一些独立于主进程（主容器）之外的工作。

kube-proxy

为集群提供内部的服务发现和负载均衡，监听 API Server 中 Service 控制器和它后面挂的 endpoint 的变化情况，并通过 iptables 等方式来为 Service 的虚拟 IP、访问规则、负载均衡。

总结

本篇文章聚焦 K8s 的整体架构，给大家描绘出 K8s 的大致模样。下一节我们来说说 K8s 的面向对象，以及我们能接触到的常用控制器对象。此刻看到这句话你的心情可能是：“纳尼，这厮也是面向对象？面向对象，怎么老是你？”

是的，K8s 也是面向对象的，而且面向的还很彻底，就跟某语言说的一切皆对象一样彻底。不过正因为它是面向对象的，那么以面向对象的方式来思考这些东西，反而会很好理解，毕竟我们每天都要面向"对象"，不是么：）

扫码关注公众号「网管叨 bi 叨」

最近整理了一本《Go 开发参考书》收集了 80 多条开发实践。去公众号回复【gocookbook】领取！还有一本《k8s 入门实践》讲解了常用软件在 K8s 上的部署过程，公众号回复【k8s】即可领取！