pod控制器

?

预期状态

pod控制器的类型

pod和控制器之间的关系

controllers：管理控制器，pod通过label(标签)到selector(选择标签)进行关联

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx2
  name: nginx2
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx2
  strategy:
    type: Recreate
#每次有更新，会把旧的全部所有停止，然后再启动新的实例，服务可能会短暂的终断,这个很少见，一般来说这个字段可加可不加
  template:
    metadata:
      labels:
        app: nginx2
    spec:
      containers:
      - image: nginx:1.22
        name: nginx2

如果不加
strategy:
    type: Recreate
strategy：
 rollingUpdate:
   maxSurge: 25%
   maxUnavailable: 25%
这是Deployment的默认更新策略
RollingUpdate：滚动更新
MaxSurge：25%升级过程中，新启动的pod数量不能超过期望pod数的25%，如果有3个根据25%策略那会先拉起1个然后再拉起第二个
MaxUnavailable：25%升级过程中，新的pod启动好后，销毁的旧的pod数量不能超过期望的25%

无状态应用

无状态应用，pod名称是无序的，任务所有pod的都是一体的，共享存储NFS

所有deployment下的pod共享一个存储，

StatfulSetL有状态应用，pod的名称是有序的，所有的pod都是独立的，存储卷也是独立的。

顺序从0-n，且delete删除也不会改变pod的序号，扩缩容也是有序或缩容如0,1,2,3按照顺序

Headless service：无头服务，没有clusterIP

必须要有动态的pvc

Headless service： k8s集群当中一种特殊的服务类型，不分配ClusterIP给service，也不会负载均衡到后端的pod，由DNS来提供服务的发现和访问

由于Clusterip的是空，k8s集群会给每个headless serviced中的pod创建一个dns记录

格式： pod-name.headles-service-name.namespace.Svc.Cluster.Local.

?????Web-o ??nginx-web ??defaults ??本地地址 ?(pod的ip地址)

通过：dns直接访问pod的ip地址 ?如web-0 ?映射 10.244.1.10

为什么要用headless：就是为了有序，独立个体，deployment创建的pod是没有名称的，随机的字符串，无序，他需要一个集中的clusterip来集中统一统一为pod提供网络

Statefulset是有序的集合pod的名称是固定的，即便是重建之后的pod的标识符也不变，pod的名称是唯一的标识符

系统直接通过pod名称解析ip地址，ip地址会不会变？（会变）

为什么要有volumeClaimTemplates：

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

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

1.节点不是固定节点的应用，不是固定ip的应用

2.更新发布比较频繁

3.支持自动伸缩，节点的资源不够，可以自动扩容

apiVerion: v1
kind: Service
metadata:
  name: nginx-web
  labels:
    app: nginx2
spec:
  ports:
  - port: 80
    targetPort: 80
  clusterIP: ""
  selector:
    app: nginx2
---
apiVerion: 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"]
      storageClassName: "nfs-client-storageclass"
      resources:
        requests:
          storage: 2Gi

daemonSet?

核心机制就是确保每个节点上都运行一个pod副本，当有node节点加入集群，也会为它新增一个pod，当node节点从集群当中移除时，pod也会被回收，

DaemonSet不需要指定调度策略，默认会在每个节点创建一个pod，除非污点

我们也可以通过指定的方式，只把daemonset部署在指定的节点

Daemonset没有副本数选择，只能部署一个，也不需要设置

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: nginx-daemon
  labels:
    app: nginx1
  namespaces:
#提高代码的可读性，别人读，不同业务可以通过namespace隔离命名时要根据业务专业命名
spec:
  selector:
    matchLabels:
      app: nginx1
  template:
    metadata:
      labels:
        app: nginx1
    spec:
      containers:
      - name: nginx
        image: nginx:1.22
      nodeSelector:
#这个匹配的是标签
        ingress: "true"
#只要往有true标签的节点部署

?job

job分为两类，一个就是job，普通任务，还有一个cronjob，定时任务

Job的作用，执行只需要一次性的任务

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

对于k8s系统来说，既然定义了job，你只需要执行一次，或者指定次数即可，不能一直运行，同样对失败也是有次数的

第一点:必须指定的容器的重启策略 ，onfailure， never，

第二点:执行失败的次数也是受限的，默认是6次，可以自定义，可以不加

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

容器化部署，部署过数据库没有

数据库是核心资产不会容器化部署

前端会容器化部署码

Nginx可以容器化部署

[root@master01 k8s]# kubectl apply -f f.yaml
The Job "centos" is invalid:
* spec.template.spec.restartPolicy: Required value: valid values: "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/passwd"]
      restartPolicy: Never
  backoffLimit: 4
#允许任务失败的次数是4次，4次到了之后，restartpolicy的策略，来进行容器的重启或者
不重启·

?cronjob

cronjob 周期性任务，定时执行，和linuxcrontable一个意思，语法一样

分时日月周

应用场景:定时备份，通知作用，定时监测（结合探针）

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

cronjob结合探针

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  concurrencyPolicy: Allow
#如果执行失败的任务的保留的个数，默认是1个
  startingDeadlineSeconds: 15
#pod启动之后必须在一定的时间内开始执行，如果超过15秒仍未运行，任务将不会运行，任
务也会标记失败，可选字段，可以不加
  successfulJobsHistoryLimit: 3
#保留成功的任务数，默认值就是3
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: centos:7
            command: ["/bin/bash","-c","date; echo gqzs"]
            livenessProbe:
              tcpSocket:
                port: 80
          restartPolicy: Never