带你玩转kubernetes-k8s（第52篇-Kubernetes开发指南）
本章将引入REST的概念，详细说明Kubernetes API的概念和使用方法，并举例说明如何基于Jersey和Fabric8框架访问Kubernetes API，深入分析基于这两个框架访问Kubernetes API的优缺点，最后对Kubernetes API的扩展进行详细说明。下面从REST开始说起。
REST简述
REST（Representational State Transfer，表述性状态传递）是由Roy Thomas Fielding博士在他的论文Architectural Styles and the Design of Network-based Software Architectures中提出的一个术语。REST本身只是为分布式超媒体系统设计的一种架构风格，而不是标准。
基于Web的架构实际上就是各种规范的集合，比如HTTP是一种规范，客户端服务器模式是另一种规范。每当我们在原有规范的基础上增加新的规范时，就会形成新的架构。而REST正是这样一种架构，它结合了一系列规范，形成了一种新的基于Web的架构风格。
传统的Web应用大多是B/S架构，涉及如下规范。
（1）客户端-服务器：这种规范的提出，改善了用户接口跨多个平台的可移植性，并且通过简化服务器组件，改善了系统的可伸缩性。最为关键的是通过分离用户接口和数据存储，使得不同的用户终端共享相同的数据成为可能。
（2）无状态性：无状态性是在客户端-服务器规范的基础上添加的又一层规范，它要求通信必须在本质上是无状态的，即从客户端到服务器的每个request都必须包含理解该request必需的所有信息。这个规范改善了系统的可见性（无状态性使得客户端和服务器端不必保存对方的详细信息，服务器只需要处理当前的request，而不必了解所有request的历史）、可靠性（无状态性减少了服务器从局部错误中恢复的任务量）、可伸缩性（无状态性使得服务器端可以很容易释放资源，因为服务器端不必在多个request中保存状态）。同时，这种规范的缺点也是显而易见的，不能将状态数据保存在服务器上，导致增加了在一系列request中发送重复数据的开销，严重降低了效率。
（3）缓存：为了改善无状态性带来的网络的低效性，客户端缓存规范出现。缓存规范允许隐式或显式地标记一个response中的数据，赋予了客户端缓存response数据的功能，这样就可以为以后的request共用缓存的数据消除部分或全部交互，提高了网络效率。但是客户端缓存了信息，所以客户端数据与服务器数据不一致的可能性增加，从而降低了可靠性。
B/S架构的优点是部署非常方便，在用户体验方面却不很理想。为了改善这种状况，REST规范出现。REST规范在原有B/S架构的基础上增加了三个新规范：统一接口、分层系统和按需代码。
（1）统一接口：REST架构风格的核心特征就是强调组件之间有一个统一的接口，表现为在REST世界里，网络上的所有事物都被抽象为资源，REST通过通用的链接器接口对资源进行操作。这样设计的好处是保证系统提供的服务都是解耦的，可极大简化系统，改善系统的交互性和可重用性。
（2）分层系统：分层系统规则的加入提高了各种层次之间的独立性，为整个系统的复杂性设置了边界，通过封装遗留的服务，使新的服务器免受遗留客户端的影响，也提高了系统的可伸缩性。
（3）按需代码：REST允许对客户端的功能进行扩展。比如，通过下载并执行applet或脚本形式的代码来扩展客户端的功能。但这在改善系统可扩展性的同时降低了可见性，所以它只是REST的一个可选约束。
REST架构是针对Web应用而设计的，其目的是为了降低开发的复杂性，提高系统的可伸缩性。REST提出了如下设计准则。
（1）网络上的所有事物都被抽象为资源（Resource）。
（2）每个资源都对应唯一的资源标识符（Resource Identifier）。
（3）通过通用的连接器接口（Generic Connector Interface）对资源进行操作。
（4）对资源的各种操作都不会改变资源标识符。
（5）所有操作都是无状态的（Stateless）。
REST中的资源指的不是数据，而是数据和表现形式的组合，比如“最新访问的10位会员”和“最活跃的10位会员”在数据上可能有重叠或者完全相同，而它们由于表现形式不同，被归为不同的资源，这也就是为什么REST的全名是Representational State Transfer。资源标识符就是URI（Uniform Resource Identifier），不管是图片、Word还是视频文件，甚至只是一种虚拟的服务，也不管是XML、TXT还是其他文件格式，全部通过URI对资源进行唯一标识。
REST是基于HTTP的，任何对资源的操作行为都通过HTTP来实现。以往的Web开发大多数用的是HTTP中的GET和POST方法，很少使用其他方法，这实际上是对HTTP的片面理解造成的。HTTP不仅仅是一个简单的运载数据的协议，还是一个具有丰富内涵的网络软件的协议，它不仅能对互联网资源进行唯一定位，还能告诉我们如何对该资源进行操作。HTTP把对一个资源的操作限制在4种方法（GET、POST、PUT和DELETE）中，这正是对资源CRUD操作的实现。由于资源和URI是一一对应的，在执行这些操作时URI没有变化，和以往的Web开发有很大的区别，所以极大地简化了Web开发，也使得URI可以被设计成能更直观地反映资源的结构。这种URI的设计被称作RESTful的URI，为开发人员引入了一种新的思维方式：通过URL来设计系统结构。当然，这种设计方式对于一些特定情况也是不适用的，也就是说不是所有URI都适用于RESTful。
REST之所以可以提高系统的可伸缩性，就是因为它要求所有操作都是无状态的。没有了上下文（Context）的约束，做分布式和集群时就更为简单，也可以让系统更为有效地利用缓冲池（Pool），并且由于服务器端不需要记录客户端的一系列访问，也就减少了服务器端的性能损耗。
Kubernetes API也符合RESTful规范，下面对其进行介绍。
Kubernetes API详解
Kubernetes API 概述
Kubernetes API是集群系统中的重要组成部分，Kubernetes中各种资源（对象）的数据都通过该API接口被提交到后端的持久化存储（etcd）中，Kubernetes集群中的各部件之间通过该API接口实现解耦合，同时Kubernetes集群中一个重要且便捷的管理工具kubectl也是通过访问该API接口实现其强大的管理功能的。Kubernetes API中的资源对象都拥有通用的元数据，资源对象也可能存在嵌套现象，比如在一个Pod里面嵌套多个Container。创建一个API对象是指通过API调用创建一条有意义的记录，该记录一旦被创建，Kubernetes就将确保对应的资源对象会被自动创建并托管维护。
在Kubernetes系统中，在大多数情况下，API定义和实现都符合标准的HTTP REST格式，比如通过标准的HTTP动词（POST、PUT、GET、DELETE）来完成对相关资源对象的查询、创建、修改、删除等操作。但同时，Kubernetes也为某些非标准的REST行为实现了附加的API接口，例如Watch某个资源的变化、进入容器执行某个操作等。另外，某些API接口可能违背严格的REST模式，因为接口返回的不是单一的JSON对象，而是其他类型的数据，比如JSON对象流或非结构化的文本日志数据等。
Kubernetes开发人员认为，任何成功的系统都会经历一个不断成长和不断适应各种变更的过程。因此，他们期望Kubernetes API是不断变更和增长的。同时，他们在设计和开发时，有意识地兼容了已存在的客户需求。通常，我们不希望将新的API资源和新的资源域频繁地加入系统，资源或域的删除需要一个严格的审核流程。
Kubernetes API文档官网为https://kubernetes.io/docs/reference，可以通过相关链接查看不同版本的API文档，例如Kubernetes 1.14版本的链接为https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.14。
在Kubernetes 1.13版本及之前的版本中，Master的API Server服务提供了Swagger格式的API网页。Swagger UI是一款REST API文档在线自动生成和功能测试软件，关于Swagger的内容请访问官网http://swagger.io。我们通过设置kube-apiserver服务的启动参数--enable-swagger-ui=true来启用Swagger UI页面，其访问地址为http://
单击api/v1可以查看所有API的列表，以创建一个Pod为例，找到Rest API的访问路径为“/api/v1/namespaces/{namespace}/pods”，单击链接展开，即可查看详细的API接口说明，单击Model链接，则可以查看文本格式显示的API接口描述
我们看到，在Kubernetes API中，一个API的顶层（Top Level）元素由kind、apiVersion、metadata、spec和status这5部分组成，接下来分别对这5部分进行说明。
1.kind
kind表明对象有以下三大类别。
（1）对象（objects）：代表系统中的一个永久资源（实体），例如Pod、RC、Service、Namespace及Node等。通过操作这些资源的属性，客户端可以对该对象进行创建、修改、删除和获取操作。
（2）列表（list）：一个或多个资源类别的集合。所有列表都通过items域获得对象数组，例如PodLists、ServiceLists、NodeLists。大部分被定义在系统中的对象都有一个返回所有资源集合的端点，以及零到多个返回所有资源集合的子集的端点。某些对象有可能是单例对象（singletons），例如当前用户、系统默认用户等，这些对象没有列表。
（3）简单类别（simple）：该类别包含作用在对象上的特殊行为和非持久实体。该类别限制了使用范围，它有一个通用元数据的有限集合，例如Binding、Status。
2.apiVersion
apiVersion表明API的版本号，当前版本默认只支持v1。
3.Metadata
Metadata是资源对象的元数据定义，是集合类的元素类型，包含一组由不同名称定义的属性。在Kubernetes中每个资源对象都必须包含以下3种Metadata。
（1）namespace：对象所属的命名空间，如果不指定，系统则会将对象置于名为default的系统命名空间中。
（2）name：对象的名称，在一个命名空间中名称应具备唯一性。
（3）uid：系统为每个对象都生成的唯一ID，符合RFC 4122规范的定义。
此外，每种对象都还应该包含以下几个重要元数据。
1）labels：用户可定义的“标签”，键和值都为字符串的map，是对象进行组织和分类的一种手段，通常用于标签选择器，用来匹配目标对象。
（2）annotations：用户可定义的“注解”，键和值都为字符串的map，被Kubernetes内部进程或者某些外部工具使用，用于存储和获取关于该对象的特定元数据。
（3）resourceVersion：用于识别该资源内部版本号的字符串，在用于Watch操作时，可以避免在GET操作和下一次Watch操作之间造成的信息不一致，客户端可以用它来判断资源是否改变。该值应该被客户端看作不透明，且不做任何修改就返回给服务端。客户端不应该假定版本信息具有跨命名空间、跨不同资源类别、跨不同服务器的含义。
（4）creationTimestamp：系统记录创建对象时的时间戳，符合RFC 3339规范。
（5）deletionTimestamp：系统记录删除对象时的时间戳，符合RFC 3339规范。
（6）selfLink：通过API访问资自身的URL，例如一个Pod的link可能是“/api/v1/namespaces/ default/pods/frontend-o8bg4”。
4.spec
spec是集合类的元素类型，用户对需要管理的对象进行详细描述的主体部分都在spec里给出，它会被Kubernetes持久化到etcd中保存，系统通过spec的描述来创建或更新对象，以达到用户期望的对象运行状态。spec的内容既包括用户提供的配置设置、默认值、属性的初始化值，也包括在对象创建过程中由其他相关组件（例如schedulers、auto-scalers）创建或修改的对象属性，比如Pod的Service IP地址。如果spec被删除，那么该对象将会从系统中删除。
5.Status
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可能附带一些信息，例如最后的探测时间或最后的转变时间。
Kubernetes从1.14版本开始，使用OpenAPI（https://www.openapis.org）的格式对API进行查询，其访问地址为http://
curl http://192.168.18.3;8080/openapi/v2 | jq
小结：
本节内容到此为止，如果大家是做运维的话，那么大家可以简单了解。
了解其中的原理即可。