‫Oke. De laatste paar lezingen ben je
‫begonnen om alle verschillende gebieden van Kubernetes te zien die
‫zich uitbreiden, toch. Als je het
‫een beetje ziet als deze kleine bol in het midden van
‫alleen de binaire bestanden en
‫de basisinfrastructuur van Kubernetes, dan worden de ringen steeds groter,
‫nietwaar. Met
‫Ingress- en Operator-patroon en aangepaste resourcedefinities.
‫Het wordt alleen maar groter.
‫Nu wil ik met je praten over hoe
‫het nog groter wordt. In feite is dit waarschijnlijk het enige gebied waar het
‫een beetje gek is.
‫Dat is op het gebied van meningen over
‫hoe de YAML voor deze bronnen moet worden ingezet, toch.
‫Tot nu toe heb je de kubectl van toepassing zien worden.
‫Nou, dat zal je op weg helpen en dat zal je
‫waarschijnlijk door je eerste implementatie van een container-orchestrator
‫helpen, toch. Je zult... of
‫je nu Swarm of Kubernetes gebruikt, je krijgt die YAML
‫en je hebt een repo en je slaat het daar op,
‫en dat is logisch.
‫Als je dit eenmaal begint uit te breiden, en je
‫hebt teams, en je
‫hebt machtigingen, en verschillende soorten machtigingen, en
‫mensen die dingen moeten besturen of goedkeuren, wordt alles ingewikkelder.
‫Wat is er gebeurd in deze wereld van het
‫implementeren van uw apps op Kubernetes,
‫en dat is eigenlijk waar dit over gaat. We gaan het hebben over het
‫feit dat er nu meer dan 60 zijn, nou ja, er zijn
‫er 80, maar veel van hen zijn niet langer echte projecten of
‫ze zijn dood of gearchiveerd.
‫Maar er zijn minstens 60
‫manieren om tools toe te voegen bovenop Kubernetes,
‫simpelweg voor het implementeren van uw applicaties op Kubernetes.
‫Er zijn veel meningen, toch.
‫Dit is waar de meningen beginnen te komen over hoe
‫je dit zou moeten doen. Alles van Jenkins X tot Helm
‫en verder. Er zijn
‫al deze verschillende dingen en meningen over,
‫nou ja, Kubernetes is geen eigenzinnige infrastructuur, dus we hebben meningen
‫nodig om mensen te begeleiden bij
‫het implementeren en bijwerken van hun apps.
‫Dus iedereen heeft er een. Als je iets hebt
‫gelezen over hoe je dit in Kubernetes doet, heb
‫je vast wel eens van Helm gehoord. Helm naar Kubernetes is
‫in wezen Kubernetes naar containers. Helm is de feitelijke manier
‫waarop iedereen sjablonen
‫wil maken en sjabloonstandaarden wil gebruiken voor het
‫implementeren van apps van derden of het maken
‫van hun eigen aangepaste Helm-diagrammen.
‫Zo heten ze grafieken.
‫Het is in wezen een YAML-sjabloon, maar het stelt Helm in
‫staat om de YAML te maken of
‫uit te spugen die vervolgens voor u in uw
‫Kubernetes-cluster wordt geplaatst. Maar het is niet de enige mening, toch.
‫Ik zei dat er meer dan 60 zijn, de laatste keer dat ik kijk.
‫Er is eigenlijk een Google-spreadsheet die ik in de
‫referentielinks heb geplaatst. Het is een beetje achterhaald, maar het is
‫de laatst bekende lijst van alle plaatsen waar je deze
‫verschillende manieren kunt vinden om te implementeren. Docker zelf heeft zijn eigen mening die
‫erg interessant is, vooral als je nauw in het
‫Docker-ecosysteem wilt zitten. Dat
‫is Compose op Kubernetes.
‫Als je Docker Desktop hebt, kun je
‫vandaag Kubernetes inschakelen, wat je waarschijnlijk al hebt gedaan voor
‫dit deel van de cursus. U kunt docker-stack-implementatie gebruiken en
‫in plaats van dat het naar Swarm gaat, kunt u
‫het naar Kubernetes sturen.
‫Als je de opdracht docker stack deploy bekijkt en de
‫help daarvoor bekijkt, zul je zien dat daar een
‫optie is om de orchestrator op te geven
‫die je wilt gebruiken. In de instellingen
‫van Docker Desktop kun je zelfs aangeven dat het Kubernetes de
‫voorkeur geeft of standaard gebruikt voor de stack-implementatieopdrachten.
‫Dat is best interessant omdat ik dacht dat Compose YAML anders
‫was dan Kubernetes YAML.
‫Welnu, dat is wat Compose op Kubernetes nu doet.
‫Het is in wezen een tool van derden.
‫Het is een eigenzinnige manier, van Docker, om de YAML
‫van Compose, het Compose-formaat, in te zetten, te
‫interpreteren of technisch te vertalen naar het
‫YAML of Kubernetes-formaat.
‫Dus ik heb hier een link voor je geplaatst
‫om dat te gaan bekijken als je iemand bent die Docker
‫Enterprise gaat beschouwen als je enterprise-tooling voor Kubernetes en Swarm
‫en Docker in het algemeen.
‫Dan moet je dit zeker eens bekijken, want dat komt uit
‫de doos. Een van de leuke
‫dingen van die functie is dat de workflow
‫supereenvoudig blijft. Kortom, u gebruikt
‫uw Compose YAML door de hele pijplijn en u kunt deze
‫gebruiken in Ops en Dev. Het dwingt je niet
‫om te zeggen, oké voor ontwikkelaars, je moet YAML hebben
‫voor Compose en voor productie en servers, je moet deze Kubernetes YAML
‫hebben, en ze zijn niet compatibel, toch.
‫Het idee met Docker was dat ze dit te
‫ingewikkeld vonden. Laten we het vereenvoudigen.
‫Laten we gewoon één YAML-standaard gebruiken voor de
‫hele besturingspijplijn.
‫En ik vind het leuk. Het probleem ermee
‫is dat het niet alles ondersteunt wat
‫Kubernetes kan doen, toch. Ik bedoel natuurlijk, we
‫hebben een enkele pagina in de Docker-documenten om alle functies van
‫een Compose-bestand op te sommen. Maar de Kubernetes YAML
‫is zo complex dat we ons moeten verdiepen in
‫meerdere commando's en API-referenties en zo.
‫Het kan dus duidelijk niet alles.
‫Het leuke is op de Compose for Kubernetes-website,
‫ze praten in GitHub over de verschillende functies die
‫het wel ondersteunt.
‫Het is daar de 80/20 regel.
‫Met andere woorden, het ondersteunt de 20 procent van
‫de Kubernetes-functies die 80 procent van ons waarschijnlijk nodig heeft.
‫U kunt daar dus mee aan de slag en kijken of die
‫workflow voor u zou werken. Een ander leuk
‫ding is dat ze eind 2018 de broncode Compose
‫op Kubernetes openen, zodat je het nu kunt implementeren op
‫elke Kubernetes-infrastructuur die je hebt, en het werkt gewoon
‫als een soort tolk. Het vertaalt wanneer u
‫het Compose-bestand van Docker gebruikt en Docker-opdrachten gebruikt, het
‫zal uw Kubernetes-cluster voor u verbinden, dat
‫automatisch vertalen naar Kubernetes YAML en u
‫kunt beginnen. Je kunt
‫op dat moment eigenlijk veel van de Kubernetes YAML
‫voor je applicaties negeren. Weet je, misschien
‫gebruik je Kubernetes YAML voor infrastructuurdingen die je
‫niet elke dag implementeert. Maar misschien voor uw ontwikkelaars
‫om het voor hen gemakkelijker te maken om Compose YAML te schrijven
‫en om dingen sneller in productie te krijgen, kiest u ervoor om
‫Compose op Kubernetes als workflow te gebruiken.
‫Dan gebruikt u misschien Helm-diagrammen, wat
‫een soort concurrerende standaard is voor uw
‫grote infrastructuur. Want het ding
‫met Helm is dat het out-of-the-box wordt geleverd met
‫veel van deze kaartsjablonen, zodat je misschien Prometheus-
‫of Elasticsearch-logboekregistratie met ELK kunt implementeren, of iets dergelijks.
‫Het wordt geleverd met die sjablonen direct uit de doos
‫waarmee u sneller aan de slag kunt.
‫Onthoud ook dat deze allemaal optioneel zijn, toch.
‫Je kunt Kubernetes doen met de standaard YAML waarmee je tot
‫nu toe hebt gespeeld, en dat is prima.
‫Het vereist deze andere dingen niet.
‫Het zijn slechts optionele tools van derden.
‫Traditioneel, als het team groeit, wanneer
‫je meerdere Kubernetes-productieclusters krijgt en er meerdere
‫teams bij betrokken zijn, wordt alles moeilijker
‫en krijg je waarschijnlijk meer dan
‫één oplossing. U kunt op bepaalde clusters Helm krijgen.
‫Je zou kunnen eindigen met Compose op Kubernetes voor je
‫ontwikkelaars, of iets dergelijks.
‫Of een van deze andere 60 plus tools in
‫het ecosysteem.
‫Het laatste punt is dat aangezien Helm momenteel echt de leider
‫is in deze ruimte, bijna
‫elke distributie het gebruikt, of ondersteunt, of er zelfs
‫out-of-the-box mee komt. Bedenk dat wanneer
‫u naar deze tools kijkt, u Helm in een
‫grote omgeving waarschijnlijk niet kunt vermijden.
‫Je zult het gewoon moeten gebruiken.
‫Het leuke is dat het tegenwoordig op 3 staat. 0 en dat er
‫veel eenvoudigere implementatie-opties voor zijn in de
‫3. 0 tegen de 1. 0 en
‫2. 0. Dus de dingen
‫worden daarmee steeds beter en gemakkelijker. Veel van deze implementatietools
‫helpen u eigenlijk alleen maar om uw YAML op verschillende manieren
‫te sjablonen. Kubernetes zelf
‫had al heel lang niets meer.
‫In de recente releases is het nu uitgekomen met
‫iets genaamd Kustomize met een K.
‫Als je dat woord met een K begint te zien, weet je dat
‫het een speciale functie is.
‫Het stelt je in staat om dingen te doen die vergelijkbaar
‫zijn met Helm en deze andere implementatieoplossingen, maar
‫het is niet zo krachtig
‫als Helm, toch.
‫Dus Helm is nog steeds de leider.
‫Kustomize is een soort nieuwe jongen in de buurt, maar het komt uit de
‫doos met alles wat je doet in Kubernetes.
‫Het kubectl-commando ondersteunt dit.
‫Echt wat het is, is dat het
‫gewoon neemt, in plaats van een sjabloon YAML, het neemt gewoon YAML
‫die je al hebt, dat is standaard Kubernetes YAML, en je
‫kunt dan dat bestand nemen en er dan iets anders
‫bovenop uitvoeren en het veranderen met een overschrijving van soorten.
‫Een beetje vergelijkbaar met hoe we het doen in Swarm.
‫We hebben eigenlijk in Swarm en Compose, we hebben
‫override-bestanden en dat soort dingen.
‫Ze hebben dit nu out-of-the-box gebouwd.
‫Het heeft veel functies.
‫Ik denk dat het er min of meer niet helemaal is in termen
‫van de functieset van wat Helm heeft, maar het
‫komt tenminste out-of-the-box.
‫Onthoud dat als je Docker hebt, de
‫nieuwste release, 19. 03 of nieuwer
‫van Docker, heeft nu het subcommando docker-app, dat zijn
‫eigen sjablonen van Compose YAML doet
‫en echt vergelijkbaar is met deze aangepaste optie
‫voor Kubernetes. Nogmaals, als je
‫bij de Docker-track blijft en je gaat Docker Enterprise
‫overwegen of je vindt het gewoon heel leuk hoe Docker zich richt op
‫de ontwikkelaarsworkflow, kijk dan naar de subopdracht van
‫de docker-app en ook naar de repo van de docker-app, die Ik
‫zal de bronnen hier plaatsen.
‫Omdat ze documentatie hebben over hoe je
‫Compose YAML kunt gebruiken, dingen als omgevingsvariabelen en andere
‫dingen kunt extraheren. Verpak het allemaal in een
‫enkele afbeelding en verzend uw YAML vervolgens als een afbeelding.
‫Wat betekent dat je nu je YAML kunt versieren en
‫implementeren met een enkele regel zonder dat je de
‫YAML naar beneden hoeft te halen en vervolgens lange commando's hoeft te typen.
‫Het is een behoorlijk interessante manier om het te doen.
‫Het gebruikt iets nieuws, de CNAB-standaard, waar we hier
‫niet op ingaan, maar dat is C
‫N A B.
‫Het was een aankondiging die Docker en Microsoft in
‫2018 deden.
‫U kunt dat allemaal bekijken op de
‫Docker-app-website in de bronnen. Nogmaals, al deze dingen gaan
‫over optionele manieren van derden om de standaard YAML aan te passen
‫en uit te breiden om het voor je team gemakkelijker te maken
‫terwijl je groeit.