Configuración del clúster de administración para AWS

Para crear un archivo de configuración de clúster, puede copiar un archivo de configuración existente para una implementación anterior en Amazon Web Services (AWS) y actualizarlo. Si lo prefiere, puede crear un archivo desde cero mediante una plantilla vacía.

Importante
Tanzu Kubernetes Grid v2.4.x es la última versión de TKG que admite la creación de clústeres de administración de TKG independientes en AWS. La capacidad para crear clústeres de administración de TKG independientes en AWS se eliminará en la versión 2.5 de Tanzu Kubernetes Grid.

A partir de ahora, VMware recomienda utilizar Tanzu Mission Control para crear clústeres de AWS EKS nativos en lugar de crear nuevos clústeres de administración de TKG en AWS. Para obtener información sobre cómo crear clústeres nativos de AWS EKS con Tanzu Mission Control, consulte Gestión del ciclo de vida de los clústeres de AWS EKS en la documentación de Tanzu Mission Control.

Para obtener más información, consulte Desuso de la administración de TKG y los clústeres de cargas de trabajo en AWS y Azure en las Notas de la versión de VMware Tanzu Kubernetes Grid v2.4.

Plantilla de configuración del clúster de administración

La siguiente plantilla incluye todas las opciones pertinentes para implementar clústeres de administración en AWS. Puede copiar esta plantilla y utilizarla para implementar clústeres de administración en AWS.

Para obtener información sobre cómo actualizar la configuración común a todas las plataformas de destino, consulte Crear un archivo de configuración del clúster de administración
Para obtener información sobre todas las variables del archivo de configuración, consulte la Referencia de variables del archivo de configuración de la CLI de Tanzu.
Para obtener ejemplos de cómo configurar los ajustes de vSphere, consulte las secciones situadas debajo de la plantilla.

Las opciones obligatorias no están comentadas. Los ajustes opcionales están comentados. Los valores predeterminados se incluyen donde corresponda.

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

CLUSTER_NAME:
CLUSTER_PLAN: dev
INFRASTRUCTURE_PROVIDER: aws
# CLUSTER_API_SERVER_PORT:
ENABLE_CEIP_PARTICIPATION: true
ENABLE_AUDIT_LOGGING: true
CLUSTER_CIDR: 100.96.0.0/11
SERVICE_CIDR: 100.64.0.0/13
# CAPBK_BOOTSTRAP_TOKEN_TTL: 30m

#! ---------------------------------------------------------------------
#! Node configuration
#! AWS-only MACHINE_TYPE settings override cloud-agnostic SIZE settings.
#! ---------------------------------------------------------------------

# SIZE:
# CONTROLPLANE_SIZE:
# WORKER_SIZE:
CONTROL_PLANE_MACHINE_TYPE: t3.large
NODE_MACHINE_TYPE: m5.large
# OS_NAME: ""
# OS_VERSION: ""
# OS_ARCH: ""

#! ---------------------------------------------------------------------
#! AWS configuration
#! ---------------------------------------------------------------------

AWS_REGION:
AWS_NODE_AZ: ""
AWS_ACCESS_KEY_ID:
AWS_SECRET_ACCESS_KEY:
AWS_SSH_KEY_NAME:
BASTION_HOST_ENABLED: true
# AWS_NODE_AZ_1: ""
# AWS_NODE_AZ_2: ""
# AWS_VPC_ID: ""
# AWS_PRIVATE_SUBNET_ID: ""
# AWS_PUBLIC_SUBNET_ID: ""
# AWS_PUBLIC_SUBNET_ID_1: ""
# AWS_PRIVATE_SUBNET_ID_1: ""
# AWS_PUBLIC_SUBNET_ID_2: ""
# AWS_PRIVATE_SUBNET_ID_2: ""
# AWS_PRIVATE_NODE_CIDR: 10.0.0.0/24
# AWS_PUBLIC_NODE_CIDR: 10.0.1.0/24
# AWS_PRIVATE_NODE_CIDR_1: 10.0.2.0/24
# AWS_PUBLIC_NODE_CIDR_1: 10.0.3.0/24
# AWS_PRIVATE_NODE_CIDR_2: 10.0.4.0/24
# AWS_PUBLIC_NODE_CIDR_2: 10.0.5.0/24
# AWS_SECURITY_GROUP_BASTION: sg-12345
# AWS_SECURITY_GROUP_CONTROLPLANE: sg-12346
# AWS_SECURITY_GROUP_APISERVER_LB: sg-12347
# AWS_SECURITY_GROUP_NODE: sg-12348
# AWS_SECURITY_GROUP_LB: sg-12349
# DISABLE_TMC_CLOUD_PERMISSIONS: false # Deactivates IAM permissions required for TMC enablement

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

# TKG_CUSTOM_IMAGE_REPOSITORY: ""
# TKG_CUSTOM_IMAGE_REPOSITORY_CA_CERTIFICATE: ""

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

# TKG_HTTP_PROXY: ""
# TKG_HTTPS_PROXY: ""
# TKG_NO_PROXY: ""

#! ---------------------------------------------------------------------
#! Machine Health Check configuration
#! ---------------------------------------------------------------------

ENABLE_MHC:
ENABLE_MHC_CONTROL_PLANE: true
ENABLE_MHC_WORKER_NODE: true
MHC_UNKNOWN_STATUS_TIMEOUT: 5m
MHC_FALSE_STATUS_TIMEOUT: 12m

#! ---------------------------------------------------------------------
#! Identity management configuration
#! ---------------------------------------------------------------------

IDENTITY_MANAGEMENT_TYPE: "none"

#! Settings for IDENTITY_MANAGEMENT_TYPE: "oidc"
# CERT_DURATION: 2160h
# CERT_RENEW_BEFORE: 360h
# OIDC_IDENTITY_PROVIDER_CLIENT_ID:
# OIDC_IDENTITY_PROVIDER_CLIENT_SECRET:
# OIDC_IDENTITY_PROVIDER_GROUPS_CLAIM: groups
# OIDC_IDENTITY_PROVIDER_ISSUER_URL:
# OIDC_IDENTITY_PROVIDER_SCOPES: "email,profile,groups,offline_access"
# OIDC_IDENTITY_PROVIDER_USERNAME_CLAIM: email

#! The following two variables are used to configure Pinniped JWTAuthenticator for workload clusters
# SUPERVISOR_ISSUER_URL:
# SUPERVISOR_ISSUER_CA_BUNDLE_DATA:

#! Settings for IDENTITY_MANAGEMENT_TYPE: "ldap"
# LDAP_BIND_DN:
# LDAP_BIND_PASSWORD:
# LDAP_HOST:
# LDAP_USER_SEARCH_BASE_DN:
# LDAP_USER_SEARCH_FILTER:
# LDAP_USER_SEARCH_ID_ATTRIBUTE: dn
# LDAP_USER_SEARCH_NAME_ATTRIBUTE:
# LDAP_GROUP_SEARCH_BASE_DN:
# LDAP_GROUP_SEARCH_FILTER:
# LDAP_GROUP_SEARCH_NAME_ATTRIBUTE: dn
# LDAP_GROUP_SEARCH_USER_ATTRIBUTE: dn
# LDAP_ROOT_CA_DATA_B64:

#! ---------------------------------------------------------------------
#! 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_TRANSPORT_INTERFACE: ""
# ANTREA_TRANSPORT_INTERFACE_CIDRS: ""

Configuración de conexión de AWS

Para proporcionar información sobre la cuenta de AWS y la región y la zona de disponibilidad en las que desea implementar el clúster, realice una de las siguientes acciones:

(Recomendado) Configure un perfil de credenciales de AWS con la CLI de AWS y establezca una variable de entorno AWS_PROFILE en el nombre del perfil en la máquina de arranque.

Incluya las credenciales de la cuenta y otra información en el archivo de configuración del clúster. Por ejemplo:

AWS_REGION: eu-west-1
AWS_NODE_AZ: "eu-west-1a"
# Only use AWS_PROFILE OR combination of AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, but not both.
AWS_PROFILE: tkg
# AWS_ACCESS_KEY_ID:  <encoded:QUtJQVQ[...]SU82TTM=>
# AWS_SECRET_ACCESS_KEY: <encoded:eGN4RHJmLzZ[...]SR08yY2ticQ==>
AWS_SSH_KEY_NAME: default
BASTION_HOST_ENABLED: true

Utilice solo AWS_PROFILE o una combinación de AWS_ACCESS_KEY_ID y AWS_SECRET_ACCESS_KEY, pero no ambas.
Los valores de AWS_ACCESS_KEY_ID y AWS_SECRET_ACCESS_KEY deben tener codificación Base64.

Usar un equilibrador de carga interno para el servidor de API

De forma predeterminada, Tanzu Kubernetes Grid on AWS crea un equilibrador de carga público para el servidor de API de Kubernetes del clúster de administración.

Para entornos entorno con acceso a Internet restringido, como con proxy o aire, puede evitar la creación de un equilibrador de carga público estableciendo AWS_LOAD_BALANCER_SCHEME_INTERNAL en true en el archivo de configuración del clúster:

AWS_LOAD_BALANCER_SCHEME_INTERNAL: true

Esta configuración personaliza el equilibrador de carga del clúster de administración para que utilice un esquema interno, lo que significa que no se podrá acceder a su servidor de la API de Kubernetes ni se enrutará a través de Internet.

Configurar tamaños de nodo

La CLI de Tanzu crea los nodos individuales de los clústeres de carga de trabajo de acuerdo con la configuración que se proporciona en el archivo de configuración. En AWS, puede configurar todas las máquinas virtuales de los nodos para que tengan las mismas configuraciones predefinidas, establecer diferentes configuraciones predefinidas para los nodos de trabajo y el plano de control. Con esta configuración, puede crear clústeres de Tanzu Kubernetes que tengan nodos con diferentes configuraciones en los nodos del clúster de administración. También puede crear clústeres en los que los nodos del plano de control y los nodos de trabajo tengan configuraciones diferentes.

Cuando se crea el clúster de administración, los tipos de instancia para las máquinas del nodo se establecen en las opciones CONTROL_PLANE_MACHINE_TYPE y NODE_MACHINE_TYPE. De forma predeterminada, esta configuración también se utiliza para los clústeres de carga de trabajo. La configuración mínima es de 2 CPU y 8 GB de memoria. La lista de tipos de instancia compatibles varía según las diferentes regiones.

CONTROL_PLANE_MACHINE_TYPE: "t3.large"
NODE_MACHINE_TYPE: "m5.large"

Puede anular esta configuración mediante las opciones SIZE CONTROLPLANE_SIZE y WORKER_SIZE. Para crear un clúster de Tanzu Kubernetes en el que todas las máquinas virtuales del plano de control y del nodo de trabajo tengan el mismo tamaño, especifique la variable SIZE. Si establece la variable SIZE, todos los nodos se crearán con la configuración establecida. Para obtener información sobre las configuraciones de los diferentes tamaños de las instancias de nodo para Amazon EC2, consulte Tipos de instancia de Amazon EC2.

SIZE: "t3.large"

Para crear un clúster de carga de trabajo en el que las máquinas virtuales del nodo de trabajo y del plano de control sean de diferentes tamaños, especifique las opciones CONTROLPLANE_SIZE y WORKER_SIZE.

CONTROLPLANE_SIZE: "t3.large"
WORKER_SIZE: "m5.xlarge"

Puede combinar las opciones de CONTROLPLANE_SIZE y WORKER_SIZE con la opción SIZE. Por ejemplo, si especifica SIZE: "t3.large" con WORKER_SIZE: "m5.xlarge", los nodos del plano de control se establecerán en t3.large y los nodos de trabajo se establecerán en m5.xlarge.

SIZE: "t3.large"
WORKER_SIZE: "m5.xlarge"

Configurar VPC

Quite la marca de comentario de las siguientes filas y actualice las siguientes filas para especificar la VPC y otra infraestructura de AWS que alojará y utilizará el clúster de administración independiente

AWS_REGION:
AWS_NODE_AZ:
AWS_PRIVATE_SUBNET_ID:
AWS_PUBLIC_SUBNET_ID:
AWS_SSH_KEY_NAME:
AWS_VPC_ID:
BASTION_HOST_ENABLED:
CONTROL_PLANE_MACHINE_TYPE:
NODE_MACHINE_TYPE:
SERVICE_CIDR:
CLUSTER_CIDR:

Si va a implementar un clúster de administración de producción, quite también la marca de comentario y rellene lo siguiente para los dos nodos de plano de control adicionales:

AWS_NODE_AZ_1:
AWS_NODE_AZ_2:
AWS_PRIVATE_SUBNET_ID_1:
AWS_PRIVATE_SUBNET_ID_2:
AWS_PUBLIC_SUBNET_ID_1:
AWS_PUBLIC_SUBNET_ID_2:

Por ejemplo, la configuración de un clúster de administración de producción en una VPC existente podría tener este aspecto:

AWS_REGION: us-west-2
AWS_NODE_AZ: us-west-2a
AWS_NODE_AZ_1: us-west-2b
AWS_NODE_AZ_2: us-west-2c
AWS_PRIVATE_SUBNET_ID: subnet-ID
AWS_PRIVATE_SUBNET_ID_1: subnet-ID
AWS_PRIVATE_SUBNET_ID_2: subnet-ID
AWS_PUBLIC_SUBNET_ID: subnet-ID
AWS_PUBLIC_SUBNET_ID_1: subnet-ID
AWS_PUBLIC_SUBNET_ID_2: subnet-ID
AWS_SSH_KEY_NAME: tkg
AWS_VPC_ID: vpc-ID
BASTION_HOST_ENABLED: "true"
CONTROL_PLANE_MACHINE_TYPE: m5.large
NODE_MACHINE_TYPE: m5.large
SERVICE_CIDR: 100.64.0.0/13
CLUSTER_CIDR: 100.96.0.0/11

De forma predeterminada, Tanzu Kubernetes Grid crea nuevos grupos de seguridad para conectar el plano de control, los nodos de trabajo y los equilibradores de carga. Si necesita reglas personalizadas, puede aprovisionar previamente los grupos de seguridad, agregar los conjuntos de reglas y configurar clústeres para utilizar los grupos de seguridad personalizados como se describe a continuación.

Configurar grupos de seguridad personalizados

De forma predeterminada, Tanzu Kubernetes Grid crea cinco grupos de seguridad dentro de una VPC.

Para evitar que Tanzu Kubernetes Grid cree nuevos grupos de seguridad y, en su lugar, utilice los existentes y aprovisionados previamente con conjuntos de reglas personalizados, realice lo siguiente:

Cree grupos de seguridad con conjuntos de reglas personalizados que coincidan lo más posible con los conjuntos de reglas predeterminados.
Especifique los grupos de seguridad personalizados en el archivo de configuración del clúster estableciendo variables AWS_SECURITY_GROUP_* en los nombres de los grupos de seguridad. Por ejemplo:
```
AWS_SECURITY_GROUP_BASTION: sg-12345
```

A continuación, se enumeran los cinco grupos de seguridad, sus reglas predeterminadas y sus variables de configuración de clúster correspondientes:

Grupo: CLUSTER-NAME-bastion

Se establece con la variable de configuración del clúster AWS_SECURITY_GROUP_BASTION.

Reglas:

Descripción	Protocolo	Del puerto	Al puerto	Permitir entrada desde	Obligatorio
SSH	TCP	22	22	0.0.0.0/0	No

Grupo: NOMBRE-DE-CLÚSTER-nodo

Se establece con la variable de configuración del clúster AWS_SECURITY_GROUP_NODE.

Reglas:

Descripción	Protocolo	Del puerto	Al puerto	Permitir entrada desde	Obligatorio
SSH	TCP	22	22	Grupo de seguridad <cluster-name>-bastión	No
Servicios de puerto de nodo	TCP	30000	32767	0.0.0.0/0	No (consulte la nota a continuación)
API de Kubelet	TCP	10250	10250	Grupos de seguridad <cluster-name>-controlplane y <cluster-name>-node	Sí
CNI de Antrea	TCP	10349-10351	10349-10351	Grupo de seguridad <cluster-name>-node	Sí
GENEVE	UDP	6081	6081	Grupo de seguridad <cluster-name>-node	Sí

Nota
0.0.0.0/0 solo es de entrada desde la VPC, las VPC emparejadas y cualquier red conectada a través de VPN o DirectConnect. El valor 0.0.0.0/0 no debe interpretarse como accesible por Internet. Es posible cambiar tanto el rango de puertos como la regla de entrada para los servicios del puerto del nodo siempre que sean administradores y no se utilicen para el funcionamiento del clúster.

Grupo: CLUSTER-NAME-controlplane

Se establece con la variable de configuración del clúster AWS_SECURITY_GROUP_CONTROLPLANE.

Reglas:

Descripción	Protocolo	Del puerto	Al puerto	Permitir entrada desde	Obligatorio
SSH	TCP	22	22	Grupo de seguridad <cluster-name>-bastión	No
API de Kubernetes	TCP	6443*	6443*	Grupos de seguridad <cluster-name>-apiserver-lb, <cluster-name>-apiserver-controlplane, y <cluster-name>-apiserver-node	Sí
etcd	TCP	2379	2379	Grupo de seguridad <cluster-name>-controlplane	Sí
etcd igual	TCP	2380	2380	Grupo de seguridad <cluster-name>-controlplane	Sí
addons-manager	TCP	9865	9865	Grupos de seguridad <cluster-name>-controlplane	Sí
kapp-controller	TCP	10100	10100	Grupos de seguridad <cluster-name>-controlplane	Sí

* Si establece CLUSTER_API_SERVER_PORT, reemplace 6443 por el número de puerto que estableció en la variable.

Grupo: CLUSTER-NAME-apiserver-lb

Se establece con la variable de configuración del clúster AWS_SECURITY_GROUP_APISERVER_LB.

Reglas:

Descripción	Protocolo	Del puerto	Al puerto	Permitir entrada desde	Obligatorio
API de Kubernetes	TCP	6443*	6443*	0.0.0.0/0	No (consulte la nota a continuación)

* Si establece CLUSTER_API_SERVER_PORT, reemplace 6443 por el número de puerto que estableció en la variable.

Nota
Se puede acceder a la regla 0.0.0.0/0 de forma predeterminada a través de Internet cuando no se especifica aprovisionar el equilibrador de carga de forma interna. Si el equilibrador de carga es interno, debe ser posible acceder a él desde el clúster de administración (para los clústeres de carga de trabajo) o desde la máquina de arranque (para el clúster de administración). Esta regla se puede bloquear, pero si lo hace, debe agregarse la siguiente regla:

Descripción	Protocolo	Del puerto	Al puerto	Permitir entrada desde	Obligatorio
API de Kubernetes en clúster	TCP	6443*	6443*	Grupos de seguridad <cluster-name>-controlplane y <cluster-name>-node	Sí

* Si establece CLUSTER_API_SERVER_PORT, reemplace 6443 por el número de puerto que estableció en la variable.

Grupo: CLUSTER-NAME-lb

Se establece con la variable de configuración del clúster AWS_SECURITY_GROUP_LB.

Este grupo de seguridad se utiliza para los equilibradores de carga de trabajo. No se agrega ninguna regla a este grupo de seguridad y se espera que los administradores de AWS personalicen el conjunto de reglas según sea necesario para la carga de trabajo de la aplicación.

Qué hacer a continuación

Después de que haya terminado de actualizar el archivo de configuración del clúster de administración, cree el clúster de administración siguiendo las instrucciones de Implementar clúster de administración desde un archivo de configuración.