一、pod控制器定义

  Pod控制器，又称之为工作负载（workload），是用于实现管理pod的中间层，确保pod资源符合预期的状态，pod的资源出现故障时，会尝试进行重启，当根据重启策略无效，则会重新新建pod的资源。

二、pod控制器类型

• ReplicaSet: 代用户创建指定数量的pod副本，确保pod副本数量符合预期状态，并且支持滚动式自动扩容和缩容功能，帮助用户管理无状态的pod资源，精确反应用户定义的目标数量，但是ReplicaSet不是直接使用的控制器，而是使用Deployment。

    ReplicaSet主要三个组件组成：

1. 用户期望的pod副本数量
2. 标签选择器，判断哪个pod归自己管理
3. 当现存的pod数量不足，会根据pod资源模板进行新建

• Deployment：工作在ReplicaSet之上，用于管理无状态应用，目前来说最好的控制器。支持滚动更新和回滚功能，还提供声明式配置。
  • 注意：ReplicaSet 与Deployment 这两个资源对象逐步替换之前RC的作用。
• DaemonSet：用于确保集群中的每一个节点只运行特定的pod副本，通常用于实现系统级后台任务。比如ELK。服务特性：服务是无状态的。服务必须是守护进程
• StatefulSet：管理有状态应用
• Job：只要完成就立即退出，不需要重启或重建
• Cronjob：周期性任务控制，不需要持续后台运行

三、pod与控制器的关系

  controllers：在集群上管理和运行容器的pod对象， pod通过label-selector相关联。Pod通过控制器实现应用的运维，如伸缩，升级等。

四、Deployment

  4.1 deployment功能及应用场景

1. 部署无状态应用，管理Pod和ReplicaSet
2. 具有上线部署、副本设定、滚动升级、回滚等功能
3. 提供声明式更新，例如只更新一个新的image

• 应用场景：web服务

  4.2 deployment示例

  4.2.1 创建文件夹

mkdir /opt/pod
cd /opt/pod/
kubectl create deployment nginx-demo1 --image=nginx:1.15 --port=80 --replicas=3 --dry-run=client -oyaml > nginx-deployment.yaml

  4.2.2 编辑yaml

  4.2.3 运行yaml文件

kubectl apply -f nginx-deployment.yaml

kubectl get pod,deploy,rs

  4.2.3.1 查看nginx版本

    随机远程测试一个running的pod目的是查看nginx的版本

  4.2.4 查看控制器配置

kubectl edit deployment/nginx-demo1

  4.2.5 查看历史版本

    K8S中nginx服务升级版本——配置文件升级

  4.2.6 查看版本

  4.2.7 配置文件里面修改版本

  4.2.8 查看升级后的版本

  4.2.9 k8s服务回滚

  4.2.9.1 查看目前有几个回滚

  4.2.9.2 回滚

kubectl rollout undo deployment nginx-demo1
kubectl get pod -owide
curl -I xxxx

  4.2.10 K8S中nginx服务升级版本——直接更新pod（在副本里面单独升级）

  4.3 SatefulSet使用方式及示例

  4.3.1 SatefulSet使用方式、功能及使用场景

  部署有状态应用

    稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现

    稳定的网络标志，即Pod重新调后其PodName和HostName不变，基于**Headless （没有IP只有DNS主机解析名，无头服务ｐｏｄ名称是唯一的标识不会变）**Service (即没有cluster IP的Service)来实现

    有序部署（一个一个部署从０到ｎ－１启动一个个部署），有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次进行(即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态)，基于init containers来实现

    有序收缩，有序删除 (是倒序即从N-1到0)

    常见的应用场景: 数据库

  4.3.2 StatefulSet模式（无头模式） 

  4.3.2.1 编辑sts.svc.yaml文件

apiVersion: v1
kind: Service
metadata:
  labels:
    app: sts-svc
  name: sts-svc
  namespace: default
spec:
  clusterIP: None
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: myapp-sts
  type: ClusterIP

  4.3.2.2 运行yaml文件

  4.3.2.3 编辑svc.yaml文件

apiVersion: apps/v1
kind: StatefulSet
metadata:
  labels:
    app: sts01
  name: sts01
spec:
  serviceName: "sts-svc"
  replicas: 2
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - image: soscscs/myapp:v1
        name: nginx
        ports:
        - containerPort: 80
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "nfs-client-storageclass"
      resources:
        requests:
          storage: 1Gi

  4.3.2.4 运行yaml文件

sts按顺序生成

  4.3.2.5 在NFS机下修改内容

  4.3.2.6 正常访问

kubectl get pod -owide

  4.3.3 StatefulSet的组成

    从上面的应用场景可以发现，StatefulSet由以下几个部分组成：

• Headless Service（无头服务）：用于为Pod资源标识符生成可解析的DNS记录
• volumeClaimTemplates（存储卷申请模板）：基于静态或动态PV供给方式为Pod资源提供专有的固定存储
• StatefulSet：用于管控Pod资源

  4.3.4 使用headless目的

    在deployment中，每一个pod是没有名称，是随机字符串，是无序的。但是statefulset中是要求有序的，每一个pod的名称必须是固定的。

    当节点挂了，重建之后的标识符是不变的，每一个节点的节点名称是不能改变的。pod名称是作为pod识别的唯一标识符，必须保证其标识符的稳定并且唯一。
    为了实现标识符的稳定，这时候就需要一个headless service 解析直达到pod，还需要给pod配置一个唯一的名称。

  4.3.5 使用volumeClainTemplate目的

    大部分有状态副本集都会用到持久存储，比如分布式系统来说，由于数据是不一样的，每个节点都需要自己专用的存储节点。而在 deployment中pod模板中创建的存储卷是一个共享的存储卷，多个pod使用同一个存储卷，而statefulset定义中的每一个pod都不能使用同一个存储卷，由此基于pod模板创建pod是不适应的，这就需要引入volumeClainTemplate，当在使用statefulset创建pod时，会自动生成一个PVC，从而请求绑定一个PV，从而有自己专用的存储卷。

  4.3.6 服务发现的定义

    服务发现：就是应用服务之间相互定位的过程。
    应用场景：

• 动态性强：Pod会飘到别的node节点
• 更新发布频繁：互联网思维小步快跑，先实现再优化，老板永远是先上线再慢慢优化，先把idea变成产品挣到钱然后再慢慢一点一点优化
• 支持自动伸缩：一来大促，肯定是要扩容多个副本

    K8S里服务发现的方式—DNS，使K8S集群能够自动关联Service资源的“名称”和“CLUSTER-IP”，从而达到服务被集群自动发现的目的。

  4.3.7 实现K8S里DNS功能的插件

• skyDNS：Kubernetes 1.3之前的版本
• kubeDNS：Kubernetes 1.3至Kubernetes 1.11
• CoreDNS：Kubernetes 1.11开始至今

  4.3.7.1 编辑nginx-service.yaml文件

apiVersion: v1  
kind: Service  
metadata:
  name: nginx-service
  labels:
    app: nginx  
spec:
  type: NodePort  
  ports:
  - port: 80
    targetPort: 80  
  selector:
    app: nginx
 
#创建
kubectl create -f nginx-service.yaml
#查看
kubectl get svc

  4.3.7.2 运行yaml文件

  4.3.7.3 编辑dns-test.yaml文件

apiVersion: v1
kind: Pod
metadata:
  name: dns-test
spec:
  containers:
  - name: busybox
    image: busybox:1.28.4
    args:
    - /bin/sh
    - -c
    - sleep 36000
  restartPolicy: Never

  4.3.7.4 运行yaml文件

  4.3.7.5 解析kubernetes和nginx-service名称

  4.3.7.6 查看statefulset的定义

  4.3.7.7 清单定义StatefulSet

    一个完整的 StatefulSet 控制器由一个 Headless Service、一个 StatefulSet 和一个 volumeClaimTemplate组成。如下资源清单中的定义：

apiVersion: apps/v1
kind: StatefulSet
metadata:
  labels:
    app: sts01
  name: sts01
spec:
  serviceName: "sts-svc"
  replicas: 2
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - image: soscscs/myapp:v1
        name: nginx
        ports:
        - containerPort: 80
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "nfs-client-storageclass"
      resources:
        requests:
          storage: 1Gi

  4.3.7.8 查看statefulset

  4.3.7.9 查看pvc绑定

  4.3.7.10 查看pv绑定

  4.3.7.11 查看Pod信息

  4.3.7.12 当删除的时候是从sts01-1开始进行删除的，关闭是逆向关闭，此时PVC依旧存在的，再重新创建pod时，依旧会重新去绑定原来的pvc

  4.3.7.13 StatefulSet滚动更新

    StatefulSet控制器将在StatefulSet中删除并重新创建每个Pod。它将以与Pod终止相同的顺序进行（从最大的序数到最小的序数），每次更新一个Pod。在更新其前身之前，它将等待正在更新的 Pod状态变成正在运行并就绪。如下操作的滚动更新是按照1-0的顺序更新。

  4.3.7.13.1 修改版本

  4.3.7.13.2 运行yaml查看滚动更新的过程

  4.3.7.13.3 在创建的每一个Pod中，每一个pod自己的名称都是可以被解析的

  4.3.7.13.4 编辑pod6.yaml文件

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: nginx-statefulset
spec:
  serviceName: nginx
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

  4.3.7.13.5 运行yaml文件

  4.3.7.13.6 查看pod和service

  4.3.7.13.7 进入dns-test下解析内容

  4.3.7.13.8 远程测试能否连通

kubectl exec -it nginx-statefulset-0 bash
 
/# curl nginx-statefulset-0.nginx
/# curl nginx-statefulset-1.nginx
/# curl nginx-statefulset-2.nginx
 
exit

  4.3.7.14 statefulset扩展伸缩

  4.3.7.14.1 动态查看扩容

kubectl scale sts nginx-statefulset --replicas=4  #扩容副本增加到4个，默认值就是一个

  4.3.7.14.2 打补丁方式缩容

  4.4 DaemonSet使用方式及实例

    ELK，zabbix，普罗米修斯监控，数据变动可用这个控制器，数据库暴露可以用这个暴露

  4.4.1 DaemonSet使用方式

1. DaemonSet 确保全部（或者一些）Node 上运行一个 Pod 的副本。当有 Node 加入集群时，也会为他们新增一个 Pod 。当有 Node 从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。
2. 使用 DaemonSet 的一些典型用法：

• 运行集群存储 daemon，例如在每个 Node 上运行 glusterd、ceph。
• 在每个 Node 上运行日志收集 daemon，例如fluentd、logstash。
• 在每个 Node 上运行监控 daemon，例如 Prometheus Node Exporter、collectd、Datadog 代理、New Relic 代理，或 Ganglia gmond。

    应用场景：Agent
    官方案例（监控）：https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/

  4.4.2 Daemonset示例

  4.4.2.1 编辑ds.yaml文件

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: nginx-daemonset
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
        ports:
        - containerPort: 80

  4.4.2.2 运行yaml文件

  4.5 job使用方法及示例

  4.5.1 job使用方法

    常用于运行那些仅需要执行一次的任务
    应用场景：数据库迁移、批处理脚本、kube-bench扫描、离线数据处理，视频解码等业务
https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/

  4.5.2 job示例

  4.5.2.1 编辑yaml文件

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
  backoffLimit: 4

  4.5.2.2 在node下下载perl

  4.5.2.3 运行服务

kubectl apply -f job.yaml 
kubectl get pods

  4.5.2.4 输出结果到控制台

kubectl logs pi-zcnh2

  4.5.2.5 清除job资源

kubectl delete -f job.yaml 

  4.5.2.6 编辑yaml文件

vim job-limit.yaml
 
apiVersion: batch/v1
kind: Job
metadata:
  name: busybox
spec:
  template:
    spec:
      containers:
        - name: busybox
          image: busybox
          imagePullPolicy: IfNotPresent
          command: ["/bin/sh", "-c", "sleep 10;date;exit 1"]
      restartPolicy: Never
  backoffLimit: 2

  4.5.2.7 运行job-limit.yaml文件

  4.5.2.8 查看busybox详细信息

 这个警告表示job已经达到了指定的回退限制（backoff limit），这意味着该job的重试次数已经达到了设定的上限。当job中的pod失败并且重试次数超过了回退限制，kubernetes会进一步阻止这个重试次数并且记录下

  4.6 CronJob使用方式及实例

  4.6.1 CronJob使用方式

    周期性任务，像Linux的Crontab一样。
    应用场景：通知，备份
https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/

  4.6.2 示例

  4.6.2.1 编辑yaml文件

#每分钟打印hello
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            imagePullPolicy: IfNotPresent
            args:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure

cronjob其它可用参数的配置
spec:

• concurrencyPolicy: Allow——要保留的失败的完成作业数（默认为1）
• schedule: ‘*/1 * * * *’ ——作业时间表。在此示例中，作业将每分钟运行一次
• startingDeadlineSeconds: 15——pod必须在规定时间后的15秒内开始执行，若超过该时间未执行，则任务将不运行，且标记失败
• successfulJobsHistoryLimit: 3——要保留的成功完成的作业数（默认为3）
• terminationGracePeriodSeconds: 30——job存活时间 默认不设置为永久
• jobTemplate——作业模板。这类似于工作示例

  4.6.2.2 运行yaml文件

如果报错：Error from server (Forbidden): Forbidden (user=system:anonymous, verb=get, resource=nodes, subresource=proxy) ( pods/log hello-1621587780-c7v54)

解决办法：绑定一个cluster-admin的权限
kubectl create clusterrolebinding system:anonymous --clusterrole=cluster-admin --user=system:anonymous