K8s对象，管理及其架构

k8s是kubernetes的简称，它是一个开源的容器管理系统, 用于系统自动化部署，扩展和管理。最初由谷歌设计，现在有Cloud Native Computing Foundation维护。目标是打造一个自动化部署，扩展和跨主机集群的应用程序容器操作平台。它可以与包含Docker在内的很多容器工具协同工作。

许多云服务系统提供基于k8s的平台，或者以基础设施即服务的理念把k8s部署为平台提供的服务。许多提供商也提供他们自己品牌的k8s系统。

1      k8s的对象 

Kubernetes定义了一组构件，它们共同提供了基于CPU、内存或自定义指标来部署、维护和扩展应用程序的机制。

 Kubernetes是松散耦合和可扩展的，以满足不同的工作负载。这种可扩展性很大程度上是由Kubernetes API提供的，内部组件以及在Kubernetes上运行的扩展和容器都会使用该API。

该平台通过将资源定义为Objects来对计算和存储资源进行控制，然后可以将其作为Objects进行管理。 

关键的对象有： 

1.1    Pods 

一个pod是对容器化组件进行分组的更高层次的抽象。一个pod由一个或多个容器组成，这些容器在主机上共存，并且可以共享资源。

Kubernetes中的基本调度单元是一个pod。 

Kubernetes中的每个pod在集群中都被分配了一个唯一的Pod IP地址，这使得应用程序可以在没有冲突风险的情况下使用端口。

在pod中，所有容器都可以在localhost上相互引用，但一个pod中的容器没有办法直接寻址另一个pod中的另一个容器 。

在此时，它必须使用Pod IP地址。 不过，应用程序开发人员永远不应该使用Pod IP地址来引用/调用另一个pod中的功能，因为Pod IP地址是短暂的，他们所引用的特定pod可能会在重新启动时被分配到另一个Pod IP地址。

正确的方式是他们应该使用对服务的引用，该服务在特定的Pod IP地址上拥有对目标pod的引用。

一个pod可以定义一个卷，如本地磁盘目录或网络磁盘，并将其暴露给pod中的容器。 

pod可以通过Kubernetes API手动管理，也可以将其管理委托给控制器。 这种卷也是配置图（通过容器可见的文件系统提供对配置的访问）和秘密（通过在仅对授权容器可见的文件系统上提供这些凭证，提供对安全访问远程资源所需的凭证的访问）等Kubernetes特性的基础。

1.2    复制集

复制集的目的是维持一组稳定的复制Pod在任何给定时间运行。因此，它经常被用来保证指定数量的相同Pod的可用性。

复制集也可以说是一种分组机制，它让Kubernetes可以维护给定pod所声明的实例数量。

复制集的定义使用了一个选择器，其评估的结果将识别所有与之相关联的pod。

1.3    Services

Kubernetes服务是一组共同工作的pod，比如多层应用的一个层级。构成服务的一组pod由标签选择器定义，Kubernetes提供了两种服务发现模式，使用环境变量或使用Kubernetes DNS，服务发现为服务分配一个稳定的IP地址和DNS名，并以循环的方式在匹配选择器的pod之间负载平衡该IP地址的网络连接的流量（即使故障导致pod从一台机器移动到另一台机器），默认情况下，一个服务暴露在集群内部（例如后端 pods 可能会被归为一个服务，来自前端 pods 的请求在它们之间进行负载均衡），但服务也可以暴露在集群之外（例如，客户机可以接触到前端 pods）。

简化的视图显示了服务如何与Kubernetes集群中的Pod网络交互。

1.4    卷

Kubernetes容器中的文件系统默认提供短暂的存储。这意味着重新启动pod会抹去这种容器上的任何数据，因此，这种形式的存储在除了琐碎的应用之外的任何应用中都是相当有限的。Kubernetes 卷提供了持久性存储，它存在于pod本身的生命周期内。这种存储也可以作为pod内容器的共享磁盘空间。卷被挂载在容器内的特定挂载点，这些挂载点由pod配置定义，不能挂载到其他卷上，也不能链接到其他卷。

同一卷可以被不同的容器挂载在文件系统树的不同点。

1.5    命名空间 

Kubernetes提供了一种将其管理的资源分割成非重叠的集合，称为命名空间。 它们旨在用于有许多用户的环境中，这些用户分布在多个团队，或项目中，甚至分离的环境，如开发、测试和生产。

1.6    配置图和秘密 

一个常见的应用挑战是决定在哪里存储和管理配置信息，其中一些可能包含敏感数据。配置数据可以是任何细粒度的东西，如单个属性，也可以是粗粒度的信息，如整个配置文件或JSON / XML文档。

Kubernetes提供了两种密切相关的机制来处理这一需求。"配置图 "和 "秘密"，这两个机制都允许在不需要构建应用的情况下进行配置更改。

来自配置图和秘密的数据将被提供给这些对象通过部署绑定到的每一个应用实例。只有当一个节点上的pod需要时，秘密和/或配置图才会被发送到该节点。

Kubernetes会将其保存在该节点的内存中。一旦依赖于秘密或配置图的pod被删除，所有绑定的秘密和配置图的内存副本也会被删除。这些数据通过两种方式之一被pod访问：

a)作为环境变量(当pod启动时，Kubernetes将创建环境变量)，或者

b)在容器文件系统上可用，只有在pod内可见。

数据本身存储在主机上，主机是一台高度安全的机器，任何人都不应该有登录权限。秘密和配置图最大的区别是秘密中的数据内容是base64编码的。(在新的k8s版本中，秘密是加密存储在etcd中的)

1.7    状态集

解决无状态应用的伸缩问题非常容易：只要增加更多的运行中的pod即可。这一点Kubernetes做得非常好。

有状态的工作负载要难得多，因为如果一个pod被重新启动，状态需要被保存，如果应用被放大或缩小，那么状态可能需要被重新分配。数据库是有状态工作负载的一个例子。当在高可用性模式下运行时，许多数据库都带有一个主实例和一个辅助实例的概念。

在这种情况下，实例的排序概念很重要。

其他的应用程序，如Kafka，在它们的经纪人之间分配数据，所以一个经纪人和另一个经纪人是不一样的。在这种情况下，实例唯一性的概念很重要。状态集是由Kubernetes提供的控制器，它在pod的实例中强制执行唯一性和排序的属性，可以用来运行有状态的应用程序。

1.8    Daemon集 

通常情况下，运行pod的位置是由Kubernetes 调度器中实现的算法决定的。但对于某些用例来说，可能需要在集群中的每一个节点上运行一个 pod。这对于像日志收集，和存储服务这样的用例是很有用的。做这种pod调度的能力是由名为Daemon集的功能实现的。

2      管理K8S对象 

Kubernetes提供了一些机制，允许人们管理、选择或操作其对象。

2.1    标签和选择器 

Kubernetes使客户端（用户或内部组件）能够将称为 "标签"的密钥附加到系统中的任何API对象上，如pods和节点。

相应地，"标签选择器"是针对标签的查询，这些查询可以解析到匹配的对象。 当定义一个服务时，人们可以定义标签选择器，这些标签选择器将被服务路由器/负载平衡器用来选择流量将被路由到的pod实例。

因此，只需改变pod的标签或改变服务上的标签选择器，就可以用来控制哪些pod获得流量，哪些不获得流量，这可以用来支持各种部署模式，如蓝绿部署或A-B测试。这种动态控制服务如何利用实现资源的能力，在基础设施中提供了一种松散的耦合。 

例如，如果一个应用的pods有系统层的标签（值如前端、后端）和release_track（值如canary、生产），那么对所有后端和canary节点的操作可以使用标签选择器，例如： 

tier=后端，release_track=canary。

2.2    字段选择器 

就像标签一样，字段选择器也可以让人选择Kubernetes资源。与标签不同的是，选择是基于被选择的资源固有的属性值，而不是用户定义的分类。metadata.name和metadata.namespace是所有Kubernetes对象上都会出现的字段选择器。可以使用的其他选择器取决于对象/资源类型。

2.3    复制控制器和部署 

复制集声明需要的pod实例数量，复制控制器管理系统，使运行的健康pod数量与复制集中声明的pod数量相匹配（通过评估其选择器确定）。 

部署是复制集的更高级别的管理机制。复制控制器管理副本集的规模，而部署将管理副本集的情况--是否需要推出更新，或回滚等。当部署规模扩大或缩小时，会导致复制集的声明发生变化--这种声明状态的变化由复制控制器管理。

2.4    集群API 

Kubernetes的基础设计原则允许人们以编程方式创建、配置和管理Kubernetes集群。这个功能是通过一个名为Cluster API的API来暴露的。API中体现的一个关键概念是，Kubernetes集群本身就是一个资源/对象，可以像其他Kubernetes资源一样进行管理。同样，组成集群的机器也被视为Kubernetes资源。API有两块--核心API，和提供者实现。提供者实现由云提供商的特定功能组成，让Kubernetes以一种与云提供商的服务和资源良好集成的方式提供集群API。

3      架构

Kubernetes遵循主/副本架构。Kubernetes的组件可以分为管理单个节点的组件和作为控制平面一部分的组件。

3.1    Kubernetes控制平面 

Kubernetes主控机是集群的主要控制单元，管理集群的工作负载，并指导整个系统的通信。Kubernetes控制平面由各种组件组成，每个组件都有自己的进程，既可以在单个主节点上运行，也可以在支持高可用性集群的多个主节点上运行，Kubernetes控制平面的各种组件如下： 

l  etcd：etcd是CoreOS开发的一个持久的、轻量级的、分布式的、键值数据存储，它可靠地存储集群的配置数据，可以表示集群在任何给定时间点的整体状态。

就像Apache ZooKeeper一样，etcd是一个在网络分区的情况下偏重一致性而非可用性的系统。这种一致性对于正确调度和操作服务至关重要。Kubernetes API服务器使用etcd的watch API来监控集群，并推出关键的配置更改，或者简单地将集群状态的任何分歧恢复到部署者声明的状态。举个例子，如果部署者指定某个pod的三个实例需要运行，这个事实就会存储在etcd中。如果发现只有两个实例在运行，那么这个delta将通过与etcd数据的比较被检测出来，Kubernetes将利用这一点来调度该pod的额外实例的创建。 

l  API服务器：API服务器是一个关键组件，它通过HTTP使用JSON为Kubernetes API提供服务，为Kubernetes提供内部和外部接口。

l  调度器：调度器是一个可插入的组件，它根据资源的可用性选择在哪个节点上运行未排定的pod(由调度器管理的基本实体)。调度器跟踪每个节点上的资源使用情况，以确保工作负载的调度不会超过可用资源。为此，调度器必须知道资源需求、资源可用性以及其他用户提供的约束条件和策略指令，如服务质量、亲和/反亲和要求、数据定位等。从本质上讲，调度器的作用是将资源 "供给 "与工作负载 "需求 "相匹配。

l  控制器管理器：控制器是一个调和循环，推动实际集群状态向所需的集群状态发展，与API服务器通信，以创建、更新和删除其管理的资源(pods、服务端点等)。控制器管理器是一个管理一组核心Kubernetes控制器的进程。

一种控制器是复制控制器，它通过在集群中运行指定数量的pod副本来处理复制和扩展。它还处理在底层节点发生故障时创建替换的pod。

其他控制器作为核心Kubernetes系统一部分包括Daemon集控制器，用于在每台机器（或一些机器子集）上精确地运行一个pod，以及Job控制器，用于运行完成的pod，例如作为批处理作业的一部分。 控制器管理的pod集由标签选择器决定，标签选择器是控制器定义的一部分。

3.2    Kubernetes节点

Node，又称Worker或Minion，是部署容器（工作负载）的机器。集群中的每个节点都必须运行一个容器运行时，如Docker，以及下面提到的组件，用于与这些容器的网络配置的主要的通信。 

l  Kubelet：Kubelet负责每个节点的运行状态，确保节点上的所有容器都是健康的。它负责按照控制平面的指示启动、停止和维护组织成豆荚的应用容器。

l  Kubelet监控一个pod的状态，如果不在所需状态，pod会重新部署到同一个节点。节点状态每隔几秒就会通过心跳消息传递给主站。一旦primary检测到节点故障，复制控制器就会观察到这种状态变化，并在其他健康节点上启动吊舱 。

l  Kube-proxy： Kube-proxy是一个网络代理和负载均衡器的实现，它支持服务抽象和其他网络操作，它负责根据传入请求的IP和端口号将流量路由到合适的容器。

l  容器运行时：容器居于pod内部。容器是微服务的最低层，它容纳了正在运行的应用程序、库以及它们的依赖关系。容器可以通过外部IP地址向外部暴露。Kubernetes从第一个版本开始就支持Docker容器，2016年7月增加了rkt容器引擎。

3.3    附加组件 

附加组件的操作就像在集群内运行的其他应用一样：它们通过pods和服务来实现，唯一不同的是它们实现了Kubernetes集群的功能。pods可以由Deployments、复制控制器等管理。附加组件有很多，而且这个列表还在不断增加。其中比较重要的有： 

l  DNS：所有的Kubernetes集群都应该有集群DNS；这是一个强制功能。除了环境中的其他DNS服务器外，集群DNS是一个DNS服务器，它为Kubernetes服务提供DNS记录。Kubernetes启动的容器会自动将此DNS服务器纳入其DNS搜索中。

l  Web UI：这是Kubernetes集群的一个通用的、基于Web的UI。它允许用户管理和排除在集群中运行的应用程序以及集群本身的故障。

l  容器资源监控：提供可靠的应用运行时，并能够根据工作负载进行扩展或缩减，意味着能够持续有效地监控工作负载性能。容器资源监控通过在中央数据库中记录有关容器的指标来提供这种能力，并提供一个UI来浏览这些数据。cAdvisor是一个从属节点上的组件，它提供了有限的度量监控能力。也有完整的度量管道，如Prometheus，可以满足大多数监控需求。

l  集群级日志记录：日志应该有独立于节点、pod或容器的独立存储和生命周期。否则，节点或吊舱的故障会导致事件数据的丢失。这种能力称为集群级日志记录，这种机制负责将容器日志保存到一个带有搜索/浏览界面的中央日志存储中。Kubernetes不提供日志数据的本地存储，但人们可以将许多现有的日志解决方案集成到Kubernetes集群中。

3.4    微服务 

Kubernetes通常被用作托管基于微服务的实现的方式，因为它及其相关的工具生态系统提供了解决任何微服务架构所需的所有关键问题功能。

3.4.1    Kubernetes持久存储 

容器是作为一种使软件可移植的方式出现的。容器包含了运行服务所需的所有包。提供的文件系统使得容器具有极强的可移植性，并且在开发中易于使用。一个容器可以从开发到测试或生产，不需要或需要相对较少的配置更改。 

历史上，Kubernetes只适合无状态服务。但是，很多应用都有数据库，需要持久化，这就导致了Kubernetes的持久化存储的产生。为容器实现持久化存储是Kubernetes管理员、DevOps和云工程师的首要挑战之一。容器可能是短暂的，但其越来越多的数据却不是，所以需要在容器终止或硬件故障时确保数据的持久生存。 

当使用Kubernetes或容器化应用部署容器时，公司经常意识到他们需要持久性存储。他们需要为容器使用的数据库、根镜像和其他数据提供快速可靠的存储。目前，用于Kubernetes的持久性存储由几个存储提供商提供如MayaData（OpenEBS--一个CNCF项目）、Portworx、Linstor、StorPool Storage]、StorageOS、NetApp、Rancher（Longhorn--另一个CNCF项目）和VMware。Rook是另一个流行的项目，主要用于连接Kubernetes和CEPH。

4      参考

https://kubernetes.io/

https://en.wikipedia.org/wiki/Kubernetes