Docker Swarm, Kubernetes en Mesos binne de populêrste kontenerorkestraasjekaders. Yn syn petear fergeliket Arun Gupta de folgjende aspekten fan Docker, Swarm en Kubernetes:
- Lokale ûntwikkeling.
- Ynsetfunksjes.
- Multi-container applikaasjes.
- Service ûntdekking.
- Skaalfergrutting fan de tsjinst.
- Run-ien kear taken.
- Yntegraasje mei Maven.
- "Rolling" update.
- It meitsjen fan in Couchbase-databasekluster.
As resultaat krije jo in dúdlik begryp fan wat elk orkestraasje-ark te bieden hat en learje hoe't jo dizze platfoarms effektyf kinne brûke.
Arun Gupta is de haadtechnolooch foar iepenboarne produkten by Amazon Web Services, dy't de Sun, Oracle, Red Hat en Couchbase ûntwikkelersmienskippen foar mear as 10 jier hat ûntwikkele. Hat wiidweidige ûnderfining yn it lieden fan cross-funksjonele teams dy't strategyen ûntwikkelje en ymplementearje foar marketingkampanjes en programma's. Hy late teams fan Sun-yngenieurs, is ien fan 'e oprjochters fan it Java EE-team en de skepper fan' e Amerikaanske tûke fan Devoxx4Kids. Arun Gupta is de skriuwer fan mear as 2 tûzen berjochten yn IT-blogs en hat petearen jûn yn mear as 40 lannen.
Rigel 55 befettet in COUCHBASE_URI dy't wiist op dizze databanktsjinst, dy't ek makke is mei it Kubernetes-konfiguraasjetriem. As jo sjogge op rigel 2, kinne jo sjen soarte: Tsjinst is de tsjinst ik meitsje neamd couchbase-tsjinst, en deselde namme stiet op rigel 4. Hjirûnder binne guon havens.
De kaai rigels binne 6 en 7. Yn tsjinst sis ik: "Hey, dit binne de labels dy't ik sykje!", En dizze labels binne neat mear as fariabele pear nammen, en line 7 wiist op myn couchbase-rs-pod oanfraach. De folgjende binne de havens dy't tagong jouwe ta deselde labels.
Op rigel 19 meitsje ik in nij type ReplicaSet, line 31 befettet de namme fan 'e ôfbylding, en rigels 24-27 wize op de metadata ferbûn mei myn pod. Dit is krekt wat de tsjinst siket en wêr't de ferbining mei makke wurde moat. Oan 'e ein fan' e triem is d'r in soarte fan ferbining tusken rigels 55-56 en 4, sizzende: "brûk dizze tsjinst!"
Dat, ik begjin myn tsjinst as d'r in replika-set is, en om't elke replika-set in eigen poarte hat mei it oerienkommende label, is it opnommen yn 'e tsjinst. Fanút it eachpunt fan in ûntwikkelder neame jo gewoan de tsjinst, dy't dan de set replika's brûkt dy't jo nedich binne.
As gefolch haw ik in WildFly-pod dy't kommunisearret mei de databank-backend fia Couchbase Service. Ik kin de frontend brûke mei ferskate WildFly-pods, dy't ek kommunisearret mei de couchbase-backend fia de couchbase-tsjinst.
Letter sille wy sjen hoe't in tsjinst bûten it kluster kommunisearret fia syn IP-adres mei eleminten dy't binnen it kluster lizze en in ynterne IP-adres hawwe.
Dat, steatleaze konteners binne geweldich, mar hoe goed is it om steatlike konteners te brûken? Litte wy nei de systeemynstellingen sjen foar steatlike, as persistente konteners. Yn Docker binne d'r 4 ferskillende oanpakken foar yndieling fan gegevens opslach wêrop jo oandacht moatte besteegje. De earste is Implicit Per-Container, wat betsjut dat by it brûken fan couchbase, MySQL of MyDB satatefolle konteners, se allegear begjinne mei de standert Sandbox. Dat is, alles dat is opslein yn 'e databank wurdt opslein yn' e kontener sels. As de kontener ferdwynt, ferdwine de gegevens dêrmei.
De twadde is Explicit Per-Container, as jo in spesifike opslach meitsje mei it docker-volumint meitsje kommando en bewarje gegevens dêryn. De tredde Per-Host-oanpak is ferbûn mei opslachmapping, as alles dat yn 'e kontener is opslein tagelyk op' e host duplikearre wurdt. As de kontener mislearret, sille de gegevens op 'e host bliuwe. Dat lêste is it gebrûk fan ferskate Multi-Host-hosts, wat oan te rieden is yn 'e produksjestadium fan ferskate oplossingen. Litte wy sizze dat jo konteners mei jo applikaasjes op 'e host rinne, mar jo wolle jo gegevens earne op it ynternet opslaan, en dêrfoar brûke jo automatyske mapping foar ferspraat systemen.
Elk fan dizze metoaden brûkt in spesifike opslachlokaasje. Implisite en eksplisite Per-Container bewarje gegevens op 'e host by /var/lib/docker/volumes. By it brûken fan de Per-Host-metoade wurdt de opslach yn 'e kontener monteard, en de kontener sels wurdt op' e host monteard. Foar multihosts kinne oplossings lykas Ceph, ClusterFS, NFS, ensfh.
As in oanhâldende kontener mislearret, wurdt de opslachmap yn 'e earste twa gefallen ûnberikber, mar yn' e lêste twa gefallen wurdt tagong behâlden. Yn it earste gefal kinne jo lykwols tagong krije ta it repository fia in Docker-host dy't rint op in firtuele masine. Yn it twadde gefal sille de gegevens ek net ferlern gean, om't jo in eksplisite opslach makke hawwe.
As de host mislearret, is de opslachmap net beskikber yn 'e earste trije gefallen; yn it lêste gefal wurdt de ferbining mei de opslach net ûnderbrutsen. Uteinlik is de dielde funksje folslein útsletten foar opslach yn it earste gefal en is mooglik yn 'e rest. Yn it twadde gefal kinne jo opslach diele ôfhinklik fan oft jo databank ferdielde opslach stipet of net. Yn it gefal fan Per-Host is gegevensdistribúsje allinich mooglik op in opjûne host, en foar in multihost wurdt it fersoarge troch klusterútwreiding.
Dit moat rekken holden wurde by it meitsjen fan steatlike konteners. In oar brûkber Docker-ark is it Volume-plugin, dat wurket op it prinsipe fan "batterijen oanwêzich, mar moatte wurde ferfongen." As jo in Docker-kontener begjinne, seit it: "Hey, as jo ienris in kontener begjinne mei in database, kinne jo jo gegevens yn dizze kontener opslaan!" Dit is de standertfunksje, mar jo kinne it feroarje. Dizze plugin lit jo in netwurkstasjon of wat ferlykber brûke ynstee fan in kontenerdatabase. It omfettet in standert stjoerprogramma foar host-basearre opslach en lit konteneryntegraasje mei eksterne opslachsystemen lykas Amazon EBS, Azure Storage en GCE Persistent skiven.
De folgjende slide toant de arsjitektuer fan it Docker Volume-plugin.
De blauwe kleur stiet foar de Docker-kliïnt dy't ferbûn is mei de blauwe Docker-host, dy't in Lokale opslachmotor hat dy't jo konteners foarsjocht foar it opslaan fan gegevens. Grien jout de Plugin Client en Plugin Daemon oan, dy't ek ferbûn binne mei de host. Se jouwe de kâns om gegevens te bewarjen yn netwurk opslach fan it type Storage Backend dat jo nedich binne.
De Docker Volume-plugin kin brûkt wurde mei Portworx-opslach. De PX-Dev-module is eins in kontener dy't jo útfiere dy't ferbynt mei jo Docker-host en lit jo maklik gegevens op Amazon EBS opslaan.
De Portworx-kliïnt lit jo de status kontrolearje fan ferskate opslachkonteners dy't ferbûn binne mei jo host. As jo myn blog besykje, kinne jo lêze hoe't jo it measte út Portworx kinne meitsje mei Docker.
It konsept fan opslach yn Kubernetes is fergelykber mei Docker en wurdt fertsjintwurdige troch mappen dy't tagonklik binne foar jo kontener yn in pod. Se binne ûnôfhinklik fan it libben fan elke kontener. De meast foarkommende opslachtypen beskikber binne hostPath, nfs, awsElasticBlockStore, en gsePersistentDisk. Litte wy ris sjen hoe't dizze winkels wurkje yn Kubernetes. Typysk, it proses fan it ferbinen se bestiet út 3 stappen.
De earste is dat immen oan 'e netwurkside, meastentiids in behearder, jo persistente opslach leveret. D'r is in oerienkommende PersistentVolume-konfiguraasjetriem foar dit. Folgjende skriuwt de applikaasje-ûntwikkelder in konfiguraasjetriem neamd PersistentVolumeClaim, as in PVC-opslachfersyk, dat seit: "Ik haw 50 GB ferdielde opslach foarsjoen, mar om oare minsken ek syn kapasiteit te brûken, fertel ik dizze PVC dat ik op it stuit hawwe mar 10 GB nedich". Uteinlik is de tredde stap dat jo fersyk is monteard as opslach, en de applikaasje dy't de pod hat, of replika-set, of wat ferlykber, begjint it te brûken. It is wichtich om te betinken dat dit proses bestiet út de 3 neamde stappen en is skalberber.
De folgjende dia lit de Kubernetes Persistence Container fan 'e AWS-arsjitektuer sjen.
Binnen de brune rjochthoeke dat stiet foar de Kubernetes kluster, der is ien master knooppunt en twa arbeider knooppunten, oanjûn yn giel. Ien fan 'e arbeidersknooppunten befettet in oranje pod, opslach, in replika-controller, en in griene Docker Couchbase-kontener. Binnen it kluster, boppe de knooppunten, jout in pearse rjochthoek de tsjinst oan dy't fan bûten tagonklik is. Dizze arsjitektuer wurdt oanrikkemandearre foar it bewarjen fan gegevens op it apparaat sels. As it nedich is, kin ik myn gegevens opslaan yn EBS bûten it kluster, lykas werjûn yn 'e folgjende dia. Dit is in typysk model foar skaalfergrutting, mar d'r is in finansjeel aspekt te beskôgjen by it brûken - it opslaan fan gegevens earne op it netwurk kin djoerder wêze dan op in host. By it kiezen fan oplossings foar containerisaasje is dit ien fan 'e gewichtige arguminten.
Krekt as by Docker kinne jo persistente Kubernetes-konteners brûke mei Portworx.
Dit is wat yn hjoeddeistige Kubernetes 1.6-terminology in "StatefulSet" neamd wurdt - in manier om te wurkjen mei Stateful-applikaasjes dy't eveneminten ferwurket oer it stopjen fan de Pod en it útfieren fan Graceful Shutdown. Yn ús gefal binne sokke applikaasjes databases. Yn myn blog kinne jo lêze hoe't jo in StatefulSet kinne meitsje yn Kubernetes mei Portworx.
Litte wy prate oer it ûntwikkelingsaspekt. Lykas ik sei, Docker hat 2 ferzjes - CE en EE, yn it earste gefal hawwe wy it oer in stabile ferzje fan 'e Community Edition, dy't ien kear elke 3 moannen wurdt bywurke, yn tsjinstelling ta de moanlikse bywurke ferzje fan EE. Jo kinne Docker downloade foar Mac, Linux of Windows. Ienris ynstalleare sil Docker automatysk bywurkje en it is heul maklik om te begjinnen.
Foar Kubernetes leaver ik de Minikube-ferzje - it is in goede manier om te begjinnen mei it platfoarm troch in kluster te meitsjen op ien knooppunt. Om klusters fan ferskate knopen te meitsjen, is de kar fan ferzjes breder: dit binne kops, kube-aws (CoreOS + AWS), kube-up (ferâldere). As jo op syk binne nei AWS-basearre Kubernetes te brûken, ried ik oan om mei te dwaan oan de AWS SIG, dy't elke freed online komt en in ferskaat oan nijsgjirrige materialen publisearret oer wurkjen mei AWS Kubernetes.
Litte wy sjen hoe't Rolling Update wurdt útfierd op dizze platfoarms. As d'r in kluster is fan ferskate knopen, dan brûkt it in spesifike ferzje fan 'e ôfbylding, bygelyks WildFly:1. In rôljende fernijing betsjut dat de ôfbyldingferzje opienfolgjend wurdt ferfongen troch in nije op elke knooppunt, ien nei de oare.
Om dit te dwaan, brûk ik it kommando docker tsjinst update (tsjinst namme), wêryn ik spesifisearje de nije ferzje fan de WildFly: 2 ôfbylding en de update metoade update-parallelism 2. It nûmer 2 betsjut dat it systeem sil bywurkje 2 applikaasje ôfbyldings tagelyk, dan in 10-twadde update fertraging 10s, wêrnei't de folgjende 2 bylden wurde fernijd op 2 mear knopen, etc. Dit ienfâldige rôljende fernijingsmeganisme wurdt jo levere as ûnderdiel fan Docker.
Yn Kubernetes wurket in rôljende update sa. De replikaasjekontrôler rc makket in set replika's fan deselde ferzje, en elke pod yn dizze webapp-rc wurdt foarsjoen fan in label dat leit yn etcd. As ik in pod nedich bin, brûk ik de applikaasjetsjinst om tagong te krijen ta it etcd-repository, dat my de pod foarsjocht mei it opjûne label.
Yn dit gefal hawwe wy 3 pods yn 'e Replikaasjekontrôler dy't de applikaasje WildFly ferzje 1 útfiert. By it bywurkjen op 'e eftergrûn wurdt in oare replikaasjekontrôler makke mei deselde namme en yndeks oan 'e ein - - xxxxx, wêrby x willekeurige nûmers binne, en mei deselde labels. No hat Application Service trije pods mei de âlde ferzje fan 'e applikaasje en trije pods mei de nije ferzje yn' e nije Replikaasje-controller. Hjirnei wurde de âlde pods wiske, de replikaasjekontrôler mei de nije pods wurdt omneamd en yn wurking set.
Litte wy trochgean nei tafersjoch. Docker hat in protte ynboude tafersjochkommando's. Bygelyks, de kommandorigelynterface foar docker-containerstatistiken lit jo elke sekonde ynformaasje werjaan oer de steat fan konteners oan 'e konsole - prosessorgebrûk, skiifgebrûk, netwurklading. It Docker Remote API-ark jout gegevens oer hoe't de kliïnt kommunisearret mei de tsjinner. It brûkt ienfâldige kommando's, mar is basearre op de Docker REST API. Yn dit gefal betsjutte de wurden REST, Flash, Remote itselde ding. As jo kommunisearje mei de host, it is in REST API. De Docker Remote API lit jo mear ynformaasje krije oer it útfieren fan konteners. Myn blog sketst de details fan it brûken fan dizze tafersjoch mei Windows Server.
It kontrolearjen fan docker-systeemeveneminten by it útfieren fan in multi-host-kluster makket it mooglik om gegevens te krijen oer in hostcrash of in kontenerûngelok op in spesifike host, skaaltsjinsten, en sa. Begjinnend mei Docker 1.20 omfettet it Prometheus, dy't einpunten ynbêde yn besteande applikaasjes. Hjirmei kinne jo metriken fia HTTP ûntfange en se werjaan op dashboards.
In oare tafersjochfunksje is cAdvisor (koart foar konteneradviseur). It analysearret en leveret gegevens oer gebrûk fan boarnen en prestaasjes fan rinnende konteners, en leveret Prometheus-metriken direkt út it fak. It spesjale ding oer dit ark is dat it allinich gegevens foar de lêste 60 sekonden leveret. Dêrom moatte jo dizze gegevens kinne sammelje en yn in databank pleatse, sadat jo in lange termyn proses kinne kontrolearje. It kin ek brûkt wurde om dashboardmetriken grafysk wer te jaan mei Grafana of Kibana. Myn blog hat in detaillearre beskriuwing fan hoe't jo cAdvisor brûke om konteners te kontrolearjen mei it Kibana-dashboard.
De folgjende dia lit sjen hoe't de Prometheus-einpuntútfier der útsjocht en de metriken dy't beskikber binne om te werjaan.
Linksûnder sjogge jo metriken foar HTTP-oanfragen, antwurden, ensfh., Rjochts is har grafyske werjefte.
Kubernetes omfettet ek ynboude monitoring-ark. Dizze slide toant in typysk kluster mei ien master en trije wurkknooppunten.
Elk fan 'e wurkknooppunten befettet in automatysk lansearre cAdvisor. Derneist is d'r Heapster, in systeem foar kontrôle fan prestaasjes en metriken dy't kompatibel is mei Kubernetes ferzje 1.0.6 en heger. Heapster lit jo net allinich prestaasjemetriken fan workloads, pods en konteners sammelje, mar ek eveneminten en oare sinjalen generearre troch it heule kluster. Om gegevens te sammeljen, praat it mei de Kubelet fan elke pod, bewarret de ynformaasje automatysk yn 'e InfluxDB-database, en jout it as metriken nei it Grafana-dashboard. Hâld lykwols yn gedachten dat as jo miniKube brûke, dizze funksje net standert beskikber is, dus jo moatte tafoegings brûke foar tafersjoch. Dat it hinget allegear ôf fan wêr't jo de konteners útfiere en hokker monitoring-ark jo standert kinne brûke en dy't jo moatte ynstallearje as aparte tafoegings.
De folgjende dia toant Grafana-dashboards dy't de rinnende status fan myn konteners sjen litte. D'r binne hjir in protte nijsgjirrige gegevens. Fansels binne d'r in protte kommersjele Docker- en Kubernetes-prosesmonitoring-ark, lykas SysDig, DataDog, NewRelic. Guon fan harren hawwe in fergese proefperioade fan 30 jier, dus jo kinne besykje dejinge te finen dy't it bêste by jo past. Persoanlik brûke ik leaver SysDig en NewRelic, dy't goed yntegrearje mei Kubernetes. D'r binne ark dy't like goed yntegrearje yn sawol Docker- as Kubernetes-platfoarms.
Guon advertinsjes 🙂
Tankewol foar it bliuwen by ús. Hâld jo fan ús artikels? Wolle jo mear ynteressante ynhâld sjen? Stypje ús troch in bestelling te pleatsen of oan te befeljen oan freonen, , in unike analoog fan servers op yngongsnivo, dy't troch ús foar jo útfûn is: (beskikber mei RAID1 en RAID10, oant 24 kearnen en oant 40GB DDR4).
Dell R730xd 2 kear goedkeaper yn Equinix Tier IV data sintrum yn Amsterdam? Allinne hjir yn Nederlân! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fan $99! Lêze oer
Boarne: www.habr.com