Docker Swarm, Kubernetes og Mesos er de mest populære rammeverkene for containerorkestrering. I sitt foredrag sammenligner Arun Gupta følgende aspekter av hvordan Docker, Swarm og Kubernetes fungerer:
- Lokal utvikling.
- Implementeringsfunksjoner.
- Multibeholderapplikasjoner.
- Tjenesteoppdagelse.
- Tjenesteskalering.
- Run-one-jobber.
- Integrasjon med Maven.
- Rullende oppdatering.
- Opprett en Couchbase-databaseklynge.
Som et resultat vil du få en solid forståelse av hva hvert orkestreringsverktøy har å tilby og lære hvordan du bruker disse plattformene effektivt.
Arun Gupta er Chief Technology Officer for åpen kildekode-produkter hos Amazon Web Services, som har bygget utviklermiljøene Sun, Oracle, Red Hat og Couchbase i over 10 år. Han har lang erfaring med å lede tverrfunksjonelle team som utvikler og implementerer strategier for markedsføringskampanjer og programmer. Han har ledet Sun-ingeniørteam, er et grunnleggende medlem av Java EE-teamet, og er grunnleggeren av den amerikanske Devoxx4Kids-divisjonen. Arun Gupta er forfatteren av over 2 innlegg på IT-blogger og har snakket i over 40 land.
Linje 55 inneholder COUCHBASE_URI som peker til denne databasetjenesten, som også er opprettet ved hjelp av Kubernetes-konfigurasjonsfilen. Hvis du ser på linje 2, kan du se type: Service er tjenesten jeg oppretter under navnet couchbase-service, og det samme navnet er oppført på linje 4. Nedenfor er noen porter.
Nøkkellinjene er 6 og 7. I tjenesten sier jeg «Hei, dette er etikettene jeg leter etter!» og disse etikettene er ikke annet enn variable parnavn, og linje 7 peker til min couchbase-rs-pod-applikasjon. Følgende er portene som gir tilgang til de samme etikettene.
På linje 19 oppretter jeg en ny ReplicaSet-type, linje 31 inneholder navnet på bildet, og linje 24-27 peker på metadataene knyttet til poden min. Det er nettopp dette tjenesten er ute etter og hva forbindelsen må etableres med. På slutten av filen er en slags forbindelse mellom linje 55-56 og 4, som sier "bruk denne tjenesten!".
Så jeg starter tjenesten min med et replikasett, og siden hvert replikasett har sin egen port med passende etikett, er det inkludert i tjenesten. Fra en utviklers synspunkt får du ganske enkelt tilgang til tjenesten, som deretter bruker replikasettet du trenger.
Jeg endte opp med en WildFly-pod som kommuniserer med databasens backend via Couchbase-tjenesten. Jeg kan bruke WildFly multi-pod-frontend, som også kommuniserer med couchbase-backend gjennom couchbase-tjenesten.
Senere skal vi se på hvordan en tjeneste som ligger utenfor klyngen, gjennom sin IP-adresse, kommuniserer med elementer som er plassert inne i klyngen og har en intern IP-adresse.
Så statsløse containere er flotte, men hvor god er ideen om å bruke stateful containere? La oss se på systeminnstillinger for tilstandsfulle eller vedvarende beholdere. I Docker er det 4 forskjellige tilnærminger til plasseringen av datalageret som du bør være oppmerksom på. Den første er Implicit Per-Container, som betyr at når du bruker couchbase, MySQL eller MyDB satateful containere, starter de alle med standard Sandbox. Det vil si at alt som er lagret i databasen lagres i selve containeren. Hvis beholderen forsvinner, følger dataene med.
Den andre er Explicit Per-Container, når du oppretter en spesifikk lagring med docker-volumet opprette kommando og lagre data i den. Den tredje Per-Host-tilnærmingen er relatert til lagringskartlegging, når alt som er lagret i containeren samtidig dupliseres på verten. Hvis beholderen mislykkes, forblir dataene på verten. Den siste er bruken av flere Multi-Host-verter, noe som anbefales på produksjonsstadiet av ulike løsninger. Anta at beholderne med applikasjonene dine kjører på en vert, men samtidig ønsker du å lagre dataene dine et sted på Internett, og automatisk kartlegging for distribuerte systemer brukes til dette.
Hver av disse metodene bruker en bestemt lagringsplass. Implisitt og eksplisitt per-beholder lagrer data på verten på /var/lib/docker/volumes. Ved bruk av Per-Host-metoden monteres lageret inne i containeren, og selve containeren monteres på verten. For multi-host løsninger som Ceph, ClusterFS, NFS, etc. kan brukes.
Når en vedvarende beholder mislykkes, blir lagringskatalogen utilgjengelig i de to første tilfellene, og i de to siste tilfellene beholdes tilgangen. I det første tilfellet kan du imidlertid få tilgang til depotet gjennom en Docker-vert som kjører i en virtuell maskin. I det andre tilfellet vil heller ikke dataene gå tapt, fordi du har opprettet en eksplisitt lagring.
Når verten svikter, er depotkatalogen utilgjengelig i de tre første tilfellene, i det siste tilfellet blir ikke kommunikasjonen med depotet avbrutt. Til slutt er den delte funksjonen helt utelukket for lagring i det første tilfellet og mulig i resten. I det andre tilfellet kan du dele lagring avhengig av om databasen din støtter distribuert lagring eller ikke. Når det gjelder Per-vert, er distribusjon av data bare mulig på en gitt vert, og for en multi-vert leveres det av klyngeutvidelsen.
Dette bør tas i betraktning når du oppretter stateful containere. Et annet nyttig Docker-verktøy er Volume-plugin, som fungerer etter prinsippet "batterier er tilstede, men må byttes ut". Når du starter en Docker-beholder, står det "Hei, ved å kjøre en beholder med en database, kan du lagre dataene dine i denne beholderen!" Dette er standardfunksjonen, men du kan endre den. Denne plugin lar deg bruke en nettverksstasjon eller noe lignende i stedet for en containerdatabase. Den inkluderer en standard vertsbasert lagringsdriver og tillater containerintegrasjon med eksterne lagringssystemer som Amazon EBS, Azure Storage og GCE Persistent-disker.
Det neste lysbildet viser arkitekturen til Docker Volume plugin.
Blå indikerer en Docker-klient knyttet til en blå Docker-vert som har en lokal lagringsmotor som gir deg lagringsbeholdere. Grønt indikerer Plugin Client og Plugin Daemon, som også er koblet til verten. De gir muligheten til å lagre data i nettverkslagre av typen du trenger Storage Backend.
Docker Volume-pluginen kan brukes med Portworx-lagring. PX-Dev-modulen er faktisk en container du kjører som kobles til en Docker-vert og gjør det enkelt å lagre data på Amazon EBS.
Portworx-klienten lar deg overvåke statusen til ulike lagringsbeholdere som er koblet til verten din. Hvis du besøker bloggen min, kan du lese hvordan du får mest mulig ut av Portworx med Docker.
Konseptet med lagring i Kubernetes ligner på Docker og er representert av kataloger som er tilgjengelige for beholderen din i en pod. De er uavhengige av levetiden til enhver beholder. De vanligste tilgjengelige lagringstypene er hostPath, nfs, awsElasticBlockStore og gsePersistentDisk. La oss ta en titt på hvordan disse lagringene fungerer i Kubernetes. Vanligvis består prosessen med å koble dem av 3 trinn.
Den første er at noen på nettverkssiden, vanligvis en administrator, gir deg vedvarende lagring. Det er en tilsvarende PersistentVolume-konfigurasjonsfil for dette. Deretter skriver applikasjonsutvikleren en konfigurasjonsfil kalt PersistentVolumeClaim, eller en forespørsel om PVC-lagring, som sier: «Jeg har 50 GB distribuert lagringsplass klargjort, men for at andre mennesker også kan bruke kapasiteten, informerer jeg i denne PVC-en at jeg nå trenger bare 10 GB". Til slutt er det tredje trinnet at spørringen din er montert som en butikk, og applikasjonen som har en pod eller replikasett eller noe sånt begynner å bruke den. Det er viktig å huske at denne prosessen består av de 3 nevnte trinnene og gir mulighet for skalering.
Det neste lysbildet viser AWS-arkitekturens Kubernetes Persistence Container.
Inne i det brune rektangelet som representerer Kubernetes-klyngen, er det én hovednode og to arbeidernoder, vist i gult. En av arbeidernodene inneholder en oransje pod, et depot, en kopikontroller og en grønn Docker Couchbase-beholder. Inne i klyngen, over nodene, indikerer et lilla rektangel en ekstern tilgjengelig tjeneste. Denne arkitekturen anbefales for lagring av data på selve enheten. Om nødvendig kan jeg lagre dataene mine i EBS utenfor klyngen, som vist på neste lysbilde. Dette er en typisk modell for skalering, men når du bruker den, må du ta hensyn til det økonomiske aspektet - lagring av data et sted på nettverket kan være dyrere enn på verten. Ved valg av containeriseringsløsninger er dette et av de tungtveiende argumentene.
Akkurat som med Docker, kan du bruke vedvarende Kubernetes-beholdere med Portworx.
Dette er det som i dagens Kubernetes 1.6-terminologi kalles et "StatefulSet", en måte å jobbe med Stateful-applikasjoner på som håndterer Pod stop og Graceful Shutdown-hendelser. I vårt tilfelle er slike applikasjoner databaser. På bloggen min kan du lese hvordan du lager et StatefulSet i Kubernetes ved hjelp av Portworx.
La oss snakke om utviklingsaspektet. Docker har som sagt 2 versjoner – CE og EE, i det første tilfellet snakker vi om den stabile versjonen av Community Edition, som oppdateres hver 3. måned, i motsetning til den månedlig oppdaterte versjonen av EE. Du kan laste ned Docker for Mac, Linux eller Windows. Når den er installert, vil Docker automatisk oppdateres, og det er veldig enkelt å komme i gang med det.
I Kubernetes foretrekker jeg Minikube-versjonen – dette er en god måte å komme i gang med denne plattformen ved å lage en klynge på en enkelt node. For å lage klynger fra flere noder, er utvalget av versjoner bredere: disse er kops, kube-aws (CoreOS + AWS), kube-up (utdatert). Hvis du ønsker å bruke AWS-baserte Kubernetes, anbefaler jeg å bli med i AWS SIG, som møtes online hver fredag og legger ut en rekke interessant innhold om arbeid med AWS Kubernetes.
La oss ta en titt på hvordan Rolling Update fungerer på disse plattformene. Hvis det er en klynge med flere noder, bruker den en spesifikk versjon av bildet, for eksempel WildFly:1. En rullende oppdatering betyr at bildeversjonen erstattes med en ny sekvensielt på hver node, én etter én.
Til dette brukes kommandoen docker service update (tjenestenavn), der jeg spesifiserer den nye versjonen av WildFly: 2-bildet og update-parallelism 2. Oppdateringsmetoden 2. Tallet 2 betyr at systemet vil oppdatere 10 applikasjonsbilder kl. en gang, etterfulgt av en 10-sekunders oppdateringsforsinkelse på 2s, hvoretter de neste 2 bildene vil bli oppdatert på ytterligere XNUMX noder osv. Denne enkle rullende oppdateringsmekanismen leveres til deg som en del av Docker.
I Kubernetes fungerer rullende oppdatering slik. Replikeringskontrolleren rc oppretter et replikasett med én versjon, og hver pod i denne webapp-rc er merket med en etikett som finnes i etcd. Når jeg trenger en slags pod, bruker jeg applikasjonstjenesten for å få tilgang til etcd-lageret, som ved den angitte etiketten gir meg denne poden.
I dette tilfellet har vi 3 pods i replikeringskontrolleren som kjører applikasjonen WildFly versjon 1. Ved oppdatering i bakgrunnen opprettes en annen replikeringskontroller med samme navn og indeks på slutten - - xxxxx, der x er tilfeldige tall, og med samme merkelapper. Applikasjonstjenesten har nå tre Pods med den gamle versjonen av applikasjonen og tre Pods med den nye versjonen i den nye replikeringskontrolleren. Etter det blir de gamle podene slettet, replikeringskontrolleren med de nye podene blir omdøpt og satt i drift.
La oss gå videre til overvåking. Docker har mange innebygde overvåkingskommandoer. For eksempel lar docker container stats kommandolinjegrensesnittet deg vise data om statusen til containere hvert sekund til konsollen - bruk av prosessor, disk, nettverksbelastning. Docker Remote API-verktøyet gir data om hvordan klienten kommuniserer med serveren. Den bruker enkle kommandoer, men er basert på Docker REST API. I dette tilfellet betyr ordene REST, Flash, Remote det samme. Når du kommuniserer med verten, er det en REST API. Docker Remote API lar deg få mer informasjon om å kjøre containere. Bloggen min har detaljene om bruk av denne overvåkingen med Windows Server.
Overvåking av systemhendelser docker-systemhendelser ved oppstart av en multi-vert-klynge gjør det mulig å få data om et vertskrasj eller et containerkrasj på en spesifikk vert, tjenesteskalering og lignende. Fra og med Docker 1.20 inkluderer den Prometheus, som bygger inn endepunkter i eksisterende applikasjoner. Dette lar deg motta beregninger over HTTP og vise dem i dashboards.
En annen overvåkingsfunksjon er cAdvisor (forkortelse for container Advisor). Den analyserer og gir ressursbruk og ytelsesdata fra kjørende containere, og gir Prometheus-beregninger rett ut av boksen. Det særegne med dette verktøyet er at det bare gir data for de siste 60 sekundene. Derfor må du sørge for muligheten til å samle inn disse dataene og plassere dem i en database for å kunne overvåke en langsiktig prosess. Den kan også brukes til å vise beregninger grafisk på et dashbord ved hjelp av Grafana eller Kibana. Bloggen min har en detaljert beskrivelse av hvordan du bruker cAdvisor til å overvåke containere ved å bruke Kibana-dashbordet.
Det neste lysbildet viser hvordan resultatet av Prometheus-endepunktet ser ut og beregningene som er tilgjengelige for visning.
Nederst til venstre ser du beregningene for HTTP-forespørsler, svar osv., til høyre - deres grafiske visning.
Kubernetes inneholder også innebygde overvåkingsverktøy. Dette lysbildet viser en typisk klynge som inneholder én hoved- og tre arbeidernoder.
Hver av arbeidernodene inneholder en automatisk lansert cAdvisor. I tillegg kommer Heapster, et ytelsesovervåkings- og målesystem som er kompatibelt med Kubernetes versjon 1.0.6 og nyere. Heapster lar deg samle ikke bare ytelsen til arbeidsbelastninger, moduler og containere, men også hendelser og andre signaler generert av hele klyngen. For å samle inn data, kommuniserer den med Kubelet til hver Pod, lagrer automatisk informasjonen i InfluxDB-databasen og viser den som metrikk i Grafana-dashbordet. Vær imidlertid oppmerksom på at hvis du bruker miniKube, er denne funksjonen ikke tilgjengelig som standard, så du må bruke tillegg for overvåking. Så alt avhenger av hvor du kjører containere og hvilke overvåkingsverktøy du kan bruke som standard og hvilke du må installere som separate tillegg.
Det neste lysbildet viser Grafana-dashbordene som viser driftsstatusen til containerne mine. Det er mye interessant data her. Selvfølgelig er det mange kommersielle Docker- og Kubernetes-prosessovervåkingsverktøy, for eksempel SysDig, DataDog, NewRelic. Noen av dem har en 30 gratis prøveperiode, så du kan prøve å finne den som passer deg best. Personlig foretrekker jeg å bruke SysDig og NewRelic, som integreres godt med Kubernetes. Det finnes verktøy som integreres like godt i både Docker- og Kubernetes-plattformene.
Noen annonser 🙂
Takk for at du bor hos oss. Liker du artiklene våre? Vil du se mer interessant innhold? Støtt oss ved å legge inn en bestilling eller anbefale til venner, , en unik analog av entry-level servere, som ble oppfunnet av oss for deg: (tilgjengelig med RAID1 og RAID10, opptil 24 kjerner og opptil 40 GB DDR4).
Dell R730xd 2x billigere i Equinix Tier IV datasenter i Amsterdam? Bare her i Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra $99! Lese om
Kilde: www.habr.com