当前位置:   article > 正文

k8s——pod控制器_namespace workload pod

namespace workload pod

目录

一、Pod控制器

1.1  pod 控制器简介

1.2  pod控制器有多种类型

1.3   Pod与控制器之间的关系

二、Deployment(无状态)

2.1 Deployment的资源清单文件

2.2 创建deployment 

三、ReplicaSet(RS) 

3.1 ReplicaSet的资源清单文件

3.2  创建ReplicaSet

四、SatefulSet(有状态)

4.1  有状态与无状态的区别

4.2  常规service和无头服务区别

4.2.1  Service类型

4.2.2   headless方式

五、DaemonSet(守护进程集)

六、Job

七、 CronJob


一、Pod控制器

1.1  pod 控制器简介

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

kubernetes中,按照pod的创建安方式可以将其分为两类:

  • 自主式pod:kubernetes直接创建出来的pod,这种pod删除后就没有了,也不会重建
  • 控制器创建的pod:通过控制器创建的pod,这种pod删除了之后还会自动重建

pod控制器分为有状态和无状态的
有状态:
1.实例之间有差别,每个实例都有自己的独特性,元数据不同,例如etcd,zookeeper
2.实例之间不对等的关系,以及依靠外部存储的应用

无状态:
1.deployment认为所有的pod都是一样的
2.不用考虑顺序的要求
3.不用考虑在哪个node节点上运行
4.可以随意扩容和缩容

常规service和无头服务的区别:
service:一组pod访问策略,提供cluster-ip集群之间通讯,还提供负载均衡和服务发现
Headless service:无头服务,不需要cluster-ip,直接绑定具体的pod的IP

1.2  pod控制器有多种类型

1、ReplicaSet: 代用户创建指定数量的pod副本数量,确保pod副本数量符合预期状态,并且支持滚动式自动扩容和缩容功能。

ReplicaSet主要三个组件组成:

(1)用户期望的pod副本数量

(2)标签选择器,判断哪个pod归自己管理

(3)当现存的pod数量不足,会根据pod资源模板进行新建

帮助用户管理无状态的pod资源,精确反应用户定义的目标数量,但是RelicaSet不是直接使用的控制器,而是使用Deployment

2、Deployment:工作在ReplicaSet之上,用于管理无状态应用,目前来说最好的控制器。支持滚动更新和回滚功能,还提供声明式配置。

ReplicaSet 与Deployment 这两个资源对象逐步替换之前RC的作用。

3、DaemonSet:用于确保集群中的每一个节点只运行特定的pod副本,通常用于实现系统级后台任务。比如ELK服务

  • 特性:服务是无状态的
  • 服务必须是守护进程

4、StatefulSet:管理有状态应用

5、Job:只要完成就立即退出,不需要重启或重建

6、Cronjob:周期性任务控制,不需要持续后台运行

1.3   Pod与控制器之间的关系

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

二、Deployment(无状态)

为了更好的解决服务编排的问题,kubernetes在v1.2版本开始,引入了Deployment控制。值得一提的是,这种控制器并不直接管理pod,而是通过管理  ReplicaSet  来间接管理Pod,即:Deployment管理ReplicaSet,ReplicaSet管理Pod。所以Deployment比ReplicaSet功能更加强大。

Deployment主要功能有下面几个:

  • 支持ReplicaSet的所有功能
  • 支持发布的停止、继续
  • 支持版本滚动升级和版本回退

特点:

  • 部署无状态应用,只关心数量,不论角色等,称无状态
  • 管理Pod和ReplicaSet
  • 具有上线部署、副本设定、滚动升级、回滚等功能
  • 提供声明式更新,例如只更新一个新的image

应用场景:应用场景: Nginx, 微服务,jar

2.1 Deployment的资源清单文件

  1. apiVersion: apps/v1 # 版本号
  2. kind: Deployment # 类型
  3. metadata: # 元数据
  4. name: # rs名称
  5. namespace: # 所属命名空间
  6. labels: #标签
  7. controller: deploy
  8. spec: # 详情描述
  9. replicas: 3 # 副本数量
  10. revisionHistoryLimit: 3 # 保留历史版本,默认是10,用于版本回退时使用
  11. paused: false # 暂停部署,默认是false,即deployment创建好后是否立即开始部署和创建pod
  12. progressDeadlineSeconds: 600 # 部署超时时间(s),默认是600
  13. strategy: # 策略
  14. type: RollingUpdate # 滚动更新策略
  15. rollingUpdate: # 滚动更新
  16. maxSurge: 30% # 最大额外可以存在的副本数,可以为百分比,也可以为整数
  17. maxUnavailable: 30% # 最大不可用状态的 Pod 的最大值,可以为百分比,也可以为整数
  18. selector: # 选择器,通过它指定该控制器管理哪些pod
  19. matchLabels: # Labels匹配规则
  20. app: nginx-pod
  21. matchExpressions: # Expressions匹配规则
  22. - {key: app, operator: In, values: [nginx-pod]}
  23. template: # 模板,当副本数量不足时,会根据下面的模板创建pod副本
  24. metadata:
  25. labels:
  26. app: nginx-pod
  27. spec:
  28. containers:
  29. - name: nginx
  30. image: nginx:1.17.1
  31. ports:
  32. - containerPort: 80

上述资源清单可以分为三部分,spec以上是deployment信息;spec的replicas到selector是副本数量、镜像更新策略、标签选择器(会和下面的Pod做关联)等;template及以下是Pod配置信息。

2.2 创建deployment 

创建pc-deployment.yaml,内容如下:

  1. # vim nginx-deployment.yaml
  2. apiVersion: apps/v1
  3. kind: Deployment
  4. metadata:
  5. name: nginx-deployment
  6. labels:
  7. app: nginx
  8. spec:
  9. replicas: 3
  10. selector:
  11. matchLabels:
  12. app: nginx
  13. template:
  14. metadata:
  15. labels:
  16. app: nginx
  17. spec:
  18. containers:
  19. - name: nginx
  20. image: nginx:1.15.4
  21. ports:
  22. - containerPort: 80
  1. Replicaset是副本数,回滚就是通过此来实现
  2. 创建资源
  3. # kubectl create -f nginx-deployment.yaml
  4. 查看创建的pod资源、控制器和副本
  5. # kubectl get pods,deploy,rs
  6. 查看历史版本
  7. # kubectl rollout history deployment/nginx-deployment

三、ReplicaSet(RS) 

ReplicaSet的主要作用是保证一定数量的pod正常运行,它会持续监听这些Pod的运行状态,一旦Pod发生故障,就会重启或重建。同时它还支持对pod数量的扩缩容镜像版本的升降级

3.1 ReplicaSet的资源清单文件

  1. apiVersion: apps/v1 # 版本号
  2. kind: ReplicaSet # 类型
  3. metadata: # 元数据
  4. name: # rs名称
  5. namespace: # 所属命名空间
  6. labels: #标签
  7. controller: rs
  8. spec: # 详情描述
  9. replicas: 3 # 副本数量
  10. selector: # 选择器,通过它指定该控制器管理哪些pod
  11. matchLabels: # Labels匹配规则
  12. app: nginx-pod
  13. matchExpressions: # Expressions匹配规则
  14. - {key: app, operator: In, values: [nginx-pod]}
  15. template: # 模板,当副本数量不足时,会根据下面的模板创建pod副本
  16. metadata:
  17. labels:
  18. app: nginx-pod
  19. spec:
  20. containers:
  21. - name: nginx
  22. image: nginx:1.17.1
  23. ports:
  24. - containerPort: 80

 在这里面,需要新了解的配置项就是spec下面几个选项: 

  • replicas:指定副本数量,其实就是当前rs创建出来的pod的数量,默认为1
  • selector:选择器,它的作用是建立pod控制器和pod之间的关联关系,采用的Label Selector机制。在pod模板上定义label,在控制器上定义选择器,就可以表明当前控制器能管理哪些pod了
  • template:模板,就是当前控制器创建pod所使用的模板板,里面其实就是前一章学过的pod的定义
     

3.2  创建ReplicaSet

创建pc-replicaset.yaml文件,内容如下:

  1. apiVersion: apps/v1
  2. kind: ReplicaSet
  3. metadata:
  4. name: pc-replicaset
  5. namespace: dev
  6. spec:
  7. replicas: 3
  8. selector:
  9. matchLabels:
  10. app: nginx-pod
  11. template:
  12. metadata:
  13. labels:
  14. app: nginx-pod
  15. spec:
  16. containers:
  17. - name: nginx
  18. image: nginx:1.17.1
  1. # 创建rs
  2. [root@master ~]# kubectl create -f pc-replicaset.yaml
  3. replicaset.apps/pc-replicaset created
  4. # 查看rs
  5. # DESIRED:期望副本数量
  6. # CURRENT:当前副本数量
  7. # READY:已经准备好提供服务的副本数量
  8. [root@master ~]# kubectl get rs pc-replicaset -n dev -o wide
  9. NAME DESIRED CORRENT READY AGE CONTAINERS IMAGES SELECTOR
  10. pc-replicaset 3 3 3 22s nginx nginx:1.17.1 app=nginx-pod
  11. # 查看当前控制器创建出来的pod
  12. # 这里发现控制器创建出来的pod的名称是在控制器名称后面拼接了-xxxx随机码
  13. [root@master ~]# kubectl get pod -n dev
  14. NAME READY STATUS RESTARTS AGE
  15. pc-replicaset-6vmvt 1/1 Running 0 54s
  16. pc-replicaset-fm8f 1/1 Running 0 54s
  17. pc-replicaset-snrk 1/1 Running 0 54s

四、SatefulSet(有状态)

  1. 部署有状态应用
  2. 解决Pod独立生命周期,保持Pod启动顺序和唯一性
  3. 稳定,唯一的网络标识符,持久存储(例如:etcd配置文件,节点地址发生变化,将无法使用)
  4. 有序,优雅的部署和扩展、删除和终止(例如:mysql主从关系,先启动主,再启动从)
  5. 有序,滚动更新

应用场景:数据库,Mysql主从,zookeeper集群,etcd集群

无论是Kube-dns还是CoreDNS,基本原理都是利用监听Kubernetes的Service和Pod,生成DNS记录,然后通过重新配置Kubelet的DNS选项让新启动的Pod使用Kube-dns或CoreDNS提供的

4.1  有状态与无状态的区别

无状态

  1. deployment认为所有的pod都是一样的
  2. 不用考虑顺序的要求
  3. 不用考虑在哪个node节点上运行
  4. 可以随意扩容和缩容

有状态

  1. 实例之间有差别,每个实例都有自己的独特性,元数据不同,例如etcd,zookeeper
  2. 实例之间不对等的关系,以及依靠外部存储的应用

4.2  常规service和无头服务区别

  1. service:一组Pod访问策略,提供cluster-IP群集之间通讯,还提供负载均衡和服务发现。
  2. Headless service :无头服务,不需要cluster-IP,直接绑定具体的Pod的IP

4.2.1  Service类型

  1. Cluster_IP
  2. NodePort:使用Pod所在节点的IP和其端口范围
  3. Headless
  4. HostPort(ingress、kubesphere)
  5. LoadBalance负载均衡(F5硬件负载均衡器)

PS:k8s暴露方式主要就3种:ingress loadbalance(SLB/ALB K8S集群外的负载均衡器、Ng、harproxy、KONG、traefik等等) service

  1. vim nginx-service.yaml
  2. apiVersion: v1
  3. kind: Service
  4. metadata:
  5. name: nginx-svc
  6. labels:
  7. app: nginx
  8. spec:
  9. type: NodePort
  10. ports:
  11. - port: 80
  12. targetPort: 80
  13. selector:
  14. app: nginx

在node节点操作,查看集群间通讯

4.2.2   headless方式

因为Pod动态IP地址,所以常用于绑定DNS访问—来尽可能固定Pod的位置

  1. [root@master demo]# vim headless.yaml
  2. apiVersion: v1
  3. kind: Service
  4. metadata:
  5. name: nginx
  6. labels:
  7. app: nginx
  8. spec:
  9. ports:
  10. - port: 80
  11. name: web
  12. clusterIP: None
  13. selector:
  14. app: nginx

  1. kubectl apply -f headless.yaml
  2. kubectl get svc

再定义一个pod

  1. [root@master demo]# vim dns-test.yaml
  2. apiVersion: v1
  3. kind: Pod
  4. metadata:
  5. name: dns-test
  6. spec:
  7. containers:
  8. - name: busybox
  9. image: busybox:1.28.4
  10. args:
  11. - /bin/sh
  12. - -c
  13. - sleep 36000
  14. restartPolicy: Never

 

 验证dns解析

  1. kubectl create -f dns-test.yaml
  2. kubectl get svc

解析kubernetes和nginx-svc名称

kubectl exec -it dns-test sh

创建StatefulSet.yaml文件

  1. vim statefulSet.yaml
  2. apiVersion: v1
  3. kind: Service
  4. metadata:
  5. name: nginx
  6. labels:
  7. app: nginx
  8. spec:
  9. ports:
  10. - port: 80
  11. name: web
  12. clusterIP: None
  13. selector:
  14. app: nginx
  15. ---
  16. apiVersion: apps/v1beta1
  17. kind: StatefulSet
  18. metadata:
  19. name: nginx-statefulset
  20. namespace: default
  21. spec:
  22. serviceName: nginx
  23. replicas: 3
  24. selector:
  25. matchLabels:
  26. app: nginx
  27. template:
  28. metadata:
  29. labels:
  30. app: nginx
  31. spec:
  32. containers:
  33. - name: nginx
  34. image: nginx:latest
  35. ports:
  36. - containerPort: 80

 清理所有pod

kubectl delete -f .

  1. kubectl create -f statefulSet.yaml
  2. kubectl get pods,svc

解析pod的唯一域名和自身的ip

  1. kubectl apply -f dns-test.yaml
  2. kubectl exec -it dns-test sh
  3. nslookup nginx-statefulset-0.nginx
  4. nslookup nginx-statefulset-1.nginx
  5. nslookup nginx-statefulset-2.nginx

总结
StatefulSet与Deployment区别:有身份的!
身份三要素:

  1. 域名 nginx-statefulset-0.nginx
  2. 主机名 nginx-statefulset-0
  3. 存储(PVC)

无状态服务对象-Deployment:用于部署无状态的服务,一般用于管理维护企业内部无状态的微服务,比如configserver、zuul、springboot。其可以管理多个副本的Pod实现无缝迁移、自动扩容缩容、自动灾难恢复、一键回滚等功能。其服务部署结构模型是Deployment->ReplicaSet->Pod;Deployment工作在ReplicaSet之上,用于管理无状态应用,通过“控制器模式”,来操作 ReplicaSet 的个数和属性,进而实现“水平扩展 / 收缩”和“滚动更新”这两个编排动作,也就是说,Deployment 控制器实际操纵的是ReplicaSet 对象,而不是 Pod 对象

有状态服务-statefuleset:用于管理有状态应用程序的工作负载API对象。比如在生产环境中,可以部署ElasticSearch集群、MongoDB集群或者需要持久化的RabbitMQ集群、Redis集群、Kafka集群和ZooKeeper集群等,其解决了有状态服务使用容器化部署的一个问题,保证pod的hostname重启/重建后不变,通过hostname维护关联数据。其服务部署结构模型是Statefulset->ReplicaSet->Pod;Statefulset也是工作在Replicaset之上,用于管理有状态服务。有状态部署的产品设置通无状态部署

五、DaemonSet(守护进程集)

daemonset确保全部(或者一些)node上运行一个pod副本,当有node加入集群时,也会为他们新增一个pod。当有node从集群移除时,这些pod也会被回收。删除daemonset将会删除它创建的所有的pod
应用场景:运行日志收集,监控,集群存储daemon

  1. 在每一个Node上运行一个Pod
  2. 新加入的Node也同样会自动运行一个Pod
  1. [root@master demo]# vim daemonSet.yaml
  2. apiVersion: apps/v1
  3. kind: DaemonSet
  4. metadata:
  5. name: nginx-deployment
  6. labels:
  7. app: nginx
  8. spec:
  9. selector:
  10. matchLabels:
  11. app: nginx
  12. template:
  13. metadata:
  14. labels:
  15. app: nginx
  16. spec:
  17. containers:
  18. - name: nginx
  19. image: nginx:1.15.4
  20. ports:
  21. - containerPort: 80

DaemonSet会在每个node节点都创建一个Pod

  1. kubectl apply -f daemonSet.yaml
  2. kubectl get pods

六、Job

Job分为普通任务(Job)和定时任务(CronJob)

一次性执行

应用场景:离线数据处理,视频解码等业务

Jobs | Kubernetes

官方案例

 应用大数据场景

示例: 

用job控制器类型创建资源,执行算圆周率的命令,保持后2000位,创建过程等同于在计算
,重试次数默认是6次,修改为4次,当遇到异常时Never状态会重启,所以要设定次数。

  1. [root@master demo]# vim job.yaml
  2. apiVersion: batch/v1
  3. kind: Job
  4. metadata:
  5. name: pi
  6. spec:
  7. template:
  8. spec:
  9. containers:
  10. - name: pi
  11. image: perl:5.34.0
  12. command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
  13. restartPolicy: Never
  14. backoffLimit: 4

在node1节点下载perl镜像,因为镜像比较大所以提前下载好

docker pull perl

创建

查看到完成状态

结果输出到控制台

清除job资源

  1. kubectl get job
  2. kubectl delete -f job.yaml

七、 CronJob

  1. 周期性任务,像Linux的Crontab一样。
  2. 周期性任务
  3. 应用场景:通知,备份

官方示例:Running Automated Tasks with a CronJob | Kubernetes

 示例: 

每隔一分钟输出一条信息,打印hello

  1. [root@master demo]# vim cronjob.yaml
  2. apiVersion: batch/v1beta1
  3. kind: CronJob
  4. metadata:
  5. name: lcdb
  6. spec:
  7. schedule: "*/1 * * * *"
  8. jobTemplate:
  9. spec:
  10. template:
  11. spec:
  12. containers:
  13. - name: lcdb
  14. image: busybox
  15. args:
  16. - /bin/sh
  17. - -c
  18. - date; echo lcdb from the Kubernetes cluster
  19. restartPolicy: OnFailure

  1. kubectl apply -f cronjob.yaml
  2. kubectl get pod
  3. kubectl get cronjob

 清除cronjob资源

kubectl delete -f cronjob.yaml

 

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/知新_RL/article/detail/162336
推荐阅读
  

闽ICP备14008679号