Docker Swarm, Kubernetes och Mesos är de mest populära containerorkestreringsramverken. I sitt föredrag jämför Arun Gupta följande aspekter av Docker, Swarm och Kubernetes:
- Lokal utveckling.
- Implementeringsfunktioner.
- Tillämpningar för flera behållare.
- Service upptäckt.
- Skala tjänsten.
- Engångsuppgifter.
- Integration med Maven.
- "Rullande" uppdatering.
- Skapa ett Couchbase-databaskluster.
Som ett resultat kommer du att få en tydlig förståelse för vad varje orkestreringsverktyg har att erbjuda och lära dig hur du använder dessa plattformar effektivt.
Arun Gupta är chefsteknologen för produkter med öppen källkod på Amazon Web Services, som har utvecklat utvecklargemenskaperna Sun, Oracle, Red Hat och Couchbase i över 10 år. Har lång erfarenhet av att arbeta i att leda tvärfunktionella team som utvecklar och implementerar strategier för marknadsföringskampanjer och program. Han ledde team av Sun-ingenjörer, är en av grundarna av Java EE-teamet och skaparen av den amerikanska grenen av Devoxx4Kids. Arun Gupta är författare till mer än 2 tusen inlägg i IT-bloggar och har hållit föredrag i mer än 40 länder.
Rad 55 innehåller en COUCHBASE_URI som pekar på denna databastjänst, som också skapades med hjälp av Kubernetes konfigurationsfil. Om du tittar på rad 2 kan du se typ: Service är tjänsten jag skapar som heter couchbase-service, och samma namn finns på rad 4. Nedan finns några portar.
Nyckelraderna är 6 och 7. I tjänst säger jag, "Hej, det här är etiketterna jag letar efter!", och de här etiketterna är inget annat än variabla parnamn, och rad 7 pekar på min couchbase-rs-pod Ansökan. Följande är portarna som ger åtkomst till samma etiketter.
På rad 19 skapar jag en ny typ ReplicaSet, rad 31 innehåller namnet på bilden och raderna 24-27 pekar på metadata som är associerade med min pod. Det är precis vad tjänsten letar efter och vad kopplingen ska göras till. I slutet av filen finns det någon form av koppling mellan raderna 55-56 och 4, som säger: "använd den här tjänsten!"
Så jag startar min tjänst när det finns en replikuppsättning, och eftersom varje replikuppsättning har sin egen port med motsvarande etikett, ingår den i tjänsten. Ur en utvecklares synvinkel ringer du helt enkelt tjänsten, som sedan använder den uppsättning repliker du behöver.
Som ett resultat har jag en WildFly-pod som kommunicerar med databasens backend via Couchbase Service. Jag kan använda frontend med flera WildFly-poddar, som också kommunicerar med couchbase-backend genom couchbase-tjänsten.
Senare ska vi titta på hur en tjänst som ligger utanför klustret kommunicerar genom sin IP-adress med element som finns inne i klustret och har en intern IP-adress.
Så statslösa behållare är bra, men hur bra är det att använda tillståndslösa behållare? Låt oss titta på systeminställningarna för stateful eller beständiga behållare. I Docker finns det 4 olika metoder för datalagringslayout som du bör vara uppmärksam på. Den första är Implicit Per-Container, vilket innebär att när du använder couchbase, MySQL eller MyDB mättade behållare börjar de alla med standardsandlådan. Det vill säga att allt som lagras i databasen lagras i själva behållaren. Om behållaren försvinner försvinner data tillsammans med den.
Den andra är Explicit Per-Container, när du skapar en specifik lagring med dockervolymen skapa kommando och lagra data i den. Den tredje Per-Host-metoden är associerad med lagringsmapping, när allt som lagras i behållaren samtidigt dupliceras på värden. Om behållaren misslyckas kommer data att finnas kvar på värden. Det senare är användningen av flera Multi-Host-värdar, vilket är tillrådligt i produktionsstadiet av olika lösningar. Låt oss säga att dina behållare med dina applikationer körs på värden, men du vill lagra dina data någonstans på Internet, och för detta använder du automatisk mappning för distribuerade system.
Var och en av dessa metoder använder en specifik lagringsplats. Implicit och explicit per behållare lagrar data på värden på /var/lib/docker/volumes. Vid användning av Per-Host-metoden monteras förvaringen inuti behållaren, och själva behållaren monteras på värden. För multihosts kan lösningar som Ceph, ClusterFS, NFS etc. användas.
Om en beständig behållare misslyckas blir lagringskatalogen otillgänglig i de två första fallen, men i de två sista fallen bibehålls åtkomsten. Men i det första fallet kan du komma åt förvaret via en Docker-värd som körs på en virtuell maskin. I det andra fallet kommer data inte heller att gå förlorade, eftersom du har skapat en explicit lagring.
Om värden misslyckas är lagringskatalogen inte tillgänglig i de första tre fallen, i det sista fallet avbryts inte anslutningen till lagringen. Slutligen är den delade funktionen helt utesluten för lagring i det första fallet och är möjlig i resten. I det andra fallet kan du dela lagring beroende på om din databas stöder distribuerad lagring eller inte. När det gäller Per-Host är datadistribution endast möjlig på en given värd, och för en multihost tillhandahålls den genom klusterexpansion.
Detta bör beaktas när du skapar statusfulla behållare. Ett annat användbart Docker-verktyg är volymplugin, som fungerar enligt principen om "batterier finns, men måste bytas ut." När du startar en Docker-container står det "Hej, när du väl startar en container med en databas kan du lagra dina data i den här containern!" Detta är standardfunktionen, men du kan ändra den. Denna plugin låter dig använda en nätverksenhet eller något liknande istället för en containerdatabas. Den innehåller en standarddrivrutin för värdbaserad lagring och tillåter containerintegration med externa lagringssystem som Amazon EBS, Azure Storage och GCE Persistent-diskar.
Nästa bild visar arkitekturen för Docker Volume plugin.
Den blå färgen representerar Docker-klienten som är associerad med den blå Docker-värden, som har en lokal lagringsmotor som förser dig med behållare för lagring av data. Grönt indikerar Plugin Client och Plugin Daemon, som också är anslutna till värden. De ger möjlighet att lagra data i nätverkslagring av den typ av Storage Backend du behöver.
Docker Volume-plugin kan användas med Portworx-lagring. PX-Dev-modulen är faktiskt en behållare du kör som ansluter till din Docker-värd och låter dig enkelt lagra data på Amazon EBS.
Portworx-klienten låter dig övervaka statusen för olika lagringsbehållare som är anslutna till din värd. Om du besöker min blogg kan du läsa hur du får ut det mesta av Portworx med Docker.
Konceptet med lagring i Kubernetes liknar Docker och representeras av kataloger som är tillgängliga för din behållare i en pod. De är oberoende av livslängden för alla behållare. De vanligaste tillgängliga lagringstyperna är hostPath, nfs, awsElasticBlockStore och gsePersistentDisk. Låt oss ta en titt på hur dessa butiker fungerar i Kubernetes. Vanligtvis består processen för att ansluta dem av 3 steg.
Den första är att någon på nätverkssidan, vanligtvis en administratör, förser dig med beständig lagring. Det finns en motsvarande PersistentVolume-konfigurationsfil för detta. Därefter skriver applikationsutvecklaren en konfigurationsfil som heter PersistentVolumeClaim, eller en PVC-lagringsbegäran, som säger: "Jag har 50 GB distribuerad lagring tillhandahållen, men för att andra människor också ska kunna använda dess kapacitet, säger jag till denna PVC att jag för närvarande behöver bara 10 GB". Slutligen är det tredje steget att din förfrågan monteras som lagring och applikationen som har podden, eller replikuppsättningen, eller något liknande, börjar använda den. Det är viktigt att komma ihåg att denna process består av de tre nämnda stegen och är skalbar.
Nästa bild visar Kubernetes Persistence Container för AWS-arkitekturen.
Inuti den bruna rektangeln som representerar Kubernetes-klustret finns en huvudnod och två arbetarnoder, indikerade med gult. En av arbetarnoderna innehåller en orange pod, lagring, en replikkontroller och en grön Docker Couchbase-behållare. Inuti klustret, ovanför noderna, indikerar en lila rektangel tjänsten tillgänglig från utsidan. Denna arkitektur rekommenderas för att lagra data på själva enheten. Vid behov kan jag lagra mina data i EBS utanför klustret, som visas i nästa bild. Det här är en typisk modell för skalning, men det finns en ekonomisk aspekt att tänka på när du använder den - att lagra data någonstans på nätverket kan vara dyrare än på en värd. När man väljer containeriseringslösningar är detta ett av de tungt vägande argumenten.
Precis som med Docker kan du använda beständiga Kubernetes-behållare med Portworx.
Detta är vad som i nuvarande Kubernetes 1.6-terminologi kallas för ett "StatefulSet" - ett sätt att arbeta med Stateful-applikationer som behandlar händelser om att stoppa Pod och utföra Graceful Shutdown. I vårt fall är sådana applikationer databaser. I min blogg kan du läsa hur du skapar ett StatefulSet i Kubernetes med hjälp av Portworx.
Låt oss prata om utvecklingsaspekten. Docker har som sagt 2 versioner – CE och EE, i det första fallet pratar vi om en stabil version av Community Edition, som uppdateras en gång var 3:e månad, i motsats till den månatligen uppdaterade versionen av EE. Du kan ladda ner Docker för Mac, Linux eller Windows. När det väl är installerat kommer Docker att uppdateras automatiskt och det är väldigt enkelt att komma igång.
För Kubernetes föredrar jag Minikube-versionen – det är ett bra sätt att komma igång med plattformen genom att skapa ett kluster på en enda nod. För att skapa kluster av flera noder är valet av versioner bredare: dessa är kops, kube-aws (CoreOS+AWS), kube-up (föråldrade). Om du funderar på att använda AWS-baserade Kubernetes rekommenderar jag att du går med i AWS SIG, som träffas online varje fredag och publicerar en mängd intressant material om att arbeta med AWS Kubernetes.
Låt oss titta på hur Rolling Update utförs på dessa plattformar. Om det finns ett kluster med flera noder använder det en specifik version av bilden, till exempel WildFly:1. En rullande uppdatering innebär att bildversionen sekventiellt ersätts med en ny på varje nod, en efter en.
För att göra detta använder jag kommandot docker service update (tjänstnamn), där jag anger den nya versionen av WildFly:2-bilden och uppdateringsmetoden update-parallelism 2. Siffran 2 betyder att systemet kommer att uppdatera 2 applikationsbilder samtidigt, sedan en 10-sekunders uppdateringsfördröjning 10s, varefter nästa 2 bilder kommer att uppdateras på ytterligare 2 noder osv. Denna enkla rullande uppdateringsmekanism tillhandahålls till dig som en del av Docker.
I Kubernetes fungerar en rullande uppdatering så här. Replikeringskontrollern rc skapar en uppsättning repliker av samma version, och varje pod i denna webapp-rc är försedd med en etikett som finns i etcd. När jag behöver en pod använder jag applikationstjänsten för att komma åt etcd-förrådet, som förser mig med podden med den angivna etiketten.
I det här fallet har vi 3 pods i replikeringskontrollern som kör programmet WildFly version 1. Vid uppdatering i bakgrunden skapas en annan replikeringskontroller med samma namn och index i slutet - - xxxxx, där x är slumptal, och med samma etiketter. Nu har Application Service tre poddar med den gamla versionen av programmet och tre pods med den nya versionen i den nya replikeringskontrollern. Efter detta raderas de gamla poddarna, replikeringskontrollern med de nya poddarna byts om och tas i drift.
Låt oss gå vidare till övervakning. Docker har många inbyggda övervakningskommandon. Till exempel låter docker container stats kommandoradsgränssnittet dig visa information om containers tillstånd till konsolen varje sekund - processoranvändning, diskanvändning, nätverksbelastning. Docker Remote API-verktyget tillhandahåller data om hur klienten kommunicerar med servern. Den använder enkla kommandon, men är baserad på Docker REST API. I det här fallet betyder orden REST, Flash, Remote samma sak. När du kommunicerar med värden är det ett REST API. Docker Remote API låter dig få mer information om att köra behållare. Min blogg beskriver detaljerna för att använda denna övervakning med Windows Server.
Övervakning av docker-systemhändelser vid körning av ett multi-host-kluster gör det möjligt att få data om en värdkrasch eller en containerkrasch på en specifik värd, skalningstjänster och liknande. Från och med Docker 1.20 inkluderar den Prometheus, som bäddar in slutpunkter i befintliga applikationer. Detta gör att du kan ta emot mätvärden via HTTP och visa dem på instrumentpaneler.
En annan övervakningsfunktion är cAdvisor (förkortning för container advisor). Den analyserar och tillhandahåller resursanvändning och prestandadata från körande behållare, vilket ger Prometheus-statistik direkt från lådan. Det speciella med det här verktyget är att det bara tillhandahåller data för de senaste 60 sekunderna. Därför måste du kunna samla in denna data och lägga in den i en databas så att du kan övervaka en långsiktig process. Den kan också användas för att visa instrumentpanelens mätvärden grafiskt med Grafana eller Kibana. Min blogg har en detaljerad beskrivning av hur man använder cAdvisor för att övervaka containrar med hjälp av Kibanas instrumentpanel.
Nästa bild visar hur Prometheus-slutpunktsutgången ser ut och vilka mätvärden som är tillgängliga att visa.
Längst ner till vänster ser du mätvärden för HTTP-förfrågningar, svar etc., till höger är deras grafiska display.
Kubernetes inkluderar även inbyggda övervakningsverktyg. Den här bilden visar ett typiskt kluster som innehåller en huvud- och tre arbetsnoder.
Var och en av arbetsnoderna innehåller en automatiskt startad cAdvisor. Dessutom finns det Heapster, ett prestandaövervaknings- och mätsystem som är kompatibelt med Kubernetes version 1.0.6 och senare. Heapster låter dig samla in inte bara prestandamått för arbetsbelastningar, poddar och behållare, utan även händelser och andra signaler som genereras av hela klustret. För att samla in data pratar den med varje pods Kubelet, lagrar automatiskt informationen i InfluxDB-databasen och matar ut den som mätvärden till Grafana-instrumentpanelen. Kom dock ihåg att om du använder miniKube är den här funktionen inte tillgänglig som standard, så du måste använda tillägg för övervakning. Så det beror helt på var du kör behållarna och vilka övervakningsverktyg du kan använda som standard och vilka du behöver installera som separata tillägg.
Nästa bild visar Grafana-instrumentpaneler som visar körstatus för mina containrar. Det finns ganska mycket intressant data här. Naturligtvis finns det många kommersiella Docker och Kubernetes processövervakningsverktyg, såsom SysDig, DataDog, NewRelic. Vissa av dem har en 30-årig gratis provperiod, så du kan försöka hitta den som passar dig bäst. Personligen föredrar jag att använda SysDig och NewRelic, som integreras bra med Kubernetes. Det finns verktyg som integreras lika bra i både Docker- och Kubernetes-plattformar.
Några annonser 🙂
Tack för att du stannar hos oss. Gillar du våra artiklar? Vill du se mer intressant innehåll? Stöd oss genom att lägga en beställning eller rekommendera till vänner, , en unik analog av ingångsservrar, som uppfanns av oss för dig: (tillgänglig med RAID1 och RAID10, upp till 24 kärnor och upp till 40 GB DDR4).
Dell R730xd 2 gånger billigare i Equinix Tier IV datacenter i Amsterdam? Bara här i Nederländerna! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - från $99! Läs om
Källa: will.com