因此，我们可以看到的是，get rs和get deploy 是一样结果，但deploy有一个 UP-TO-DATE，并且名称也不一样。但是看到的pod是一致的哦。水平扩展---将web01这个部署扩展到三个副本：
[root@master ~]# k scale deploy web01 --replicas=3 -n test deployment.apps/web01 scaled
水平扩展后，可以看到，slave1节点多了两个nginx的pod。
[root@master ~]# k get po -n test -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES web01-859c876457-d5978 1/1 Running 0 2m56s 10.244.1.23 slave1 <none> <none> web01-859c876457-j7hd5 1/1 Running 0 3m35s 10.244.2.20 slave2 <none> <none> web01-859c876457-mbt7p 1/1 Running 0 2m56s 10.244.1.24 slave1 <none> <none>
3，StatefulSet Controller
StatefulSet Controller主要是用于部署有状态的服务，有状态的pod与无状态的pod不一样的是，有状态的pod有时候需要通过其主机名来定位，而无状态的不需要，因为无状态的pod每个都是一样的，随机选一个就行，但对于有状态的来说，每一个pod都不一样，通常希望操作的是特定的某一个。statefulset适用于需要以下特点的应用：
（1）稳定的网络标志（主机名）：Pod重新调度后其PodName和HostName不变；（2）稳定的持久化存储：基于PVC，Pod重新调度后仍能访问到相同的持久化数据；（3）稳定的创建与扩容次序：有序创建或扩容，从序号小到大的顺序对pod进行创建（即从0到N-1），且在下一个Pod创建运行之前，所有之前的Pod必须都是Running和Ready状态；
（4）稳定的删除与缩容次序：有序删除或缩容，从序号大到小的顺序对pod进行删除（即从N-1到0），且在下一个Pod终止与删除之前，所有之前的Pod必须都已经被删除；（5）稳定的滚动更新次序：从序号大到小的顺序对pod进行更新（即从N-1到0），先删除后创建，且需等待当前序号的pod再次创建完成且状态为Ready时才能进行下一个pod的更新处理。示例，nginx使用volume挂载保存首页状态，具体代码如下：sc是这个：
[root@master ~]# k get sc -A NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE managed-nfs-storage fuseim.pri/ifs Delete Immediate true 28h
service和StatefulSet一起编写。
apiVersion: v1 kind: Service metadata: name: nginx labels: app: nginx spec: ports: - port: 80 name: web clusterIP: None selector: app: nginx --- apiVersion: apps/v1 kind: StatefulSet metadata: labels: app: sts-nginx name: web spec: selector: matchLabels: app: nginx serviceName: "nginx" replicas: 2 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.18 imagePullPolicy: IfNotPresent ports: - containerPort: 80 name: web volumeMounts: - name: www mountPath: /usr/share/nginx/html volumeClaimTemplates: - metadata: name: www spec: accessModes: ["ReadWriteOnce"] # ["ReadWriteOnce","ReadWriteMany"] storageClassName: managed-nfs-storage resources: requests: storage: 1Gi
查看pv，pvc和pod的名称以及状态。
[root@master ~]# k get pvc -A NAMESPACE NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE default test-claim Bound pvc-39177650-a78e-46d4-899c-7c1f52108280 1Mi RWX managed-nfs-storage 28h default www-web-0 Bound pvc-ffd14bef-e852-4955-840d-6d3c84d3c3d8 1Gi RWO managed-nfs-storage 19m default www-web-1 Bound pvc-5fd485a8-9e7b-470f-816f-d674cb5d7648 1Gi RWO managed-nfs-storage 19m [root@master ~]# k get pv -A NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pvc-39177650-a78e-46d4-899c-7c1f52108280 1Mi RWX Delete Bound default/test-claim managed-nfs-storage 28h pvc-5fd485a8-9e7b-470f-816f-d674cb5d7648 1Gi RWO Delete Bound default/www-web-1 managed-nfs-storage 19m pvc-ffd14bef-e852-4955-840d-6d3c84d3c3d8 1Gi RWO Delete Bound default/www-web-0 managed-nfs-storage 19m [root@master ~]# k get po -A |grep web default web-0 1/1 Running 0 21m default web-1 1/1 Running 0 21m
由以上输出可以看到statefulset的命名规则和删除规则：
statefulset pod的命名规则、pod创建与删除
如果创建一个名称为web、replicas为3的statefulset对象，则其pod名称分别为web-0、web-1、web-2。
statefulset pod的创建按0 - n的顺序创建，且在创建下一个pod之前，需要等待前一个pod创建完成并处于ready状态。
同样拿上面的例子来说明，在web statefulset创建后，2 个 Pod 将按顺序创建 web-0，web-1。在 web-0 处于 ready 状态之前，web-1 将不会被创建。直到 web-0 再次回到ready状态。
statefulset滚动更新或缩容过程中pod的删除按n - 0的顺序删除，且在删除下一个pod之前，需要等待前一个pod删除完成。
另外，当statefulset.Spec.VolumeClaimTemplates中定义了pod所需的pvc时，statefulset controller在创建pod时，会同时创建对应的pvc出来，但删除pod时，不会做对应pvc的删除操作，这些pvc需要人工额外做删除操作
4，Daemonset Controller
DaemonSet：服务守护进程，它的主要作用是在Kubernetes集群的所有节点中运行我们部署的守护进程，相当于在集群节点上分别部署Pod副本，如果有新节点加入集群，Daemonset会自动的在该节点上运行我们需要部署的Pod副本，相反如果有节点退出集群，Daemonset也会移除掉部署在旧节点的Pod副本。DaemonSet的主要特征：这个 Pod 运行在 Kubernetes 集群里的每一个节点（Node）上；每个节点上只会运行一个这样的 Pod 实例；如果新的节点加入 Kubernetes 集群后，该 Pod 会自动地在新节点上被创建出来；而当旧节点被删除后，它上面的 Pod 也相应地会被回收掉。
DaemonSet常用场景：
网络插件的 Agent 组件，如（Flannel，Calico）需要运行在每一个节点上，用来处理这个节点上的容器网络；
存储插件的 Agent 组件，如（Ceph，Glusterfs）需要运行在每一个节点上，用来在这个节点上挂载F远程存储目录；
监控系统的数据收集组件，如（Prometheus Node Exporter，Cadvisor）需要运行在每一个节点上，负责这个节点上的监控信息搜集。
日志系统的数据收集组件，如（Fluent，Logstash）需要运行在每一个节点上，负责这个节点上的日志信息搜集。
下面是一个示例，该示例将会在每个node内创建一个nginx-1.9.9版本的pod，除了master节点：
[root@master ~]# cat ds-test.yaml apiVersion: apps/v1 kind: DaemonSet # 类型为DaeminSet metadata: name: deamonset-example labels: app: daemonset spec: selector: matchLabels: name: deamonset-example # 当前这个 daemenset 只管理标签 name=deamonset-example的pod template: metadata: labels: name: deamonset-example # 设置标签 匹配上文 spec: containers: - name: daemonset-example image: nginx:1.9.9
Job Controller
简单示例一个，比如，打印π值到2000位，代码如下：
[root@master ~]# cat job-test apiVersion: batch/v1 kind: Job metadata: name: pi spec: completions: 3 template: spec: containers: - name: pi image: registry.cn-beijing.aliyuncs.com/google_registry/perl:5.26 command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] restartPolicy: Never backoffLimit: 4
执行这个文件：
k apply -f job-test.yaml
查看pod状态：
[root@master ~]# k get po -A |grep pi default pi-5zzr7 0/1 Completed 0 32m default pi-nhgqg 0/1 Completed 0 35m default pi-slf4k 0/1 Completed 0 32m
查看日志，证明这个job完成了：
[root@master ~]# k logs pi-slf4k 3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275898
其中有一个参数可以自动清理：
activeDeadlineSeconds: 10
这个表示该job运行成功10秒后，自动删除pod，那么，如果是需要看一下log的job，以确认job完成无误的话，这个参数是不可以带的哦。
CronJob Controller
示例：启动一个pod，打印容器内时间并打印hello world，代码如下：
[root@master ~]# cat cronjob.yaml apiVersion: batch/v1beta1 kind: CronJob metadata: name: hello spec: schedule: "*/1 * * * *" jobTemplate: spec: template: spec: containers: - name: hello image: busybox args: - /bin/sh - -c - date; echo "Hello world" restartPolicy: OnFailure
可以看到，每一分钟启动一个pod
[root@master ~]# k get po -A |grep hello default hello-1661256840-zbz77 0/1 Completed 0 2m19s default hello-1661256900-cjvsk 0/1 Completed 0 78s default hello-1661256960-pbmmr 0/1 Completed 0 18s
查看日志：
1. [root@master ~]# k logs hello-1661256840-zbz77 2. Tue Aug 23 12:14:06 UTC 2022 3. Hello world
删除该任务：
[root@master ~]# k get cronjob -A NAMESPACE NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE default hello */1 * * * * False 1 12s 6m42s [root@master ~]# k delete cronjob hello cronjob.batch "hello" deleted
