‫Er zijn twee stukjes metadata in deze YAML die
‫je waarschijnlijk hebt gezien in de voorbeelden en
‫waarover je hebt nagedacht, terwijl je je afvraagt waar labels en annotaties
‫echt voor zijn.
‫Je besefte waarschijnlijk niet hun betekenis.
‫Ze zijn een belangrijk onderdeel van Kubernetes en hoe dingen
‫met elkaar verbonden zijn.
‫Veel meer dan Swarm.
‫De eerste is etiketten. Labels staan onder de
‫metadatasleutel in de hoofdmap van het bestand, dus ze
‫zijn daar optioneel. U hoeft ze niet te
‫plaatsen, maar ze zijn een sleutelwaarde, of een lijst met sleutelwaarden, onder de
‫kop van de labels.
‫Die zijn er om meerdere redenen.
‫Ze zijn niet altijd nodig, maar u kunt ze
‫later nodig hebben om de objecten te selecteren,
‫te groeperen en zelfs te filteren.
‫Dit kan alles zijn dat het object
‫of de resource beschrijft.
‫Het kan een sleutelwaardepaar zijn waarvan de waarde gewoon waar
‫of onwaar is.
‫De sleutels kunnen zijn wat je maar wilt.
‫Er kan gewoon niet meer dan één sleutel in elk object
‫zijn, dus je kunt niet twee sleutels achter elkaar in
‫de YAML hebben voor hetzelfde object met de sleutelnaam
‫van, laten we zeggen app, juist. Deze worden echt gebruikt om het
‫object te beschrijven. Deze resources die
‫we maken, hebben verschillende eigenschappen.
‫Misschien is het de omgeving zoals prod, dev of test.
‫Misschien is het de locatie zoals dmz,
‫of backend of frontend. Misschien is het de naam van de
‫app, of misschien is het de naam van de klant, als je sites van
‫klanten host of zoiets. Het kan gewoon zijn wat
‫je wilt en er zijn niet heel veel normen.
‫De Kubernetes-documentatie die in de bronnen hier wordt vermeld, geeft
‫u enkele voorbeelden, maar dat zijn slechts voorbeelden.
‫Er zijn niet veel normen in de industrie.
‫Het is echt aan je team en je bedrijf
‫hoe je dit ding wilt omschrijven.
‫We hebben ook aantekeningen. Ze zijn een soort yin en yang.
‫De etiketten zijn heel eenvoudig.
‫Ze zijn zeer beperkt in grootte en welke tekens
‫je erin kunt zetten. Ze zijn bedoeld om de bron te beschrijven.
‫Met annotaties is dit voor complexere gegevens en gegevens
‫met meerdere waarden, dat soort dingen.
‫Meestal zie je annotaties die worden gebruikt wanneer je
‫aangepaste dingen toevoegt aan Kubernetes die met Kubernetes kunnen
‫praten en er gegevens uit kunnen halen.
‫De annotaties zijn er om configuratiegegevens
‫op te slaan, zoals proxy's en ingress-dingen kunnen
‫vaak verschillende configuraties opslaan, binnen verschillende annotaties.
‫Die zijn er dus niet per
‫se om te beschrijven, maar meer om te configureren.
‫Laten we even teruggaan naar labels, want er is veel
‫meer dat essentieel is om te begrijpen hoe al deze dingen
‫werken in Kubernetes.
‫Het eerste is dat we eenvoudige filters kunnen doen door ons
‫te beperken tot de labels vanaf de opdrachtregel.
‫We kunnen pods halen en zeggen, laat me alleen de
‫pods zien met dit label.
‫U kunt daar zelfs een komma gebruiken om meerdere labels toe te voegen.
‫In feite is er een heel syntaxisniveau voor dit ding
‫waar je verschillende soorten syntaxis kunt gebruiken, verschillende of's
‫en en's.
‫Echt, het is een van die dingen waar
‫ik je dat niet allemaal wil leren, omdat het zal zijn
‫als het leren van Regex. Het is iets waar je het niet echt
‫leert door het een keer te proberen.
‫Pas als je het nodig hebt, ga je
‫het echt begrijpen. De documentatie van Kubernetes
‫is echt geweldig. Ze hebben meerdere links die
‫ik in de bronnen heb geplaatst die je door het pad leiden van alle
‫verschillende manieren waarop je misschien labels nodig hebt.
‫Eerlijk gezegd hoef je dat pas echt te leren als je weet dat
‫je het nodig hebt om een probleem op te lossen.
‫Je kunt het zelfs gebruiken voor het toepassen van opdrachten.
‫Als je een heleboel dingen in één groot YAML-bestand had
‫en je wilde alleen bepaalde delen van
‫dat YAML-bestand toepassen.
‫Ik doe dit niet vaak, maar het is daar
‫waar je het zou kunnen beperken om te zeggen, pas de wijzigingen
‫of informatie toe die je in de YAML hebt aangebracht
‫voor specifieke labels.
‫Natuurlijk kun je bij deze weer
‫dezelfde syntaxis gebruiken. U kunt slechts één label hebben.
‫U kunt komma's plaatsen, meerdere labels en waarden
‫daar hebben. Het is aan jou.
‫Er is nog iets dat de labels doen dat belangrijk
‫is voor hoe Kubernetes werkt.
‫Het komt erop neer dat er bepaalde bronnen zijn die
‫met andere bronnen praten, er verbinding mee maken
‫of ermee verband houden.
‫Hoe je het ook wilt zeggen. Het goede voorbeeld
‫is dat de services moeten weten naar welke pods
‫ze hun verkeer moeten sturen. Je vraagt je misschien af hoe het weet?
‫Ik bedoel, als je het intypt, als je een Kubectl-serviceopdracht uitvoert
‫en je verwijst het naar de implementatie, wat
‫gebruikt het dan precies om die implementatie te identificeren?
‫Welnu, in de CLI zou je denken dat het eigenlijk
‫naar het implementatieobject verwijst.
‫Maar echt, de service moet met de pods praten, niet met
‫de implementatie zelf.
‫Het gebruikt iets dat labelselectors wordt genoemd.
‫Dit is gebruikelijk bij veel van de verschillende bronnen
‫met hogere abstractieniveaus van pods.
‫Om ervoor te zorgen dat ze zich kunnen verhouden tot de pods, of om te weten
‫welke pods van hen zijn, gebruiken ze labelkiezers. Je zult dat zien
‫in de YAML in onze repo die je de
‫afgelopen paar lezingen hebt gebruikt.
‫Als je in de app kijkt. yml, je zult merken dat we al
‫die tijd een paar dingen hebben gehad waar we
‫het niet over hebben gehad. De eerste staat
‫bovenaan bij de service, we hebben onder de specificatie een selector.
‫Dat moet er zijn.
‫We vertellen het de sleutel en waarde van een label
‫voor pods waarnaar het verkeer moet leiden.
‫Dat is gewoon een simpele match.
‫Daar moet het pods mee vinden.
‫Vervolgens zie je in de implementatie eronder
‫dat onze specificatie zijn eigen selector
‫heeft, matchLabels, app, app-nginx.
‫Wat daar gebeurt, is dat beide objecten pods
‫selecteren op basis van die overeenkomst.
‫Dat betekent dat in de sjabloon onder
‫onze specificatie, waar we de pods uittekenen, dat label
‫erin moet staan, zodat die bronnen hun pods
‫kunnen vinden.
‫Het leuke van de latere versies van Kubernetes
‫is dat deze in ieder geval met slechts een enkele
‫implementatie synchroon moeten zijn. Het zal eigenlijk niet
‫worden geïmplementeerd als het ziet dat de selector-overeenkomstlabels niet overeenkomen
‫met de sjabloonmetadatalabels, omdat ze dat moeten doen om
‫de pods zelfs te implementeren en ze
‫te kunnen besturen.
‫Het is er om te voorkomen dat je het per ongeluk op
‫de verkeerde manier doet. Het zal verwachten dat
‫je die stukken daar hebt. In oudere versies was er een
‫manier waarop het ze standaard automatisch zou genereren, dus je
‫kon het spul weglaten. Ze zijn daar nu mee gestopt en
‫ze dwingen je om dit erin te zetten. Ik denk dat
‫dat een goede zaak is, vooral hoe
‫belangrijk deze labelkiezers zijn. Technisch gezien, als je teruggaat
‫naar Swarm, doet Swarm een beetje van dit out-of-the-box waar
‫het labels heeft die dingen matchen van stapels tot services,
‫en stapels met hun volumes, en dat soort dingen.
‫We krijgen het niet echt onder controle en we zien het niet
‫veel in de interface. Het is een beetje op
‫de achtergrond gedaan voor ons in Swarm.
‫Maar het is ook erg beperkend.
‫Je kunt dingen niet zomaar veranderen.
‫Je kunt die niet per se gaan aanpassen voor
‫echt unieke opstellingen.
‫Hier kunnen we mogelijk een servicegesprek voeren met
‫meerdere implementaties als we die
‫selectors willen wijzigen.
‫Bij selectors gaat het niet alleen om het aan elkaar koppelen van bronnen.
‫Het gaat er ook om te controleren waar ze heen gaan.
‫Op de knooppunten kunt u labels en selectors gebruiken om te bepalen
‫waar ze naartoe gaan.
‫Je kunt nog meer maatwerk gebruiken met dingen die taints en tolerantie
‫worden genoemd, die een soort van het omgekeerde zijn
‫van dat waarbij je knooppunten vertelt dat ze bepaalde dingen niet kunnen
‫doen, zodat Kubernetes weet waar ze in principe kunnen
‫bepalen waar je pods naartoe gaan.
‫Deze dingen worden echt op maat gemaakt en
‫gaan behoorlijk snel vooruit. Als je ze allemaal samen doet,
‫kan het een beetje harig en gek worden.
‫Ik raad je zeker aan om het rustig aan te doen met hen.
‫Houd het allemaal eenvoudig out-of-the-box.
‫Vermijd smet en toleranties totdat je er echt
‫naar moet kijken.
‫Oke. Laten we opruimen voor deze hele sectie.
‫Als er iets draait in een standaardnaamruimte voor je cluster,
‫als je gewoon een kubectl-get all doet, en je
‫ziet daar dingen buiten de Kubernetes-API zelf, ga je
‫gang en verwijder al die bronnen, want we gaan verder
‫. Die zullen we niet nodig hebben.