#云原生征文#Kubernetes工作负载

Posted 2022-06-10 Lansonli

Kubernetes工作负载

 一、Workloads

什么是工作负载（Workloads）

• 工作负载是运行在 Kubernetes 上的一个应用程序。
• 一个应用很复杂，可能由单个组件或者多个组件共同完成。无论怎样我们可以用一组Pod来表示一个应用，也就是一个工作负载
• Pod又是一组容器（Containers）
• 所以关系又像是这样

• 工作负载（Workloads）控制一组Pod
• Pod控制一组容器（Containers）

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

二、Pod

 1、什么是Pod

• Pod是一组（一个或多个）容器（docker容器）的集合 （就像在豌豆荚中）；这些容器共享存储、网络、以及怎样运行这些容器的声明。
• 我们一般不直接创建Pod，而是创建一些工作负载由他们来创建Pod
• Pod的形式

• Pod对容器有自恢复能力（Pod自动重启失败的容器）
• Pod自己不能恢复自己，Pod被删除就真的没了（100，mysql、Redis、Order）还是希望k8s集群能自己在其他地方再启动这个Pod
• 单容器Pod
• 多容器协同Pod。我们可以把另外的容器称为​​SideCar（为应用赋能）​​
• Pod 天生地为其成员容器提供了两种共享资源：网络和存储

• 一个Pod由一个Pause容器设置好整个Pod里面所有容器的网络、名称空间等信息
• systemctl status可以观测到。Pod和容器进程关系

• kubelet启动一个Pod，准备两个容器，一个是Pod声明的应用容器（nginx），另外一个是Pause。Pause给当前应用容器设置好网络空间各种的。

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生命周期

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

编写yaml测试生命周期

• 应用容器生命周期钩子
• 初始化容器（也可以有钩子）

临时容器：线上排错。

有些容器基础镜像。线上没法排错。使用临时容器进入这个Pod。临时容器共享了Pod的所有。临时容器有Debug的一些命令，排错完成以后，只要exit退出容器，临时容器自动删除

例如： 

Java：dump， jre 50mb。jdk 150mb

jre 50mb: jdk作为临时容器

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

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

使用临时容器的步骤：

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一直守护在这个机器上

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

每个容器三种探针（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。

官方参考文档：​​配置存活、就绪和启动探测器 | Kubernetes​​

编写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  ###不行
        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 ## 失败阈值，连续几次失败才算真失败

三、Deployment

1、什么是Deployment

• 一个Deployment为​​Pods​​​ 和​​ReplicaSets​​ 提供声明式的更新能力。
• 你负责描述 Deployment 中的目标状态，而 Deployment 控制器（Controller） 以受控速率更改实际状态， 使其变为期望状态；控制循环。 for() xxx controller.spec()
• 不要管理 Deployment 所拥有的 ReplicaSet
• 我们部署一个应用一般不直接写Pod，而是部署一个Deployment
• Deploy编写规约​​Deployments | Kubernetes​​

2、Deployment创建

• 基本格式

• ​​.metadata.name​​指定deploy名字
• ​​replicas​​ 指定副本数量
• ​​selector​​ 指定匹配的Pod模板。
• ​​template​​ 声明一个Pod模板

编写一个Deployment的yaml

赋予Pod自愈和故障转移能力

• 在检查集群中的 Deployment 时，所显示的字段有：

• ​​NAME​​ 列出了集群中 Deployment 的名称。
• ​​READY​​ 显示应用程序的可用的副本数。显示的模式是“就绪个数/期望个数”。
• ​​UP-TO-DATE​​ 显示为了达到期望状态已经更新的副本数。
• ​​AVAILABLE​​ 显示应用可供用户使用的副本数。
• ​​AGE​​ 显示应用程序运行的时间。

• ReplicaSet 输出中包含以下字段：

• ​​NAME​​ 列出名字空间中 ReplicaSet 的名称；
• ​​DESIRED​​ 显示应用的期望副本个数，即在创建 Deployment 时所定义的值。 此为期望状态；
• ​​CURRENT​​ 显示当前运行状态中的副本个数；
• ​​READY​​ 显示应用中有多少副本可以为用户提供服务；
• ​​AGE​​ 显示应用已经运行的时间长度。
• 注意：ReplicaSet 的名称始终被格式化为​​[Deployment名称]-[随机字符串]​​。 其中的随机字符串是使用 pod-template-hash 作为种子随机生成的。

一个Deploy产生三个

• Deployment资源
• replicaset资源
• Pod资源

Deployment控制RS，RS控制Pod的副本数

ReplicaSet： 只提供了副本数量的控制功能

Deployment： 每部署一个新版本就会创建一个新的副本集，利用他记录状态，回滚也是直接让指定的rs生效

3、Deployment 更新机制

• 仅当 Deployment Pod 模板（即​​.spec.template​​）发生改变时，例如模板的标签或容器镜像被更新， 才会触发 Deployment 上线。其他更新（如对 Deployment 执行扩缩容的操作）不会触发上线动作。
• 上线动作 原理： 创建新的rs，准备就绪后，替换旧的rs（此时不会删除，因为​​revisionHistoryLimit​​ 指定了保留几个版本）
• 常用的kubectl 命令

################更新#################################
#kubectl  set image  deployment资源名  容器名=镜像名
kubectl set image deployment.apps/nginx-deployment php-redis=tomcat:8 --record
## yaml提取可更新的关键所有字段计算的hash。
web---- /hello
postman   aservice- /hello

#或者直接修改定义也行
kubectl edit deployment.v1.apps/nginx-deployment
#查看状态
kubectl rollout status deployment.v1.apps/nginx-deployment

################查看历史并回滚####################################
#查看更新历史-看看我们设置的历史总记录数是否生效了
kubectl rollout history deployment.v1.apps/nginx-deployment
#回滚
kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2

###############累计更新##############
#暂停记录版本
kubectl rollout pause deployment.v1.apps/nginx-deployment
#多次更新操作。
##比如更新了资源限制
kubectl set resources deployment.v1.apps/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi
##比如更新了镜像版本
kubectl set image deployment.apps/nginx-deployment php-redis=tomcat:8
##在继续操作多次
##看看历史版本有没有记录变化
kubectl rollout history deployment.v1.apps/nginx-deployment
#让多次累计生效
kubectl rollout resume deployment.v1.apps/nginx-deployment

3.1、比例缩放（Proportional Scaling）

maxSurge（最大增量）：除当前数量外还要添加多少个实例。

maxUnavailable（最大不可用量）：滚动更新过程中的不可用实例数。

3.2、HPA（动态扩缩容）

概念：​​Pod 水平自动扩缩 | Kubernetes​​

实战：​​HorizontalPodAutoscaler 演练 | Kubernetes​​

3.2.1、需要先安装metrics-server  

​​GitHub - kubernetes-sigs/metrics-server: Scalable and efficient source of container resource metrics for Kubernetes built-in autoscaling pipelines.​​

3.2.2、安装步骤  

apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    k8s-app: metrics-server
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
    rbac.authorization.k8s.io/aggregate-to-view: "true"
  name: system:aggregated-metrics-reader
rules:
- apiGroups:
  - metrics.k8s.io
  resources:
  - pods
  - nodes
  verbs:
  - get
  - list
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    k8s-app: metrics-server
  name: system:metrics-server
rules:
- apiGroups:
  - ""
  resources:
  - pods
  - nodes
  - nodes/stats
  - namespaces
  - configmaps
  verbs:
  - get
  - list
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server-auth-reader
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: extension-apiserver-authentication-reader
subjects:
- kind: ServiceAccount
  name: metrics-server
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server:system:auth-delegator
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:auth-delegator
subjects:
- kind: ServiceAccount
  name: metrics-server
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    k8s-app: metrics-server
  name: system:metrics-server
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:metrics-server
subjects:
- kind: ServiceAccount
  name: metrics-server
  namespace: kube-system
---
apiVersion: v1
kind: Service
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server
  namespace: kube-system
spec:
  ports:
  - name: https
    port: 443
    protocol: TCP
    targetPort: https
  selector:
    k8s-app: metrics-server
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server
  namespace: kube-system
spec:
  selector:
    matchLabels:
      k8s-app: metrics-server
  strategy:
    rollingUpdate:
      maxUnavailable: 0
  template:
    metadata:
      labels:
        k8s-app: metrics-server
    spec:
      containers:
      - args:
        - --cert-dir=/tmp
        - --kubelet-insecure-tls
        - --secure-port=4443
        - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
        - --kubelet-use-node-status-port
        image: registry.cn-hangzhou.aliyuncs.com/lanson_k8s_images/metrics-server:v0.4.3
        imagePullPolicy: IfNotPresent
        livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /livez
            port: https
            scheme: HTTPS
          periodSeconds: 10
        name: metrics-server
        ports:
        - containerPort: 4443
          name: https
          protocol: TCP
        readinessProbe:
          failureThreshold: 3
          httpGet:
            path: /readyz
            port: https
            scheme: HTTPS
          periodSeconds: 10
        securityContext:
          readOnlyRootFilesystem: true
          runAsNonRoot: true
          runAsUser: 1000
        volumeMounts:
        - mountPath: /tmp
          name: tmp-dir
      nodeSelector:
        kubernetes.io/os: linux
      priorityClassName: system-cluster-critical
      serviceAccountName: metrics-server
      volumes:
      - emptyDir: 
        name: tmp-dir
---
apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
  labels:
    k8s-app: metrics-server
  name: v1beta1.metrics.k8s.io
spec:
  group: metrics.k8s.io
  groupPriorityMinimum: 100
  insecureSkipTLSVerify: true
  service:
    name: metrics-server
    namespace: kube-system
  version: v1beta1
  versionPriority: 100

• kubectl apply 即可
• 全部runnning 用

• kubectl top nodes --use-protocol-buffers
• kubectl top pods --use-protocol-buffers

3.2.3、配置hpa测试

### 测试镜像 registry.cn-hangzhou.aliyuncs.com/lanson_k8s_images/php-hpa:latest

##应用的yaml已经做好
apiVersion: v1
kind: Service
metadata:
  name: php-apache
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: php-apache
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: php-apache
  name: php-apache
spec:
  replicas: 1
  selector:
    matchLabels:
      run: php-apache
  template:
    metadata:
      creationTimestamp: null
      labels:
        run: php-apache
    spec:
      containers:
      - image: registry.cn-hangzhou.aliyuncs.com/lanson_k8s_images/php-hpa:latest
        name: php-apache
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 200m

##hpa配置 hpa.yaml
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
spec:
  maxReplicas: 10
  minReplicas: 1
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  targetCPUUtilizationPercentage: 50
  
#3、进行压力测试
kubectl run -i --tty load-generator --image=busybox /bin/sh

#回车然后敲下面的命令
 kubectl run -i --tty load-generator --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"

3.3、Canary（金丝雀部署）

3.3.1、蓝绿部署VS金丝雀部署

蓝绿部署

金丝雀部署

3.3.2、金丝雀的简单测试

使用这个镜像测试registry.cn-hangzhou.aliyuncs.com/lanson_k8s_images/nginx-test
这个镜像docker run 的时候 -e msg=aaaa，访问这个nginx页面就是看到aaaa

步骤原理

• 准备一个Service，负载均衡Pod
• 准备版本v1的deploy，准备版本v2的deploy

4、Deployment状态与排错

​​Deployments | Kubernetes​​

四、RC、RS、DaemonSet、StatefulSet

1、RC、RS

RC （ReplicationController ）主要的作用就是用来确保容器应用的副本数始终保持在用户定义的副本数 。即如果有容器异常退出，会自动创建新的Pod来替代；而如果异常多出来的容器也会自动回收

Kubernetes 官方建议使用 RS（ReplicaSet ） 替代 RC （ReplicationController ） 进行部署，RS 跟 RC 没有本质的不同，只是名字不一样，并且 RS 支持集合式的 selector
 

RC 控制器

apiVersion: v1
kind: ReplicationController
metadata:
  name: frontend
spec:
  replicas: 3
  selector:
    app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: php-redis
        image: lansonlinux/myapp:v1
        env:
        - name: GET_HOSTS_FROM
          value: dns
          name: zhangsan
          value: "123"
        ports:
        - containerPort: 80

RS控制器

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: myapp
        image: lansonlinux/myapp:v1
        env:
        - name: GET_HOSTS_FROM
          value: dns
        ports:
        - containerPort: 80

2、DaemonSet

DaemonSet 控制器确保所有（或一部分）的节点都运行了一个指定的 Pod 副本。

• 每当向集群中添加一个节点时，指定的 Pod 副本也将添加到该节点上
• 当节点从集群中移除时，Pod 也就被垃圾回收了
• 删除一个 DaemonSet 可以清理所有由其创建的 Pod

DaemonSet 的典型使用场景有：

• 在每个节点上运行集群的存储守护进程，例如 glusterd、ceph
• 在每个节点上运行日志收集守护进程，例如 fluentd、logstash
• 在每个节点上运行监控守护进程，例如​​Prometheus Node Exporter​​​、​​Sysdig Agent​​​、collectd、​​Dynatrace OneAgent​​​、​​APPDynamics Agent​​​、​​Datadog agent​​​、​​New Relic agent​​​、Ganglia gmond、​​Instana Agent​​ 等

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: logging
  labels:
    app: logging
spec:
  selector:
    matchLabels:
      name: logging
  template:
    metadata:
      labels:
        name: logging
    spec:
      containers:
      - name: logging
        image: nginx
        resources:
          limits:
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
      tolerations:  #设置容忍master的污点
      - key: node-role.kubernetes.io/master
        effect: NoSchedule

查看效果

kubectl get pod -l name=logging -o wide

3、StatefulSet

有状态副本集；Deployment等属于无状态的应用部署（stateless）

• StatefulSet使用场景；对于有如下要求的应用程序，StatefulSet 非常适用：

• 稳定、唯一的网络标识（dnsname）

• StatefulSet通过与其相关的无头服务为每个pod提供DNS解析条目。假如无头服务的DNS条目为: "$(service name).$(namespace).svc.cluster.local"， 那么pod的解析条目就是"$(pod name).$(service name).$(namespace).svc.cluster.local"，每个pod name也是唯一的。

• 稳定的、持久的存储；【每个Pod始终对应各自的存储路径（PersistantVolumeClaimTemplate）】
• 有序的、优雅的部署和缩放。【按顺序地增加副本、减少副本，并在减少副本时执行清理】
• 有序的、自动的滚动更新。【按顺序自动地执行滚动更新】

• 限制

• 给定 Pod 的存储必须由PersistentVolume 驱动基于所请求的​​storage class​​ 来提供，或者由管理员预先提供。
• 删除或者收缩 StatefulSet 并不会删除它关联的存储卷。 这样做是为了保证数据安全，它通常比自动清除 StatefulSet 所有相关的资源更有价值。
• StatefulSet 当前需要无头服务来负责 Pod 的网络标识。你需要负责创建此服务。
• 当删除 StatefulSets 时，StatefulSet 不提供任何终止 Pod 的保证。 为了实现 StatefulSet 中的 Pod 可以有序地且体面地终止，可以在删除之前将 StatefulSet 缩放为 0。
• 在默认Pod 管理策略(​​OrderedReady​​) 时使用 滚动更新，可能进入需要人工干预才能修复的损坏状态。

如果一个应用程序不需要稳定的网络标识，或者不需要按顺序部署、删除、增加副本，就应该考虑使用 Deployment 这类无状态（stateless）的控制器

apiVersion: v1
kind: Service   #定义一个负载均衡网络
metadata:
  name: stateful-tomcat
  labels:
    app: stateful-tomcat
spec:
  ports:
  - port: 8123
    name: web
    targetPort: 8080
  clusterIP: None   #NodePort：任意机器+NodePort都能访问，ClusterIP：集群内能用这个ip、service域名能访问，clusterIP: None；不要分配集群ip。headless；无头服务。稳定的域名
  selector:
    app: stateful-tomcat
---
apiVersion: apps/v1
kind: StatefulSet  #控制器。
metadata:
  name: stateful-tomcat
spec:
  selector:
    matchLabels:
      app: stateful-tomcat # has to match .spec.template.metadata.labels
  serviceName: "stateful-tomcat" #这里一定注意，必须提前有个service名字叫这个的
  replicas: 3 # by default is 1
  template:
    metadata:
      labels:
        app: stateful-tomcat # has to match .spec.selector.matchLabels
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: tomcat
        image: tomcat:7
        ports:
        - containerPort: 8080
          name: web

#观察效果。
删除一个，重启后名字，ip等都是一样的。保证了状态

#细节
kubectl explain StatefulSet.spec
podManagementPolicy：
  OrderedReady（按序）、Parallel（并发）
  
serviceName -required-
  设置服务名，就可以用域名访问pod了。
  pod-specific-string.serviceName.default.svc.cluster.local

#测试
kubectl run -i --tty --image busybox dns-test --restart=Never --rm /bin/sh
ping stateful-tomcat-0.stateful-tomcat

#我们在这里没有加存储卷。如果有的话  kubectl get pvc -l app=stateful-tomcat 我们就能看到即使Pod删了再拉起，卷还是同样的。

五、Job、CronJob

1、Job

Kubernetes中的 Job 对象将创建一个或多个 Pod，并确保指定数量的 Pod 可以成功执行到进程正常结束：

• 当 Job 创建的 Pod 执行成功并正常结束时，Job 将记录成功结束的 Pod 数量
• 当成功结束的 Pod 达到指定的数量时，Job 将完成执行
• 删除 Job 对象时，将清理掉由 Job 创建的 Pod

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never #Job情况下，不支持Always
  backoffLimit: 4 #任务4次都没成，认为失败
  activeDeadlineSeconds: 10

#默认这个任务需要成功执行一次。
#查看job情况
kubectl get job

#修改下面参数设置再试试
#千万不要用阻塞容器。nginx。job由于Pod一直running状态。下一个永远得不到执行，而且超时了，当前running的Pod还会删掉
kubectl api-resources

#云原生征文#深入Kubernetes（k8s）概念

 云原生 | Kubernetes篇Kubernetes（k8s）工作负载
 #云原生征文#Kubernetes集群部署
 #云原生征文#Kubernetes（k8s）临时存储
 #云原生征文#Kubernetes（k8s）网络
 如何将云原生工作负载映射到Kubernetes中的控制器