Kubernetes（一）----概述

港控/mmm° 2022-12-25 12:56 101阅读 0赞

### 文章目录 ###

*  简介
 *  起源
 *  Kubernetes设计架构
 *  Kubernetes节点
 *  分层架构
 *  kubelet
 *  kube-proxy
 *  Kubernetes控制面板
 *  etcd
 *  Kubernetes API Server
 *  Scheduler
 *  Kubernetes控制管理服务器

# 简介 #

[k8s\_\_中文文档][k8s]  
**Kubernetes**是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效（powerful）,Kubernetes提供了应用部署，规划，更新，维护的一种机制。

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

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

在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（注释）。

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是时间和空间上的唯一。

# 起源 #

**大规模容器集群管理工具，从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]对计算资源进行了更高层次的抽象，通过将容器进行细致的组合，将最终的应用服务交给用户。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等高级引擎带动容器技术兴起和大众化的同时，为容器集群管理提供独了到见解和新思路。

# Kubernetes设计架构 #

Kubernetes集群包含有节点代理kubelet和Master组件(APIs, scheduler, etc)，一切都基于分布式的存储系统。下面这张图是Kubernetes的架构图。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nob3VjaGVuY2h1YW41MjUz_size_16_color_FFFFFF_t_70_pic_center][]

# Kubernetes节点 #

在这张系统架构图中，我们把服务分为运行在工作节点上的服务和组成集群级别控制板的服务。

Kubernetes节点有运行应用容器必备的服务，而这些都是受Master的控制。

每次个节点上当然都要运行Docker。Docker来负责所有具体的映像下载和容器运行。

Kubernetes主要由以下几个核心组件组成：

*  etcd保存了整个集群的状态；
 *  apiserver提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；
 *  controller manager负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；
 *  scheduler负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；
 *  kubelet负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理；
 *  Container runtime负责镜像管理以及Pod和容器的真正运行（CRI）；
 *  kube-proxy负责为Service提供cluster内部的服务发现和负载均衡；

除了核心组件，还有一些推荐的Add-ons：

*  kube-dns负责为整个集群提供DNS服务
 *  Ingress Controller为服务提供外网入口
 *  Heapster提供资源监控
 *  Dashboard提供GUI
 *  Federation提供跨可用区的集群
 *  Fluentd-elasticsearch提供集群日志采集、存储与查询

![img][]

![img][img 1]

# 分层架构 #

Kubernetes设计理念和功能其实就是一个类似Linux的分层架构，如下图所示

![img][img 2]

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

# kubelet #

kubelet负责管理[pods][]和它们上面的容器，images镜像、volumes、etc。

# kube-proxy #

每一个节点也运行一个简单的网络代理和负载均衡（详见[services FAQ][] )（PS:官方 英文）。 正如Kubernetes API里面定义的这些服务（详见[the services doc][]）（PS:官方 英文）也可以在各种终端中以轮询的方式做一些简单的TCP和UDP传输。

服务端点目前是通过DNS或者环境变量( Docker-links-compatible 和 Kubernetes\{FOO\}\_SERVICE\_HOST 及 \{FOO\}\_SERVICE\_PORT 变量都支持)。这些变量由服务代理所管理的端口来解析。

# Kubernetes控制面板 #

Kubernetes控制面板可以分为多个部分。目前它们都运行在一个*master* 节点，然而为了达到高可用性，这需要改变。不同部分一起协作提供一个统一的关于集群的视图。

# etcd #

所有master的持续状态都存在etcd的一个实例中。这可以很好地存储配置数据。因为有watch(观察者)的支持，各部件协调中的改变可以很快被察觉。

# Kubernetes API Server #

API服务提供[Kubernetes API][] （PS:官方 英文）的服务。这个服务试图通过把所有或者大部分的业务逻辑放到不两只的部件中从而使其具有CRUD特性。它主要处理REST操作，在etcd中验证更新这些对象（并最终存储）。

# Scheduler #

调度器把未调度的pod通过binding api绑定到节点上。调度器是可插拔的，并且我们期待支持多集群的调度，未来甚至希望可以支持用户自定义的调度器。

# Kubernetes控制管理服务器 #

所有其它的集群级别的功能目前都是由控制管理器所负责。例如，端点对象是被端点控制器来创建和更新。这些最终可以被分隔成不同的部件来让它们独自的可插拔。

[replicationcont][][roller][replicationcont]（PS:官方 英文）是一种建立于简单的 [pod][pods] API之上的一种机制。一旦实现，我们最终计划把这变成一种通用的插件机制。

[k8s]: https://www.kubernetes.org.cn/k8s
[Pod]: https://www.kubernetes.org.cn/tags/pod
[Kubernetes]: https://www.kubernetes.org.cn/
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Nob3VjaGVuY2h1YW41MjUz_size_16_color_FFFFFF_t_70_pic_center]: /images/20221120/51c3bd4d384f44ada6c281901c622bd4.png
[img]: https://img-blog.csdnimg.cn/img_convert/71bd7db7b5fc7e68bb611e9e4c3d0887.png
[img 1]: https://img-blog.csdnimg.cn/img_convert/d4ae040c1ec215e3d04a2a53c20a3b35.png
[img 2]: https://img-blog.csdnimg.cn/img_convert/6f98c4c10ea6a6ed50ae24698667d1c0.png
[pods]: https://www.kubernetes.org.cn/kubernetes-pod
[services FAQ]: https://github.com/kubernetes/kubernetes/wiki/Services-FAQ
[the services doc]: https://github.com/kubernetes/kubernetes/blob/release-1.2/docs/user-guide/services.md
[Kubernetes API]: https://github.com/kubernetes/kubernetes/blob/release-1.2/docs/api.md
[replicationcont]: https://github.com/kubernetes/kubernetes/blob/release-1.2/docs/user-guide/replication-controller.md