k8s中kubernetes字段含義

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

initialDelaySeconds

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

periodSeconds

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

timeoutSeconds

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

successThreshold

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

failureThreshold

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

subPath

用來對于一個Volume分別給多個容器使用時，會根據(jù)subPath給出的key創(chuàng)建目錄。在這個例子中site-data這個Volume在分別個mysql和php容器使用時，html的內(nèi)容映射在site-data卷的html子目錄，而數(shù)據(jù)庫則保存在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

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

generation

terminationGracePeriodSeconds

K8S滾動升級的步驟:

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

tier

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

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

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

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

blockOwnerDeletion

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

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

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

實際上，按理說以上的kubernetes對象并不會產(chǎn)生垃圾，對象一直都存在，除非用戶或者某種控制器將對象刪除。這里稱為"Garbage Collection"不太準確，實際上它想講的是在執(zhí)行刪除操作時如何控制對象之間的依賴關(guān)系。比如，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字段的值，當然也可以手動設(shè)置。

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

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

1.前臺級聯(lián)刪除

前臺級聯(lián)刪除時，根對象首先進入"deletion in progress"狀態(tài)，在"deletion in progress"狀態(tài)下，存在如下事實：

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

一旦根對象的狀態(tài)被設(shè)置成"deletion in progress"，垃圾回收器開始啟動對從對象的刪除。如果從對象的object有
“ownerReference.blockOwnerDeletion=true”屬性，那么垃圾回收器必需等到此類從對象被刪除完成以后，才可以刪除根對象。否則垃圾回收器啟動對從對象的刪除后立即刪除根對象。

“ownerReference.blockOwnerDeletion=true”會延遲根對象的刪除。在kubernetes1.7版本中增加了一個admission controller，它根據(jù)根對象訪問權(quán)限，對將ownerReference.blockOwnerDeletion設(shè)置成true的操作進行訪問控制，防止未經(jīng)授權(quán)的用戶將
ownerReference.blockOwnerDeletion的值設(shè)置成true，從而延遲根對象的刪除。

如果從對象的ownerReferences由某種控制器設(shè)置，那么用戶最好不要手動修改其值。

2.后臺級聯(lián)刪除

后臺級聯(lián)刪除時，kubernetes立即刪除根對象并返回。垃圾回收器在后臺刪除其從對象。

3.不刪除從對象

只刪除根對象不刪除從對象，這種方式稱為“Orphan”，保留下來的從對象變成了“孤兒”。

在具體操作時設(shè)置刪除策略
在執(zhí)行具體的操作請求時，通過設(shè)置刪除請求中的"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中，默認從對象刪除。

后臺級聯(lián)刪除示例：

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充當?shù)氖莗roxy角色，直接調(diào)用REST API執(zhí)行刪除操作，注意其propagationPolicy的取值。

前臺級聯(lián)刪除示例：

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命令也支持級聯(lián)刪除操作。在執(zhí)行kubectl命令時指定"--cascade"選項，其值為true時刪除從對象，為false不刪除從對象，默認值為true。 示例如下：

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

級聯(lián)刪除Deployment時的注意點 
當級聯(lián)刪除Deployment時，其刪除請求中的propagationPolicy必需設(shè)定成Foreground。否則Deployment創(chuàng)建的ReplicaSet會被級聯(lián)刪除，但是ReplicaSet創(chuàng)建的pod不會被級聯(lián)刪除，會成為孤兒。

podManagementPolicy

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

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

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

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

tolerationSeconds 

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

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在生命周期中有多種狀態(tài)。在創(chuàng)建一個新的ReplicaSet的時候它可以是 progressing 狀態(tài)， complete 狀態(tài)，或者fail to progress狀態(tài)。

Progressing Deployment

Kubernetes將執(zhí)行過下列任務(wù)之一的Deployment標記為progressing狀態(tài)：

• Deployment正在創(chuàng)建新的ReplicaSet過程中。
• Deployment正在擴容一個已有的ReplicaSet。
• Deployment正在縮容一個已有的ReplicaSet。
• 有新的可用的pod出現(xiàn)。

你可以使用kubectl roullout status命令監(jiān)控Deployment的進度。

Complete Deployment

Kubernetes將包括以下特性的Deployment標記為complete狀態(tài)：

• Deployment最小可用。最小可用意味著Deployment的可用replica個數(shù)等于或者超過Deployment策略中的期望個數(shù)。
• 所有與該Deployment相關(guān)的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
• 鏡像拉取錯誤
• 權(quán)限不夠
• 范圍限制
• 程序運行時配置錯誤

探測這種情況的一種方式是，在你的Deployment spec中指定spec.progressDeadlineSeconds。spec.progressDeadlineSeconds表示Deployment controller等待多少秒才能確定（通過Deployment status）Deployment進程是卡住的。

下面的kubectl命令設(shè)置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狀態(tài)信息外不會對卡住的Deployment做任何操作。更高層次的協(xié)調(diào)器可以利用它并采取相應(yīng)行動，例如，回滾Deployment到之前的版本。

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

revisionHistoryLimit

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

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

minReadySeconds

新創(chuàng)建的Pod狀態(tài)為Ready持續(xù)的時間至少為.spec.minReadySeconds才認為Pod Available(Ready)。

activeDeadlineSeconds

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

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

spec:     
      backoffLimit: 5    
      activeDeadlineSeconds: 100

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

dnsPolicy

hostNetwork

priority

securityContext 

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