🥇Kubernetes: código aberto vs. vendedor

Ola, chámome Dmitry Krasnov. Levo máis de cinco anos administrando clústeres de Kubernetes e construíndo complexas arquitecturas de microservizos. A principios deste ano, lanzamos un servizo de xestión de clústeres de Kubernetes baseado en Containerum. Aproveitando esta oportunidade, contarei que é Kubernetes e como se diferencia a integración cun provedor do código aberto.

Para comezar, o que é Kubernetes. Este é un sistema para xestionar contedores nun gran número de hosts. Do grego, por certo, tradúcese como "piloto" ou "timonel". Desenvolvido orixinalmente por Google e despois doado como unha contribución tecnolóxica á Cloud Native Computing Foundation, unha organización internacional sen ánimo de lucro que reúne aos principais desenvolvedores, usuarios finais e provedores de tecnoloxía de contedores do mundo.

Xestionar un gran número de contedores

Agora imos descubrir que tipo de recipientes son estes. Esta é unha aplicación con todo o seu entorno, principalmente as bibliotecas das que depende o programa. Todo isto está empaquetado en arquivos e preséntase en forma de imaxe que se pode executar independentemente do sistema operativo, probado e moito máis. Pero hai un problema: xestionar contedores nun gran número de hosts é moi difícil. É por iso que se creou Kubernetes.

Unha imaxe de contedor representa unha aplicación máis as súas dependencias. A aplicación, as súas dependencias e a imaxe do sistema de ficheiros do SO sitúanse en diferentes partes da imaxe, as chamadas capas. As capas pódense reutilizar para diferentes recipientes. Por exemplo, todas as aplicacións dunha empresa poden usar a capa base de Ubuntu. Cando se executan contedores, non é necesario almacenar varias copias dunha única capa base no host. Isto permítelle optimizar o almacenamento e a entrega de imaxes.

Cando queremos executar unha aplicación desde un contenedor, as capas necesarias superpoñense unhas a outras e fórmase un sistema de ficheiros superposto. Enriba colócase unha capa de gravación, que se elimina cando o recipiente para. Isto garante que cando se execute o contedor, a aplicación terá sempre o mesmo ambiente, que non se pode cambiar. Isto garante a reproducibilidade do ambiente en diferentes sistemas operativos anfitrións. Xa sexa Ubuntu ou CentOS, o entorno sempre será o mesmo. Ademais, o contedor está illado do host mediante mecanismos integrados no núcleo de Linux. As aplicacións nun contedor non ven ficheiros, procesos do host e contedores veciños. Este illamento das aplicacións do sistema operativo anfitrión proporciona unha capa adicional de seguridade.

Hai moitas ferramentas dispoñibles para xestionar contedores nun host. O máis popular deles é Docker. Permítelle proporcionar o ciclo de vida completo dos recipientes. Non obstante, só funciona nun servidor. Se precisas xestionar contedores en varios hosts, Docker pode facer un inferno para os enxeñeiros. É por iso que se creou Kubernetes.

A demanda de Kubernetes débese precisamente á capacidade de xestionar grupos de contedores en varios hosts como unha especie de única entidade. A popularidade do sistema ofrece a oportunidade de construír DevOps ou operacións de desenvolvemento, nas que Kubernetes se utiliza para executar os procesos deste mesmo DevOps.

Figura 1. Representación esquemática do funcionamento de Kubernetes

Automatización total

DevOps é basicamente a automatización do proceso de desenvolvemento. En liñas xerais, os desenvolvedores escriben código que se carga no repositorio. Despois, este código pódese recoller automaticamente inmediatamente nun contedor con todas as bibliotecas, probar e "lanzarse" á seguinte fase: a posta en escena, e despois inmediatamente á produción.

Xunto con Kubernetes, DevOps permítelle automatizar este proceso para que se produza sen practicamente ningunha participación dos propios desenvolvedores. Debido a isto, a construción é significativamente máis rápida, xa que o desenvolvedor non ten que facelo no seu ordenador: simplemente escribe un anaco de código, empurra o código ao repositorio, despois de que se lanza a canalización, que pode incluír o proceso. de construción, proba e implantación. E isto ocorre con cada commit, polo que as probas ocorren continuamente.

Ao mesmo tempo, usar un contedor permítelle estar seguro de que todo o ambiente deste programa será lanzado en produción exactamente na forma na que foi probado. É dicir, non haberá problemas como "houbo unhas versións na proba, outras en produción, pero cando as instalamos caeu todo". E xa que hoxe temos unha tendencia cara á arquitectura de microservizos, cando en lugar dunha aplicación enorme hai centos de pequenas, para administralas manualmente, será necesario un enorme persoal de empregados. Por iso usamos Kubernetes.

Pros, pros, pros

Se falamos das vantaxes de Kubernetes como plataforma, ten importantes vantaxes desde o punto de vista da xestión dunha arquitectura de microservizos.

Xestionar varias réplicas. O máis importante é xestionar contedores en varios hosts. Máis importante aínda, xestionar varias réplicas de aplicacións en contedores como unha única entidade. Grazas a isto, os enxeñeiros non teñen que preocuparse por cada recipiente individual. Se un dos contedores falla, Kubernetes verá isto e reiniciao de novo.
Rede de clústeres. Kubernetes tamén ten a chamada rede de clúster co seu propio espazo de enderezos. Grazas a isto, cada pod ten o seu propio enderezo. Un subpod enténdese como a unidade estrutural mínima dun clúster na que se lanzan directamente os contedores. Ademais, Kubernetes ten unha funcionalidade que combina un equilibrador de carga e Service Discovery. Isto permítelle desfacerse da xestión manual de enderezos IP e delegar esta tarefa en Kubernetes. E as comprobacións automáticas de saúde axudarán a detectar problemas e a redirixir o tráfico aos módulos funcionantes.
Xestión da configuración. Cando se xestiona un gran número de aplicacións, faise difícil xestionar a configuración da aplicación. Para este fin, Kubernetes dispón de recursos especiais de ConfigMap. Permítenche almacenar configuracións de forma centralizada e expoñelas a pods ao executar aplicacións. Este mecanismo permítenos garantir a coherencia da configuración en polo menos dez ou cen réplicas de aplicacións.
Volumes persistentes. Os contedores son inherentemente inmutables e cando o contedor se detén, todos os datos escritos no sistema de ficheiros serán destruídos. Pero algunhas aplicacións almacenan datos directamente no disco. Para resolver este problema, Kubernetes dispón dunha funcionalidade de xestión de almacenamento en disco - Volumes persistentes. Este mecanismo usa almacenamento externo para os datos e pode transferir almacenamento persistente, bloque ou ficheiro, a contedores. Esta solución permítelle almacenar os datos por separado dos traballadores, o que garda-los se estes mesmos traballadores avarian.
Balanceador de carga. Aínda que en Kubernetes xestionamos entidades abstractas como Deployment, StatefulSet, etc., en última instancia os contedores execútanse de forma regular. máquinas virtuais Ou servidores bare metal. Non son perfectos e poden fallar en calquera momento. Kubernetes detectará isto e redirixirá o tráfico interno a outras réplicas. Pero que pasa co tráfico externo? Simplemente dirixir o tráfico a un traballador significa que o servizo deixará de estar dispoñible se falla. Para solucionar este problema, Kubernetes ofrece servizos como Load Balancer. Están deseñados para configurar automaticamente un balanceador de carga na nube externo para todos os traballadores do clúster. Este balanceador de carga externo dirixe o tráfico externo aos traballadores e supervisa o seu estado. Se un ou máis traballadores deixan de estar dispoñibles, o tráfico rediríxese a outros. Isto permíteche crear servizos de alta dispoñibilidade usando Kubernetes.

Kubernetes funciona mellor cando se executan arquitecturas de microservizos. É posible implementar o sistema na arquitectura clásica, pero non ten sentido. Se unha aplicación non pode executarse en varias réplicas, que diferenza fai, en Kubernetes ou non?

Kubernetes de código aberto

Kubernetes de código aberto é unha gran cousa: instaleino e funciona. Pode implantalo nos seus propios servidores de hardware, na súa propia infraestrutura, instalar mestres e traballadores nos que se executarán todas as aplicacións. E o máis importante, todo isto é gratuíto. Non obstante, hai matices.

O primeiro é a demanda de coñecemento e experiencia dos administradores e enxeñeiros que implantarán e apoiarán todo isto. Dado que o cliente recibe total liberdade de acción no clúster, é responsable do propio rendemento do clúster. E é moi doado romper todo aquí.
O segundo é a falta de integracións. Se executas Kubernetes sen unha plataforma de virtualización popular, non obterás todos os beneficios do programa. Como usar volumes persistentes e servizos de equilibrador de carga.

Figura 2. arquitectura k8s

Kubernetes do provedor

A integración cun provedor de nube ofrece dúas opcións:

En primeiro lugar, unha persoa pode simplemente facer clic no botón "crear clúster" e obter un clúster xa configurado e listo para o seu uso.
En segundo lugar, o propio vendedor instala o clúster e configura a integración coa nube.

Como pasa aquí. O enxeñeiro que inicia o clúster especifica cantos traballadores necesita e con que parámetros (por exemplo, 5 traballadores, cada un con 10 CPU, 16 GB de RAM e, por exemplo, 100 GB de disco). Despois diso, accede ao cluster xa formado. Neste caso, os traballadores sobre os que se lanza a carga transfírense completamente ao cliente, pero todo o plano de xestión permanece baixo a responsabilidade do provedor (se o servizo se presta segundo o modelo de servizo xestionado).

Non obstante, este esquema ten os seus inconvenientes. Debido ao feito de que o plano de xestión permanece co vendedor, o vendedor non dá acceso total ao cliente, e isto reduce a flexibilidade ao traballar con Kubernetes. Ás veces ocorre que un cliente quere engadir algunha funcionalidade específica a Kubernetes, por exemplo, a autenticación mediante LDAP, pero a configuración do plano de xestión non o permite.

Figura 3. Exemplo dun clúster de Kubernetes dun provedor de nube

Que escoller: código aberto ou provedor

Entón, é Kubernetes de código aberto ou específico do vendedor? Se tomamos Kubernetes de código aberto, entón o usuario fai o que quere con el. Pero hai unha gran posibilidade de dispararte no pé. Co vendedor é máis difícil, porque todo está pensado e configurado para a empresa. A maior desvantaxe de Kubernetes de código aberto é a esixencia de especialistas. Cunha opción de vendedor, a empresa queda liberada desta dor de cabeza, pero terá que decidir se paga aos seus especialistas ou ao vendedor.

Ben, os pros son obvios, os contras tamén son coñecidos. Unha cousa é constante: Kubernetes resolve moitos problemas automatizando a xestión de moitos contedores. E cal escoller, código aberto ou provedor: cada un toma a súa propia decisión.