Deployment

Deployment用于部署无状态的服务，一般用于管理维护企业内部无状态的微服务，比如configserver、zuul、springboot等。

无状态服务：不会在本地存储持久化数据，多个服务实例对于同一个用户请求的响应结果是完全一致的。这种多服务实例之间是没有依赖关系，比如Web应用。在K8s控制器中动态启停无状态服务的Pod并不会对其它的Pod产生影响.

这种控制器并不直接管理Pod，而是通过管理Replicaset来间接管理Pod，即：Deployment 管理 Replicaset，Replicaset管理Pod。所以Deployment比Replicaset的功能更强大。

Deployment 的作用

滚动更新：通过Deployment可以方便地部署应用，并支持滚动更新，确保在更新过程中不中断服务。
副本管理：Deployment负责管理指定数量的Pod副本，确保始终有指定数量的实例在运行。
版本回滚：Deployment允许用户回滚到先前的应用版本，以应对更新引入的问题。
暂停和恢复：Deployment可以监控Pod的状态，当Pod发生故障时，会自动替换为新的Pod，确保应用的高可用性。

Deployment 语法

apiVersion: extensions/v1beta1  # 指定api版本，此值必须在kubectl api-versions中  
kind: Deployment  # 指定创建资源的角色/类型   
metadata:  # 资源的元数据/属性 
  name: demo  # 资源的名字，在同一个namespace中必须唯一
  namespace: test # 部署在哪个namespace中
  labels:  # 设定资源的标签
    app: nginx
    version: v1
spec: # 资源规范字段
  replicas: 1 # 声明副本数目
  revisionHistoryLimit: 3 # 保留历史版本
  selector: # 选择器
    matchLabels: # 匹配标签
      app: nginx
      version: v1
  minReadySeconds: 30 #定义新建的 Pod 经过多少秒后才被视为可用
  terminationGracePeriodSeconds: 30 #30秒内 (默认 30s) 还未完全停止，就发送 SIGKILL 信号强制杀死进程。
  progressDeadlineSeconds: 600 #升级过程中的最大时间(如果升级过程被暂停了，该时间也会同步暂停，时间不会一直增长)
  strategy: # 策略
    rollingUpdate: # 滚动更新
      maxSurge: 30% # 最大额外可以存在的副本数，可以为百分比，也可以为整数
      maxUnavailable: 30% # 示在更新过程中能够进入不可用状态的 Pod 的最大值，可以为百分比，也可以为整数
    type: RollingUpdate # 滚动更新策略
  template: # 模版
    metadata: # 资源的元数据/属性 
      annotations: # 自定义注解列表
        sidecar.istio.io/inject: "false" # 自定义注解名字
      labels: # 设定资源的标签
        app: nginx
        version: v1
    spec: # 资源规范字段
      containers:
      - name: nginx# 容器的名字   
        image: nginx:1.17.0 # 容器使用的镜像地址   
        imagePullPolicy: IfNotPresent # 每次Pod启动拉取镜像策略，三个选择 Always、Never、IfNotPresent
                                      # Always，每次都检查；
                                      # Never，每次都不检查（不管本地是否有）；
                                      # IfNotPresent，如果本地有就不检查，如果没有就拉取（手动测试时，已经打好镜像存在docker容器中时，
                                      #    使用存在不检查级别， 默认为每次都检查，然后会进行拉取新镜像，因镜像仓库不存在，导致部署失败）
        volumeMounts:       #文件挂载目录，容器内配置
        - mountPath: /data/     #容器内要挂载的目录
          name: share       #定义的名字，需要与下面vloume对应
        resources: # 资源管理
          limits: # 最大使用
            cpu: 300m # CPU，1核心 = 1000m
            memory: 500Mi # 内存，1G = 1000Mi
          requests:  # 容器运行时，最低资源需求，也就是说最少需要多少资源容器才能正常运行
            cpu: 100m
            memory: 100Mi
        livenessProbe: # pod 内部健康检查的设置
          httpGet: # 通过httpget检查健康，返回200-399之间，则认为容器正常
            path: /healthCheck # URI地址
            port: 8080 # 端口
            scheme: HTTP # 协议
            # host: 127.0.0.1 # 主机地址
          initialDelaySeconds: 30 # 表明第一次检测在容器启动后多长时间后开始
          timeoutSeconds: 5 # 检测的超时时间
          periodSeconds: 30 # 检查间隔时间
          successThreshold: 1 # 成功门槛
          failureThreshold: 5 # 失败门槛，连接失败5次，pod杀掉，重启一个新的pod
        readinessProbe: # Pod 准备服务健康检查设置
          httpGet:
            path: /healthCheck
            port: 8080
            scheme: HTTP
          initialDelaySeconds: 30
          timeoutSeconds: 5
          periodSeconds: 10
          successThreshold: 1
          failureThreshold: 5
        #也可以用这种方法   
        #exec: 执行命令的方法进行监测，如果其退出码不为0，则认为容器正常   
        #  command:   
        #    - cat   
        #    - /tmp/health   
        #也可以用这种方法   
        #tcpSocket: # 通过tcpSocket检查健康  
        #  port: number 
        ports:
          - name: http # 名称
            containerPort: 8080 # 容器开发对外的端口 
            protocol: TCP # 协议
      imagePullSecrets: # 镜像仓库拉取密钥
        - name: harbor-certification
      volumes:      #挂载目录在本机的路径
      - name: share #对应上面的名字
        hostPath:
          path: /data   #挂载本机的路径
      affinity: # 亲和性调试
        nodeAffinity: # 节点亲和力
          requiredDuringSchedulingIgnoredDuringExecution: # pod 必须部署到满足条件的节点上
            nodeSelectorTerms: # 节点满足任何一个条件就可以
            - matchExpressions: # 有多个选项，则只有同时满足这些逻辑选项的节点才能运行 pod
              - key: beta.kubernetes.io/arch
                operator: In
                values:
                - amd64

查看 Deployment 状态

# 查看 `Deployment` 总体的一个状态
kubectl get deployment

字段含义

DESIRED：期望的 Pod 数量；
CURRENT：当前实际 Pod 数量；
UP-TO-DATE：其实是到达最新的期望版本的 Pod 数量；
AVAILABLE：这个其实是运行过程中可用的 Pod 数量。后面会提到，这里 AVAILABLE 并不简单是可用的，也就是 Ready 状态的，它其实包含了一些可用超过一定时间长度的 Pod；
AGE：deployment 创建的时长，如80m表示80分钟。

管理模式

管理模式通过kubectl get pods --show-labels查看deployment创建的pod，可以看到类似的内容

NAME                                READY     STATUS    RESTARTS   AGE       LABELS
nginx-deployment-75675f5897-7ci7o   1/1       Running   0          18s       app=nginx,pod-template-hash=75675f5897
nginx-deployment-75675f5897-kzszj   1/1       Running   0          18s       app=nginx,pod-template-hash=75675f5897
nginx-deployment-75675f5897-qqcnn   1/1       Running   0          18s       app=nginx,pod-template-hash=75675f5897

可以看到最前面一段其实是 Pod 所属 Deployment.name；中间一段：template-hash，这里多个 Pod 是一样的，因为这三个 Pod 其实都是同一个 template 中创建出来的；最后一段，是一个随机的字符串，我们通过 get.pod 可以看到，Pod 的 ownerReferences 即 Pod 所属的 controller 资源，并不是 Deployment，而是一个 ReplicaSet。这个 ReplicaSet 的 name，其实是 deloyment.name 加上 pod.template-hash。所有的 Pod 都是 ReplicaSet 创建出来的，而 ReplicaSet 它对应的某一个具体的 Deployment.template 版本。

注意 ReplicaSet 的名称格式始终为 [Deployment 名称]-[哈希]。该名称将成为所创建的 Pod 的命名基础。其中的哈希字符串与 ReplicaSet 上的 pod-template-hash 标签一致。

Deployment 控制器将 pod-template-hash 标签添加到 Deployment 所创建或收留的每个 ReplicaSet 。

此标签可确保 Deployment 的子 ReplicaSets 不重叠。标签是通过对 ReplicaSet 的 PodTemplate 进行哈希处理。所生成的哈希值被添加到 ReplicaSet 选择算符、Pod 模板标签，并存在于在 ReplicaSet 可能拥有的任何现有 Pod 中。

Deployme Status

每一个资源都有它的 spec.Status。这里可以看一下，deploymentStatus 中描述的三个其实是它的 conversion 状态，也就是 Processing、Complete 以及 Failed。

以 Processing 为例：Processing 指的是 Deployment 正在处于扩容和发布中。比如说 Processing 状态的 deployment，它所有的 replicas 及 Pod 副本全部达到最新版本，而且是 available，这样的话，就可以进入 complete 状态。而 complete 状态如果发生了一些扩缩容的话，也会进入 processing 这个处理工作状态。

如果在处理过程中遇到一些问题：比如说拉镜像失败了，或者说 readiness probe 检查失败了，就会进入 failed 状态；如果在运行过程中即 complete 状态，中间运行时发生了一些 pod readiness probe 检查失败，这个时候 deployment 也会进入 failed 状态。进入 failed 状态之后，除非所有点 replicas 均变成 available，而且是 updated 最新版本，deployment 才会重新进入 complete 状态。

Kubernetes 之 Deployment