溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章將為大家詳細講解有關k8s中kubernetes字段含義，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。
容器啟動后等待多少秒后kubelet 才開始執(zhí)行探測，默認是 0 秒，最小值是 0。
執(zhí)行探測的時間間隔（單位是秒）。默認是 10 秒。最小值是 1
探測超時時間。如果超過這個時間，則認為探測失敗。默認值是 1 秒。最小值是 1。
探測器在失敗后，被視為成功的最小連續(xù)成功數。默認值是 1。 存活探測的這個值必須是 1。最小值是 1
探測失敗時的重試次數。 當為存活探測時，達到閾值則重啟容器。 當為就緒探測時Pod會被打上NotReady的標簽。默認值是 3。最小值是 1。
用來對于一個Volume分別給多個容器使用時，會根據subPath給出的key創(chuàng)建目錄。在這個例子中site-data這個Volume在分別個mysql和php容器使用時，html的內容映射在site-data卷的html子目錄，而數據庫則保存在site-data卷的mysql目錄。
apiVersion: v1
kind: Pod
metadata:
name: my-lamp-site
spec:
containers:
- name: mysql
image: mysql
volumeMounts:
- mountPath: /var/lib/mysql
name: site-data
subPath: mysql
- name: php
image: php
volumeMounts:
- mountPath: /var/www/html
name: site-data
subPath: html
volumes:
- name: site-data
persistentVolumeClaim:
claimName: my-lamp-site-data
用于識別該資源內部版本號的字符串，在用于 Watch 操作時，可以避免在 GET 操作和下一次 Watch 操作之間造成的信息不一致，客戶端可以用它來判斷資源是否改變。該值應該被客戶端看作不透明，且不做任何修改就返回給服務端?？蛻舳瞬粦摷俣ò姹拘畔⒕哂锌缑臻g、跨不同資源類別、跨不同服務器的含義。
K8S滾動升級的步驟:
- K8S首先啟動新的POD
- K8S等待新的POD進入Ready狀態(tài)
- K8S創(chuàng)建Endpoint，將新的POD納入負載均衡
- K8S移除與老POD相關的Endpoint，并且將老POD狀態(tài)設置為Terminating，此時將不會有新的請求到達老POD
- 同時 K8S 會給老POD發(fā)送SIGTERM信號，并且等待 terminationGracePeriodSeconds 這么長的時間。(默認為30秒)
- 超過terminationGracePeriodSeconds等待時間后， K8S 會強制結束老POD
labels:
component: kube-controller-manager
tier: control-plane"tier" : "frontend", "tier" : "backend", "tier" : "cache"
tier意思是類似電影院階梯座位那種的一排，有等級的含義在里面。
可以簡單里面為架構里面的分層。一般設為前端，后端，緩存，控制平面這些值
根對象是rs，從對象是pod。
如果在pod的ownerReferences字段下由設置了blockOwnerDeletion: true，那么在刪除rs的時候，會先等pod刪除完后，在刪除rs。
在以前的博文中介紹過如何配置kubelet，按策略刪除無用image、正?；蛘弋惓＝K止不會再啟動的container，以節(jié)省資源。kubelet回收的對象在容器層面。那么kubernetes層面的對象，比如pod、ReplicaSet、Replication Controller、Deployment、StatefulSet、DaemonSet等類型的對象，垃圾回收又是如何呢？
實際上，按理說以上的kubernetes對象并不會產生垃圾，對象一直都存在，除非用戶或者某種控制器將對象刪除。這里稱為"Garbage Collection"不太準確，實際上它想講的是在執(zhí)行刪除操作時如何控制對象之間的依賴關系。比如，Deployment對象創(chuàng)建ReplicaSet對象，ReplicaSet對象又創(chuàng)建pod對象，那么在刪除Deployment時，是否需要刪除與之相依賴的ReplicaSet與pod呢？
從對象與根對象（Owners and dependents）
某些kubernetes對象是其它對象的owner。比如ReplicaSet對象就是其所管理的pod對象的owner，本文稱這類對象為“根對象”。而被管理的pod對ReplicaSet存在dependent，pod對象通過metadata.ownerReferences字段指向其依賴的對象，本文稱這類對象為“從對象”。在kubernetes1.8中，ReplicationController, ReplicaSet, StatefulSet, DaemonSet, Deployment, Job and CronJob自動向其創(chuàng)建、收養(yǎng)的對象添加metadata.ownerReferences字段的值，當然也可以手動設置。
如何控制垃圾回收刪除從對象？
當刪除一個對象時，可以控制以何種方式刪除其從對象，自動刪除從對象稱為級聯刪除(cascading deletion)。有background與foreground兩種方式。也可以只刪除根對象不刪除從對象。
1.前臺級聯刪除
前臺級聯刪除時，根對象首先進入"deletion in progress"狀態(tài)，在"deletion in progress"狀態(tài)下，存在如下事實：
如果通過REST API訪問根對象，仍然可見。
根對象的deletionTimestamp被設置。
根對象元數據metadata.finalizers包含"foregroundDeletion"。
一旦根對象的狀態(tài)被設置成"deletion in progress"，垃圾回收器開始啟動對從對象的刪除。如果從對象的object有
“ownerReference.blockOwnerDeletion=true”屬性，那么垃圾回收器必需等到此類從對象被刪除完成以后，才可以刪除根對象。否則垃圾回收器啟動對從對象的刪除后立即刪除根對象。
“ownerReference.blockOwnerDeletion=true”會延遲根對象的刪除。在kubernetes1.7版本中增加了一個admission controller，它根據根對象訪問權限，對將ownerReference.blockOwnerDeletion設置成true的操作進行訪問控制，防止未經授權的用戶將
ownerReference.blockOwnerDeletion的值設置成true，從而延遲根對象的刪除。
如果從對象的ownerReferences由某種控制器設置，那么用戶最好不要手動修改其值。
2.后臺級聯刪除
后臺級聯刪除時，kubernetes立即刪除根對象并返回。垃圾回收器在后臺刪除其從對象。
3.不刪除從對象
只刪除根對象不刪除從對象，這種方式稱為“Orphan”，保留下來的從對象變成了“孤兒”。
在具體操作時設置刪除策略
在執(zhí)行具體的操作請求時，通過設置刪除請求中的"propagationPolicy"字段為 “Orphan”, “Foreground”, or “Background”中的一種，選擇上述三種刪除策略中的一種。
在kubernetes1.9以前，對大部分控制器的刪除，默認策略是"Orphan"（注意本段中說的默認值指REST API的默認行為，不是kubectl命令），包含ReplicationController, ReplicaSet, StatefulSet, DaemonSet, and Deployment，也就是在刪除根對象時不刪除從對象。并且當apiVersion是extensions/v1beta1, apps/v1beta1, and apps/v1beta2時，除非特別指定，默認刪除策略仍然是"Orphan"。在kubernetes1.9版本中，所有類型的對象，在app/v1版本的apiVersion中，默認從對象刪除。
后臺級聯刪除示例：
kubectl proxy --port=8080
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \
-H "Content-Type: application/json"
注意上例中kubectl充當的是proxy角色，直接調用REST API執(zhí)行刪除操作，注意其propagationPolicy的取值。
前臺級聯刪除示例：
kubectl proxy --port=8080
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
-H "Content-Type: application/json"
不刪除從對象示例：
kubectl proxy --port=8080
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
-H "Content-Type: application/json"
kubectl命令也支持級聯刪除操作。在執(zhí)行kubectl命令時指定"--cascade"選項，其值為true時刪除從對象，為false不刪除從對象，默認值為true。 示例如下：
kubectl delete replicaset my-repset --cascade=false
當--cascade為true時，kubectl采用的是前臺級聯刪除還是后臺級聯刪除，文檔中沒有講。
級聯刪除Deployment時的注意點
當級聯刪除Deployment時，其刪除請求中的propagationPolicy必需設定成Foreground。否則Deployment創(chuàng)建的ReplicaSet會被級聯刪除，但是ReplicaSet創(chuàng)建的pod不會被級聯刪除，會成為孤兒。
stattefulset的pod管理策略，有兩個可選值，默認是OrderedReady，另一個是Parallel。1.7中引入。
顧名思義，OrderedReady：增刪改的時候會按順序來。比如順序創(chuàng)建：web-0 Pod 處于 Running和Ready 狀態(tài)后 web-1 Pod 才會被啟動。
刪除事按照與 Pod 序號索引相反的順序每次刪除一個 Pod。在刪除下一個 Pod 前會等待上一個被完全關閉。
Parallel： 不按順序，總是并行的啟動或終止所有 Pod。在啟動或終止另一個 Pod 前，不必等待這些 Pod 變成 Running 和 Ready 或者完全終止狀態(tài)。
tolerationSeconds 是當 pod 需要被驅逐時，可以繼續(xù)在 node 上運行的時間。
tolerations:
- effect: NoExecute
key: node.kubernetes.io/not-ready
operator: Exists
tolerationSeconds: 300
- effect: NoExecute
key: node.kubernetes.io/unreachable
operator: Exists
tolerationSeconds: 300
status:
conditions:
- lastProbeTime: null
lastTransitionTime: "2019-06-05T11:15:25Z"
status: "True"
type: Initialized
- lastProbeTime: null
lastTransitionTime: "2019-06-05T11:15:28Z"
status: "True"
type: Ready
- lastProbeTime: null
lastTransitionTime: "2019-06-05T11:15:28Z"
status: "True"
type: ContainersReady
- lastProbeTime: null
lastTransitionTime: "2019-06-05T11:15:25Z"
status: "True"
type: PodScheduled
Deployment在生命周期中有多種狀態(tài)。在創(chuàng)建一個新的ReplicaSet的時候它可以是 progressing 狀態(tài)， complete 狀態(tài)，或者fail to progress狀態(tài)。
Progressing Deployment
Kubernetes將執(zhí)行過下列任務之一的Deployment標記為progressing狀態(tài)：
你可以使用kubectl roullout status命令監(jiān)控Deployment的進度。
Complete Deployment
Kubernetes將包括以下特性的Deployment標記為complete狀態(tài)：
你可以用kubectl rollout status命令查看Deployment是否完成。如果rollout成功完成，kubectl rollout status將返回一個0值的Exit Code。
$ kubectl rollout status deploy/nginx
Waiting for rollout to finish: 2 of 3 updated replicas are available...
deployment "nginx" successfully rolled out
$ echo $?
0
Failed Deployment
你的Deployment在嘗試部署新的ReplicaSet的時候可能卡住，用于也不會完成。這可能是因為以下幾個因素引起的：
探測這種情況的一種方式是，在你的Deployment spec中指定spec.progressDeadlineSeconds。spec.progressDeadlineSeconds表示Deployment controller等待多少秒才能確定（通過Deployment status）Deployment進程是卡住的。
下面的kubectl命令設置progressDeadlineSeconds 使controller在Deployment在進度卡住10分鐘后報告：
$ kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'
"nginx-deployment" patched
Once the deadline has been exceeded, the Deployment controller adds a with the following attributes to the Deployment’s
當超過截止時間后，Deployment controller會在Deployment的 status.conditions中增加一條DeploymentCondition，它包括如下屬性：
注意： kubernetes除了報告Reason=ProgressDeadlineExceeded狀態(tài)信息外不會對卡住的Deployment做任何操作。更高層次的協(xié)調器可以利用它并采取相應行動，例如，回滾Deployment到之前的版本。
注意： 如果你暫停了一個Deployment，在暫停的這段時間內kubernetnes不會檢查你指定的deadline。你可以在Deployment的rollout途中安全的暫停它，然后再恢復它，這不會觸發(fā)超過deadline的狀態(tài)。
指定保留多少舊的ReplicaSet。 余下的將在后臺被當作垃圾收集。默認的，所有的revision歷史就都會被保留。在未來的版本中，將會更改為2。
注意： 將該值設置為0，將導致所有的Deployment歷史記錄都會被清除，該Deploynent就無法再回退了。
新創(chuàng)建的Pod狀態(tài)為Ready持續(xù)的時間至少為.spec.minReadySeconds才認為Pod Available(Ready)。
當一個 Job 的 Pod 運行結束后，它會進入 Completed 狀態(tài)。但是，如果這個 Pod 因為某種原因一直不肯結束呢？
在 Job 的 API 對象里，有一個 spec.activeDeadlineSeconds 字段可以設置最長運行時間，比如：
spec:
backoffLimit: 5
activeDeadlineSeconds: 100
一旦運行超過了 100 s，這個 Job 的所有 Pod 都會被終止。并且，你可以在 Pod 的狀態(tài)里看到終止的原因是 reason: DeadlineExceeded。
關于k8s中kubernetes字段含義就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
免責聲明：本站發(fā)布的內容（圖片、視頻和文字）以原創(chuàng)、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
