計算機系統

5G云計算

第三章 LINUX Kubernetes Pod控制器

一、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.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: 80kubectl apply -f nginx-deployment.yamlkubectl 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由以下幾個部分組成：
1）Headless Service（無頭服務）：用于為Pod資源標識符生成可解析的DNS記錄。
2）volumeClaimTemplates（存儲卷申請模板）：基于靜態或動態PV供給方式為Pod資源提供專有的固定存儲。
3）StatefulSet：用于管控Pod資源。

1）為什么要有headless

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

2）為什么要有volumeClaimTemplate

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

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

3）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.basevim 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 apply -f coredns.yamlkubectl get pods -n kube-system

4）示例

//查看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-svc
spec:ports:- port: 80name: httpprotocol: TCPtargetPort: 80type: ClusterIPclusterIP: Noneselector:app: myapp
---
apiVersion: apps/v1
kind: StatefulSet
metadata:name: myapp-sts
spec:serviceName: myapp-svcreplicas: 3selector:matchLabels:app: myapptemplate:metadata:labels:app: myappspec:containers:- name: myappimage: soscscs/myapp:v1ports:- containerPort: 80volumeMounts:- name: mypvcmountPath: /usr/share/nginx/htmlvolumeClaimTemplates:- metadata:name: mypvcspec:accessModes: ["ReadWriteOnce"]storageClassName: "nfs-client-storageclass"              #動態PV創建時，在PVC里聲明一個StorageClass對象的標識進行關聯resources:requests:storage: 2Gi解析上例：由于 StatefulSet 資源依賴于一個實現存在的 Headless 類型的 Service 資源，所以需要先定義一個名為 myapp-svc 的 Headless Service 資源，用于為關聯到每個 Pod 資源創建 DNS 資源記錄。接著定義了一個名為 myapp 的 StatefulSet 資源，它通過 Pod 模板創建了 3 個 Pod 資源副本，并基于 volumeClaimTemplates 向前面創建的PV進行了請求大小為 2Gi 的專用存儲卷//創建statefulset
kubectl apply -f stateful-demo.yaml kubectl get svc  #查看創建的無頭服務myapp-svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.0.0.1     <none>        443/TCP   4d19h
myapp-svc    ClusterIP   None         <none>        80/TCP    93skubectl get sts    #查看statefulset
NAME        READY   AGE
myapp-sts   3/3     19skubectl get pvc    #查看pvc綁定
NAME                STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS              AGE
mypvc-myapp-sts-0   Bound    pvc-2bc50b0d-09f4-410d-890e-6d95344ab945   2Gi        RWO            nfs-client-storageclass   5m15s
mypvc-myapp-sts-1   Bound    pvc-65162234-347e-4c07-8422-baa73ebd20ce   2Gi        RWO            nfs-client-storageclass   87s
mypvc-myapp-sts-2   Bound    pvc-027ef87c-0764-4c20-9ac8-a20f6c9a7376   2Gi        RWO            nfs-client-storageclass   82skubectl get pv    #查看pv綁定
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                       STORAGECLASS              REASON   AGE
pvc-027ef87c-0764-4c20-9ac8-a20f6c9a7376   2Gi        RWO            Delete           Bound    default/mypvc-myapp-sts-2   nfs-client-storageclass            2m4s
pvc-2bc50b0d-09f4-410d-890e-6d95344ab945   2Gi        RWO            Delete           Bound    default/mypvc-myapp-sts-0   nfs-client-storageclass            2m13s
pvc-65162234-347e-4c07-8422-baa73ebd20ce   2Gi        RWO            Delete           Bound    default/mypvc-myapp-sts-1   nfs-client-storageclass            2m9skubectl get pods   #查看Pod信息
NAME                                      READY   STATUS    RESTARTS   AGE
myapp-sts-0                               1/1     Running   0          2m11s
myapp-sts-1                               1/1     Running   0          2m9s
myapp-sts-2                               1/1     Running   0          2m8s
nfs-client-provisioner-55bbbfbb9f-bwrhm   1/1     Running   0          3m2s//當刪除一個 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//滾動更新
//StatefulSet 控制器將在 StatefulSet 中刪除并重新創建每個 Pod。它將以與 Pod 終止相同的順序進行（從最大的序數到最小的序數），每次更新一個 Pod。在更新其前身之前，它將等待正在更新的 Pod 狀態變成正在運行并就緒。如下操作的滾動更新是按照2-0的順序更新。
vim stateful-demo.yaml  		#修改image版本為v2
.....
image: soscscs/myapp:v2
....kubectl apply -f stateful-demo.yamlkubectl get pods -w   #查看滾動更新的過程
NAME                                      READY   STATUS              RESTARTS   AGE
myapp-sts-0                               1/1     Running             0          18m
myapp-sts-1                               1/1     Running             0          18m
myapp-sts-2                               0/1     ContainerCreating   0          6s
nfs-client-provisioner-55bbbfbb9f-bwrhm   1/1     Running             0          19m
myapp-sts-2                               1/1     Running             0          18s
myapp-sts-1                               1/1     Terminating         0          18m
myapp-sts-1                               0/1     Terminating         0          18m
myapp-sts-1                               0/1     Terminating         0          19m
myapp-sts-1                               0/1     Terminating         0          19m
myapp-sts-1                               0/1     Pending             0          0s
myapp-sts-1                               0/1     Pending             0          0s
myapp-sts-1                               0/1     ContainerCreating   0          0s
myapp-sts-1                               1/1     Running             0          1s
myapp-sts-0                               1/1     Terminating         0          19m
myapp-sts-0                               0/1     Terminating         0          19m
myapp-sts-0                               0/1     Terminating         0          19m
myapp-sts-0                               0/1     Terminating         0          19m
myapp-sts-0                               0/1     Pending             0          0s
myapp-sts-0                               0/1     Pending             0          0s
myapp-sts-0                               0/1     ContainerCreating   0          0s
myapp-sts-0                               1/1     Running             0          1s//在創建的每一個Pod中，每一個pod自己的名稱都是可以被解析的
kubectl exec -it myapp-sts-0 sh
/ # nslookup myapp-sts-0.myapp-svc.default.svc.cluster.local
nslookup: can't resolve '(null)': Name does not resolveName:      myapp-sts-0.myapp-svc.default.svc.cluster.local
Address 1: 10.244.1.18 myapp-sts-0.myapp-svc.default.svc.cluster.local/ # nslookup myapp-sts-1.myapp-svc.default.svc.cluster.local
nslookup: can't resolve '(null)': Name does not resolveName:      myapp-sts-1.myapp-svc.default.svc.cluster.local
Address 1: 10.244.0.37 myapp-sts-1.myapp-svc.default.svc.cluster.local/ # nslookup myapp-sts-2.myapp-svc.default.svc.cluster.local
nslookup: can't resolve '(null)': Name does not resolveName:      myapp-sts-2.myapp-svc.default.svc.cluster.local
Address 1: 10.244.1.19 myapp-sts-2.myapp-svc.default.svc.cluster.local//從上面的解析，我們可以看到在容器當中可以通過對Pod的名稱進行解析到ip。其解析的域名格式如下：
(pod_name).(service_name).(namespace_name).svc.cluster.local//擴展伸縮
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  #動態查看縮容

5）總結

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

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

6）常規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: Nevervim 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.yamlkubectl get pods,svckubectl 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

四、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: 80kubectl apply -f ds.yaml//DaemonSet會在每個node節點都創建一個Pod
kubectl get pods -owide

五、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: 2kubectl apply -f job-limit.yamlkubectl 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          4m21skubectl describe job busybox
......
Warning  BackoffLimitExceeded  43s    job-controller  Job has reached the specified backoff limit

六、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>          25skubectl 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          60skubectl 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

E 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