Un enfoque moderno das operacións resolve moitos problemas empresariais urxentes. Os contedores e os orquestadores facilitan a escala de proxectos de calquera complexidade, simplifican o lanzamento de novas versións, fanos máis fiables, pero ao mesmo tempo crean problemas adicionais para os desenvolvedores. O programador, en primeiro lugar, preocúpase polo seu código: arquitectura, calidade, rendemento, elegancia, e non como funcionará en Kubernetes e como probalo e depuralo despois de facer cambios mínimos. Polo tanto, tamén é bastante natural que se desenvolvan activamente ferramentas para Kubernetes, axudando a resolver os problemas incluso dos desenvolvedores máis "arcaicos" e permitíndolles centrarse no principal.
Esta revisión ofrece información breve sobre algunhas das ferramentas que facilitan a vida dun programador cuxo código se executa no pod'ax dun clúster de Kubernetes.
Axudantes sinxelos
Kubectl-depuración
- A liña de fondo: engade o teu recipiente a un Pod e mira o que ocorre nel.
- .
- Breves estatísticas de GH: 715 estrelas, 54 commits, 9 colaboradores.
- Idioma: Vaia.
- Licenza: Apache License 2.0.
Este complemento para kubectl permítelle crear un contedor adicional dentro do pod de interese, que compartirá o espazo de nomes do proceso con outros contedores. Nel pódese depurar o funcionamento do pod: comprobar a rede, escoitar o tráfico da rede, facer unha traza do proceso de interese, etc.
Tamén podes cambiar ao contenedor de procesos executando chroot /proc/PID/root - isto pode ser moi conveniente cando necesitas obter un shell raíz nun recipiente para o que está definido no manifesto securityContext.runAs.
A ferramenta é sinxela e eficaz, polo que pode ser útil para todos os desenvolvedores. Escribimos máis sobre iso en .
Telepresencia
- A liña de fondo: transferir a aplicación ao seu ordenador. Desenvolver e depurar localmente.
- ; .
- Breves estatísticas de GH: 2131 estrelas, 2712 commits, 33 colaboradores.
- Idioma: Python.
- Licenza: Apache License 2.0.
A idea deste complemento é lanzar un contedor coa aplicación no ordenador local do usuario e proxy todo o tráfico do clúster ata el e de volta. Este enfoque permíteche desenvolver localmente simplemente editando ficheiros no teu IDE favorito: os resultados estarán dispoñibles inmediatamente.
As vantaxes de executar localmente son a comodidade das edicións e os resultados instantáneos, a posibilidade de depurar a aplicación do xeito habitual. O inconveniente é que é esixente en velocidade de conexión, o que se nota especialmente cando hai que traballar cunha aplicación con RPS e tráfico bastante elevados. Ademais, Telepresence ten problemas cos montaxes de volume en Windows, o que pode ser unha limitación decisiva para os desenvolvedores afeitos a este SO.
Xa compartimos a nosa experiencia de uso da Telepresencia .
Ksync
- A liña de fondo: sincronización case instantánea do código co contedor do clúster.
- .
- Breves estatísticas de GH: 555 estrelas, 362 commits, 11 colaboradores.
- Idioma: Vaia.
- Licenza: Apache License 2.0.
A utilidade permítelle sincronizar o contido dun directorio local co directorio dun contedor que se executa no clúster. Tal ferramenta é perfecta para desenvolvedores de linguaxes de programación de scripts, cuxo principal problema é entregar código a un contedor en execución. Ksync está deseñado para aliviar esta dor de cabeza.
Cando se inicializa unha vez polo comando ksync init créase un DaemonSet no clúster, que se usa para supervisar o estado do sistema de ficheiros do contedor seleccionado. No seu ordenador local, o programador executa o comando ksync watch, que supervisa as configuracións e as execucións , que sincroniza directamente os ficheiros co clúster.
Todo o que queda é indicarlle a ksync que sincronizar con que. Por exemplo, este comando:
ksync create --name=myproject --namespace=test --selector=app=backend --container=php --reload=false /home/user/myproject/ /var/www/myproject/
...crearase un observador chamado myprojectque buscará unha vaina cunha etiqueta app=backend e tenta sincronizar o directorio local /home/user/myproject/ con catálogo /var/www/myproject/ no recipiente chamado php.
Problemas e notas sobre ksync da nosa experiencia:
- Debe usarse nos nodos do clúster de Kubernetes
overlay2como controlador de almacenamento para Docker. A utilidade non funcionará con ningunha outra. - Cando se usa Windows como sistema operativo cliente, é posible que o vixiante do sistema de ficheiros non funcione correctamente. Este erro notouse ao traballar con directorios grandes, cun gran número de ficheiros e directorios aniñados. Creamos no proxecto de sincronización, pero aínda non hai avances nel (desde principios de xullo).
- Usa o ficheiro para especificar camiños ou patróns de ficheiros que non precisan estar sincronizados (por exemplo, directorios
app/cacheи.git). - Por defecto, ksync reiniciará o contedor sempre que cambien os ficheiros. Para Node.js isto é conveniente, pero para PHP é completamente innecesario. É mellor desactivar opcache e usar a bandeira
--reload=false. - A configuración sempre se pode corrixir en
$HOME/.ksync/ksync.yaml.
Cabaza
- A liña de fondo: depurar procesos directamente no clúster.
- .
- Breves estatísticas de GH: 1154 estrelas, 279 commits, 23 colaboradores.
- Idioma: Vaia.
- Licenza: Apache License 2.0.
Esta ferramenta está deseñada para depurar procesos directamente en pods. A utilidade é sinxela e de forma interactiva permítelle seleccionar o depurador desexado (Ver abaixo) e espazo de nomes + pod, no proceso dos cales cómpre intervir. Soportado actualmente:
- delve - para aplicacións Go;
- GDB - a través de destino remoto + reenvío de portos;
- Reenvío de portos JDWP para depurar aplicacións Java.
No lado do IDE, o soporte só está dispoñible en VScode (usando ), con todo, os plans para o ano actual (2019) inclúen Eclipse e Intellij.
Para depurar procesos, Squash executa un contedor privilexiado nos nodos do clúster, polo que primeiro debes familiarizarte coas capacidades para evitar problemas de seguridade.
Solucións completas
Pasemos á artillería pesada: proxectos máis "a gran escala" deseñados para satisfacer inmediatamente moitas das necesidades dos desenvolvedores.
NB: Nesta lista, por suposto, hai un lugar para a nosa utilidade de código aberto (anteriormente coñecido como dapp). Porén, xa o escribimos e falamos máis dunha vez, polo que decidimos non incluílo na recensión. Para aqueles que desexen familiarizarse máis coas súas capacidades, recomendamos ler/escoitar o informe "».
DevSpace
- A liña de fondo: para aqueles que queiran comezar a traballar en Kubernetes, pero non queren afondar na súa selva.
- .
- Breves estatísticas de GH: 630 estrelas, 1912 commits, 13 colaboradores.
- Idioma: Vaia.
- Licenza: Apache License 2.0.
Unha solución da empresa do mesmo nome, que proporciona clústeres xestionados con Kubernetes para o desenvolvemento do equipo. A utilidade creouse para clusters comerciais, pero funciona moi ben con calquera outro.
Ao executar o comando devspace init no catálogo do proxecto ofreceráselle (de forma interactiva):
- seleccione un clúster de Kubernetes que funcione,
- uso existente
Dockerfile(ou xerar un novo) para crear un contedor baseado nel, - seleccione un repositorio para almacenar imaxes de contedores, etc.
Despois de todos estes pasos preparatorios, podes comezar o desenvolvemento executando o comando devspace dev. Creará o contedor, cargarao no repositorio, lanzará a implantación no clúster e iniciará o reenvío de portos e a sincronización do contedor co directorio local.
Opcionalmente, solicitaráselle que mova o terminal ao contedor. Non debes rexeitar, porque en realidade o contedor comeza co comando de suspensión, e para probar reais a aplicación debe ser iniciada manualmente.
Finalmente, o equipo devspace deploy lanza a aplicación e a infraestrutura asociada ao clúster, despois de que todo comeza a funcionar en modo combate.
Toda a configuración do proxecto gárdase nun ficheiro devspace.yaml. Ademais da configuración do contorno de desenvolvemento, tamén podes atopar nela unha descrición da infraestrutura, similar aos manifestos estándar de Kubernetes, só moi simplificado.
Arquitectura e principais etapas de traballo con DevSpace
Ademais, é fácil engadir un compoñente predefinido (por exemplo, un DBMS MySQL) ou un gráfico Helm ao proxecto. Ler máis en - Non é complicado.
Patín
- ; .
- Breves estatísticas de GH: 7423 estrelas, 4173 commits, 136 colaboradores.
- Idioma: Vaia.
- Licenza: Apache License 2.0.
Esta utilidade de Google afirma cubrir todas as necesidades dun programador cuxo código se executará dalgún xeito nun clúster de Kubernetes. Comezar a usalo non é tan sinxelo coma devspace: non hai interactividade, detección de idiomas e creación automática Dockerfile aquí non cho ofrecerán.
Non obstante, se isto non che asusta, isto é o que che permite facer Skaffold:
- Rastrexa os cambios no código fonte.
- Sincronízao co recipiente da vaina se non precisa montaxe.
- Recolle contedores con código, se a linguaxe é interpretada, ou compila artefactos e empaquetaos en contedores.
- As imaxes resultantes compróbanse automaticamente mediante .
- Etiquetar e cargar imaxes no Rexistro de Docker.
- Implementa unha aplicación nun clúster mediante kubectl, Helm ou kustomize.
- Realiza o reenvío de portos.
- Depurar aplicacións escritas en Java, Node.js, Python.
O fluxo de traballo en varias variacións descríbese declarativamente no ficheiro skaffold.yaml. Para un proxecto, tamén pode definir varios perfís nos que pode modificar parcial ou totalmente as fases de montaxe e implantación. Por exemplo, para o desenvolvemento, especifique unha imaxe base conveniente para o desenvolvedor e para a posta en escena e a produción: unha mínima (+ use securityContext contenedores ou redefinir o clúster no que se despregará a aplicación).
Os contedores Docker pódense construír de forma local ou remota: in ou nun clúster usando . Bazel e Jib Maven/Gradle tamén son compatibles. Para etiquetar, Skaffold admite moitas estratexias: por git commit hash, data/hora, sha256-sum de fontes, etc.
Por separado, cómpre destacar a posibilidade de probar os recipientes. O marco de proba de estrutura de contedores xa mencionado ofrece os seguintes métodos de verificación:
- Executar comandos no contexto dun contedor con seguimento dos estados de saída e comprobando a saída de texto do comando.
- Comprobar a presenza de ficheiros no contedor e facer coincidir os atributos especificados.
- Control do contido do ficheiro mediante expresións regulares.
- Verificación de metadatos da imaxe (
ENV,ENTRYPOINT,VOLUMESetc.). - Comprobando a compatibilidade da licenza.
A sincronización dos ficheiros co contedor non se realiza da forma máis óptima: Skaffold simplemente crea un arquivo coas fontes, cópiao e desempaquetao no contedor (debe estar instalado tar). Polo tanto, se a súa tarefa principal é a sincronización de código, é mellor buscar unha solución especializada (ksync).
Principais etapas da operación Skaffold
En xeral, a ferramenta non permite abstraerse dos manifestos de Kubernetes e non ten interactividade, polo que pode parecer difícil de dominar. Pero esta é tamén a súa vantaxe: maior liberdade de acción.
Xardín
- ; .
- Breves estatísticas de GH: 1063 estrelas, 1927 commits, 17 colaboradores.
- Linguaxe: TypeScript (está previsto dividir o proxecto en varios compoñentes, algúns dos cales estarán en Go, e tamén facer un SDK para crear complementos en TypeScript/JavaScript e Go).
- Licenza: Apache License 2.0.
Do mesmo xeito que Skaffold, Garden pretende automatizar os procesos de entrega de código de aplicación ao clúster K8s. Para facelo, primeiro cómpre describir a estrutura do proxecto nun ficheiro YAML e, a continuación, executar o comando garden dev. Ela fará toda a maxia:
- Recoller recipientes con varias partes do proxecto.
- Realiza probas de integración e unitarias, se se describiu algunha.
- Desplega todos os compoñentes do proxecto ao clúster.
- Se o código fonte cambia, reiniciarase toda a canalización.
O obxectivo principal do uso desta ferramenta é compartir un clúster remoto cun equipo de desenvolvemento. Neste caso, se xa se realizaron algúns dos pasos de construción e proba, isto acelerará significativamente todo o proceso, xa que Garden poderá utilizar os resultados almacenados na caché.
Un módulo de proxecto pode ser un contedor, un contedor Maven, un gráfico Helm, un manifesto para kubectl apply ou incluso unha función OpenFaaS. Ademais, calquera dos módulos pódese extraer dun repositorio Git remoto. Un módulo pode definir ou non servizos, tarefas e probas. Os servizos e tarefas poden ter dependencias, grazas ás cales pode determinar a secuencia de despregamento dun determinado servizo e organizar o lanzamento de tarefas e probas.
Garden ofrece ao usuario un fermoso panel de control (actualmente en ), que mostra a gráfica do proxecto: compoñentes, secuencia de montaxe, execución de tarefas e probas, as súas conexións e dependencias. Xusto no navegador, pode ver os rexistros de todos os compoñentes do proxecto e comprobar o que un determinado compoñente sae a través de HTTP (se, por suposto, se declara un recurso de entrada para el).
Panel para xardín
Esta ferramenta tamén ten un modo de recarga en quente, que simplemente sincroniza os cambios de script co contedor do clúster, acelerando moito o proceso de depuración da aplicación. O xardín ten un bo e non está mal , o que che permite acostumar rapidamente a el e comezar a usalo. Por certo, hai pouco que publicamos dos seus autores.
Conclusión
Por suposto, esta lista de ferramentas para desenvolver e depurar aplicacións en Kubernetes non se limita a. Hai moitas máis utilidades moi útiles e prácticas que son dignas, se non un artigo separado, polo menos unha mención. Cóntanos o que usas, que problemas atopaches e como os solucionou!
PS
Lea tamén no noso blog:
- «»;
- «»;
- «»;
- «».
Fonte: www.habr.com