Nota. transl.: O autor do artigo orixinal é Théo Chamley, Google Cloud Solutions Architect. Nesta publicación para o blog de Google Cloud, ofrece un resumo da guía máis detallada da súa empresa, chamada "" Nel, os expertos de Google recolleron as mellores prácticas para operar contedores no contexto do uso de Google Kubernetes Engine e moito máis, tocando unha ampla gama de temas: desde a seguridade ata a supervisión e o rexistro. Entón, cales son as prácticas de contedores máis importantes segundo Google?
(Servizo baseado en Kubernetes para executar aplicacións en contedores en Google Cloud - aprox. tradución) é unha das mellores formas de executar cargas de traballo que precisan escalar. garantirá o bo funcionamento da maioría das aplicacións se están en contenedores. Pero se queres que a túa aplicación sexa fácil de xestionar e queres aproveitar ao máximo Kubernetes, debes seguir as prácticas recomendadas. Simplificarán o funcionamento da aplicación, o seu seguimento e depuración, e tamén aumentarán a seguridade.
Neste artigo, repasaremos unha lista de cousas que debes saber e facer para executar os contedores de forma eficaz en Kubernetes. Os que desexen afondar nos detalles deben ler o material , e tamén prestar atención ao noso sobre a montaxe de envases.
1. Use mecanismos de rexistro de contedores nativos
Se a aplicación está a executarse nun clúster de Kubernetes, non se necesita moito para os rexistros. É probable que un sistema de rexistro centralizado xa estea integrado no clúster que está a usar. No caso de usar Kubernetes Engine, este é o responsable . (Nota. transl.: E se usas a túa propia instalación de Kubernetes, recomendámosche unha ollada máis atenta á nosa solución de código aberto. .) Mantén a túa vida sinxela e usa mecanismos de rexistro de contedores nativos. Escriba rexistros en stdout e stderr: recibiranse, gardaranse e indexaranse automaticamente.
Se o desexa, tamén pode escribir rexistros . Este enfoque facilitará engadirlles metadatos. E con eles, Stackdriver Logging terá a capacidade de buscar nos rexistros usando estes metadatos.
2. Asegúrate de que os contedores sexan sen estado e sexan inmutables
Para que os contedores funcionen correctamente nun clúster de Kubernetes, deben ser sen estado e inmutables. Unha vez que se cumpren estas condicións, Kubernetes pode facer o seu traballo, creando e destruíndo entidades de aplicación cando e onde sexa necesario.
Apátrida significa que calquera estado (datos persistentes de calquera tipo) almacénase fóra do contedor. Para iso, segundo as necesidades, pódense utilizar diferentes tipos de almacenamento externo: , , , ou outras bases de datos xestionadas. (Nota. transl.: Lea máis sobre isto no noso artigo "".)
Inmutable significa que o contedor non será modificado durante a súa vida útil: non hai actualizacións, parches, cambios de configuración. Se precisa actualizar o código da súa aplicación ou aplicar un parche, cree unha nova imaxe e despréguea. Recoméndase mover a configuración do contedor (porto de escoita, opcións de ambiente de execución, etc.) externamente a и . Pódense actualizar sen ter que construír unha nova imaxe de contedor. Para crear canalizacións facilmente con ensamblaxe de imaxes, podes usar . (Nota. transl.: Usamos unha ferramenta de código aberto para estes fins .)
Un exemplo de actualización da configuración de implementación en Kubernetes usando ConfigMap montado en pods como configuración
3. Evita os contedores privilexiados
Non executas aplicacións como root nos teus servidores, non? Se un atacante entra na aplicación, obterá acceso root. As mesmas consideracións aplícanse a non executar contedores privilexiados. Se precisas cambiar a configuración do host, podes especificar o contenedor capacidades usando a opción en Kubernetes. Se precisa cambiar sysctls, Kubernetes ten para isto. En xeral, intente sacar o máximo proveito e contedores sidecar para realizar operacións privilexiadas similares. Non precisan que sexan accesibles nin para o tráfico interno nin para o externo.
Se administras un clúster, podes usar por restricións ao uso de contedores privilexiados.
4. Evite executar como root
Xa se comentaron os contedores privilexiados, pero aínda será mellor se, ademais disto, non executas aplicacións dentro do contedor como root. Se un atacante atopa unha vulnerabilidade remota nunha aplicación con dereitos de root que permite a execución de código, despois de que pode saír do contedor a través dunha vulnerabilidade aínda descoñecida, gañará root no host.
A mellor forma de evitar isto é non executar nada como root en primeiro lugar. Para iso, pode utilizar a directiva USER в Dockerfile ou runAsUser en Kubernetes. O administrador do clúster tamén pode configurar o comportamento de aplicación mediante .
5. Fai que a aplicación sexa fácil de supervisar
Do mesmo xeito que o rexistro, o seguimento é unha parte integrante da xestión de aplicacións. Unha solución de monitorización popular na comunidade de Kubernetes é - un sistema que detecta automaticamente pods e servizos que requiren seguimento. (Nota. transl.: Vexa tamén o noso sobre o tema do seguimento mediante Prometheus e Kubernetes). é capaz de supervisar clústeres de Kubernetes e inclúe a súa propia versión de Prometheus para o seguimento de aplicacións.
Panel de control de Kubernetes en Stackdriver
Prometheus espera que a aplicación reenvíe métricas ao punto final HTTP. Dispoñible para iso . O mesmo formato é usado por outras ferramentas como и .
6. Fai dispoñible o estado de saúde da aplicación
A xestión de aplicacións en produción é axudada pola súa capacidade para comunicar o seu estado a todo o sistema. A aplicación está en execución? Está ben? Estás preparado para recibir tráfico? Como se está comportando? A forma máis común de resolver este problema é implementar controis de saúde (cheques de saúde). Kubernetes ten dous tipos: .
Para sonda de vivacidade (verificacións de vitalidade) a aplicación debe ter un punto final HTTP que devolva unha resposta "200 OK" se é funcional e se cumpren as súas dependencias básicas. Para sonda de preparación (verificacións de preparación do servizo) a aplicación debe ter outro punto final HTTP que devolva unha resposta "200 OK" se a aplicación está nun estado saudable, se completaron os pasos de inicialización e calquera solicitude válida non produce un erro. Kubernetes só dirixirá o tráfico ao contedor se a aplicación está lista segundo estas comprobacións. Pódense fusionar dous puntos finais se non hai diferenzas entre os estados de vivacidade e de preparación.
Podes ler máis sobre isto no artigo relacionado de Sandeep Dinesh, defensor do programador de Google: "».
7. Escolla coidadosamente a súa versión da imaxe
A maioría das imaxes públicas e privadas usan un sistema de etiquetado similar ao descrito en . Se a imaxe usa un sistema próximo a , é necesario ter en conta as especificidades da etiquetaxe. Por exemplo, etiqueta latest pode moverse con frecuencia dunha imaxe a outra; non se pode confiar nel se precisa de construcións e instalacións previsibles e repetibles.
Podes usar a etiqueta X.Y.Z (case sempre non se modifican), pero neste caso, fai un seguimento de todos os parches e actualizacións da imaxe. Se a imaxe que estás a usar ten unha etiqueta X.Y, esta é unha boa opción para a media dourada. Ao escollelo, recibe parches automaticamente e ao mesmo tempo confía na versión estable da aplicación.
PS do tradutor
Lea tamén no noso blog:
- «»;
- «»;
- «»;
- «» (recensión e vídeo reportaxe);
- «» (recensión e vídeo reportaxe);
- «» (recensión e vídeo reportaxe);
- «» (recensión e vídeo reportaxe);
- «».
Fonte: www.habr.com