A lo largo de los años, los 300 millones de usuarios de Pinterest han creado más de 200 mil millones de pines en más de 4 mil millones de tableros. Para servir a este ejército de usuarios y a esta vasta base de contenidos, el portal ha desarrollado miles de servicios, que van desde microservicios que pueden ser manejados por unas pocas CPU hasta monolitos gigantes que se ejecutan en una flota completa de máquinas virtuales. Y luego llegó el momento en que los ojos de la empresa se posaron en los k8. ¿Por qué el “cubo” quedó bien en Pinterest? Aprenderá sobre esto en nuestra traducción de un artículo reciente de .
Entonces, cientos de millones de usuarios y cientos de miles de millones de pines. Para servir a este ejército de usuarios y a esta vasta base de contenido, hemos desarrollado miles de servicios, que van desde microservicios que pueden ser manejados por unas pocas CPU hasta monolitos gigantes que se ejecutan en flotas enteras de máquinas virtuales. Además, tenemos una variedad de marcos que también pueden requerir acceso a CPU, memoria o E/S.
Para mantener este zoológico de herramientas, el equipo de desarrollo enfrenta una serie de desafíos:
- No existe una forma uniforme para que los ingenieros ejecuten un entorno de producción. Los servicios sin estado, los servicios con estado y los proyectos en desarrollo activo se basan en pilas de tecnología completamente diferentes. Esto llevó a la creación de un curso completo de formación para ingenieros y también complica seriamente el trabajo de nuestro equipo de infraestructura.
- Los desarrolladores con su propia flota de máquinas virtuales crean una carga enorme para los administradores internos. Como resultado, operaciones tan simples como actualizar el sistema operativo o la AMI llevan semanas y meses. Esto conduce a una mayor carga de trabajo en situaciones aparentemente absolutamente cotidianas.
- Dificultades para crear herramientas de gestión de infraestructura global además de las soluciones existentes. La situación se complica aún más por el hecho de que no es fácil encontrar a los propietarios de las máquinas virtuales. Es decir, no sabemos si esta capacidad se puede extraer de manera segura para operar en otras partes de nuestra infraestructura.
Los sistemas de orquestación de contenedores son una forma de unificar la gestión de cargas de trabajo. Abren la puerta a una mayor velocidad de desarrollo y simplifican la gestión de la infraestructura, ya que todos los recursos involucrados en el proyecto son gestionados por un sistema centralizado.
Figura 1: Prioridades de infraestructura (confiabilidad, productividad de los desarrolladores y eficiencia).
El equipo de Cloud Management Platform de Pinterest descubrió los K8 en 2017. Para la primera mitad de 2017, habíamos documentado la mayoría de nuestras capacidades de producción, incluida la API y todos nuestros servidores web. Posteriormente, llevamos a cabo una evaluación exhaustiva de varios sistemas para orquestar soluciones de contenedores, crear clústeres y trabajar con ellos. A finales de 2017, decidimos utilizar Kubernetes. Era bastante flexible y tenía un amplio apoyo en la comunidad de desarrolladores.
Hasta la fecha, hemos creado nuestras propias herramientas de arranque de clúster basadas en Kops y hemos migrado componentes de infraestructura existentes, como redes, seguridad, métricas, registros, gestión de identidades y tráfico a Kubernetes. También implementamos un sistema de modelado de cargas de trabajo para nuestro recurso, cuya complejidad está oculta a los desarrolladores. Ahora estamos enfocados en asegurar la estabilidad del cluster, escalarlo y conectar nuevos clientes.
Kubernetes: el estilo Pinterest
Comenzar a utilizar Kubernetes a la escala de Pinterest como una plataforma que a nuestros ingenieros les encantaría supuso muchos desafíos.
Como gran empresa, hemos invertido mucho en herramientas de infraestructura. Los ejemplos incluyen herramientas de seguridad que manejan el procesamiento de certificados y la distribución de claves, componentes de control de tráfico, sistemas de descubrimiento de servicios, componentes de visibilidad y componentes de envío de registros y métricas. Todo esto se recopiló por una razón: seguimos el camino normal de prueba y error y, por lo tanto, queríamos integrar todo este equipo en la nueva infraestructura de Kubernetes en lugar de reinventar la vieja rueda en una nueva plataforma. En general, este enfoque simplificó la migración, ya que todo el soporte de la aplicación ya existe y no es necesario crearlo desde cero.
Por otro lado, los modelos de previsión de carga en el propio Kubernetes (como implementaciones, trabajos y conjuntos de demonios) no son suficientes para nuestro proyecto. Estos problemas de usabilidad son enormes barreras para migrar a Kubernetes. Por ejemplo, hemos escuchado a los desarrolladores de servicios quejarse de configuraciones de inicio de sesión faltantes o incorrectas. También encontramos un uso incorrecto de los motores de plantillas, cuando se crearon cientos de copias con la misma especificación y tarea, lo que resultó en problemas de depuración de pesadilla.
También era muy difícil mantener diferentes versiones en el mismo clúster. Imagine la complejidad de la atención al cliente si necesita trabajar simultáneamente en varias versiones del mismo entorno de ejecución, con todos sus problemas, errores y actualizaciones.
Controladores y propiedades de usuario de Pinterest
Para facilitar a nuestros ingenieros la implementación de Kubernetes y simplificar y acelerar nuestra infraestructura, hemos desarrollado nuestras propias definiciones de recursos personalizadas (CRD).
Los CRD proporcionan la siguiente funcionalidad:
- Combinando diferentes recursos nativos de Kubernetes para que funcionen como una única carga de trabajo. Por ejemplo, el recurso PinterestService incluye una implementación, un servicio de inicio de sesión y un mapa de configuración. Esto permite a los desarrolladores no preocuparse por configurar DNS.
- Implementar el soporte necesario para las aplicaciones. El usuario debe centrarse únicamente en la especificación del contenedor de acuerdo con su lógica empresarial, mientras que el controlador CRD implementa todos los contenedores de inicio, variables de entorno y especificaciones de pod necesarios. Esto proporciona un nivel de comodidad fundamentalmente diferente para los desarrolladores.
- Los controladores CRD también gestionan el ciclo de vida de los recursos nativos y mejoran la disponibilidad de depuración. Esto incluye conciliar las especificaciones deseadas y reales, actualizar el estado de CRD y mantener registros de eventos, y más. Sin CRD, los desarrolladores se verían obligados a gestionar múltiples recursos, lo que sólo aumentaría la probabilidad de error.
A continuación se muestra un ejemplo de un PinterestService y un recurso interno administrado por nuestro controlador:
Como puede ver arriba, para admitir un contenedor personalizado necesitamos integrar un contenedor de inicio y varios complementos para brindar seguridad, visibilidad y tráfico de red. Además, creamos plantillas de mapas de configuración e implementamos soporte para plantillas de PVC para trabajos por lotes, así como seguimiento de múltiples variables de entorno para rastrear identidad, consumo de recursos y recolección de basura.
Es difícil imaginar que los desarrolladores quieran escribir estos archivos de configuración a mano sin soporte CRD, y mucho menos mantener y depurar las configuraciones.
Flujo de trabajo de implementación de aplicaciones
La imagen de arriba muestra cómo implementar un recurso personalizado de Pinterest en un clúster de Kubernetes:
- Los desarrolladores interactúan con nuestro clúster de Kubernetes a través de la CLI y la interfaz de usuario.
- Las herramientas CLI/UI recuperan los archivos YAML de configuración del flujo de trabajo y otras propiedades de compilación (misma ID de versión) de Artifactory y luego los envían al Servicio de envío de trabajos. Este paso garantiza que solo se entreguen versiones de producción al clúster.
- JSS es una puerta de enlace para varias plataformas, incluido Kubernetes. Aquí se autentica al usuario, se emiten cuotas y se comprueba parcialmente la configuración de nuestro CRD.
- Después de verificar el CRD en el lado JSS, la información se envía a la API de la plataforma k8s.
- Nuestro controlador CRD monitorea eventos en todos los recursos del usuario. Convierte los CR en recursos nativos de k8, agrega los módulos necesarios, establece las variables de entorno apropiadas y realiza otros trabajos de soporte para garantizar que las aplicaciones de usuario en contenedores tengan suficiente soporte de infraestructura.
- Luego, el controlador CRD pasa los datos recibidos a la API de Kubernetes para que el programador pueda procesarlos y ponerlos en producción.
Nota: Este flujo de trabajo previo al lanzamiento de la implementación se creó para los primeros usuarios de la nueva plataforma k8s. Actualmente estamos en el proceso de perfeccionar este proceso para integrarlo completamente con nuestro nuevo CI/CD. Esto significa que no podemos contarte todo lo relacionado con Kubernetes. Esperamos compartir nuestra experiencia y el progreso del equipo en esta dirección en nuestra próxima publicación de blog, "Construcción de una plataforma CI/CD para Pinterest".
Tipos de recursos especiales
Según las necesidades específicas de Pinterest, hemos desarrollado los siguientes CRD para adaptarse a diferentes flujos de trabajo:
- PinterestService son servicios sin estado que se han estado ejecutando durante mucho tiempo. Muchos de nuestros sistemas principales se basan en un conjunto de dichos servicios.
- PinterestJobSet modela trabajos por lotes de ciclo completo. Un escenario común en Pinterest es que varios trabajos ejecutan los mismos contenedores en paralelo, independientemente de otros procesos similares.
- PinterestCronJob se usa ampliamente junto con pequeñas cargas periódicas. Este es un contenedor para el trabajo cron nativo con mecanismos de soporte de Pinterest que son responsables de la seguridad, el tráfico, los registros y las métricas.
- PinterestDaemon incluye demonios de infraestructura. Esta familia continúa creciendo a medida que agregamos más apoyo a nuestros grupos.
- PinterestTrainingJob se extiende a los procesos de Tensorflow y Pytorch, proporcionando el mismo nivel de soporte de tiempo de ejecución que todos los demás CRD. Dado que Pinterest utiliza activamente Tensorflow y otros sistemas de aprendizaje automático, teníamos una razón para crear un CRD separado en torno a ellos.
También estamos trabajando en PinterestStatefulSet, que pronto se adaptará para almacenes de datos y otros sistemas con estado.
Soporte de tiempo de ejecución
Cuando un pod de aplicaciones se ejecuta en Kubernetes, recibe automáticamente un certificado para identificarse. Este certificado se utiliza para acceder al almacenamiento secreto o para comunicarse con otros servicios a través de mTLS. Mientras tanto, Container Init Configurator y Daemon descargarán todas las dependencias necesarias antes de ejecutar la aplicación en contenedor. Cuando todo esté listo, el sidecar de tráfico y Daemon registrarán la dirección IP del módulo con nuestro Zookeeper para que los clientes puedan descubrirlo. Todo esto funcionará porque el módulo de red se configuró antes de iniciar la aplicación.
Los anteriores son ejemplos típicos de soporte de tiempo de ejecución para cargas de trabajo. Otros tipos de cargas de trabajo pueden requerir un soporte ligeramente diferente, pero todas vienen en forma de sidecars a nivel de pod, demonios a nivel de nodo o de máquina virtual. Nos aseguramos de que todo esto se implemente dentro de la infraestructura de administración y sea consistente en todas las aplicaciones, lo que en última instancia reduce significativamente la carga en términos de trabajo técnico y soporte al cliente.
Pruebas y control de calidad
Construimos un proceso de prueba de extremo a extremo sobre la infraestructura de prueba de Kubernetes existente. Estas pruebas se aplican a todos nuestros clusters. Nuestro proceso pasó por muchas revisiones antes de convertirse en parte del grupo de productos.
Además de probar los sistemas, contamos con sistemas de monitoreo y alerta que monitorean constantemente el estado de los componentes del sistema, el consumo de recursos y otros indicadores importantes, notificándonos solo cuando es necesaria la intervención humana.
Alternativas
Analizamos algunas alternativas a los recursos personalizados, como controladores de acceso por mutación y sistemas de plantillas. Sin embargo, todos ellos conllevan importantes desafíos operativos, por lo que elegimos la ruta CRD.
Se utilizó un controlador de admisión mutacional para introducir sidecars, variables de entorno y otro soporte de tiempo de ejecución. Sin embargo, enfrentó varios problemas, como la vinculación de recursos y la gestión del ciclo de vida, donde tales problemas no surgen en CRD.
Nota: Los sistemas de plantillas, como los gráficos Helm, también se utilizan ampliamente para ejecutar aplicaciones con configuraciones similares. Sin embargo, nuestras aplicaciones de trabajo son demasiado diversas para gestionarlas mediante plantillas. Además, durante la implementación continua habrá demasiados errores al utilizar plantillas.
Próximos trabajos
Actualmente estamos lidiando con una carga mixta en todos nuestros clústeres. Para soportar este tipo de procesos de diferentes tipos y tamaños, trabajamos en las siguientes áreas:
- Una colección de clústeres distribuye aplicaciones grandes en diferentes clústeres para lograr escalabilidad y estabilidad.
- Garantizar la estabilidad, escalabilidad y visibilidad del clúster para crear conectividad de aplicaciones y acuerdos de nivel de servicio.
- Gestionar recursos y cuotas para que las aplicaciones no entren en conflicto entre sí y la escala del clúster esté controlada por nuestra parte.
- Una nueva plataforma CI/CD para soportar e implementar aplicaciones en Kubernetes.
Fuente: habr.com