Docker Swarm, Kubernetes e Mesos son os marcos de orquestración de contedores máis populares. Na súa charla, Arun Gupta compara os seguintes aspectos de Docker, Swarm e Kubernetes:
- Desenvolvemento local.
- Funcións de despregue.
- Aplicacións de múltiples contedores.
- Descubrimento do servizo.
- Ampliación do servizo.
- Tarefas dunha vez.
- Integración con Maven.
- Actualización "Rolling".
- Creando un clúster de bases de datos Couchbase.
Como resultado, obterás unha comprensión clara do que ofrece cada ferramenta de orquestración e aprenderás a utilizar estas plataformas de forma eficaz.
Arun Gupta é o tecnólogo xefe de produtos de código aberto en Amazon Web Services, que leva máis de 10 anos desenvolvendo as comunidades de desenvolvedores Sun, Oracle, Red Hat e Couchbase. Ten unha ampla experiencia traballando na dirección de equipos multifuncionais que desenvolven e implementan estratexias para campañas e programas de mercadotecnia. Dirixiu equipos de enxeñeiros de Sun, é un dos fundadores do equipo Java EE e o creador da filial estadounidense de Devoxx4Kids. Arun Gupta é o autor de máis de 2 mil publicacións en blogs de TI e deu charlas en máis de 40 países.
A liña 55 contén un COUCHBASE_URI que apunta a este servizo de base de datos, que tamén se creou mediante o ficheiro de configuración de Kubernetes. Se miras a liña 2, podes ver amable: O servizo é o servizo que estou creando chamado couchbase-service, e o mesmo nome aparece na liña 4. Abaixo amósanse algúns portos.
As liñas clave son 6 e 7. No servizo digo: "¡Oe, estas son as etiquetas que estou buscando!", e estas etiquetas non son máis que nomes de pares variables, e a liña 7 apunta ao meu couchbase-rs-pod aplicación. Os seguintes son os portos que proporcionan acceso a estas mesmas etiquetas.
Na liña 19 creo un novo tipo ReplicaSet, a liña 31 contén o nome da imaxe e as liñas 24-27 apuntan aos metadatos asociados co meu pod. Isto é exactamente o que busca o servizo e con que se debe establecer a conexión. Ao final do ficheiro hai algún tipo de conexión entre as liñas 55-56 e 4, dicindo: "use este servizo!"
Entón, inicio o meu servizo cando hai un conxunto de réplicas, e como cada conxunto de réplicas ten o seu propio porto coa etiqueta correspondente, está incluído no servizo. Desde o punto de vista dun programador, simplemente chamas ao servizo, que logo usa o conxunto de réplicas que necesitas.
Como resultado, teño un pod WildFly que se comunica co backend da base de datos a través do servizo Couchbase. Podo usar o frontend con varias pods WildFly, que tamén se comunica co backend couchbase a través do servizo couchbase.
Máis adiante veremos como un servizo situado fóra do clúster se comunica a través do seu enderezo IP con elementos que están situados dentro do clúster e teñen un enderezo IP interno.
Entón, os contedores sen estado son xeniais, pero que bo é usar contedores con estado? Vexamos a configuración do sistema para contedores con estado ou persistentes. En Docker, hai 4 enfoques diferentes para o deseño de almacenamento de datos aos que debes prestar atención. O primeiro é Implicit Per-Container, o que significa que cando se usan contedores couchbase, MySQL ou MyDB, todos comezan co Sandbox predeterminado. É dicir, todo o que se almacena na base de datos gárdase no propio contedor. Se o contedor desaparece, os datos desaparecen xunto con el.
O segundo é Explicit Per-Container, cando crea un almacenamento específico co comando docker volume create e almacena datos nel. O terceiro enfoque por host está asociado coa asignación de almacenamento, cando todo o almacenado no contedor duplícase simultaneamente no host. Se o contedor falla, os datos permanecerán no host. Este último é o uso de varios hosts Multi-Host, o que é recomendable na fase de produción de varias solucións. Digamos que os teus contedores coas túas aplicacións están a executarse no host, pero queres almacenar os teus datos nalgún lugar de Internet e para iso utilizas a asignación automática para sistemas distribuídos.
Cada un destes métodos usa un lugar de almacenamento específico. Os datos implícitos e explícitos por contedor almacenan no host en /var/lib/docker/volumes. Cando se utiliza o método Por-Host, o almacenamento está montado dentro do recipiente e o propio recipiente está montado no host. Para multihosts, pódense usar solucións como Ceph, ClusterFS, NFS, etc.
Se un contenedor persistente falla, o directorio de almacenamento pasa a ser inaccesible nos dous primeiros casos, pero nos dous últimos casos mantense o acceso. Non obstante, no primeiro caso, pode acceder ao repositorio a través dun host Docker que se executa nunha máquina virtual. No segundo caso, tampouco se perderán os datos, porque creaches un almacenamento explícito.
Se o host falla, o directorio de almacenamento non está dispoñible nos tres primeiros casos; no último caso, a conexión co almacenamento non se interrompe. Finalmente, a función compartida está completamente excluída para o almacenamento no primeiro caso e é posible no resto. No segundo caso, pode compartir almacenamento dependendo de se a súa base de datos admite almacenamento distribuído ou non. No caso de Per-Host, a distribución de datos só é posible nun host determinado e, para un multihost, é proporcionada pola expansión do clúster.
Isto debe terse en conta ao crear contedores con estado. Outra ferramenta útil de Docker é o complemento Volume, que funciona co principio de "baterías presentes, pero deben ser substituídas". Cando inicias un contedor Docker, di: "Ola, unha vez que inicies un contedor cunha base de datos, podes almacenar os teus datos neste contedor!" Esta é a función predeterminada, pero podes cambiala. Este complemento permítelle usar unha unidade de rede ou algo similar en lugar dunha base de datos de contedores. Inclúe un controlador predeterminado para o almacenamento baseado no host e permite a integración de contedores con sistemas de almacenamento externos como Amazon EBS, Azure Storage e discos persistentes GCE.
A seguinte diapositiva mostra a arquitectura do complemento Docker Volume.
A cor azul representa o cliente de Docker asociado ao host azul de Docker, que ten un motor de almacenamento local que che proporciona contedores para almacenar datos. O verde indica o cliente de complementos e o daemon de complementos, que tamén están conectados ao host. Ofrecen a oportunidade de almacenar datos no almacenamento de rede do tipo de backend de almacenamento que necesites.
O complemento Docker Volume pódese usar co almacenamento Portworx. O módulo PX-Dev é en realidade un contedor que executas que se conecta ao teu servidor Docker e permítelle almacenar facilmente datos en Amazon EBS.
O cliente Portworx permítelle supervisar o estado de varios contedores de almacenamento que están conectados ao seu servidor. Se visitas o meu blog, podes ler como sacar o máximo proveito de Portworx con Docker.
O concepto de almacenamento en Kubernetes é semellante ao de Docker e está representado por directorios aos que se pode acceder o teu contedor nun pod. Son independentes da vida útil de calquera recipiente. Os tipos de almacenamento máis comúns dispoñibles son hostPath, nfs, awsElasticBlockStore e gsePersistentDisk. Vexamos como funcionan estas tendas en Kubernetes. Normalmente, o proceso de conexión deles consta de 3 pasos.
O primeiro é que alguén do lado da rede, xeralmente un administrador, ofrécelle almacenamento persistente. Hai un ficheiro de configuración de PersistentVolume correspondente para isto. A continuación, o desenvolvedor da aplicación escribe un ficheiro de configuración chamado PersistentVolumeClaim, ou unha solicitude de almacenamento de PVC, que di: "Teño 50 GB de almacenamento distribuído aprovisionados, pero para que outras persoas tamén usen a súa capacidade, dígolle a este PVC que actualmente só necesita 10 GB". Finalmente, o terceiro paso é que a túa solicitude se monte como almacenamento e a aplicación que teña o pod, ou o conxunto de réplicas, ou algo semellante, comece a usalo. É importante lembrar que este proceso consta dos 3 pasos mencionados e é escalable.
A seguinte diapositiva mostra o contenedor de persistencia de Kubernetes da arquitectura AWS.
Dentro do rectángulo marrón que representa o clúster de Kubernetes, hai un nodo mestre e dous nodos traballadores, indicados en amarelo. Un dos nodos de traballo contén unha cápsula laranxa, almacenamento, un controlador de réplica e un contenedor Docker Couchbase verde. Dentro do clúster, enriba dos nodos, un rectángulo violeta indica o Servizo accesible desde o exterior. Recoméndase esta arquitectura para almacenar datos no propio dispositivo. Se é necesario, podo almacenar os meus datos en EBS fóra do clúster, como se mostra na seguinte diapositiva. Este é un modelo típico de escalado, pero hai que ter en conta un aspecto financeiro ao usalo: almacenar datos nalgún lugar da rede pode ser máis caro que nun host. Á hora de elixir solucións de contenerización, este é un dos argumentos de peso.
Do mesmo xeito que con Docker, podes usar contedores persistentes de Kubernetes con Portworx.
Isto é o que na terminoloxía actual de Kubernetes 1.6 chámase "StatefulSet", unha forma de traballar con aplicacións Stateful que procesa eventos sobre a detención do Pod e a realización de Graceful Shutdown. No noso caso, este tipo de aplicacións son bases de datos. No meu blog podes ler como crear un StatefulSet en Kubernetes usando Portworx.
Falemos do aspecto do desenvolvemento. Como dixen, Docker ten 2 versións - CE e EE, no primeiro caso estamos a falar dunha versión estable da Community Edition, que se actualiza unha vez cada 3 meses, en contraste coa versión actualizada mensualmente de EE. Podes descargar Docker para Mac, Linux ou Windows. Unha vez instalado, Docker actualizarase automaticamente e é moi sinxelo comezar.
Para Kubernetes, prefiro a versión de Minikube; é unha boa forma de comezar coa plataforma creando un clúster nun único nodo. Para crear clusters de varios nodos, a elección de versións é máis ampla: estas son kops, kube-aws (CoreOS+AWS), kube-up (desactualizada). Se queres utilizar Kubernetes baseado en AWS, recoméndoche unirte ao AWS SIG, que se reúne en liña todos os venres e publica unha variedade de materiais interesantes sobre o traballo con AWS Kubernetes.
Vexamos como se realiza Rolling Update nestas plataformas. Se hai un clúster de varios nodos, entón usa unha versión específica da imaxe, por exemplo, WildFly:1. Unha actualización continua significa que a versión da imaxe substitúese secuencialmente por unha nova en cada nodo, un despois do outro.
Para iso, uso o comando docker service update (nome do servizo), no que especifico a nova versión da imaxe WildFly:2 e o método de actualización update-parallelism 2. O número 2 significa que o sistema actualizará 2 imaxes da aplicación. simultaneamente, despois un atraso de actualización de 10 segundos de 10 segundos, despois do cal as próximas 2 imaxes actualizaranse en 2 nodos máis, etc. Este sinxelo mecanismo de actualización continua ofrécese como parte de Docker.
En Kubernetes, unha actualización continua funciona así. O controlador de replicación rc crea un conxunto de réplicas da mesma versión e cada pod desta webapp-rc ten unha etiqueta situada en etcd. Cando necesito un pod, uso o servizo de aplicacións para acceder ao repositorio etcd, que me proporciona o pod mediante a etiqueta especificada.
Neste caso, temos 3 pods no controlador de replicación que executa a aplicación WildFly versión 1. Cando se actualiza en segundo plano, créase outro controlador de replicación co mesmo nome e índice ao final - - xxxxx, onde x son números aleatorios e coas mesmas etiquetas. Agora Application Service ten tres pods coa versión antiga da aplicación e tres pods coa nova versión no novo controlador de replicación. Despois disto, elimínanse os antigos pods, o controlador de replicación cos novos pods é renomeado e posto en funcionamento.
Pasemos ao seguimento. Docker ten moitos comandos de monitorización incorporados. Por exemplo, a interface de liña de comandos docker container stats permítelle mostrar información sobre o estado dos contedores na consola cada segundo: uso do procesador, uso do disco, carga da rede. A ferramenta Docker Remote API ofrece datos sobre como se comunica o cliente co servidor. Usa comandos sinxelos, pero baséase na API REST de Docker. Neste caso, as palabras REST, Flash, Remote significan o mesmo. Cando te comunicas co host, é unha API REST. A API de Docker Remote permítelle obter máis información sobre a execución de contedores. O meu blog describe os detalles do uso desta vixilancia con Windows Server.
A supervisión dos eventos do sistema docker cando se executa un clúster de varios hosts permite obter datos sobre un fallo do host ou un fallo do contenedor nun host específico, escalar servizos e similares. A partir de Docker 1.20, inclúe Prometheus, que incorpora puntos finais nas aplicacións existentes. Isto permítelle recibir métricas a través de HTTP e mostralas en paneis.
Outra función de monitorización é cAdvisor (abreviatura de asesor de contedores). Analiza e proporciona datos de uso e rendemento dos recursos dos contedores en execución, proporcionando métricas de Prometheus de inmediato. O especial desta ferramenta é que só proporciona datos dos últimos 60 segundos. Polo tanto, cómpre poder recoller estes datos e poñelos nunha base de datos para que poida supervisar un proceso a longo prazo. Tamén se pode usar para mostrar gráficamente as métricas do panel usando Grafana ou Kibana. O meu blog ten unha descrición detallada de como usar cAdvisor para supervisar os contedores mediante o panel de control de Kibana.
A seguinte diapositiva mostra como é a saída do punto final de Prometheus e as métricas dispoñibles para mostrar.
Na parte inferior esquerda ves métricas de solicitudes HTTP, respostas, etc., á dereita a súa visualización gráfica.
Kubernetes tamén inclúe ferramentas de monitorización integradas. Esta diapositiva mostra un clúster típico que contén un nodo mestre e tres nodos traballadores.
Cada un dos nodos de traballo contén un cAdvisor iniciado automaticamente. Ademais, hai Heapster, un sistema de seguimento do rendemento e recollida de métricas compatible con Kubernetes versión 1.0.6 e superior. Heapster permítelle recoller non só métricas de rendemento de cargas de traballo, pods e contedores, senón tamén eventos e outros sinais xerados por todo o clúster. Para recoller datos, fala co Kubelet de cada pod, almacena automaticamente a información na base de datos InfluxDB e envíaa como métricas ao panel de Grafana. Non obstante, ten en conta que se estás a usar miniKube, esta función non está dispoñible por defecto, polo que terás que usar complementos para a monitorización. Polo tanto, todo depende de onde executes os contedores e que ferramentas de vixilancia podes usar por defecto e que necesitas instalar como complementos separados.
A seguinte diapositiva mostra os paneis de Grafana que mostran o estado de funcionamento dos meus contedores. Aquí hai moitos datos interesantes. Por suposto, hai moitas ferramentas comerciais de seguimento de procesos de Docker e Kubernetes, como SysDig, DataDog, NewRelic. Algúns deles teñen un período de proba gratuíto de 30 anos, polo que podes probar e atopar o que máis che conveña. Persoalmente, prefiro usar SysDig e NewRelic, que se integran ben con Kubernetes. Hai ferramentas que se integran igual de ben nas plataformas Docker e Kubernetes.
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