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.
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.
TKG_CUSTOM_IMAGE_REPOSITORY
como una variable de entorno.ImportanteEs 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.
ImportanteEn 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.
t3.large
o t3.xlarge
, consulte Tipos de instancia de Amazon EC2.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.
Si ya creó la pila de CloudFormation para Tanzu Kubernetes Grid en la cuenta de AWS, omita el resto de este procedimiento.
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:
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.
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
.
ImportanteEl comando
tanzu mc permissions aws set
reemplaza la utilidad de línea de comandosclusterawsadm
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 comandoclusterawsadm alpha bootstrap create-stack
. Para Tanzu Kubernetes Grid de v1.2 y clústeres posteriores, utilice la pilatkg-cloud-vmware-com
.
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.
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.
La Referencia de variables del archivo de configuración explica todas las variables que el archivo de configuración puede incluir.
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.
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:
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
.
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:
Configure los ajustes dentro del archivo:
Guarde el archivo.
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.
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.
ENABLE_AUDIT_LOGGING
en false
. Para obtener información sobre el registro de auditoría, consulte Registro de auditoría.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
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
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
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
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.
NotaEn 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
entrue
o bien agregar la dirección IP o el nombre de host vCenter a la lista deTKG_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:
PROTOCOL
: Debe ser http
.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: # ` ^ | / \ ? % ^ { [ ] }" < >
.
FQDN-OR-IP
: Este es el FQDN o la dirección IP del proxy HTTP.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:
PROTOCOL
: Debe ser http
.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: # ` ^ | / \ ? % ^ { [ ] }" < >
.
FQDN-OR-IP
: Este es el FQDN o la dirección IP del proxy HTTPS.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:
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
.
ImportanteSi 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:
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"
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.
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
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:
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.Por ejemplo:
#! ---------------------------------------------------------------------
#! Image repository configuration
#! ---------------------------------------------------------------------
TKG_CUSTOM_IMAGE_REPOSITORY: "custom-image-repository.io/yourproject"
TKG_CUSTOM_IMAGE_REPOSITORY_CA_CERTIFICATE: "LS0t[...]tLS0tLQ=="
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: ""
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ónEl comando
tanzu mc create
tarda en completarse. Mientras se ejecutatanzu mc create
, no ejecute invocaciones adicionales detanzu 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
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.
Si no se cumple alguna de estas condiciones, se produce un error en el comando tanzu mc create
.
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]
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.