k8s——pod控制器

2024-06-22 2387阅读

一、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使用方式
        
        DaemonSet 确保全部（或者一些）Node 上运行一个 Pod 的副本。当有 Node 加入集群时，也会为他们新增一个 Pod 。当有 Node 从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。
        使用 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

相关阅读：

1、自建VPS超全攻略，轻松搭建个人云服务器，一键开启云端之旅！

2、VPS连接全攻略，一步步教你如何轻松连接虚拟私人服务器

3、VPS入站规则详解，安全配置与操作指南

4、iPad掌控VPS，远程管理轻松实现操作指南！

5、搭建高效VPS全攻略，轻松玩转服务器设置！

高速稳定云服务器25元起

免责声明：我们致力于保护作者版权，注重分享，被刊用文章因无法核实真实出处，未能及时与作者取得联系，或有版权异议的，请联系管理员，我们会立即处理! 部分文章是来自自研大数据AI进行生成,内容摘自(百度百科,百度知道,头条百科,中国民法典,刑法,牛津词典,新华词典,汉语词典,国家院校,科普平台)等数据,内容仅供学习参考,不准确地方联系删除处理! 图片声明：本站部分配图来自人工智能系统AI生成,觅知网授权图片,PxHere摄影无版权图库和百度，360，搜狗等多加搜索引擎自动关键词搜索配图，如有侵权的图片，请第一时间联系我们，邮箱：ciyunidc@ciyunshuju.com。本站只作为美观性配图使用,无任何非法侵犯第三方意图,一切解释权归图片著作权方,本站不承担任何责任。如有恶意碰瓷者,必当奉陪到底严惩不贷!

相关阅读

目录[+]