部署Dotnet Core应用到Kubernetes（二） (2)

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

 

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

template:
  metadata:
    labels:
      app: nginx
  spec:
    containers:

    - name: nginx
      image: nginx:1.19.3
      ports:
      - containerPort: 80

    - name: nginx1
      image: nginx:1.19.3
      ports:
      - containerPort: 8080

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

 

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

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

标签和选择器的配合

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

看前边的例子：

metadata:
  name: nginx-deployment
  labels:
    app: nginx

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

同样，在spec的template中：

spec:
  template:
    metadata:
      labels:
        app: nginx

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

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

metadata:
  labels:
    app: nginx
    environment: staging
    system: frontend

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

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

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

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

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

selector:
  matchLabels:
    app: nginx

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

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

selector:
  matchLabels:
    environment: staging
    system: frontend

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

 

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

服务的配置清单

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

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

apiVersion: v1
kind: Service
metadata:
  name: my-shop-backend
  labels: 
    app: my-shop
    system: backend
spec:
  type: ClusterIP
  selector:
    app: my-shop
    system: backend
  ports:
  - port: 80
    targetPort: 8080
    protocol: 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-shop
    system: backend

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

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

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