所以尝试重新组织语言、文章段落，把 K8s 的这些知识写的更有层次些，让大家更容易读懂，更有温度，不再是觉得对文档的翻译和概念的堆砌。
K8s基础入门和实践--大纲
前三篇理论，后两篇实践，理论篇也会有一些例子，不会让文章内容太枯燥。其实之前已经写过一篇 Docker 与 K8s 的关系，算是进入K8s学习之前的预热，先分清两者的关系。
本篇文章聚焦K8s的整体架构，给大家描绘出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 的整体架构图
了解到 K8s 由主节点、工作节点两大部分组成后，接下来我们逐一展开，看看主节点和工作节点分别由哪些组件构成。
主节点
Master 节点是 K8s 集群的大脑，负责向外开放集群的 API，调度和管理整个集群。集群至少要有一个Master节点，如果在生产环境中要达到高可用，还需要配置 Master 集群。
下面这张图，描绘出了主节点内部的结构。
K8s主节点内部结构
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 等。
K8s 工作节点的内部结构
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 也是面向对象的，而且面向的还很彻底，就跟某语言说的一切皆对象一样彻底。不过正因为它是面向对象的，那么以面向对象的方式来思考这些东西，反而会很好理解，毕竟我们每天都要面向"对象"，不是么：）。
