Ao longo dos anos, os 300 millóns de usuarios de Pinterest crearon máis de 200 millóns de pins en máis de 4 millóns de taboleiros. Para servir a este exército de usuarios e unha ampla base de contidos, o portal desenvolveu miles de servizos, que van desde microservizos que poden ser xestionados por unhas poucas CPU, ata monólitos xigantes que se executan en toda unha flota de máquinas virtuais. E entón chegou o momento no que os ollos da empresa caeron sobre os k8. Por que o "cubo" quedou ben en Pinterest? Aprenderás sobre isto coa nosa tradución dun artigo recente de .
Así, centos de millóns de usuarios e centos de miles de millóns de pinos. Para servir a este exército de usuarios e unha ampla base de contidos, desenvolvemos miles de servizos, que van desde microservizos que poden manexar unhas poucas CPU ata monólitos xigantes que se executan en flotas enteiras de máquinas virtuais. Ademais, temos unha variedade de marcos que tamén poden requirir acceso a CPU, memoria ou E/S.
Ao manter este zoológico de ferramentas, o equipo de desenvolvemento enfróntase a unha serie de desafíos:
- Non existe un xeito uniforme para que os enxeñeiros executen un ambiente de produción. Os servizos sen estado, os servizos con estado e os proxectos en desenvolvemento activo baséanse en pilas de tecnoloxía completamente diferentes. Isto levou á creación de todo un curso de formación para enxeñeiros, e ademais complica seriamente o traballo do noso equipo de infraestruturas.
- Os desenvolvedores coa súa propia flota de máquinas virtuais crean unha enorme carga para os administradores internos. Como resultado, operacións tan sinxelas como actualizar o SO ou a AMI levan semanas e meses. Isto leva a unha maior carga de traballo en situacións aparentemente absolutamente cotiás.
- Dificultades para crear ferramentas globais de xestión de infraestruturas ademais das solucións existentes. A situación complícase aínda máis polo feito de que atopar os propietarios das máquinas virtuais non é doado. É dicir, non sabemos se esta capacidade pode extraerse con seguridade para operar noutras partes da nosa infraestrutura.
Os sistemas de orquestración de contedores son unha forma de unificar a xestión da carga de traballo. Abren a porta a unha maior velocidade de desenvolvemento e simplifican a xestión da infraestrutura, xa que todos os recursos implicados no proxecto son xestionados por un sistema centralizado.
Figura 1: prioridades de infraestrutura (fiabilidade, produtividade dos desenvolvedores e eficiencia).
O equipo de Cloud Management Platform de Pinterest descubriu os K8 en 2017. No primeiro semestre de 2017, documentamos a maioría das nosas capacidades de produción, incluída a API e todos os nosos servidores web. Despois, realizamos unha avaliación exhaustiva de varios sistemas para orquestrar solucións de contedores, construír clusters e traballar con eles. A finais de 2017, decidimos utilizar Kubernetes. Foi bastante flexible e foi amplamente apoiado na comunidade de desenvolvedores.
Ata a data, creamos as nosas propias ferramentas de arranque de clúster baseadas en Kops e migramos os compoñentes da infraestrutura existentes, como redes, seguridade, métricas, rexistro, xestión de identidades e tráfico a Kubernetes. Tamén implementamos un sistema de modelado de carga de traballo para o noso recurso, cuxa complexidade está oculta aos desenvolvedores. Agora centrámonos en garantir a estabilidade do clúster, escalalo e conectar novos clientes.
Kubernetes: The Pinterest Way
Empezar con Kubernetes a escala de Pinterest como unha plataforma que lles encantaría aos nosos enxeñeiros presentaba moitos retos.
Como gran empresa, investimos moito en ferramentas de infraestrutura. Os exemplos inclúen ferramentas de seguridade que xestionan o procesamento de certificados e a distribución de claves, compoñentes de control de tráfico, sistemas de descubrimento de servizos, compoñentes de visibilidade e compoñentes de envío de rexistros e métricas. Todo isto foi recollido por un motivo: percorremos o camiño normal do ensaio e erro e, polo tanto, queriamos integrar todo este equipo na nova infraestrutura de Kubernetes en lugar de reinventar a vella roda nunha nova plataforma. Este enfoque en xeral simplificou a migración, xa que xa existe todo o soporte das aplicacións e non é necesario crear desde cero.
Por outra banda, os modelos de previsión de carga no propio Kubernetes (como despregamentos, traballos e conxuntos de daemon) non son suficientes para o noso proxecto. Estes problemas de usabilidade son grandes barreiras para pasar a Kubernetes. Por exemplo, escoitamos que os desenvolvedores de servizos se queixan de que faltan ou son incorrectas as opcións de inicio de sesión. Tamén atopamos un uso incorrecto dos motores de modelos, cando se crearon centos de copias coa mesma especificación e tarefa, o que provocou problemas de depuración de pesadelo.
Tamén era moi difícil manter diferentes versións no mesmo clúster. Imaxina a complexidade do servizo de atención ao cliente se necesitas traballar simultaneamente en varias versións do mesmo entorno de execución, con todos os seus problemas, erros e actualizacións.
Propiedades e controladores do usuario de Pinterest
Para facilitar aos nosos enxeñeiros a implementación de Kubernetes e para simplificar e acelerar a nosa infraestrutura, desenvolvemos as nosas propias definicións de recursos personalizadas (CRD).
Os CRD proporcionan as seguintes funcións:
- Combinando diferentes recursos nativos de Kubernetes para que funcionen como unha única carga de traballo. Por exemplo, o recurso PinterestService inclúe unha implementación, un servizo de inicio de sesión e un mapa de configuración. Isto permite que os desenvolvedores non se preocupen por configurar o DNS.
- Implementar o soporte necesario para a aplicación. O usuario debe centrarse só na especificación do contedor segundo a súa lóxica de negocio, mentres que o controlador CRD implementa todos os contedores de inicio necesarios, as variables de ambiente e as especificacións do pod. Isto proporciona un nivel de comodidade fundamentalmente diferente para os desenvolvedores.
- Os controladores CRD tamén xestionan o ciclo de vida dos recursos nativos e melloran a dispoñibilidade de depuración. Isto inclúe a conciliación das especificacións desexadas e as reais, a actualización do estado do CRD e o mantemento dos rexistros de eventos e moito máis. Sen CRD, os desenvolvedores veríanse obrigados a xestionar varios recursos, o que só aumentaría a probabilidade de erro.
Aquí tes un exemplo dun servizo Pinterest e dun recurso interno que xestiona o noso controlador:
Como podes ver arriba, para admitir un contedor personalizado necesitamos integrar un contedor de inicio e varios complementos para proporcionar seguridade, visibilidade e tráfico de rede. Ademais, creamos modelos de mapas de configuración e implementamos soporte para modelos de PVC para traballos por lotes, así como o seguimento de varias variables de ambiente para rastrexar a identidade, o consumo de recursos e a recollida de lixo.
É difícil imaxinar que os desenvolvedores queiran escribir estes ficheiros de configuración a man sen o soporte de CRD, e moito menos manter e depurar as configuracións.
Fluxo de traballo de implantación de aplicacións
A imaxe de arriba mostra como implementar un recurso personalizado de Pinterest nun clúster de Kubernetes:
- Os desenvolvedores interactúan co noso clúster de Kubernetes a través da CLI e da interface de usuario.
- As ferramentas CLI/UI recuperan os ficheiros YAML de configuración do fluxo de traballo e outras propiedades de compilación (o mesmo ID de versión) de Artifactory e, a continuación, envíaos ao Servizo de envío de traballos. Este paso garante que só se entreguen ao clúster as versións de produción.
- JSS é unha pasarela para varias plataformas, incluíndo Kubernetes. Aquí autentica o usuario, emítense cotas e compróbase parcialmente a configuración do noso CRD.
- Despois de comprobar o CRD no lado JSS, a información envíase á API da plataforma k8s.
- O noso controlador CRD supervisa os eventos en todos os recursos do usuario. Convértese CR en recursos k8s nativos, engade os módulos necesarios, establece as variables de ambiente adecuadas e realiza outros traballos de soporte para garantir que as aplicacións de usuarios en contenedores teñan suficiente compatibilidade de infraestrutura.
- A continuación, o controlador CRD pasa os datos recibidos á API de Kubernetes para que o programador poida procesalos e poñelos en produción.
Nota: Este fluxo de traballo de prelanzamento do despregamento foi creado para os primeiros usuarios da nova plataforma k8s. Actualmente estamos en proceso de perfeccionar este proceso para integralo totalmente co noso novo CI/CD. Isto significa que non podemos dicirche todo o relacionado con Kubernetes. Agardamos compartir a nosa experiencia e o progreso do equipo nesta dirección na nosa próxima publicación do blog, "Construíndo unha plataforma CI/CD para Pinterest".
Tipos de recursos especiais
En función das necesidades específicas de Pinterest, desenvolvemos os seguintes CRD para adaptarse a diferentes fluxos de traballo:
- PinterestService son servizos sen estado que levan moito tempo funcionando. Moitos dos nosos sistemas principais baséanse nun conxunto deste tipo de servizos.
- PinterestJobSet modela traballos por lotes de ciclo completo. Un escenario común en Pinterest é que varios traballos executan os mesmos contedores en paralelo, independentemente doutros procesos similares.
- PinterestCronJob úsase amplamente xunto con pequenas cargas periódicas. Este é un envoltorio para o traballo cron nativo con mecanismos de soporte de Pinterest que son responsables da seguridade, o tráfico, os rexistros e as métricas.
- PinterestDaemon inclúe daemons de infraestrutura. Esta familia segue crecendo a medida que engadimos máis apoio aos nosos clusters.
- PinterestTrainingJob esténdese aos procesos Tensorflow e Pytorch, proporcionando o mesmo nivel de soporte en tempo de execución que todos os outros CRD. Dado que Pinterest usa activamente Tensorflow e outros sistemas de aprendizaxe automática, tiñamos un motivo para construír un CRD separado ao seu redor.
Tamén estamos a traballar en PinterestStatefulSet, que en breve se adaptará para almacéns de datos e outros sistemas con estado.
Soporte en tempo de execución
Cando un pod de aplicación se executa en Kubernetes, recibe automaticamente un certificado para identificarse. Este certificado úsase para acceder ao almacenamento secreto ou para comunicarse con outros servizos mediante mTLS. Mentres tanto, o Container Init Configurator e o Daemon descargarán todas as dependencias necesarias antes de executar a aplicación en contedores. Cando todo estea listo, o tráfico sidecar e Daemon rexistrarán o enderezo IP do módulo co noso Zookeeper para que os clientes o descubran. Todo isto funcionará porque o módulo de rede foi configurado antes de que se lanzase a aplicación.
Os anteriores son exemplos típicos de soporte en tempo de execución para cargas de traballo. Outros tipos de cargas de traballo poden requirir un soporte lixeiramente diferente, pero todos veñen en forma de sidecars a nivel de pod, daemons a nivel de nodos ou máquinas virtuais. Aseguramos que todo isto se despregue dentro da infraestrutura de xestión e sexa coherente en todas as aplicacións, o que finalmente reduce significativamente a carga en termos de traballo técnico e asistencia ao cliente.
Probas e control de calidade
Creamos unha canalización de probas de extremo a extremo ademais da infraestrutura de probas de Kubernetes existente. Estas probas aplícanse a todos os nosos clusters. O noso pipeline pasou por moitas revisións antes de formar parte do clúster de produtos.
Ademais dos sistemas de proba, contamos con sistemas de monitorización e alerta que supervisan constantemente o estado dos compoñentes do sistema, o consumo de recursos e outros indicadores importantes, notificándonos só cando é necesaria a intervención humana.
Alternativas
Analizamos algunhas alternativas aos recursos personalizados, como controladores de acceso á mutación e sistemas de modelos. Non obstante, todos teñen importantes retos operativos, polo que escollemos a ruta CRD.
Utilizouse un controlador de admisión mutacional para introducir sidecars, variables de ambiente e outros soportes de tempo de execución. Non obstante, afrontou varios problemas, como a vinculación de recursos e a xestión do ciclo de vida, onde tales problemas non xorden en CRD.
Nota: Os sistemas de modelos como os gráficos Helm tamén son moi utilizados para executar aplicacións con configuracións similares. Non obstante, as nosas aplicacións de traballo son demasiado diversas para poder xestionalas mediante modelos. Tamén durante o despregamento continuo haberá demasiados erros ao usar modelos.
Próximo traballo
Actualmente estamos lidando cunha carga mixta en todos os nosos clústeres. Para soportar estes procesos de diferentes tipos e tamaños, traballamos nas seguintes áreas:
- Unha colección de clústeres distribúe grandes aplicacións en diferentes clústeres para a súa escalabilidade e estabilidade.
- Garantir a estabilidade, escalabilidade e visibilidade do clúster para crear conectividade de aplicacións e SLA.
- Xestionando recursos e cotas para que as aplicacións non entren en conflito entre si, e a escala do clúster estea controlada pola nosa parte.
- Unha nova plataforma CI/CD para soportar e implementar aplicacións en Kubernetes.
Fonte: www.habr.com