kubenetes的抽象概念，如Pod、Service、Volume、Namespace、ReplicaSet、Deployment、StatefulSet、DaemonSet、Job等統稱物件，kubectl命令提供三種方式對這些物件進行操作、管理，三種方式分別為：Imperative commands(祈使命令)、Imperative object configuration(祈使物件配置)、Declarative object configuration(宣告物件配置)，後兩種方式統稱物件配置方式。本文分別介紹三種管理物件方式，並比較優缺點。在正式介紹之前，先說明一個重要的概念：live objects（實時物件）。

實時物件的表現形式由兩個部分組成，一部分由初始配置資訊決定，稱為規格，表示使用者的期望值，例如使用者定義了一個Deployment，並且將副本的個數設定成3，注意3是一個期望值。非常重要的一點是某些型別的物件，其規格並非完全由配置決定，比如負載均衡型別的服務。另一部分稱之為狀態，表示當前的實時狀態，是動態變化的，比如當前系統中副本的數量是2。而kubenetes的工作就是調整系統當前的狀態，以使狀態與規格相符。所以live objects（實時物件）由兩部分組成，靜態的規格及動態的狀態。

警告：應該只使用其中的一種方式管理相同的物件，如果混合使用後果不可預知。

1.Imperative commands(祈使命令)

使用者直接通過設定命令列中的引數、標誌，指示操作的具體物件以及操作，操作本身直接作用於叢集中的實時物件(live objects)。這是最簡單的在叢集中啟動、執行一次性任務的方法，原因是它直接作用於實時物件本身，不涉及物件的歷史配置。

與物件配置比較的優點：

1. 命令本身簡單直觀、易學、易記、易用
2. 整個操作只需要一步就可以完成

與物件配置比較的缺點：

1. 沒有與變更稽核流程整合
2. 沒有將變更與審計追蹤關聯
3. 只針對實時物件而沒有提供原始配置
4. 不能為新建立物件提供模板

總體上看，這種方式簡單但是功能不強，適合於開發測試場景而非生產環境。缺點產生的根本原因是在更新的時候沒有涉及歷史配置，沒有將整個變更過程記錄下來，而是直接作用於實時物件，不與歷史配置對比就無法計算出“變更”，自然也就不能稽核、審記、追蹤“變更”，這種方式的優點也是因為這一原因而產生。

通過祈使命令管理物件的方法

如何建立物件？

 kubenctl祈使命令管理物件的方式，又細分成兩種，一種稱之為“動詞驅動”，可以用來建立大多數基礎的物件型別，特點是簡單直觀，主要針對的是對kubenetes物件型別不熟悉的使用者。

• run：建立Deployment型別物件，實現在一個或者多個Pod中執行容器。
• expose：建立Service物件，實現Pod之間流量的負載均衡。
• autoscale：建立彈性伸縮物件。

另一種稱之為“物件型別驅動”，能夠建立的物件型別更多，需要使用者對kubenetes中的物件型別比較熟悉。

基本語法：create <objecttype> [<subtype>] <instancename>

在建立某些型別的物件時，可以在命令中指定其支援的子型別。如Service物件，包含ClusterIP、LoadBalancer、NodePort等數個子型別，以下是建立子型別為NodePort的Service的示例：

kubectl create service nodeport <myservicename>

在上例中，create service nodeport命令被稱為create service的子命令。可以通過-h選項獲得子命令支援的引數及標誌的幫忙資訊，如：

kubectl create service nodeport -h

如何更新物件？

以下是由易到難更新物件的方法

• scale：建立水平擴充套件控制器，通過更新物件控制器中副本的資料來增加或者減少Pod的數量。
• annotate：修改物件註解。
• label：修改物件標籤，以上三種方法適用於對kubenetes物件不熟悉的用法。
• set：修改任意型別物件的任意屬性，需要對物件的構成比較熟悉。
• edit：在直接在編輯器中開啟實時物件的原始配置並編輯。
• patch：通過patch string修改實時物件的某個欄位，詳細參考https://git.k8s.io/community/contributors/devel/api-conventions.md#patch-operations。

如何刪除物件？

基本語法：delete <type>/<name>

示例：

kubectl delete deployment/nginx

以上命令，刪除型別為Deployment名為nginx的物件。

如何瀏覽物件？

以下命令列印物件資訊。

• get：列印物件的基本資訊，可以通過-h選項獲取幫助。
• describe：列印物件詳細資訊。
• log：列印Pod中容器的標準與錯誤輸出。

通過set命令在建立之前修改物件

這是一種高階用法。有些型別的物件比較複雜，物件的某些欄位在執行create命令時無法直接指定。可以通過管道將create命令與set命令連線起來，實現對這種型別的物件欄位的修改，示例如下：

kubectl create service clusterip my-svc --clusterip="None" -o yaml --dry-run | kubectl set selector --local -f - 'environment=qa' -o yaml | kubectl create -f -

上述命令用兩個管道將三個命令連線起來，具體執行過程如下：

1. kubectl create service clusterip my-svc --clusterip="None" -o yaml --dry-run，這個命令先建立物件的配置，但是並沒有將配置傳遞給Kubernetes API server，而是以YAML格式輸出到標準輸出。
   
2. kubectl set selector --local -f - 'environment=qa' -o yaml，這個命令通過管道接收步驟1的輸出，並對內容進行修改，同樣沒有將配置傳遞給Kubernetes API server，而是以YAML格式輸出到標準輸出。
   
3. kubectl create -f -，接收第2步的輸出傳遞給Kubernetes API server，啟動真正的建立工作。

通過--edit選項在建立之前修改物件

使用kubectl create --edit命令在物件建立之前進行任意修改，以下是例子：

ubectl create service clusterip my-svc --clusterip="None" -o yaml --dry-run > /tmp/srv.yaml

kubectl create --edit -f /tmp/srv.yaml

在以上命令中，kubectl create service命令建立service的配置檔案並儲存在/tmp/srv.yaml檔案中。kubectl create --edit命令先編輯建立好的配置檔案，再啟動建立流程。

２.Imperative object configuration(祈使物件配置)

祈使物件配置方式，kubectl命令指定操作如create、replace等，其它選項及配置檔案，配置檔案為完整描述物件定義的JOSN或者MAML格式的檔案。警告：這種方式中，replace命令用新提供的規格替換掉物件當前的規格，對於不是由配置檔案決定的物件的規格則全部丟失，因此這種修改方式，不適用於某些規格不依賴於配置而獨立變化的物件型別。例如，負載均衡型別的服務，其externalIPs屬性由整個叢集的配置決定而非完全由當前服務的規格決定。

與祈使命令比較的優點：

1. 物件的完整配置能以檔案的形式儲存在版本控制系統中如Git。
2. 物件配置能夠與其它的處理過程如變數稽核、審訊追蹤整合。
3. 配置檔案能提供建立物件的模板。

與祈使命令比較的缺點：

1. 複雜
2. 多了一個步驟，管理配置檔案。

與宣告物件配置比較的優點：

1. 祈使物件配置的行為更簡單且易於理解。
2. 從版本1.5開始，祈使物件配置更加成熟。

與宣告物件配置比較的缺點：

1. 祈使物件配置善於處理配置檔案，不能處理目錄。
2. 實時物件中獨立於配置檔案變化的規格必需手動反映在新的配置檔案裡，否則在更新的過程中這部分規格會丟失。

總體而言，祈使物件配置方法將物件的配置資訊轉移到配置檔案中，通過與版本控制器的整合從而支援變更稽核、審計等，最大的問題是在變更的過程中，丟失獨立與配置檔案的規格，對於某些特定型別的物件不適用。

通過祈使物件配置管理物件的方法

如何建立物件？

基本語法：kubectl create -f <filename|url>

如何更新物件？

基本語法：kubectl replace -f <filename|url>

警告：這種方法對於某些規格獨立於配置檔案型別的物件不適用。

如何刪除物件？

基本語法：kubectl delete -f <filename|url>

如何瀏覽物件？

基本語法：kubectl get -f <filename|url> -o yaml

限制

這種方式的不足，在前文中的警告中已經提及，現集中說明。

當配置檔案中包含物件的完整定義時（注意完整一詞），create、replace、delete命令能夠很好的工作。但是，當實時物件中獨立於配置的規格沒有被合併到配置檔案中，也就是說配置檔案中的定義是不“完整”的，那麼在更新被執行時就會丟失掉這部分資訊。例如：

1. 從配置建立物件。
   
2. 其它的源更新了物件的某個欄位。
   
3. 利用配置檔案再次更新物件，如果部步驟２中的變更沒有被手動反映在配置檔案中，則資訊丟失。
   

如果想要支援對同一個物件的多源變更，可以使用下文化介紹的kubectl apply命令管理物件。

從URL建立、編輯物件，但是不儲存修改

假如可以通過URL讀取配置檔案。可以通過create --edit命令先獲取配置檔案，在物件建立之前進行修改，然後再建立物件。此時的修改是臨時的。

基本語法：kubectl create -f <url> --edit

從祈使命令遷移到祈使物件配置

手動步驟如下：

1. 將實時物件的配置匯入到本地檔案：kubectl get <kind>/<name> -o yaml --export > <kind>_<name>.yaml。
   
2. 匯出的配置檔案包含規格與狀態兩部分，手動將狀態部分欄位刪除。
3. 使用replace命令更新：kubectl replace -f <kind>_<name>.yaml

定義控制類物件的選擇器與Pod模板標籤

警告：強烈不推薦更新控制類物件的選擇器，推薦的方法是為Pod模板選擇器定義單一、恆定、專用此外再無其它用處的標籤。

標籤示例：

selector:
  matchLabels:
      controller-selector: "extensions/v1beta1/deployment/nginx"
template:
  metadata:
    labels:
      controller-selector: "extensions/v1beta1/deployment/nginx"

３.Declarative object configuration(宣告物件配置)

當使用宣告物件配置方法時，使用者通過操作儲存在本地的物件配置檔案實現，並且使用者無需定義對物件執行何種操作。對於每個物件的create、 update、delete等操作，由kubectl命令自動決定，這種機制適用如下場景，如果一個目錄下有多個物件配置檔案，需要實現對不同物件的不同操作。宣告物件配置方法將會保持其它源對物件的修改，即使這種修改沒有被合併到本地的配置檔案中。這種機制，確保系統能夠計算出當前物件的配置與實時物件的差值，然後通過補丁型別的API只區域性更新差值而不是整體替換。

與祈使物件配置比較的優點：

1. 其它源對實時物件的直接修改將會被系統保持，即使修改沒有被更新進配置檔案。直接修改的意思是不通過配置檔案而是直接修改實現物件。
2. 宣告物件配置支援目錄、對每個對旬自動決定操作型別。

與祈使物件配置比較的缺點：

1. 當發生異常時，其結果難於理解、除錯。
2. 區域性更新時涉及複雜的差值計算及補丁操作。

如何建立物件？

除了已經存在的物件，建立目錄下的所有其它對物件，基本語法：

kubectl apply -f <directory>/

注意這個操作的附加結果。對於每個新建立的物件，自動添加註解：kubectl.kubernetes.io/last-applied-configuration: '{...}'。註解的內部就是本次操作時配置檔案的內容，也就是說物件本身自包含建立歷史配置。-R選項支援多層級目錄遍歷。

以下是一個示例配置檔案：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  minReadySeconds: 5
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

路徑：https://github.com/kubernetes/website/blob/master/content/en/docs/concepts/overview/object-management-kubectl/simple_deployment.yaml

使用kubectl apply命令建立物件：

kubectl apply -f https://k8s.io/docs/concepts/overview/object-management-kubectl/simple_deployment.yaml

使用kubectl get列印物件的實時配置：

kubectl get -f https://k8s.io/docs/concepts/overview/object-management-kubectl/simple_deployment.yaml -o yaml

結果如下：

kind: Deployment
metadata:
  annotations:
    # ...
    # This is the json representation of simple_deployment.yaml
    # It was written by kubectl apply when the object was created
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"apps/v1","kind":"Deployment",
      "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
      "spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
      "spec":{"containers":[{"image":"nginx:1.7.9","name":"nginx",
      "ports":[{"containerPort":80}]}]}}}}
  # ...
spec:
  # ...
  minReadySeconds: 5
  selector:
    matchLabels:
      # ...
      app: nginx
  template:
    metadata:
      # ...
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.7.9
        # ...
        name: nginx
        ports:
        - containerPort: 80
        # ...
      # ...
    # ...
  # ...

紅色字型部分通過註釋的方式記錄了建立物件的原始配置。

如何更新物件？

同樣使用kubectl apply命令。如果物件已經存在則執行更新。執行步驟如下：

1. 將出現在配置檔案中的欄位更新到實時物件中。
2. 從實時物件的配置中刪除在配置檔案中刪除的欄位，明顯，這個操作是通過將當前的配置檔案與儲存在物件註解中的歷史配置對比，計算出需要刪除的欄位。

具體語法：

kubectl apply -f <directory>/

使用kubectl scale命令直接更新上例中建立物件的副本資料，注意是使用kubectl scale命令直接更新，而不是kubectl apply宣告物件配置。

kubectl scale deployment/nginx-deployment --replicas=2

通過kubectl get指印出物件的實時配置：

kubectl get -f https://k8s.io/docs/concepts/overview/object-management-kubectl/simple_deployment.yaml -o yaml

結果：

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    # ...
    # note that the annotation does not contain replicas
    # because it was not updated through apply
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"apps/v1","kind":"Deployment",
      "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
      "spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
      "spec":{"containers":[{"image":"nginx:1.7.9","name":"nginx",
      "ports":[{"containerPort":80}]}]}}}}
  # ...
spec:
  replicas: 2 # written by scale
  # ...
  minReadySeconds: 5
  selector:
    matchLabels:
      # ...
      app: nginx
  template:
    metadata:
      # ...
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.7.9
        # ...
        name: nginx
        ports:
        - containerPort: 80
      # ...

從結果可以看出，副本數量已被更新為２，但是在紅色字型的註釋中，並沒有記錄相關資訊，原因就是使用的是命令kubectl scale直接更的實時物件。

更新配置檔案simple_deployment.yaml，將映象從nginx:1.7.9更新到nginx:1.11.9，並且刪除minReadySeconds欄位。

更新後的檔案內容如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.11.9 # update the image
        ports:
        - containerPort: 80

應用更新：

kubectl apply -f https://k8s.io/docs/concepts/overview/object-management-kubectl/update_deployment.yaml

再次指印實時配置：

kubectl get -f https://k8s.io/docs/concepts/overview/object-management-kubectl/simple_deployment.yaml -o yaml

結果如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    # ...
    # The annotation contains the updated image to nginx 1.11.9,
    # but does not contain the updated replicas to 2
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"apps/v1","kind":"Deployment",
      "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
      "spec":{"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
      "spec":{"containers":[{"image":"nginx:1.11.9","name":"nginx",
      "ports":[{"containerPort":80}]}]}}}}
    # ...
spec:
  replicas: 2 # Set by `kubectl scale`.  Ignored by `kubectl apply`.
  # minReadySeconds cleared by `kubectl apply`
  # ...
  selector:
    matchLabels:
      # ...
      app: nginx
  template:
    metadata:
      # ...
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.11.9 # Set by `kubectl apply`
        # ...
        name: nginx
        ports:
        - containerPort: 80
        # ...
      # ...
    # ...
  # ...

詳細說明如下：

• 副本欄位的值仍然是2，說明kube apply命令操持了因為kubectl scale產生的變更。
• 映象從nginx:1.7.9更新到nginx:1.11.9。
• 紅色字型註解中的映象值也更新成了nginx:1.11.9。
• minReadySeconds欄位被清除
  
• 註解中的minReadySeconds欄位同時被清除。

警告：不支援混合使用kubectl apply與祈使物件配置建立、更新物件，因為後者不包含前者用於計算變數的kubectl.kubernetes.io/last-applied-configuration欄位。

如何刪除物件？

通過kubectl apply管理的物件，有兩種刪除方法。

推薦方法：kubectl delete -f <filename>

指定刪除物件的檔案，通過祈使命令刪除。這種方式的好處是簡單、不容易誤刪除。

另外一種方法：kubectl apply -f <directory/> --prune -l your=label

警告：kubectl apply --prune處於alpha版本，可能會有後向相容問題。

刪除實現的物件要滿足如下條件：

1. 屬於使用者設定的標籤過濾後的集合。
2. 其它配置檔案在當前目錄下不存在。
3. 其具備last-applied-configuration註解。

警告：總之後一種方式複雜，很容易發生誤刪，系統支援不成熟，所以不應該使用。

如何瀏覽物件？

kubectl get -f <filename|url> -o yaml

apply如何計算差值與合併變更？

提示：“補丁”是更新特定範圍內的欄位而不是整個物件，實現讀入整個物件之前對特定範圍欄位的更新。

kubectl apply通過傳送“補丁”API給API服務實現更新，注意傳送的“補丁”而不是完整的配置。“補丁”的計算涉及到呼叫命令時指定的配置檔案、實時物件的配置、以及儲存在實時物件中的last-applied-configuration註解。

合併補丁計算

kubectl apply命令通過比較配置檔案與last-applied-configuration註解的內容，計算刪除、增加、重新設定的欄位：

1. 存在於last-applied-configuration註解中，而在配置檔案中不存在則需要刪除。
2. 存在於配置檔案中，在last-applied-configuration中不存在，就是新增加的欄位。
3. 同時存在但是值不相同，則是重新設定的欄位。

示例如下：

以下是Deployment物件的配置檔案：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.11.9 # update the image
        ports:
        - containerPort: 80

以下是實時物件的配置檔案：

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    # ...
    # note that the annotation does not contain replicas
    # because it was not updated through apply
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"apps/v1","kind":"Deployment",
      "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
      "spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
      "spec":{"containers":[{"image":"nginx:1.7.9","name":"nginx",
      "ports":[{"containerPort":80}]}]}}}}
  # ...
spec:
  replicas: 2 # written by scale
  # ...
  minReadySeconds: 5
  selector:
    matchLabels:
      # ...
      app: nginx
  template:
    metadata:
      # ...
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.7.9
        # ...
        name: nginx
        ports:
        - containerPort: 80
      # ...

以下是kubectl apply實現的合併計算：

• 計算刪除欄位。首先比較last-applied-configuration註解與配置檔案。在本例中，minReadySeconds欄位只出現在last-applied-configuration註解中，則執行的動作是將此欄位從實時物件的配置中刪除。
• 計算重新設定欄位。在本例中，image欄位的值在配置檔案與last-applied-configuration註釋之間不匹配，執行的動作是將配置檔案中的值設定到實時物件的配置中。
• 用當前配置檔案的內容更新last-applied-configuration註解。
• 將前三步的計算結果合併成一個“補丁”請求傳送給API服務。

合併後的結果如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    # ...
    # The annotation contains the updated image to nginx 1.11.9,
    # but does not contain the updated replicas to 2
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"apps/v1","kind":"Deployment",
      "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
      "spec":{"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
      "spec":{"containers":[{"image":"nginx:1.11.9","name":"nginx",
      "ports":[{"containerPort":80}]}]}}}}
    # ...
spec:
  selector:
    matchLabels:
      # ...
      app: nginx
  replicas: 2 # Set by `kubectl scale`.  Ignored by `kubectl apply`.
  # minReadySeconds cleared by `kubectl apply`
  # ...
  template:
    metadata:
      # ...
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.11.9 # Set by `kubectl apply`
        # ...
        name: nginx
        ports:
        - containerPort: 80
        # ...
      # ...
    # ...
  # ...

不同型別的欄位如何合併

當配置檔案與實時物件中的某個相同欄位值型別不一樣時，如何處理？存在如下幾種型別的欄位

• 原始型別：如字串、整數、布林值等，直接替換。
• 欄位值型別為map或者另一個物件時，如label、annotation、metadate、spec等，合併元素及子域。
• 列表型別：多重複合。

kubectl apply更新map或者list時，不是將整個欄位完全替換，而是更新個別的子元素。例如：當更新Deployment的spec時，spec欄位並不會被整體替換，而是比較spec中的元素並更新。

欄位預設值

某些型別的欄位值，在建立物件如果沒有指定，則API服務會設定成預設值，比如Deployment物件中的“strategy”。示例：

建立物件時的配置：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  minReadySeconds: 5
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

用kubectl apply建立物件後實時物件的配置：

apiVersion:apps/v1kind:Deployment# ...spec:selector:matchLabels:app:nginxminReadySeconds:5replicas:1# defaulted by apiserverstrategy:rollingUpdate:# defaulted by apiserver - derived from strategy.typemaxSurge:1maxUnavailable:1type:RollingUpdate# defaulted apiservertemplate:metadata:creationTimestamp:nulllabels:app:nginxspec:containers:-image:nginx:1.7.9imagePullPolicy:IfNotPresent# defaulted by apiservername:nginxports:-containerPort:80protocol:TCP# defaulted by apiserverresources:{}# defaulted by apiserverterminationMessagePath:/dev/termination-log# defaulted by apiserverdnsPolicy:ClusterFirst# defaulted by apiserverrestartPolicy:Always# defaulted by apiserversecurityContext:{}# defaulted by apiserverterminationGracePeriodSeconds:30# defaulted by apiserver# ...

可能看到，API服務指定了很多預設值。這些預設值除非在“補丁”請求中明確指定，否則它們的值一直保持不變，也就是如果所依賴的欄位發生了更新，但是預設的欄位並不會自動更新，除非明確指定，因此對於那些依賴於其它欄位的預設值存在著行為的不確定性。基於這個原因，對於API服務設定預設值的欄位，最好還是在配置檔案中明確說明，即使指定的值與預設值相同，以此減少系統預設行為影響。

推薦的需要設定預設值的欄位：

• Selectors and PodTemplate labels on workloads, such as Deployment, StatefulSet, Job, DaemonSet, ReplicaSet, and ReplicationController
  
• Deployment rollout strategy
  

如何清空服務預設設定或者其它源更新的欄位？

從版本1.5開始，合併操作不能清除未出現在配置檔案中的欄位。有兩個選擇：

選擇一：通過kubectl edit直接修改實現物件（存在風險不推薦）

選擇二：通過配置檔案刪除，步驟如下：

1. 在配置檔案中新增實時物件中想要刪除的欄位。
2. apply此配置檔案，想要刪除的欄位會寫入實時物件的註釋中。
3. 從配置檔案中刪除此欄位。
4. 再次apply配置檔案，則此欄位將從實時物件的註解及配置中刪除。

如何在配置檔案與祈使命令更新者之間變更欄位的所有權？

應該使用的變更物件欄位的方法有以下兩種：

• 使用kubectl apply
• 不通過配置檔案，直接修改實時物件欄位，如kubectl scale。

將欄位歸屬權從祈使命令轉移到配置檔案的方法：

將欄位寫入配置檔案，以後不再通過祈使命令的方式更新，只通過kubectl apply

將欄位歸屬權從配置檔案轉移到祈使命令的方法：

• 將欄位從配置檔案中刪除
• 將欄位從實時物件的last-applied-configuration註解中刪除。

參考文件：https://kubernetes.io/docs/concepts/overview/object-management-kubectl/overview/

最重要的是宣告物件配置這種管理方式。