Descripción general de Autopilot


Introducción

Autopilot es un nuevo modo de operación en Google Kubernetes Engine (GKE) diseñado para reducir el costo operativo de la administración de clústeres, optimizarlos en producción y obtener una mayor disponibilidad de cargas de trabajo. El modo de operación se refiere al nivel de flexibilidad, responsabilidad y control que tienes sobre tu clúster. Además de los beneficios de un plano de control completamente administrado y las automatizaciones de nodos, GKE ofrece dos modos de operación:

  • Autopilot: GKE aprovisiona y administra la infraestructura subyacente del clúster, incluidos los nodos y grupos de nodos, lo que te brinda un clúster optimizado con una experiencia práctica.
  • Estándar: Tú administras la infraestructura subyacente del clúster, lo que te brinda flexibilidad para configurar el nodo.

Gracias a Autopilot, ya no tienes que supervisar el estado de los nodos ni calcular la capacidad de procesamiento que necesitan tus cargas de trabajo. Autopilot admite la mayoría de las API y herramientas de Kubernetes y su ecosistema completo. Permaneces dentro de GKE sin tener que interactuar con las API, las CLI o la IU de Compute Engine, ya que los nodos no son accesibles a través de Compute Engine, como lo son en el modo estándar. Solo pagas por la CPU, la memoria y el almacenamiento que tus Pods solicitan mientras se ejecutan.

Los clústeres de Autopilot están preconfigurados con una configuración de clúster optimizada que está lista para las cargas de trabajo de producción. Esta configuración optimizada sigue las prácticas recomendadas y las recomendaciones de GKE para la seguridad y la configuración de clústeres y cargas de trabajo. Algunas de estas configuraciones integradas (que se detallan en la tabla a continuación) son inmutables y otros ajustes opcionales se pueden activar o desactivar.

Autopilot viene con un ANS que cubre el plano de control y los Pods. Con Autopilot, a medida que se abstrae la infraestructura subyacente, puedes enfocarte en la API de Kubernetes y tus implementaciones. Autopilot usa los requisitos de recursos que defines en PodSpec y aprovisiona los recursos para la implementación, como CPU, memoria y discos persistentes.

Existen dos motivos principales por los que podrías preferir usar el modo de operación estándar en lugar de Autopilot:

  • Necesitas un nivel de control más alto sobre la configuración de tu clúster.
  • Tus clústeres deben ejecutar cargas de trabajo que no cumplen con las restricciones de Autopilot.

Comparación de los modos Autopilot y estándar

Con Autopilot, GKE administra varias complejidades del ciclo de vida de tu clúster. En la siguiente tabla, se muestran las opciones disponibles según el modo de operación del clúster:

  • Preconfigurado: Esta configuración está incorporada y no puedes cambiarla.
  • Predeterminado: Esta configuración está activada, pero puedes anularla.
  • Opcional: Esta configuración está desactivada, pero puedes activarla.
Opciones Modo Autopilot Modo estándar
Tipo de clúster básico Disponibilidad y versión:

Preconfigurado: Regional
Predeterminada: Canal de versiones regular
Disponibilidad y versión:

Opcional:
Nodos y grupos de nodos Administrado por GKE Administrado, configurado y especificado por ti.
Aprovisionamiento de recursos GKE aprovisiona los recursos de forma dinámica en función de la especificación de tu Pod. Tú aprovisionas manualmente recursos adicionales y estableces el tamaño general del clúster. Configura el ajuste de escala automático del clúster y el aprovisionamiento automático de nodos para ayudar a automatizar el proceso
Tipo de imagen Preconfigurado: Container-Optimized OS con Containerd Elige una de las siguientes opciones:
Facturación Pago por solicitudes de recursos de pod (CPU, memoria y almacenamiento efímero) Pago por nodo (CPU, memoria, disco de arranque)
Seguridad Preconfigurado:
Opcional:
Redes Preconfigurado:
Predeterminado:
  • Clúster público
  • Rangos CIDR automáticos
  • Nombre de la red/subred
Opcional:
Opcional:
Actualizaciones, reparaciones y mantenimiento Preconfigurado:
Opcional:
Credenciales de autenticación Preconfigurado: Workload Identity Opcional:
Escalamiento Preconfigurado: Autopilot controla todos los escalamientos y la configuración de los nodos.

Predeterminado:
Opcional:
Supervisa y registra Preconfigurado: Operaciones de la nube para GKE

Predeterminado: Registro del sistema y de las cargas de trabajo

Opcional: Registro solo del sistema
Predeterminado:
Opcional: Registro solo del sistema
Enrutamiento Preconfigurado: enrutamiento basado en Pods. Grupos de extremos de red (NEG) habilitados. Elige el enrutamiento de paquetes basado en nodos (predeterminado) o el enrutamiento basado en Pods.
Complementos del clúster Preconfigurado:
Predeterminado:
Opcional:

1Se requiere una configuración adicional para habilitar Cloud NAT en un clúster.

Características de clúster no compatibles

Las siguientes características de clúster de GKE no son compatibles con los clústeres de Autopilot:

Instancias de Compute Engine

Seguridad

Integraciones y complementos

Escalamiento

Autopilot escala automáticamente los recursos del clúster en función de las especificaciones de tu Pod para que puedas enfocarte en ellos. Para aumentar o disminuir de forma automática el número de pods, puedes implementar el ajuste de escala automático horizontal de pod con las métricas de CPU o memoria estándares de Kubernetes, o con métricas personalizadas a través de Cloud Monitoring.

Rangos de recursos permitidos

En la tabla siguiente, se enumeran los rangos de recursos permitidos para los Pods de Autopilot. Todos los valores se aplican a la suma de todas las solicitudes de recursos de contenedor en el Pod, a menos que se indique lo contrario. La CPU virtual del pod está disponible en incrementos de 0.25  PU virtuales. Además de los valores mínimos, la proporción de CPU:memoria debe estar en el rango de 1 CPU virtual:1 GiB a 1 CPU virtual:6.5 GiB. Se escalarán verticalmente los recursos fuera de los rangos de proporción permitidos. Para obtener más información, consulta la administración de rangos y recursos y los ejemplos de limitación de recursos.

Recurso Recursos mínimos Recursos máximos
Pods normales Pods de DaemonSet Todos los pods
CPU 250 mCPU 10 mCPU 28 CPU virtuales2
Memoria 512 MiB 10 MiB 80 GiB2
Almacenamiento efímero 10 MiB (por contenedor) 10 MiB (por contenedor) 10 GiB

2El límite máximo de CPU y memoria para los Pods normales se reduce aún más por la suma total de las solicitudes de recursos de todos los Pods de DaemonSet.

Solicitudes predeterminadas de recursos de contenedor

Autopilot se basa en lo que especificas en la configuración de la implementación para aprovisionar recursos. Si no especificas las solicitudes de recursos para ningún contenedor en el Pod, Autopilot aplica valores predeterminados. Estos valores predeterminados están diseñados para otorgar a los contenedores en tus Pods una cantidad promedio de recursos, lo que es adecuado para muchas cargas de trabajo más pequeñas.

Autopilot aplica estos valores predeterminados a los recursos que no están definidos en la especificación de pod.

Recurso Contenedores en pods normales Contenedores en DaemonSets
CPU 500 mCPU 50 mCPU
Memoria 2 GiB 100 MiB
Almacenamiento efímero 1 GiB 100 MiB

Para obtener más información sobre los límites del clúster de Autopilot, consulta Cuotas y límites.

Limitaciones y restricciones de las cargas de trabajo

Autopilot admite la mayoría de las cargas de trabajo que ejecutan tus aplicaciones. A fin de que GKE ofrezca la administración de los nodos y te brinde una experiencia operativa más optimizada, existen algunas restricciones y limitaciones cuando se compara con GKE Standard. Algunas de estas limitaciones son recomendaciones de seguridad, mientras que otras permiten que los clústeres de Autopilot se administren de forma segura. Las limitaciones de las cargas de trabajo se aplican a todos los Pods, incluidos los que se ejecutan mediante Deployment, DaemonSets, ReplicaSets, ReplicationControllers, StatefulSets, Jobs y CronJobs.

Restricciones para las opciones de host

No se permiten hostPort y hostNetwork porque GKE administra la administración de nodos. El uso de volúmenes hostPath en modo de escritura está prohibido, mientras que el uso de volúmenes de hostPath en modo de lectura solo se permite para los prefijos de ruta de acceso /var/log/. Se prohíbe usar espacios de nombres de host en las cargas de trabajo.

Limitaciones de las cargas de trabajo de Linux

Autopilot solo admite las siguientes capacidades de Linux para las cargas de trabajo:

"SETPCAP", "MKNOD", "AUDIT_WRITE", "CHOWN", "DAC_OVERRIDE", "FOWNER",
"FSETID", "KILL", "SETGID", "SETUID", "NET_BIND_SERVICE", "SYS_CHROOT", "SETFCAP"

Selectores de nodos y afinidad de nodos

Las topologías de afinidad zonal son compatibles. El uso de la afinidad de nodo y los selectores de nodos está limitado a las siguientes claves: topology.kubernetes.io/region, topology.kubernetes.io/zone, failure-domain.beta.kubernetes.io/region, failure-domain.beta.kubernetes.io/zone, cloud.google.com/gke-os-distribution, kubernetes.io/os y kubernetes.io/arch. No todos los valores del SO y de la arquitectura son compatibles con Autopilot.

Sin detección de amenazas a contenedores

Autopilot no admite la detección de amenazas a contenedores.

Sin Pods privilegiados

El modo privilegiado para los contenedores en las cargas de trabajo se usa principalmente a fin de realizar cambios en los nodos, como cambiar la configuración de kubelet o de la red. Con los clústeres Autopilot, no se permiten los cambios de nodo, por lo que no se permite este tipo de Pods. Esta restricción puede afectar a algunas cargas de trabajo de administración.

Afinidad y antiafinidad de Pods

Aunque GKE administra tus nodos por ti en Autopilot, conservas la capacidad de programar tus Pods. El piloto automático admite la afinidad de Pods, para que puedas colocar fácilmente los Pods en un solo nodo a fin de aumentar la eficiencia de la red. Por ejemplo, puedes usar la afinidad de Pods para implementar Pods de frontend en nodos con Pods de backend. La afinidad de Pods está limitada al uso con las siguientes claves: topology.kubernetes.io/region, topology.kubernetes.io/zone, failure-domain.beta.kubernetes.io/region y failure-domain.beta.kubernetes.io/zone.

Autopilot también admite la antiafinidad, de modo que puedas distribuir los Pods entre los nodos para evitar puntos únicos de fallo. Por ejemplo, puedes usar la antiafinidad del Pod para evitar que los Pods de frontend estén ubicados junto con los Pods de backend.

Valores predeterminados y limitaciones de recursos cuando se usa antiafinidad de Pods

Autopilot admite la antiafinidad de Pods, para evitar que dos Pods se ubiquen en el mismo nodo. Cuando se usa la antiafinidad, Autopilot debe asignar recursos de procesamiento adicionales para garantizar una separación adecuada de Pods, como lo define PodSpec. Cuando se usa la antiafinidad de Pods, aumentan los límites predeterminados y los límites de recursos mínimos. Para todos los contenedores que se enumeran en el PodSpec:

Recurso Valor predeterminado
CPU 0.75 CPU virtual
Memoria 2 GiB
Almacenamiento efímero 1 GiB

Cuando se usa la antiafinidad de Pods, se aplican las mismas reglas de limitación de recursos y lógica, pero con incrementos de CPU virtuales más altos. La CPU virtual de Pod se ofrece en un mínimo de 0.5 CPU virtuales y incrementos de 0.5 CPU virtuales (redondeado al incremento más cercano). Por ejemplo, si solicitas 0.66 CPU virtuales en total (entre todos tus contenedores con antiafinidad), tu PodSpec se modifica durante la admisión y se establece en 1 CPU virtual. Tu Pod tiene acceso completo al recurso más alto, con el recurso adicional dividido entre las solicitudes de recursos de todos los contenedores.

Las tolerancias solo son compatibles con la separación de cargas de trabajo

Las tolerancias solo son compatibles con la separación de las cargas de trabajo. Los taints se agregan automáticamente mediante el aprovisionamiento automático de nodos según sea necesario.

Administración de proporciones y rangos de recursos

  • Aumentos de CPU virtuales del Pod: la CPU virtual del Pod está disponible en incrementos de 0.25 CPU virtuales (redondeado). Por ejemplo, si solicitas 0.66 CPU virtuales en total (entre todos tus contenedores), el PodSpec se modifica durante la admisión y se establece en 0.75. Tu Pod tiene acceso completo al recurso más alto, con el recurso adicional dividido entre las solicitudes de recursos de todos los contenedores. El valor mínimo es 250 millicores de CPU (mCPU). La CPU virtual de DaemonSet se ofrece en incrementos de 10 mCPU (redondeados al incremento más cercano).

  • Rango de proporción de memoria y CPU: la proporción de memoria (en GiB) que se debe incluir en la CPU virtual debe estar entre 1 y 6.5 CPU virtuales. Por ejemplo, puedes tener un Pod con 1 CPU virtual y 1 GiB de memoria, o 1 CPU virtual y 6.5 GiB de memoria, pero no 1 CPU virtual y 7 GiB de memoria. Para entregar la solicitud de recursos, GKE escala verticalmente el recurso que sea demasiado bajo. Por ejemplo, si solicitas 1 CPU virtual y 7 GiB de memoria, tu PodSpec se modifica a 1.25 CPU virtuales y 7 GiB de memoria en la admisión. Del mismo modo, si solicitas 1 CPU virtual y 800 MiB de memoria, tu PodSpec se modifica a 1 CPU virtual y 1 GiB de RAM, con el recurso adicional dividido entre los contenedores.

Los requisitos de incremento y proporción de CPU y memoria, y el potencial escalamiento vertical de las solicitudes de recursos se calculan una vez que se aplican los valores predeterminados a los contenedores con solicitudes de recursos faltantes.

Los contenedores sin solicitudes de recursos tendrán, de manera predeterminada, los valores mínimos estándar de 500 mCPU y 1 GiB de memoria. Para la CPU y la memoria, cuando GKE escala una solicitud de recursos verticalmente (por ejemplo, para cumplir con el requisito mínimo o el requisito de proporción), el recurso adicional se asigna de manera uniforme entre contenedores. Los valores redondeados se distribuyen de forma proporcional entre los contenedores. Por ejemplo, un contenedor con el doble de memoria que los otros contenedores recibirá el doble de memoria adicional.

  • Almacenamiento efímero: el rango disponible es de entre 10 MiB y 10 GiB. Esto afecta a la capa de escritura del contenedor y a las activaciones emptyDir.

El almacenamiento efímero tiene una solicitud mínima por contenedor, por lo que si las solicitudes de almacenamiento efímeras para un contenedor son inferiores al mínimo, Autopilot aumenta la solicitud al mínimo. El almacenamiento efímero no tiene una solicitud mínima por Pod. El almacenamiento efímero tiene una solicitud máxima por Pod, que es acumulativa en todos los contenedores. Si el valor acumulativo es mayor que el máximo, Autopilot refleja la solicitud al máximo al mismo tiempo que garantiza que la proporción de solicitudes entre contenedores sea la misma.

Ejemplos de limitación de recursos

Ejemplo 1: Para un solo contenedor con < 250 mCPU, como mínimo:

Cantidad de contenedores Solicitudes de recursos originales Solicitudes modificadas
1 CPU: 180 mCPU
Memoria: 0.5 GiB
Almacenamiento efímero: 10 MiB
CPU: 250 mCPU
Memoria: 0.5 GiB
Almacenamiento efímero: 10 MiB
Total de recursos del Pod CPU: 250 mCPU
Memoria: 0.5 GiB
Almacenamiento efímero: 10 MiB

Ejemplo 2: Para varios contenedores con un total de < 250 mCPU, como mínimo, Autopilot distribuye el resto de los recursos (hasta 250 CPU virtuales) de manera uniforme entre todos los contenedores del pod.

Cantidad de contenedores Solicitudes de recursos originales Solicitudes modificadas
1 CPU: 70 mCPU
Memoria: 0.5 GiB
Almacenamiento efímero: 10 MiB
CPU: 84 mCPU
Memoria: 0.5 GiB
Almacenamiento efímero: 10 MiB
2 CPU: 70 mCPU
Memoria: 0.5 GiB
Almacenamiento efímero: 10 MiB
CPU: 83 mCPU
Memoria: 0.5 GiB
Almacenamiento efímero: 10 MiB
3 CPU: 70 mCPU
Memoria: 0.5 GiB
Almacenamiento efímero: 10 MiB
CPU: 83 mCPU
Memoria: 0.5 GiB
Almacenamiento efímero: 10 MiB
Total de recursos del Pod CPU: 250 mCPU
Memoria: 1.5 GiB
Almacenamiento efímero: 30 MiB

Ejemplo 3: En el caso de varios contenedores con recursos totales >= 250 mCPU, la CPU se redondea a múltiplos de 250 mCPU y la CPU adicional se distribuye en todos los contenedores según la proporción de sus solicitudes originales. En este ejemplo, la CPU acumulada original es de 320 mCPU y se modifica en un total de 500 mCPU. La capacidad de 180 mCPU adicionales se distribuye entre los contenedores:

Cantidad de contenedores Solicitudes de recursos originales Solicitudes modificadas
1 CPU: 170 mCPU
Memoria: 0.5 GiB
Almacenamiento efímero: 10 MiB
CPU: 266 mCPU
Memoria: 0.5 GiB
Almacenamiento efímero: 10 MiB
2 CPU: 80 mCPU
Memoria: 0.5 GiB
Almacenamiento efímero: 10 MiB
CPU: 125 mCPU
Memoria: 0.5 GiB
Almacenamiento efímero: 10 MiB
3 CPU: 70 mCPU
Memoria: 0.5 GiB
Almacenamiento efímero: 10 MiB
CPU: 109 mCPU
Memoria: 0.5 GiB
Almacenamiento efímero: 10 MiB
4 Contenedor init, recursos no definidos Recibirá recursos del Pod
Total de recursos del Pod CPU: 500 mCPU
Memoria: 1.5 GiB
Almacenamiento efímero: 30 MiB

Ejemplo 4: Para un solo contenedor en el que la CPU es demasiado baja para la cantidad de memoria (1 CPU virtual:6.5 GiB como máximo) La proporción máxima permitida de CPU a memoria es 1:6.5. Si la proporción es mayor que eso, la solicitud de CPU se incrementa y, luego, se redondea, si es necesario:

Cantidad de contenedores Solicitudes de recursos originales Solicitudes modificadas
1 CPU: 250 mCPU
Memoria: 4 GiB
Almacenamiento efímero: 10 MiB
CPU: 750 mCPU
Memoria: 4 GiB
Almacenamiento efímero: 10 MiB
Total de recursos del Pod CPU: 750 mCPU
Memoria: 4 GiB
Almacenamiento efímero: 10 MiB

Ejemplo 5: Para un solo contenedor donde la memoria es demasiado baja para la cantidad de CPU (1 CPU virtual:1 GiB como mínimo). La proporción mínima permitida de CPU y memoria es 1:1. Si la proporción es menor que eso, la solicitud de memoria se incrementa.

Cantidad de contenedores Solicitudes de recursos originales Solicitudes modificadas
1 CPU: 4 vCPU
Memoria: 1 GiB
Almacenamiento efímero: 10 MiB
CPU: 4 vCPU
Memoria: 4 GiB
Almacenamiento efímero: 10 MiB
Total de recursos del Pod CPU: 4 mCPU
Memoria: 4 GiB
Almacenamiento efímero: 10 MiB

Ejemplo 6: Para un solo contenedor con < 250 mCPU como mínimo, en el que, después del ajuste, la CPU es demasiado baja para la cantidad de memoria (1 CPU virtual:6.5 GiB como máximo)

Cantidad de contenedores Solicitudes de recursos originales Solicitudes modificadas
1 CPU: 100 mCPU
Memoria: 50 MiB
Almacenamiento efímero: 10 MiB
CPU: 250 mCPU
Memoria: 256 MiB
Almacenamiento efímero: 10 MiB
Total de recursos del Pod CPU: 250 mCPU
Memoria: 256 MiB
Almacenamiento efímero: 10 MiB

Ejemplo 7: Para un solo contenedor con solicitudes de almacenamiento efímero > 10 GiB, la solicitud de almacenamiento efímero máximo permitido es de 10 GiB. Si la solicitud es mayor que el valor máximo, la solicitud se reduce a 10 GiB.

Cantidad de contenedores Solicitudes de recursos originales Solicitudes modificadas
1 CPU: 250 mCPU
Memoria: 256 MiB
Almacenamiento efímero: 11 GiB
CPU: 250 mCPU
Memoria: 256 MiB
Almacenamiento efímero: 10 GiB
Total de recursos del Pod CPU: 250 mCPU
Memoria: 256 MiB
Almacenamiento efímero: 10 GiB

Ejemplo 8: En el caso de varios contenedores con solicitudes de almacenamiento efímero > 10 GiB, todas las solicitudes de almacenamiento efímero del contenedor se reducen para hacer la solicitud final de almacenamiento acumulativo de 10 GiB.

Cantidad de contenedores Solicitudes de recursos originales Solicitudes modificadas
1 CPU: 250 mCPU
Memoria: 256 MiB
Almacenamiento efímero: 5 GiB
CPU: 250 mCPU
Memoria: 256 MiB
Almacenamiento efímero: 2.94 GiB
2 CPU: 250 mCPU
Memoria: 256 MiB
Almacenamiento efímero: 6 GiB
CPU: 250 mCPU
Memoria: 256 MiB
Almacenamiento efímero: 3.53 GiB
3 CPU: 250 mCPU
Memoria: 256 MiB
Almacenamiento efímero: 6 GiB
CPU: 250 mCPU
Memoria: 256 MiB
Almacenamiento efímero: 3.53 GiB
Total de recursos del Pod CPU: 750 mCPU
Memoria: 768 MiB
Almacenamiento efímero: 10 GiB

Limitaciones de seguridad

Aislamiento del contenedor

Autopilot aplica una configuración endurecida para tus pods que proporciona un aislamiento de seguridad mejorado y ayuda a limitar el impacto de las vulnerabilidades de escape de contenedor en tu clúster:

  • El perfil de seccomp predeterminado del entorno de ejecución del contenedor se aplica de forma predeterminada a todos los Pods en tu clúster.
  • Se elimina el permiso CAP_NET_RAW de contenedor en todos los contenedores. Por lo general, el permiso CAP_NET_RAW no se usa y está sujeto a varias vulnerabilidades de escape de contenedores. La falta de CAP_NET_RAW puede hacer que el uso de ping falle en tu contenedor.
  • Workload Identity se aplica y evita el acceso de los Pods a la cuenta de servicio subyacente de Compute Engine y a otros metadatos de nodos sensibles.
  • Los servicios con spec.ExternalIPs están bloqueados para protegerse contra CVE-2020-8554. Estos servicios se usan poco.
  • Se permiten los siguientes StorageTypes. Otros StorageTypes están bloqueados porque requieren privilegios sobre el nodo:

    "configMap", "csi", "downwardAPI", "emptyDir", "gcePersistentDisk", "hostPath",
    "nfs", "persistentVolumeClaim", "projected", "secret"
    

Políticas de seguridad de Pods

Autopilot aplica la configuración que proporciona aislamiento mejorado para tus contenedores. PodSecurityPolicy, OPA Gatekeeper y Policy Controller de Kubernetes no se admiten en los clústeres de Autopilot.

Límites de seguridad en Autopilot

En la capa de Kubernetes, el modo piloto automático de GKE proporciona la API de Kubernetes, pero quita permisos para usar algunas primitivas de Kubernetes altamente privilegiadas, como los pods privilegiados, con el objetivo de limitar la capacidad de acceder, modificar o controlar directamente la máquina virtual (VM) de los nodos

Estas restricciones se aplican para el modo de piloto automático de GKE a fin de limitar las cargas de trabajo que tienen acceso de bajo nivel a la VM de nodo, a fin de permitir que Google Cloud ofrezca administración completa de nodos y un nivel de pod ANS.

Nuestra intención es prevenir el acceso no deseado a la máquina virtual del nodo. Aceptamos los envíos a ese efecto mediante el Programa de recompensas por detección de vulnerabilidades de Google (VRP) y recompensaremos los informes a discreción del panel de recompensas de Google VRP.

Por su diseño, los usuarios privilegiados, como los administradores del clúster, tienen control total sobre cualquier clúster de GKE. Como práctica recomendada de seguridad, te recomendamos que evites los privilegios potentes de GKE o Kubernetes, y que uses la delegación de administrador del espacio de nombres siempre que sea posible, como se describe en nuestra guía multiusuario.

Las cargas de trabajo en Autopiloto siguen disfrutando de la misma seguridad que el modo estándar de GKE, en el que las VM de usuario único se aprovisionan en el proyecto del usuario para su uso exclusivo. Además, como en el modo estándar, en cada VM individual, las cargas de trabajo automáticas de un clúster pueden ejecutarse juntas en una VM con un kernel de mayor seguridad, pero compartido.

Debido a que el kernel compartido representa un único límite de seguridad, GKE recomienda que, si necesitas un aislamiento eficaz, como cargas de trabajo de alto riesgo o no confiables, las ejecutes en clústeres de GKE Standard con GKE Sandbox para brindar protección de seguridad de varias capas.

Otras limitaciones

Solicitudes de firma de certificados

No puedes crear solicitudes de firma de certificados en Autopilot.

Herramientas de supervisión externas

La mayoría de las herramientas de supervisión externas requieren acceso que está restringido. Las soluciones de varios socios de Google Cloud están disponibles para su uso en Autopilot. Sin embargo, no todas son compatibles, y las herramientas de supervisión personalizadas no se pueden instalar en clústeres de Autopilot.

Servicios externos

Los servicios de IP externa no están permitidos en los clústeres de Autopilot. Para proporcionar una IP externa a un servicio, puedes usar un tipo LoadBalancer de Service o usar un Ingress para agregar el servicio a un servicio externo. IP compartida entre varios servicios.

Contenedores Init

Los contenedores init se ejecutan en serie antes de que se inicien los contenedores de la aplicación. De forma predeterminada, GKE asigna los recursos completos disponibles para el pod a cada contenedor init.

A diferencia de tus otros contenedores, GKE recomienda dejar las solicitudes de recursos no especificadas para los contenedores de inicialización, de modo que los contenedores tengan los recursos completos. Si configuras recursos más bajos, tu contenedor init está restringido de forma innecesaria y, si configuras recursos más altos, es posible que aumente tu factura por el ciclo de vida del pod.

Espacios de nombres administrados

El espacio de nombres kube-system está administrado, lo que significa que no se pueden alterar todos los recursos en este espacio de nombres y no se pueden crear recursos nuevos.

Sin cambios en los nodos

Dado que GKE administra los nodos por ti para los clústeres de Autopilot, no puedes modificar los nodos.

Sin conversión

No se admite la conversión de clústeres estándar al modo de Autopilot y la conversión de clústeres de Autopilot al modo estándar.

Sin conexiones entrantes externas directas para clústeres privados

Los clústeres automáticos con nodos privados no tienen IP externas y no pueden aceptar conexiones entrantes directamente. Si implementas servicios en un NodePort, no puedes acceder a esos servicios desde fuera de la VPC, como desde Internet. Para exponer las aplicaciones de forma externa en los clústeres de Autopilot, usa Servicios. Para obtener más información, consulta Cómo exponer aplicaciones con servicios.

Sin aumentos de actividad de pods

En los clústeres estándar, los pods se pueden configurar para que tengan aumentos de actividad en la capacidad sin usar del nodo. Para los clústeres de Autopilot, dado que todos los pods tienen límites establecidos en las solicitudes, los aumentos de actividad de recursos no son posibles. Es importante garantizar que la especificación de tu pod defina los recursos adecuados para las solicitudes de recursos y no dependa de los aumentos de actividad.

Sin redirección de puertos

Los clústeres de Autopilot no admiten el comando kubectl port-forward.

Sin SSH

Como ya no aprovisionas ni administras los nodos en Autopilot, no hay acceso SSH. GKE maneja todos los aspectos operativos de los nodos, incluido el estado del nodo y todos los componentes de Kubernetes que se ejecutan en los nodos.

Límites de recursos

En un clúster de piloto automático, cada Pod se trata como un Pod de clase QoS garantizado, con límites que son iguales a las solicitudes. Autopilot automáticamente establece límites de recursos iguales a las solicitudes si no especificaste límites de recursos. Si especificas límites de recursos, tus límites se anularán y se establecerán para que sean iguales a las solicitudes.

Limitaciones de webhooks

No puedes crear webhooks de admisión de mutación personalizados para clústeres de Autopilot, pero puedes crear webhooks de validación personalizados.

Soluciona problemas

No se puede crear un clúster: 0 nodos registrados

Cuando creas un clúster de Autopilot, falla con el siguiente error:

All cluster resources were brought up, but: only 0 nodes out of 2 have registered.

Para solucionar el problema, asegúrate de que la cuenta de servicio predeterminada de Compute Engine no esté inhabilitada. Ejecuta el siguiente comando para verificar lo siguiente:

   gcloud iam service-accounts describe SERVICE_ACCOUNT

Reemplaza SERVICE_ACCOUNT por el ID numérico de la cuenta de servicio o la dirección de correo electrónico de la cuenta de servicio (como 123456789876543212345 o my-iam-account@somedomain.com).

¿Qué sigue?