Kubernetes é unha excelente ferramenta para executar contedores Docker nun ambiente de produción en clúster. Non obstante, hai problemas que Kubernetes non pode resolver. Para as implantacións de produción frecuentes, necesitamos unha implementación totalmente automatizada en azul/verde para evitar tempo de inactividade no proceso, que tamén precisa xestionar solicitudes HTTP externas e realizar descargas SSL. Isto require a integración cun equilibrador de carga como ha-proxy. Outro reto é a escala semiautomática do propio clúster de Kubernetes cando se executa nun ambiente de nube, por exemplo, a escala parcial do clúster pola noite.
Aínda que Kubernetes non ten estas funcións fóra da caixa, si ofrece unha API que pode usar para resolver problemas similares. Como parte do proxecto Cloud RTI, que se creou baseándose en código aberto, desenvolvéronse ferramentas para o despregamento e escalado automatizado de Blue/Green dun clúster de Kubernetes.
Este artigo, unha transcrición de vídeo, móstrache como configurar Kubernetes xunto con outros compoñentes de código aberto para crear un ambiente preparado para a produción que acepte código dun commit git sen tempo de inactividade na produción.
Entón, unha vez que teñas acceso ás túas aplicacións desde o mundo exterior, podes comezar a configurar completamente a automatización, é dicir, levala ao escenario onde podes realizar un commit git e asegurarte de que este commit git remate en produción. Por suposto, ao implementar estes pasos, ao implementar a implantación, non queremos atopar tempo de inactividade. Entón, calquera automatización en Kubernetes comeza coa API.
Kubernetes non é unha ferramenta que se poida usar de forma produtiva fóra da caixa. Por suposto, podes facelo, usar kubectl e así por diante, pero aínda así a API é o máis interesante e útil desta plataforma. Ao usar a API como un conxunto de funcións, podes acceder a case todo o que queiras facer en Kubernetes. O propio kubectl tamén usa a API REST.
Isto é REST, polo que podes utilizar calquera linguaxe ou ferramenta para traballar con esta API, pero as bibliotecas personalizadas facilitarán moito a túa vida. O meu equipo escribiu dúas bibliotecas deste tipo: unha para Java/OSGi e outra para Go. O segundo non se usa con frecuencia, pero en calquera caso tes estas cousas útiles á túa disposición. Son un proxecto de código aberto parcialmente licenciado. Hai moitas bibliotecas deste tipo para diferentes idiomas, polo que podes escoller as que máis che convén.
Polo tanto, antes de comezar a automatizar a súa implementación, cómpre asegurarse de que o proceso non estará suxeito a ningún tempo de inactividade. Por exemplo, o noso equipo realiza despregamentos de produción durante o medio día cando a xente está a utilizar as aplicacións ao máximo, polo que é importante evitar atrasos neste proceso. Para evitar tempo de inactividade, utilízanse 2 métodos: implementación azul/verde ou actualización continua. Neste último caso, se tes 5 réplicas da aplicación en execución, actualízanse secuencialmente unha tras outra. Este método funciona moi ben, pero non é adecuado se tes diferentes versións da aplicación executando simultaneamente durante o proceso de implantación. Neste caso, pode actualizar a interface de usuario mentres o backend está a executar a versión antiga e a aplicación deixará de funcionar. Polo tanto, dende o punto de vista da programación, traballar en tales condicións é bastante difícil.
Esta é unha das razóns polas que preferimos utilizar o despregamento azul/verde para automatizar o despregamento das nosas aplicacións. Con este método, debes asegurarte de que só unha versión da aplicación está activa á vez.
O mecanismo de implantación azul/verde ten este aspecto. Recibimos tráfico das nosas aplicacións a través de ha-proxy, que o reenvía a réplicas en execución da aplicación da mesma versión.
Cando se fai un novo despregamento, usamos Deployer, que recibe os novos compoñentes e desprega a nova versión. A implantación dunha nova versión dunha aplicación significa que se "levanta" un novo conxunto de réplicas, despois do cal estas réplicas da nova versión lánzanse nun novo pod separado. Non obstante, ha-proxy non sabe nada sobre eles e aínda non lles envía ningunha carga de traballo.
Polo tanto, en primeiro lugar, é necesario realizar unha comprobación de rendemento das novas versións da comprobación de saúde para garantir que as réplicas están listas para atender a carga.
Todos os compoñentes de implantación deben admitir algún tipo de comprobación de saúde. Esta pode ser unha comprobación de chamada HTTP moi sinxela, cando recibe un código con estado 200, ou unha comprobación máis profunda, na que verifica a conexión das réplicas coa base de datos e outros servizos, a estabilidade das conexións do contorno dinámico. , e se todo comeza e funciona correctamente. Este proceso pode ser bastante complexo.
Despois de que o sistema verifique que todas as réplicas actualizadas funcionan, Deployer actualizará a configuración e pasará a configuración correcta, que reconfigurará o ha-proxy.
Só despois disto o tráfico dirixirase ao pod con réplicas da nova versión e desaparecerá o pod antigo.
Este mecanismo non é unha característica de Kubernetes. O concepto de implantación azul/verde existe desde hai moito tempo e sempre usou un equilibrador de carga. En primeiro lugar, dirixe todo o tráfico á versión antiga da aplicación e, despois da actualización, transfire completamente á nova versión. Este principio úsase non só en Kubernetes.
Agora presentareiche un novo compoñente de implantación: Deployer, que realiza comprobacións de saúde, reconfigura os proxies, etc. Este é un concepto que non se aplica ao mundo exterior e que existe dentro de Kubernetes. Vouche mostrar como podes crear o teu propio concepto Deployer usando ferramentas de código aberto.
Polo tanto, o primeiro que fai Deployer é crear un controlador de replicación RC usando a API de Kubernetes. Esta API crea pods e servizos para un posterior despregue, é dicir, crea un clúster completamente novo para as nosas aplicacións. En canto RC estea convencido de que se iniciaron as réplicas, realizará unha comprobación de saúde da súa funcionalidade. Para iso, Deployer usa o comando GET /health. Executa os compoñentes de dixitalización axeitados e comproba todos os elementos que admiten o funcionamento do clúster.
Despois de que todos os pods informaron sobre o seu estado, Deployer crea un novo elemento de configuración: almacenamento distribuído etcd, que Kubernetes usa internamente, incluíndo o almacenamento da configuración do equilibrador de carga. Escribimos datos en etcd, e unha pequena ferramenta chamada confd monitors etcd para novos datos.
Se detecta algún cambio na configuración inicial, xera un novo ficheiro de configuración e transfire a ha-proxy. Neste caso, ha-proxy reinicia sen perder ningunha conexión e dirixe a carga a novos servizos que permiten que a nova versión das nosas aplicacións funcione.
Como podes ver, a pesar da abundancia de compoñentes, aquí non hai nada complicado. Só tes que prestar máis atención á API e etcd. Quero falarvos do implementador de código aberto que nós mesmos usamos: Amdatu Kubernetes Deployer.
É unha ferramenta para orquestrar as implementacións de Kubernetes e ten as seguintes características:
- despregamento azul/verde;
- configurar un equilibrador de carga externo;
- xestión de descritores de despregamento;
- xestionar o despregamento real;
- comprobar a funcionalidade das comprobacións de saúde durante a implantación;
- implementación de variables de entorno en pods.
Este implementador está construído sobre a API de Kubernetes e ofrece unha API de REST para xestionar identificadores e despregamentos, así como unha API de Websocket para transmitir rexistros durante o proceso de implantación.
Coloca os datos de configuración do equilibrador de carga en etcd, polo que non tes que usar ha-proxy con soporte listo para usar, pero usa facilmente o teu propio ficheiro de configuración do equilibrador de carga. Amdatu Deployer está escrito en Go, como o propio Kubernetes, e ten a licenza de Apache.
Antes de comezar a usar esta versión do implementador, usei o seguinte descritor de implementación, que especifica os parámetros que necesito.
Un dos parámetros importantes deste código é activar a marca "useHealthCheck". Debemos especificar que se debe realizar unha comprobación de cordura durante o proceso de implantación. Esta configuración pódese desactivar cando a implantación utiliza contedores de terceiros que non precisan ser verificados. Este descritor tamén indica o número de réplicas e o URL de frontend que necesita ha-proxy. Ao final está a marca de especificación do pod "podspec", que chama a Kubernetes para obter información sobre a configuración do porto, a imaxe, etc. Este é un descritor JSON bastante sinxelo.
Outra ferramenta que forma parte do proxecto de código aberto Amdatu é Deploymentctl. Ten unha IU para configurar despregamentos, almacena o historial de implantación e contén webhooks para as devolucións de chamada de usuarios e desenvolvedores de terceiros. Non podes usar a IU xa que o propio Amdatu Deployer é unha API REST, pero esta interface pode facilitarche moito a implementación sen implicar ningunha API. Deploymentctl está escrito en OSGi/Vertx usando Angular 2.
Agora demostrarei o anterior na pantalla usando unha gravación pregravada para que non teñas que esperar. Implementaremos unha sinxela aplicación Go. Non te preocupes se non probaches Go antes, é unha aplicación moi sinxela polo que deberías poder descubrilo.
Aquí estamos a crear un servidor HTTP que só responde a /health, polo que esta aplicación só proba a comprobación de saúde e nada máis. Se a verificación pasa, utilízase a estrutura JSON que se mostra a continuación. Contén a versión da aplicación que implementará o implementador, a mensaxe que ves na parte superior do ficheiro e o tipo de datos booleanos, se a nosa aplicación funciona ou non.
Enganei un pouco coa última liña, porque coloquei un valor booleano fixo na parte superior do ficheiro, que no futuro axudarame a implementar incluso unha aplicación "non saudable". Tratarémolo máis adiante.
Entón, imos comezar. En primeiro lugar, comprobamos a presenza de pods en execución mediante o comando ~ kubectl get pods e, en función da ausencia dunha resposta do URL do frontend, asegurámonos de que non se están a realizar implementacións.
A continuación, na pantalla ves a interface Deploymentctl que mencionei, na que se definen os parámetros de implementación: espazo de nomes, nome da aplicación, versión de implementación, número de réplicas, URL do front-end, nome do contedor, imaxe, límites de recursos, número de porto para a comprobación de saúde, etc. Os límites de recursos son moi importantes, xa que permiten utilizar a máxima cantidade posible de hardware. Aquí tamén podes ver o rexistro de implantación.
Se agora repites o comando ~ kubectl get pods, podes ver que o sistema "conxela" durante 20 segundos, durante os cales se reconfigura o ha-proxy. Despois diso, o pod comeza e a nosa réplica pódese ver no rexistro de implantación.
Cortei a espera de 20 segundos do vídeo, e agora podes ver na pantalla que se implantou a primeira versión da aplicación. Todo isto fíxose usando só a IU.
Agora imos probar a segunda versión. Para iso, cambio a mensaxe da aplicación de "Ola, Kubernetes!" en "Ola, implementador!", o sistema crea esta imaxe e colócaa no rexistro de Docker, despois de que simplemente prememos de novo no botón "Implementar" na xanela Deploymentctl. Neste caso, o rexistro de despregamento lánzase automaticamente do mesmo xeito que ocorreu ao despregar a primeira versión da aplicación.
O comando ~ kubectl get pods mostra que actualmente hai dúas versións da aplicación en execución, pero a interface mostra que aínda estamos executando a versión 2.
O equilibrador de carga espera a que se complete a comprobación de estado antes de redirixir o tráfico á nova versión. Despois de 20 segundos, cambiamos a curl e vemos que agora temos a versión 2 da aplicación despregada e que a primeira foi eliminada.
Este foi o despregamento dunha aplicación "saudable". Vexamos que pasa se para unha nova versión da aplicación cambio o parámetro Saúde de verdadeiro a falso, é dicir, intento implantar unha aplicación non saudable que fallou na comprobación de saúde. Isto pode ocorrer se se cometeron algúns erros de configuración na aplicación na fase de desenvolvemento e se enviou a produción neste formulario.
Como podes ver, a implementación pasa por todos os pasos anteriores e ~kubectl get pods mostra que ambos pods están en execución. Pero a diferenza da implementación anterior, o rexistro mostra o estado do tempo de espera. É dicir, debido a que fallou a comprobación de saúde, non se pode despregar a nova versión da aplicación. Como resultado, ves que o sistema volveu usar a versión antiga da aplicación e simplemente desinstalouse a nova.
O bo disto é que aínda que teñas un gran número de solicitudes simultáneas que chegan á aplicación, nin sequera notarán o tempo de inactividade mentres implementan o procedemento de implantación. Se probas esta aplicación usando o marco Gatling, que lle envía tantas solicitudes como sexa posible, non se eliminará ningunha destas solicitudes. Isto significa que os nosos usuarios nin sequera notarán as actualizacións de versións en tempo real. Se falla, o traballo continuará na versión antiga; se ten éxito, os usuarios cambiarán á nova versión.
Só hai unha cousa que pode fallar: se a comprobación de saúde ten éxito, pero a aplicación falla tan pronto como se lle aplica a carga de traballo, é dicir, o colapso producirase só despois de que se complete a implementación. Neste caso, terás que volver manualmente á versión antiga. Entón, analizamos como usar Kubernetes coas ferramentas de código aberto deseñadas para iso. O proceso de implantación será moito máis sinxelo se incorporas estas ferramentas ás túas canalizacións de compilación/implementación. Ao mesmo tempo, para iniciar a implantación, pode usar a interface de usuario ou automatizar completamente este proceso mediante, por exemplo, commit to master.
O noso servidor de compilación creará unha imaxe de Docker, empurraraa no Docker Hub ou no rexistro que utilices. Docker Hub admite webhook, polo que podemos activar a implantación remota mediante Deployer do xeito que se mostra arriba. Deste xeito, pode automatizar completamente o despregamento da súa aplicación para a produción potencial.
Pasemos ao seguinte tema: escalar o clúster de Kubernetes. Teña en conta que o comando kubectl é un comando de escalado. Con máis axuda, podemos aumentar facilmente o número de réplicas no noso clúster existente. Non obstante, na práctica, normalmente queremos aumentar o número de nodos en lugar de vainas.
Ao mesmo tempo, durante o horario de traballo pode ter que aumentar, e pola noite, para reducir o custo dos servizos de Amazon, pode ter que reducir o número de instancias de aplicación en execución. Isto non significa que escalar só o número de pods sexa suficiente, porque aínda que un dos nodos estea inactivo, aínda terás que pagar a Amazon por iso. É dicir, xunto coa escala das vainas, terás que escalar o número de máquinas utilizadas.
Isto pode ser un reto porque se usamos Amazon ou outro servizo na nube, Kubernetes non sabe nada sobre o número de máquinas que se están a utilizar. Carece dunha ferramenta que lle permita escalar o sistema a nivel de nodo.
Así que teremos que coidar tanto os nodos como os pods. Podemos escalar facilmente o lanzamento de novos nodos usando a API de AWS e as máquinas do grupo Scaling para configurar o número de nodos de traballo de Kubernetes. Tamén podes usar cloud-init ou un script similar para rexistrar nós no clúster de Kubernetes.
A nova máquina comeza no grupo Escalado, iníciase como un nodo, rexístrase no rexistro do mestre e comeza a funcionar. Despois diso, pode aumentar o número de réplicas para usar nos nodos resultantes. A redución require máis esforzo, xa que cómpre asegurarse de que tal paso non leve á destrución das aplicacións que xa se executan despois de desactivar as máquinas "innecesarias". Para evitar tal situación, cómpre configurar os nodos no estado "non programable". Isto significa que o planificador predeterminado ignorará estes nodos ao programar pods de DaemonSet. O programador non eliminará nada destes servidores, pero tampouco lanzará ningún novo contedor alí. O seguinte paso é expulsar o nodo de drenaxe, é dicir, transferir pods en execución desde el a outra máquina, ou outros nodos que teñan capacidade suficiente para iso. Unha vez que te asegures de que xa non hai contedores nestes nodos, podes eliminalos de Kubernetes. Despois disto, simplemente deixarán de existir para Kubernetes. A continuación, cómpre usar a API de AWS para desactivar os nós ou máquinas innecesarias.
Podes usar Amdatu Scalerd, outra ferramenta de escalado de código aberto similar á API de AWS. Ofrece unha CLI para engadir ou eliminar nós nun clúster. A súa característica interesante é a posibilidade de configurar o planificador usando o seguinte ficheiro json.
O código que se mostra reduce a capacidade do clúster á metade durante o período nocturno. Configura tanto o número de réplicas dispoñibles como a capacidade desexada do clúster de Amazon. Usar este programador reducirá automaticamente o número de nós pola noite e aumentarase pola mañá, aforrando o custo do uso de nós dun servizo na nube como Amazon. Esta función non está integrada en Kubernetes, pero usar Scalerd permitirache escalar esta plataforma como queiras.
Gustaríame sinalar que moita xente me din: "Está todo ben, pero que pasa coa miña base de datos, que normalmente é estática?" Como se pode executar algo así nun ambiente dinámico como Kubernetes? Na miña opinión, non deberías facelo, non deberías intentar executar un almacén de datos en Kubernetes. Isto é tecnicamente posible, e hai titoriais en Internet sobre este tema, pero complicarache seriamente a vida.
Si, hai un concepto de tendas persistentes en Kubernetes, e podes tentar executar tendas de datos como Mongo ou MySQL, pero esta é unha tarefa moi laboriosa. Isto débese ao feito de que os almacéns de datos non admiten totalmente a interacción cun ambiente dinámico. A maioría das bases de datos requiren unha configuración significativa, incluída a configuración manual do clúster, non lles gusta o escalado automático e outras cousas similares.
Polo tanto, non deberías complicarte a vida tentando executar un almacén de datos en Kubernetes. Organice o seu traballo de forma tradicional utilizando servizos coñecidos e simplemente proporcione a Kubernetes a posibilidade de utilizalos.
Para rematar o tema, gustaríame presentarvos a plataforma Cloud RTI baseada en Kubernetes, na que está a traballar o meu equipo. Ofrece rexistro centralizado, seguimento de aplicacións e clústeres e moitas outras funcións útiles que serán útiles. Usa varias ferramentas de código aberto como Grafana para mostrar o seguimento.
Houbo unha pregunta sobre por que usar o equilibrador de carga ha-proxy con Kubernetes. Boa pregunta porque actualmente hai 2 niveis de equilibrio de carga. Os servizos de Kubernetes aínda residen en enderezos IP virtuais. Non podes usalos para portos en máquinas host externas porque se Amazon sobrecarga o seu servidor na nube, o enderezo cambiará. É por iso que colocamos ha-proxy diante dos servizos, para crear unha estrutura máis estática para que o tráfico se comunique perfectamente con Kubernetes.
Outra boa pregunta é como se pode coidar dos cambios no esquema da base de datos cando se realiza a implementación azul/verde? O feito é que, independentemente do uso de Kubernetes, cambiar o esquema da base de datos é unha tarefa difícil. Debe asegurarse de que o esquema antigo e o novo son compatibles, despois de que pode actualizar a base de datos e despois actualizar as propias aplicacións. Podes intercambiar en quente a base de datos e despois actualizar as aplicacións. Sei de persoas que iniciaron un clúster de bases de datos completamente novo cun novo esquema, esta é unha opción se tes unha base de datos sen esquemas como Mongo, pero de todos os xeitos non é unha tarefa fácil. Se non tes máis preguntas, grazas pola túa atención!
Algúns anuncios 🙂
Grazas por estar connosco. Gústanche os nosos artigos? Queres ver máis contido interesante? Apóyanos facendo un pedido ou recomendando a amigos, , un análogo único de servidores de nivel de entrada, que inventamos nós para ti: (dispoñible con RAID1 e RAID10, ata 24 núcleos e ata 40 GB DDR4).
Dell R730xd 2 veces máis barato no centro de datos Equinix Tier IV en Amsterdam? Só aquí nos Países Baixos! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - desde $ 99! Ler sobre
Fonte: www.habr.com