《Kubernetes进阶实战》第三章《资源管理基础》

有道云分享：资源管理基础

Kubernetes系统的API Server基于HTTP/HTTPS接受并响应客户端的操作请求，它提供了一种“基于资源”的RESTful风格的编程接口，将集群的各种组件都抽象成为标准的REST资源，并支持通过标准的HTTP方法以JSON为数据序列化方案进行资源管理操作。

REST意为“表征状态转移”，它是一种程序架构风格基本元素为资源，表征和行为。

Kubernetes系统将一切事物都抽象为API资源。

Kubernetes的API对象大体可分为工作负载（Workload），发现和负载均衡（Discovery & LB），配置和存储（Config & Storage），集群（Cluster）以及元数据（Metadata）五个类别，它们基本上都是围绕一个核心目的而设计：如何更好地运行和丰富Pod资源，从而为容器化应用提供更灵活，更完善的操作与管理组件

工作负载型资源

有状态和无状态的区别？

持久化应用和非持久化应用的区别?

ReplicationController:用于确保每个Pod副本在任一时刻均能满足目标数量，是上一代的无状态Pod应用控制器

ReplicaSet:新一代的ReplicationController，与ReplicationController的唯一区别仅在于支持的标签选择器不同，ReplicationController只支持等值选择器，而ReplicaSet还额外支持基于集合的选择器

Deployment:管理无状态的持久化应用；用于为Pod和ReplicaSet提供声明式更新，是建构在ReplicaSet之上的更为高级的控制器

StatefulSet:管理有状态的持久化应用；为每个Pod创建一个独有的持久性标识符，并会确保各Pod之间的顺序性

DaemonSet:用于确保每个节点都运行了某Pod的一个副本；DaemonSet常用于运行集群存储守护进程，还有日志收集进程，以及监控进程。

Job:用于管理运行完成后即可终止的应用，例如批处理作业任务

发现和负载均衡

Pod资源可能会因为任何意外故障而被重建，于是它需要固定的可被“发现”的方式。Pod资源仅在集群内可见，它的客户端也可能是集群内的其他Pod资源，若要开放给外部网络中的用户访问，则需要事先将其暴露到集群外部，并且要为同一种工作负载的访问进行负载均衡。

配置与存储

Kubernetes设计了Volume资源，它支持众多类型的存储设备或存储系统

ConfigMap资源能够以环境变量或存储卷的方式接入Pod资源的容器中，并且可被多个同类的Pod共享引用。不过，这种方式不适于存储敏感数据，那是另一个资源类型Secret的功能

集群级资源

Namespace:资源对象名称的作用范围，绝大多数对象都隶属于某个名称空间，默认时隶属于“default”

Node:集群的工作节点，其标识符在当前集群中必须唯一的

Role:名称空间级别的由规则组成的权限集合，可被RoleBinding引用

ClusterRole:Cluster级别的由规则组成的权限集合，可被RoleBinding和ClusterRoleBinding引用

RoleBinding：将Role中的许可权限绑定在一个或一组用户之上，它隶属于且仅能作用于一个名称空间；绑定时，可以引用同一名称空间中的Role，也可以引用全局名称空间中的ClusterRole

ClusterRoleBinding：将ClusterRole中定义的许可权限绑定在一个或一组用户之上；它能够引用全局名称空间中的ClusterRole，并能通过Subject添加相关信息

元数据型资源

此类资源对象用于为集群内部的其他资源配置其行为或特征。

在Kubernetes API中，一个API的顶层（Top Level）元素由kind、apiVersion、metadata、spec和status 五个核心部分组成，接下来，我们分别对这几个部分进行说明。

kind表明对象有以下三大类别。

（1）对象（objects）：代表在系统中的一个永久资源（实体），例如Pod、RC、Service、Namespace及Node等。通过操作这些资源的属性，客户端可以对该对象做创建、修改、删除和获取操作。

（2）列表（list）：一个或多个资源类别的集合。列表有一个通用元数据的有限集合。所有列表（lists）通过“items”域获得对象数组。例如PodLists、ServiceLists、NodeLists。大部分定义在系统中的对象都有一个返回所有资源（resource）集合的端点，以及零到多个返回所有资源集合的子集的端点。某些对象有可能是单例对象（singletons），例如当前用户、系统默认用户等，这些对象没有列表。

（3）简单类别（simple）：该类别包含作用在对象上的特殊行为和非持久实体。该类别限制了使用范围，它有一个通用元数据的有限集合，例如Binding、 Status。

apiVersion表明API的版本号，当前版本默认只支持v1。

Metadata是资源对象的元数据定义，是集合类的元素类型，包含一组由不同名称定义的属性。在Kubernetes中每个资源对象都必须包含以下3种Metadata。

（1）namespace：对象所属的命名空间，如果不指定，系统则会将对象置于名为“default”的系统命名空间中。

（2）name：对象的名字，在一个命名空间中名字应具备唯一性。

（3）uid：系统为每个对象生成的唯一ID，符合RFC 4122规范的定义。

此外，每种对象还应该包含以下几个重要元数据。

labels：用户可定义的“标签”，键和值都为字符串的map，是对象进行组织和分类的一种手段，通常用于标签选择器（Label Selector），用来匹配目标对象。
annotations：用户可定义的“注解”，键和值都为字符串的map，被Kubernetes内部进程或者某些外部工具使用，用于存储和获取关于该对象的特定元数据。
resourceVersion：用于识别该资源内部版本号的字符串，在用于Watch操作时，可以避免在GET操作和下一次Watch操作之间造成的信息不一致，客户端可以用它来判断资源是否改变。该值应该被客户端看作不透明，且不做任何修改就返回给服务端。客户端不应该假定版本信息具有跨命名空间、跨不同资源类别、跨不同服务器的含义。
creationTimestamp：系统记录创建对象时的时间戳，符合RFC 3339规范。
deletionTimestamp：系统记录删除对象时的时间戳，符合RFC 3339规范。
selfLink：通过API访问资源自身的URL，例如一个Pod的link可能是/api/v1/namespaces/ default/pods/frontend-o8bg4。

spec是集合类的元素类型，用户对需要管理的对象进行详细描述的主体部分都在spec里给出，它会被Kubernetes持久化到etcd中保存，系统通过spec的描述来创建或更新对象，以达到用户期望的对象运行状态。spec的内容既包括用户提供的配置设置、默认值、属性的初始化值，也包括在对象创建过程中由其他相关组件（例如schedulers、auto-scalers）创建或修改的对象属性，比如Pod的Service IP地址。如果spec被删除，那么该对象将会从系统中被删除。

Status用于记录对象在系统中的当前状态信息，它也是集合类元素类型，status在一个自动处理的进程中被持久化，可以在流转的过程中生成。如果观察到一个资源丢失了它的状态（Status），则该丢失的状态可能被重新构造。以Pod为例，Pod的status信息主要包括conditions、containerStatuses、hostIP、phase、podIP、startTime等。其中比较重要的两个状态属性如下。

（1）phase：描述对象所处的生命周期阶段，phase的典型值是“Pending”（创建中）“Running”“Active”（正在运行中）或“Terminated”（已终结），这几种状态对于不同的对象可能有轻微的差别，此外，关于当前phase附加的详细说明可能包含在其他域中。

（2）condition：表示条件，由条件类型和状态值组成，目前仅有一种条件类型Ready，对应的状态值可以为True、False或Unknown。一个对象可以具备多种condition，而condition的状态值也可能不断发生变化，condition可能附带一些信息，例如最后的探测时间或最后的转变时间。

API版本

为了在兼容旧版本的同时不断升级新的API，Kubernetes 提供了多版本API的支持能力，每个版本的API通过一个版本号路径前缀进行区分，例如/api/v1beta3。通常情况下，新旧几个不同的API版本都能涵盖所有的Kubernetes资源对象，在不同的版本之间这些API接口存在一些细微差别。Kubernetes开发团队基于API级别选择版本而不是基于资源和域级别，是为了确保API能够描述一个清晰的连续的系统资源和行为的视图，能够控制访问的整个过程和控制实验性API的访问。

API及版本发布建议描述了版本升级的当前思路。版本v1beta1、v1beta2和 v1beta3 为不建议使用（Deprecated）的版本，请尽快转到v1版本。在2015年6月4日，Kubernetes v1版本API正式发布。版本v1beta1和v1beta2 API在2015年6月1日被删除，版本v1beta3 API在2015年7月6日被删除。

API详细说明

API 资源使用REST模式，具体说明如下。

GET /<资源名的复数格式>：获得某一类型的资源列表，例如GET /pods 返回一个Pod资源列表。
POST /<资源名的复数格式>：创建一个资源，该资源来自用户提供的JSON对象。
GET /<资源名复数格式>/<名字>：通过给出的名称（Name）获得单个资源，例如GET /pods/first 返回一个名称为“first”的Pod。
DELETE /<资源名复数格式>/<名字>：通过给出的名字删除单个资源，删除选项（DeleteOptions）中可以指定的优雅删除（Grace Deletion）的时间（GracePeriodSeconds），该可选项表明了从服务端接收到删除请求到资源被删除的时间间隔（单位为秒）。不同的类别（Kind）可能为优雅删除时间（Grace Period）申明默认值。用户提交的优雅删除时间将覆盖该默认值，包括值为0的优雅删除时间。
PUT /<资源名复数格式>/<名字>：通过给出的资源名和客户端提供的JSON对象来更新或创建资源。
PATCH /<资源名复数格式>/<名字>：选择修改资源详细指定的域。

对于PATCH操作，目前Kubernetes API通过相应的HTTP首部“Content-Type”对其进行识别。

目前支持以下三种类型的PATCH操作。

JSON Patch, Content-Type: application/json-patch+json。在RFC6902的定义中，JSON Patch是执行在资源对象上的一系列操作，例如 {＂op＂: ＂add＂, ＂path＂: ＂/a/b/c＂, ＂value＂: [ ＂foo＂, ＂bar＂ ]}。详情请查看RFC6902说明，网址为HTTPs://tools.ietf.org/html/rfc6902。
Merge Patch, Content-Type: application/merge-json-patch+json。在RFC7386的定义中，Merge Patch必须包含对一个资源对象的部分描述，这个资源对象的部分描述就是一个JSON对象。该JSON对象被提交到服务端，并和服务端的当前对象合并，从而创建一个新的对象。详情请查看RFC73862说明，网址为HTTPs://tools.ietf.org/html/rfc7386。
Strategic Merge Patch, Content-Type: application/strategic-merge-patch+json。

Strategic Merge Patch是一个定制化的Merge Patch实现。接下来将详细讲解Strategic Merge Patch。

在标准的JSON Merge Patch中，JSON对象总是被合并（merge）的，但是资源对象中的列表域总是被替换的。通常这不是用户所希望的。例如，我们通过下列定义创建一个Pod资源对象：

spec:
containers:
- name: nginx
image: nginx-1.0

接着我们希望添加一个容器到这个Pod中，代码和上传的JSON对象如下所示：

PATCH /api/v1/namespaces/default/pods/pod-name
spec:
containers:
- name: log-tailer
image: log-tailer-1.0

如果我们使用标准的Merge Patch，则其中的整个容器列表将被单个的“log-tailer”容器所替换。然而我们的目的是两个容器列表能够合并。

为了解决这个问题，Strategic Merge Patch通过添加元数据到API对象中，并通过这些新元数据来决定哪个列表被合并，哪个列表不被合并。当前这些元数据作为结构标签，对于API对象自身来说是合法的。对于客户端来说，这些元数据作为Swagger annotations也是合法的。在上述例子中，向“containers”中添加“patchStrategy”域，且它的值为“merge”，通过添加“patchMergeKey”，它的值为“name”。也就是说，“containers”中的列表将会被合并而不是替换，合并的依据为“name”域的值。

此外，Kubernetes API添加了资源变动的“观察者”模式的API接口。

GET /watch/<资源名复数格式>：随时间变化，不断接收一连串的JSON对象，这些JSON对象记录了给定资源类别内所有资源对象的变化情况。
GET /watch/<资源名复数格式>/：随时间变化，不断接收一连串的JSON对象，这些JSON对象记录了某个给定资源对象的变化情况。

上述接口改变了返回数据的基本类别，watch动词返回的是一连串的JSON对象，而不是单个的JSON对象。并不是所有的对象类别都支持“观察者”模式的API接口，在后续的章节中将会说明哪些资源对象支持这种接口。

另外，Kubernetes还增加了HTTP Redirect与HTTP Proxy这两种特殊的API接口，前者实现资源重定向访问，后者则实现HTTP请求的代理。

API响应说明

API Server响应用户请求时附带一个状态码，该状态码符合HTTP规范。表3.1列出了API Server可能返回的状态码。

下表 API Server可能返回的状态码

在调用API接口发生错误时，Kubernetes 将会返回一个状态类别（Status Kind）。下面是两种常见的错误场景：

（1）当一个操作不成功时（例如，当服务端返回一个非2xx HTTP 状态码时）；

（2）当一个HTTP DELETE方法调用失败时。

状态对象被编码成JSON格式，同时该JSON对象被作为请求的响应体。该状态对象包含人和机器使用的域，这些域中包含来自API的关于失败原因的详细信息。状态对象中的信息补充了对HTTP状态码的说明。例如：

$ curl -v -k -H ＂Authorization: Bearer WhCDvq4VPpYhrcfmF6ei7V9qlbqTubUc＂ HTTPs://10.240.122.184:443/api/v1/namespaces/default/pods/grafana
> GET /api/v1/namespaces/default/pods/grafana HTTP/1.1
> User-Agent: curl/7.26.0
> Host: 10.240.122.184
> Accept: */*
> Authorization: Bearer WhCDvq4VPpYhrcfmF6ei7V9qlbqTubUc
>
< HTTP/1.1 404 Not Found
< Content-Type: application/json
< Date: Wed, 20 May 2015 18:10:42 GMT
< Content-Length: 232
<
{
＂kind＂: ＂Status＂,
＂apiVersion＂: ＂v1＂,
＂metadata＂: {},
＂status＂: ＂Failure＂,
＂message＂: ＂pods \＂grafana\＂ not found＂,
＂reason＂: ＂NotFound＂,
＂details＂: {
＂name＂: ＂grafana＂,
＂kind＂: ＂pods＂
},
＂code＂: 404
}