Kubernetes一个核心的特点就是：能够自主的管理容器来保证云平台中的容器按照用户的期望状态运行着（比如用户想让apache一直运行，用户不需要关心怎么去做，Kubernetes会自动去监控，然后去重启，新建，总之，让apache一直提供服务），管理员可以加载一个微型服务，让规划器来找到合适的位置，同时，Kubernetes也系统提升工具以及人性化方面，让用户能够方便的部署自己的应用（就像canary deployments）。

现在Kubernetes着重于：不间断的服务状态（比如web服务器或者缓存服务器）和原生云平台应用（Nosql）,在不久的将来会支持各种生产云平台中的各种服务，例如，分批，工作流，以及传统数据库。

K8S的核心价值是：自主、自动的按照它的客户的要求管理客户的应用程序，而不需要用户手工参与，纵使运营应用程序的过程中会出现各种异常、负载的巨大变化，K8S也能够尽职尽力的为它的“主人”管理和打点好应用程序的运行，让应用程序提供不间断的服务。

1.4 K8S应用程序构建的基本单元:Pod

要实现K8S的价值，首先要对应用程序进行改造，使得应用程序必须是容器化的应用程序，以容器镜像方式进行发布、部署与运行。

为了更好的管理好应用，K8S自己内部对容器进行了进一步的组织，K8S把多个逻辑上精密相关的容器打包在一起，组成一个pod，pod成为K8S调度、管理应用的最小单位。

在Kubenetes中，所有的容器均在Pod中运行,一个Pod可以承载一个或者多个相关的容器，同一个Pod中的多个容器会部署在同一个物理机器上并且能够共享资源，这样做的目的是提升整个系统的效率，避免紧密相关的容器的应用程序的数据交互还必须通过网络完成。

为了进一步提升Pod内部容器之间数据传输的效率，一个Pod也可以包含O个或者多个磁盘卷组（volumes）,这些卷组将会以目录的形式提供给一个容器，或者被所有Pod中的容器共享。

对于用户创建的每个Pod,系统会自动选择那个健康并且有足够容量的机器，然后创建类似容器的容器,当容器创建失败的时候，容器会被node agent自动的重启,这个node agent叫kubelet,但是，如果是Pod失败或者机器，它不会自动的转移并且启动，除非用户定义了 replication controller。

用户可以自己创建并管理Pod, Kubernetes将这些操作简化为两个操作：基于相同的Pod配置文件部署多个Pod复制品；创建可替代的Pod当一个Pod挂了或者机器挂了的时候。而Kubernetes API中负责来重新启动，迁移等行为的部分叫做“replication controller”，它根据一个模板生成了一个Pod,然后系统就根据用户的需求创建了许多冗余，这些冗余的Pod组成了一个整个应用，或者服务，或者服务中的一层。一旦一个Pod被创建，系统就会不停的监控Pod的健康情况以及Pod所在主机的健康情况，如果这个Pod因为软件原因挂掉了或者所在的机器挂掉了，replication controller 会自动在一个健康的机器上创建一个一摸一样的Pod,来维持原来的Pod冗余状态不变，一个应用的多个Pod可以共享一个机器。

我们经常需要选中一组Pod，例如，我们要限制一组Pod的某些操作，或者查询某组Pod的状态，作为Kubernetes的基本机制，用户可以给Kubernetes Api中的任何对象贴上一组 key:value的标签，然后，我们就可以通过标签来选择一组相关的Kubernetes Api 对象，然后去执行一些特定的操作，每个资源额外拥有一组（很多） keys 和 values,然后外部的工具可以使用这些keys和vlues值进行对象的检索，这些Map叫做annotations（注释）。

除了共享volumes，还可以共享网络空间，进一步提升容器通信的效率。

Kubernetes支持一种特殊的网络模型，Kubernetes创建了一个地址空间，并且不动态的分配端口，它可以允许用户选择任何想使用的端口，为了实现这个功能，它为每个Pod分配IP地址。

现代互联网应用一般都会包含多层服务构成，比如web前台空间与用来存储键值对的内存服务器以及对应的存储服务，为了更好的服务于这样的架构，Kubernetes提供了服务的抽象，并提供了固定的IP地址和DNS名称，而这些与一系列Pod进行动态关联，这些都通过之前提到的标签进行关联，所以我们可以关联任何我们想关联的Pod，当一个Pod中的容器访问这个地址的时候，这个请求会被转发到本地代理（kube proxy）,每台机器上均有一个本地代理，然后被转发到相应的后端容器。Kubernetes通过一种轮训机制选择相应的后端容器，这些动态的Pod被替换的时候,Kube proxy时刻追踪着，所以，服务的 IP地址（dns名称），从来不变。

所有Kubernetes中的资源，比如Pod,都通过一个叫URI的东西来区分，这个URI有一个UID,URI的重要组成部分是：对象的类型（比如pod），对象的名字，对象的命名空间，对于特殊的对象类型，在同一个命名空间内，所有的名字都是不同的，在对象只提供名称，不提供命名空间的情况下，这种情况是假定是默认的命名空间。UID是时间和空间上的唯一。

1.5 K8S的主要功能与特点

Kubernetes是一个轻便的和可扩展的开源平台，用于管理容器化应用和服务。通过Kubernetes能够进行应用的自动化部署和扩缩容。

在Kubernetes中，会将组成应用的容器组合成一个逻辑单元以更易管理和发现。

Kubernetes积累了作为Google生产环境运行工作负载15年的经验，并吸收了来自于社区的最佳想法和实践。Kubernetes经过这几年的快速发展，形成了一个大的生态环境，Google在2014年将Kubernetes作为开源项目。

Kubernetes的关键特性包括：

自动化装箱：在不牺牲可用性的条件下，基于容器对资源的要求和约束自动部署容器。同时，为了提高利用率和节省更多资源，将关键和最佳工作量结合在一起。
自愈能力：当容器失败时，会对容器进行重启；当所部署的Node节点有问题时，会对容器进行重新部署和重新调度；当容器未通过监控检查时，会关闭此容器；直到容器正常运行时，才会对外提供服务。
水平扩容：通过简单的命令、用户界面或基于CPU的使用情况，能够对应用进行扩容和缩容。
服务发现和负载均衡：开发者不需要使用额外的服务发现机制，就能够基于Kubernetes进行服务发现和负载均衡。
自动发布和回滚：Kubernetes能够程序化的发布应用和相关的配置。如果发布有问题，Kubernetes将能够回归发生的变更。
保密和配置管理：在不需要重新构建镜像的情况下，可以部署和更新保密和应用配置。
存储编排：自动挂接存储系统，这些存储系统可以来自于本地、公共云提供商（例如：GCP和AWS）、网络存储(例如：NFS、iSCSI、Gluster、Ceph、Cinder和Floker等)。

第2章 Kubernetes的网络架构

Kubernetes网络完全是面向业务的，与集团公司的运行机制非常类似。

2.1 业务节点架构（控制面+业务面）

业务节点，不是单一节点，而是有无数个业务节点的集群。它类似集群公司的业务部门。

业务节点是指运营业务软件容器的机器，其功能相对简单，除了简单的自主管理和运行外，大部分业务的部署、分配、调度都是有外部的master来分配的。

业务节点主要的责任就是运行好指派、部署给自己的容器应用程序（通过pod组织相关联的容器），并监控容器运行的状态，把状态信息汇报给master。

其内部架构如下图所示：

（1）Docker：K8S是构建在Docker之上的，因此需要先安装docker引擎。类似开发团队的成员，不同的成员，负责不同的任务。

（2）Pod：承载多个业务强相关的容器，是K8S最基本的管理对象。类似敏捷团队的Scrum master。pod的思想就是敏捷团队的思想。没有scrum团队，就没有scrum敏捷开发，也不会有大规模敏捷SAFe。

（3）Kubelte（控制面和管理面）：负责内部业务管理。类似业务部门业务主管。

kubelet负责管理pods和它们里面的容器业务，容器images镜像、volumes、etc。

（4）kub-proxy（数据面或业务面）：负责对外客户接口，负责对外接“活”。类似业务部门的销售主管，只管“接活”和分配任务。至于任务如何实现，就是pod的职责了，而至于pod的组建，日常的管理，就是Kubelte的职责了。

每一个节点也运行一个简单的网络代理和负载均衡（详见services FAQ )（PS:官方英文）。

正如Kubernetes API里面定义，这些服务（详见the services doc）（PS:官方英文）也可以在各种终端中以轮询的方式做一些简单的TCP和UDP传输。

服务端点目前是通过DNS或者环境变量( Docker-links-compatible 和 KubernetesFOO_SERVICE_HOST 及 FOO_SERVICE_PORT 变量都支持)。

这些变量由服务代理所管理的端口来解析。

（5）Fluentd-elasticsearch：辅助组件，负责提供集群日志采集、存储与查询。

2.2 管理节点架构（控制面+管理面）

管理节点也不是单个节点，而是有多个管理节点的组。它类似集团公司的最高管理层，是集团公司的总部。既然是总部，就不是由单一个体组成，也是由多个不同的功能实体组成，不同的角色，也不是单一的实例，是有多个实例构成。管理节点是集群的核心！

管理节点负责整个集群的容器业务的动态部署，即不同节点能够负责什么样的业务（业务职责），完全由管理节点来安排和调度，基于容器和pod的业务软件，使得这种动态调度成为可能。

同时管理节点对来自于外部的业务请求进行动态负载均衡式的任务分派，按照一定的调度策略指派到不同的业务节点上。

K8S master只负责“控制面和管理面”的调度。

（1）Controller manager Server（控制管理服务器）：类似集团的董事会

Controller manager Server是集群的最高权力机构，用于执行大部分的集群层次（而不是节点层次）策略和功能。

执行生命周期功能(例如：命名空间创建和生命周期、事件垃圾收集、已终止垃圾收集、级联删除垃圾收集、node垃圾收集)，
执行API业务逻辑（例如：pod的弹性扩容）。

控制管理提供自愈能力、扩容、应用生命周期管理、服务发现、路由、服务绑定和提供。Kubernetes默认提供Replication Controller、Node Controller、Namespace Controller、Service Controller、Endpoints Controller、Persistent Controller、DaemonSet Controller等控制器。

（2）scheduler：调度器

类似集团公司的项目管理办公室，不负责指定策略，只负责按照既定的策略执行pod的调度和部署。

调度器按照既定的策略和当前数据库的信息，把未调度的pod通过binding api指派到节点上。调度器是可插拔的，并且我们期待支持多集群的调度，未来甚至希望可以支持用户自定义的调度器。

（3）RESTful API server：

API Server主要用来处理REST的操作，确保它们生效，并执行相关业务逻辑，以及更新etcd（或者其他存储）中的相关对象。

API Server是所有REST命令的入口，它的相关结果状态将被保存在etcd（或其他存储）中。

API Server的基本功能包括：

REST语义，监控，持久化和一致性保证，API 版本控制，放弃和生效
内置准入控制语义，同步准入控制钩子，以及异步资源初始化
API注册和发现

另外，API Server也作为集群的网关。

默认情况，客户端通过API Server对集群进行访问，客户端需要通过认证，并使用API Server作为访问Node和Pod（以及service）的堡垒和代理/通道。

（4）etcd：集团数据库

所有master的持续状态都存在etcd的一个实例中。这可以很好地存储配置数据。

因为采用watch(观察者)模式，所以各部件协调中的改变可以很快被察觉。API server，scheduler，controller都是通过etcd数据库进行通信。

（5）kubectl：集群的超级管理者

程序员和集群的管理员，才是K8S系统终极的上帝和最高权力机构，通过kubectl提供的UI和命令行接口。程序员和集群的管理员可是实时对K8S集群的人为干预！！！

2.3 系统架构

第3章 K8S系统的“三大面”数据流

（1）管理面

cubectl -> API server -> controller manager

cubectl -> API server -> scheduler manager

cubectl -> API server -> .............................

（2）控制面

controller manager -> API server -> etcd -> scheduler -> API server -> Kubelet -> pod

（3）业务面

来自于用户的服务请求，cubeprox -> pod

第4章 K8S的分层

4.1 协议分层

核心层：Kubernetes最核心的功能，对外提供API构建高层的应用，对内提供插件式应用执行环境
应用层：部署（无状态应用、有状态应用、批处理任务、集群应用等）和路由（服务发现、DNS解析等）
管理层：系统度量（如基础设施、容器和网络的度量），自动化（如自动扩展、动态Provision等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy等）
接口层：kubectl命令行工具、客户端SDK以及集群联邦
生态系统：在接口层之上的庞大容器集群管理调度的生态系统，可以划分为两个范畴
- Kubernetes外部：日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS应用、ChatOps等
- Kubernetes内部：CRI、CNI、CVI、镜像仓库、Cloud Provider、集群自身的配置和管理等

4.2 网络架构分层与生态

在该生态中，K8S处于四层，主要职责实现容器与服务的编排。

向下有：docker、LXD, rkt等容器引擎，docker只是其中一种容器的实现。

向上有：容器管理平台。

补充：Kubernetes的起源：从Borg到Kubernetes

在Docker 作为高级容器引擎快速发展的同时，Google也开始将自身在容器技术及集群方面的积累贡献出来。在Google内部，容器技术已经应用了很多年，Borg系统运行管理着成千上万的容器应用，在它的支持下，无论是谷歌搜索、Gmail还是谷歌地图，可以轻而易举地从庞大的数据中心中获取技术资源来支撑服务运行。

Borg是集群的管理器，在它的系统中，运行着众多集群，而每个集群可由成千上万的服务器联接组成，Borg每时每刻都在处理来自众多应用程序所提交的成百上千的Job, 对这些Job进行接收、调度、启动、停止、重启和监控。正如Borg论文中所说，Borg提供了3大好处:

1）隐藏资源管理和错误处理，用户仅需要关注应用的开发。

2) 服务高可用、高可靠。

3) 可将负载运行在由成千上万的机器联合而成的集群中。

作为Google的竞争技术优势，Borg理所当然的被视为商业秘密隐藏起来，但当Tiwtter的工程师精心打造出属于自己的Borg系统（Mesos）时， Google也审时度势地推出了来源于自身技术理论的新的开源工具。

2014年6月，谷歌云计算专家埃里克·布鲁尔（Eric Brewer）在旧金山的发布会为这款新的开源工具揭牌，它的名字Kubernetes在希腊语中意思是船长或领航员，这也恰好与它在容器集群管理中的作用吻合，即作为装载了集装箱（Container）的众多货船的指挥者，负担着全局调度和运行监控的职责。

虽然Google推出Kubernetes的目的之一是推广其周边的计算引擎（Google Compute Engine）和谷歌应用引擎（Google App Engine）。但Kubernetes的出现能让更多的互联网企业可以享受到连接众多计算机成为集群资源池的好处。

Kubernetes对计算资源进行了更高层次的抽象，通过将容器进行细致的组合，将最终的应用服务交给用户。Kubernetes在模型建立之初就考虑了容器跨机连接的要求，支持多种网络解决方案，同时在Service层次构建集群范围的SDN网络。其目的是将服务发现和负载均衡放置到容器可达的范围，这种透明的方式便利了各个服务间的通信，并为微服务架构的实践提供了平台基础。而在Pod层次上，作为Kubernetes可操作的最小对象，其特征更是对微服务架构的原生支持。

Kubernetes项目来源于Borg，可以说是集结了Borg设计思想的精华，并且吸收了Borg系统中的经验和教训。

Kubernetes作为容器集群管理工具，于2015年7月22日迭代到 v 1.0并正式对外公布，这意味着这个开源容器编排系统可以正式在生产环境使用。与此同时，谷歌联合Linux基金会及其他合作伙伴共同成立了CNCF基金会( Cloud Native Computing Foundation)，并将Kuberentes 作为首个编入CNCF管理体系的开源项目，助力容器技术生态的发展进步。Kubernetes项目凝结了Google过去十年间在生产环境的经验和教训，从Borg的多任务Alloc资源块到Kubernetes的多副本Pod，从Borg的Cell集群管理，到Kubernetes设计理念中的联邦集群，在Docker等高级引擎带动容器技术兴起和大众化的同时，为容器集群管理提供独了到见解和新思路。

作者主页(文火冰糖的硅基工坊)：文火冰糖（王文兵）的博客_文火冰糖的硅基工坊_CSDN博客

本文网址：https://blog.csdn.net/HiWangWenBing/article/details/122751006

以上是关于[云原生专题-23]：K8S - Kubernetes(K8S)整体概述与组件架构通俗讲解的主要内容，如果未能解决你的问题，请参考以下文章

[云原生专题-29]：K8S - 核心概念 - 名字空间/命名空间概念详解与主要操作案例

[云原生专题-46]：Kubesphere云治理-安装-在K8S的基础之上快速安装

[云原生专题-22]：K8S - 集群编排工具K8S与SWARM比较与技术选择

[云原生专题-43]：K8S - 核心概念 - placeholder - 加密数据

[云原生专题-42]：K8S - 核心概念 - placeholder-有状态服务

[云原生专题-28]：K8S - Kubernetes(K8S)Master集群构建与安装过程详细解读 - Dashboard的安装与访问