Ver y actualizar la configuración de paquetes administrados automáticamente

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.

Algunos de los procedimientos de este tema utilizan imgpkg. Para obtener información sobre cómo descargar e instalar imgpkg, consulte Instalar Carvel Tools.

Ver configuración del paquete

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:
1. 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:
  1. Ejecute kubectl get clusters CLUSTER-NAME -n CLUSTER-NAMESPACE --show-labels.
  2. En el resultado, busque el valor de tanzuKubernetesRelease. Por ejemplo, tanzuKubernetesRelease=v1.27.5---vmware.2-tkg.1.
  3. Ejecute kubectl get tkr TKR-VERSION, donde TKR-VERSION es el valor que recuperó anteriormente. Por ejemplo:
```
kubectl get tkr v1.27.5---vmware.2-tkg.1 -o yaml
```
  4. En el resultado, busque la etiqueta de versión en packages/core/antrea.
2. Descargue los archivos de configuración del paquete. Por ejemplo:
```
imgpkg pull -b projects.registry.vmware.com/tkg/packages/core/antrea:v1.11.2_vmware.1-tkg.1-advanced -o antrea
```
3. 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.6.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 Kubernetes con Antrea CNI.

Personalizar la configuración del paquete

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.

Configuración de values.yaml de paquetes administrados automáticamente

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: Para `LoadBalancer`, en vSphere con NSX ALB, AWS o Azure, no incluya el número de puerto: `https://hr.tkg.example.com` Para `NodePort` como en vSphere sin NSX ALB, incluya el número de puerto: `https://hr.tkg.example.com:31234`
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.
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`.

Personalizar la configuración de values.yaml

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           1.11.1+vmware.4-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

Nota
Asegú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.

Personalizar con una superposición

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.

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.

Personalizar un manifiesto basado en clases

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.
El valor ips: es el rango de direcciones de los volúmenes de archivos para los que la sección establece permisos.
El valor 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.

Solucionar problemas de configuración del paquete

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.

Términos clave

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.
CR PackageRepository: tanzu-addons-manager crea un CR PackageRepository que hace referencia a todos los CR Package de componentes del complemento (consulte a continuación).
CR Package: Para cada componente de complemento de PackageRepository, kapp-controller crea un CR Package en el clúster de destino.
CR 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.
CR 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.
ConfigMap de BoM: Proporciona información de metadatos sobre los componentes del complemento, como la ubicación de la imagen, para 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.

Pausar la administración del ciclo de vida de un paquete administrado automáticamente

Importante
Los 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.