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.
- Multi-containertoepassingen.
- Servicedetectie.
- De service opschalen.
- Taken die u maar één keer hoeft uit te voeren.
- Integratie met Maven.
- "Rollende" update.
- Een Couchbase DB-cluster maken.
Hierdoor krijgt u een duidelijk beeld van wat elke orkestratietool te bieden heeft en leert u technieken om deze platforms effectief te gebruiken.
Arun Gupta is de belangrijkste open source-technoloog voor Amazon Web Services en houdt zich al meer dan tien jaar bezig met het opbouwen van ontwikkelaarscommunity's bij Sun, Oracle, Red Hat en Couchbase. Heeft ruime ervaring in het leiden van multifunctionele teams die betrokken zijn bij het ontwikkelen en implementeren van marketingcampagnes en programmastrategieën. Hij heeft leiding gegeven aan engineeringteams bij Sun, is een van de oprichters van het Java EE-team en is de oprichter van de Amerikaanse afdeling van Devoxx10Kids. Arun Gupta heeft meer dan 4 berichten op IT-blogs geschreven en heeft in meer dan 2 landen lezingen gegeven.
Regel 55 bevat de COUCHBASE_URI, die naar deze databaseservice verwijst, die ook wordt gemaakt met behulp van het Kubernetes-configuratiebestand. Als je naar regel 2 kijkt, zie je kind: Service – dit is de service die ik aan het maken ben, genaamd couchbase-service, en dat is dezelfde naam die op regel 4 is gespecificeerd. Daaronder staan enkele poorten.
De sleutellijnen zijn 6 en 7. In de bediening zeg ik: "Hé, dit zijn de labels die ik zoek!" en die labels zijn niets meer dan namen van variabele paren, en regel 7 verwijst naar mijn couchbase-rs-pod-app. Hieronder vindt u de poorten die toegang bieden tot deze labels.
Op regel 19 maak ik een nieuw ReplicaSet-type, regel 31 bevat de afbeeldingsnaam en de regels 24-27 verwijzen naar de metagegevens die aan mijn pod zijn gekoppeld. Dit is precies wat de dienst zoekt en waarmee de verbinding tot stand moet worden gebracht. Aan het einde van het bestand staat een soort verbinding tussen regel 55-56 en 4, met de tekst: "gebruik deze service!"
Ik start mijn service dus wanneer ik een replicaset heb. Aangezien elke replicaset een eigen poort met een bijbehorend label heeft, is deze opgenomen in de service. Vanuit het perspectief van een ontwikkelaar roept u simpelweg de service aan, die vervolgens de set replica's aanroept die u nodig hebt.
Ik heb dus een WildFly-pod die via de Couchbase Service communiceert met de database-backend. Ik kan een frontend gebruiken met meerdere WildFly-pods die ook via de couchbase-service met de couchbase-backend communiceert.
Later bekijken we hoe een service 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 geweldig, maar hoe nuttig is het om stateful containers te gebruiken? Laten we eens kijken naar de systeeminstellingen voor stateful of permanente containers. Er zijn vier verschillende benaderingen voor de indeling van gegevensopslag in Docker waarmee u rekening moet houden. De eerste is Implicit Per-Container, wat betekent dat wanneer u gebruikmaakt van volledige containers zoals couchbase, MySQL of MyDB, deze allemaal worden uitgevoerd 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 ook de gegevens.
De tweede is Expliciet per container, waarbij u een specifieke opslag maakt met de opdracht docker volume create en daar gegevens in opslaat. De derde Per-Host-benadering maakt gebruik van opslagmapping, waarbij alles wat in een container is opgeslagen, gelijktijdig op de host wordt gerepliceerd. Als de container uitvalt, blijven de gegevens op de host staan. De laatste is het gebruik van meerdere Multi-Host hosts, wat raadzaam is in de productiefase van verschillende oplossingen. Stel dat u containers hebt met uw applicaties die op een host draaien, maar u wilt uw gegevens ergens op internet opslaan en u gebruikt hiervoor automatische mapping voor gedistribueerde systemen.
Elk van deze methoden maakt gebruik van een specifieke opslaglocatie. Impliciete en expliciete opslag per container van gegevens op de host in /var/lib/docker/volumes. Bij de Per-Host-methode wordt de opslag in de container gemonteerd en wordt de container zelf op de host gemonteerd. Voor multi-hosts kunnen oplossingen zoals Ceph, ClusterFS, NFS, etc. worden gebruikt.
Als een persistente container uitvalt, is de opslagdirectory in de eerste twee gevallen niet meer beschikbaar, maar in de laatste twee gevallen blijft de toegang behouden. In het eerste geval kunt u de repository benaderen via een Docker-host die op een virtuele machine draait. In het tweede geval gaan de gegevens ook niet verloren, omdat u 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 voor opslag in het eerste geval volledig uitgesloten en is deze in de andere gevallen wel mogelijk. In het tweede geval kunt u de opslag delen, afhankelijk van de vraag of uw database gedistribueerde opslag ondersteunt of niet. Bij Per-Host is gegevensdistributie alleen mogelijk op een bepaalde host, terwijl dit bij multi-host gebeurt via 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 'batterijen zijn aanwezig maar vervangbaar'. Wanneer u een Docker-container start, verschijnt de melding: "Als u een container met een database uitvoert, kunt u uw gegevens in deze container opslaan!" Deze functie is standaard, maar u kunt dit wijzigen. Met deze plugin kunt u een netwerkstation of iets dergelijks gebruiken in plaats van een containerdatabase. Het bevat een standaardstuurprogramma voor hostgebaseerde opslag en maakt containerintegratie met externe opslagsystemen zoals Amazon EBS, Azure Storage en GCE Persistent Disks mogelijk.
De volgende dia toont de architectuur van de Docker Volume-plug-in.
In het blauw ziet u de Docker-client. Deze is verbonden met een blauwe Docker-host met een lokale opslagengine die u containers biedt om uw gegevens in op te slaan. In het groen staan de Plugin Client en de Plugin Daemon, die ook verbonden zijn met de host. Ze bieden de mogelijkheid om gegevens op te slaan in netwerkopslag van het type Storage Backend dat u nodig hebt.
De Docker Volume-plug-in kan worden gebruikt met Portworx-opslag. De PX-Dev-module is in feite een container die u uitvoert en die verbinding maakt met een Docker-host. Hiermee kunt u eenvoudig gegevens opslaan op Amazon EBS.
Met de Portworx-client kunt u de status van containers met verschillende opslagmedia die met uw host zijn verbonden, bewaken. Als u mijn blog bezoekt, kunt u lezen hoe u Portworx het meest effectief met Docker kunt gebruiken.
Het opslagconcept in Kubernetes is vergelijkbaar met dat van Docker en wordt vertegenwoordigd door mappen die toegankelijk zijn voor uw container in de pod. Ze zijn onafhankelijk van de levensduur van een container. De meest voorkomende beschikbare opslagtypen zijn hostPath, nfs, awsElasticBlockStore en gsePersistentDisk. Laten we eens kijken hoe deze opslagmogelijkheden werken in Kubernetes. Normaal gesproken bestaat het verbindingsproces uit 3 stappen.
De eerste is dat iemand aan de netwerkkant, meestal een beheerder, u permanente opslag ter beschikking stelt. Hiervoor is er een bijbehorend configuratiebestand PersistentVolume. Vervolgens schrijft de applicatieontwikkelaar een configuratiebestand met de naam PersistentVolumeClaim (PVC-opslagaanvraag) waarin staat: 'Ik heb 50 GB aan gedistribueerde opslag ingericht, maar om andere mensen die capaciteit te laten gebruiken, geef ik in deze PVC aan dat ik op dit moment slechts 10 GB nodig heb.' De derde stap is dat uw verzoek wordt gekoppeld als opslag en dat de toepassing die de pod, replicaset of wat dan ook heeft, deze gaat gebruiken. Het is belangrijk om te onthouden dat dit proces uit de drie genoemde stappen bestaat en dat er ruimte is voor opschaling.
De volgende dia toont de AWS-architectuur Kubernetes Persistence Container.
Binnen de bruine rechthoek, die het Kubernetes-cluster voorstelt, bevinden zich één masterknooppunt en twee werkknooppunten, weergegeven in het geel. Een van de werkernodes bevat een oranje pod, opslag, replicacontroller en een groene Docker Couchbase-container. Binnen het cluster, boven de knooppunten, geeft een paarse rechthoek een extern toegankelijke service aan. 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 in de volgende dia wordt getoond. Dit is een typisch model voor schaalbaarheid, maar wanneer u dit model gebruikt, moet u rekening houden met het financiële aspect: het opslaan van gegevens ergens op het netwerk kan duurder zijn dan op de host. Bij de keuze voor containerisatieoplossingen is dit een van de zwaarwegende argumenten.
Net als met Docker kunt u met Portworx persistente Kubernetes-containers gebruiken.
Dit is wat in de huidige Kubernetes 1.6-terminologie een "StatefulSet" wordt genoemd: een manier van werken met stateful-applicaties die Pod-afsluitgebeurtenissen en Graceful Shutdowns afhandelt. In ons geval zijn zulke toepassingen databases. Lees mijn blogpost over het maken van een StatefulSet in Kubernetes met behulp van Portworx.
Laten we het over het ontwikkelingsaspect hebben. Zoals ik al zei, Docker kent twee versies: CE en EE. In het eerste geval hebben we het over de stabiele versie van Community Edition, die elke drie maanden wordt bijgewerkt, in tegenstelling tot de maandelijks bijgewerkte versie van EE. U kunt Docker downloaden voor Mac, Linux of Windows. Nadat Docker is geïnstalleerd, wordt het automatisch bijgewerkt en kunt u er heel eenvoudig mee aan de slag.
In Kubernetes geef ik de voorkeur aan de Minikube-versie. Dit is een goede manier om met het platform aan de slag te gaan door een cluster op één knooppunt te maken. Voor het maken van clusters van meerdere knooppunten is de keuze uit versies groter: kops, kube-aws (CoreOS+AWS), kube-up (verouderd). Als u Kubernetes op AWS gaat gebruiken, raad ik u aan om lid te worden van de AWS SIG-groep. Deze groep komt elke vrijdag online bijeen en publiceert allerlei interessante materialen over het werken met Kubernetes op AWS.
Laten we eens kijken hoe Rolling Update op deze platforms wordt uitgevoerd. Als er sprake is van een cluster met meerdere knooppunten, wordt er een specifieke versie van de afbeelding gebruikt, bijvoorbeeld WildFly:1. Een rolling update betekent dat de imageversie op elk knooppunt één voor één wordt vervangen door een nieuwe.
Hiervoor gebruik ik de opdracht docker service update (servicenaam), waarin ik de nieuwe versie van de WildFly:2-image en de update-parallelism 2-updatemethode opgeef. Het getal 2 betekent dat het systeem 2 applicatie-images tegelijk bijwerkt, waarna er een vertraging van 10 seconden is, waarna de volgende 10 images op 2 andere knooppunten worden bijgewerkt, enzovoort. Dit eenvoudige mechanisme voor doorlopende updates wordt u aangeboden als onderdeel van Docker.
In Kubernetes werken rolling updates 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. Wanneer ik een pod nodig heb, krijg ik via de Application Service toegang tot de etcd-opslag. Deze service biedt mij deze pod aan met het opgegeven label.
In dit geval hebben we 3 pods in de replicatiecontroller, waarop de WildFly versie 1-applicatie wordt uitgevoerd. Bij het updaten wordt op de achtergrond een andere replicatiecontroller gemaakt met dezelfde naam en index aan het einde — — xxxxx, waarbij x willekeurige getallen zijn en met dezelfde labels. De Application Service heeft nu drie pods met de oude versie van de applicatie en drie pods 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 het over monitoring hebben. Docker heeft veel ingebouwde opdrachten voor monitoring. Met de opdrachtregelinterface docker container stats kunt u bijvoorbeeld elke seconde gegevens over de status van containers naar de console sturen, zoals processorgebruik, schijfgebruik en netwerkbelasting. De Docker Remote API-tool biedt informatie over de manier waarop 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 en Remote hetzelfde. Wanneer u met de host communiceert, is dit een REST API. Met de Docker Remote API krijgt u meer informatie over het uitvoeren van containers. In mijn blog ga ik dieper in op het gebruik van deze monitoring met Windows Server.
Door docker-systeemgebeurtenissen te bewaken bij het starten van een cluster met meerdere hosts, kunt u gegevens verkrijgen over een hostcrash of een containercrash op een specifieke host, het schalen van services en dergelijke. Vanaf Docker 1.20 omvat het Prometheus, waarmee eindpunten in bestaande applicaties kunnen worden geïntegreerd. Hiermee kunt u statistieken via HTTP ophalen en op dashboards weergeven.
Een andere monitoringfunctie is cAdvisor (afkorting van container Advisor). Het analyseert en levert gegevens over resourcegebruik en prestaties van actieve containers, waardoor u direct over Prometheus-statistieken beschikt. Het bijzondere aan deze tool is dat het alleen gegevens van de laatste 60 seconden levert. U moet dus de mogelijkheid bieden om deze gegevens te verzamelen en in een database te plaatsen, zodat u een proces op de lange termijn kunt monitoren. Het kan ook worden gebruikt om statistieken grafisch weer te geven op een dashboard met behulp van Grafana of Kibana. Mijn blog bevat een gedetailleerde beschrijving van hoe u cAdvisor kunt gebruiken om containers te monitoren met behulp van een Kibana-dashboard.
De volgende dia toont hoe de uitvoer van een Prometheus-eindpunt eruitziet en welke statistieken beschikbaar zijn om weer te geven.
Linksonder ziet u de statistieken voor HTTP-verzoeken, reacties, etc. Rechts ziet u de grafische weergave hiervan.
Kubernetes beschikt ook over ingebouwde monitoringtools. Deze dia toont een typisch cluster met één master- en drie werkernodes.
Elk van de werkernodes bevat een automatisch gestarte cAdvisor. Daarnaast is er Heapster, een systeem voor prestatiebewaking en het verzamelen van statistieken dat compatibel is met Kubernetes versie 1.0.6 en hoger. Met Heapster kunt u niet alleen prestatiegegevens voor workloads, pods en containers verzamelen, maar ook gebeurtenissen en andere signalen die door het gehele cluster worden gegenereerd. Om gegevens te verzamelen, communiceert het met de Kubelet van elke pod, waarbij de informatie automatisch wordt opgeslagen in een InfluxDB-database en als metrische gegevens naar het Grafana-dashboard wordt verzonden. Houd er echter rekening mee dat deze functie niet standaard beschikbaar is als u miniKube gebruikt. In dat geval zult u add-ons moeten gebruiken voor monitoring. Het hangt er dus vanaf waar u containers uitvoert en welke monitoringtools u standaard kunt gebruiken en welke u als aparte add-ons moet installeren.
De volgende dia toont Grafana-dashboards die de actieve status van mijn containers weergeven. Er staan hier nogal wat interessante gegevens. Er zijn uiteraard veel commerciële tools voor het monitoren van Docker- en Kubernetes-processen, zoals SysDig, DataDog en NewRelic. Sommige hebben een gratis proefperiode van 30 dagen, zodat u het kunt uitproberen en kunt kiezen welke het beste bij u past. Persoonlijk gebruik ik liever SysDig en NewRelic, die goed integreren met Kubernetes. Er zijn tools die even goed integreren in beide platformen: Docker en Kubernetes.
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
