此主題說明如何檢視從 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 管理,因此您通常不需要更新其組態。
類型 | 資源 | 說明 |
---|---|---|
組態更新 | 附加元件 Secret |
如要更新由自動管理的套件安裝的附加元件預設組態,您可以:
|
疑難排解 | PackageInstall 自訂資源 (CR) 和 Secret 附加元件 |
步驟同上。此外,如果需要對套件組態套用臨時變更,您可以:
這將停用套件的生命週期管理。請謹慎使用。如需詳細資訊,請參見下面的暫停自動管理套件的生命週期管理。 |
有關附加元件密碼和 PackageInstall
CR 的詳細資訊,請參見下面的主要術語。
您可以透過修改附加元件密碼的 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 的服務類型而定,可能還需要包含連接埠號:
|
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 。 |
* 如果要更新以 dex.
開頭的 Pinniped 設定,請參閱部署管理叢集後更新 Dex 設定。
如要修改附加元件密碼的 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 狀態。
在某些情況下,您可以將覆疊新增至附加元件密碼。這樣,您可以自訂套件組態檔中定義的預設組態。以下範例指示 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 部分中所述。
在對自動管理的套件進行疑難排解之前,請查看以下部分:
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}}
或移除變數。