部署Dotnet Core应用到Kubernetes（二）

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

 

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

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

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

    为防止非授权转发，这儿给出本文的原文链接：https://www.cnblogs.com/tiger-wang/p/13996662.html

Pod和部署的配置清单

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

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

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

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

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  strategy: 
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
      maxUnavailable: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.19.3
        ports:
        - 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-deployment
  labels:
    app: nginx

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

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

2. spec

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

 

  replicas: 3
  strategy: 
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
      maxUnavailable: 1

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

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

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

 

  selector:
    matchLabels:
      app: nginx

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

 

  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.19.3
        ports:
        - containerPort: 80

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

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