En este tema se explica cómo ver, personalizar y solucionar los problemas de configuración de los paquetes administrados automáticamente instalados desde el repositorio de tanzu-core
. También enumera los ajustes de configuración de Antrea, Pinniped, Calico, vSphere CPI y vSphere CSI que puede personalizar.
Los paquetes administrados automáticamente, que se encuentran en el repositorio de tanzu-core
, contienen componentes que admiten la funcionalidad básica del clúster, como la interfaz de red de contenedor de Antrea o Calico y el componente de autenticación Pinniped. En algunos casos, los recursos internos de Tanzu Kubernetes Grid y Kubernetes hacen referencia a estos componentes como addons
.
Para ver la configuración de un paquete administrado automáticamente y el componente de complemento que contiene, puede:
Recuperar el secreto de Kubernetes para el componente de complemento instalado ejecutando el comando kubectl get secret CLUSTER-NAME-PACKAGE-NAME-addon -n CLUSTER-NAMESPACE
en el clúster de administración. Donde:
CLUSTER-NAME
es el nombre de su clúster de destino. Si desea recuperar el secreto del componente de complemento que está instalado en un clúster de carga de trabajo, CLUSTER-NAME
es el nombre del clúster de carga de trabajo.PACKAGE-NAME
es el nombre del paquete.CLUSTER-NAMESPACE
es el espacio de nombres de su clúster de destino.Descargue los archivos de configuración del paquete de projects.registry.vmware.com/tkg/packages/core
.
Por ejemplo, para ver la configuración de Antrea:
Recupere el secreto de Antrea ejecutando el siguiente comando en el clúster de administración:
kubectl get secret CLUSTER-NAME-antrea-addon -n CLUSTER-NAMESPACE
Descargue los archivos de configuración del paquete de Antrea:
Busque la etiqueta de versión para antrea
en la versión de Tanzu Kubernetes (TKr) que utilizó para crear el clúster. Puede recuperar la TKr ejecutando el comando kubectl get tkr
respecto al clúster de administración:
Ejecute kubectl get clusters CLUSTER-NAME -n CLUSTER-NAMESPACE --show-labels
.
En el resultado, busque el valor de tanzuKubernetesRelease
. Por ejemplo, tanzuKubernetesRelease=v1.23.10---vmware.1-tkg.1
.
Ejecute kubectl get tkr TKR-VERSION
, donde TKR-VERSION
es el valor que recuperó anteriormente. Por ejemplo:
kubectl get tkr v1.23.10---vmware.1-tkg.1 -o yaml
En el resultado, busque la etiqueta de versión en packages/core/antrea
.
Si lo prefiere, puede buscar la etiqueta de versión revisando la TKr en ~/.config/tanzu/tkg/bom/YOUR-TKR-BOM-FILE
.
Descargue los archivos de configuración del paquete. Por ejemplo:
imgpkg pull -b projects.registry.vmware.com/tkg/packages/core/antrea:v1.2.3_vmware.4-tkg.1-advanced -o antrea
Desplácese hasta antrea
y revise los archivos.
Para obtener más información sobre las funciones de red de contenedores de Antrea, consulte las Notas de la versión de VMware Container Networking con Antrea 1.4.0. Para obtener más información sobre la integración de un clúster de contenedores de Antrea con VMware NSX, consulte Integración de clústeres de contenedores de Antrea.
Debido a que los paquetes administrados automáticamente se administran mediante Tanzu Kubernetes Grid, por lo general, no es necesario personalizar la configuración de los paquetes administrados automáticamente en los clústeres de carga de trabajo.
Sin embargo, puede personalizar estos ajustes si es necesario. La forma en que se personaliza la configuración del paquete administrado automáticamente depende del tipo de clúster.
Para los clústeres basados en plan o TKC, puede modificar y aplicar revisiones a la sección values.yaml
del secreto del componente para personalizar individualmente un clúster existente, como se describe en Personalizar la configuración de values.yaml.
En algunos casos con clústeres basados en planes o TKC, puede agregar una superposición al secreto de configuración del paquete en el clúster de administración para personalizar los clústeres antes de crearlos, como se describe en Personalizar con una superposición.
Para los clústeres basados en clases, puede personalizar el clúster antes de crearlo mediante la creación de un manifiesto del clúster como en el paso 1 de un proceso de dos pasos descrito en Crear un clúster basado en clases y, a continuación, agregar una definición de objeto personalizada al manifiesto antes de crear el clúster en el paso 2. Para ver un ejemplo, consulte Personalizar un manifiesto basado en clases.
Puede personalizar las siguientes opciones de configuración en los paquetes administrados automáticamente. Estos valores se establecen en la sección values.yaml
del secreto del componente del paquete:
Paquete | Configuración | Descripción |
---|---|---|
Antrea | antrea.config.defaultMTU |
El valor predeterminado es null . |
Antrea | antrea.config.tlsCipherSuites |
Incluya conjuntos de claves de cifrado habilitados para FIPS de forma predeterminada. Para cambiar a otros conjuntos de claves de cifrado, actualice los valores en el campo tlsCipherSuites . |
Calico | calico.config.vethMTU |
El valor predeterminado es “0” , lo que hace que Calico detecte automáticamente su configuración de tamaño de transmisión máximo (MTU). Establezca este parámetro para especificar un tamaño de paquete máximo, en bytes, como una cadena. |
Calico | calico.config.skipCNIBinaries |
El valor predeterminado es true , lo que impide que Calico sobrescriba la configuración de los complementos de CNI existentes durante la creación del clúster. Cuando actualice un clúster, para evitar la sobrescritura, establezca calico.config.skipCNIBinaries=true . |
Pinniped | pinniped.supervisor_svc_external_dns |
Un FQDN asociado con un supervisor Pinniped, que se utiliza como URL de devolución de llamada en el cliente IDP de OIDC. Según el tipo de servicio de Pinniped, es posible que también deba incluir el número de puerto:
|
Pinniped | pinniped.upstream_oidc_client_id |
El identificador de cliente del proveedor de OIDC. |
Pinniped | pinniped.upstream_oidc_client_secret |
El secreto de cliente del proveedor de OIDC. |
Pinniped | pinniped.upstream_oidc_issuer_url |
La URL del proveedor de OIDC. |
Pinniped | pinniped.upstream_oidc_tls_ca_data |
Los datos del paquete de CA con codificación base64 que se utilizan para verificar las conexiones TLS con el proveedor de OIDC. |
Pinniped | pinniped.upstream_oidc_additional_scopes |
Una lista de ámbitos adicionales para solicitar en la respuesta del token. |
Pinniped | pinniped.upstream_oidc_claims |
Asignación de notificación de OIDC. |
Pinniped | dex.config.ldap.host * |
La dirección IP o DNS del servidor LDAP. Si desea cambiar el puerto predeterminado 636 a otro puerto, especifique “host:port” . |
Pinniped | dex.config.ldap.bindDN * y dex.config.ldap.BIND_PW_ENV_VAR * |
El DN y la contraseña de una cuenta de servicio de aplicaciones. |
Pinniped | dex.config.ldap.userSearch * |
Busque atributos para usuarios. Para ver el esquema, consulte la documentación de Dex. |
Pinniped | dex.config.ldap.groupSearch * |
Busque atributos para grupos. Para ver el esquema, consulte la documentación de Dex. |
vSphere CSI | vsphereCSI.provisionTimeout |
El valor predeterminado es 300s . |
vSphere CSI | vsphereCSI.attachTimeout |
El valor predeterminado es 300s . |
vSphere CSI | vsphereCSI.netPermissions |
El valor predeterminado es null . |
* Si desea actualizar una opción de Pinniped que comience con dex.
, consulte Actualizar configuración Dex después de la implementación del clúster de administración.
Para personalizar la sección values.yaml
de un secreto de componente de complemento en un clúster basado en TKC o plan que ya está en ejecución:
Recupere el secreto de ejecutando el siguiente comando kubectl get secret CLUSTER-NAME-PACKAGE-NAME-addon -n CLUSTER-NAMESPACE
en el clúster de administración. Por ejemplo:
kubectl get secret example-workload-cluster-antrea-addon -n example-workload-cluster-namespace -o jsonpath="{.data.values\.yaml}" | base64 -d > values.yaml
Actualice la sección values.yaml
. Puede actualizar cualquiera de los valores enumerados en la tabla anterior.
Aplique la actualización mediante codificación base64 del archivo values.yaml
editado y sustituyéndolo en el secreto del clúster. Este comando varía según el sistema operativo del entorno. Por ejemplo:
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
Después de actualizar el secreto, verifique el estado del paquete ejecutando el comando kubectl get packageinstall
. Por ejemplo:
$ 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
Si el estado devuelto es Reconcile failed
, ejecute el siguiente comando para obtener detalles sobre el error:
kubectl get packageinstall antrea -n tkg-system -o yaml
Ejecute el comando kubectl get app
. Por ejemplo:
$ kubectl get app antrea -n tkg-system
NAME DESCRIPTION SINCE-DEPLOY AGE
antrea Reconcile succeeded 3m23s 7h50m
Si el estado devuelto es Reconcile failed
, ejecute el siguiente comando para obtener detalles sobre el error:
kubectl get app antrea -n tkg-system -o yaml
El siguiente ejemplo actualiza la unidad de transmisión máxima (Maximum Transmission Unit, MTU) predeterminada para Antrea.
stringData:
values.yaml: |
#@data/values
#@overlay/match-child-defaults missing_ok=True
---
infraProvider: vsphere
antrea:
config:
defaultMTU: 8900
NotaAsegúrese de configurar los mismos ajustes de MTU para todos los nodos de un clúster. La configuración del firewall debe permitir paquetes del tamaño de MTU configurado. Para resolver cualquier problema causado por diferentes configuraciones de MTU en los nodos de un clúster, consulte Nodos de trabajo del clúster en estado No listo debido a MTU no coincidentes.
En algunos casos, puede agregar una superposición al secreto del componente de complemento para personalizar la configuración de paquetes administrados automáticamente de los clústeres basados en planes o TKC antes de crearlos.
En el siguiente ejemplo, se indica a Pinniped que utilice el tipo de servicio LoadBalancer
en lugar de NodePort
, que es el valor predeterminado en vSphere cuando NSX Advanced Load Balancer (ALB) no funciona como endpoint del plano de control:
...
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
Para agregar una superposición:
Recupere el secreto de ejecutando el siguiente comando kubectl get secret CLUSTER-NAME-PACKAGE-NAME-addon -n CLUSTER-NAMESPACE
en el clúster de administración. Por ejemplo:
kubectl get secret example-workload-cluster-pinniped-addon -n example-workload-cluster-namespace -o jsonpath="{.data.values\.yaml}" | base64 -d > values.yaml
Agregue la sección overlays.yaml
en stringData
.
Aplique la actualización mediante codificación base64 del archivo values.yaml
editado y sustituyéndolo en el secreto del clúster. Este comando varía según el sistema operativo del entorno. Por ejemplo:
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
Después de actualizar el secreto, verifique el estado del paquete ejecutando los comandos kubectl get packageinstall
ykubectl get app
como se describe en la Configuración de values.yaml del paquete administrado automáticamente.
Para los clústeres basados en clases, puede personalizar el clúster antes de crearlo mediante la creación de un manifiesto del clúster como en el paso 1 de un proceso de dos pasos descrito en Crear un clúster basado en clases y, a continuación, agregar una definición de objeto personalizada al manifiesto antes de crear el clúster en el paso 2.
Por ejemplo, para personalizar el valor de netPermissions
para vSphere CSI, modifique el manifiesto generado con tanzu cluster create --dry-run
agregando un bloque netPermissions
como el siguiente en el bloque de definición de spec.vsphereCSI
del objeto VSphereCSIConfig
.
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
Donde:
PERM-*
es un nombre que se otorga a esa sección de la configuración de permisos, que se convierte a [NetPermissions "PERM-1"]
etc. en el secreto de configuración de vSphere.ips:
es el rango de direcciones de los volúmenes de archivos para los que la sección establece permisos.permissions:
indica los permisos establecidos para esa sección.Después de modificar el manifiesto, puede crear el clúster siguiendo el paso 2 en Crear un clúster basado en clases.
Para solucionar los problemas de las configuraciones de paquetes administrados automáticamente en un clúster, revise y modifique el recurso personalizado (CR) PackageInstall
y el componente Secret
.
Para aplicar cambios temporales a la configuración de su paquete, es posible que deba pausar la reconciliación de los objetos PackageInstall
y Secret
como se describe en Pausar la administración del ciclo de vida para un paquete administrado automáticamente a continuación. Este procedimiento desactiva la administración del ciclo de vida del paquete y debe utilizarse con precaución.
Tanzu Kubernetes Grid utiliza los siguientes recursos para administrar el ciclo de vida de los paquetes administrados automáticamente.
Componentes instalados en el clúster de administración:
kapp-controller
, un administrador de paquetes local: Cuando se implementa un clúster de administración, la CLI de Tanzu instala kapp-controller
en el clúster. kapp-controller
instala tanzu-addons-manager
y otros paquetes administrados automáticamente. También instala y administra kapp-controller
en cada clúster de carga de trabajo que se implementa desde ese clúster de administración.tanzu-addons-manager
: Administra los componentes de complemento que se instalan, como paquetes administrados automáticamente, en el clúster de administración y los clústeres de carga de trabajo que se implementan desde el clúster de administración.tkr-controller
: Crea ConfigMaps de TKr y BoM en el clúster de administración.Componente instalado en clústeres de carga de trabajo:
kapp-controller
instala paquetes administrados automáticamente en el clúster de carga de trabajo en el que se ejecuta.
Objetos:
Secret
: La CLI de Tanzu crea un Secret
para cada componente de complemento, por clúster. Estos secretos definen la configuración de los componentes del complemento. tanzu-addons-manager
lee los secretos y utiliza la información de configuración que contienen para configurar los componentes del complemento. Todos los secretos se crean en el clúster de administración.PackageRepository
: tanzu-addons-manager
crea un CR PackageRepository
que hace referencia a todos los CR Package
de componentes del complemento (consulte a continuación).Package
: Para cada componente de complemento de PackageRepository
, kapp-controller
crea un CR Package
en el clúster de destino.PackageInstall
: Para cada componente de complemento Package
, tanzu-addons-manager
crea un CR PackageInstall
en el clúster de destino para informar a kapp-controller
sobre qué paquetes administrados automáticamente debe instalar.App
: Para cada PackageInstall
, kapp-controller
crea un CR App
en el clúster de destino. A continuación, kapp-controller
concilia el CR e instala el paquete.tanzu-addons-manager
.Puede utilizar los siguientes comandos para supervisar el estado de estos recursos:
Comando | Descripción |
---|---|
kubectl get packageinstall PACKAGE-NAME -n tkg-system -o yaml |
Compruebe el CR PackageInstall en el clúster de destino. Por ejemplo, kubectl get packageinstall antrea -n tkg-system -o yaml . |
kubectl get app PACKAGE-NAME -n tkg-system -o yaml |
Compruebe el CR App en el clúster de destino. Por ejemplo, kubectl get app antrea -n tkg-system -o yaml . |
kubectl get cluster CLUSTER-NAME -n CLUSTER-NAMESPACE -o jsonpath={.metadata.labels.tanzuKubernetesRelease} |
En el clúster de administración, compruebe si la etiqueta de TKr del clúster de destino apunta al TKr correcto. |
kubectl get tanzukubernetesrelease TKR-NAME |
Compruebe si la TKr está presente en el clúster de administración. |
kubectl get configmaps -n tkr-system -l ‘tanzuKubernetesRelease=TKR-NAME’ |
Compruebe si el ConfigMap de BoM correspondiente a su TKr está presente en el clúster de administración. |
kubectl get app CLUSTER-NAME-kapp-controller -n CLUSTER-NAMESPACE |
Para los clústeres de carga de trabajo, compruebe si el CR kapp-controller App está presente en el clúster de administración. |
kubectl logs deployment/tanzu-addons-controller-manager -n tkg-system |
Compruebe los registros de tanzu-addons-manager en el clúster de administración. |
kubectl get configmap -n tkg-system | grep ADD-ON-NAME-ctrl |
Compruebe si se aplicaron las actualizaciones al secreto del complemento. El período de sincronización es de 5 minutos. |
ImportanteLos comandos de esta sección desactivan la administración del ciclo de vida de los paquetes. Siempre que sea posible, utilice los procedimientos descritos en Actualizar la configuración del paquete en su lugar.
Si necesita pausar temporalmente la administración del ciclo de vida de un paquete administrado automáticamente, puede utilizar los siguientes comandos:
Para pausar la reconciliación secreta, ejecute el siguiente comando en el clúster de administración:
kubectl patch secret/CLUSTER-NAME-ADD-ON-NAME-addon -n CLUSTER-NAMESPACE -p '{"metadata":{"annotations":{"tkg.tanzu.vmware.com/addon-paused": ""}}}' --type=merge
Después de ejecutar este comando, tanzu-addons-manager
deja de conciliar el secreto.
Para pausar la reconciliación de CR PackageInstall
, ejecute el siguiente comando en el clúster de destino:
kubectl patch packageinstall/PACKAGE-NAME -n tkg-system -p '{"spec":{"paused":true}}' --type=merge
Después de ejecutar este comando, kapp-controller
deja de conciliar PackageInstall
y el CR App
correspondiente.
Si desea modificar temporalmente los recursos de un componente de complemento, primero detenga la reconciliación de secretos y, a continuación, detenga la reconciliación de CR PackageInstall
. Después de anular la pausa de la administración del ciclo de vida, tanzu-addons-manager
y kapp-controller
reanudan el secreto y la reconciliación de CR PackageInstall
:
Para anular la pausa de reconciliación de secretos, elimine tkg.tanzu.vmware.com/addon-paused
de las anotaciones secretas.
Para anular la pausa de la reconciliación de CR PackageInstall
, actualice el CR PackageInstall
con {"spec":{"paused":false}}
o elimine la variable.