Clúster totalmente privado de EKS

eksctl admite la creación de clústeres totalmente privados que no tienen acceso saliente a Internet y que solo tienen subredes privadas. Los puntos de enlace de VPC se utilizan para permitir el acceso privado a los servicios de AWS.

Esta guía describe cómo crear un clúster privado sin acceso saliente a Internet.

Cómo crear un clúster totalmente privado

El único campo obligatorio para crear un clúster totalmente privado es: privateCluster.enabled

privateCluster:
  enabled: true

Tras la creación del clúster, los comandos eksctl que necesiten acceso al servidor API de Kubernetes deberán ejecutarse desde la VPC del clúster, una VPC interconectada o mediante algún otro medio, como AWS Direct Connect. Los comandos eksctl que necesiten acceso al EKS no APIs funcionarán si se ejecutan desde la VPC del clúster. Para solucionar este problema, cree un punto de enlace de interfaz para que Amazon EKS pueda acceder de forma privada a la administración de Amazon Elastic Kubernetes Service (Amazon EKS APIs ) desde su Amazon Virtual Private Cloud (VPC). En una versión futura, eksctl añadirá soporte para crear este punto final, por lo que no será necesario crearlo manualmente. Los comandos que necesiten acceder a la URL del proveedor de OpenID Connect deberán ejecutarse desde fuera de la VPC del clúster una vez que haya habilitado AWS para PrivateLink Amazon EKS.

La creación de grupos de nodos administrados seguirá funcionando y la creación de grupos de nodos autogestionados funcionará, ya que se necesita acceso al servidor de API a través del punto final de la interfaz EKS si el comando se ejecuta desde la VPC del clúster, una VPC interconectada o mediante algún otro medio, como AWS Direct Connect.

nota

Los puntos finales de VPC se cobran por hora y en función del uso. Puede encontrar más información sobre los precios en los PrivateLink precios de AWS

aviso

No se admiten clústeres totalmente privados. eu-south-1

Configuración del acceso privado a servicios de AWS adicionales

Para permitir que los nodos de trabajo accedan a los servicios de AWS de forma privada, eksctl crea puntos de enlace de VPC para los siguientes servicios:

• Puntos de enlace de interfaz para que ECR (ambos ecr.apiecr.dkr) extraiga imágenes de contenedores (complemento CNI de AWS, etc.)

• Un punto de enlace para que S3 extraiga las capas de imágenes reales

• Un punto final de interfaz para EC2 los requisitos de la aws-cloud-provider integración

• Un punto final de interfaz para que STS admita las funciones de Fargate e IAM para cuentas de servicios (IRSA)

• Un punto final de interfaz para el CloudWatch registro (logs) si CloudWatch el registro está activado

Estos puntos finales de VPC son esenciales para que un clúster privado funcione y, como tal, eksctl no admite su configuración ni desactivación. Sin embargo, es posible que un clúster necesite acceso privado a otros servicios de AWS (por ejemplo, el escalado automático requerido por el escalador automático del clúster). Estos servicios se pueden especificar enprivateCluster.additionalEndpointServices, que indica a eksctl que cree un punto final de VPC para cada uno de ellos.

Por ejemplo, para permitir el acceso privado al escalado automático y al registro: CloudWatch

privateCluster:
  enabled: true
  additionalEndpointServices:
  # For Cluster Autoscaler
  - "autoscaling"
  # CloudWatch logging
  - "logs"

Los puntos finales compatibles additionalEndpointServices sonautoscaling, ycloudformation. logs

Omitir la creación de puntos finales

Si ya se ha creado una VPC con los puntos de enlace de AWS necesarios configurados y vinculados a las subredes descritas en la documentación de EKS, eksctl puede omitir su creación proporcionando la siguiente opción: skipEndpointCreation

privateCluster:
  enabled: true
  skipEndpointCreation: true

Esta configuración no se puede usar junto con. additionalEndpointServices Se omitirá la creación de todos los puntos finales. Además, esta configuración solo se recomienda si la topología de <→ subred del punto final está configurada correctamente. Si los identificadores de subred son correctos, el vpce enrutamiento se configura con direcciones de prefijo y se crean todos los puntos finales de EKS necesarios y se vinculan a la VPC proporcionada. eksctlno alterará ninguno de estos recursos.

Grupos de nodos

En un clúster totalmente privado, solo se admiten grupos de nodos privados (tanto gestionados como autogestionados), ya que la VPC del clúster se crea sin subredes públicas. El privateNetworking campo (y) se debe establecer de forma nodeGroup[].privateNetworking explícitamanagedNodeGroup[. Es un error dejarlo privateNetworking sin configurar en un clúster totalmente privado.

nodeGroups:
- name: ng1
  instanceType: m5.large
  desiredCapacity: 2
  # privateNetworking must be explicitly set for a fully-private cluster
  # Rather than defaulting this field to `true`,
  # we require users to explicitly set it to make the behaviour
  # explicit and avoid confusion.
  privateNetworking: true

managedNodeGroups:
- name: m1
  instanceType: m5.large
  desiredCapacity: 2
  privateNetworking: true

Acceso al punto de enlace del clúster

Un clúster totalmente privado no admite la modificación clusterEndpointAccess durante la creación del clúster. Es un error configurar una clusterEndpoints.publicAccess u otra opciónclusterEndpoints.privateAccess, ya que un clúster totalmente privado solo puede tener acceso privado y permitir la modificación de estos campos puede interrumpir el clúster.

VPC y subredes suministradas por el usuario

eksctl admite la creación de clústeres totalmente privados mediante una VPC y subredes preexistentes. Solo se pueden especificar subredes privadas y es un error especificar subredes en ellas. vpc.subnets.public

eksctl crea puntos de enlace de VPC en la VPC proporcionada y modifica las tablas de enrutamiento de las subredes proporcionadas. Cada subred debe tener asociada una tabla de rutas explícita, ya que eksctl no modifica la tabla de rutas principal.

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: private-cluster
  region: us-west-2

privateCluster:
  enabled: true
  additionalEndpointServices:
  - "autoscaling"

vpc:
  subnets:
    private:
      us-west-2b:
        id: subnet-0818beec303f8419b
      us-west-2c:
        id: subnet-0d42ef09490805e2a
      us-west-2d:
        id: subnet-0da7418077077c5f9


nodeGroups:
- name: ng1
  instanceType: m5.large
  desiredCapacity: 2
  # privateNetworking must be explicitly set for a fully-private cluster
  # Rather than defaulting this field to true for a fully-private cluster, we require users to explicitly set it
  # to make the behaviour explicit and avoid confusion.
  privateNetworking: true

managedNodeGroups:
- name: m1
  instanceType: m5.large
  desiredCapacity: 2
  privateNetworking: true

Administrar un clúster totalmente privado

Para que todos los comandos funcionen después de la creación del clúster, eksctl necesitará acceso privado al punto final del servidor API de EKS y acceso saliente a Internet (para). EKS:DescribeCluster Se admitirán los comandos que no necesiten acceso al servidor API si eksctl tiene acceso saliente a Internet.

Eliminar por la fuerza un clúster totalmente privado

Es probable que se produzcan errores al eliminar un clúster totalmente privado a través de eksctl, ya que eksctl no tiene acceso automático a todos los recursos del clúster. --forceexiste para resolver esto: forzará la eliminación del clúster y continuará cuando se produzcan errores.

Limitaciones

Una limitación de la implementación actual es que eksctl crea inicialmente el clúster con el acceso a los terminales públicos y privados habilitado, y lo deshabilita una vez finalizadas todas las operaciones. Esto es necesario porque eksctl necesita acceso al servidor API de Kubernetes para permitir que los nodos autogestionados se unan al clúster y admitan Fargate. GitOps Una vez finalizadas estas operaciones, eksctl cambia el acceso al punto final del clúster a un acceso exclusivamente privado. Esta actualización adicional significa que la creación de un clúster totalmente privado llevará más tiempo que la de un clúster estándar. En el futuro, eksctl puede cambiar a una función Lambda habilitada para VPC para realizar estas operaciones de API.

Acceso saliente a través de servidores proxy HTTP

eksctl puede comunicarse con la AWS a APIs través de un servidor proxy HTTP (S) configurado, sin embargo, deberá asegurarse de configurar su lista de exclusión de proxy correctamente.

Por lo general, tendrá que asegurarse de que las solicitudes del punto final de la VPC de su clúster no se enruten a través de sus proxies. Para ello, debe configurar una variable de no_proxy entorno adecuada que incluya el valor. .eks.amazonaws.com

Si su servidor proxy realiza una «interceptación de SSL» y utiliza las funciones de IAM para las cuentas de servicio (IRSA), tendrá que asegurarse de omitir explícitamente el SSL para el dominio. Man-in-the-Middle oidc.<region>.amazonaws.com Si no lo hace, eksctl obtendrá una huella digital incorrecta del certificado raíz para el proveedor de OIDC y el complemento CNI para VPC de AWS no se iniciará debido a que no puede obtener las credenciales de IAM, lo que hará que su clúster no funcione.

Más información

• Clústeres privados de EKS