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.
# Fully-Private Clúster 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 de 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 a las API de EKS no 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](https://docs.aws.amazon.com/eks/latest/userguide/vpc-interface-endpoints.html) pueda acceder de forma privada a las API de administración de Amazon Elastic Kubernetes Service (Amazon EKS) 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](https://aws.amazon.com/about-aws/whats-new/2022/12/amazon-eks-supports-aws-privatelink/) 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](https://aws.amazon.com/privatelink/pricing/)
**aviso**
Fully-private no se admiten clústeres`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.api``ecr.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
+ La integración requiere un punto final de interfaz para EC2 `aws-cloud-provider`
+ 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 en`privateCluster.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` son`autoscaling`, y`cloudformation`. `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. `eksctl`no alterará ninguno de estos recursos.
## Grupos de nodos
Solo se admiten grupos de nodos privados (tanto administrados como autoadministrados) en un clúster totalmente privado, 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ícita`managedNodeGroup[`. 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ón`clusterEndpoints.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.
## User-supplied VPC y subredes
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.
## Force-delete 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. `--force`existe 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 puntos finales públicos y privados habilitados, y deshabilita el acceso a los puntos finales públicos una vez que se hayan completado 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 VPC-enabled Lambda para realizar estas operaciones de API.
## Acceso saliente a través de servidores proxy HTTP
eksctl puede comunicarse con las API de AWS a 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..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](https://docs.aws.amazon.com/eks/latest/userguide/private-clusters.html)