Docker Swarm, Kubernetes en Mesos zijn de populairste containerorkestratieframeworks. In zijn lezing vergelijkt Arun Gupta de volgende aspecten van Docker, Swarm en Kubernetes:
- Lokale ontwikkeling.
- Implementatiefuncties.
- Toepassingen met meerdere containers.
- Ontdekking van diensten.
- Het schalen van de dienst.
- Eenmalige taken.
- Integratie met Maven.
- "Rollende"-update.
- Een Couchbase-databasecluster maken.
Als gevolg hiervan krijgt u een duidelijk inzicht in wat elke orkestratietool te bieden heeft en leert u hoe u deze platforms effectief kunt gebruiken.
Arun Gupta is de hoofdtechnoloog voor open-sourceproducten bij Amazon Web Services en ontwikkelt al meer dan tien jaar de ontwikkelaarsgemeenschappen van Sun, Oracle, Red Hat en Couchbase. Heeft uitgebreide ervaring met het leiden van multifunctionele teams bij het ontwikkelen en implementeren van strategieën voor marketingcampagnes en -programma's. Hij leidde teams van Sun-ingenieurs, is een van de oprichters van het Java EE-team en de bedenker van de Amerikaanse tak van Devoxx10Kids. Arun Gupta is de auteur van meer dan tweeduizend berichten op IT-blogs en heeft lezingen gegeven in meer dan 4 landen.
Regel 55 bevat een COUCHBASE_URI die verwijst naar deze databaseservice, die ook is gemaakt met behulp van het Kubernetes-configuratiebestand. Als je naar regel 2 kijkt, zie je soort: Service is de service die ik aan het maken ben, genaamd couchbase-service, en dezelfde naam staat vermeld op regel 4. Hieronder staan enkele poorten.
De belangrijkste regels zijn 6 en 7. In de service zeg ik: "Hé, dit zijn de labels die ik zoek!", En deze labels zijn niets meer dan variabele paarnamen, en regel 7 verwijst naar mijn couchbase-rs-pod sollicitatie. Hieronder volgen de poorten die toegang bieden tot dezelfde labels.
Op regel 19 maak ik een nieuw type ReplicaSet, regel 31 bevat de naam van de afbeelding en regels 24-27 verwijzen naar de metagegevens die aan mijn pod zijn gekoppeld. Dit is precies waar de dienst naar op zoek is en waar de verbinding mee gemaakt moet worden. Aan het einde van het bestand is er een soort verbinding tussen de regels 55-56 en 4, die zegt: "gebruik deze service!"
Ik start mijn service dus als er een replicaset is, en aangezien elke replicaset een eigen poort heeft met het bijbehorende label, is deze bij de service inbegrepen. Vanuit het oogpunt van een ontwikkelaar bel je eenvoudigweg de service, die vervolgens de set replica's gebruikt die je nodig hebt.
Als gevolg hiervan heb ik een WildFly-pod die via Couchbase Service communiceert met de database-backend. Ik kan de frontend gebruiken met verschillende WildFly-pods, die ook communiceren met de couchbase-backend via de couchbase-service.
Later zullen we bekijken hoe een dienst die zich buiten het cluster bevindt, via zijn IP-adres communiceert met elementen die zich binnen het cluster bevinden en een intern IP-adres hebben.
Stateless containers zijn dus geweldig, maar hoe goed is het om stateful containers te gebruiken? Laten we eens kijken naar de systeeminstellingen voor stateful of persistente containers. In Docker zijn er vier verschillende benaderingen van de indeling van gegevensopslag waar u op moet letten. De eerste is Implicit Per-Container, wat betekent dat bij gebruik van couchbase-, MySQL- of MyDB-satellietcontainers ze allemaal beginnen met de standaard Sandbox. Dat wil zeggen dat alles wat in de database is opgeslagen, in de container zelf wordt opgeslagen. Als de container verdwijnt, verdwijnen de gegevens mee.
De tweede is Explicit Per-Container, wanneer u een specifieke opslag maakt met de docker-volumeopdracht, en daarin gegevens opslaat. De derde Per-Host-benadering houdt verband met opslagtoewijzing, waarbij alles wat in de container is opgeslagen tegelijkertijd op de host wordt gedupliceerd. Als de container uitvalt, blijven de gegevens op de host staan. Dit laatste is het gebruik van meerdere Multi-Host hosts, wat aan te raden is in de productiefase van diverse oplossingen. Stel dat uw containers met uw applicaties op de host draaien, maar u wilt uw gegevens ergens op internet opslaan en hiervoor gebruikt u automatische mapping voor gedistribueerde systemen.
Elk van deze methoden maakt gebruik van een specifieke opslaglocatie. Impliciete en expliciete per-container slaan gegevens op de host op in /var/lib/docker/volumes. Bij gebruik van de Per-Host-methode wordt de opslag in de container gemonteerd en wordt de container zelf op de host gemonteerd. Voor multihosts kunnen oplossingen zoals Ceph, ClusterFS, NFS, etc. worden gebruikt.
Als een persistente container uitvalt, wordt de opslagdirectory in de eerste twee gevallen ontoegankelijk, maar in de laatste twee gevallen blijft de toegang behouden. In het eerste geval hebt u echter toegang tot de repository via een Docker-host die op een virtuele machine draait. In het tweede geval gaan de gegevens ook niet verloren, omdat je een Expliciete opslag hebt aangemaakt.
Als de host uitvalt, is de opslagdirectory in de eerste drie gevallen niet beschikbaar; in het laatste geval wordt de verbinding met de opslag niet onderbroken. Ten slotte is de gedeelde functie in het eerste geval volledig uitgesloten voor opslag en in de rest wel mogelijk. In het tweede geval kunt u opslag delen, afhankelijk van of uw database gedistribueerde opslag ondersteunt of niet. In het geval van Per-Host is gegevensdistributie alleen mogelijk op een bepaalde host, en voor een multihost wordt dit verzorgd door clusteruitbreiding.
Hiermee moet rekening worden gehouden bij het maken van stateful containers. Een andere handige Docker-tool is de Volume-plug-in, die werkt volgens het principe van “batterijen aanwezig, maar moeten worden vervangen.” Wanneer u een Docker-container start, staat er: "Hé, zodra u een container met een database start, kunt u uw gegevens in deze container opslaan!" Dit is de standaardfunctie, maar u kunt deze wijzigen. Met deze plug-in kunt u een netwerkstation of iets dergelijks gebruiken in plaats van een containerdatabase. Het bevat een standaardstuurprogramma voor hostgebaseerde opslag en maakt containerintegratie mogelijk met externe opslagsystemen zoals Amazon EBS, Azure Storage en GCE Persistent disks.
De volgende dia toont de architectuur van de Docker Volume-plug-in.
De blauwe kleur vertegenwoordigt de Docker-client die is gekoppeld aan de blauwe Docker-host, die een lokale opslagengine heeft die u containers biedt voor het opslaan van gegevens. Groen geeft de Plugin Client en Plugin Daemon aan, die ook met de host zijn verbonden. Ze bieden de mogelijkheid om gegevens op te slaan in netwerkopslag van het type Storage Backend dat u nodig heeft.
De Docker Volume-plug-in kan worden gebruikt met Portworx-opslag. De PX-Dev-module is eigenlijk een container die u uitvoert en die verbinding maakt met uw Docker-host en waarmee u eenvoudig gegevens op Amazon EBS kunt opslaan.
Met de Portworx-client kunt u de status monitoren van verschillende opslagcontainers die op uw host zijn aangesloten. Als je mijn blog bezoekt, kun je lezen hoe je met Docker het maximale uit Portworx haalt.
Het concept van opslag in Kubernetes is vergelijkbaar met Docker en wordt weergegeven door mappen die toegankelijk zijn voor uw container in een pod. Ze zijn onafhankelijk van de levensduur van welke container dan ook. De meest voorkomende beschikbare opslagtypen zijn hostPath, nfs, awsElasticBlockStore en gsePersistentDisk. Laten we eens kijken hoe deze winkels in Kubernetes werken. Normaal gesproken bestaat het proces om ze te verbinden uit 3 stappen.
De eerste is dat iemand aan de netwerkkant, meestal een beheerder, u voorziet van permanente opslag. Hiervoor bestaat een bijbehorend PersistentVolume-configuratiebestand. Vervolgens schrijft de applicatie-ontwikkelaar een configuratiebestand met de naam PersistentVolumeClaim, of een PVC-opslagverzoek, waarin staat: “Ik heb 50 GB aan gedistribueerde opslag ingericht, maar zodat andere mensen de capaciteit ook kunnen gebruiken, vertel ik deze PVC dat ik momenteel slechts 10 GB nodig". Ten slotte is de derde stap dat uw verzoek wordt aangekoppeld als opslag, en dat de toepassing met de pod, replicaset of iets dergelijks deze gaat gebruiken. Het is belangrijk om te onthouden dat dit proces uit de 3 genoemde stappen bestaat en schaalbaar is.
De volgende dia toont de Kubernetes Persistence Container van de AWS-architectuur.
Binnen de bruine rechthoek die het Kubernetes-cluster vertegenwoordigt, bevinden zich één hoofdknooppunt en twee werkknooppunten, aangegeven in geel. Eén van de werkknooppunten bevat een oranje pod, opslag, een replicacontroller en een groene Docker Couchbase-container. Binnen het cluster, boven de knooppunten, geeft een paarse rechthoek aan dat de dienst van buitenaf toegankelijk is. Deze architectuur wordt aanbevolen voor het opslaan van gegevens op het apparaat zelf. Indien nodig kan ik mijn gegevens buiten het cluster in EBS opslaan, zoals weergegeven in de volgende dia. Dit is een typisch model voor schaalvergroting, maar er is een financieel aspect waarmee rekening moet worden gehouden bij het gebruik ervan: het opslaan van gegevens ergens op het netwerk kan duurder zijn dan op een host. Bij het kiezen van containerisatieoplossingen is dit een van de zwaarwegende argumenten.
Net als bij Docker kun je bij Portworx gebruik maken van persistente Kubernetes-containers.
Dit is wat in de huidige Kubernetes 1.6-terminologie een “StatefulSet” wordt genoemd: een manier van werken met Stateful-applicaties die gebeurtenissen verwerkt over het stoppen van de Pod en het uitvoeren van Graceful Shutdown. In ons geval zijn dergelijke toepassingen databases. In mijn blog lees je hoe je met Portworx een StatefulSet in Kubernetes maakt.
Laten we het hebben over het ontwikkelingsaspect. Zoals ik al zei, heeft Docker 2 versies: CE en EE, in het eerste geval hebben we het over een stabiele versie van de Community Edition, die eens in de drie maanden wordt bijgewerkt, in tegenstelling tot de maandelijks bijgewerkte versie van EE. Je kunt Docker downloaden voor Mac, Linux of Windows. Eenmaal geïnstalleerd, wordt Docker automatisch bijgewerkt en is het heel eenvoudig om aan de slag te gaan.
Voor Kubernetes geef ik de voorkeur aan de Minikube-versie: het is een goede manier om aan de slag te gaan met het platform door een cluster op één knooppunt te maken. Om clusters van meerdere knooppunten te maken, is de keuze aan versies groter: dit zijn kops, kube-aws (CoreOS+AWS), kube-up (verouderd). Als je op AWS gebaseerde Kubernetes wilt gebruiken, raad ik je aan lid te worden van de AWS SIG, die elke vrijdag online bijeenkomt en een verscheidenheid aan interessant materiaal publiceert over het werken met AWS Kubernetes.
Laten we eens kijken hoe Rolling Update op deze platforms wordt uitgevoerd. Als er een cluster van meerdere knooppunten is, wordt een specifieke versie van de afbeelding gebruikt, bijvoorbeeld WildFly:1. Een rolling update betekent dat de imageversie opeenvolgend wordt vervangen door een nieuwe op elk knooppunt, de een na de ander.
Om dit te doen, gebruik ik de opdracht docker service update (servicenaam), waarin ik de nieuwe versie van de WildFly:2-afbeelding en de updatemethode update-parallelisme 2 specificeer. Het getal 2 betekent dat het systeem 2 applicatie-images zal bijwerken tegelijkertijd, daarna een updatevertraging van 10 seconden van 10 seconden, waarna de volgende 2 afbeeldingen worden bijgewerkt op nog 2 knooppunten, enz. Dit eenvoudige, doorlopende updatemechanisme wordt u aangeboden als onderdeel van Docker.
In Kubernetes werkt een rolling update als volgt. De replicatiecontroller rc maakt een set replica's van dezelfde versie, en elke pod in deze webapp-rc wordt voorzien van een label in etcd. Als ik een pod nodig heb, gebruik ik de Application Service om toegang te krijgen tot de etcd-repository, die mij de pod levert met het opgegeven label.
In dit geval hebben we 3 pods in de replicatiecontroller waarop de toepassing WildFly versie 1 draait. Bij het updaten op de achtergrond wordt een andere replicatiecontroller gemaakt met dezelfde naam en index aan het einde - - xxxxx, waarbij x willekeurige getallen zijn, en met dezelfde etiketten. Nu heeft Application Service drie peulen met de oude versie van de applicatie en drie peulen met de nieuwe versie in de nieuwe replicatiecontroller. Hierna worden de oude pods verwijderd, wordt de replicatiecontroller met de nieuwe pods hernoemd en in gebruik genomen.
Laten we verder gaan met het monitoren. Docker heeft veel ingebouwde monitoringopdrachten. Met de opdrachtregelinterface van Docker Container Stats kunt u bijvoorbeeld elke seconde informatie over de status van containers op de console weergeven: processorgebruik, schijfgebruik, netwerkbelasting. De Docker Remote API-tool biedt gegevens over hoe de client met de server communiceert. Het maakt gebruik van eenvoudige opdrachten, maar is gebaseerd op de Docker REST API. In dit geval betekenen de woorden REST, Flash, Remote hetzelfde. Wanneer u met de host communiceert, is het een REST API. Met de Docker Remote API krijgt u meer informatie over het uitvoeren van containers. Mijn blog schetst de details van het gebruik van deze monitoring met Windows Server.
Het monitoren van docker-systeemgebeurtenissen bij het uitvoeren van een cluster met meerdere hosts maakt het mogelijk om gegevens te verkrijgen over een hostcrash of een containercrash op een specifieke host, schaalservices en dergelijke. Vanaf Docker 1.20 bevat het Prometheus, dat eindpunten in bestaande applicaties insluit. Hierdoor kunt u via HTTP statistieken ontvangen en op dashboards weergeven.
Een andere monitoringfunctie is cAdvisor (afkorting van containeradviseur). Het analyseert en levert gegevens over het gebruik van bronnen en prestatiegegevens van actieve containers, en biedt direct uit de doos Prometheus-statistieken. Het bijzondere aan deze tool is dat deze alleen gegevens van de laatste 60 seconden levert. Daarom moet u deze gegevens kunnen verzamelen en in een database kunnen plaatsen, zodat u een langdurig proces kunt volgen. Het kan ook worden gebruikt om dashboardstatistieken grafisch weer te geven met behulp van Grafana of Kibana. Op mijn blog staat een gedetailleerde beschrijving van hoe u cAdvisor kunt gebruiken om containers te monitoren met behulp van het Kibana-dashboard.
De volgende dia laat zien hoe de Prometheus-eindpuntuitvoer eruit ziet en welke statistieken beschikbaar zijn om weer te geven.
Linksonder zie je statistieken voor HTTP-verzoeken, reacties, etc., rechts is hun grafische weergave.
Kubernetes bevat ook ingebouwde monitoringtools. Deze dia toont een typisch cluster met één master- en drie werkknooppunten.
Elk van de werkende knooppunten bevat een automatisch gestarte cAdvisor. Daarnaast is er Heapster, een systeem voor prestatiemonitoring en verzameling van statistieken dat compatibel is met Kubernetes versie 1.0.6 en hoger. Met Heapster kunt u niet alleen prestatiestatistieken verzamelen van workloads, pods en containers, maar ook gebeurtenissen en andere signalen die door het hele cluster worden gegenereerd. Om gegevens te verzamelen, praat het met de Kubelet van elke pod, slaat het de informatie automatisch op in de InfluxDB-database en voert het als statistieken uit naar het Grafana-dashboard. Houd er echter rekening mee dat als u miniKube gebruikt, deze functie niet standaard beschikbaar is, dus u zult add-ons moeten gebruiken voor monitoring. Het hangt dus allemaal af van waar je de containers draait en welke monitoringtools je standaard kunt gebruiken en die je als aparte add-ons moet installeren.
De volgende dia toont Grafana-dashboards die de actieve status van mijn containers tonen. Er zijn hier behoorlijk wat interessante gegevens. Natuurlijk zijn er veel commerciële Docker- en Kubernetes-procesmonitoringtools, zoals SysDig, DataDog en NewRelic. Sommigen van hen hebben een gratis proefperiode van 30 jaar, dus u kunt proberen degene te vinden die het beste bij u past. Persoonlijk gebruik ik liever SysDig en NewRelic, die goed integreren met Kubernetes. Er zijn tools die even goed kunnen worden geïntegreerd in zowel Docker- als Kubernetes-platforms.
Sommige advertenties 🙂
Bedankt dat je bij ons bent gebleven. Vind je onze artikelen leuk? Wil je meer interessante inhoud zien? Steun ons door een bestelling te plaatsen of door vrienden aan te bevelen, , een unieke analoog van servers op instapniveau, die door ons voor u is uitgevonden: (beschikbaar met RAID1 en RAID10, tot 24 cores en tot 40GB DDR4).
Dell R730xd 2x goedkoper in Equinix Tier IV datacenter in Amsterdam? Alleen hier in Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - vanaf $99! Lees over
Bron: www.habr.com