Docker Swarm, Kubernetes i Mesos són els marcs d'orquestració de contenidors més populars. En la seva xerrada, Arun Gupta compara els aspectes següents de Docker, Swarm i Kubernetes:
- Desenvolupament local.
- Funcions de desplegament.
- Aplicacions multicontenidor.
- Descobriment de serveis.
- Ampliació del servei.
- Tasques d'execució única.
- Integració amb Maven.
- Actualització "Rolling".
- Creació d'un clúster de bases de dades Couchbase.
Com a resultat, obtindreu una comprensió clara del que ofereix cada eina d'orquestració i aprendreu a utilitzar aquestes plataformes de manera eficaç.
Arun Gupta és el tecnòleg cap de productes de codi obert d'Amazon Web Services, que ha estat desenvolupant les comunitats de desenvolupadors Sun, Oracle, Red Hat i Couchbase durant més de 10 anys. Té una àmplia experiència treballant en el lideratge d'equips multifuncionals desenvolupant i implementant estratègies per a campanyes i programes de màrqueting. Va dirigir equips d'enginyers de Sun, és un dels fundadors de l'equip Java EE i el creador de la branca nord-americana de Devoxx4Kids. Arun Gupta és l'autor de més de 2 mil publicacions en blocs de TI i ha donat xerrades a més de 40 països.
La línia 55 conté un COUCHBASE_URI que apunta a aquest servei de base de dades, que també es va crear mitjançant el fitxer de configuració de Kubernetes. Si mireu la línia 2, podeu veure el tipus: El servei és el servei que estic creant anomenat couchbase-service, i el mateix nom apareix a la línia 4. A continuació es mostren alguns ports.
Les línies clau són 6 i 7. En servei dic: "Ei, aquestes són les etiquetes que estic buscant!", i aquestes etiquetes no són més que noms de parelles variables, i la línia 7 apunta al meu couchbase-rs-pod aplicació. A continuació es mostren els ports que proporcionen accés a aquestes mateixes etiquetes.
A la línia 19, creo un nou tipus ReplicaSet, la línia 31 conté el nom de la imatge i les línies 24-27 apunten a les metadades associades al meu pod. Això és exactament el que busca el servei i amb què s'ha d'establir la connexió. Al final del fitxer hi ha algun tipus de connexió entre les línies 55-56 i 4, que diu: "utilitza aquest servei!"
Per tant, començo el meu servei quan hi ha un conjunt de rèpliques, i com que cada conjunt de rèpliques té el seu propi port amb l'etiqueta corresponent, s'inclou al servei. Des del punt de vista d'un desenvolupador, simplement truqueu al servei, que després utilitza el conjunt de rèpliques que necessiteu.
Com a resultat, tinc un pod WildFly que es comunica amb el backend de la base de dades mitjançant el servei Couchbase. Puc utilitzar la interfície amb diversos pods WildFly, que també es comunica amb el backend de couchbase mitjançant el servei de couchbase.
Més endavant veurem com un servei situat fora del clúster es comunica mitjançant la seva adreça IP amb elements que es troben dins del clúster i tenen una adreça IP interna.
Per tant, els contenidors sense estat són excel·lents, però què tan bo és utilitzar contenidors amb estat? Vegem la configuració del sistema per als contenidors amb estat o persistents. A Docker, hi ha 4 enfocaments diferents per al disseny d'emmagatzematge de dades als quals hauríeu de prestar atenció. El primer és Implicit Per-Container, el que significa que quan s'utilitzen contenidors couchbase, MySQL o MyDB, tots comencen amb el Sandbox predeterminat. És a dir, tot el que s'emmagatzema a la base de dades s'emmagatzema al propi contenidor. Si el contenidor desapareix, les dades desapareixen juntament amb ell.
El segon és Explicit Per-Container, quan creeu un emmagatzematge específic amb l'ordre de creació de volum docker i emmagatzemeu-hi dades. El tercer enfocament per host s'associa amb el mapeig d'emmagatzematge, quan tot el que s'emmagatzema al contenidor es duplica simultàniament a l'amfitrió. Si el contenidor falla, les dades romandran a l'amfitrió. Aquest últim és l'ús de diversos hosts Multi-Host, que és aconsellable en l'etapa de producció de diverses solucions. Suposem que els vostres contenidors amb les vostres aplicacions s'estan executant a l'amfitrió, però voleu emmagatzemar les vostres dades en algun lloc d'Internet i, per a això, utilitzeu el mapeig automàtic per a sistemes distribuïts.
Cadascun d'aquests mètodes utilitza una ubicació d'emmagatzematge específica. Les dades implícites i explícites per contenidor emmagatzemen a l'amfitrió a /var/lib/docker/volumes. Quan s'utilitza el mètode Per-Host, l'emmagatzematge es munta dins del contenidor i el mateix contenidor es munta a l'amfitrió. Per a multihosts, es poden utilitzar solucions com Ceph, ClusterFS, NFS, etc.
Si falla un contenidor persistent, el directori d'emmagatzematge esdevé inaccessible en els dos primers casos, però en els dos últims casos es manté l'accés. Tanmateix, en el primer cas, podeu accedir al repositori mitjançant un amfitrió Docker que s'executa en una màquina virtual. En el segon cas, tampoc es perdran les dades, perquè heu creat un emmagatzematge explícit.
Si l'amfitrió falla, el directori d'emmagatzematge no està disponible en els tres primers casos; en l'últim cas, la connexió amb l'emmagatzematge no s'interromp. Finalment, la funció compartida queda totalment exclosa per a l'emmagatzematge en el primer cas i és possible en la resta. En el segon cas, podeu compartir emmagatzematge en funció de si la vostra base de dades admet emmagatzematge distribuït o no. En el cas de Per-Host, la distribució de dades només és possible en un host determinat, i per a un multihost es proporciona mitjançant l'expansió del clúster.
Això s'ha de tenir en compte a l'hora de crear contenidors amb estat. Una altra eina útil de Docker és el connector de volum, que funciona segons el principi de "bateries presents, però s'han de substituir". Quan inicieu un contenidor Docker, diu: "Ei, un cop inicieu un contenidor amb una base de dades, podeu emmagatzemar les vostres dades en aquest contenidor!" Aquesta és la funció predeterminada, però la podeu canviar. Aquest connector us permet utilitzar una unitat de xarxa o alguna cosa semblant en lloc d'una base de dades de contenidors. Inclou un controlador predeterminat per a l'emmagatzematge basat en l'amfitrió i permet la integració de contenidors amb sistemes d'emmagatzematge externs com ara Amazon EBS, Azure Storage i discs persistents GCE.
La diapositiva següent mostra l'arquitectura del connector Docker Volume.
El color blau representa el client Docker associat a l'amfitrió Docker blau, que té un motor d'emmagatzematge local que us proporciona contenidors per emmagatzemar dades. El verd indica el client del connector i el dimoni del connector, que també estan connectats a l'amfitrió. Ofereixen l'oportunitat d'emmagatzemar dades a l'emmagatzematge de xarxa del tipus de backend d'emmagatzematge que necessiteu.
El connector Docker Volume es pot utilitzar amb l'emmagatzematge Portworx. El mòdul PX-Dev és en realitat un contenidor que executeu que es connecta al vostre amfitrió Docker i us permet emmagatzemar fàcilment dades a Amazon EBS.
El client Portworx us permet supervisar l'estat de diversos contenidors d'emmagatzematge connectats al vostre amfitrió. Si visiteu el meu bloc, podreu llegir com treure el màxim profit de Portworx amb Docker.
El concepte d'emmagatzematge a Kubernetes és similar a Docker i està representat per directoris als quals es pot accedir el contenidor en un pod. Són independents de la vida útil de qualsevol recipient. Els tipus d'emmagatzematge més comuns disponibles són hostPath, nfs, awsElasticBlockStore i gsePersistentDisk. Fem una ullada a com funcionen aquestes botigues a Kubernetes. Normalment, el procés de connexió consta de 3 passos.
El primer és que algú del costat de la xarxa, normalment un administrador, us proporciona emmagatzematge persistent. Hi ha un fitxer de configuració de PersistentVolume corresponent per a això. A continuació, el desenvolupador de l'aplicació escriu un fitxer de configuració anomenat PersistentVolumeClaim, o una sol·licitud d'emmagatzematge de PVC, que diu: "Tinc 50 GB d'emmagatzematge distribuït subministrats, però perquè altres persones també utilitzin la seva capacitat, li dic a aquest PVC que actualment només necessiten 10 GB". Finalment, el tercer pas és que la vostra sol·licitud es munti com a emmagatzematge i l'aplicació que tingui el pod, el conjunt de rèpliques o alguna cosa semblant, comenci a utilitzar-lo. És important recordar que aquest procés consta dels 3 passos esmentats i és escalable.
La diapositiva següent mostra el contenidor de persistència de Kubernetes de l'arquitectura AWS.
Dins del rectangle marró que representa el clúster de Kubernetes, hi ha un node mestre i dos nodes de treball, indicats en groc. Un dels nodes de treball conté una beina taronja, emmagatzematge, un controlador de rèplica i un contenidor verd de Docker Couchbase. Dins del clúster, a sobre dels nodes, un rectangle porpra indica el Servei accessible des de l'exterior. Aquesta arquitectura es recomana per emmagatzemar dades al propi dispositiu. Si cal, puc emmagatzemar les meves dades a EBS fora del clúster, tal com es mostra a la diapositiva següent. Aquest és un model típic d'escalat, però hi ha un aspecte financer a tenir en compte a l'hora d'utilitzar-lo: emmagatzemar dades en algun lloc de la xarxa pot ser més car que en un host. A l'hora d'escollir solucions de contenidorització, aquest és un dels arguments de pes.
Igual que amb Docker, podeu utilitzar contenidors persistents de Kubernetes amb Portworx.
Això és el que en la terminologia actual de Kubernetes 1.6 s'anomena "StatefulSet", una manera de treballar amb aplicacions Stateful que processa esdeveniments sobre aturar el pod i realitzar l'apagada graceful. En el nostre cas, aquestes aplicacions són bases de dades. Al meu bloc podeu llegir com crear un StatefulSet a Kubernetes mitjançant Portworx.
Parlem de l'aspecte del desenvolupament. Com he dit, Docker té 2 versions - CE i EE, en el primer cas estem parlant d'una versió estable de Community Edition, que s'actualitza un cop cada 3 mesos, en contrast amb la versió actualitzada mensual d'EE. Podeu descarregar Docker per a Mac, Linux o Windows. Un cop instal·lat, Docker s'actualitzarà automàticament i és molt fàcil començar.
Per a Kubernetes, prefereixo la versió Minikube: és una bona manera de començar amb la plataforma creant un clúster en un sol node. Per crear clústers de diversos nodes, l'elecció de versions és més àmplia: es tracta de kops, kube-aws (CoreOS+AWS), kube-up (obsolet). Si voleu utilitzar Kubernetes basat en AWS, us recomano unir-vos a l'AWS SIG, que es reuneix en línia cada divendres i publica una varietat de materials interessants sobre el treball amb AWS Kubernetes.
Vegem com es realitza l'actualització continua en aquestes plataformes. Si hi ha un clúster de diversos nodes, s'utilitza una versió específica de la imatge, per exemple, WildFly:1. Una actualització progressiva significa que la versió de la imatge se substitueix seqüencialment per una de nova a cada node, una darrere l'altra.
Per fer-ho, faig servir l'ordre d'actualització del servei docker (nom del servei), en què especifico la nova versió de la imatge WildFly:2 i el mètode d'actualització update-parallelism 2. El número 2 significa que el sistema actualitzarà 2 imatges d'aplicació. al mateix temps, després un retard d'actualització de 10 segons 10 segons, després del qual les dues imatges següents s'actualitzaran en 2 nodes més, etc. Aquest senzill mecanisme d'actualització continua se us proporciona com a part de Docker.
A Kubernetes, una actualització continuada funciona així. El controlador de rèplica rc crea un conjunt de rèpliques de la mateixa versió i cada pod d'aquesta webapp-rc es proporciona amb una etiqueta situada a etcd. Quan necessito un pod, faig servir el servei d'aplicacions per accedir al repositori etcd, que em proporciona el pod mitjançant l'etiqueta especificada.
En aquest cas, tenim 3 pods al controlador de rèplica que executa l'aplicació WildFly versió 1. Quan s'actualitza en segon pla, es crea un altre controlador de rèplica amb el mateix nom i índex al final - - xxxxx, on x són números aleatoris i amb les mateixes etiquetes. Ara Application Service té tres pods amb la versió antiga de l'aplicació i tres pods amb la nova versió al nou controlador de replicació. Després d'això, s'eliminen els pods antics, es canvia el nom del controlador de rèplica amb els pods nous i es posa en funcionament.
Passem al seguiment. Docker té moltes ordres de supervisió integrades. Per exemple, la interfície de línia d'ordres de docker container stats us permet mostrar informació sobre l'estat dels contenidors a la consola cada segon: ús del processador, ús del disc, càrrega de xarxa. L'eina Docker Remote API proporciona dades sobre com es comunica el client amb el servidor. Utilitza ordres senzilles, però es basa en l'API REST de Docker. En aquest cas, les paraules REST, Flash, Remote signifiquen el mateix. Quan us comuniqueu amb l'amfitrió, és una API REST. L'API Docker Remote us permet obtenir més informació sobre l'execució de contenidors. El meu bloc descriu els detalls de l'ús d'aquesta supervisió amb Windows Server.
La supervisió dels esdeveniments del sistema Docker quan s'executa un clúster multiamfitrió permet obtenir dades sobre una fallada de l'amfitrió o una fallada del contenidor en un amfitrió específic, serveis d'escalat i similars. A partir de Docker 1.20, inclou Prometheus, que incorpora els punts finals a les aplicacions existents. Això us permet rebre mètriques mitjançant HTTP i mostrar-les als taulers de control.
Una altra característica de supervisió és cAdvisor (abreviatura de contenidor advisor). Analitza i proporciona dades d'ús i rendiment dels recursos dels contenidors en execució, proporcionant mètriques de Prometheus immediatament. L'especial d'aquesta eina és que només proporciona dades dels últims 60 segons. Per tant, cal poder recollir aquestes dades i posar-les en una base de dades per poder supervisar un procés a llarg termini. També es pot utilitzar per mostrar gràficament les mètriques del tauler mitjançant Grafana o Kibana. El meu bloc té una descripció detallada de com utilitzar cAdvisor per supervisar contenidors mitjançant el tauler de control de Kibana.
La diapositiva següent mostra com és la sortida del punt final de Prometheus i les mètriques disponibles per mostrar.
A la part inferior esquerra veieu mètriques de sol·licituds HTTP, respostes, etc., a la dreta hi ha la seva visualització gràfica.
Kubernetes també inclou eines de monitorització integrades. Aquesta diapositiva mostra un clúster típic que conté un node mestre i tres nodes de treball.
Cadascun dels nodes de treball conté un cAdvisor llançat automàticament. A més, hi ha Heapster, un sistema de control de rendiment i recollida de mètriques compatible amb Kubernetes versió 1.0.6 i superior. Heapster us permet recollir no només mètriques de rendiment de càrregues de treball, pods i contenidors, sinó també esdeveniments i altres senyals generats per tot el clúster. Per recollir dades, parla amb el Kubelet de cada pod, emmagatzema automàticament la informació a la base de dades InfluxDB i l'envia com a mètriques al tauler de Grafana. Tanmateix, tingueu en compte que si feu servir miniKube, aquesta funció no està disponible de manera predeterminada, per la qual cosa haureu d'utilitzar complements per al seguiment. Per tant, tot depèn d'on executeu els contenidors i quines eines de supervisió podeu utilitzar per defecte i quines heu d'instal·lar com a complements separats.
La diapositiva següent mostra els taulers de control de Grafana que mostren l'estat d'execució dels meus contenidors. Aquí hi ha moltes dades interessants. Per descomptat, hi ha moltes eines comercials de seguiment de processos de Docker i Kubernetes, com ara SysDig, DataDog, NewRelic. Alguns d'ells tenen un període de prova gratuït de 30 anys, de manera que podeu provar i trobar el que més us convingui. Personalment, prefereixo utilitzar SysDig i NewRelic, que s'integren bé amb Kubernetes. Hi ha eines que s'integren igual de bé a les plataformes Docker i Kubernetes.
Alguns anuncis 🙂
Gràcies per quedar-te amb nosaltres. T'agraden els nostres articles? Vols veure més contingut interessant? Doneu-nos suport fent una comanda o recomanant als amics, , un anàleg únic dels servidors d'entrada, que vam inventar per a vosaltres: (disponible amb RAID1 i RAID10, fins a 24 nuclis i fins a 40 GB DDR4).
Dell R730xd 2 vegades més barat al centre de dades Equinix Tier IV a Amsterdam? Només aquí als Països Baixos! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gbps 100 TB - a partir de 99 $! Llegeix sobre
Font: www.habr.com