pod控制器

pod控制器:

pv pvc 动态pv.

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:周期性的定时任务控制器。不需要在后台持续运行。

(1)有状态应用 
pod的名称有序,所有pod都独立,存储卷也独立。顺序0-n,delete删除也不会改变pod的序号。扩缩容也是有序扩缩容 
(2)无状态应用
deployment认为所有的pod都是一样的,名称无序,共享存储nfs。
不用考虑顺序的要求
不用考虑在哪个node节点上运行
可以随意扩容和缩容

Deployment控制器

SatefulSet 控制器

headless service:无头服务,没有clusterlP。

必须要有动态的pvc.

创建演示 

apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  ports:
  - port: 80
    targetPort: 80
  clusterIP: None
  selector:
    app: nginx-sts
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: nginx-sts
spec:
  replicas: 3
  serviceName: "nginx-sts"
  selector:
    matchLabels:
      app: nginx-sts
  template:
    metadata:
      labels:
        app: nginx-sts
    spec:
      containers:
      - image: nginx:1.14
        imagePullPolicy: IfNotPresent
        name: nginx-test
        ports:
        - containerPort: 80
          protocol: TCP
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "nfs-client-storageclass"
      resources:
        requests:
          storage: 2Gi

pod控制器_第1张图片

pod控制器_第2张图片

pod控制器_第3张图片

pod控制器_第4张图片

扩容与缩容

kubectl edit sts

pod控制器_第5张图片

pod控制器_第6张图片

pod控制器_第7张图片

pod控制器_第8张图片

headless service:k8s集群当中一种特殊的服务类型。不分配clusterlP给service.也不会负载均衡到后端的pod。
DNS来提供服务的发现和访问。
由于Clusterip是空,k8s集群会给每个headless service中的pod创建一个dns记录。
格式: pod-name.headless-service-name.namespace.svc.cluster.local.

为什么要用headless:

有序。
独立个体。
deployment的pod是没有名称的,随机字符串,无序。他需要一个集中的clusterip来集中统一为pod提供网络。
statefulset是有序的,pod的名称是固定的。重建之后pod的标识符也不变。pod的名称是唯一的标识符。
系统直接通过pod名称解析ip地址。ip地址不变?

为什么要有volumeClaimTemplates:

有状态的副本吧集群都会涉及持久化存储,每个pod是独立个体,每个pod都有一个自己专用的存储点。
statefulset在定义的时候就规定了每个pod是不能同一个存储卷。所以才需要动态pv.
不是固定节点的应用,不是固定ip的应用、
更新发布比较频发。
支持自动伸缩,节点的资源资源不够,可以自动扩容。

DaemonSet控制器

案例演示

vim 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.14
        ports:
        - containerPort: 80
 
 
kubectl apply -f ds.yaml

daemonSet:确保每个节点上都运行一个pod副本。当node加入集群,也会为他新增一个pod.
当node节点从集群当中移除时,pod也会被回收。
daemonSet不需要指定调度策略,默认会在每个节点创建一个pod。除非污点。
我们也可以通过指定的方式,只把deamonset部署在指定的节点。
没有副本数选择,不需要设置。
控制器类型的资源创建方式:基于控制器创建的pod,delete只是相当于重启,要彻底删除pod,必须删除控制器。
不要随便的delete。

Job控制器

vim job.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

参数解释:
.spec.template.spec.restartPolicy该属性拥有三个候选值:OnFailure,Never和Always。默认值为Always。它主要用于描述Pod内容器的重启策略。在Job中只能将此属性设置为OnFailure或Never,否则Job将不间断运行。

.spec.backoffLimit用于设置job失败后进行重试的次数,默认值为6。默认情况下,除非Pod失败或容器异常退出,Job任务将不间断的重试,此时Job遵循 .spec.backoffLimit上述说明。一旦.spec.backoffLimit达到,作业将被标记为失败。

job的作用,执行只需要一次性的任务。
脚本需要执行,数据库迁移,视频解码等等业务。
对于k8s系统来说,既然定义了是job,你只需要执行一次,或者指定次数即可。不能一直允许。
第一个:必须指定的容器策略 onfailure never
第二个:执行失败的次数也是受限的。默认是6次。

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

容器化部署,部署过数据库没有?数据库是核心资产,不会容器化部署。

前端你们会容器化部署吗?nginx可以容器化部署。

pod控制器_第9张图片

CronJob 

周期性任务,定时执行,和linux的crontab一模一样,语法一样

分时日月周

应用场景:定时备份通知作用。定时检测(结合探针一起做)

示例:
//每分钟打印hello
vim cronjob.yaml
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            #声明了 CronJob 创建的任务执行时发生重叠如何处理(并发性规则仅适用于相同 CronJob 创建的任务)。spec仅能声明下列规则中的一种:
                                         ●Allow (默认):CronJob 允许并发任务执行。
                                         ●Forbid:CronJob 不允许并发任务执行;如果新任务的执行时间到了而老任务没有执行完,CronJob 会忽略新任务的执行。
                                         ●Replace:如果新任务的执行时间到了而老任务没有执行完,CronJob 会用新任务替换当前正在运行的任务。
  startingDeadlineSeconds: 15        #它表示任务如果由于某种原因错过了调度时间,开始该任务的截止时间的秒数。过了截止时间,CronJob 就不会开始任务,且标记失败.如果此字段未设置,那任务就没有最后期限。
  successfulJobsHistoryLimit: 3        #要保留的成功完成的任务数(默认为3)
  failedJobsHistoryLimit:1         #要保留多少已完成和失败的任务数(默认为1)
  suspend:true                     #如果设置为 true ,后续发生的执行都会被挂起。 这个设置对已经开始的执行不起作用。默认是 false。
  schedule: '*/1 * * * *'            #必需字段,作业时间表。在此示例中,作业将每分钟运行一次
  jobTemplate:                        #必需字段,作业模板。这类似于工作示例
 
kubectl create -f cronjob.yaml 
 
kubectl get cronjob
NAME    SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
hello   */1 * * * *   False     0                  25s
 
kubectl get pods
NAME                     READY   STATUS      RESTARTS   AGE
hello-1621587180-mffj6   0/1     Completed   0          3m
hello-1621587240-g68w4   0/1     Completed   0          2m
hello-1621587300-vmkqg   0/1     Completed   0          60s
 
kubectl logs hello-1621587180-mffj6
Fri May 21 09:03:14 UTC 2021
Hello from the Kubernetes cluster
//如果报错: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

pod控制器_第10张图片

总结

Pod 控制器有几种?
1、Deployment+ReplicaSet  部署无状态应用的Pod
2、StatefulSet    部署有状态应用的Pod
3、DaemonSet      在K8S集群的所有Node节点上部署相同的Pod
4、Job            部署一次性的任务Pod,完成后就会退出并不会重启
5、CronJob        部署周期性的任务Pod,完成后就会退出并不会重启
 
Deployment
1、部署无状态应用的
2、创建和管理 ReplicaSet(RS)和Pod资源,维护Pod副本数量与期望值相同
3、创建和删除Pod时是并行执行的,升级时是先创建一部分新Pod,再删除一部分旧Pod
 
StatefulSet
1、部署有状态应用的   
2、每个Pod的名称是唯一且固定不变的,而且每个Pod应该拥有自己专属的持久化存储(基于PVC模板volumeClaimTemplates绑定PV)
3、需要关联 Headless Service(ClusterIP为None),在K8S集群内部可通过 ...svc.cluster.local 的格式解析出 PodIP (基于无头服务和CoreDNS实现)
4、创建、删除、升级、扩缩容Pod都是有序进行的(默认为串行执行的):
    创建、升级是升序执行的(顺序为Pod标识序号0..n-1),删除是逆序执行的(顺序为 n-1..0)
    扩缩容都是逆序执行的(顺序为 n-1..0),会先删除旧Pod,再创建新Pod
 
spec.podManagementPolicy: Parallel  #可设置StatefulSet创建和删除Pod时为并行执行
 
service类型种类  4+1
ClusterIP
NodePort
LoadBalancer
ExtenalName
 
Headless Service
常规service与Headless Service的区别
常规service:一组Pod的访问策略,提供ClusterIP在K8S集群内部访问,还提供负载均衡和服务发现功能
Headless Service:无头服务,可以不需要ClusterIP,与StatefulSet资源关联配合CoreDNS实现通过 Pod名称 解析出 PodIP
 
DaemonSet
1、理论上可以在K8S集群的所有Node节点上创建同类型的Pod资源(无论Node节点什么加入到K8S集群)
2、会受到Node节点上的污点或者cordon不可调度设置的影响。可以在Pod配置中设置容忍忽略污点,设置uncordon解除不可调度
3、不需要设置副本数replicas
 
Job
1、部署一次性任务的资源
2、任务正常完成后Pod容器会立即退出并不会再重启(Job类型Pod容器的retartPolicy通常设置为Never),也不会重建Pod
3、如果任务异常完成Pod容器异常退出,会重建Pod重试任务,重试次数根据 backoffLimit 配置(默认6次)
 
CronJob
1、部署周期性任务的资源,一次任务至少创建一个Pod
2、任务正常完成后Pod容器会立即退出并不会再重启(Job类型Pod容器的retartPolicy不设置为Always),也不会重建Pod
3、使用 spec.schedule 字段设置时间周期表,格式为 '分 时 日 月 周'

你可能感兴趣的:(网络)