本主題介紹了如何檢視和自訂從 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 套件組態檔:
在用於建立叢集的 Tanzu Kubernetes 版本 (Tkr) 中找到 antrea
的版本標籤。您可以通過對管理叢集執行 kubectl get tkr
命令來擷取 TKr。
執行 kubectl get clusters CLUSTER-NAME -n CLUSTER-NAMESPACE --show-labels
。
在輸出中,找到 tanzuKubernetesRelease
的值。例如,tanzuKubernetesRelease=v1.23.10---vmware.1-tkg.1
。
執行 kubectl get tkr TKR-VERSION
,其中 TKR-VERSION
是上面擷取的值。例如:
kubectl get tkr v1.23.10---vmware.1-tkg.1 -o yaml
在輸出中,在 packages/core/antrea
下找到版本標籤。
或者,也可以通過在 ~/.config/tanzu/tkg/bom/YOUR-TKR-BOM-FILE
中查看 TKr 找到版本標籤。
下載套件組態檔。例如:
imgpkg pull -b projects.registry.vmware.com/tkg/packages/core/antrea:v1.2.3_vmware.4-tkg.1-advanced -o antrea
導覽到 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
部分中設定:
套件 | 設定 | 說明 |
---|---|---|
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 的服務類型而定,可能還需要包含連接埠號:
|
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 設定。
要在已執行的基於計劃或 TKC 的叢集中自訂附加元件密鑰的 values.yaml
部分,請執行以下操作:
透過對管理叢集執行 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
更新 values.yaml
部分。您可以更新上表中列出的任何值。
套用您的更新,方法是對所編輯的 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
在更新密鑰後,執行 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
執行 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
要新增覆疊:
透過對管理叢集執行 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
在 overlays.yaml
下新增 stringData
部分。
套用您的更新,方法是對所編輯的 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
更新密鑰後,透過執行 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 並安裝套件。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}}
或移除變數。