This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

檢視和更新自動管理的套件組態

本主題介紹了如何檢視和自訂從 tanzu-core 存放庫安裝的自動管理套件的組態以及對其進行疑難排解。此外，還列出了您可以自訂的 Antrea、Pinniped、Calico、vSphere CPI 和 vSphere CSI 組態設定。

檢視套件組態

自動管理的套件位於 tanzu-core 存放庫中，其中包含支援基本叢集功能的元件，例如 Antrea 或 Calico 容器網路介面以及 Pinniped 身分驗證元件。在某些情況下，內部 Tanzu Kubernetes Grid 和 Kubernetes 資源將這些元件稱為 addons。

如要檢視自動管理的套件及其包含的附加元件的組態，您可以：

  • 對管理叢集執行 kubectl get secret CLUSTER-NAME-PACKAGE-NAME-addon -n CLUSTER-NAMESPACE 命令，擷取已安裝附加元件的 Kubernetes 密鑰。其中：

    • CLUSTER-NAME 是目標叢集的名稱。如果要擷取安裝在工作負載叢集中的附加元件的密鑰，CLUSTER-NAME 是工作負載叢集的名稱。
    • PACKAGE-NAME 是套件的名稱。
    • CLUSTER-NAMESPACE 是目標叢集的命名空間。

  • 從 projects.registry.vmware.com/tkg/packages/core 下載套件組態檔案。

例如，如要檢視 Antrea 的組態，請執行以下操作：

  • 透過對管理叢集執行以下命令來擷取 Antrea 密鑰：

    kubectl get secret CLUSTER-NAME-antrea-addon -n CLUSTER-NAMESPACE

  • 下載 Antrea 套件組態檔：

    1. 在用於建立叢集的 Tanzu Kubernetes 版本 (Tkr) 中找到 antrea 的版本標籤。您可以通過對管理叢集執行 kubectl get tkr 命令來擷取 TKr。

      1. 執行 kubectl get clusters CLUSTER-NAME -n CLUSTER-NAMESPACE --show-labels。

      2. 在輸出中，找到 tanzuKubernetesRelease 的值。例如，tanzuKubernetesRelease=v1.23.10---vmware.1-tkg.1。

      3. 執行 kubectl get tkr TKR-VERSION，其中 TKR-VERSION 是上面擷取的值。例如：

        kubectl get tkr v1.23.10---vmware.1-tkg.1 -o yaml

      4. 在輸出中，在 packages/core/antrea 下找到版本標籤。

        或者，也可以通過在 ~/.config/tanzu/tkg/bom/YOUR-TKR-BOM-FILE 中查看 TKr 找到版本標籤。

    2. 下載套件組態檔。例如：

      imgpkg pull -b projects.registry.vmware.com/tkg/packages/core/antrea:v1.2.3_vmware.4-tkg.1-advanced -o antrea

    3. 導覽到 antrea 並查看檔案。

如要瞭解有關 Antrea 容器網路連接功能的更多資訊，請參閱 VMware Container Networking with Antrea 1.4.0 版本資訊。如要瞭解有關將 Antrea 容器叢集與 VMware NSX 整合的更多資訊，請參閱 Antrea 容器叢集的整合。

自訂套件組態

由於自動管理的套件由 Tanzu Kubernetes Grid 管理，因此通常不需要自訂工作負載叢集中自動管理的套件的組態。

但如果需要，可以自訂這些設定。如何自訂自動管理的套件設定取決於叢集的類型。

對於基於計劃或 TKC 的叢集，可以修改和修補元件密鑰的 values.yaml 部分，以單獨自訂現有叢集，如自訂 values.yaml 設定中所述。

在某些情況下，對於基於計劃或 TKC 的叢集，可以將覆疊加入管理叢集中的套件組態密鑰，以便在建立叢集之前對其進行自訂，如使用覆疊自訂中所述。

對於基於類別的叢集，可以在建立叢集之前對其自訂，方法是按照建立以類別為基礎的叢集中所述的兩步驟程序步驟 1 中建立叢集資訊清單，然後將自訂物件定義加入資訊清單中，再於步驟 2 中建立叢集。有關範例，請參閱自訂基於類別的資訊清單。

自動管理的套件 values.yaml 設定

您可以在自動管理的套件中自訂以下組態設定。這些值在套件元件密鑰的 values.yaml 部分中設定：

套件 設定 說明
Antrea antrea.config.defaultMTU 預設值為 null。
Antrea antrea.config.tlsCipherSuites 預設下，包括啟用了 FIPS 的加密套件。要切換到其他加密套件，請更新 tlsCipherSuites 欄位之下的值。
Calico calico.config.vethMTU 預設為 “0”，讓 Calico 自動偵測其傳輸單元最大值 (MTU) 設定。設定此參數以字串形式指定最大封包大小 (以位元組為單位)。
Calico calico.config.skipCNIBinaries 預設值為 true，這會限制 Calico 在叢集建立期間覆蓋現有 CNI 外掛程式的設定。升級叢集時，為避免覆寫，請設定 calico.config.skipCNIBinaries=true。
Pinniped pinniped.supervisor_svc_external_dns 與 Pinniped 主管關聯的 FQDN，用於 OIDC IDP 用戶端中的回撥 URL。視 Pinniped 的服務類型而定，可能還需要包含連接埠號：
  • 對於 LoadBalancer，在具有 NSX ALB、AWS 或 Azure 的 vSphere 上，請勿包含連接埠號：https://hr.tkg.example.com。
  • 對於 NodePort，如在沒有 NSX ALB 的 vSphere 上一樣，請包含連接埠號：https://hr.tkg.example.com:31234。
Pinniped pinniped.upstream_oidc_client_id OIDC 提供者的用戶端 ID。
Pinniped pinniped.upstream_oidc_client_secret OIDC 提供者的用戶端密碼。
Pinniped pinniped.upstream_oidc_issuer_url OIDC 提供者的 URL。
Pinniped pinniped.upstream_oidc_tls_ca_data 用於驗證與 OIDC 提供者的 TLS 連線的 base64 編碼 CA 服務包資料。
Pinniped pinniped.upstream_oidc_additional_scopes Token 回應中所要求的其他範圍清單。
Pinniped pinniped.upstream_oidc_claims OIDC 聲明對應。
Pinniped dex.config.ldap.host* LDAP 伺服器的 IP 或 DNS 位址。如果要將預設連接埠 636 更改為其他連接埠，請指定 “host:port”。
Pinniped dex.config.ldap.bindDN* 和 dex.config.ldap.BIND_PW_ENV_VAR* 應用程式服務帳戶的 DN 和密碼。
Pinniped dex.config.ldap.userSearch* 使用者搜尋屬性。有關配置，請參閱 Dex 說明文件。
Pinniped dex.config.ldap.groupSearch* 群組搜尋屬性。有關配置，請參閱 Dex 說明文件。
vSphere CSI vsphereCSI.provisionTimeout 預設值為 300s。
vSphere CSI vsphereCSI.attachTimeout 預設值為 300s。
vSphere CSI vsphereCSI.netPermissions 預設值為 null。

* 如果要更新以 dex. 開頭的 Pinniped 設定，請參閱部署管理叢集後更新 Dex 設定。

自訂 values.yaml 設定

要在已執行的基於計劃或 TKC 的叢集中自訂附加元件密鑰的 values.yaml 部分，請執行以下操作：

  1. 透過對管理叢集執行 kubectl get secret CLUSTER-NAME-PACKAGE-NAME-addon -n CLUSTER-NAMESPACE 命令來擷取密鑰：例如：

    kubectl get secret example-workload-cluster-antrea-addon -n example-workload-cluster-namespace -o jsonpath="{.data.values\.yaml}" | base64 -d > values.yaml

  2. 更新 values.yaml 部分。您可以更新上表中列出的任何值。

  3. 套用您的更新，方法是對所編輯的 values.yaml 檔案進行 base64 編碼，並在叢集密鑰中取代該檔案。此命令會因環境的作業系統而異。例如：

    Linux：

    kubectl patch secret/example-workload-cluster-antrea-addon -n example-workload-cluster-namespace -p "{\"data\":{\"values.yaml\":\"$(base64 -w 0 < values.yaml)\"}}" --type=merge

    macOS：

    kubectl patch secret/example-workload-cluster-antrea-addon -n example-workload-cluster-namespace -p "{\"data\":{\"values.yaml\":\"$(base64 < values.yaml)\"}}" --type=merge

  4. 在更新密鑰後，執行 kubectl get packageinstall 命令來檢查套件狀態。例如：

    $ kubectl get packageinstall antrea -n tkg-system
NAMESPACE    NAME                   PACKAGE NAME                      PACKAGE VERSION                 DESCRIPTION                  AGE
tkg-system   antrea                 antrea.tanzu.vmware.com           0.13.3+vmware.1-tkg.1           Reconcile succeeded          7d14h

    如果傳回的狀態為 Reconcile failed，請執行以下命令，以取得有關失敗的詳細資料：

    kubectl get packageinstall antrea -n tkg-system -o yaml

  5. 執行 kubectl get app 命令。例如：

    $ kubectl get app antrea -n tkg-system
NAME           DESCRIPTION             SINCE-DEPLOY    AGE
antrea         Reconcile succeeded     3m23s           7h50m

    如果傳回的狀態為 Reconcile failed，請執行以下命令，以取得有關失敗的詳細資料：

    kubectl get app antrea -n tkg-system -o yaml

以下範例更新了 Antrea 的預設傳輸單元最大值 (MTU)。

stringData:
  values.yaml: |
    #@data/values
    #@overlay/match-child-defaults missing_ok=True
    ---
    infraProvider: vsphere
    antrea:
      config:
        defaultMTU: 8900
附註

請確定您為叢集中的所有節點所設定的 MTU 設定都相同。防火牆設定必須允許具有所設定 MTU 大小的封包。要解決由叢集中節點上的不同 MTU 設定引起的任何問題，請參閱 MTU 不相符導致叢集工作節點處於 NotReady 狀態。

使用覆疊自訂

在某些情況下，您可以向附加元件密鑰新增覆疊，以便在建立基於計劃或 TKC 的叢集之前自訂這些叢集的自動管理套件組態。

以下範例指示 Pinniped 使用 LoadBalancer 服務類型，而不是 NodePort，當 NSX Advanced Load Balancer (ALB) 未用作控制平面端點時，這是 vSphere 上的預設值：

...
stringData:
 overlays.yaml: |
   #@ load("@ytt:overlay", "overlay")
   #@overlay/match by=overlay.subset({"kind": "Service", "metadata": {"name": "pinniped-supervisor", "namespace": "pinniped-supervisor"}})
   ---
   #@overlay/replace
   spec:
     type: LoadBalancer
     selector:
       app: pinniped-supervisor
     ports:
       - name: https
         protocol: TCP
         port: 443
         targetPort: 8443
 values.yaml: |
   #@data/values
   #@overlay/match-child-defaults missing_ok=True
   ---
   infrastructure_provider: vsphere
   tkg_cluster_role: management

要新增覆疊：

  1. 透過對管理叢集執行 kubectl get secret CLUSTER-NAME-PACKAGE-NAME-addon -n CLUSTER-NAMESPACE 命令來擷取密鑰：例如：

    kubectl get secret example-workload-cluster-pinniped-addon -n example-workload-cluster-namespace -o jsonpath="{.data.values\.yaml}" | base64 -d > values.yaml

  2. 在 overlays.yaml 下新增 stringData 部分。

  3. 套用您的更新，方法是對所編輯的 values.yaml 檔案進行 base64 編碼，並在叢集密鑰中取代該檔案。此命令會因環境的作業系統而異。例如：

    Linux：

    kubectl patch secret/example-workload-cluster-pinniped-addon -n example-workload-cluster-namespace -p "{\"data\":{\"values.yaml\":\"$(base64 -w 0 < values.yaml)\"}}" --type=merge

    macOS：

    kubectl patch secret/example-workload-cluster-pinniped-addon -n example-workload-cluster-namespace -p "{\"data\":{\"values.yaml\":\"$(base64 < values.yaml)\"}}" --type=merge

  4. 更新密鑰後，透過執行 kubectl get packageinstall 和 kubectl get app 命令來檢查套件的狀態，如自動管理的套件 values.yaml 設定中所述。

自訂基於類別的資訊清單

對於基於類別的叢集，可以在建立叢集之前對其自訂，方法是按照建立以類別為基礎的叢集中所述的兩步驟程序步驟 1 中建立叢集資訊清單，然後將自訂物件定義加入資訊清單中，再於步驟 2 中建立叢集。

例如，如要自訂 vSphere CSI 的 netPermissions 值，請修改使用 tanzu cluster create --dry-run 產生的資訊清單，方法是在 netPermissions 物件的 VSphereCSIConfig 區塊中加入類似以下內容的 spec.vsphereCSI 區塊：

apiVersion: csi.tanzu.vmware.com/v1alpha1
kind: VSphereCSIConfig
[...]
spec:
  vsphereCSI:
    mode: vsphereCSI
    config:
      [...]
      provisionTimeout: 33s
      attachTimeout: 77s
      resizerTimeout: 99s
      netPermissions:
        PERM-1:
          ips: "*"
          permissions: READ_WRITE
          rootsquash: false
        PERM-2:
          ips: "10.20.20.0/24"
          permissions: READ_ONLY
          rootsquash: true
        PERM-3:
          ips: "10.30.30.0/24"
          permissions: NO_ACCESS

其中：

  • PERM-* 是您為權限設定的該部分指定的名稱，可轉換為 vSphere 設定密鑰中的 [NetPermissions "PERM-1"] 等。
  • ips: 值是該部分為其設定權限的檔案磁碟區的位址範圍。
  • permissions: 值是為該部分設定的權限。

修改資訊清單後，可以按照建立以類別為基礎的叢集中的步驟 2 建立叢集。

疑難排解套件組態

要對叢集中的自動管理的套件組態進行疑難排解，請查看並修改套件的 PackageInstall 自訂資源 (CR) 和元件 Secret。

要對套件組態套用臨時變更，可能需要暫停協調 PackageInstall 和 Secret 物件，如以下自動管理套件的暫停生命週期管理所述。此程序將停用套件的生命週期管理，應謹慎使用。

關鍵詞彙

Tanzu Kubernetes Grid 使用以下資源來管理自動管理套件的生命週期。

管理叢集中安裝的元件：

  • kapp-controller，本機套件管理員：部署管理叢集時，Tanzu CLI 會在叢集中安裝 kapp-controller。kapp-controller 將安裝 tanzu-addons-manager 和其他自動管理的套件。它還會在從管理叢集部署的每個工作負載叢集中安裝和管理 kapp-controller。
  • tanzu-addons-manager：管理叢集和從管理叢集部署的工作負載叢集中作為自動管理的套件安裝的附加元件。
  • tkr-controller：在管理叢集中建立 TKrs 和 BoM ConfigMaps。

工作負載叢集中安裝的元件：

kapp-controller 會在執行它的工作負載叢集中安裝自動管理的套件。

物件:

  • Secret：Tanzu CLI 為每個叢集的每個附加元件建立一個 Secret。這些密鑰定義了附加元件的組態。tanzu-addons-manager 讀取密鑰，並使用密鑰包含的組態資訊來設定附加元件。所有密鑰都儲存在管理叢集中。
  • PackageRepository CR：tanzu-addons-manager 建立 PackageRepository CR，該 CR 引用所有附加元件Package CR (如下所示)。
  • Package CR：對於 PackageRepository、kapp-controller 中的每個附加元件都會在目標叢集中建立一個 Package CR。
  • PackageInstall CR：對於附加元件 Package，tanzu-addons-manager 會在目標叢集中建立一個 PackageInstall CR，以通知 kapp-controller 需要安裝哪些自動管理的套件。
  • App CR：對於每個 PackageInstall，kapp-controller 會在目標叢集中建立一個 App CR。然後，kapp-controller 協調 CR 並安裝套件。
  • BoM ConfigMap：向 tanzu-addons-manager 提供有關附加元件 (如映像位置) 的中繼資料。

您可以使用以下命令監控這些資源的狀態：

命令 說明
kubectl get packageinstall PACKAGE-NAME -n tkg-system -o yaml 檢查目標叢集中的 PackageInstall CR。例如，kubectl get packageinstall antrea -n tkg-system -o yaml。
kubectl get app PACKAGE-NAME -n tkg-system -o yaml 檢查目標叢集中的 App CR。例如，kubectl get app antrea -n tkg-system -o yaml。
kubectl get cluster CLUSTER-NAME -n CLUSTER-NAMESPACE -o jsonpath={.metadata.labels.tanzuKubernetesRelease} 在管理叢集中，檢查目標叢集的 TKr 標籤是否指向正確的 TKr。
kubectl get tanzukubernetesrelease TKR-NAME 檢查 TKr 是否位於管理叢集中。
kubectl get configmaps -n tkr-system -l ‘tanzuKubernetesRelease=TKR-NAME’ 檢查管理叢集中是否存在與您的 TKr 對應的 BoM ConfigMap。
kubectl get app CLUSTER-NAME-kapp-controller -n CLUSTER-NAMESPACE 對於工作負載叢集，請檢查管理叢集中是否存在 kapp-controller App CR。
kubectl logs deployment/tanzu-addons-controller-manager -n tkg-system 檢查管理叢集中的 tanzu-addons-manager 記錄。
kubectl get configmap -n tkg-system | grep ADD-ON-NAME-ctrl 檢查是否已套用對附加元件密鑰的更新。同步時間為 5 分鐘。

暫停自動管理的套件的生命週期管理

重要

本節中的命令會停用套件生命週期管理。如果可能，請改用上述更新套件組態中所述的程序。

如果需要臨時暫停自動管理的套件的生命週期管理，可以使用以下命令：

  • 要暫停密鑰協調，請對管理叢集執行以下命令：

    kubectl patch secret/CLUSTER-NAME-ADD-ON-NAME-addon -n CLUSTER-NAMESPACE -p '{"metadata":{"annotations":{"tkg.tanzu.vmware.com/addon-paused": ""}}}' --type=merge

    執行此命令後，tanzu-addons-manager 會停止協調密鑰。

  • 如要暫停 PackageInstall CR 協調，請針對目標叢集執行以下命令：

    kubectl patch packageinstall/PACKAGE-NAME -n tkg-system -p '{"spec":{"paused":true}}' --type=merge

    執行此命令後，kapp-controller 會停止協調 PackageInstall 和相應的 App CR。

如果要臨時修改附加元件的資源，請先暫停密鑰協調，然後再暫停 PackageInstall CR 協調。取消暫停生命週期管理後，tanzu-addons-manager 和 kapp-controller 會恢復密鑰及 PackageInstall CR 協調：

  • 要取消暫停金鑰協調，請從密鑰註解中移除 tkg.tanzu.vmware.com/addon-paused。

  • 要取消暫停 PackageInstall CR 協調，請將 PackageInstall CR 更新為 {"spec":{"paused":false}} 或移除變數。

check-circle-line exclamation-circle-line close-line
Scroll to top icon