Descripción general de Autopilot

Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

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 de comparación entre Autopilot y Standard) 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.

Estas son algunas de las razones por las que quizás desees 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 limitaciones de Autopilot.
  • Tus cargas de trabajo requieren un procesamiento intensivo. Los clústeres de Autopilot son ideales para ejecutar la mayoría de las cargas de trabajo de producción, pero los clústeres de Standard pueden ser más adecuados para cargas de trabajo de procesamiento intensivo que requieren plataformas de procesamiento de alto rendimiento.

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

Autopilot te permite solicitar recursos de almacenamiento efímero, memoria y CPU para tus cargas de trabajo. Los rangos permitidos dependen de si deseas ejecutar los Pods en la plataforma de procesamiento predeterminada de uso general o en una clase de procesamiento. Para obtener información sobre las solicitudes de recursos de contenedor predeterminadas y los rangos de recursos permitidos, consulta Solicitudes de recursos en Autopilot.

Limitaciones y restricciones de cargas de trabajo en Autopilot

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"

En la versión 1.21 de GKE y versiones posteriores, la capacidad "SYS_PTRACE" también es compatible con las cargas de trabajo.

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.

También puedes usar selectores de nodos y afinidad de nodos para los siguientes fines:

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.

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.

Limitaciones de seguridad en Autopilot

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 de Kubernetes no es compatible con los clústeres de Autopilot. En las versiones de GKE anteriores a la 1.21, tampoco se admiten OPA Gatekeeper y Policy Controller.

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 impedir el acceso no deseado a la máquina virtual del nodo. Aceptamos las presentaciones para ese fin 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 VRP de Google.

Por su diseño, los usuarios privilegiados, como los administradores de clústeres, tienen el control total de cualquier clúster de GKE. Como práctica recomendada de seguridad, recomendamos que evites otorgar privilegios potentes de GKE/Kubernetes y, en su lugar, uses la delegación de administrador de espacio de nombres siempre que sea posible, como se describe en nuestra guía de 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 en Autopilot

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.

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

No puedes realizar cambios en los nodos de Autopilot, como cambios en el tipo de máquina subyacente, si tus cargas de trabajo tienen requisitos de procesamiento específicos.

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 SSH en los nodos

Como ya no aprovisionas ni administras los nodos en Autopilot, no hay acceso SSH a los nodos. 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.

Aún puedes conectarte de forma remota a los contenedores en ejecución mediante la funcionalidad exec de Kubernetes a fin de ejecutar comandos en los contenedores para la depuración, incluida la conexión a una shell interactiva, por ejemplo, con kubectl exec -it deploy/YOUR_DEPLOYMENT -- sh.

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.

Registro de puertos en serie

Los clústeres de Autopilot requieren que se habilite el registro de puertos en serie para depurar y solucionar problemas de tus nodos. Si tu organización de Google Cloud tiene una política de la organización que aplica la restricción compute.disableSerialPortLogging, es posible que los nodos nuevos no aprovisionen.

Pídele al administrador de políticas de la organización que quite esta restricción en los proyectos con clústeres de Autopilot.

Limitaciones de webhooks

En la versión 1.21 de GKE y versiones posteriores, también puedes crear webhooks de admisión dinámicos de mutación. Sin embargo, Autopilot modifica los objetos de webhooks de mutación para agregar un selector de espacios de nombres que excluya los recursos de los espacios de nombres administrados (p. ej., kube-system). Además, se rechazarán los webhooks que especifiquen uno o más de los siguientes recursos (y cualquiera de sus subrecursos) en las reglas:

- group: ""
  resource: nodes
- group: ""
  resource: persistentvolumes
- group: certificates.k8s.io
  resource: certificatesigningrequests
- group: authentication.k8s.io
  resource: tokenreviews

No puedes usar el token *, que representa todos los valores, en el campo resources ni groups para permitir los recursos anteriores.

Limitación de la actuación en nombre de usuarios

La versión 1.22.4-gke.1501 y posteriores de GKE admiten la actuación en nombre de usuarios para todos los usuarios y grupos definidos por el usuario. No se puede actuar en nombre de los usuarios y grupos del sistema, como el usuario kube-apiserver y el grupo system:masters.

No hay aplicaciones de Google Cloud Marketplace

No puedes instalar apps de Cloud Marketplace en clústeres de Autopilot.

Soluciona problemas

Para ver los pasos para solucionar problemas, consulta Soluciona problemas de clústeres de Autopilot.

¿Qué sigue?