七、工作负载

七、工作负载

1、什么是工作负载（Workloads）

• 工作负载是运行在 Kubernetes 上的一个应用程序。

• 一个应用很复杂，可能由单个组件或者多个组件共同完成。无论怎样我们可以用一组Pod来表示一个应用，也就是一个工作负载

• Pod又是一组容器（Containers）

• 所以关系又像是这样

  工作负载（Workloads）控制一组Pod

  Pod控制一组容器（Containers）

  ​ 比如Deploy（工作负载） 3个副本的nginx（3个Pod），每个nginx里面是真正的nginx容器（container）

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NiDWiolN-1657518906954)(images/Kubernetes/1619667328103.png)]

工作负载能让Pod能拥有自恢复能力。

会写Pod。研究不同的工作负载怎么控制Pod的行为

2、Pod

1、什么是Pod

https://kubernetes.io/zh/docs/concepts/workloads/pods/

• Pod是一组（一个或多个） 容器（docker容器）的集合 （就像在豌豆荚中）；这些容器共享存储、网络、以及怎样运行这些容器的声明。
• [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mqDRkjXJ-1657518906955)(images/Kubernetes/u=1896948306,2106475823&fm=26&gp=0.jpg)]
• 我们一般不直接创建Pod，而是创建一些工作负载由他们来创建Pod
• Pod的形式
  • Pod对容器有自恢复能力（Pod自动重启失败的容器）
  • Pod自己不能恢复自己，Pod被删除就真的没了，还是希望k8s集群能自己在其他地方再启动这个Pod
  • 单容器Pod
  • 多容器协同Pod。我们可以把另外的容器称为**SideCar（为应用赋能）**
  • Pod 天生地为其成员容器提供了两种共享资源：网络和存储。
• 一个Pod由一个Pause容器设置好整个Pod里面所有容器的网络、名称空间等信息
• systemctl status可以观测到。Pod和容器进程关系
  • kubelet启动一个Pod，准备两个容器，一个是Pod声明的应用容器（nginx），另外一个是Pause。Pause给当前应用容器设置好网络空间各种的。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-stQ35xr3-1657518906955)(images/Kubernetes/1619667914671.png)]

编写yaml测试：多容器协同

vi pod-multicontainer.yaml

apiVersion: v1
kind: Pod
metadata:
  name: "multi-container-pod"
  namespace: default
  labels:
    app: "multi-container-pod"
spec:
  volumes:    ### 以后见到的所有名字 都应该是一个合法的域名方式
  - name: nginx-vol
    emptyDir: {}  ### docker匿名挂载，外部创建一个位置  /abc
  containers:  ## kubectl exec -it podName  -c nginx-container（容器名）-- /bin/sh
  - name: nginx-container
    image: "nginx"
    volumeMounts:  #声明卷挂载  -v
      - name: nginx-vol
        mountPath: /usr/share/nginx/html
  - name: content-container
    image: "alpine"
    command: ["/bin/sh","-c","while true;do sleep 1; date > /app/index.html;done;"]
    volumeMounts: 
      - name: nginx-vol
        mountPath: /app

2、Pod使用

• 可以编写deploy等各种工作负载的yaml文件，最终创建出pod，也可以直接创建

• Pod的模板如下

•     # 这里是 Pod 模版
      apiVersion: v1
      kind: Pod
      metadata:
        name: my-pod
      spec:
        containers:
        - name: hello
          image: busybox
          command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
        restartPolicy: OnFailure
      # 以上为 Pod 模版
  

3、Pod生命周期

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KVzZnYeX-1657518906955)(images/Kubernetes/1619669494854.png)]

• Pod启动，会先依次执行所有初始化容器，有一个失败，则Pod不能启动
• 接下来启动所有的应用容器（每一个应用容器都必须能一直运行起来），Pod开始正式工作，一个启动失败就会尝试重启Pod内的这个容器，Pod只要是NotReady，Pod就不对外提供服务了

编写yaml测试生命周期

vi pod-lifecycle.yaml

• 应用容器生命周期钩子
• 初始化容器（也可以有钩子）
• 初始化容器必须有终结的那个时刻

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6jbCvjHC-1657518906955)(images/Kubernetes-上/image-20211110222406101.png)]

apiVersion: v1
kind: Pod
metadata:
  name: "pod-life-02"
  namespace: default
  labels:
    app: "pod-life-02"
spec:
  volumes:
  - name: content-vol
    emptyDir: {}
  initContainers:  ## Pod在启动containers之前，先要【运行完】initContainers的所有容器，所以这些容器必须有终结，不能一直运行
  - name: init-c-01
    image: alpine  ### 必须有终结的那个时刻，一般不要用一直启动的镜像
    command: ["/bin/sh","-c","echo 12222222 > /app/index.html;sleep 30;"]
    volumeMounts: 
     - name: content-vol
       mountPath: /app
  # - name: init-c-02
  #   image: alpine  ### 必须有终结的那个时刻，一般不要用一直启动的镜像
  #   command: ["/bin/sh","-c","echo 12222222 > /app/index.html;sleep 30;"]
  #   volumeMounts: 
  #    - name: content-vol
  #      mountPath: /app
  containers:
  ### docker run alpine 没有在后台一直启动的程序
  - name: pod-life-01
    image: "nginx" #默认的启动命令是启动nginx。nginx启动在后台一直有了
    volumeMounts: 
     - name: content-vol
       mountPath: /usr/share/nginx/html
  - name: pod-life-02
    image: "alpine"  #pod里面的containers都必须能启动起来，Pod会不断的重启这个容器
    command: ["/bin/sh","-c","sleep 30"]

临时容器：线上排错。

https://kubernetes.io/zh/docs/concepts/workloads/pods/ephemeral-containers/

有些容器基础镜像(好多东西都没有，比如wget、vim)。线上没法排错。使用临时容器进入这个Pod。临时容器共享了Pod的所有。临时容器有Debug的一些命令，排错完成以后，只要exit退出容器，临时容器自动删除

Java：dump， jre 50mb。jdk 150mb

jre 50mb。:jdk作为临时容器

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-cWUE1Hlk-1657518906955)(images/Kubernetes-上/image-20211110224937656.png)]

https://kubernetes.io/zh/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container

临时容器需要开启特性门控 --feature-gates=“EphemeralContainers=true”

在所有组件，api-server、kubelet、scheduler、controller-manager都得配置

1.21.0： 生产环境推荐后缀是 .5的版本

使用临时容器的步骤：

1、声明一个临时容器。准备好json文件

{
    "apiVersion": "v1",
    "kind": "EphemeralContainers",
    "metadata": {
            "name": "my-nginx666" //指定Pod的名字
    },
    "ephemeralContainers": [{
        "command": [
            "sh"
        ],
        "image": "busybox",  //jre的需要jdk来调试
        "imagePullPolicy": "IfNotPresent",
        "name": "debugger",
        "stdin": true,
        "tty": true,
        "terminationMessagePolicy": "File"
    }]
}

2、使用临时容器，应用一下即可

kubectl replace --raw /api/v1/namespaces/default/pods/my-nginx666【pod名】/ephemeralcontainers  -f ec.json

4、静态Pod

​ 在 /etc/kubernetes/manifests 位置放的所有Pod.yaml文件，机器启动kubelet自己就把他启动起来。

静态Pod一直守护在他的这个机器上

​ 静态 Pod（Static Pod） 直接由特定节点上的 kubelet 守护进程管理， 不需要API 服务器看到它们。 尽管大多数 Pod 都是通过控制面（例如，Deployment） 来管理的，对于静态 Pod 而言，kubelet 直接监控每个 Pod，并在其失效时重启之。

​ 静态 Pod 通常绑定到某个节点上的 kubelet。 其主要用途是运行自托管的控制面。 在自托管场景中，使用 kubelet 来管理各个独立的 控制面组件。

​ kubelet 自动尝试为每个静态 Pod 在 Kubernetes API 服务器上创建一个 镜像 Pod。 这意味着在节点上运行的 Pod 在 API 服务器上是可见的，但不可以通过 API 服务器来控制。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KpszlPT6-1657518906955)(images/Kubernetes-上/image-20211110153915251.png)]

5、Probe 探针机制（健康检查机制）

https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes

kubectl explain pod.spec.containers.readinessProbe

• 每个容器三种探针（Probe）

  • 启动探针（后来才加的） 一次性成功探针。 只要启动成功了

    • kubelet 使用启动探针，来检测应用是否已经启动。如果启动就可以进行后续的探测检查。慢容器一定指定启动探针。一直在等待启动
    • 启动探针成功以后就不用了，剩下存活探针和就绪探针持续运行

  • 存活探针

    • kubelet 使用存活探针，来检测容器是否正常存活。（有些容器可能产生死锁【应用程序在运行，但是无法继续执行后面的步骤】），如果检测失败就会重新启动这个容器
    • initialDelaySeconds： 3600（长了导致可能应用一段时间不可用） 5（短了陷入无限启动循环）

  • 就绪探针

    • kubelet 使用就绪探针，来检测容器是否准备好了可以接收流量。当一个 Pod 内的所有容器都准备好了，才能把这个 Pod 看作就绪了。用途就是：Service后端负载均衡多个Pod，如果某个Pod还没就绪，就会从service负载均衡里面剔除

  • 谁利用这些探针探测

• kubelet会主动按照配置给Pod里面的所有容器发送相应的探测请求

• Probe配置项

  • initialDelaySeconds：容器启动后要等待多少秒后存活和就绪探测器才被初始化，默认是 0 秒，最小值是 0。这是针对以前没有
  • periodSeconds：执行探测的时间间隔（单位是秒）。默认是 10 秒。最小值是 1。
  • successThreshold：探测器在失败后，被视为成功的最小连续成功数。默认值是 1。
    • 存活和启动探针的这个值必须是 1。最小值是 1。
  • failureThreshold：当探测失败时，Kubernetes 的重试次数。 存活探测情况下的放弃就意味着重新启动容器。 就绪探测情况下的放弃 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。
  • timeoutSeconds：探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。

https://kubernetes.io/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes

# 可以写下列字段
exec、httpGet、tcpSocket 【哪种方式探测】

failureThreshold # 失败阈值 连续几次失败才算真失败

initialDelaySeconds # 指定多少秒之后才执行探测

periodSeconds # 每隔几秒来运行这个

successThreshold # 成功阈值 连续几次成功才算成功 

terminationGracePeriodSeconds

timeoutSeconds	> # 探测超时时间 单位 秒  到了超时时间 还没返回结果说明失败

# 启动探针 vi  start-probe.yaml
apiVersion: v1
kind: Pod
metadata:
  name: "nginx-start-probe-test"
  namespace: default
  labels:
    app: "nginx-start-probe-test"
spec:
  volumes: 
  - name: nginx-vol
    hostPath: 
      path: /app
  containers:
  - name: nginx
    image: "nginx"
    startupProbe:
      exec: 
        command: ["/bin/sh","-c","cat /app/abc"] # 返回不是0，就是失败
      initialDelaySeconds: 20 # 指定多少秒之后才执行探测
      periodSeconds: 5 # 每隔几秒来运行这个
      timeoutSeconds: 5 # 探测超时时间 单位 秒  到了超时时间 还没返回结果说明失败
      successThreshold: 1 # 成功阈值 连续几次成功才算成功 
      failureThreshold: 3 # 失败阈值 连续几次失败才算真失败
    volumeMounts:
    - name: nginx-vol
      mountPath: /app

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xzAqH2T8-1657518906956)(images/Kubernetes-上/image-20211111205147489.png)]

一直没有就绪

# 到运行pod的机器上 创建这个文件
touch /app/abc
# 创建完后等待下一次探测就成功了

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DCiRz7qS-1657518906956)(images/Kubernetes-上/image-20211111205836369.png)]

# 存活探针 vi liveness-probe.yaml
apiVersion: v1
kind: Pod
metadata:
  name: "nginx-start-probe02"
  namespace: default
  labels:
    app: "nginx-start-probe02"
spec:
  volumes: 
  - name: nginx-vol
    hostPath: 
      path: /app
  - name: nginx-html
    hostPath: 
      path: /html
  containers:
  - name: nginx
    image: "nginx"
    startupProbe:
      exec: 
        command: ["/bin/sh","-c","cat /app/abc"] # 返回不是0，就是失败
      initialDelaySeconds: 20 # 指定多少秒之后才执行探测
      periodSeconds: 5 # 每隔几秒来运行这个
      timeoutSeconds: 5 # 探测超时时间 单位 秒  到了超时时间 还没返回结果说明失败
      successThreshold: 1 # 成功阈值 连续几次成功才算成功 
      failureThreshold: 3 # 失败阈值 连续几次失败才算真失败
    volumeMounts:
    - name: nginx-vol
      mountPath: /app
    - name: nginx-html 
      mountPath: /usr/share/nginx/html 
    livenessProbe: # nginx容器有没有 /abc.html，就绪探针
      # httpGet:
      #   host: 127.0.0.1
      #   path: /abc.html
      #   port: 80
      #   scheme: HTTP
      # periodSeconds: 5  ## 每隔几秒来运行这个
      # successThreshold: 1 ## 成功阈值，连续几次成才算成功
      # failureThreshold: 5 ## 失败阈值，连续几次失败才算真失败
      exec:
        command:  ["/bin/sh","-c","cat /usr/share/nginx/html/abc.html"]  ## 返回不是0，那就是探测失败
      # initialDelaySeconds: 20 ## 指定的这个秒以后才执行探测
      periodSeconds: 5  ## 每隔几秒来运行这个
      timeoutSeconds: 5  ##探测超时，到了超时时间探测还没返回结果说明失败
      successThreshold: 1 ## 成功阈值，连续几次成才算成功
      failureThreshold: 3 ## 失败阈值，连续几次失败才算真失败

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Ponjd8Gu-1657518906956)(images/Kubernetes-上/image-20211111211444928.png)]

到运行pod的机器上 创建这个文件

touch /html/abc.html

创建完后等待下一次探测就成功了

# 存活探针 vi pod-liveness.yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 18; rm -rf /tmp/healthy; sleep 600
    # 创建一个文件；睡30s；文件又删除，睡600秒
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5  #容器启动RUNNING 5秒以后再来探测
      periodSeconds: 5 #每隔5秒探测一次

# vi pod-probe.yaml
apiVersion: v1
kind: Pod
metadata:
  name: "nginx-start-probe02"
  namespace: default
  labels:
    app: "nginx-start-probe02"
spec:
  volumes:
  - name: nginx-vol
    hostPath: 
      path: /app
  - name: nginx-html
    hostPath: 
      path: /html
  containers:
  - name: nginx
    image: "nginx"
    ports:
    - containerPort: 80
    startupProbe:
      exec:
        command:  ["/bin/sh","-c","cat /app/abc"]  ## 返回不是0，那就是探测失败
      # initialDelaySeconds: 20 ## 指定的这个秒以后才执行探测
      periodSeconds: 5  ## 每隔几秒来运行这个
      timeoutSeconds: 5  ##探测超时，到了超时时间探测还没返回结果说明失败
      successThreshold: 1 ## 成功阈值，连续几次成才算成功
      failureThreshold: 3 ## 失败阈值，连续几次失败才算真失败
    volumeMounts:
    - name: nginx-vol
      mountPath: /app
    - name: nginx-html
      mountPath: /usr/share/nginx/html
    livenessProbe:   ## nginx容器有没有 /abc.html，就绪探针
      # httpGet:
      #   host: 127.0.0.1
      #   path: /abc.html
      #   port: 80
      #   scheme: HTTP
      # periodSeconds: 5  ## 每隔几秒来运行这个
      # successThreshold: 1 ## 成功阈值，连续几次成才算成功
      # failureThreshold: 5 ## 失败阈值，连续几次失败才算真失败
      exec:
        command:  ["/bin/sh","-c","cat /usr/share/nginx/html/abc.html"]  ## 返回不是0，那就是探测失败
      # initialDelaySeconds: 20 ## 指定的这个秒以后才执行探测
      periodSeconds: 5  ## 每隔几秒来运行这个
      timeoutSeconds: 5  ##探测超时，到了超时时间探测还没返回结果说明失败
      successThreshold: 1 ## 成功阈值，连续几次成才算成功
      failureThreshold: 3 ## 失败阈值，连续几次失败才算真失败
    readinessProbe: ##就绪检测，都是http
      httpGet:  
        # host: 127.0.0.1  ###不行 因为就绪探针没成功 所以容器起不来 就访问不了 如果自己另外起一个容器可以          host本机 可以不写
        path: /abc.html  ## 给容器发请求
        port: 80
        scheme: HTTP ## 返回不是0，那就是探测失败
      initialDelaySeconds: 2 ## 指定的这个秒以后才执行探测
      periodSeconds: 5  ## 每隔几秒来运行这个
      timeoutSeconds: 5  ##探测超时，到了超时时间探测还没返回结果说明失败
      successThreshold: 3 ## 成功阈值，连续几次成才算成功
      failureThreshold: 5 ## 失败阈值，连续几次失败才算真失败
        
    # livenessProbe:
    #   exec: ["/bin/sh","-c","sleep 30;abc "]  ## 返回不是0，那就是探测失败
    #   initialDelaySeconds: 20 ## 指定的这个秒以后才执行探测
    #   periodSeconds: 5  ## 每隔几秒来运行这个
    #   timeoutSeconds: 5  ##探测超时，到了超时时间探测还没返回结果说明失败
    #   successThreshold: 5 ## 成功阈值，连续几次成才算成功
    #   failureThreshold: 5 ## 失败阈值，连续几次失败才算真失败

微服务。 /health

K8S检查当前应用的状态；connection refuse；

SpringBoot 优雅停机：gracefulShowdown: true

pod.spec.terminationGracePeriodSeconds = 30s 优雅停机；给一个缓冲时间

健康检查 + 优雅停机 = 0宕机

start完成以后，liveness和readness并存。 liveness失败导致重启。readness失败导致不给Service负载均衡网络中加，不接受流量。 kubectl exec -it 就进不去。Kubectl describe 看看咋了。

3、Deployment

1、什么是Deployment

https://kubernetes.io/zh/docs/concepts/workloads/controllers/deployment/

• 一个 Deployment 为 Pods 和 ReplicaSets 提供声明式的更新能力。
• 你负责描述 Deployment 中的 目标状态，而 Deployment 控制器（Controller） 以受控速率更改实际状态， 使其变为期望状态；控制循环。 for(){ xxx controller.spec()}
• 不要管理 Deployment 所拥有的 ReplicaSet
• 我们部署一个应用一般不直接写Pod，而是部署一个Deployment
• Deploy编写规约 https://kubernetes.io/zh/docs/concepts/workloads/controllers/deployment/#writing-a-deployment-spec

   # Deployment：
   # 滚动更新：   10   2 - 8  4 ，  2 4   0 - 10
   # RS1  RS2 两个版本同时存在
   
   minReadySeconds: 10  这个Pod10s以后才认为是read状态，影响多久后杀死旧Pod

   paused	: false 当前是否停止状态，暂停更新

   progressDeadlineSeconds: 600  处理的最终期限，Deployment如果超过了这个指定的处理描述就会给集群汇报错误
     The maximum time in seconds for a deployment to make progress before it is
     considered to be failed. The deployment controller will continue to process
     failed deployments and a condition with a ProgressDeadlineExceeded reason
     will be surfaced in the deployment status. Note that progress will not be
     estimated during the time a deployment is paused. Defaults to 600s.

   replicas	:  Pod 期望的数量（副本数量），是  ReplicaSet  控制器实现的

   revisionHistoryLimit	: 旧副本集保留的数量，可回滚的数量，默认是10

   selector