Personalización de nodos administrados con plantillas de lanzamiento

Para obtener el nivel más alto de personalización, puede implementar nodos administrados mediante el uso de su propia plantilla de lanzamiento. El uso de una plantilla de lanzamiento le permite hacer lo siguiente:

• Proporcionar argumentos de arranque en la implementación de un nodo, como argumentos kubelet adicionales.

• Asignar direcciones IP a Pods desde un bloque de CIDR diferente de la dirección IP asignada al nodo.

• Implementar su propia AMI personalizada en los nodos.

• Implementar su propia CNI personalizada en los nodos.

Si proporciona su propia plantilla de lanzamiento al crear por primera vez un grupo de nodos administrado, también tendrá mayor flexibilidad más adelante. Siempre que implemente un grupo de nodos administrado con su propia plantilla de lanzamiento, puede actualizarlo de forma iterativa con una versión diferente de la misma plantilla de lanzamiento. Cuando actualiza el grupo de nodos a una versión diferente de la plantilla de lanzamiento, todos los nodos del grupo se reciclan para que coincidan con la nueva configuración de la versión de la plantilla de lanzamiento especificada.

Los grupos de nodos administrados se implementan siempre con una plantilla de lanzamiento para utilizar con el grupo de Amazon EC2 Auto Scaling. Cuando no proporciona una plantilla de lanzamiento, la API de Amazon EKS crea una en su cuenta de forma automática con los valores predeterminados. Sin embargo, no le recomendamos que modifique las plantillas de lanzamiento generadas automáticamente. Además, los grupos de nodos existentes que no utilizan una plantilla de lanzamiento personalizada no se pueden actualizar directamente. En su lugar, debe crear un nuevo grupo de nodos con una plantilla de lanzamiento personalizada para hacerlo.

Conceptos básicos de configuración de plantillas de lanzamiento

Puede crear una plantilla de lanzamiento de Amazon EC2 Auto Scaling con la AWS Management Console, la AWS CLI o un SDK de AWS. Para obtener más información, consulte Creación de una plantilla de lanzamiento para un grupo de Auto Scaling en la guía del usuario de Amazon EC2 Auto Scaling. Algunas de las opciones de configuración de una plantilla de lanzamiento son similares a las que se utilizan para la configuración de nodos administrados. Al implementar o actualizar un grupo de nodos con una plantilla de lanzamiento, se deben especificar algunas opciones en la configuración del grupo de nodos o en la plantilla de lanzamiento. No especifique un ajuste en ambos lugares. Si existe una configuración donde no debería, las operaciones como la creación o actualización de un grupo de nodos fallarán.

En la siguiente tabla, se enumeran los ajustes prohibidos en una plantilla de lanzamiento. También se enumeran ajustes similares, si hay alguno disponible, que se requieren en la configuración del grupo de nodos administrados. La configuración de la lista es la configuración que aparece en la consola. Pueden tener nombres similares, pero diferentes en la AWS CLI y el SDK.

Plantilla de lanzamiento: opciones prohibidas	Configuración del grupo de nodos de Amazon EKS
Subred en Interfaces de red (Agregar interfaz de red)	Subredes en Configuración de red del grupo de nodos en la página Especificar red
Perfil de instancia de IAM en Detalles avanzados	Rol de IAM del nodo en Configuración del grupo de nodos en la página Configurar grupo de nodos.
Comportamiento de apagado y Detener: comportamiento de hibernación en Detalles avanzados. Mantenga la opción predeterminada No incluir en la configuración de la plantilla de lanzamiento en la plantilla de lanzamiento para ambas configuraciones.	Sin equivalente. Amazon EKS debe controlar el ciclo de vida de la instancia, no el grupo de escalado automático.

En la siguiente tabla, se enumeran los ajustes prohibidos de una configuración de grupo de nodos administrados. También se enumeran configuraciones similares, si hay alguna disponible, que son necesarias en una plantilla de lanzamiento. La configuración de la lista es la configuración que aparece en la consola. Es posible que tengan nombres similares en la AWS CLI y el SDK.

Configuración del grupo de nodos de Amazon EKS: opciones prohibidas	Plantilla de inicialización
(Solo si especificó una AMI personalizada en una plantilla de lanzamiento) Tipo de AMI en Configuración de computación del grupo de nodos en la página Establecer la configuración de informática y escalado: la consola muestra Especificada en la plantilla de lanzamiento y el ID de la AMI que se especificó. Si no se especificó nada en Imágenes de aplicaciones y sistema operativo (Imagen de máquina de Amazon) en la plantilla de lanzamiento, puede seleccionar una AMI en la configuración del grupo de nodos.	Imágenes de aplicaciones y sistema operativo (Imagen de máquina de Amazon) en Contenido de la plantilla de lanzamiento: debe especificar un ID si tiene alguno de los siguientes requisitos: Uso de una AMI personalizada. Si especifica una AMI que no cumple los requisitos enumerados en Especificación de una AMI, la implementación del grupo de nodos producirá un error. Desea facilitar datos de usuario para proporcionar argumentos al archivo bootstrap.sh incluido con una AMI optimizada para Amazon EKS. Puede habilitar sus instancias para asignar un número significativamente mayor de direcciones IP a los Pods, asignar direcciones IP a los Pods de un bloque de CIDR diferente al de la instancia, habilitar el tiempo de ejecución o implementar un clúster privado sin acceso a Internet saliente. Para obtener más información, consulte los temas siguientes: Aumentar la cantidad de direcciones IP disponibles para sus nodos de Amazon EC2 Redes personalizadas para los pods Requisitos del clúster privado Especificación de una AMI
Tamaño del disco en Configuración de computación del grupo de nodos en la página Establecer la configuración de informática y escalado: la consola muestra Especificado en la plantilla de lanzamiento.	Tamaño en Almacenamiento (Volúmenes) (Agregar nuevo volumen). Debe especificarlo en la plantilla de lanzamiento.
Par de claves de SSH en Configuración del grupo de nodos en la página Especificar redes: la consola muestra la clave especificada en la plantilla de lanzamiento o muestra No especificado en la plantilla de lanzamiento.	Nombre del par de claves en Par de claves (inicio de sesión).
No se pueden especificar grupos de seguridad fuente a los que se permita el acceso remoto cuando se utiliza una plantilla de lanzamiento.	Grupos de seguridad en Configuración de red para la instancia o Grupos de seguridad en Interfaces de red (Agregar interfaz de red), pero no ambos. Para obtener más información, consulte Uso de grupos de seguridad personalizados.

nota

• Si implementa un grupo de nodos mediante una plantilla de lanzamiento, especifique un tipo de instancia o ninguno en Contenido de la plantilla de lanzamiento en una plantilla de lanzamiento. Si lo desea, puede especificar entre 0 y 20 tipos de instancia para Tipos de instancias en la página Establecer la configuración de informática y escalado de la consola. O bien, puede hacerlo mediante otras herramientas que utilizan la API de Amazon EKS. Si especifica un tipo de instancia en una plantilla de lanzamiento y utiliza esa plantilla de lanzamiento para implementar el grupo de nodos, no podrá especificar ningún tipo de instancia en la consola ni utilizar otras herramientas que utilicen la API de Amazon EKS. Si no especifica un tipo de instancia en una plantilla de lanzamiento, en la consola o si utiliza otras herramientas que utilizan la API de Amazon EKS, se utiliza el tipo de instancia t3.medium. Si el grupo de nodos utiliza el tipo de capacidad spot, se recomienda especificar varios tipos de instancias mediante la consola. Para obtener más información, consulte Tipos de capacidad de grupo de nodos administrado.

• Si alguno de los contenedores que implementa en el grupo de nodos utiliza el servicio de metadatos de instancia versión 2, asegúrese de establecer la propiedad Límite del salto de respuesta de metadatos en 2 en la plantilla de lanzamiento. Para obtener más información, consulte Metadatos de instancia y datos de usuario en la Guía del usuario de Amazon EC2. Si implementa un grupo de nodos administrado sin utilizar una plantilla de lanzamiento personalizada, este valor se establece automáticamente para el grupo de nodos en la plantilla de lanzamiento predeterminada.

Etiquetado de instancias de Amazon EC2

Puede utilizar el parámetro TagSpecification de una plantilla de lanzamiento para especificar qué etiquetas se aplicarán a las instancias de Amazon EC2 del grupo de nodos. La entidad IAM que llama a las API CreateNodegroup o UpdateNodegroupVersion debe tener permisos para ec2:RunInstances y ec2:CreateTags, y las etiquetas deben agregarse a la plantilla de lanzamiento.

Uso de grupos de seguridad personalizados

Puede utilizar una plantilla de lanzamiento para especificar grupos de seguridad de Amazon EC2 personalizados para aplicar a instancias del grupo de nodos. Esto puede estar en el parámetro de grupos de seguridad de nivel de instancia o como parte de los parámetros de configuración de la interfaz de red. Sin embargo, no se puede crear una plantilla de lanzamiento que especifique el nivel de la instancia y los grupos de seguridad de una interfaz de red. Tenga en cuenta las siguientes condiciones que se aplican al uso de grupos de seguridad personalizados con grupos de nodos administrados:

• Amazon EKS solo permite plantillas de lanzamiento con una única especificación de interfaz de red.

• De forma predeterminada, Amazon EKS aplica el grupo de seguridad de clúster a las instancias del grupo de nodos para facilitar la comunicación entre nodos y el plano de control. Si especifica grupos de seguridad personalizados en la plantilla de lanzamiento mediante cualquiera de las opciones mencionadas anteriormente, Amazon EKS no agrega el grupo de seguridad del clúster. Debe asegurarse de que las reglas entrantes y salientes de los grupos de seguridad habiliten la comunicación con el punto de conexión del clúster. Si las reglas del grupo de seguridad son incorrectas, los nodos de trabajo no pueden unirse al clúster. Para obtener más información acerca de las reglas de los grupos de seguridad, consulte Requisitos y consideraciones sobre grupos de seguridad de Amazon EKS.

• Si necesita acceso SSH a las instancias del grupo de nodos, incluya un grupo de seguridad que permita ese acceso.

Datos de usuario de Amazon EC2

La plantilla de lanzamiento incluye una sección para datos de usuario personalizados. Puede especificar la configuración de su grupo de nodos en esta sección sin crear manualmente AMI personalizadas individuales. Para obtener más información sobre la configuración disponible para Bottlerocket, consulte Utilización de datos de usuario en GitHub.

Puede proporcionar datos de usuario de Amazon EC2 en su plantilla de lanzamiento mediante cloud-init al iniciar sus instancias. Para obtener más información, consulte la documentación de cloud-init. Los datos de usuario se pueden utilizar para realizar operaciones de configuración comunes. Esto incluye las operaciones siguientes:

• Inclusión de usuarios o grupos

• Instalación de paquetes

Los datos de usuario de Amazon EC2 en las plantillas de lanzamiento que se utilizan con grupos de nodos administrados deben estar en el formato de archivo multiparte MIME para las AMI de Amazon Linux y en el formato TOML para las AMI de Bottlerocket. Esto se debe a que los datos de usuario se combinan con los datos de usuario de Amazon EKS necesarios para que los nodos se unan al clúster. No especifique ningún comando en los datos de usuario que inicie o modifique kubelet. Esto se realiza como parte de los datos de usuario fusionados por Amazon EKS. Ciertos parámetros de kubelet, como establecer etiquetas en nodos, se pueden configurar directamente a través de la API de grupos de nodos administrados.

nota

Para obtener más información sobre la personalización de kubelet avanzada, lo que incluye un inicio manual o pasar parámetros de configuración personalizados, consulte Especificación de una AMI. Si se especifica un ID de AMI personalizado en una plantilla de lanzamiento, Amazon EKS no fusiona los datos de usuario.

Los siguientes detalles proporcionan más información sobre la sección de datos de usuario.

Amazon Linux 2 user data

Puede combinar varios bloques de datos de usuario en un único archivo multiparte MIME. Por ejemplo, puede combinar un boothook de nube que configure el daemon de Docker con un script de shell de datos de usuario que instala un paquete personalizado. Un archivo multiparte MIME consta de los siguientes componentes:

• El tipo de contenido y declaración de límite de partes: Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="

• La declaración de versión de MIME: MIME-Version: 1.0

• Uno o más bloques de datos de usuario, que contienen los siguientes componentes:

  • El límite de apertura, que señala el inicio de un bloque de datos de usuario: --==MYBOUNDARY==

  • La declaración de tipo de contenido para el bloque: Content-Type: text/cloud-config; charset="us-ascii". Para obtener más información sobre los tipos de contenido, consulte la documentación de cloud-init.

  • El contenido de los datos de usuario, por ejemplo, una lista de comandos de shell o políticas de cloud-init.

  • El límite de cierre, que señala el final del archivo multiparte MIME: --==MYBOUNDARY==--

  A continuación, se muestra un ejemplo de un archivo multiparte MIME que puede utilizar para crear el suyo propio.

  MIME-Version: 1.0
  Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
  
  --==MYBOUNDARY==
  Content-Type: text/x-shellscript; charset="us-ascii"
  
  #!/bin/bash
  echo "Running custom user data script"
  
  --==MYBOUNDARY==--

Amazon Linux 2023 user data

Amazon Linux 2023 (AL2023) introduce un nuevo proceso de inicialización de nodos nodeadm que utiliza un esquema de configuración YAML. Si utiliza grupos de nodos autoadministrados o una AMI con una plantilla de lanzamiento, ahora tendrá que proporcionar metadatos del clúster adicionales de forma explícita cuando cree un nuevo grupo de nodos. A continuación, se muestra un ejemplo de los parámetros mínimos necesarios, en los que ahora se necesitan apiServerEndpoint, certificateAuthority y el servicio de cidr:

---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  cluster:
    name: my-cluster
    apiServerEndpoint: https://example.com
    certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
    cidr: 10.100.0.0/16

Por lo general, establecerá esta configuración en los datos de usuario, tal y como están o incrustados en un documento MIME de varias partes:

MIME-Version: 1.0 
Content-Type: multipart/mixed; boundary="BOUNDARY"

--BOUNDARY
Content-Type: application/node.eks.aws

---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig spec: [...]

--BOUNDARY--

En AL2, los metadatos de estos parámetros se descubrieron a partir de la llamada a la API DescribeCluster de Amazon EKS. Con AL2023, este comportamiento ha cambiado, ya que la llamada a la API adicional corre el riesgo de limitarse durante los escalados verticales de nodos a gran escala. Este cambio no le afecta si utiliza grupos de nodos administrados sin una plantilla de lanzamiento o si utiliza Karpenter. Para obtener más información sobre certificateAuthority y el servicio de cidr, consulte DescribeCluster en la Referencia de la API de Amazon EKS.

Bottlerocket user data

Bottlerocket estructura los datos de usuario en formato TOML. Puede facilitar datos de usuario para fusionarlos con los datos de usuario proporcionados por Amazon EKS. Por ejemplo, puede especificar un configuración adicional de kubelet.

[settings.kubernetes.system-reserved]
cpu = "10m"
memory = "100Mi"
ephemeral-storage= "1Gi"

Para obtener más información acerca de la configuración admitida, consulte la documentación de Bottlerocket. Puede configurar etiquetas de nodos y taints en los datos de usuario. Sin embargo, recomendamos que las configure en su grupo de nodos. Amazon EKS aplica estas configuraciones cuando lo hace de este modo.

Cuando se fusionan los datos de usuario, el formato no se conserva, pero el contenido sigue siendo el mismo. La configuración que proporciona en los datos de usuario anula cualquier configuración configurada por Amazon EKS. Entonces, si configura settings.kubernetes.max-pods o settings.kubernetes.cluster-dns-ip, estos valores de los datos de usuario se aplican a los nodos.

Amazon EKS no admite todos los TOML válidos. A continuación, se muestra una lista de formatos conocidos no compatibles:

• Comillas dentro de las claves citadas: 'quoted "value"' = "value"

• Comillas escapadas en valores: str = "I'm a string. \"You can quote me\""

• Flotantes y enteros mixtos: numbers = [ 0.1, 0.2, 0.5, 1, 2, 5 ]

• Tipos mixtos en matrices: contributors = ["[e-mail]", { name = "Baz", email = "[e-mail]" }]

• Encabezados entre corchetes con claves citadas: [foo."bar.baz"]

Windows user data

Los datos de usuario de Windows utilizan comandos de PowerShell. Al crear un grupo de nodos administrado, los datos de usuario personalizados se combinan con los datos de usuario administrados de Amazon EKS. Sus comandos de PowerShell son lo primero, seguidos de los comandos de datos de usuario administrados, todo dentro de una etiqueta <powershell></powershell>.

nota

Si no se especifica ningún ID de AMI en la plantilla de lanzamiento, no utilice el script Amazon EKS Bootstrap de Windows en los datos de usuario para configurar Amazon EKS.

Los datos de usuario de ejemplo son los siguientes.

<powershell>
Write-Host "Running custom user data script"
</powershell>

Especificación de una AMI

Si tiene alguno de los siguientes requisitos, especifique un ID de AMI en el campo ImageId de la plantilla de lanzamiento. Seleccione el requisito que tiene para obtener información adicional.

Proporcione datos de usuario a fin de pasar argumentos al archivo bootstrap.sh incluido con una AMI optimizada Linux/Bottlerocket para Amazon EKS

Bootstrapping es un término que se utiliza para describir la adición de comandos que se pueden ejecutar cuando se inicia una instancia. Por ejemplo, el arranque permite usar argumentos kubelet adicionales. Puede pasar los argumentos al script bootstrap.sh mediante eksctl sin especificar una configuración de lanzamiento. O puede hacerlo al especificar la información en la sección de datos de usuario de una plantilla de lanzamiento.

eksctl without specifying a launch template

Cree un archivo denominado my-nodegroup.yaml con el siguiente contenido. Sustituya cada example value con valores propios. Los argumentos --apiserver-endpoint, --b64-cluster-ca y --dns-cluster-ip son opcionales. Sin embargo, definirlos permite que el script bootstrap.sh evite crear una llamada describeCluster. Esto resulta útil en configuraciones de clústeres privados o clústeres en los que los nodos se reducen y escalan horizontalmente con frecuencia. Para obtener más información sobre el script bootstrap.sh, consulte el archivo bootstrap.sh en GitHub.

• El único argumento requerido en el nombre del clúster (my-cluster).

• Para recuperar el ID de una AMI optimizada para ami-1234567890abcdef0, puede utilizar las tablas en las secciones siguientes:

  • Recuperación de los ID de la AMI de Amazon Linux optimizada para Amazon EKS

  • Recuperación de los ID de la AMI de Bottlerocket optimizada para Amazon EKS

  • Recuperación de los ID de la AMI de Windows optimizada para Amazon EKS

• Para recuperar el valor de certificate-authority de su clúster, ejecute el siguiente comando.

  aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code
  

• Para recuperar el api-server-endpoint de su clúster, ejecute el siguiente comando.

  aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code
  

• El valor de --dns-cluster-ip es su servicio de CIDR con .10 al final. Para recuperar el service-cidr de su clúster, ejecute el siguiente comando. Por ejemplo, si el valor devuelto es ipv4 10.100.0.0/16, su valor es 10.100.0.10.

  aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code
  

• En este ejemplo proporciona un argumento kubelet para establecer un valor de max-pods personalizado mediante el script bootstrap.sh incluido con la AMI optimizada para Amazon EKS. El nombre del grupo de nodos no puede tener más de 63 caracteres. Debe empezar por una letra o un dígito, pero también puede incluir guiones y guiones bajos como caracteres no iniciales. Para obtener ayuda con la selección de my-max-pods-value, consulte Número máximo de Pods recomendado por Amazon EKS para cada tipo de instancia de Amazon EC2.

---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: my-cluster
  region: region-code

managedNodeGroups:
  - name: my-nodegroup
    ami: ami-1234567890abcdef0
    instanceType: m5.large
    privateNetworking: true
    disableIMDSv1: true
    labels: { x86-al2-specified-mng }
    overrideBootstrapCommand: |
      #!/bin/bash
      /etc/eks/bootstrap.sh my-cluster \
        --b64-cluster-ca certificate-authority \
        --apiserver-endpoint api-server-endpoint \
        --dns-cluster-ip service-cidr.10 \
        --kubelet-extra-args '--max-pods=my-max-pods-value' \
        --use-max-pods false

Para cada opción de archivo eksctl config disponible, consulte Config file schema (Esquema de archivo de configuración) en la documentación de eksctl. La utilidad eksctl sigue creando una plantilla de lanzamiento para usted y rellena sus datos de usuario con los datos que proporciona en el archivo config.

Cree un grupo de nodos con el siguiente comando.

eksctl create nodegroup --config-file=my-nodegroup.yaml

User data in a launch template

Especifique la siguiente información en la sección de datos de usuario de la plantilla de lanzamiento. Sustituya cada example value con valores propios. Los argumentos --apiserver-endpoint, --b64-cluster-ca y --dns-cluster-ip son opcionales. Sin embargo, definirlos permite que el script bootstrap.sh evite crear una llamada describeCluster. Esto resulta útil en configuraciones de clústeres privados o clústeres en los que los nodos se reducen y escalan horizontalmente con frecuencia. Para obtener más información sobre el script bootstrap.sh, consulte el archivo bootstrap.sh en GitHub.

• El único argumento requerido en el nombre del clúster (my-cluster).

• Para recuperar el valor de certificate-authority de su clúster, ejecute el siguiente comando.

  aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code
  

• Para recuperar el api-server-endpoint de su clúster, ejecute el siguiente comando.

  aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code
  

• El valor de --dns-cluster-ip es su servicio de CIDR con .10 al final. Para recuperar el service-cidr de su clúster, ejecute el siguiente comando. Por ejemplo, si el valor devuelto es ipv4 10.100.0.0/16, su valor es 10.100.0.10.

  aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code
  

• En este ejemplo proporciona un argumento kubelet para establecer un valor de max-pods personalizado mediante el script bootstrap.sh incluido con la AMI optimizada para Amazon EKS. Para obtener ayuda con la selección de my-max-pods-value, consulte Número máximo de Pods recomendado por Amazon EKS para cada tipo de instancia de Amazon EC2.

MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="

--==MYBOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"

#!/bin/bash
set -ex
/etc/eks/bootstrap.sh my-cluster \
  --b64-cluster-ca certificate-authority \
  --apiserver-endpoint api-server-endpoint \
  --dns-cluster-ip service-cidr.10 \
  --kubelet-extra-args '--max-pods=my-max-pods-value' \
  --use-max-pods false

--==MYBOUNDARY==--

Proporcione datos de usuario a fin de pasar argumentos al archivo Start-EKSBootstrap.ps1 incluido con una AMI optimizada Windows para Amazon EKS

Bootstrapping es un término que se utiliza para describir la adición de comandos que se pueden ejecutar cuando se inicia una instancia. Puede pasar los argumentos al script Start-EKSBootstrap.ps1 mediante eksctl sin especificar una configuración de lanzamiento. O puede hacerlo al especificar la información en la sección de datos de usuario de una plantilla de lanzamiento.

Si desea especificar un ID de AMI de Windows personalizado, tenga en cuenta las siguientes consideraciones:

• Debe utilizar una plantilla de lanzamiento y proporcionar los comandos de arranque necesarios en la sección de datos de usuario. Para recuperar el identificador deseado de Windows, puede utilizar la tabla de AMI de Windows optimizadas para Amazon EKS.

• Hay varios límites y condiciones. Por ejemplo, debe agregar eks:kube-proxy-windows a su mapa de configuración de IAM Authenticator de AWS. Para obtener más información, consulte Límites y condiciones al especificar un ID de AMI.

Especifique la siguiente información en la sección de datos de usuario de la plantilla de lanzamiento. Sustituya cada example value con valores propios. Los argumentos -APIServerEndpoint, -Base64ClusterCA y -DNSClusterIP son opcionales. Sin embargo, definirlos permite que el script Start-EKSBootstrap.ps1 evite crear una llamada describeCluster.

• El único argumento requerido en el nombre del clúster (my-cluster).

• Para recuperar el valor de certificate-authority de su clúster, ejecute el siguiente comando.

  aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code
  

• Para recuperar el api-server-endpoint de su clúster, ejecute el siguiente comando.

  aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code
  

• El valor de --dns-cluster-ip es su servicio de CIDR con .10 al final. Para recuperar el service-cidr de su clúster, ejecute el siguiente comando. Por ejemplo, si el valor devuelto es ipv4 10.100.0.0/16, su valor es 10.100.0.10.

  aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code
  

• Para obtener argumentos adicionales, consulte Parámetros de configuración del script de arranque.

  nota

  Si utiliza un CIDR de servicio personalizado, debe especificarlo con el parámetro -ServiceCIDR. De lo contrario, se producirá un error en la resolución de DNS del clúster para Pods.

<powershell>
[string]$EKSBootstrapScriptFile = "$env:ProgramFiles\Amazon\EKS\Start-EKSBootstrap.ps1"
& $EKSBootstrapScriptFile -EKSClusterName my-cluster `
	 -Base64ClusterCA certificate-authority `
	 -APIServerEndpoint api-server-endpoint `
	 -DNSClusterIP service-cidr.10
</powershell>

Ejecute una AMI personalizada debido a requisitos específicos de seguridad, conformidad o políticas internas

Para obtener más información, consulte Imágenes de máquina de Amazon (AMI) en la Guía del usuario de Amazon EC2. La especificación de compilación de la AMI de Amazon EKS contiene recursos y scripts de configuración para crear una AMI personalizada de Amazon EKS basada en Amazon Linux. Para obtener más información, consulte Especificación de compilación de AMI de Amazon EKS en GitHub. Para crear AMI personalizadas instaladas con otros sistemas operativos, consulte AMI personalizadas de ejemplo de Amazon EKS en GitHub.

importante

Al especificar una AMI, Amazon EKS no combina ningún dato de usuario. Más bien, usted es responsable de suministrar el comando bootstrap requerido para que los nodos se unan al clúster. Si los nodos no se unen al clúster, las acciones de Amazon EKS CreateNodegroup y UpdateNodegroupVersion también fallan.

Límites y condiciones al especificar un ID de AMI

A continuación se detallan los límites y las condiciones que implica especificar un ID de AMI con grupos de nodos administrados:

• Debe crear un nuevo grupo de nodos para cambiar entre especificar un ID de AMI en una plantilla de lanzamiento y no especificar un ID de AMI.

• No se le notifica en la consola cuando hay disponible una versión más reciente de AMI. Para actualizar el grupo de nodos a una versión de AMI más reciente, debe crear una nueva versión de la plantilla de lanzamiento con un ID de AMI actualizado. A continuación, debe actualizar el grupo de nodos con la nueva versión de plantilla de lanzamiento.

• Los siguientes campos no se pueden establecer en la API si especifica un ID de AMI:

  • amiType

  • releaseVersion

  • version

• Todas las taints configuradas en la API se aplican de manera asíncrona si se especifica un ID de AMI. Para aplicar taints antes de que un nodo se una al clúster, se deben transferir las taints a kubelet en sus datos de usuario mediante la marca --register-with-taints de la línea de comandos. Para obtener más información, consulte kubelet en la documentación del Kubernetes.

• Al especificar un ID de AMI personalizado para los grupos de nodos administrados de Windows, agregue eks:kube-proxy-windows al mapa de configuración de AWS IAM Authenticator. Esto es necesario para que el DNS funcione correctamente.

  1. Abra el mapa de configuración de IAM Authenticator de AWS para editarlo.

     kubectl edit -n kube-system cm aws-auth
     

  2. Agregue esta entrada a la lista de groups debajo de cada uno de los rolearn asociados con nodos de Windows. El mapa de configuración debería tener un aspecto similar a aws-auth-cm-windows.yaml.

     - eks:kube-proxy-windows

  3. Guarde el archivo y salga del editor de texto.