前一篇文章，概念性地介绍了K8s的一些基础组件，如Pod、部署和服务。这篇文章，我打算写写如何使用YAML清单定义和配置这些资源。

 

实际上，在K8s集群中创建对象有几种方式 - 命令，或声明。两种方式区别不大。

不过实际应用中，一旦开始真正部署应用，最终都会走到YAML配置文件方式。这种方式也叫配置清单。每个资源类型的清单，例如部署、服务、入口，他们的格式会略有不同，尽管他们之间存在着共性。

这篇文章，我就着重写写如何使用YAML清单定义和配置这些资源。当然，涉及内容太多，我们还是面向实际应用，写写通用的，和最有针对性的配置格式，而不详细解释所有的配置选项和排列。

Pod和部署的配置清单

前文我们说过，Pod是K8s最小的可部署单元。我们部署Pod，不是部署单个容器，而是部署包含一个或多个容器的Pod。这个概念一定要清楚。

K8s中部署独立的Pod是可以的。但在实际应用中，最常见的做法是将Pod部署成为“部署资源”的一部分。

所以，通常我们的做法，是在部署清单中定义Pod资源，而不是创建一个Pod，然后创建一个部署来管理他们。换句话说，我们是创建了一个知道如何为我们创建Pod的部署。

我们先来看一个相对基础的部署清单：

apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx
spec:replicas: 3strategy: type: RollingUpdaterollingUpdate:maxUnavailable: 1maxSurge: 1maxUnavailable: 1selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.19.3ports:- containerPort: 80

YAML对空格敏感，所以写的时候一定要注意缩进。

1. apiVersion、kind、metadata

这是K8s配置清单的开头，每个清单都会有这三个项。

 

apiVersion: apps/v1

apiVersion用来指示K8s API的版本。K8s有很多个API版本。以下命令可以查询已经安装的全部版本。

% kubectl api-versions

K8s的每个版本都包含了不同的API资源版本。

大多数情况下，配置应用时不需要太多关注这个版本号，对应好就成。

 

kind: Deployment

定义清单的类型。前面说了，各种资源都有不同的配置清单。本例中是部署。

 

metadata:name: nginx-deploymentlabels:app: nginx

元数据提供了诸如资源名称以及附加到资源上的标签等细节。

需要注意一下：标签是与资源相关的键值对，后面我们会用到。本例中，我们只有一个标签app，值是nginx。

2. spec

这是K8s清单中的规范资源部分，这部分才是实际指定类型的资源定义，在本例中，是部署（kind: Deployment）的配置。

 

  replicas: 3strategy: type: RollingUpdaterollingUpdate:maxUnavailable: 1maxSurge: 1maxUnavailable: 1

副本和策略，定义了部署应该创建多少个Pod实例，以及创建他们应该使用的方法。本例中，我们希望K8s同时运行三个Pod，并且部署新版本时使用滚动更新。

在策略中，我们设置maxUnavilable为1，这是更新策略的一个额外设置，表示我们希望在发布部署新版本时，在需要用新版本替换旧版本的Pod过程中，或者开始新Pod之前，每次只删除一个旧Pod。

maxSurge和maxUnavailable也是额外设置。maxSurge控制滚动更新时一次应该添加多少额外的容器，而maxUnavilable则定义了一个容器要运行多少秒后才可被认为是可用的。

 

  selector:matchLabels:app: nginx

selector部分定义这个部署管理哪些Pod。这里面涉及到元数据和选择器的相互配合，我们后面会说到。

 

  template:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.19.3ports:- containerPort: 80

部署的spec节的最后一个部分是模板。这是一个清单内的清单，里面也同样有metadata和spec。这里的内容实际是一个Pod的定义配置清单。

因此，这整个部署清单定义了两种类型的资源：Pod，和用于管理Pod扩展和生命周期的部署。

上面这个Pod模板，定义了一个叫nginx的容器，是由nginx 1.19.3镜像构建的。这里containerPort定义了容器内公开的端口。默认80，可不写。不过我自己觉得，写出来是一个好习惯。

 

如果我们想在Pod中部署两个容器，则需要在containers下添加另一个：

template:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.19.3ports:- containerPort: 80- name: nginx1image: nginx:1.19.3ports:- containerPort: 8080

例子中，我们添加的第二个容器，名称叫nginx1，也是nginx 1.19.3镜像，端口在8080。

 

上面就是部署清单的基本内容。这部分内容很多，需要了可以查K8s相关的部分。

前面说了，K8s清单不同类型的规范会稍有不同，但他们的共同之处也很多，比如元数据和选择器。所以学通了一个，其它基本上也就通了。

标签和选择器的配合

标签是K8s中最广泛使用的一个概念，是与对象关联的一个键值对。每个对象都可以有几个不同的标签，但每个键只能定义一次。

看前边的例子：

metadata:name: nginx-deploymentlabels:app: nginx

有一个键名叫app，值是nginx。

同样，在spec的template中：

spec:template:metadata:labels:app: nginx

这里，我们向Pod添加了同样的键值对。

在需要的情况下，我们还可以添加其它的标签，例如：

metadata:labels:app: nginxenvironment: stagingsystem: frontend

这两个标签的用处，可以自己去查。

标签在命令行管理的时候非常有用。例如下面的命令：

kubectl get pods -l environment=staging,system=frontend

可以查出所有具有staging和frontend标签的Pod。

标签在这里，主要是提供附加信息。所以，实际中可以加上各种合适的标签。同样，在选择器定义时，也可以通过这些标签来区分不同的资源。例如：

selector:matchLabels:app: nginx

这里面，选择器定义了所选资源的条件。满足条件的资源，才会被匹配。例如，上面这个选择器将匹配所有具有app标签且值为nginx的Pod。

同样，对应上面的命令行，选择器可以写为：

selector:matchLabels:environment: stagingsystem: frontend

这儿要注意：这个匹配的全条件的，条件之间是与的关系。当然，还有一些资源可以支持更多的匹配表达式，例如：In、NotIn、Exists或DoesNotExist。

 

除了部署外，服务也使用相同的机制来定义它将数据传递给哪个Pod。

服务的配置清单

在前文中说过，服务可以看作集群内的负载均衡，负责隔离并转发向Pod发出的请求。

我们来看一个清单的例子：

apiVersion: v1
kind: Service
metadata:name: my-shop-backendlabels: app: my-shopsystem: backend
spec:type: ClusterIPselector:app: my-shopsystem: backendports:- port: 80targetPort: 8080protocol: TCP

1. apiVersion、kind、metadata

跟前边一样，先定义清单的资源类型，这回是服务，以及所需的API版本。元数据为服务指定了一个名称，并加了两个标签用来记录和提供信息。

2. spec

首先，需要定义服务类型。根据K8s的版本，这儿有4种选择：

• ClusterIP，默认值，定义服务只能从内部访问；

• NodePort，在每个节点自动生成的端口上公开服务；

• loadbalance，在连接AWS、Azure等云服务时，提供负载均衡；

• ExternalName，这个有点特殊，它不做代理或转发，而只提供内部的DNS服务。

实际应用中，通常就用默认的ClusterIP，把服务作为内部负载均衡器，并使用入口将外部请求转发到服务的结构就OK了。

下一个是选择器，这个配置具体控制负载均衡的实现配置。如前一节所写的，选择器将选择所有具有所需标签的Pod，在本例中是app:my-shop和system:backend。服务将把所有传入的请求路由到这些服务。看下面的部分：

spec:selector:app: my-shopsystem: backend

最后，是清单中的端口配置。例子中定义了服务将被公开的端口80以及要使用的协议，本例中是TCP。targetPort是Pod上的端口，表示请求将会被传发到8080。这一段单摘出来如下：

spec:ports:- port: 80targetPort: 8080protocol: TCP

这个部分因为涉及到网络，所以配置可以很复杂。必要时，可以参考K8s的文档。

 

在应用中，通常需要向外部公开某种HTTP服务。部署部分处理应用程序Pod的管理，服务提供多个Pod内部的负载均衡，而入口将应用暴露给外部。

入口的配置清单

前文中说过，入口充当内部K8s服务的外部负载均衡或反向代理。下面的例子展示了如何公开内部服务到外网：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:name: my-shop-backend-ingresslabels: app: my-shopsystem: backendannotations:nginx.ingress.kubernetes.io/rewrite-target: /
spec:rules:- http:host: api.my-shop.compaths:- path: /my-shopbackend:serviceName: my-shop-backendservicePort: 80

1. apiVersion、kind、metadata

同样，入口清单也包含API版本、类型和元数据。不同的是，入口的元数据还包含入口的名称以及关联对象的标签。

此外，还多了一个注释标签annotations。注释标签的工作原理与前面提到的标签很相似，也都是键值对。不同的是注释标签不能用来选择对象。

本例中，我们添加了注释nginx.ingress.kubernetes.io/rewrite-target，值为/。这个注释用到了Nginx入口控制器的一个特殊键值，用来告诉控制器重写传入请求的匹配路径为“/”。

例如，在以下路径收到一个请求：

/my-shop/orders/123

入口控制器将重写到：

/orders/123

 

另外，为了使用入口，集群中需要部署一个入口控制器。每个入口控制器会有不同的特性，都需要不同的注释来配置。因此，入口配置清单可能会根据不同的作用而有所不同。

2. spec

入口清单的spec部分包含配置由集群的入口控制器管理的反向代理所需要的全部规则。如果你用过Nginx、IIS或其它类似的反代，那应该会容易理解，规则很相似，都是定义了一组传入请求的规则，以决定将他们路由到什么路径。

入口清单可以定义多种规则，但一定要记着可部署单元的概念。我们应该为部署到K8s的每个应用配置单一入口，而不是跨应用去配置入口，尽管这样做技术上支持。

看上面例子的spec段：

spec:rules:- http:host: api.my-shop.compaths:- path: /my-shopbackend:serviceName: my-shop-backendservicePort: 80

通常我会习惯用主机来区分不同的应用，像例子中的api.my-shop.com。当然，您也可以通过匹配路径来定义，例如/my-shop。而这个会根据元数据中的重写定义注释被重写。

除了匹配传入的路径和主机外，清单中还需要定义请求转发的内部服务和端口。本例中，我们用了同样的80端口去路由到上一节中定义的后端服务中。

 

上面这个例子是最常见的一个入口清单定义，只将传入的请求与单个服务匹配。

有时候，可能会几种不同类型的Pod组成一个服务“微单元”。这种情况下，也可能会有几个K8s服务，并且基于路径将几个服务路由到单一入口内，这时候可以这样配置：

spec:rules:- http:paths:- path: /ordersbackend:serviceName: my-shop-orders-serviceservicePort: 80- http:paths:- path: /historybackend:serviceName: my-shop-order-history-backendservicePort: 80

 

在K8s配置时，入口中可以加入很多配置。这部分如果有问题，可以去翻K8s文档。

如果只是需要将应用部署到K8s，那上边的内容基本够用了。唯一要注意的是集群中用了哪个入口控制器。

总结一下

这篇文章是这个系列的第二篇。

这篇文章介绍了我们必须要知道的K8s的主要资源：Pod、部署、服务、入口的YAML基本配置，并列出了一些最重要的配置值。

K8s这个东西，做为一个大的分布式架构，肯定是比较复杂的。但实际应用中，不是每个内容都需要理解和应用。

做多了，就是套路。

蹚过了，就是经验。

（未完待续）

喜欢就来个三连，让更多人因你而受益