Docker Swarm, Kubernetes og Mesos er de mest populære containerorkestreringsframeworks. I sit foredrag sammenligner Arun Gupta følgende aspekter af Docker, Swarm og Kubernetes:
- Lokal udvikling.
- Implementeringsfunktioner.
- Multi-container applikationer.
- Tjenesteopdagelse.
- Skalering af tjenesten.
- Opgaver, der skal køres én gang.
- Integration med Maven.
- "Rullende" opdatering.
- Oprettelse af en Couchbase DB-klynge.
Som et resultat får du en klar forståelse af, hvad hvert orkestreringsværktøj har at tilbyde, og lærer teknikker til at bruge disse platforme effektivt.
Arun Gupta er chef for open source-teknologi hos Amazon Web Services og har opbygget udviklerfællesskaber hos Sun, Oracle, Red Hat og Couchbase i over et årti. Har omfattende erfaring med at lede tværfaglige teams involveret i udvikling og implementering af marketingkampagner og programstrategier. Han har ledet ingeniørteams hos Sun, er et af stiftende medlemmer af Java EE-teamet og skaberen af den amerikanske afdeling af Devoxx10Kids. Arun Gupta har skrevet over 4 indlæg på IT-blogs og har talt i over 2 lande.
Linje 55 indeholder COUCHBASE_URI, som peger på denne databasetjeneste, som også er oprettet ved hjælp af Kubernetes-konfigurationsfilen. Hvis du kigger på linje 2, kan du se kind: Service – det er den tjeneste, jeg opretter, kaldet couchbase-service, og det er det samme navn, som er angivet på linje 4. Nedenfor er nogle porte.
Nøglelinjerne er 6 og 7. I tjenesten siger jeg "Hey, det er de etiketter, jeg leder efter!" og disse etiketter er intet andet end navne på variable par, og linje 7 peger på min couchbase-rs-pod-app. Nedenfor er en liste over de porte, der giver adgang til disse samme etiketter.
På linje 19 opretter jeg en ny ReplicaSet-type, linje 31 indeholder billednavnet, og linje 24-27 peger på de metadata, der er knyttet til min pod. Det er præcis, hvad tjenesten leder efter, og hvad forbindelsen skal etableres med. I slutningen af filen er der en slags forbindelse mellem linje 55-56 og 4, hvor der står: "brug denne tjeneste!"
Så jeg starter min tjeneste, når jeg har et replikasæt, og da hvert replikasæt har sin egen port med en tilhørende etiket, er det inkluderet i tjenesten. Fra en udviklers perspektiv kalder du blot tjenesten, som derefter aktiverer det sæt af replikaer, du har brug for.
Så jeg har en WildFly-pod, der kommunikerer med databasens backend via Couchbase-tjenesten. Jeg kan bruge en frontend med flere WildFly pods, der også kommunikerer med couchbase backend via couchbase-tjenesten.
Senere vil vi se på, hvordan en tjeneste placeret uden for klyngen kommunikerer via sin IP-adresse med elementer, der er placeret inde i klyngen og har en intern IP-adresse.
Så statsløse containere er fantastiske, men hvor godt er det at bruge stateful containere? Lad os se på systemindstillingerne for stateful, eller persistente, containere. Der er 4 forskellige tilgange til datalagringslayout i Docker, som du bør tage i betragtning. Den første er Implicit Per-Container, hvilket betyder, at når man bruger mættede containere som couchbase, MySQL eller MyDB, kører de alle med standard Sandbox. Det vil sige, at alt, hvad der er gemt i databasen, er gemt i selve containeren. Hvis containeren forsvinder, forsvinder dataene med den.
Den anden er Explicit Per-Container, hvor du opretter et specifikt lager med docker volume create-kommandoen og gemmer data i det. Den tredje Per-Host-tilgang involverer storage-mapping, hvor alt, der er gemt i en container, replikeres samtidigt på værten. Hvis containeren fejler, forbliver dataene på værten. Den sidste er brugen af flere Multi-Host-værter, hvilket er tilrådeligt i produktionsfasen af forskellige løsninger. Lad os sige, at du har containere med dine applikationer, der kører på en vært, men du vil gemme dine data et sted på internettet, og du bruger automatisk kortlægning til distribuerede systemer til dette.
Hver af disse metoder bruger en specifik lagringsplacering. Implicitte og eksplicitte per-container lagrer data på værten i /var/lib/docker/volumes. Med Per-Host-metoden monteres lageret inde i containeren, og selve containeren monteres på værten. Til multi-hosts kan løsninger som Ceph, ClusterFS, NFS osv. anvendes.
Hvis en persistent container fejler, bliver lagermappen utilgængelig i de første to tilfælde, men adgangen bevares i de sidste to tilfælde. I det første tilfælde kan du dog få adgang til depotet via en Docker-vært, der kører på en virtuel maskine. I det andet tilfælde vil dataene heller ikke gå tabt, fordi du har oprettet et eksplicit lager.
Hvis værten fejler, er lagermappen ikke tilgængelig i de første tre tilfælde; I sidste tilfælde afbrydes forbindelsen til lageret ikke. Endelig er den delte funktion fuldstændig udelukket fra lagring i det første tilfælde og mulig i de andre. I det andet tilfælde kan du dele lagerplads afhængigt af om din database understøtter distribueret lagring eller ej. I tilfælde af Per-Host er datadistribution kun mulig på en given vært, mens den for multi-host leveres via klyngeudvidelse.
Dette bør tages i betragtning, når man opretter stateful containere. Et andet nyttigt Docker-værktøj er Volume-plugin'et, som fungerer ud fra princippet om, at "batterier er til stede, men kan udskiftes". Når du starter en Docker-container, siger den: "Hey, ved at køre en container med en database kan du gemme dine data i denne container!" Denne funktion er standard, men du kan ændre den. Dette plugin giver dig mulighed for at bruge et netværksdrev eller noget lignende i stedet for en containerdatabase. Den inkluderer en standarddriver til værtsbaseret lagring og muliggør containerintegration med eksterne lagringssystemer som Amazon EBS, Azure Storage og GCE Persistent Disks.
Det næste slide viser arkitekturen for Docker Volume-pluginnet.
I blåt er Docker-klienten, som er forbundet til en blå Docker-vært, der har en lokal lagringsmotor, der giver dig containere til at gemme dine data. Plugin-klienten og plugin-dæmonen er vist i grønt, og de er også forbundet til værten. De giver mulighed for at gemme data i netværkslager af den type Storage Backend, du har brug for.
Docker Volume-pluginnet kan bruges med Portworx-lagring. PX-Dev-modulet er faktisk en container, som du kører, der opretter forbindelse til en Docker-vært og giver dig mulighed for nemt at gemme data på Amazon EBS.
Portworx-klienten giver dig mulighed for at overvåge status for containere med forskellig lagring, der er forbundet til din vært. Hvis du besøger min blog, kan du læse, hvordan du bruger Portworx med Docker mest effektivt.
Lagringskonceptet i Kubernetes ligner Docker og er repræsenteret af mapper, der er tilgængelige for din container i pod'en. De er uafhængige af beholderens levetid. De mest almindelige tilgængelige lagringstyper er hostPath, nfs, awsElasticBlockStore og gsePersistentDisk. Lad os se på, hvordan disse lagre fungerer i Kubernetes. Typisk består processen med at forbinde dem af 3 trin.
Den første er, at en person på netværkssiden, normalt en administrator, giver dig permanent lagring. Der findes en tilsvarende konfigurationsfil PersistentVolume til dette formål. Dernæst skriver applikationsudvikleren en konfigurationsfil kaldet en PersistentVolumeClaim, eller PVC-lagringsanmodning, der siger: "Jeg har 50 GB distribueret lager klargjort, men for at give andre mulighed for at bruge den kapacitet, siger jeg i denne PVC, at jeg kun har brug for 10 GB lige nu." Endelig er det tredje trin, at din anmodning monteres som lager, og den applikation, der har poden, eller replikasættet, eller hvad som helst, begynder at bruge den. Det er vigtigt at huske, at denne proces består af de 3 nævnte trin og giver mulighed for skalering.
Det næste slide viser AWS-arkitekturen Kubernetes Persistence Container.
Inde i det brune rektangel, som repræsenterer Kubernetes-klyngen, er der én masternode og to arbejdsnoder, vist med gult. En af arbejdsnoderne indeholder en orange pod, lager, replikacontroller og en grøn Docker Couchbase-container. Inde i klyngen, over noderne, angiver et lilla rektangel en eksternt tilgængelig tjeneste. Denne arkitektur anbefales til lagring af data på selve enheden. Hvis det er nødvendigt, kan jeg gemme mine data i EBS uden for klyngen, som vist på næste slide. Dette er en typisk model for skalering, men der er en omkostningsovervejelse ved brug - lagring af data et sted på netværket kan være dyrere end på værten. Når man vælger containeriseringsløsninger, er dette et af de vægtige argumenter.
Ligesom med Docker kan du bruge persistente Kubernetes-containere med Portworx.
Dette er det, der i den nuværende Kubernetes 1.6-terminologi kaldes et "StatefulSet" - en måde at arbejde med Stateful-applikationer på, der håndterer Pod-nedlukningshændelser og Graceful Shutdowns. I vores tilfælde er sådanne applikationer databaser. Du kan læse mit blogindlæg om, hvordan man opretter et StatefulSet i Kubernetes ved hjælp af Portworx.
Lad os tale om udviklingsaspektet. Som sagt har Docker 2 versioner - CE og EE, i det første tilfælde taler vi om den stabile version af Community Edition, som opdateres hver 3. måned, i modsætning til den månedligt opdaterede version af EE. Du kan downloade Docker til Mac, Linux eller Windows. Når Docker er installeret, opdaterer den sig selv automatisk, og det er meget nemt at komme i gang.
I Kubernetes foretrækker jeg Minikube-versionen - det er en god måde at komme i gang med platformen ved at oprette en klynge på en enkelt node. For at oprette klynger af flere noder er udvalget af versioner bredere: kops, kube-aws (CoreOS+AWS), kube-up (forældet). Hvis du skal bruge Kubernetes på AWS, anbefaler jeg at du deltager i AWS SIG-gruppen, som mødes online hver fredag og udgiver forskellige interessante materialer om at arbejde med Kubernetes på AWS.
Lad os se på, hvordan rullende opdateringer udføres på disse platforme. Hvis der er en klynge af flere noder, bruger den en specifik version af billedet, for eksempel WildFly:1. En rullende opdatering betyder, at afbildningsversionen erstattes med en ny på hver node, den ene efter den anden.
For at gøre dette bruger jeg docker service update-kommandoen (servicenavn), hvor jeg angiver den nye version af WildFly:2-billedet og update-parallelism 2-opdateringsmetoden. Tallet 2 betyder, at systemet opdaterer 2 applikationsbilleder ad gangen, derefter vil der være en 10 sekunders forsinkelse på opdateringen, hvorefter de næste 10 billeder opdateres på 2 noder mere, og så videre. Denne enkle rullende opdateringsmekanisme leveres til dig som en del af Docker.
I Kubernetes fungerer rullende opdateringer sådan her. Replikeringscontrolleren rc opretter et sæt replikaer af den samme version, og hver pod i denne webapp-rc forsynes med en etiket placeret i etcd. Når jeg har brug for en pod, tilgår jeg etcd-lageret via applikationstjenesten, som forsyner mig med denne pod ved hjælp af den angivne etiket.
I dette tilfælde har vi 3 pods i replikeringscontrolleren, der kører WildFly version 1-applikationen. Ved opdatering oprettes en anden replikeringscontroller i baggrunden med samme navn og indeks til sidst — — xxxxx, hvor x er tilfældige tal, og med de samme labels. Nu har applikationstjenesten tre pods med den gamle version af applikationen og tre pods med den nye version i den nye replikeringscontroller. Derefter slettes de gamle pods, replikeringscontrolleren med de nye pods omdøbes og sættes i drift.
Lad os gå videre til at overveje overvågning. Docker har mange indbyggede kommandoer til overvågning. For eksempel giver kommandolinjegrænsefladen "docker container stats" dig mulighed for at sende data om containernes tilstand til konsollen hvert sekund - processorforbrug, diskforbrug, netværksbelastning. Docker Remote API-værktøjet giver oplysninger om, hvordan klienten kommunikerer med serveren. Den bruger simple kommandoer, men er baseret på Docker REST API'en. I dette tilfælde betyder ordene REST, Flash og Remote det samme. Når du taler med værten, er det en REST API. Docker Remote API'en giver dig mulighed for at få flere oplysninger om kørsel af containere. Min blog går i detaljer med brugen af denne overvågning med Windows Server.
Overvågning af docker-systemhændelser, når du starter en multi-host-klynge, giver dig mulighed for at få data om et værts- eller containernedbrud på en bestemt vært, skaleringstjenester og lignende. Fra og med Docker 1.20 inkluderer den Prometheus, som integrerer endpoints i eksisterende applikationer. Dette giver dig mulighed for at hente metrikker via HTTP og vise dem på dashboards.
En anden overvågningsfunktion er cAdvisor (forkortelse for container Advisor). Den analyserer og leverer data om ressourceforbrug og ydeevne fra kørende containere og leverer Prometheus-målinger direkte fra installationen. Det særlige ved dette værktøj er, at det kun leverer data for de sidste 60 sekunder. Så du skal sørge for muligheden for at indsamle disse data og lægge dem i en database for at kunne overvåge en langsigtet proces. Det kan også bruges til at vise metrikker grafisk på et dashboard ved hjælp af Grafana eller Kibana. Min blog har en detaljeret beskrivelse af, hvordan man bruger cAdvisor til at overvåge containere ved hjælp af et Kibana-dashboard.
Det næste slide viser, hvordan outputtet fra et Prometheus-slutpunkt ser ud, og hvilke metrikker der kan vises.
Nederst til venstre ser du metrikker for HTTP-anmodninger, svar osv., og til højre ser du deres grafiske visning.
Kubernetes leveres også med indbyggede overvågningsværktøjer. Dette slide viser en typisk klynge, der indeholder én master- og tre worker-noder.
Hver af arbejdsnoderne indeholder en automatisk startet cAdvisor. Derudover er der Heapster, et system til præstationsovervågning og indsamling af metrikker, der er kompatibelt med Kubernetes version 1.0.6 og nyere. Heapster giver dig mulighed for at indsamle ikke kun performance-målinger for workloads, pods og containere, men også hændelser og andre signaler genereret af hele klyngen. For at indsamle data kommunikerer den med hver pods Kubelet, lagrer automatisk informationen i en InfluxDB-database og sender den som metrikker til Grafana-dashboardet. Bemærk dog, at hvis du bruger miniKube, er denne funktion ikke tilgængelig som standard, så du bliver nødt til at bruge tilføjelsesprogrammer til overvågning. Så det hele afhænger af, hvor du kører dine containere, og hvilke overvågningsværktøjer du kan bruge som standard, og hvilke du skal installere som separate tilføjelser.
Det næste slide viser Grafana-dashboards, der viser mine containeres driftsstatus. Der er en hel del interessante data her. Der findes selvfølgelig mange kommercielle værktøjer til overvågning af Docker- og Kubernetes-processer, såsom SysDig, DataDog og NewRelic. Nogle af dem har en 30-dages gratis prøveperiode, så du kan prøve og vælge den, der passer dig bedst. Personligt foretrækker jeg at bruge SysDig og NewRelic, som integrerer godt med Kubernetes. Der findes værktøjer, der integreres lige godt i begge platforme – Docker og Kubernetes.
Nogle annoncer 🙂
Tak fordi du blev hos os. Kan du lide vores artikler? Vil du se mere interessant indhold? Støt os ved at afgive en ordre eller anbefale til venner, , en unik analog af entry-level servere, som blev opfundet af os til dig: (tilgængelig med RAID1 og RAID10, op til 24 kerner og op til 40 GB DDR4).
Dell R730xd 2 gange billigere i Equinix Tier IV datacenter i Amsterdam? Kun her i Holland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra $99! Læse om
Kilde: www.habr.com
