Configuración de la VPC - Guía del usuario de Eksctl

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Configuración de la VPC

VPC dedicada para clúster

De forma predeterminada, eksctl create cluster creará una VPC dedicada para el clúster. Esto se hace para evitar la interferencia con los recursos existentes por diversas razones, incluida la seguridad, pero también porque es difícil detectar todos los ajustes en una VPC existente.

  • El CIDR de VPC predeterminado que utiliza es. eksctl 192.168.0.0/16

    • Se divide en 8 (/19) subredes (3 privadas, 3 públicas y 2 reservadas).

  • El grupo de nodos inicial se crea en subredes públicas.

  • El acceso SSH está deshabilitado a menos que se especifique. --allow-ssh

  • De forma predeterminada, el grupo de nodos permite el tráfico entrante desde el grupo de seguridad del plano de control en los puertos 1025 a 65535.

nota

En us-east-1 eksctl solo crea 2 subredes públicas y 2 privadas de forma predeterminada.

Cambiar el CIDR de VPC

Si necesitas configurar el emparejamiento con otra VPC, o simplemente necesitas un rango mayor o menor IPs de, puedes --vpc-cidr usar flag para cambiarlo. Consulte los documentos de AWS para obtener guías sobre cómo elegir los bloques de CIDR cuyo uso está permitido en una VPC de AWS.

Si va a crear un IPv6 clúster, puede configurarlo VPC.IPv6Cidr en el archivo de configuración del clúster. Esta configuración solo se encuentra en el archivo de configuración, no en un indicador de CLI.

Si tienes un bloque de direcciones IPv6 IP, también puedes traer tu propio IPv6 grupo. Consulta Cómo importar tu propio grupo de direcciones IP (BYOIP) EC2 en Amazon. A continuación, utilice el archivo VPC.IPv6Cidr de configuración del clúster para configurar Eksctl.

Usa una VPC existente: compartida con kops

Puedes usar la VPC de un clúster de Kubernetes existente gestionado por kops. Esta función se proporciona para facilitar el emparejamiento de clústeres de migración. and/or

Si ya ha creado un clúster con kops, por ejemplo, utilizando comandos similares a estos:

export KOPS_STATE_STORE=s3://kops
kops create cluster cluster-1.k8s.local --zones=us-west-2c,us-west-2b,us-west-2a --networking=weave --yes

Puede crear un clúster de EKS en el mismo AZs mediante las mismas subredes de VPC (NOTA: AZs/subnets se requieren al menos 2):

eksctl create cluster --name=cluster-2 --region=us-west-2 --vpc-from-kops-cluster=cluster-1.k8s.local

Utilizar la VPC existente: otra configuración personalizada

eksctlproporciona cierta flexibilidad, aunque no completa, para topologías de subred y VPC personalizadas.

Puede usar una VPC existente proporcionando subredes and/or públicas privadas mediante los --vpc-private-subnets indicadores y. --vpc-public-subnets Depende de usted asegurarse de que las subredes que utiliza estén clasificadas correctamente, ya que no existe una forma sencilla de comprobar si una subred es realmente privada o pública, ya que las configuraciones varían.

Con estos indicadores, eksctl create cluster determinará el ID de VPC automáticamente, pero no creará tablas de enrutamiento ni otros recursos, como internet/NAT puertas de enlace. Sin embargo, creará grupos de seguridad dedicados para el grupo de nodos inicial y el plano de control.

Debe asegurarse de proporcionar al menos 2 subredes diferentes AZs y EKS comprueba esta condición. Si utilizas una VPC existente, EKS o Eksctl no aplican ni comprueban los siguientes requisitos y EKS crea el clúster. Algunas funciones básicas del clúster funcionan sin estos requisitos. (Por ejemplo, el etiquetado no es estrictamente necesario; las pruebas han demostrado que es posible crear un clúster funcional sin establecer etiquetas en las subredes; sin embargo, no hay garantía de que esto sea siempre válido y se recomienda etiquetar).

Requisitos estándar:

  • todas las subredes dadas deben estar en la misma VPC, dentro del mismo bloque de IPs

  • hay un número suficiente de direcciones IP disponibles, en función de las necesidades

  • número suficiente de subredes (mínimo 2), en función de las necesidades

  • las subredes se etiquetan con al menos lo siguiente:

    • kubernetes.io/cluster/<name>etiqueta establecida en o shared owned

    • kubernetes.io/role/internal-elbetiqueta establecida en 1 para subredes privadas

    • kubernetes.io/role/elbetiqueta establecida en 1 para subredes públicas

  • puertas de enlace and/or NAT de Internet configuradas correctamente

  • las tablas de enrutamiento tienen entradas correctas y la red funciona

  • NUEVO: todas las subredes públicas deben tener la propiedad MapPublicIpOnLaunch habilitada (es decir, Auto-assign public IPv4 address en la consola de AWS). Los grupos de nodos gestionados y Fargate no asignan IPv4 direcciones públicas; la propiedad debe estar configurada en la subred.

Es posible que EKS o Kubernetes impongan otros requisitos, y es responsabilidad tuya cumplir con los requisitos. up-to-date and/or recommendations, and implement those as needed/possible

La configuración predeterminada de los grupos de seguridad aplicada eksctl puede o no ser suficiente para compartir el acceso con los recursos de otros grupos de seguridad. Si desea modificar ingress/egress las reglas de los grupos de seguridad, puede que necesite utilizar otra herramienta para automatizar los cambios o hacerlo mediante una EC2 consola.

En caso de duda, no utilices una VPC personalizada. Si se utiliza eksctl create cluster sin ningún --vpc-* indicador, siempre se configurará el clúster con una VPC dedicada totalmente funcional.

Ejemplos

Cree un clúster mediante una VPC personalizada con 2 subredes privadas y 2 subredes públicas:

eksctl create cluster \
  --vpc-private-subnets=subnet-0ff156e0c4a6d300c,subnet-0426fb4a607393184 \
  --vpc-public-subnets=subnet-0153e560b3129a696,subnet-009fa0199ec203c37

o usa el siguiente archivo de configuración equivalente:

apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: my-test region: us-west-2 vpc: id: "vpc-11111" subnets: private: us-west-2a: id: "subnet-0ff156e0c4a6d300c" us-west-2c: id: "subnet-0426fb4a607393184" public: us-west-2a: id: "subnet-0153e560b3129a696" us-west-2c: id: "subnet-009fa0199ec203c37" nodeGroups: - name: ng-1

Cree un clúster mediante una VPC personalizada con tres subredes privadas y haga que el grupo de nodos inicial utilice esas subredes:

eksctl create cluster \
  --vpc-private-subnets=subnet-0ff156e0c4a6d300c,subnet-0549cdab573695c03,subnet-0426fb4a607393184 \
  --node-private-networking

o usa el siguiente archivo de configuración equivalente:

apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: my-test region: us-west-2 vpc: id: "vpc-11111" subnets: private: us-west-2d: id: "subnet-0ff156e0c4a6d300c" us-west-2c: id: "subnet-0549cdab573695c03" us-west-2a: id: "subnet-0426fb4a607393184" nodeGroups: - name: ng-1 privateNetworking: true

Cree un clúster mediante subredes públicas 4x de una VPC personalizada:

eksctl create cluster \
  --vpc-public-subnets=subnet-0153e560b3129a696,subnet-0cc9c5aebe75083fd,subnet-009fa0199ec203c37,subnet-018fa0176ba320e45
apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: my-test region: us-west-2 vpc: id: "vpc-11111" subnets: public: us-west-2d: id: "subnet-0153e560b3129a696" us-west-2c: id: "subnet-0cc9c5aebe75083fd" us-west-2a: id: "subnet-009fa0199ec203c37" us-west-2b: id: "subnet-018fa0176ba320e45" nodeGroups: - name: ng-1

Puedes encontrar más ejemplos en la carpeta del repositorio: examples

Grupo de seguridad de nodo compartido personalizado

eksctlcreará y gestionará un grupo de seguridad de nodos compartidos que permita la comunicación entre los nodos no gestionados y el plano de control del clúster y los nodos gestionados.

Si, en su lugar, desea proporcionar su propio grupo de seguridad personalizado, puede anular el sharedNodeSecurityGroup campo del archivo de configuración:

vpc: sharedNodeSecurityGroup: sg-0123456789

De forma predeterminada, al crear el clúster, eksctl agregará reglas a este grupo de seguridad para permitir la comunicación hacia y desde el grupo de seguridad del clúster predeterminado que crea EKS. Tanto el plano de control de EKS como los grupos de nodos gestionados utilizan el grupo de seguridad de clúster predeterminado.

Si desea administrar las reglas del grupo de seguridad usted mismo, puede eksctl impedir la creación de las reglas manageSharedNodeSecurityGroupRules configurándolas false en el archivo de configuración:

vpc: sharedNodeSecurityGroup: sg-0123456789 manageSharedNodeSecurityGroupRules: false

Gateway NAT

La puerta de enlace NAT de un clúster se puede configurar para que seaDisable, Single (predeterminada) oHighlyAvailable. La HighlyAvailable opción implementará una puerta de enlace NAT en cada zona de disponibilidad de la región, de modo que si una AZ está inactiva, los nodos de la otra zona AZs podrán seguir comunicándose con Internet.

Se puede especificar mediante el indicador --vpc-nat-mode CLI o en el archivo de configuración del clúster, como se muestra en el siguiente ejemplo:

vpc: nat: gateway: HighlyAvailable # other options: Disable, Single (default)

Consulta el ejemplo completo aquí.

nota

La especificación de la puerta de enlace NAT solo se admite durante la creación del clúster. No se modifica durante la actualización de un clúster.