El nuevo modo GKE es más caro y menos flexible, pero más sencillo y seguro

GKE Autopilot administra los pods por usted



Se conocen bien dos cosas sobre los clústeres de Kubernetes. La primera es que es absolutamente la mejor herramienta para la tarea de misión crítica de la orquestación de contenedores. Y segundo, su complejidad es una barrera para la implementación y una causa común de errores. Incluso Google, el inventor y principal promotor de Kubernetes, lo admite.



Para simplificar la implementación y la administración de clústeres, la empresa ha proporcionado a todos los clientes de GKE acceso al servicio de piloto automático , que Google ha utilizado durante mucho tiempo en sus propios clústeres de Borg . Es la configuración automática de recursos basada en el aprendizaje automático.



"A pesar de 6 años de progreso, Kubernetes sigue siendo increíblemente complejo " , dijo a The Register Drew Bradstock, jefe de producto de Google Kubernetes Engine (GKE). "En los últimos años, hemos visto a muchas empresas adoptar Kubernetes, pero luego se encuentran con dificultades".



GKE es una plataforma de Kubernetes que se ejecuta principalmente en Google Cloud Platform (GCP). También está disponible en otras nubes o localmente como parte de Anthos .



Piloto automático - nuevo modo de funcionamientoGKE, está más automatizado y preconfigurado para reducir los costos operativos para la administración de clústeres, optimizar los clústeres para producción y alta disponibilidad.





Al usar Autopilot en la propia infraestructura de Google, el



Kubernetes de origen tiene los conceptos de clústeres (una colección de servidores físicos o virtuales), nodos (servidores individuales), pods (un bloque de control que representa uno o más contenedores en un nodo) y los propios contenedores. GKE está completamente administrado a nivel de clúster. Autopilot extiende esto a nodos y pods.



La forma más fácil de comprender las características y limitaciones de Autopilot es a partir de la descripción del sistema.... Tenga en cuenta los parámetros "preconfigurados" que no se pueden modificar.





Básicamente, esta es otra forma de reservar y administrar los recursos de GKE que sacrifica la flexibilidad por la conveniencia. Dado que Google administra la mayor parte de la configuración, garantiza un mayor tiempo de actividad del 99,9% para los módulos de piloto automático con varias zonas (consulte SLA ).



En la nube de Google, las regiones se componen de tres o más zonas. Colocar todos los recursos en una zona es menos confiable que en varias zonas, y la expansión en varias regiones brinda la máxima tolerancia a fallas. Los clústeres en el piloto automático siempre se distribuyen por regiones, no por zonas: es más confiable, pero más costoso.



Otra limitación de Autopilot es el sistema operativo Linux preinstalado con Containerd, "optimizado para contenedores". No hay forma de usar Linux con Docker o Windows Server. La cantidad máxima de pods por nodo es 32, no 110 como en el GKE estándar.



No hay acceso SSH a los nodos, los nodos del piloto automático están bloqueados. La compatibilidad con GPU y TPU (Tensor Processing Unit) no está disponible, aunque está prevista para el futuro. “Dejar SSH fue una decisión difícil”, dice Bradstock. Por supuesto, esto limita las opciones de control. Pero Bradstock dijo que la decisión se basó en una investigación que mostró una alta tasa de errores críticos en la configuración del clúster.

Dinero

El modelo de precios también es diferente aquí. No se le cobra por las instancias informáticas (máquinas virtuales), sino por el uso real de la CPU, la memoria y el almacenamiento de todos los pods. Más $ 0.10 por hora por clúster en Autopilot, al igual que GKE estándar.



La pregunta obvia es qué será más caro, un clúster estándar o un piloto automático. La respuesta no es fácil. Dado que este es de alguna manera un servicio premium, Autopilot es más costoso que una implementación estándar de GKE cuidadosamente optimizada. "Hay una prima sobre un GKE normal", dijo Bradstock, "porque brindamos no solo funcionalidad, sino también soporte completo de SRE (Ingeniería de confiabilidad del sitio) y garantías de SLA".



Sin embargo, el piloto automático puede ser más económico que una implementación de GKE configurada incorrectamente que no está completamente cargada porque es difícil evaluar la especificación correcta para las instancias de procesamiento. Función de asignación acumulativa (CDF) de memoria no utilizada y máquinas ocupadas para 5000 tareas después de activar el piloto automático en la propia infraestructura de Google, fuente Reducción de errores de memoria (OOM) y uso compartido de memoria no utilizada para 500 tareas después de activar el piloto automático en la infraestructura de Google, fuente















¿Por qué no usar Cloud Run, que ejecuta cargas de trabajo de contenedores sin ninguna configuración de clúster, nodo o pod, incluso en GKE? "Cloud Run es un gran entorno para los desarrolladores, una aplicación puede pasar de cero a 1000 instancias y volver a cero, para eso están las nubes", explica Bradstock. "Autopilot facilita la vida a las personas que quieren usar Kubernetes, quieren ver y controlar todo, quieren usar scripts de terceros, quieren construir su propia plataforma".



Un problema definitivo es la compatibilidad con los complementos existentes con herramientas de terceros para Kubernetes. Algunos de ellos aún no son compatibles con Autopilot, pero otros ya están funcionando, como el monitoreo de Datadog. Los DaemonSets también son compatibles; muchas herramientas utilizan esta función para ejecutar demonios en todos los nodos.



La configuración para el almacenamiento, la computación y las redes ha obligado a eliminar cierto nivel de flexibilidad y algunas integraciones: “Pero definitivamente queremos que se ejecute un ecosistema de terceros en [Autopilot]”, dice Bradstock.



Con el lanzamiento de Autopilot, se amplía la gama de opciones sobre cómo ejecutar Kubernetes en la nube de Google. La compensación no solo es un mayor costo y menos flexibilidad, sino también una posible desorientación de los Devops en las fábricas. Sin embargo, la lógica principal es que es mejor que las empresas se concentren en su actividad principal en lugar de en los servicios que presta el contratista.



La ingeniería de Google tiene una reputación mucho mejor que el servicio al cliente. El desarrollador Kevin Lin describió recientemente cómo es el esquema de bonificación de inicio de AWS y Google.



Google demostró ser una organización lenta e ineficaz que terminó remitiendo al cliente a un socio externo. “La primera conversación fue todo sobre cuánto dinero planeo gastar en Google (en lugar de llamar a Amazon donde querían ayudarme a poner el servicio en funcionamiento). Google Cloud tiene una ergonomía realmente buena e ingenieros de clase mundial, pero una reputación terrible en el servicio al cliente ”, dijo.



Esta es una prueba más de que los buenos ingenieros no son el único factor importante a la hora de elegir una nube.