Pod控制器及其功用

pod控制器有多種類型

1、ReplicaSet

ReplicaSet主要三個組件組成

2、Deployment

3、DaemonSet

4、StatefulSet

5、Job

6、Cronjob

Pod與控制器之間的關系

1、Deployment

查看控制器配置

查看歷史版本

2、SatefulSet

為什么要有headless？

為什么要有volumeClaimTemplate？

服務發現：就是應用服務之間相互定位的過程。

安裝CoreDNS，僅二進制部署環境需要安裝CoreDNS

解析kubernetes和nginx-service名稱

查看statefulset的定義

清單定義StatefulSet

創建pv

定義PV

創建statefulset

滾動更新

總結

擴展伸縮

3、DaemonSet

DaemonSet會在每個node節點都創建一個Pod

4、Job

參數解釋

5、CronJob?

cronjob其它可用參數的配置

Pod控制器及其功用

Pod控制器，又稱之為工作負載（workload），是用于實現管理pod的中間層，確保pod資源符合預期的狀態，pod的資源出現故障時，會嘗試進行重啟，當根據重啟策略無效，則會重新新建pod的資源。

pod控制器有多種類型

1、ReplicaSet

代用戶創建指定數量的pod副本，確保pod副本數量符合預期狀態，并且支持滾動式自動擴容和縮容功能。

ReplicaSet主要三個組件組成

（1）用戶期望的pod副本數量
（2）標簽選擇器，判斷哪個pod歸自己管理
（3）當現存的pod數量不足，會根據pod資源模板進行新建
幫助用戶管理無狀態的pod資源，精確反應用戶定義的目標數量，但是RelicaSet不是直接使用的控制器，而是使用Deployment。

2、Deployment

工作在ReplicaSet之上，用于管理無狀態應用，目前來說最好的控制器。支持滾動更新和回滾功能，還提供聲明式配置。
ReplicaSet 與Deployment 這兩個資源對象逐步替換之前RC的作用。

3、DaemonSet

用于確保集群中的每一個節點只運行特定的pod副本，通常用于實現系統級后臺任務。比如ELK服務
特性：服務是無狀態的
服務必須是守護進程

4、StatefulSet

管理有狀態應用

5、Job

只要完成就立即退出，不需要重啟或重建

6、Cronjob

周期性任務控制，不需要持續后臺運行

Pod與控制器之間的關系

controllers：在集群上管理和運行容器的 pod 對象， pod 通過 label-selector 相關聯。
Pod 通過控制器實現應用的運維，如伸縮，升級等。

1、Deployment

部署無狀態應用
管理Pod和ReplicaSet
具有上線部署、副本設定、滾動升級、回滾等功能
提供聲明式更新，例如只更新一個新的image
應用場景：web服務

示例：

vim nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx?? ?
spec:replicas: 3selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.15.4ports:- containerPort: 80

kubectl create -f nginx-deployment.yaml

kubectl get pods,deploy,rs

查看控制器配置

kubectl edit deployment/nginx-deployment
apiVersion: apps/v1
kind: Deployment
metadata:annotations:deployment.kubernetes.io/revision: "1"creationTimestamp: "2021-04-19T08:13:50Z"generation: 1labels:app: nginx?? ??? ??? ??? ??? ?#Deployment資源的標簽name: nginx-deploymentnamespace: defaultresourceVersion: "167208"selfLink: /apis/extensions/v1beta1/namespaces/default/deployments/nginx-deploymentuid: d9d3fef9-20d2-4196-95fb-0e21e65af24a
spec:progressDeadlineSeconds: 600replicas: 3?? ??? ??? ??? ??? ? #期望的pod數量，默認是1revisionHistoryLimit: 10selector:matchLabels:app: nginxstrategy:rollingUpdate:maxSurge: 25%?? ??? ??? ??? ?#升級過程中會先啟動的新Pod的數量不超過期望的Pod數量的25%，也可以是一個絕對值maxUnavailable: 25%?? ???   ?#升級過程中在新的Pod啟動好后銷毀的舊Pod的數量不超過期望的Pod數量的25%，也可以是一個絕對值type: RollingUpdate?? ??? ??? ?#滾動升級template:metadata:creationTimestamp: nulllabels:app: nginx?? ??? ??? ???  ?#Pod副本關聯的標簽spec:containers:- image: nginx:1.15.4?? ??? ??? ??? ?#鏡像名稱imagePullPolicy: IfNotPresent?? ?  #鏡像拉取策略name: nginxports:- containerPort: 80?? ??? ??? ??? ?#容器暴露的監聽端口protocol: TCPresources: {}terminationMessagePath: /dev/termination-logterminationMessagePolicy: FilednsPolicy: ClusterFirstrestartPolicy: Always?? ??? ??? ??? ?#容器重啟策略schedulerName: default-schedulersecurityContext: {}terminationGracePeriodSeconds: 30
......

查看歷史版本

kubectl rollout history deployment/nginx-deployment
deployment.apps/nginx-deployment
REVISION ?CHANGE-CAUSE
1 ? ? ? ? <none>

2、SatefulSet

部署有狀態應用
穩定的持久化存儲，即Pod重新調度后還是能訪問到相同的持久化數據，基于PVC來實現
穩定的網絡標志，即Pod重新調度后其PodName和HostName不變，基于Headless Service（即沒有Cluster IP的Service）來實現
有序部署，有序擴展，即Pod是有順序的，在部署或者擴展的時候要依據定義的順序依次進行（即從0到N-1，在下一個Pod運行之前所有之前的Pod必須都是Running和Ready狀態），基于init containers來實現
有序收縮，有序刪除（即從N-1到0）

常見的應用場景：數據庫
https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/

apiVersion: v1
kind: Service
metadata:name: nginxlabels:app: nginx
spec:ports:- port: 80name: webclusterIP: Noneselector:app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:name: web
spec:selector:matchLabels:app: nginx # has to match .spec.template.metadata.labelsserviceName: "nginx"replicas: 3 # by default is 1template:metadata:labels:app: nginx # has to match .spec.selector.matchLabelsspec:terminationGracePeriodSeconds: 10containers:- name: nginximage: k8s.gcr.io/nginx-slim:0.8ports:- containerPort: 80name: webvolumeMounts:- name: wwwmountPath: /usr/share/nginx/htmlvolumeClaimTemplates:- metadata:name: wwwspec:accessModes: [ "ReadWriteOnce" ]storageClassName: "my-storage-class"resources:requests:storage: 1Gi

從上面的應用場景可以發現，StatefulSet由以下幾個部分組成：
●Headless Service（無頭服務）：用于為Pod資源標識符生成可解析的DNS記錄。
●volumeClaimTemplates（存儲卷申請模板）：基于靜態或動態PV供給方式為Pod資源提供專有的固定存儲。
●StatefulSet：用于管控Pod資源。

為什么要有headless？

在deployment中，每一個pod是沒有名稱，是隨機字符串，是無序的。而statefulset中是要求有序的，每一個pod的名稱必須是固定的。當節點掛了，重建之后的標識符是不變的，每一個節點的節點名稱是不能改變的。pod名稱是作為pod識別的唯一標識符，必須保證其標識符的穩定并且唯一。
為了實現標識符的穩定，這時候就需要一個headless service 解析直達到pod，還需要給pod配置一個唯一的名稱。

為什么要有volumeClaimTemplate？

大部分有狀態副本集都會用到持久存儲，比如分布式系統來說，由于數據是不一樣的，每個節點都需要自己專用的存儲節點。而在 deployment中pod模板中創建的存儲卷是一個共享的存儲卷，多個pod使用同一個存儲卷，而statefulset定義中的每一個pod都不能使用同一個存儲卷，由此基于pod模板創建pod是不適應的，這就需要引入volumeClaimTemplate，當在使用statefulset創建pod時，會自動生成一個PVC，從而請求綁定一個PV，從而有自己專用的存儲卷。

服務發現：就是應用服務之間相互定位的過程。

應用場景：
●動態性強：Pod會飄到別的node節點
●更新發布頻繁：互聯網思維小步快跑，先實現再優化，老板永遠是先上線再慢慢優化，先把idea變成產品掙到錢然后再慢慢一點一點優化
●支持自動伸縮：一來大促，肯定是要擴容多個副本

K8S里服務發現的方式---DNS，使K8S集群能夠自動關聯Service資源的“名稱”和“CLUSTER-IP”，從而達到服務被集群自動發現的目的。

實現K8S里DNS功能的插件：
●skyDNS：Kubernetes 1.3之前的版本
●kubeDNS：Kubernetes 1.3至Kubernetes 1.11
●CoreDNS：Kubernetes 1.11開始至今

安裝CoreDNS，僅二進制部署環境需要安裝CoreDNS

方法一
下載鏈接：https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/dns/coredns/coredns.yaml.base

vim transforms2sed.sed
s/__DNS__SERVER__/10.0.0.2/g
s/__DNS__DOMAIN__/cluster.local/g
s/__DNS__MEMORY__LIMIT__/170Mi/g
s/__MACHINE_GENERATED_WARNING__/Warning: This is a file generated from the base underscore template file: coredns.yaml.base/gsed -f transforms2sed.sed coredns.yaml.base > coredns.yaml

方法二

上傳 coredns.yaml 文件

kubectl create -f coredns.yamlkubectl get pods -n kube-system

vim nginx-service.yaml
apiVersion: v1 ?
kind: Service ?
metadata:name: nginx-servicelabels:app: nginx ?
spec:type: NodePort ?ports:- port: 80targetPort: 80 ?selector:app: nginx

kubectl create -f nginx-service.yaml

kubectl get svc
NAME ? ? ? ? ? ?TYPE ? ? ? ?CLUSTER-IP ? ? ?EXTERNAL-IP ? PORT(S) ? ? ? ?AGE
kubernetes ? ? ?ClusterIP ? 10.96.0.1 ? ? ? <none> ? ? ? ?443/TCP ? ? ? ?5d19h
nginx-service ? NodePort ? ?10.96.173.115 ? <none> ? ? ? ?80:31756/TCP ? 10s

vim pod6.yaml?
apiVersion: v1
kind: Pod
metadata:name: dns-test
spec:containers:- name: busyboximage: busybox:1.28.4args:- /bin/sh- -c- sleep 36000restartPolicy: Never

kubectl create -f pod6.yaml?

解析kubernetes和nginx-service名稱

kubectl exec -it dns-test sh
/ # nslookup kubernetes
Server: ? ?10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.localName: ? ? ?kubernetes
Address 1: 10.96.0.1 kubernetes.default.svc.cluster.local
/ # nslookup nginx-service
Server: ? ?10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.localName: ? ? ?nginx-service
Address 1: 10.96.173.115 nginx-service.default.svc.cluster.local

查看statefulset的定義

kubectl explain statefulset
KIND: ? ? StatefulSet
VERSION: ?apps/v1DESCRIPTION:StatefulSet represents a set of pods with consistent identities. Identitiesare defined as: - Network: A single stable DNS and hostname. - Storage: Asmany VolumeClaims as requested. The StatefulSet guarantees that a givennetwork identity will always map to the same storage identity.FIELDS:apiVersion?? ?<string>kind?? ?<string>metadata?? ?<Object>spec?? ?<Object>status?? ?<Object>

kubectl explain statefulset.spec
KIND: ? ? StatefulSet
VERSION: ?apps/v1RESOURCE: spec <Object>DESCRIPTION:Spec defines the desired identities of pods in this set.A StatefulSetSpec is the specification of a StatefulSet.FIELDS:podManagementPolicy?? ?<string> ?#Pod管理策略replicas?? ?<integer> ? ?#副本數量revisionHistoryLimit?? ?<integer> ? #歷史版本限制selector?? ?<Object> -required- ? ?#選擇器，必選項serviceName?? ?<string> -required- ?#服務名稱，必選項template?? ?<Object> -required- ? ?#模板，必選項updateStrategy?? ?<Object> ? ? ? #更新策略volumeClaimTemplates?? ?<[]Object> ? #存儲卷申請模板，必選項

清單定義StatefulSet

如上所述，一個完整的 StatefulSet 控制器由一個 Headless Service、一個 StatefulSet 和一個 volumeClaimTemplate 組成。如下資源清單中的定義：

vim stateful-demo.yaml
apiVersion: v1
kind: Service
metadata:name: myapp-svclabels:app: myapp-svc
spec:ports:- port: 80name: webclusterIP: Noneselector:app: myapp-pod
---
apiVersion: apps/v1
kind: StatefulSet
metadata:name: myapp
spec:serviceName: myapp-svcreplicas: 3selector:matchLabels:app: myapp-podtemplate:metadata:labels:app: myapp-podspec:containers:- name: myappimage: ikubernetes/myapp:v1ports:- containerPort: 80name: webvolumeMounts:- name: myappdatamountPath: /usr/share/nginx/htmlvolumeClaimTemplates:- metadata:name: myappdataannotations: ? ? ? ? ?#動態PV創建時，使用annotations在PVC里聲明一個StorageClass對象的標識進行關聯volume.beta.kubernetes.io/storage-class: nfs-client-storageclassspec:accessModes: ["ReadWriteOnce"]resources:requests:storage: 2Gi

解析上例：由于 StatefulSet 資源依賴于一個實現存在的 Headless 類型的 Service 資源，所以需要先定義一個名為 myapp-svc 的 Headless Service 資源，用于為關聯到每個 Pod 資源創建 DNS 資源記錄。接著定義了一個名為 myapp 的 StatefulSet 資源，它通過 Pod 模板創建了 3 個 Pod 資源副本，并基于 volumeClaimTemplates 向前面創建的PV進行了請求大小為 2Gi 的專用存儲卷。

創建pv

NFS節點

mkdir -p /data/volumes/v{1,2,3,4,5}vim /etc/exports
/data/volumes/v1 192.168.110.0/24(rw,no_root_squash)
/data/volumes/v2 192.168.110.0/24(rw,no_root_squash)
/data/volumes/v3 192.168.110.0/24(rw,no_root_squash)
/data/volumes/v4 192.168.110.0/24(rw,no_root_squash)
/data/volumes/v5 192.168.110.0/24(rw,no_root_squash)systemctl restart rpcbind
systemctl restart nfsexportfs -arvshowmount -e

定義PV

vim pv-demo.yaml
apiVersion: v1
kind: PersistentVolume
metadata:name: pv001labels:name: pv001
spec:nfs:path: /data/volumes/v1server: stor01accessModes: ["ReadWriteMany","ReadWriteOnce"]capacity:storage: 1Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv002labels:name: pv002
spec:nfs:path: /data/volumes/v2server: stor01accessModes: ["ReadWriteOnce"]capacity:storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv003labels:name: pv003
spec:nfs:path: /data/volumes/v3server: stor01accessModes: ["ReadWriteMany","ReadWriteOnce"]capacity:storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv004labels:name: pv004
spec:nfs:path: /data/volumes/v4server: stor01accessModes: ["ReadWriteMany","ReadWriteOnce"]capacity:storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv005labels:name: pv005
spec:nfs:path: /data/volumes/v5server: stor01accessModes: ["ReadWriteMany","ReadWriteOnce"]capacity:storage: 2Gi

kubectl apply -f pv-demo.yaml

kubectl get pv
NAME ? ? ?CAPACITY ? ACCESS MODES ? RECLAIM POLICY ? STATUS ? ? ?CLAIM ? ? STORAGECLASS ? REASON ? ?AGE
pv001 ? ? 1Gi ? ? ? ?RWO,RWX ? ? ? ?Retain ? ? ? ? ? Available ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?7s
pv002 ? ? 2Gi ? ? ? ?RWO ? ? ? ? ? ?Retain ? ? ? ? ? Available ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?7s
pv003 ? ? 2Gi ? ? ? ?RWO,RWX ? ? ? ?Retain ? ? ? ? ? Available ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?7s
pv004 ? ? 2Gi ? ? ? ?RWO,RWX ? ? ? ?Retain ? ? ? ? ? Available ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?7s
pv005 ? ? 2Gi ? ? ? ?RWO,RWX ? ? ? ?Retain ? ? ? ? ? Available ? ? ? ? ? ? ? ? ? ? ? ? ? ?? ??? ??? ?7s

創建statefulset

kubectl apply -f stateful-demo.yaml?

kubectl get svc ?#查看創建的無頭服務myapp-svc
NAME ? ? ? ? TYPE ? ? ? ?CLUSTER-IP ? ? ? EXTERNAL-IP ? PORT(S) ? ? ? ? ? ? AGE
kubernetes ? ClusterIP ? 10.96.0.1 ? ? ? ?<none> ? ? ? ?443/TCP ? ? ? ? ? ? 50d
myapp-svc ? ?ClusterIP ? None ? ? ? ? ? ? <none> ? ? ? ?80/TCP ? ? ? ? ? ? ?38s

kubectl get sts ? ?#查看statefulset
NAME ? ? ?DESIRED ? CURRENT ? AGE
myapp ? ? 3 ? ? ? ? 3 ? ? ? ? 55s

kubectl get pvc ? ?#查看pvc綁定
NAME ? ? ? ? ? ? ? ?STATUS ? ?VOLUME ? ?CAPACITY ? ACCESS MODES ? STORAGECLASS ? AGE
myappdata-myapp-0 ? Bound ? ? pv002 ? ? 2Gi ? ? ? ?RWO ? ? ? ? ? ? ? ? ? ? ? ? ? 1m
myappdata-myapp-1 ? Bound ? ? pv003 ? ? 2Gi ? ? ? ?RWO,RWX ? ? ? ? ? ? ? ? ? ? ? 1m
myappdata-myapp-2 ? Bound ? ? pv004 ? ? 2Gi ? ? ? ?RWO,RWX ? ? ? ? ? ? ? ? ? ? ? 1m

kubectl get pv ? ?#查看pv綁定
NAME ? ? ?CAPACITY ? ACCESS MODES ? RECLAIM POLICY ? STATUS ? ? ?CLAIM ? ? ? ? ? ? ? ? ? ? ? STORAGECLASS ? REASON ? ?AGE
pv001 ? ? 1Gi ? ? ? ?RWO,RWX ? ? ? ?Retain ? ? ? ? ? Available ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?6m
pv002 ? ? 2Gi ? ? ? ?RWO ? ? ? ? ? ?Retain ? ? ? ? ? Bound ? ? ? default/myappdata-myapp-0 ? ? ? ? ? ? ? ? ? ? ? ? ? ?6m
pv003 ? ? 2Gi ? ? ? ?RWO,RWX ? ? ? ?Retain ? ? ? ? ? Bound ? ? ? default/myappdata-myapp-1 ? ? ? ? ? ? ? ? ? ? ? ? ? ?6m
pv004 ? ? 2Gi ? ? ? ?RWO,RWX ? ? ? ?Retain ? ? ? ? ? Bound ? ? ? default/myappdata-myapp-2 ? ? ? ? ? ? ? ? ? ? ? ? ? ?6m
pv005 ? ? 2Gi ? ? ? ?RWO,RWX ? ? ? ?Retain ? ? ? ? ? Available ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?6m

kubectl get pods ? #查看Pod信息
NAME ? ? ? ? ? ? ? ? ? ? READY ? ? STATUS ? ?RESTARTS ? AGE
myapp-0 ? ? ? ? ? ? ? ? ?1/1 ? ? ? Running ? 0 ? ? ? ? ?2m
myapp-1 ? ? ? ? ? ? ? ? ?1/1 ? ? ? Running ? 0 ? ? ? ? ?2m
myapp-2 ? ? ? ? ? ? ? ? ?1/1 ? ? ? Running ? 0 ? ? ? ? ?2m

當刪除一個 StatefulSet 時，該 StatefulSet 不提供任何終止 Pod 的保證。為了實現 StatefulSet 中的 Pod 可以有序且體面地終止，可以在刪除之前將 StatefulSet 縮容到 0。

kubectl scale statefulset myappdata-myapp --replicas=0
kubectl delete -f stateful-demo.yaml?? ?

此時PVC依舊存在的，再重新創建pod時，依舊會重新去綁定原來的pvc

kubectl apply -f stateful-demo.yaml

kubectl get pvc
NAME ? ? ? ? ? ? ? ?STATUS ? ?VOLUME ? ?CAPACITY ? ACCESS MODES ? STORAGECLASS ? AGE
myappdata-myapp-0 ? Bound ? ? pv002 ? ? 2Gi ? ? ? ?RWO ? ? ? ? ? ? ? ? ? ? ? ? ? 5m
myappdata-myapp-1 ? Bound ? ? pv003 ? ? 2Gi ? ? ? ?RWO,RWX ? ? ? ? ? ? ? ? ? ? ? 5m
myappdata-myapp-2 ? Bound ? ? pv004 ? ? 2Gi ? ? ? ?RWO,RWX

滾動更新

//StatefulSet 控制器將在 StatefulSet 中刪除并重新創建每個 Pod。它將以與 Pod 終止相同的順序進行（從最大的序數到最小的序數），每次更新一個 Pod。在更新其前身之前，它將等待正在更新的 Pod 狀態變成正在運行并就緒。如下操作的滾動更新是按照2-0的順序更新。

vim stateful-demo.yaml ??? ??? ?#修改image版本為v2
.....
image: ikubernetes/myapp:v2
....kubectl apply -f stateful-demo.yaml

kubectl get pods -w ? #查看滾動更新的過程
NAME ? ? ?READY ? STATUS ? ? ? ?RESTARTS ? AGE
myapp-0 ? 1/1 ? ? Running ? ? ? 0 ? ? ? ? ?29s
myapp-1 ? 1/1 ? ? Running ? ? ? 0 ? ? ? ? ?27s
myapp-2 ? 0/1 ? ? Terminating ? 0 ? ? ? ? ?26s
myapp-2 ? 0/1 ? ? Terminating ? 0 ? ? ? ? ?30s
myapp-2 ? 0/1 ? ? Terminating ? 0 ? ? ? ? ?30s
myapp-2 ? 0/1 ? ? Pending ? ? ? 0 ? ? ? ? ?0s
myapp-2 ? 0/1 ? ? Pending ? ? ? 0 ? ? ? ? ?0s
myapp-2 ? 0/1 ? ? ContainerCreating ? 0 ? ? ? ? ?0s
myapp-2 ? 1/1 ? ? Running ? ? ? ? ? ? 0 ? ? ? ? ?31s
myapp-1 ? 1/1 ? ? Terminating ? ? ? ? 0 ? ? ? ? ?62s
myapp-1 ? 0/1 ? ? Terminating ? ? ? ? 0 ? ? ? ? ?63s
myapp-1 ? 0/1 ? ? Terminating ? ? ? ? 0 ? ? ? ? ?66s
myapp-1 ? 0/1 ? ? Terminating ? ? ? ? 0 ? ? ? ? ?67s
myapp-1 ? 0/1 ? ? Pending ? ? ? ? ? ? 0 ? ? ? ? ?0s
myapp-1 ? 0/1 ? ? Pending ? ? ? ? ? ? 0 ? ? ? ? ?0s
myapp-1 ? 0/1 ? ? ContainerCreating ? 0 ? ? ? ? ?0s
myapp-1 ? 1/1 ? ? Running ? ? ? ? ? ? 0 ? ? ? ? ?30s
myapp-0 ? 1/1 ? ? Terminating ? ? ? ? 0 ? ? ? ? ?99s
myapp-0 ? 0/1 ? ? Terminating ? ? ? ? 0 ? ? ? ? ?100s
myapp-0 ? 0/1 ? ? Terminating ? ? ? ? 0 ? ? ? ? ?101s
myapp-0 ? 0/1 ? ? Terminating ? ? ? ? 0 ? ? ? ? ?101s
myapp-0 ? 0/1 ? ? Pending ? ? ? ? ? ? 0 ? ? ? ? ?0s
myapp-0 ? 0/1 ? ? Pending ? ? ? ? ? ? 0 ? ? ? ? ?0s
myapp-0 ? 0/1 ? ? ContainerCreating ? 0 ? ? ? ? ?0s
myapp-0 ? 1/1 ? ? Running ? ? ? ? ? ? 0 ? ? ? ? ?1s

在創建的每一個Pod中，每一個pod自己的名稱都是可以被解析的

kubectl exec -it myapp-0 /bin/sh
Name: ? ? ?myapp-0.myapp-svc.default.svc.cluster.local
Address 1: 10.244.2.27 myapp-0.myapp-svc.default.svc.cluster.local
/ # nslookup myapp-1.myapp-svc.default.svc.cluster.local
nslookup: can't resolve '(null)': Name does not resolveName: ? ? ?myapp-1.myapp-svc.default.svc.cluster.local
Address 1: 10.244.1.14 myapp-1.myapp-svc.default.svc.cluster.local
/ # nslookup myapp-2.myapp-svc.default.svc.cluster.local
nslookup: can't resolve '(null)': Name does not resolveName: ? ? ?myapp-2.myapp-svc.default.svc.cluster.local
Address 1: 10.244.2.26 myapp-2.myapp-svc.default.svc.cluster.local

從上面的解析，我們可以看到在容器當中可以通過對Pod的名稱進行解析到ip。其解析的域名格式如下：

(pod_name).(service_name).(namespace_name).svc.cluster.local

總結

無狀態
1）deployment 認為所有的pod都是一樣的
2）不用考慮順序的要求
3）不用考慮在哪個node節點上運行
4）可以隨意擴容和縮容?

有狀態
1）實例之間有差別，每個實例都有自己的獨特性，元數據不同，例如etcd，zookeeper
2）實例之間不對等的關系，以及依靠外部存儲的應用。

常規service和無頭服務區別
service：一組Pod訪問策略，提供cluster-IP群集之間通訊，還提供負載均衡和服務發現。
Headless service：無頭服務，不需要cluster-IP，而是直接以DNS記錄的方式解析出被代理Pod的IP地址。

vim pod6.yaml?
apiVersion: v1
kind: Pod
metadata:name: dns-test
spec:containers:- name: busyboximage: busybox:1.28.4args:- /bin/sh- -c- sleep 36000restartPolicy: Never

vim sts.yaml
apiVersion: v1
kind: Service
metadata:name: nginxlabels:app: nginx
spec:ports:- port: 80name: webclusterIP: Noneselector:app: nginx
---
apiVersion: apps/v1beta1 ?
kind: StatefulSet ?
metadata:name: nginx-statefulset ?namespace: default
spec:serviceName: nginx ?replicas: 3 ?selector:matchLabels: ?app: nginxtemplate: ?metadata:labels:app: nginx ?spec:containers:- name: nginximage: nginx:latest ?ports:- containerPort: 80 ?

kubectl apply -f sts.yamlkubectl apply -f pod6.yaml

kubectl get pods,svc

kubectl exec -it dns-test sh
/ # nslookup nginx-statefulset-0.nginx.default.svc.cluster.local
/ # nslookup nginx-statefulset-1.nginx.default.svc.cluster.local
/ # nslookup nginx-statefulset-2.nginx.default.svc.cluster.localkubectl exec -it nginx-statefulset-0 bash
/# curl nginx-statefulset-0.nginx
/# curl nginx-statefulset-1.nginx
/# curl nginx-statefulset-2.nginx

擴展伸縮

kubectl scale sts myapp --replicas=4 ?#擴容副本增加到4個kubectl get pods -w ?#動態查看擴容kubectl get pv ?#查看pv綁定kubectl patch sts myapp -p '{"spec":{"replicas":2}}' ?#打補丁方式縮容kubectl get pods -w ?#動態查看縮容

3、DaemonSet

DaemonSet 確保全部（或者一些）Node 上運行一個 Pod 的副本。當有 Node 加入集群時，也會為他們新增一個 Pod 。當有 Node 從集群移除時，這些 Pod 也會被回收。刪除 DaemonSet 將會刪除它創建的所有 Pod。

使用 DaemonSet 的一些典型用法

●運行集群存儲 daemon，例如在每個 Node 上運行 glusterd、ceph。
●在每個 Node 上運行日志收集 daemon，例如fluentd、logstash。
●在每個 Node 上運行監控 daemon，例如 Prometheus Node Exporter、collectd、Datadog 代理、New Relic 代理，或 Ganglia gmond。

應用場景：Agent
//官方案例（監控）
https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/

示例

vim ds.yaml?
apiVersion: apps/v1
kind: DaemonSet?
metadata:name: nginx-daemonSetlabels:app: nginx
spec:selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.15.4ports:- containerPort: 80

kubectl apply -f ds.yaml

DaemonSet會在每個node節點都創建一個Pod

kubectl get pods
nginx-deployment-4kr6h ? 1/1 ? ? Running ? ? 0 ? ? ? ? ?35s
nginx-deployment-8jrg5 ? 1/1 ? ? Running ? ? 0 ? ? ? ? ?35s

4、Job

Job分為普通任務（Job）和定時任務（CronJob）
常用于運行那些僅需要執行一次的任務
應用場景：數據庫遷移、批處理腳本、kube-bench掃描、離線數據處理，視頻解碼等業務
https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/?? ?

示例

vim job.yaml
apiVersion: batch/v1
kind: Job
metadata:name: pi
spec:template:spec:containers:- name: piimage: perlcommand: ["perl", ?"-Mbignum=bpi", "-wle", "print bpi(2000)"]restartPolicy: NeverbackoffLimit: 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達到，作業將被標記為失敗。
在所有node節點下載perl鏡像，因為鏡像比較大，所以建議提前下載好

docker pull perlkubectl apply -f job.yaml?kubectl get pods
pi-bqtf7 ? ? ? ? ? ? ? ? 0/1 ? ? Completed ? 0 ? ? ? ? ?41s

結果輸出到控制臺

kubectl logs pi-bqtf7
3.14159265......

清除job資源

kubectl delete -f job.yaml?

backoffLimit
vim job-limit.yaml
apiVersion: batch/v1
kind: Job
metadata:name: busybox
spec:template:spec:containers:- name: busyboximage: busyboximagePullPolicy: IfNotPresentcommand: ["/bin/sh", "-c", "sleep 10;date;exit 1"]restartPolicy: NeverbackoffLimit: 2

kubectl apply -f job-limit.yaml

kubectl get job,pods
NAME ? ? ? ? ? ? ? ?COMPLETIONS ? DURATION ? AGE
job.batch/busybox ? 0/1 ? ? ? ? ? 4m34s ? ? ?4m34sNAME ? ? ? ? ? ? ? ?READY ? STATUS ? RESTARTS ? AGE
pod/busybox-dhrkt ? 0/1 ? ? Error ? ?0 ? ? ? ? ?4m34s
pod/busybox-kcx46 ? 0/1 ? ? Error ? ?0 ? ? ? ? ?4m
pod/busybox-tlk48 ? 0/1 ? ? Error ? ?0 ? ? ? ? ?4m21s

kubectl describe job busybox
......
Warning ?BackoffLimitExceeded ?43s ? ?job-controller ?Job has reached the specified backoff limit

5、CronJob?

周期性任務，像Linux的Crontab一樣。
周期性任務
應用場景：通知，備份
https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/

示例

每分鐘打印hello

vim cronjob.yaml
apiVersion: batch/v1beta1
kind: CronJob
metadata:name: hello
spec:schedule: "*/1 * * * *"jobTemplate:spec:template:spec:containers:- name: helloimage: busyboximagePullPolicy: IfNotPresentargs:- /bin/sh- -c- date; echo Hello from the Kubernetes clusterrestartPolicy: 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