k8s-pod的控制器

pod控制器的概念

工作负载,workload,用于管理pod的中间层,确保pod资源符合预期的状态

预期状态

1、副本数

2、容器的重启策略

3、镜像拉取策略

pod出现故障时的重启等等

pod控制器的类型

1、replicaSet 指定pod副本的数量

三个组件

复制代码
1、pod的副本数
2、标签选择器,判断那个pod归自己管理
3、扩缩容

2、Deployment控制器,它是工作在replicaSet之上,管理无状态应用,目前是最好的控制器,支持滚动更新和回滚,提供声明式配置

3、statefulSet,控制器的一种,管理有状态的应用,也可以设置副本数,可以扩缩容,pod的序号是固定的,重启之后,pod的名称也不会发生变化,有状态的

4、DaemonSet,可以在所有节点部署一个pod(它没有副本数),可以限制部署的节点,也是无状态的应用,服务必须是守护进程

复制代码
ingress logstash flannel

5、job,工作pod控制器,执行完成即可退出,不需要重启,不需要重建

6、cronjob,周期性的定时任务控制器,不需要在后台持续运行

pod与控制器之间的关系

1、controller-manager,管理控制器

复制代码
pod通过label-----> selector进行关联

2、无状态应用,pod名称是无须的,任务所有pod的都是一体的,共享存储NFS,所有deployment下的pod共享一个存储

复制代码
statfulSet	有状态的应用,pod的名称是有序的,所有pod都是独立的,存储卷也是独立的
顺序0-n,delete删除也不会改变pod序号,扩缩容也是有序扩缩容

apiVersion: v1
kind: Service
metadata:
  name: nginx-web
  labels:
    app: nginx2
spec:
  ports:
  - port: 80
    targetPort: 80
  clusterIP: ""
  selector:
    app: nginx2
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
  labels:
    app: nginx2
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx2
  serviceName: "nginx-web"
  template:
    metadata:
      labels:
        app: nginx2
    spec:
      containers:
      - name: nginx
        image: nginx:1.22
        volumeMounts:
        - name: html
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: html
    spec:
      accessModes: ["ReadWriteMany"]
      resources:
        requests:
          storage: 2Gi



headless service 无头服务,没有clusterIP
必须要有动态的pvc

headless service  k8s集群当中一种特殊的服务类型,不分配ClusterIp给service,也不会负载均衡到后端的pod
DNS来提供服务的发现和访问
由于ClusterIP的是空,k8s集群会给每个headless service中的pod创建一个DNS记录
格式:pod-name.headless-service-name.namespace.svc.cluster.local
     web-0  nginx-web   default  本地地址(pod的IP地址)
 通过DNS直接解析访问pod的IP地址
 web-0  IP地址
为什么要用headless?

有序,独立个体

deployment的pod是没有名称的,随机字符串,无须,他需要一个集中的ClusterIP来集中统一为pod提供网络

statefulSet是有序的,pod名称是固定的,重建之后pod的标识符也不变的,pod的名称是唯一的标识符,系统直接通过pod名称解析IP地址,IP地址不变吗?(会)

为什么要有volumeClaimTemplates?

有状态的副本把集群都会涉及持久化存储,每个pod是独立个体,每个pod都有一个自己专用的存储点

statefulSet在定义的时候就规定了每个pod是不能同一个存储卷,所以才需要动态pv

statefulSet运用场所
复制代码
1、不是固定节点的应用,不是固定IP的应用
2、更新发布比较频发
3、支持自动伸缩,节点的资源不够,可以自动扩容

3、daemonset 确保每个节点上都运行一个pod副本,当node加入集群,也会为他新增一个pod

复制代码
当pod节点从集群当中移除时,pod也会被回收
daemonset不需要指定调度策略,默认会在每个节点创建一个pod,除非污点
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: nginx-deamon
  labels:
    app: nginx1
#提高代码的可读性,别人读,不同业务可以通过namespace隔离,命名时要根据业务专业命名
spec:
  selector:
    matchLabels:
      app: nginx1
  template:
    metadata:
      labels:
        app: nginx1
    spec:
      containers:
      - name: nginx
        image: nginx:1.22
        
我们也可以通过指定的方式,只把daemonset部署在指定的节点
没有副本数选择


apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: nginx-deamon
  labels:
    app: nginx1
#提高代码的可读性,别人读,不同业务可以通过namespace隔离,命名时要根据业务专业命名
spec:
  selector:
    matchLabels:
      app: nginx1
  template:
    metadata:
      labels:
        app: nginx1
    spec:
      containers:
      - name: nginx
        image: nginx:1.22
      nodeSelector:
        ingress: "true"
        
控制器类型的资源创建方式:基于控制器创建pod,delete只是相当于重启,要彻底删除pod,必须删除控制器
不要随便的delete

4、job:job分为两类,job普通任务,定时任务cronjob

job的作用,执行只需要一次性的任务

脚本需要执行,数据库迁移,视频解码等等业务

对于k8s系统来说,既然定义了是job,你只需要执行一次,或者指定次数即可,不能一直允许

复制代码
第一点:必须指定的容器策略,onfailure Never
apiVersion: batch/v1
kind: Job
metadata:
  name: centos
spec:
  template:
    spec:
      containers:
      - name: centos
        image: centos:7
        command: ["/bin/bash","-c","test -e /etc/passwd1"]
      restartPolicy: Never

第二点:执行失败的次数也是受限的,默认是6次
apiVersion: batch/v1
kind: Job
metadata:
  name: centos
spec:
  template:
    spec:
      containers:
      - name: centos
        image: centos:7
        command: ["/bin/bash","-c","test -e /etc/passwd"]
      restartPolicy: Never
  backoffLimit: 4
#允许任务失败的次数是4次,4次到了之后,restartPolicy的策略,来进行容器的重启或者不重启

第三点:更新yaml文件,先删除任务,再更新,不能动态更新


删除
kubectl delete jobs.batch centos 

5、cronjob:周期性任务,定时执行,和Linux的crontab一模一样,语法一样(分时日月周)

应用场景
复制代码
1、定时备份 
2、通知作用
3、定时检测(结合探针一起做)


可选字段(可以不加)
  concurrencyPolicy: Allow
#如果执行失败的任务的保留的个数,默认是1个
  startingDeadlineSeconds: 15
#pod启动之后必须在一定时间内开始执行,如果超过15秒没有运行,任务将不会执行,任务标记也会失败
  successfulJobHistoryLimit:3
#保留成功的任务数,默认值就是3

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
#定时任务的调度命令
  schedule: "*/1 * * * *"
  concurrencyPolicy: Allow
#如果执行失败的任务的保留的个数,默认是1个
  startingDeadlineSeconds: 15
#pod启动之后必须在一定时间内开始执行,如果超过15秒没有运行,任务将不会执行,任务标记也会失败
  successfulJobHistoryLimit:3
#保留成功的任务数,默认值就是3
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: centos:7
            command: ["/bin/bash","-c","date; echo 小布"]
          restartPolicy: Never


删除
kubectl delete cronjobs.batch hello
相关推荐
阿里云云原生11 分钟前
探秘 AgentRun丨流量一大就瘫痪?如何解决 AI 模型调用之痛
云原生
是Yu欸1 小时前
从Ascend C算子开发视角看CANN的“软硬协同”
c语言·开发语言·云原生·昇腾·ascend·cann·开放社区
光头熊1 小时前
一次 nerdctl prune -a 导致 Kubernetes 节点不可用的复盘
kubernetes
码界奇点1 小时前
基于微服务架构的企业身份与访问管理系统设计与实现
微服务·云原生·架构·车载系统·毕业设计·源代码管理
一点晖光4 小时前
docker配置npm环境变量出现问题
docker·容器·npm
一分半心动4 小时前
windows docker desktop 安装VibeVoice
运维·docker·容器
LucidX4 小时前
Docker核心操作实战
运维·docker·容器
隔壁阿布都4 小时前
Docker Compose中的网络管理
运维·docker·容器
yuxb736 小时前
kubernetes弹性伸缩
笔记·kubernetes
ice_bird6 小时前
Ansible一键部署k8s1.28.2集群
kubernetes·ansible