【kubernetes系列】kubernetes中的deployment

kubernetes中的deployment

Deployment是Kubernetes v1.2引入的概念，引入的目的是为了更好地解决Pod的编排问题，功能相对于replicas set、replicats controller来说更加强大。Deployment在内部使用了Replica Set来实现目的，无论从Deployment的作用与目的，它的YAML定义，还是从它的具体命令行操作来看，我们都可以把它看作RC的一次升级，两者相似度超过90%。

Deployment相对于RC的一个最大升级是我们随时知道当前Pod“部署”的进度。实际上由于一个Pod的创建、调度、绑定节点及在目标Node上启动对应的容器这一完整过程需要一定的时间，所以我们期待系统启动N个Pod副本的目标状态，实际上是一个连续变化的“部署过程”导致的最终状态。

Deployment的典型使用场景有以下几个。
创建一个Deployment对象来生成对应的Replica Set并完成Pod副本的创建过程。
检查Deployment的状态来看部署动作是否完成（Pod副本的数量是否达到预期的值）。
更新Deployment以创建新的Pod（比如镜像升级）。
如果当前Deployment不稳定，则回滚到一个早先的Deployment版本。
暂停Deployment以便于一次性修改多个PodTemplateSpec的配置项，之后再恢复Deployment，进行新的发布。
扩展Deployment以应对高负载。
查看Deployment的状态，以此作为发布是否成功的指标。
清理不再需要的旧版本ReplicaSets。
Deployment的定义与Replica Set的定义很类似，除了Kind类型有所区别：

apiVersion: apps/v1	apiVersion: apps/v1
kind: Deployment	kind: ReplicaSet
metadata:	metadata:
name: my-nginx	name: my–nginx

示例
下面我们通过运行一些例子来一起直观地感受这个新概念。首先创建一个名为my-nginx.yaml的Deployment描述文件，内容如下：
在这里插入代码片apiVersion: apps/v1

kind: Deployment
metadata:
  name: my-nginx
  namespace: default
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: nginx
      role: gateway
      tier: frontend
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
        role: gateway
        tier: frontend
    spec:
      containers:
        - name: nginx-gateway
          image: nginx
          resources:
            requests:
              cpu: 100m
              memory: 100Mi
          volumeMounts:
            - name: nginx-conf
              subPath: nginx.conf
              mountPath: /etc/nginx/nginx.conf
            - name: nginx-app
              mountPath: /etc/nginx/conf.d
            - name: nginx-html
              mountPath: /data/app
          ports:
            - containerPort: 80
      volumes:
        - name: nginx-conf
          configMap:
            name: nginx-conf
        - name: nginx-app
          configMap:
            name: nginx-app
        - name: nginx-html
          configMap:
            name: nginx-html

运行下述命令创建Deploymeny:
kubectl create -f tomcat-deployment.yaml
deployment “my-nginx” created

运行下述命令查看Deployment的信息：
kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
my-nginx 1 1 1 1 4m
对上述输出中涉及的数量解释如下：
DESIRED：Pod副本数量的期望值，即Deployment里定义的Replica。
CURRENT：当前Replica的值，实际上是Deployment所创建的Replica Set里的Replica值，这个值不断增加，直到达到DESIRED为止，表明整个部署过程完成。
UP-TO-DATE：最新版本的Pod副本数量，用于指示在滚动升级的过程中，有多少个Pod副本已经成功升级。
AVAILABLE：当前集群中可用的Pod副本数量，即集群中当前存活的Pod数量。
运行下述命令查看对应的Replica Set，我们看到它的命名与Deployment的名字有关系：

kubectl get rs
NAME DESIRED CURRENT AGE
my-nginx-1452590284 1 1 1m
运行下述命令查看创建的Pod，我们发现Pod的命名以Deployment对应的Replica Set的名字为前缀，这种命名很清晰地表明了一个Replica Set创建了哪些Pod，对于滚动升级这种复杂的过程来说，很容易排查错误：

kubectl get pods
NAME READY STATUS RESTARTS AGE
my-nginx-1452590284-dqadk 1/1 Running 0 3m
运行kubectl describe deployments，可以清楚地看到Deployment控制的Pod的水平扩展过程。

相对来说，我们绝大多数的业务容器都是通过deployment的方式来部署，所以一些格式一定要注意。如标签要匹配，拉取私有镜像的secret，拉取镜像的策略，limit和request是否需要，configmap的设置和挂载，liveness和readiness是否需要设置，调度策略等。