Chámome Dmitry Sugrobov, son un programador en Leroy Merlin. Neste artigo contarei por que se necesita Helm, como simplifica o traballo con Kubernetes, o que cambiou na terceira versión e como usalo para actualizar aplicacións en produción sen tempo de inactividade.
Este é un resumo baseado nun discurso nunha conferencia by - Se non queres ler, mira o vídeo.
Por que usamos Kubernetes na produción
Leroy Merlin é líder no mercado de venda polo miúdo de bricolaxe en Rusia e Europa. A nosa empresa conta con máis de cen programadores, 33 empregados internos e un gran número de persoas que visitan hipermercados e o sitio web. Para que todos sexan felices, decidimos seguir os enfoques estándar da industria. Desenvolver novas aplicacións utilizando arquitectura de microservizos; utilizar contedores para illar os ambientes e garantir a correcta entrega; e utiliza Kubernetes para a orquestración. O prezo do uso de orquestradores é cada vez máis barato: o número de enxeñeiros expertos na tecnoloxía está a crecer no mercado e aparecen provedores que ofrecen Kubernetes como servizo.
Todo o que fai Kubernetes, por suposto, pódese facer doutros xeitos, por exemplo, cubrindo algúns Jenkins e docker-compose con scripts, pero por que complicar a vida se hai unha solución preparada e fiable? É por iso que vimos a Kubernetes e xa levamos un ano usándoo na produción. Actualmente temos vinte e catro clústeres de Kubernetes, o máis antigo dos cales ten máis dun ano de antigüidade, con preto de duascentas vainas.
A maldición dos grandes ficheiros YAML en Kubernetes
Para lanzar un microservizo en Kubernetes, crearemos polo menos cinco ficheiros YAML: para Deployment, Service, Ingress, ConfigMap, Secrets e envialos ao clúster. Para a seguinte aplicación escribiremos o mesmo paquete de xambas, co terceiro escribiremos outro, etc. Se multiplicamos o número de documentos polo número de ambientes, xa conseguiremos centos de ficheiros, e isto aínda non está tendo en conta os ambientes dinámicos.
Adam Reese, mantedor principal de Helm, introduciu o concepto de "", que se ve así:
- Copiar YAML: copia un ficheiro YAML.
- Pegar YAML - pégalo.
- Corrixir sangrías: corrixir sangrías.
- Repetir - repetir de novo.
A opción funciona, pero tes que copiar os ficheiros YAML moitas veces. Para cambiar este ciclo, inventouse Helm.
Que é Helm
En primeiro lugar, Helm - xestor de paquetes, que che axuda a atopar e instalar os programas que necesitas. Para instalar, por exemplo, MongoDB, non necesitas ir ao sitio web oficial e descargar binarios, só tes que executar o comando helm install stable/mongodb.
En segundo lugar, Helm - motor de modelos, axuda a parametrizar ficheiros. Volvamos á situación dos ficheiros YAML en Kubernetes. É máis fácil escribir o mesmo ficheiro YAML, engadirlle algúns marcadores de posición, nos que Helm substituirá os valores. É dicir, en lugar dun gran conxunto de andamios, haberá un conxunto de modelos nos que se substituirán os valores requiridos no momento adecuado.
En terceiro lugar, Helm - mestre de implantación. Con el podes instalar, restaurar e actualizar aplicacións. Imos descubrir como facelo.
Como usar Helm para implementar as túas propias aplicacións
Imos instalar o cliente Helm no teu ordenador, seguindo o oficial . A continuación, crearemos un conxunto de ficheiros YAML. En lugar de especificar valores específicos, deixaremos marcadores de posición, que Helm encherá con información no futuro. Un conxunto destes ficheiros chámase gráfico Helm. Pódese enviar ao cliente da consola Helm de tres xeitos:
- indicar un cartafol con modelos;
- empaqueta o arquivo nun .tar e apunta a el;
- coloque o modelo nun repositorio remoto e engada unha ligazón ao repositorio no cliente Helm.
Tamén necesitas un ficheiro con valores - values.yaml. Os datos de alí inseriranse no modelo. Creámolo tamén.
A segunda versión de Helm ten unha aplicación de servidor adicional: Tiller. Colócase fóra de Kubernetes e agarda as solicitudes do cliente Helm e, cando se chama, substitúe os valores necesarios no modelo e envíao a Kubernetes.
Helm 3 é máis sinxelo: en lugar de procesar modelos no servidor, a información agora procesa completamente no lado do cliente de Helm e envíase directamente á API de Kubernetes. Esta simplificación mellora a seguridade do clúster e facilita o esquema de lanzamento.
Como funciona todo
Executar o comando helm install. Imos indicar o nome da versión da aplicación e dar o camiño a values.yaml. Ao final indicaremos o repositorio no que se atopa o gráfico e o nome do gráfico. No exemplo, estes son "lmru" e "bestchart", respectivamente.
helm install --name bestapp --values values.yaml lmru/bestchart
O comando só se pode executar unha vez, cando se executa de novo install necesidade de usar upgrade. Para simplificar, en lugar de dous comandos, pode executar o comando upgrade con chave adicional --install. Cando se execute por primeira vez, Helm enviará un comando para instalar a versión e actualizaráo no futuro.
helm upgrade --install bestapp --values values.yaml lmru/bestchart
Trampas de implementar novas versións dunha aplicación con Helm
Neste momento da historia, estou xogando a quen quere ser millonario coa audiencia e estamos a descubrir como conseguir que Helm actualice a versión da aplicación. .
Cando estaba aprendendo como funciona Helm, sorprendeume un comportamento estraño ao tentar actualizar versións das aplicacións en execución. Actualizou o código da aplicación, carguei unha nova imaxe ao rexistro de Docker, enviei o comando de implementación e non pasou nada. A continuación móstranse algunhas formas que non son totalmente exitosas de actualizar aplicacións. Ao estudar cada un deles con máis detalle, comeza a comprender a estrutura interna do instrumento e as razóns deste comportamento non obvio.
Método 1. Non cambie a información desde o último lanzamento
Como di Helm, "Os gráficos de Kubernetes poden ser grandes e complexos, polo que Helm trata de non tocar nada demasiado". Polo tanto, se actualiza a última versión da imaxe da aplicación no rexistro docker e executa o comando helm upgrade, entón non pasará nada. Helm pensará que nada cambiou e que non é necesario enviar un comando a Kubernetes para actualizar a aplicación.
Aquí e abaixo, a etiqueta máis recente móstrase só como exemplo. Cando especificas esta etiqueta, Kubernetes descargará a imaxe do rexistro docker cada vez, independentemente do parámetro imagePullPolicy. O uso máis recente da produción non é desexable e provoca efectos secundarios.
Método 2. Actualiza LABEL na imaxe
Como está escrito no mesmo , "Helm só actualizará unha aplicación se cambiou desde a última versión". Unha opción lóxica para isto parece ser actualizar a ETIQUETA na propia imaxe do docker. Non obstante, Helm non examina as imaxes da aplicación e non ten idea de ningún cambio nelas. En consecuencia, ao actualizar as etiquetas da imaxe, Helm non saberá sobre elas e o comando de actualización da aplicación non se enviará a Kubernetes.
Método 3: use unha chave --force
Imos aos manuais e busquemos a chave necesaria. A clave ten máis sentido --force. A pesar do nome obvio, o comportamento é diferente do esperado. En lugar de forzar a actualización da aplicación, o seu verdadeiro propósito é restaurar unha versión que estea en estado FAIBLE. Se non utiliza esta tecla, cómpre executar os comandos secuencialmente helm delete && helm install --replace. Recoméndase utilizar a chave no seu lugar --force, que automatiza a execución secuencial destes comandos. Máis información neste . Para dicirlle a Helm que actualice a versión da aplicación, desafortunadamente, esta chave non funcionará.
Método 4. Cambia as etiquetas directamente en Kubernetes
Actualizando a etiqueta directamente no clúster mediante o comando kubectl edit - mala idea. Esta acción provocará unha incoherencia na información entre a aplicación en execución e a que se enviou orixinalmente para a súa implantación. O comportamento de Helm durante a implantación neste caso difire da súa versión: Helm 2 non fará nada e Helm 3 despregará a nova versión da aplicación. Para entender por que, cómpre entender como funciona Helm.
Como funciona Helm?
Para determinar se unha aplicación cambiou desde a súa última versión, Helm pode usar:
- executando a aplicación en Kubernetes;
- novos valores.yaml e gráfico actual;
- Información do lanzamento interno de Helm.
Para os máis curiosos: onde almacena Helm información interna sobre as versións?Ao executar o comando helm history, obteremos toda a información sobre as versións instaladas mediante Helm.
Tamén hai información detallada sobre os modelos e valores enviados. Podemos solicitalo:
Na segunda versión de Helm, esta información está situada no mesmo espazo de nomes onde se está a executar Tiller (kube-system por defecto), no ConfigMap, marcado coa etiqueta "OWNER=TILLER":
Cando apareceu a terceira versión de Helm, a información trasladouse a segredos e ao mesmo espazo de nomes onde se estaba a executar a aplicación. Grazas a isto, fíxose posible executar varias aplicacións simultaneamente en diferentes espazos de nomes co mesmo nome de versión. Na segunda versión foi unha seria dor de cabeza cando os espazos de nomes están illados pero poden influír entre si.
O segundo Helm, ao tentar comprender se é necesaria unha actualización, só utiliza dúas fontes de información: a que se lle proporciona agora e a información interna sobre as versións, que se atopa no ConfigMap.
O terceiro Helm utiliza unha estratexia de combinación de tres vías: ademais desa información, tamén ten en conta a aplicación que se está a executar agora mesmo en Kubernetes.
Por este motivo, a versión antiga de Helm non fará nada, xa que non ten en conta a información da aplicación no clúster, pero Helm 3 recibirá os cambios e enviará a nova aplicación para a súa implantación.
Método 5. Usa o interruptor --recreate-pods
Cunha chave --recreate-pods podes conseguir o que inicialmente planeabas conseguir coa chave --force. Os contedores reiniciaranse e, segundo a imagePullPolicy: Sempre a política para a etiqueta máis recente (máis sobre isto na nota ao pé de arriba), Kubernetes descargará e lanzará unha nova versión da imaxe. Isto non se fará da mellor maneira: sen ter en conta o tipo de estratexia de implantación, desactivará bruscamente todas as instancias de aplicacións antigas e comezará a lanzar outras novas. Durante o reinicio, o sistema non funcionará, os usuarios sufrirán.
No propio Kubernetes, un problema semellante tamén existiu durante moito tempo. E agora, 4 anos despois da inauguración , o problema foi solucionado e, a partir da versión 1.15 de Kubernetes, aparece a capacidade de reiniciar pods.
Helm simplemente desactiva todas as aplicacións e lanza novos contedores nas proximidades. Non podes facelo en produción, para non causar tempo de inactividade da aplicación. Isto só é necesario para as necesidades de desenvolvemento e só se pode realizar en ambientes escénicos.
Como actualizar a versión da aplicación usando Helm?
Cambiaremos os valores enviados a Helm. Normalmente, estes son valores que se substitúen en lugar da etiqueta de imaxe. No caso do último, que se usa a miúdo para ambientes improdutivos, a información modificable é unha anotación, que é inútil para Kubernetes, e para Helm actuará como un sinal da necesidade de actualizar a aplicación. Opcións para cubrir o valor da anotación:
- Valor aleatorio usando a función estándar -
{{ randAlphaNum 6 }}.
Hai unha advertencia: despois de cada despregamento usando un gráfico con tal variable, o valor da anotación será único e Helm asumirá que hai cambios. Resulta que sempre reiniciaremos a aplicación, aínda que non cambiamos a súa versión. Isto non é crítico, xa que non haberá tempo de inactividade, pero aínda é desagradable. - Pegar corrente data e hora -
{{ .Release.Date }}.
Unha variante é semellante a un valor aleatorio cunha variable permanentemente única. - Unha forma máis correcta é usar sumas de verificación. Este é o SHA da imaxe ou o SHA do último commit no git -
{{ .Values.sha }}.
Deberán ser contados e enviados ao cliente Helm do lado de chamada, por exemplo en Jenkins. Se a aplicación cambiou, a suma de verificación cambiará. Polo tanto, Helm só actualizará a aplicación cando sexa necesario.
Imos resumir os nosos intentos
- Helm realiza cambios da forma menos invasiva, polo que calquera cambio a nivel de imaxe da aplicación no Rexistro de Docker non dará lugar a unha actualización: non ocorrerá nada despois de que se execute o comando.
- Clave
--forceúsase para restaurar versións problemáticas e non se asocia con actualizacións forzadas. - Clave
--recreate-podsactualizará con forza as aplicacións, pero farao de forma vandálica: apagará bruscamente todos os contedores. Os usuarios sufrirán isto; non deberías facelo na produción. - Fai cambios directamente no clúster de Kubernetes mediante o comando
kubectl editnon: romperemos a coherencia e o comportamento diferirá dependendo da versión de Helm. - Co lanzamento da nova versión de Helm, apareceron moitos matices. Os problemas no repositorio de Helm descríbense cunha linguaxe clara e axudarán a comprender os detalles.
- Engadir unha anotación editable a un gráfico farao máis flexible. Isto permitirache lanzar a aplicación correctamente, sen tempo de inactividade.
Un pensamento de "paz mundial" que funciona en todos os ámbitos da vida: le as instrucións antes do uso, non despois. Só cunha información completa será posible construír sistemas fiables e facer felices aos usuarios.
Outras ligazóns relacionadas:
Este informe presentouse por primeira vez en por Mail.ru Cloud Solutions. Mirar outras actuacións e subscríbete aos anuncios de eventos en Telegram .
Fonte: www.habr.com