This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

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.

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.

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