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

扩容与缩容

kubectl edit sts

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可以容器化部署。

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        <none>          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 控制器有几种？
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集群内部可通过 <pod_name>.<svc.name>.<namespace_name>.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 字段设置时间周期表，格式为 '分 时 日 月 周'