Kubernetes - de cloud temmen

Als u Linux wilt gebruiken om services aan een bedrijf te verlenen, moeten die services veilig, veerkrachtig en schaalbaar zijn. Mooie woorden, maar wat bedoelen we ermee?

‘Veilig’ betekent dat gebruikers toegang hebben tot de gegevens die ze nodig hebben, of het nu gaat om alleen-lezen of schrijftoegang. Tegelijkertijd worden geen gegevens blootgesteld aan een partij die niet bevoegd is om deze in te zien. Beveiliging is bedrieglijk: je kunt denken dat je alles hebt beschermd om er later achter te komen dat er gaten zijn. Vanaf het begin van een project in beveiliging ontwerpen is veel gemakkelijker dan later proberen om het achteraf aan te passen.

‘Veerkrachtig’ betekent dat uw services fouten binnen de infrastructuur tolereren. Een storing kan een server-schijfcontroller zijn die geen toegang meer heeft tot schijven, waardoor de gegevens onbereikbaar zijn. Of de storing kan een netwerkswitch zijn waardoor twee of meer systemen niet langer kunnen communiceren. In deze context is een "single point of failure" of SPOF een storing die de beschikbaarheid van de service negatief beïnvloedt. Een veerkrachtige infrastructuur is er een zonder SPOF's.

‘Schaalbaar’ beschrijft het vermogen van systemen om pieken in de vraag netjes op te vangen. Het bepaalt ook hoe gemakkelijk wijzigingen in systemen kunnen worden aangebracht. Bijvoorbeeld het toevoegen van een nieuwe gebruiker, het vergroten van de opslagcapaciteit of het verplaatsen van een infrastructuur van Amazon Web Services naar Google Cloud - of zelfs intern verhuizen.

Zodra uw infrastructuur verder gaat dan één server, zijn er tal van mogelijkheden om de beveiliging, veerkracht en schaalbaarheid te vergroten. We gaan kijken hoe deze problemen traditioneel zijn opgelost en welke nieuwe technologie beschikbaar is die het aanzien van big application computing verandert.

Krijg meer Linux!

Vind je het leuk wat je leest? Wilt u meer Linux en open source? We kunnen leveren, letterlijk! Abonneer u vandaag nog op Linux Format voor een spotprijs. U kunt printuitgaven, digitale edities of waarom niet beide krijgen? Wij bezorgen wereldwijd aan uw deur tegen een eenvoudige jaarlijkse vergoeding. Dus maak uw leven beter en gemakkelijker, schrijf u nu in!

Om te begrijpen wat er vandaag mogelijk is, is het handig om te kijken naar hoe technologieprojecten traditioneel worden geïmplementeerd. Vroeger - dat wil zeggen meer dan 10 jaar geleden - zouden bedrijven hardware kopen of leasen om alle componenten van hun applicaties uit te voeren. Zelfs relatief eenvoudige applicaties, zoals een WordPress-website, hebben meerdere componenten. In het geval van WordPress is een MySQL-database nodig, samen met een webserver, zoals Apache, en een manier om met PHP-code om te gaan. Dus ze zouden een server bouwen, Apache, PHP en MySQL opzetten, WordPress installeren en klaar was Kees.

Over het algemeen werkte dat. Het werkte goed genoeg dat er vandaag de dag nog steeds een groot aantal servers op precies die manier is geconfigureerd. Maar het was niet perfect, en twee van de grotere problemen waren veerkracht en schaalbaarheid.

Gebrek aan veerkracht betekende dat elk significant probleem op de server zou leiden tot verlies van service. Het is duidelijk dat een catastrofale storing zou betekenen dat er geen website zou zijn, maar er was ook geen ruimte om gepland onderhoud uit te voeren zonder de website te beïnvloeden. Zelfs het installeren en activeren van een routinematige beveiligingsupdate voor Apache zou een onderbreking van een paar seconden voor de website vereisen.

Het veerkrachtprobleem werd grotendeels opgelost door het bouwen van ‘high-availability clusters’. Het principe was om de website door twee servers te laten draaien, zo geconfigureerd dat het uitvallen van een van de twee niet tot gevolg had dat de website offline was. De geleverde service was veerkrachtig, zelfs als de individuele servers dat niet waren.

Abstracte wolken

Een deel van de kracht van Kubernetes is de abstractie die het biedt. Vanuit het perspectief van een ontwikkelaar ontwikkelen ze de applicatie om in een Docker-container te draaien. Het maakt Docker niet uit of het op Windows, Linux of een ander besturingssysteem draait. Diezelfde Docker-container kan van de MacBook van de ontwikkelaar worden gehaald en zonder enige aanpassing onder Kubernetes worden uitgevoerd.

De Kubernetes-installatie zelf kan een enkele machine zijn. Veel van de voordelen van Kubernetes zijn natuurlijk niet beschikbaar: er is geen automatische schaalverdeling; er is een duidelijk single point of failure, enzovoort. Als proof of concept in een testomgeving werkt het echter.

Zodra u klaar bent voor productie, kunt u deze intern uitvoeren of op een cloudprovider zoals AWS of Google Cloud. De Cloud-providers hebben een aantal ingebouwde services die helpen bij het uitvoeren van Kubernetes, maar geen van deze zijn harde vereisten. Als u wilt schakelen tussen Google, Amazon en uw eigen infrastructuur, stelt u Kubernetes in en gaat u overstappen. Geen van uw applicaties hoeft op enigerlei wijze te veranderen.

En waar is Linux? Kubernetes draait op Linux, maar het besturingssysteem is onzichtbaar voor de applicaties. Dit is een belangrijke stap in de volwassenheid en bruikbaarheid van IT-infrastructuren.

Het Slashdot-effect

Het schaalbaarheidsprobleem is iets lastiger. Stel dat uw WordPress-site 1000 bezoekers per maand krijgt. Op een dag wordt uw bedrijf vermeld op Radio 4 of ontbijt-tv. Plots krijg je in 20 minuten meer dan een maand aan bezoekers. We hebben allemaal wel eens gehoord dat websites ‘crashen’, en dat is meestal de reden: een gebrek aan schaalbaarheid.

De twee servers die hebben geholpen met veerkracht, konden een hogere werklast aan dan één server alleen, maar dat is nog steeds beperkt. U betaalt 100 procent van de tijd voor twee servers en meestal werkten beide perfect. Het is waarschijnlijk dat iemand alleen uw site kan beheren. Vervolgens vermeldt John Humphrys uw bedrijf op Today en zou u 10 servers nodig hebben om de belasting te verwerken, maar slechts voor een paar uur.

De betere oplossing voor zowel het probleem van veerkracht als schaalbaarheid was cloud computing. Stel een of twee servers in - de kleine servers waarop uw applicaties draaien - op Amazon Web Services (AWS) of Google Cloud, en als een van de instanties om de een of andere reden zou mislukken, zou deze automatisch opnieuw worden opgestart. Stel auto-scaling correct in en wanneer Mr Humphrys ervoor zorgt dat de werklast op uw webserverinstanties snel stijgt, worden automatisch extra serverinstanties gestart om de werklast te verdelen. Later, als de rente afneemt, worden die extra gevallen gestopt en betaalt u alleen voor wat u gebruikt. Perfect … of toch?

Hoewel de cloudoplossing veel flexibeler is dan de traditionele stand-alone server, zijn er nog steeds problemen. Het updaten van alle actieve cloudinstanties is niet eenvoudig. Ontwikkelen voor de cloud kent ook uitdagingen: de laptop die uw ontwikkelaars gebruiken, lijkt misschien op de cloudinstantie, maar is niet hetzelfde. Als u zich aan AWS committeert, is migreren naar Google Cloud een complexe onderneming. En stel dat u, om wat voor reden dan ook, uw computergebruik simpelweg niet wilt overdragen aan Amazon, Google of Microsoft?

Containers zijn naar voren gekomen als een middel om applicaties met al hun afhankelijkheden in één pakket te verpakken dat overal kan worden uitgevoerd. Containers, zoals Docker, kunnen op dezelfde manier op de laptops van uw ontwikkelaars worden uitgevoerd als op uw cloudinstances, maar het beheren van een vloot containers wordt een steeds grotere uitdaging naarmate het aantal containers toeneemt.

Het antwoord is containerorkestratie. Dit is een belangrijke verschuiving in focus. Vroeger zorgden we ervoor dat we genoeg servers hadden, of ze nu fysiek of virtueel waren, om ervoor te zorgen dat we de werklast konden onderhouden. Het gebruik van de automatische schaling van de cloudproviders hielp, maar we hadden nog steeds te maken met instanties. We moesten load balancers, firewalls, gegevensopslag en meer handmatig configureren. Met containerorkestratie wordt dat allemaal (en nog veel meer) geregeld. We specificeren de resultaten die we nodig hebben en onze tools voor containerorkestratie voldoen aan onze vereisten. We specificeren wat we gedaan willen hebben, in plaats van hoe we het gedaan willen hebben.

Continue integratie en continue implementatie kunnen goed werken met Kubernetes. Hier is een overzicht van Jenkins die wordt gebruikt om een Java-applicatie te bouwen en te implementeren

Word een Kubernete

Kubernetes (ku-ber-net-eez) is tegenwoordig de toonaangevende tool voor containerorkestratie en kwam van Google. Als iemand weet hoe hij grootschalige IT-infrastructuren moet runnen, doet Google dat. De oorsprong van Kubernetes is Borg, een intern Google-project dat nog steeds wordt gebruikt om de meeste Google-applicaties uit te voeren, waaronder de zoekmachine, Gmail, Google Maps en meer. Borg was een geheim totdat Google er in 2015 een paper over publiceerde, maar de paper maakte heel duidelijk dat Borg de belangrijkste inspiratiebron was achter Kubernetes.

Borg is een systeem dat computerbronnen in de datacenters van Google beheert en ervoor zorgt dat de toepassingen van Google, zowel in productie als anderszins, blijven werken ondanks hardwarestoringen, uitputting van bronnen of andere problemen die anders tot een storing zouden kunnen hebben geleid. Het doet dit door de duizenden knooppunten die samen een Borg-cel vormen en de containers die erop draaien zorgvuldig te volgen, en containers te starten of te stoppen als reactie op problemen of fluctuaties in de belasting.

Kubernetes zelf is ontstaan uit het GIFEE-initiatief (‘Google’s Infrastructure For Everyone Else’) van Google en is ontworpen als een vriendelijkere versie van Borg die nuttig zou kunnen zijn buiten Google. Het werd in 2015 aan de Linux Foundation geschonken door de oprichting van de Cloud Native Computing Foundation (CNCF).

Kubernetes biedt een systeem waarmee u uw gecontaineriseerde applicaties en services 'declareert', en het zorgt ervoor dat uw applicaties volgens die declaraties werken. Als uw programma's externe bronnen nodig hebben, zoals opslag of load balancers, kan Kubernetes deze automatisch inrichten. Het kan uw applicaties omhoog of omlaag schalen om veranderingen in de belasting bij te houden, en kan zelfs uw hele cluster schalen wanneer dat nodig is. De componenten van uw programma hoeven niet eens te weten waar ze worden uitgevoerd: Kubernetes biedt interne naamgevingsservices aan applicaties zodat ze verbinding kunnen maken met "wp_mysql" en automatisch worden verbonden met de juiste bron. ''

Het eindresultaat is een platform dat kan worden gebruikt om uw applicaties op elke infrastructuur uit te voeren, van een enkele machine via een lokaal rack met systemen tot cloudgebaseerde vloten van virtuele machines die op elke grote cloudprovider draaien, allemaal met dezelfde containers. en configuratie. Kubernetes is provideronafhankelijk: voer het uit waar u maar wilt.

Kubernetes is een krachtig hulpmiddel en is noodzakelijkerwijs complex. Voordat we een overzicht krijgen, moeten we enkele termen introduceren die binnen Kubernetes worden gebruikt. Containers draaien enkele applicaties, zoals hierboven besproken, en zijn gegroepeerd in pods. Een pod is een groep nauw verbonden containers die samen op dezelfde host worden geïmplementeerd en een aantal bronnen delen. De containers binnen een pod werken als een team: ze voeren gerelateerde functies uit, zoals een applicatiecontainer en een logboekregistratiecontainer met specifieke instellingen voor de applicatie.

Een overzicht van Kubernetes met de master die de belangrijkste componenten en twee knooppunten uitvoert. Merk op dat in de praktijk de mastercomponenten over meerdere systemen kunnen worden verdeeld

Vier belangrijke Kubernetes-componenten zijn de API Server, de Scheduler, de Controller Manager en een gedistribueerde configuratiedatabase met de naam etcd. De API-server vormt het hart van Kubernetes en fungeert als het primaire eindpunt voor alle beheerverzoeken. Deze kunnen worden gegenereerd door verschillende bronnen, waaronder andere Kubernetes-componenten, zoals de planner, beheerders via opdrachtregel- of webgebaseerde dashboards en gecontaineriseerde applicaties zelf. Het valideert verzoeken en werkt gegevens bij die zijn opgeslagen in etcd.

De Scheduler bepaalt op welke knooppunten de verschillende pods worden uitgevoerd, rekening houdend met beperkingen zoals resourcevereisten, hardware- of softwarebeperkingen, werkbelasting, deadlines en meer.

De Controller Manager bewaakt de status van het cluster en zal proberen om pods te starten of te stoppen, zoals noodzakelijk, via de API Server, om het cluster in de gewenste staat te brengen. Het beheert ook enkele interne verbindingen en beveiligingsfuncties.

Elk knooppunt voert een Kubelet-proces uit, dat communiceert met de API-server en containers beheert - meestal met behulp van Docker - en Kube-Proxy, dat de netwerkproxy en taakverdeling binnen het cluster afhandelt.

Het etcd gedistribueerde databasesysteem ontleent zijn naam aan de /enz map op Linux-systemen, die wordt gebruikt om systeemconfiguratie-informatie te bevatten, plus het achtervoegsel 'd', vaak gebruikt om een daemon-proces aan te duiden. Het doel van etcd is om sleutelwaardegegevens op een gedistribueerde, consistente en fouttolerante manier op te slaan.

De API-server bewaart al zijn statusgegevens in etcd en kan vele instanties tegelijkertijd uitvoeren. De planner en controllerbeheerder kunnen slechts één actief exemplaar hebben, maar gebruiken een leasesysteem om te bepalen welk actief exemplaar de master is. Dit alles betekent dat Kubernetes kan draaien als een Highly Available-systeem zonder single point of failure.

Alles bij elkaar

Dus hoe gebruiken we die componenten in de praktijk? Wat volgt is een voorbeeld van het opzetten van een WordPress-website met Kubernetes. Als je dit echt wilde doen, zou je waarschijnlijk een vooraf gedefinieerd recept gebruiken, een roer-diagram genaamd. Ze zijn beschikbaar voor een aantal veelvoorkomende applicaties, maar hier zullen we enkele van de stappen bekijken die nodig zijn om een WordPress-site op Kubernetes te laten werken.

De eerste taak is om een wachtwoord voor MySQL te definiëren:

 kubectl maak een geheime generieke mysql-pass --from-literal = wachtwoord = UW_WACHTWOORD

kubectl zal praten met de API-server, die de opdracht valideert en vervolgens het wachtwoord opslaat in etcd. Onze services zijn gedefinieerd in YAML-bestanden en nu hebben we wat permanente opslag nodig voor de MySQL-database.

 apiVersion: v1 soort: PersistentVolumeClaim metadata: naam: mysql-pv-claim labels: app: wordpress spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi

De specificatie moet grotendeels voor zichzelf spreken. De naam- en labelvelden worden gebruikt om naar deze opslag te verwijzen vanuit andere delen van Kubernetes, in dit geval onze WordPress-container.

Zodra we de opslag hebben gedefinieerd, kunnen we een MySQL-instantie definiëren, die deze naar de vooraf gedefinieerde opslag verwijst. Dat wordt gevolgd door het definiëren van de database zelf. We geven die database een naam en label zodat ze gemakkelijk kunnen worden geraadpleegd binnen Kubernetes.

Nu hebben we een andere container nodig om WordPress uit te voeren. Een deel van de specificatie van de containerimplementatie is:

 soort: implementatie metadata: naam: wordpress labels: app: wordpress specificatie: strategie: type: recreëren

Het strategietype "Opnieuw maken" betekent dat als een van de code waaruit de toepassing bestaat, de actieve exemplaren worden verwijderd en opnieuw worden gemaakt. Andere opties zijn onder meer de mogelijkheid om nieuwe instances binnen te fietsen en bestaande instances één voor één te verwijderen, zodat de service kan blijven draaien tijdens de implementatie van een update. Ten slotte declareren we een service voor WordPress zelf, bestaande uit de PHP-code en Apache. Een deel van het YAML-bestand waarin dit wordt verklaard, is:

 metadata: naam: wordpress labels: app: wordpress spec: poorten: - poort: 80 selector: app: wordpress tier: frontend type: LoadBalancer

Let op de laatste regel, die het servicetype definieert als LoadBalancer. Dat geeft Kubernetes de opdracht om de service buiten Kubernetes beschikbaar te maken. Zonder die regel zou dit slechts een interne "Kubernetes only" -service zijn. En dat is het. Kubernetes zal nu die YAML-bestanden gebruiken als een verklaring van wat nodig is, en zal zo nodig pods, verbindingen, opslag enzovoort opzetten om het cluster in de "gewenste" staat te krijgen.

Gebruik de dashboardweergave om in één oogopslag een overzicht te krijgen van Kubernetes in actie

Dit was noodzakelijkerwijs slechts een overzicht op hoog niveau van Kubernetes, en veel details en functies van het systeem zijn weggelaten. We hebben autoscaling verdoezeld (beide pods en de knooppunten die een cluster vormen), cron-taken (containers starten volgens een schema), Ingress (HTTP-load balancing, herschrijven en SSL-offloading), RBAC (op rollen gebaseerde toegangscontrole) , netwerkbeleid (firewalling) en nog veel meer. Kubernetes is extreem flexibel en extreem krachtig: voor elke nieuwe IT-infrastructuur moet het een serieuze concurrent zijn.

Middelen

Als u niet bekend bent met Docker, start u hier: https://docs.docker.com/get-started.

Er is hier een interactieve tutorial over het implementeren en schalen van een app: https://kubernetes.io/docs/tutorials/kubernetes-basics.

En zie https://kubernetes.io/docs/setup/scratch voor het bouwen van een cluster.

U kunt spelen met een gratis Kubernetes-cluster op https://tryk8s.com.

Ten slotte kunt u hier een lang technisch artikel doornemen met een uitstekend overzicht van het gebruik van Borg door Google en hoe dat het ontwerp van Kubernetes heeft beïnvloed: https://storage.googleapis.com/pub-tools-public-publication-data/ pdf / 43438.pdf.

Lees meer over Tiger Computing.