Implementar clústeres de administración desde un archivo de configuración

Puede utilizar la CLI de Tanzu para implementar un clúster de administración en vSphere, Amazon Web Services (AWS) y Microsoft Azure con una configuración que especifique en un archivo de configuración de YAML.

Requisitos previos

Antes de poder implementar un clúster de administración, debe asegurarse de que el entorno cumpla con los requisitos de la plataforma de destino.

Requisitos previos generales

  • Asegúrese de haber cumplido todos los requisitos y de haber seguido todos los procedimientos descritos en Instalar la CLI de Tanzu y la CLI de Kubernetes para su uso con clústeres de administración independientes.
  • Para las implementaciones de producción, se recomienda enfáticamente habilitar la administración de identidades para sus clústeres. Para obtener información sobre los pasos de preparación que se deben realizar antes de implementar un clúster de administración, consulte Obtener los detalles del proveedor de identidades en Configurar la administración de identidades. Para obtener información conceptual sobre la administración de identidades y el control de acceso en Tanzu Kubernetes Grid, consulte Acerca de la administración de identidades y acceso.
  • Si va a implementar clústeres en un entorno restringido por Internet para vSphere o AWS, también debe realizar los pasos descritos en Preparar un entorno restringido por Internet. Estos pasos incluyen configurar TKG_CUSTOM_IMAGE_REPOSITORY como una variable de entorno.
  • Importante

    Es muy recomendable utilizar la interfaz del instalador de Tanzu Kubernetes Grid en lugar de la CLI para implementar el primer clúster de administración en una plataforma de destino determinada. Cuando se implementa un clúster de administración mediante la interfaz del instalador, este rellena un archivo de configuración de clúster para el clúster de administración con los parámetros necesarios. Puede utilizar el archivo de configuración creado como modelo para futuras implementaciones de la CLI en esta plataforma de destino.

  • Si tiene pensado registrar el clúster de administración con Tanzu Mission Control, asegúrese de que los clústeres de carga de trabajo cumplan los requisitos enumerados en Requisitos para registrar un clúster de Tanzu Kubernetes con Tanzu Mission Control en la documentación de Tanzu Mission Control.

Requisitos previos de infraestructura

vSphere
Asegúrese de que cumple todos los requisitos enumerados en Preparar para implementar clústeres de administración en vSphere.
Importante

En vSphere with Tanzu, es posible que no necesite implementar un clúster de administración. Consulte El supervisor de vSphere with Tanzu es un clúster de administración.

AWS
Asegúrese de que cumple todos los requisitos enumerados en Preparar para implementar clústeres de administración en AWS.
  • Para obtener información sobre las configuraciones de los diferentes tamaños de las instancias de nodo, por ejemplo, t3.large o t3.xlarge, consulte Tipos de instancia de Amazon EC2.
  • Para obtener información sobre cuándo crear una Virtual Private Cloud (VPC) y cuándo reutilizar una VPC existente, consulte Uso de recursos en la cuenta de Amazon Web Services.
  • Si es la primera vez que implementa un clúster de administración en AWS, cree una pila de Cloud Formation para Tanzu Kubernetes Grid en su cuenta de AWS siguiendo las instrucciones de Crear recursos de IAM a continuación.

Crear recursos de IAM

Antes de implementar un clúster de administración en AWS por primera vez, debe crear una pila de CloudFormation para Tanzu Kubernetes Grid, tkg-cloud-vmware-com, en la cuenta de AWS. Esta pila de CloudFormation incluye los recursos de administración de identidades y acceso (IAM) que Tanzu Kubernetes Grid necesita para crear y ejecutar clústeres en AWS. Para obtener más información, consulte Permisos establecidos por Tanzu Kubernetes Grid en Preparar para implementar clústeres de administración en AWS.

  1. Si ya creó la pila de CloudFormation para Tanzu Kubernetes Grid en la cuenta de AWS, omita el resto de este procedimiento.

  2. Si aún no creó la pila de CloudFormation para Tanzu Kubernetes Grid en la cuenta de AWS, asegúrese de que las variables de autenticación de AWS estén establecidas en el entorno local o en la cadena del proveedor de credenciales predeterminado de AWS. Para obtener instrucciones, consulte Configurar credenciales de cuenta de AWS y clave SSH.

    Si configuró credenciales de AWS en varios lugares, la configuración de credenciales utilizada para crear la pila de CloudFormation se aplicará en el siguiente orden de prioridad:

    • Las credenciales establecidas en las variables de entorno local AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN y AWS_REGION se aplican primero.

    • Credenciales almacenadas en un archivo de credenciales compartido como parte de la cadena predeterminada del proveedor de credenciales. Puede especificar la ubicación del archivo de credenciales que se utilizará en la variable de entorno local AWS_SHARED_CREDENTIAL_FILE. Si esta variable de entorno no está definida, se utiliza la ubicación predeterminada de $HOME/.aws/credentials. Si utiliza perfiles de credenciales, el comando utiliza el nombre de perfil especificado en la variable AWS_PROFILE de configuración del entorno local. Si no especifica un valor para esta variable, se utilizará el nombre del perfil default.

      Para obtener un ejemplo de cómo se interpreta la cadena de proveedores de credenciales de AWS predeterminadas para las aplicaciones Java, consulte Trabajar con credenciales AWS en la documentación de AWS.

  3. Ejecute el siguiente comando:

    tanzu mc permissions aws set

    Para obtener más información sobre este comando, ejecute tanzu mc permissions aws set --help.

Importante

El comando tanzu mc permissions aws set reemplaza la utilidad de línea de comandos clusterawsadm que existía en Tanzu Kubernetes Grid v1.1.x y versiones anteriores. Para los clústeres de carga de trabajo y administración existentes implementados inicialmente con v1.1.x o versiones anteriores, siga usando la pila de CloudFormation que se creó ejecutando el comando clusterawsadm alpha bootstrap create-stack. Para Tanzu Kubernetes Grid de v1.2 y clústeres posteriores, utilice la pila tkg-cloud-vmware-com.

Azure
Asegúrese de que cumple todos los requisitos enumerados en Preparar para implementar clústeres de administración en Microsoft Azure.

Para obtener información sobre las configuraciones de los diferentes tamaños de las instancias de nodo para Azure, por ejemplo, Standard_D2s_v3 o Standard_D4s_v3, consulte Tamaños de las máquinas virtuales en Azure.


Crear un archivo de configuración del clúster de administración

Antes de crear un clúster de administración desde un archivo de configuración, debe crear el archivo. Cuando se implementa el clúster de administración desde la CLI, se especifica este archivo mediante la opción --file del comando tanzu mc create.

Al ejecutar el comando tanzu config init por primera vez, se crea el subdirectorio ~/.config/tanzu/tkg que contiene los archivos de configuración de Tanzu Kubernetes Grid.

Si implementó previamente un clúster de administración ejecutando tanzu mc create --ui, el directorio ~/.config/tanzu/tkg/clusterconfigs contiene archivos de configuración del clúster de administración con opciones guardadas desde cada invocación de la interfaz del instalador. Según la infraestructura en la que implementó el clúster de administración, puede utilizar estos archivos como plantillas para los archivos de configuración del clúster para nuevas implementaciones en la misma infraestructura. Si lo prefiere, puede crear archivos de configuración del clúster de administración a partir de las plantillas que se proporcionan en esta documentación.

  • Para utilizar el archivo de configuración de una implementación anterior que realizó mediante la interfaz del instalador, haga una copia del archivo de configuración con un nombre nuevo, ábralo en un editor de texto y actualice la configuración. Para obtener información sobre cómo actualizar todas las opciones de configuración, consulte la Referencia de variables del archivo de configuración.
  • Para crear un nuevo archivo de configuración, consulte Crear un archivo de configuración del clúster de administración a continuación. En esta sección se proporcionan plantillas de archivo de configuración para cada proveedor de infraestructura.

VMware recomienda utilizar un archivo de configuración dedicado para cada clúster de administración, con opciones de configuración específicas de una sola infraestructura.

Crear un archivo de configuración del clúster de administración

Cree un archivo de configuración de clúster de administración independiente con las instrucciones y plantillas que aparecen a continuación.

Consulte la Referencia de variables del archivo de configuración para obtener más información sobre cada variable.

Importante

  • Como se describe en Configurar el clúster de administración, las variables de entorno reemplazan los valores de un archivo de configuración del clúster. Para utilizar todas las opciones de un archivo de configuración de clúster, anule la configuración de cualquier variable de entorno en conflicto antes de implementar el clúster de administración desde la CLI.
  • La compatibilidad con direcciones IPv6 en Tanzu Kubernetes Grid es limitada; consulte Implementar clústeres en IPv6 (solo vSphere). Si no va a realizar la implementación en un entorno de redes de solo IPv6, toda la configuración de dirección IP de los archivos de configuración debe ser IPv4.
  • Algunos parámetros configuran propiedades idénticas. Por ejemplo, la propiedad SIZE configura los mismos ajustes de infraestructura que todas las propiedades de tamaño y tipo del nodo de trabajo y el plano de control para los diferentes plataformas de destino, pero a un nivel más general. En estos casos, evite configurar propiedades redundantes o en conflicto.

Para crear un archivo de configuración para un clúster de administración independiente:

  1. En un editor de texto, abra un nuevo archivo con la extensión .yaml y un nombre adecuado, por ejemplo, aws-mgmt-cluster-config.yaml. Este será el archivo de configuración.

    Si ya implementó un clúster de administración desde la interfaz del instalador, puede crear el archivo en la ubicación predeterminada para las configuraciones del clúster, ~/.config/tanzu/tkg/clusterconfigs.

  2. Si hace referencia al siguiente tema que coincide con su infraestructura, copie y pegue el código de plantilla en la parte superior de la página en el archivo de configuración:

  3. Configure los ajustes dentro del archivo:

    • Siga las instrucciones del resto de la página específica de la infraestructura para configurar las opciones específicas de la infraestructura.
    • Siga las instrucciones del resto de esta página para configurar los ajustes que son comunes a todas las plataformas de destino.

  4. Guarde el archivo.

Configurar la información básica de creación del clúster de administración

La configuración básica de creación del clúster de administración define la infraestructura en la que se implementará el clúster de administración y otras opciones de configuración básicas. Son comunes a todas las plataformas de destino.

  • Por CLUSTER_PLAN especifique si desea implementar un clúster de desarrollo, que proporciona un nodo de plano de control único, o un clúster de producción, que proporciona un clúster de administración de alta disponibilidad con tres nodos de plano de control. Especifique dev o prod.

  • Para INFRASTRUCTURE_PROVIDER, especifique aws, azure o vsphere.

    INFRASTRUCTURE_PROVIDER: aws

    INFRASTRUCTURE_PROVIDER: azure

    INFRASTRUCTURE_PROVIDER: vsphere

  • Opcionalmente, desactive la participación en el Programa de mejora de la experiencia de cliente (CEIP) de VMware estableciendo ENABLE_CEIP_PARTICIPATION como false. Para obtener información sobre el CEIP, consulte Administrar participación en el CEIP y https://www.vmware.com/solutions/trustvmware/ceip.html.

  • De forma opcional, desactive el registro de auditoría estableciendo ENABLE_AUDIT_LOGGING en false. Para obtener información sobre el registro de auditoría, consulte Registro de auditoría.
  • Si los rangos de CIDR recomendados de 100.64.0.0/13 y 100.96.0.0/11 no están disponibles, actualice CLUSTER_CIDR para la red de pods del clúster y SERVICE_CIDR para la red de servicio de clúster.

Por ejemplo:

#! ---------------------------------------------------------------------
#! Basic cluster creation configuration
#! ---------------------------------------------------------------------

CLUSTER_NAME: aws-mgmt-cluster
CLUSTER_PLAN: dev
INFRASTRUCTURE_PROVIDER: aws
ENABLE_CEIP_PARTICIPATION: true
ENABLE_AUDIT_LOGGING: true
CLUSTER_CIDR: 100.96.0.0/11
SERVICE_CIDR: 100.64.0.0/13

Configurar la administración de identidades

Establezca IDENTITY_MANAGEMENT_TYPE en ldap o oidc. Establezca en none u omita para desactivar la administración de identidades. Se recomienda encarecidamente habilitar la administración de identidades para las implementaciones de producción.

IDENTITY_MANAGEMENT_TYPE: oidc

IDENTITY_MANAGEMENT_TYPE: ldap

OIDC

Para configurar OIDC, actualice las siguientes variables. Para obtener información sobre cómo configurar las variables, consulte Proveedor de identidades: OIDC en la Referencia de variables del archivo de configuración.

Por ejemplo:

OIDC_IDENTITY_PROVIDER_CLIENT_ID: 0oa2i[...]NKst4x7
OIDC_IDENTITY_PROVIDER_CLIENT_SECRET: 331!b70[...]60c_a10-72b4
OIDC_IDENTITY_PROVIDER_GROUPS_CLAIM: groups
OIDC_IDENTITY_PROVIDER_ISSUER_URL: https://dev-[...].okta.com
OIDC_IDENTITY_PROVIDER_SCOPES: openid,groups,email,offline_access
OIDC_IDENTITY_PROVIDER_USERNAME_CLAIM: email

LDAP

Para configurar LDAP, quite la marca de comentario y actualice las variables LDAP_* con información sobre el servidor LDAPS. Para obtener información sobre cómo configurar las variables, consulte Proveedor de identidades: LDAP en la Referencia de variables del archivo de configuración.

Por ejemplo:

LDAP_BIND_DN: "cn=bind-user,ou=people,dc=example,dc=com"
LDAP_BIND_PASSWORD: "example-password"
LDAP_GROUP_SEARCH_BASE_DN: dc=example,dc=com
LDAP_GROUP_SEARCH_FILTER: &(objectClass=posixGroup)(memberUid={})
LDAP_GROUP_SEARCH_NAME_ATTRIBUTE: cn
LDAP_GROUP_SEARCH_USER_ATTRIBUTE: uid
LDAP_HOST: ldaps.example.com:636
LDAP_ROOT_CA_DATA_B64: ""
LDAP_USER_SEARCH_BASE_DN: ou=people,dc=example,dc=com
LDAP_USER_SEARCH_FILTER: &(objectClass=posixAccount)(uid={})
LDAP_USER_SEARCH_NAME_ATTRIBUTE: uid

Configurar proxies

Para enviar de forma opcional tráfico HTTP(S) saliente desde el clúster de administración a un proxy (por ejemplo, en un entorno restringido por Internet), quite la marca de comentario y establezca la configuración de *_PROXY. La configuración de proxy es común a todas las plataformas de destino. Puede utilizar un proxy para las solicitudes HTTP y otro proxy para las solicitudes HTTPS, o bien utilizar el mismo proxy para las solicitudes HTTP y HTTPS. No puede cambiar el proxy después de implementar el clúster.

Nota

En vSphere, el tráfico de las máquinas virtuales del clúster a vCenter no se puede utilizar como proxy. En un entorno de vSphere con proxy, debe establecer VSPHERE_INSECURE en true o bien agregar la dirección IP o el nombre de host vCenter a la lista de TKG_NO_PROXY.

  • TKG_HTTP_PROXY_ENABLED: Establezca esta opción en true para configurar un proxy.

  • TKG_PROXY_CA_CERT: Establezca esta opción en la CA del servidor proxy si su certificado está autofirmado.

  • TKG_HTTP_PROXY: Esta es la URL del proxy que controla las solicitudes HTTP. Para establecer la DIRECCIÓN URL, utilice el siguiente formato:

    PROTOCOL://USERNAME:PASSWORD@FQDN-OR-IP:PORT

    Donde:

    • (Requisitos) PROTOCOL: Debe ser http.
    • (Opcional) USERNAME y PASSWORD: Este es el nombre de usuario y la contraseña del proxy HTTP. Debe establecer USERNAME y PASSWORD si el proxy requiere autenticación.

    Nota: Al implementar clústeres de administración con la CLI, no se pueden utilizar los siguientes caracteres no alfanuméricos en las contraseñas: # ` ^ | / \ ? % ^ { [ ] }" < >.

    • (Requisitos) FQDN-OR-IP: Este es el FQDN o la dirección IP del proxy HTTP.
    • (Requisitos) PORT: Este es el número de puerto que utiliza el proxy HTTP.

    Por ejemplo, http://user:[email protected]:1234.

  • TKG_HTTPS_PROXY: Esta es la URL del proxy que controla las solicitudes HTTPS. Puede establecer TKG_HTTPS_PROXY en el mismo valor que TKG_HTTP_PROXY o proporcionar un valor diferente. Para establecer el valor, utilice el formato de URL del paso anterior, donde:

    • (Requisitos) PROTOCOL: Debe ser http.
    • (Opcional) USERNAME y PASSWORD: Este es el nombre de usuario y la contraseña del proxy HTTPS. Debe establecer USERNAME y PASSWORD si el proxy requiere autenticación.

    Nota: Al implementar clústeres de administración con la CLI, no se pueden utilizar los siguientes caracteres no alfanuméricos en las contraseñas: # ` ^ | / \ ? % ^ { [ ] }" < >.

    • (Requisitos) FQDN-OR-IP: Este es el FQDN o la dirección IP del proxy HTTPS.
    • (Requisitos) PORT: Este es el número de puerto que utiliza el proxy HTTPS.

    Por ejemplo, http://user:[email protected]:1234.

  • TKG_NO_PROXY: Esto establece uno o varios CIDR o nombres de host de red separados por comas que deben omitir el proxy HTTP(S), por ejemplo, para permitir que el clúster de administración se comunique directamente con la infraestructura que se ejecuta en la misma red, detrás del mismo proxy. No utilice espacios en la opción de lista separada por comas. Por ejemplo, noproxy.yourdomain.com,192.168.0.0/24.

    En vSphere, esta lista debe incluir:

    • Dirección IP o nombre de host de vCenter.
    • El CIDR de VSPHERE_NETWORK, que incluye la dirección IP del endpoint del plano de control. Si establece VSPHERE_CONTROL_PLANE_ENDPOINT en un FQDN, agregue también ese FQDN a la lista de TKG_NO_PROXY.

    Internamente, Tanzu Kubernetes Grid anexa localhost, 127.0.0.1, los valores de CLUSTER_CIDR y SERVICE_CIDR, .svc y .svc.cluster.local al valor que estableció en TKG_NO_PROXY. También anexa el CIDR de VPC de AWS y el 169.254.0.0/16 para las implementaciones en AWS y el CIDR de Azure VNET, 169.254.0.0/16 y 168.63.129.16 para las implementaciones en Azure. Por vSphere, debe agregar manualmente el CIDR de VSPHERE_NETWORK, que incluye la dirección IP del endpoint del plano de control, a TKG_NO_PROXY. Si establece VSPHERE_CONTROL_PLANE_ENDPOINT en un FQDN, agregue el FQDN y el VSPHERE_NETWORK a TKG_NO_PROXY.

    Importante

    Si las máquinas virtuales del clúster de necesitan comunicarse con servicios externos y endpoints de infraestructura en el entorno de Tanzu Kubernetes Grid, asegúrese de que los servidores proxy que configuró anteriormente puedan acceder a esos endpoints o agréguelos a TKG_NO_PROXY. En función de la configuración del entorno, esto puede incluir, entre otros:

    • Su servidor LDAP u OIDC
    • Harbor
    • VMware NSX
    • NSX Advanced Load Balancer
    • CIDR de VPC de AWS que son externos al clúster

Por ejemplo:

#! ---------------------------------------------------------------------
#! Proxy configuration
#! ---------------------------------------------------------------------

TKG_HTTP_PROXY_ENABLED: true
TKG_PROXY_CA_CERT: "LS0t[...]tLS0tLQ==""
TKG_HTTP_PROXY: "http://myproxy.com:1234"
TKG_HTTPS_PROXY: "http://myproxy.com:1234"
TKG_NO_PROXY: "noproxy.yourdomain.com,192.168.0.0/24"

Configurar los ajustes del nodo

De forma predeterminada, todos los nodos del clúster ejecutan Ubuntu v20.04 para todas las plataformas de destino. En vSphere opcionalmente puede implementar clústeres de que ejecuten Photon OS en sus nodos. En AWS, los nodos pueden ejecutar Amazon Linux 2 de forma opcional. Para la arquitectura, la opción predeterminada y única actual es amd64. Para obtener información sobre la configuración del sistema operativo y la versión, consulte Configuración de nodos en Referencia de variables del archivo de configuración.

Por ejemplo:

#! ---------------------------------------------------------------------
#! Node configuration
#! ---------------------------------------------------------------------

OS_NAME: "photon"
OS_VERSION: "3"
OS_ARCH: "amd64"

La forma en que establezca la configuración y los tamaños de los recursos informáticos del nodo depende de la plataforma de destino. Para obtener información, consulte Configuración del clúster de administración para vSphere, Configuración del clúster de administración para AWS o Configuración del clúster de administración para Microsoft Azure.

Configurar comprobaciones de estado de máquinas

De forma opcional, actualice las variables según las preferencias de implementación y utilice las directrices descritas en la sección Comprobaciones de estado de las máquinas de Referencia de variables del archivo de configuración.

Por ejemplo:

ENABLE_MHC:
ENABLE_MHC_CONTROL_PLANE: true
ENABLE_MHC_WORKER_NODE: true
MHC_MAX_UNHEALTHY_CONTROL_PLANE: 60%
MHC_MAX_UNHEALTHY_WORKER_NODE: 60%
MHC_UNKNOWN_STATUS_TIMEOUT: 10m
MHC_FALSE_STATUS_TIMEOUT: 20m

Configurar un registro de imágenes privado

Si va a implementar el clúster de administración en un entorno con acceso a Internet restringido, quite la marca de comentario y actualice la configuración de TKG_CUSTOM_IMAGE_REPOSITORY_*. La configuración es común a todas las plataformas de destino. No es necesario configurar las opciones del registro de imágenes privado si:

  • Va a implementar el clúster de administración en un entorno con acceso a Internet restringido y ha establecido las variables TKG_CUSTOM_IMAGE_REPOSITORY_* ejecutando el comando tanzu config set, como se describe en Preparar un entorno restringido por Internet. Las variables de entorno establecidas mediante la ejecución de tanzu config set anulan los valores de un archivo de configuración del clúster.
  • Si va a implementar el clúster de administración en un entorno que tenga acceso a Internet externo.

Por ejemplo:

#! ---------------------------------------------------------------------
#! Image repository configuration
#! ---------------------------------------------------------------------

TKG_CUSTOM_IMAGE_REPOSITORY: "custom-image-repository.io/yourproject"
TKG_CUSTOM_IMAGE_REPOSITORY_CA_CERTIFICATE: "LS0t[...]tLS0tLQ=="

Configurar CNI de Antrea

De forma predeterminada, los clústeres que se implementan con la CLI de Tanzu proporcionan redes de contenedores en clúster con la interfaz de red de contenedor de Antrea.

Opcionalmente, puede desactivar la traducción de direcciones de red (SNAT) de origen para el tráfico de pod, implementar los modos de encapsulación de tráfico hybrid, noEncap, NetworkPolicyOnly, utilizar servidores proxy y directivas de red, e implementar Traceflow.

Para obtener más información sobre Antrea, consulte los siguientes recursos:

Para configurar opcionalmente estas funciones en Antrea, quite la marca de comentario y actualice las variables ANTREA_*. Por ejemplo:

#! ---------------------------------------------------------------------
#! Antrea CNI configuration
#! ---------------------------------------------------------------------

ANTREA_NO_SNAT: true
ANTREA_NODEPORTLOCAL: true
ANTREA_NODEPORTLOCAL_ENABLED: true
ANTREA_NODEPORTLOCAL_PORTRANGE: 61000-62000
ANTREA_TRAFFIC_ENCAP_MODE: "encap"
ANTREA_PROXY: true
ANTREA_PROXY_ALL: true
ANTREA_PROXY_LOAD_BALANCER_IPS: false
ANTREA_PROXY_NODEPORT_ADDRS:
ANTREA_PROXY_SKIP_SERVICES: ""
ANTREA_POLICY: true
ANTREA_TRACEFLOW: true
ANTREA_DISABLE_UDP_TUNNEL_OFFLOAD: false
ANTREA_ENABLE_USAGE_REPORTING: false
ANTREA_EGRESS: true
ANTREA_EGRESS_EXCEPT_CIDRS: ""
ANTREA_FLOWEXPORTER: false
ANTREA_FLOWEXPORTER_COLLECTOR_ADDRESS: "flow-aggregator.flow-aggregator.svc:4739:tls"
ANTREA_FLOWEXPORTER_POLL_INTERVAL: "5s"
ANTREA_FLOWEXPORTER_ACTIVE_TIMEOUT: "5s"
ANTREA_FLOWEXPORTER_IDLE_TIMEOUT: "15s"
ANTREA_IPAM: false
ANTREA_KUBE_APISERVER_OVERRIDE: ""
ANTREA_MULTICAST: false
ANTREA_MULTICAST_INTERFACES: ""
ANTREA_NETWORKPOLICY_STATS: true
ANTREA_SERVICE_EXTERNALIP: true
ANTREA_TRAFFIC_ENCRYPTION_MODE: none
ANTREA_TRANSPORT_INTERFACE: ""
ANTREA_TRANSPORT_INTERFACE_CIDRS: ""

Ejecute el comando tanzu mc create

Después de crear o actualizar el archivo de configuración del clúster y de descargar el archivo BOM (lista de materiales) más reciente, puede implementar un clúster de administración ejecutando el comando tanzu mc create --file CONFIG-FILE, donde CONFIG-FILE es el nombre del archivo de configuración. Si el archivo de configuración es el predeterminado ~/.config/tanzu/tkg/cluster-config.yaml, puede omitir la opción --file. Si desea revisar el manifiesto de Kubernetes que aplicará el comando tanzu mc create, también puede utilizar la marca --dry-run para imprimir el manifiesto sin realizar cambios. Esta invocación seguirá ejecutando las comprobaciones de validación que se describen a continuación antes de generar el manifiesto de Kubernetes.

Precaución

El comando tanzu mc create tarda en completarse. Mientras se ejecuta tanzu mc create, no ejecute invocaciones adicionales de tanzu mc create en la misma máquina de arranque para implementar varios clústeres de administración, cambiar el contexto o editar ~/.kube-tkg/config.

Para implementar un clúster de administración, ejecute el comando tanzu mc create. Por ejemplo:

tanzu mc create --file path/to/cluster-config-file.yaml

Varias zonas de disponibilidad en vSphere: Para ejecutar el clúster de administración o sus clústeres de carga de trabajo en varias zonas de disponibilidad, ya sea ahora o más adelante, incluya la opción --az-file con el archivo vsphere-zones.yaml descrito en Crear los objetos FailureDomain y DeploymentZone en Kubernetes:

tanzu mc create --file path/to/cluster-config-file.yaml --az-file path/to/vsphere-zones.yaml
  • (Solo vSphere) Después de implementar un clúster de administración en vSphere, debe configurar las direcciones IP de sus nodos de plano de control para que sean estáticas, como se describe en Configurar reservas de DHCP para el plano de control (solo vSphere) en Crear y administrar clústeres de carga de trabajo de TKG 2.2 con la CLI de Tanzu.

Comprobaciones de validación

Al ejecutar tanzu mc create, el comando realiza varias comprobaciones de validación antes de implementar el clúster de administración. Las comprobaciones varían en función de la infraestructura en la que se va a implementar el clúster de administración.

vSphere
El comando verifica que la infraestructura del vSphere de destino cumpla los siguientes requisitos:
  • Las credenciales de vSphere que proporcionó son válidas.
  • Los nodos cumplen los requisitos de tamaño mínimo.
  • La plantilla de imagen base existe en vSphere y es válida para la versión de Kubernetes especificada.
  • Los recursos necesarios, incluidos el grupo de recursos, los almacenes de datos y la carpeta, existen en vSphere.

Validación de varias zonas de disponibilidad: Si va a implementar el clúster de administración que define los recursos FailureDomains y DeploymentZones, como se describe en Crear los objetos FailureDomain y DeploymentZone en Kubernetes y, a continuación, va a hacer referencia a ellos con la opción --az-file en el comando tanzu mc create, el proceso de creación del clúster realiza de forma predeterminada las siguientes comprobaciones adicionales:

* All vSphere zones and regions referenced in `VSphereFailureDomain`, `VSphereDeploymentZone`, and related Kubernetes objects exist in vSphere, are accessible, and have host groups, VM groups, and tags that also exist.
* Tag categories for the tags exist in vSphere and are logically consistent.
* vSphere AZ/zone and region configurations are logically consistent.
* `MATCHING_LABELS` configuration settings correspond to labels in the `VSphereDeploymentZone` objects.
* Zones referenced in Kubernetes are at the same level in vSphere.
* ResourcePools and Folders referenced in the `VSphereDeploymentZone` resources exist in vSphere.

Para evitar que el proceso de creación del clúster compruebe que las zonas y las regiones de vSphere especificadas en la configuración existen, son coherentes y están definidas en el mismo nivel, establezca SKIP_MULTI_AZ_VERIFY en "true" en el entorno local:

```
export SKIP_MULTI_AZ_VERIFY="true"
```

No puede establecer esta variable en el archivo de configuración del clúster.

Un escenario típico para usar SKIP_MULTI_AZ_VERIFY es cuando se implementa un clúster de administración independiente que se utilizará para crear clústeres de carga de trabajo que se ejecuten en varias zonas de disponibilidad en el futuro, pero los recursos de vSphere para las zonas de disponibilidad del clúster de carga de trabajo aún no se han configurado.

AWS
El comando verifica que la infraestructura de AWS de destino cumpla los siguientes requisitos:
  • Las credenciales de AWS que proporcionó son válidas.
  • La pila de Cloud Formation existe.
  • Se admite el tipo de instancia de nodo.
  • La región y la zona de disponibilidad coinciden.
Azure
El comando verifica que la infraestructura de Azure de destino cumpla los siguientes requisitos:
  • Las credenciales de Azure que proporcionó son válidas.
  • La clave SSH pública está codificada en formato base64.
  • Se admite el tipo de instancia de nodo.

Si no se cumple alguna de estas condiciones, se produce un error en el comando tanzu mc create.

Supervisar el progreso

Al ejecutar tanzu mc create, puede seguir el progreso de la implementación del clúster de administración en el terminal. La primera ejecución de tanzu mc create tarda más que las ejecuciones posteriores porque debe extraer las imágenes de Docker necesarias en el almacén de imágenes de la máquina de arranque. Las ejecuciones posteriores no requieren este paso, por lo que son más rápidas.

Si se produce un error en tanzu mc create antes de que se implemente el clúster de administración, debe limpiar los artefactos en la máquina de arranque antes de volver a ejecutar tanzu mc create. Consulte el tema Solucionar problemas del clúster de administración para obtener más información. Si la máquina en la que ejecuta tanzu mc create se apaga o se reinicia antes de que finalicen las operaciones locales, se producirá un error en la implementación.

Si la implementación se realiza correctamente, verá un mensaje de confirmación en el terminal:

Management cluster created! You can now create your first workload cluster by running tanzu cluster create [name] -f [file]

Qué hacer a continuación

Para obtener información sobre lo que ocurrió durante la implementación del clúster de administración, cómo conectar kubectl al clúster de administración, cómo crear espacios de nombres y cómo registrar el clúster de administración con Tanzu Mission Control, consulte Examinar y registrar un clúster de administración independiente recién implementado.

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