k8s中kubernetes字段含義

這篇文章將為大家詳細講解有關k8s中kubernetes字段含義，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

initialDelaySeconds

容器啟動后等待多少秒后kubelet 才開始執行探測，默認是 0 秒，最小值是 0。 

periodSeconds

執行探測的時間間隔（單位是秒）。默認是 10 秒。最小值是 1 

timeoutSeconds

探測超時時間。如果超過這個時間，則認為探測失敗。默認值是 1 秒。最小值是 1。

successThreshold

探測器在失敗后，被視為成功的最小連續成功數。默認值是 1。 存活探測的這個值必須是 1。最小值是 1

failureThreshold

探測失敗時的重試次數。 當為存活探測時，達到閾值則重啟容器。 當為就緒探測時Pod會被打上NotReady的標簽。默認值是 3。最小值是 1。

subPath

用來對于一個Volume分別給多個容器使用時，會根據subPath給出的key創建目錄。在這個例子中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

resourceVersion

用于識別該資源內部版本號的字符串，在用于 Watch 操作時，可以避免在 GET 操作和下一次 Watch 操作之間造成的信息不一致，客戶端可以用它來判斷資源是否改變。該值應該被客戶端看作不透明，且不做任何修改就返回給服務端。客戶端不應該假定版本信息具有跨命名空間、跨不同資源類別、跨不同服務器的含義。

generation

terminationGracePeriodSeconds

K8S滾動升級的步驟:

1. K8S首先啟動新的POD
2. K8S等待新的POD進入Ready狀態
3. K8S創建Endpoint，將新的POD納入負載均衡
4. K8S移除與老POD相關的Endpoint，并且將老POD狀態設置為Terminating，此時將不會有新的請求到達老POD
5. 同時 K8S 會給老POD發送SIGTERM信號，并且等待 terminationGracePeriodSeconds 這么長的時間。(默認為30秒)
6. 超過terminationGracePeriodSeconds等待時間后， K8S 會強制結束老POD

tier

labels:
    component: kube-controller-manager
    tier: control-plane

"tier" : "frontend", "tier" : "backend", "tier" : "cache"

  tier意思是類似電影院階梯座位那種的一排，有等級的含義在里面。

可以簡單里面為架構里面的分層。一般設為前端，后端，緩存，控制平面這些值

blockOwnerDeletion

根對象是rs，從對象是pod。

如果在pod的ownerReferences字段下由設置了blockOwnerDeletion: true，那么在刪除rs的時候，會先等pod刪除完后，在刪除rs。

在以前的博文中介紹過如何配置kubelet，按策略刪除無用image、正常或者異常終止不會再啟動的container，以節省資源。kubelet回收的對象在容器層面。那么kubernetes層面的對象，比如pod、ReplicaSet、Replication Controller、Deployment、StatefulSet、DaemonSet等類型的對象，垃圾回收又是如何呢？

實際上，按理說以上的kubernetes對象并不會產生垃圾，對象一直都存在，除非用戶或者某種控制器將對象刪除。這里稱為"Garbage Collection"不太準確，實際上它想講的是在執行刪除操作時如何控制對象之間的依賴關系。比如，Deployment對象創建ReplicaSet對象，ReplicaSet對象又創建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自動向其創建、收養的對象添加metadata.ownerReferences字段的值，當然也可以手動設置。

如何控制垃圾回收刪除從對象？

當刪除一個對象時，可以控制以何種方式刪除其從對象，自動刪除從對象稱為級聯刪除(cascading deletion)。有background與foreground兩種方式。也可以只刪除根對象不刪除從對象。

1.前臺級聯刪除

前臺級聯刪除時，根對象首先進入"deletion in progress"狀態，在"deletion in progress"狀態下，存在如下事實：

如果通過REST API訪問根對象，仍然可見。
根對象的deletionTimestamp被設置。
根對象元數據metadata.finalizers包含"foregroundDeletion"。

一旦根對象的狀態被設置成"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”，保留下來的從對象變成了“孤兒”。

在具體操作時設置刪除策略
在執行具體的操作請求時，通過設置刪除請求中的"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執行刪除操作，注意其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命令也支持級聯刪除操作。在執行kubectl命令時指定"--cascade"選項，其值為true時刪除從對象，為false不刪除從對象，默認值為true。 示例如下：

kubectl delete replicaset my-repset --cascade=false
當--cascade為true時，kubectl采用的是前臺級聯刪除還是后臺級聯刪除，文檔中沒有講。

級聯刪除Deployment時的注意點 
當級聯刪除Deployment時，其刪除請求中的propagationPolicy必需設定成Foreground。否則Deployment創建的ReplicaSet會被級聯刪除，但是ReplicaSet創建的pod不會被級聯刪除，會成為孤兒。

podManagementPolicy

stattefulset的pod管理策略，有兩個可選值，默認是OrderedReady，另一個是Parallel。1.7中引入。

顧名思義，OrderedReady：增刪改的時候會按順序來。比如順序創建：web-0 Pod 處于 Running和Ready 狀態后 web-1 Pod 才會被啟動。

刪除事按照與 Pod 序號索引相反的順序每次刪除一個 Pod。在刪除下一個 Pod 前會等待上一個被完全關閉。

Parallel： 不按順序，總是并行的啟動或終止所有 Pod。在啟動或終止另一個 Pod 前，不必等待這些 Pod 變成 Running 和 Ready 或者完全終止狀態。

tolerationSeconds 

tolerationSeconds 是當 pod 需要被驅逐時，可以繼續在 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

lastTransitionTime 

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

progressDeadlineSeconds 

Deployment在生命周期中有多種狀態。在創建一個新的ReplicaSet的時候它可以是 progressing 狀態， complete 狀態，或者fail to progress狀態。

Progressing Deployment

Kubernetes將執行過下列任務之一的Deployment標記為progressing狀態：

• Deployment正在創建新的ReplicaSet過程中。
• Deployment正在擴容一個已有的ReplicaSet。
• Deployment正在縮容一個已有的ReplicaSet。
• 有新的可用的pod出現。

你可以使用kubectl roullout status命令監控Deployment的進度。

Complete Deployment

Kubernetes將包括以下特性的Deployment標記為complete狀態：

• Deployment最小可用。最小可用意味著Deployment的可用replica個數等于或者超過Deployment策略中的期望個數。
• 所有與該Deployment相關的replica都被更新到了你指定版本，也就說更新完成。
• 該Deployment中沒有舊的Pod存在。

你可以用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的時候可能卡住，用于也不會完成。這可能是因為以下幾個因素引起的：

• 無效的引用
• 不可讀的probe failure
• 鏡像拉取錯誤
• 權限不夠
• 范圍限制
• 程序運行時配置錯誤

探測這種情況的一種方式是，在你的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，它包括如下屬性：

• Type=Progressing
• Status=False
• Reason=ProgressDeadlineExceeded

注意： kubernetes除了報告Reason=ProgressDeadlineExceeded狀態信息外不會對卡住的Deployment做任何操作。更高層次的協調器可以利用它并采取相應行動，例如，回滾Deployment到之前的版本。

注意： 如果你暫停了一個Deployment，在暫停的這段時間內kubernetnes不會檢查你指定的deadline。你可以在Deployment的rollout途中安全的暫停它，然后再恢復它，這不會觸發超過deadline的狀態。

revisionHistoryLimit

指定保留多少舊的ReplicaSet。 余下的將在后臺被當作垃圾收集。默認的，所有的revision歷史就都會被保留。在未來的版本中，將會更改為2。

注意： 將該值設置為0，將導致所有的Deployment歷史記錄都會被清除，該Deploynent就無法再回退了。

minReadySeconds

新創建的Pod狀態為Ready持續的時間至少為.spec.minReadySeconds才認為Pod Available(Ready)。

activeDeadlineSeconds

當一個 Job 的 Pod 運行結束后，它會進入 Completed 狀態。但是，如果這個 Pod 因為某種原因一直不肯結束呢？

在 Job 的 API 對象里，有一個 spec.activeDeadlineSeconds 字段可以設置最長運行時間，比如：

spec:     
      backoffLimit: 5    
      activeDeadlineSeconds: 100

一旦運行超過了 100 s，這個 Job 的所有 Pod 都會被終止。并且，你可以在 Pod 的狀態里看到終止的原因是 reason: DeadlineExceeded。

dnsPolicy

hostNetwork

priority

securityContext 

關于k8s中kubernetes字段含義就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。