6-Overview-Kubernetes Object Management

cucytoman發表於2019-09-23
ViewObject

kubectl命令列工具支援幾種不同的方法來建立和管理kubernetes物件。本文概述了不同的方法。閱讀Kubectl book 瞭解kubectl管理物件的詳細資訊。

Management techniques

管理技術 執行於 推薦環境 支援版本 難度
命令式 Live objects Development projects 1+ Lowest最低
Imperative object configuration命令物件配置 Individual files單個檔案 Production projects生產 1 Moderate中度
Declarative object configuration宣告性物件配置 Directories of files Production projects生產 1+ Highest最高

Imperative commands 命令式

當使用命令方式時，使用者直接操作叢集中的活動物件。使用者將操作作為引數或標誌提供給kubectl命令。

這是在叢集中啟動或執行一次性任務的最簡單方法。由於此技術直接在活動物件上操作，因此它不提供以前配置的歷史記錄。

例子

Run an instance of the nginx container by creating a Deployment object:

通過Deployment object建立執行一個nginx例項

kubectl run nginx --image nginx

用不同的語法做同樣的事情(另一種語法):

kubectl create deployment nginx --image nginx

Trade-offs 權衡

與物件配置相比的優勢:

  • 命令式易學,易記.
  • 命令只需要一個步驟就可以對叢集進行更改.

與物件配置相比的缺點:

  • 沒有review過程
  • 歷史追蹤沒有.
  • 沒有記錄
  • 命令不提供用於建立新物件的模板。

Imperative object configuration 命令物件配置

在 imperative object configuration中, 通過kubectl命令制定操作 (建立, 替換, 等等.), 操作引數必須指定一個至少檔名. 操作的檔案必須是yaml或者json格式且是一個物件完整定義

有關物件定義詳細資訊請檢視 API reference 進行參考

Warning: The imperative replace command replaces the existing spec with the newly provided one, dropping all changes to the object missing from the configuration file. This approach should not be used with resource types whose specs are updated independently of the configuration file. Services of type LoadBalancer, for example, have their externalIPs field updated independently from the configuration by the cluster.

命令替換命令用新提供的規範替換現有規範，刪除配置檔案中缺少的物件的所有更改。此方法不應用於其規範獨立於配置檔案進行更新的資源型別。例如，loadbalancer型別的服務的externalips欄位獨立於叢集的配置進行更新。

Examples

從指定的檔案建立一個物件:

kubectl create -f nginx.yaml

刪除兩個配置檔案中定義的物件:

kubectl delete -f nginx.yaml -f redis.yaml

通過覆蓋實時配置更新配置檔案中定義的物件：

kubectl replace -f nginx.yaml

Trade-offs 權衡

Advantages compared to imperative commands 與命令列相比的優勢:

  • 物件配置可以保持在git等版本控制中
  • 可以進行整合,更新推送都可對其進行稽核.
  • Object configuration 提供了建立新物件的模板

與簡單命令式對比缺點:

  • Object configuration方式需要先了解object schema.
  • Object configuration方式需要了解yaml或者json格式語法

Advantages compared to declarative object configuration 與宣告性物件配置相比的優勢: :

  • 命令式物件配置行為更簡單、更易於理解。
  • 從Kubernetes 1.5版開始，命令式物件配置更加成熟。

Disadvantages compared to declarative object configuration 與宣告性物件配置相比的缺點：

  • 命令式物件配置最適合於檔案，而不是目錄。
  • 對活動物件的更新必須反映在配置檔案中，否則它們將在下一次替換過程中丟失。

Declarative object configuration 宣告性物件配置(宣告式)

When using declarative object configuration, a user operates on object configuration files stored locally, however the user does not define the operations to be taken on the files. Create, update, and delete operations are automatically detected per-object by kubectl. This enables working on directories, where different operations might be needed for different objects.當使用宣告性物件配置時，使用者對本地儲存的物件配置檔案進行操作，但是使用者不定義要對檔案執行的操作。kubectl會自動為每個物件檢測建立、更新和刪除操作。這允許在目錄上工作，不同的物件可能需要不同的操作。

Note: Declarative object configuration retains changes made by other writers, even if the changes are not merged back to the object configuration file. This is possible by using the patch API operation to write only observed differences, instead of using the replace API operation to replace the entire object configuration.宣告性物件配置保留其他編寫器所做的更改，即使這些更改未合併回物件配置檔案。這可以通過使用“patch”api操作來只寫入觀察到的差異，而不是使用“replace”api操作來替換整個物件配置。

Examples

Process all object configuration files in the configs directory, and create or patch the live objects. You can first diff to see what changes are going to be made, and then apply--- 處理“configs”目錄中的所有物件配置檔案，並建立或修補活動物件。您可以先“diff”檢視要進行的更改，然後應用：(先對比變化再進行修改)

kubectl diff -f configs/
kubectl apply -f configs/

Recursively process directories(使用遞迴):

kubectl diff -R -f configs/
kubectl apply -R -f configs/

Trade-offs權衡

Advantages compared to imperative object configuration與命令式物件配置相比的優勢:

  • 直接對活動物件所做的更改將被保留，即使它們沒有合併回配置檔案中。

  • 宣告性物件配置更好地支援在目錄上操作和自動檢測每個物件的操作型別（建立、修補、刪除）。
    Disadvantages compared to imperative object configuration與命令式物件配置相比的缺點：

  • 宣告性物件配置在意外情況下很難除錯和理解結果。

  • 使用diff的部分更新建立複雜的合併和修補操作。

What's next

本作品採用《CC 協議》，轉載必須註明作者和本文連結

相關文章