Wat is Kubernetes?

Inleiding

Kubernetes is een krachtig open-source systeem, oorspronkelijk ontwikkeld door Google en ondersteund door de Cloud Native Computing Foundation (CNCF), voor het beheren van gecontaineriseerde applicaties in een geclusterde omgeving. Het heeft tot doel betere manieren te bieden om gerelateerde, gedistribueerde componenten en services over diverse infrastructuren te beheren. Als u meer wilt weten over Kubernetes, verken dan de onderstaande gids. Als u op zoek bent naar een beheerde Kubernetes-hostingservice, bekijk dan onze eenvoudige, beheerde Kubernetes-service die is ontworpen voor groei.

In deze gids zullen we bespreken wat Kubernetes is, enkele basisconcepten van Kubernetes. We zullen praten over de architectuur van het systeem, de problemen die het oplost, en het model dat het gebruikt om gecontaineriseerde implementaties en schaling te behandelen.

Wat is Kubernetes?

Kubernetes, op zijn basisniveau, is een systeem voor het uitvoeren en coördineren van gecontaineriseerde applicaties over een cluster van machines. Het is een platform dat is ontworpen om volledig het levenscyclusbeheer van gecontaineriseerde applicaties en services te beheren met methoden die voorspelbaarheid, schaalbaarheid en hoge beschikbaarheid bieden.

Als Kubernetes-gebruiker kunt u definiëren hoe uw toepassingen moeten worden uitgevoerd en op welke manieren ze moeten kunnen communiceren met andere toepassingen of de buitenwereld. U kunt uw services opschalen of verkleinen, soepele updates uitvoeren en verkeer tussen verschillende versies van uw toepassingen omleiden om functies te testen of problematische implementaties terug te draaien. Kubernetes biedt interfaces en samenstelbare platformprimitieven waarmee u uw toepassingen met hoge mate van flexibiliteit, kracht en betrouwbaarheid kunt definiëren en beheren.

Kubernetes Architectuur

Om te begrijpen hoe Kubernetes deze mogelijkheden kan bieden, is het nuttig om een beeld te krijgen van hoe het op hoog niveau is ontworpen en georganiseerd. Kubernetes kan worden gevisualiseerd als een systeem dat is opgebouwd uit lagen, waarbij elke hogere laag de complexiteit abstracteert die wordt aangetroffen in de lagere niveaus.

In de basis brengt Kubernetes individuele fysieke of virtuele machines samen in een cluster met behulp van een gedeeld netwerk om te communiceren tussen elke server, opnieuw of het nu gaat om fysieke of virtuele machines. Dit Kubernetes-cluster is het fysieke platform waarop alle Kubernetes-componenten, -mogelijkheden en -workloads zijn geconfigureerd.

De machines in de Kubernetes-cluster krijgen elk een rol binnen het Kubernetes-ecosysteem. Een server (of een kleine groep in zeer beschikbare implementaties) fungeert als de meesterserver. Deze server fungeert als een gateway en brein voor de cluster door een Kubernetes-API bloot te leggen voor gebruikers en klanten, de gezondheid van andere servers te controleren, te beslissen hoe het werk het beste kan worden verdeeld en toegewezen (bekend als “planning”), en de communicatie tussen andere componenten te orchestreren (soms aangeduid als containerorchestratie). De meesterserver fungeert als het primaire contactpunt met de cluster en is verantwoordelijk voor het grootste deel van de gecentraliseerde logica die Kubernetes biedt.

De andere machines in de cluster worden aangewezen als nodes: servers die verantwoordelijk zijn voor het accepteren en uitvoeren van workloads met behulp van lokale en externe middelen. Om te helpen bij isolatie, beheer en flexibiliteit voert Kubernetes toepassingen en services uit in containers, dus elke node moet zijn uitgerust met een container-runtime (zoals Docker of rkt). De node ontvangt werkopdrachten van de meesterserver en maakt of vernietigt containers dienovereenkomstig, waarbij netwerkregels worden aangepast om verkeer op de juiste manier te routeren en door te sturen.

Zoals hierboven vermeld, worden de toepassingen en services zelf uitgevoerd op de cluster binnen containers. De onderliggende componenten zorgen ervoor dat de gewenste toestand van de toepassingen overeenkomt met de werkelijke toestand van de cluster. Gebruikers communiceren met de cluster door rechtstreeks te communiceren met de belangrijkste Kubernetes API-server of met clients en bibliotheken. Om een toepassing of service op te starten, wordt een declaratief plan ingediend in JSON of YAML waarin wordt gedefinieerd wat moet worden gemaakt en hoe het moet worden beheerd. De master server neemt vervolgens het plan en bepaalt hoe het op de infrastructuur moet worden uitgevoerd door de vereisten en de huidige toestand van het systeem te onderzoeken. Deze groep door de gebruiker gedefinieerde toepassingen die worden uitgevoerd volgens een gespecificeerd plan, vertegenwoordigen de uiteindelijke laag van Kubernetes.

Componenten van de Master Server

Zoals hierboven beschreven, fungeert de master server als het primaire controlevlak voor Kubernetes-clusters. Het dient als het belangrijkste contactpunt voor beheerders en gebruikers, en biedt ook veel clusterbrede systemen voor de relatief ongecompliceerde worker nodes. Over het algemeen werken de componenten op de master server samen om gebruikersverzoeken te accepteren, de beste manieren te bepalen om werkbelastingcontainers te plannen, clients en nodes te authenticeren, clusterbrede netwerken aan te passen, en schaal- en gezondheidscontroleverantwoordelijkheden te beheren.

Deze componenten kunnen worden geïnstalleerd op een enkele machine of verdeeld over meerdere servers. We zullen in deze sectie kijken naar elk van de afzonderlijke componenten die geassocieerd zijn met master servers voor Kubernetes-clusters.

etcd

Een van de fundamentele componenten die Kubernetes nodig heeft om te functioneren, is een wereldwijd beschikbare configuratiewinkel. Het etcd project, ontwikkeld door het team van CoreOS (besturingssysteem), is een lichtgewicht, gedistribueerde key-value store die geconfigureerd kan worden om zich uit te strekken over meerdere nodes.

Kubernetes gebruikt etcd om configuratiegegevens op te slaan die toegankelijk zijn voor elk van de nodes in het cluster. Dit kan worden gebruikt voor service-ontdekking en kan componenten helpen zichzelf te configureren of te herconfigureren volgens up-to-date informatie. Het helpt ook bij het behouden van de clusterstatus met functies zoals leiderverkiezing en gedistribueerd slotenbeheer. Door een eenvoudige HTTP/JSON API te bieden, is de interface voor het instellen of ophalen van waarden zeer rechtlijnig.

Net als de meeste andere componenten in het controlepaneel kan etcd geconfigureerd worden op een enkele master-server of, in productiescenario’s, verdeeld worden over een aantal machines. De enige vereiste is dat het netwerk toegankelijk is voor elk van de Kubernetes-machines.

kube-apiserver

Een van de belangrijkste master services is een API-server. Dit is het belangrijkste beheerpunt van het hele cluster omdat het een gebruiker in staat stelt om de workloads en organisatorische eenheden van Kubernetes te configureren. Het is ook verantwoordelijk voor het waarborgen dat de etcd-opslag en de servicedetails van geïmplementeerde containers overeenkomen. Het fungeert als de brug tussen verschillende componenten om de gezondheid van het cluster te handhaven en informatie en opdrachten te verspreiden.

De API-server implementeert een RESTful interface, wat betekent dat veel verschillende tools en bibliotheken er gemakkelijk mee kunnen communiceren. Een client genaamd kubectl is beschikbaar als een standaardmethode om met het Kubernetes-cluster te communiceren vanaf een lokale computer.

kube-controller-manager

De controller-manager is een algemene service met veel verantwoordelijkheden. Primair beheert het verschillende controllers die de staat van het cluster reguleren, workloads levenscycli beheren en routinetaken uitvoeren. Bijvoorbeeld, een replicatiecontroller zorgt ervoor dat het aantal replica’s (identieke kopieën) gedefinieerd voor een pod overeenkomt met het aantal momenteel geïmplementeerd op het cluster. De details van deze bewerkingen worden naar etcd geschreven, waar de controller-manager wijzigingen via de API-server bekijkt.

Wanneer er een verandering wordt waargenomen, leest de controller de nieuwe informatie en voert de procedure uit die voldoet aan de gewenste staat. Dit kan het opschalen of verkleinen van een applicatie inhouden, het aanpassen van eindpunten, enz.

kube-scheduler

Het proces dat daadwerkelijk werkbelastingen toewijst aan specifieke knooppunten in het cluster is de scheduler. Deze service leest de operationele vereisten van een werkbelasting in, analyseert de huidige infrastructuuromgeving en plaatst het werk op een acceptabel knooppunt of knooppunten.

De scheduler is verantwoordelijk voor het bijhouden van de beschikbare capaciteit op elk host om ervoor te zorgen dat werkbelastingen niet worden gepland boven de beschikbare middelen. De scheduler moet de totale capaciteit kennen, evenals de middelen die al zijn toegewezen aan bestaande werkbelastingen op elke server.

cloud-controller-manager

Kubernetes kan worden ingezet in veel verschillende omgevingen en kan communiceren met verschillende infrastructuurproviders om de staat van resources in het cluster te begrijpen en te beheren. Hoewel Kubernetes werkt met generieke voorstellingen van resources zoals koppelbare opslag en load balancers, heeft het een manier nodig om deze te koppelen aan de daadwerkelijke resources die worden geleverd door niet-homogene cloudproviders.

Cloud controller managers fungeren als de lijm die Kubernetes in staat stelt om te interageren met providers met verschillende mogelijkheden, functies en API’s, terwijl ze intern relatief generieke constructies behouden. Dit stelt Kubernetes in staat om zijn statusinformatie bij te werken volgens de informatie die is verzameld van de cloudprovider, cloudresources aan te passen wanneer wijzigingen nodig zijn in het systeem, en aanvullende cloudservices te maken en te gebruiken om te voldoen aan de werkvereisten die naar het cluster zijn verzonden.

Node Server Components

In Kubernetes worden servers die werk uitvoeren door containers uit te voeren, nodes genoemd. Node servers hebben een paar vereisten die noodzakelijk zijn voor communicatie met mastercomponenten, het configureren van container-netwerken en het uitvoeren van de daadwerkelijke workloads die aan hen zijn toegewezen.

A Container Runtime

De eerste component die elke node moet hebben, is een container-runtime. Typisch wordt aan deze vereiste voldaan door het installeren en uitvoeren van Docker, maar alternatieven zoals rkt en runc zijn ook beschikbaar.

De container-runtime is verantwoordelijk voor het starten en beheren van containers, applicaties ingekapseld in een relatief geïsoleerde maar lichtgewicht besturingsomgeving. Elke eenheid van werk op de cluster wordt, op basisniveau, geïmplementeerd als één of meer containers die moeten worden ingezet. De container-runtime op elk knooppunt is het onderdeel dat uiteindelijk de containers uitvoert die gedefinieerd zijn in de workloads die naar de cluster zijn gestuurd.

kubelet

Het belangrijkste contactpunt voor elk knooppunt met de cluster groep is een kleine service genaamd kubelet. Deze service is verantwoordelijk voor het doorgeven van informatie van en naar de controle vlak services, evenals voor de interactie met de etcd opslag om configuratie details te lezen of nieuwe waarden te schrijven.

De kubelet service communiceert met de master componenten om zich te authenticeren bij de cluster en commando’s en werk te ontvangen. Werk wordt ontvangen in de vorm van een manifest die de workload en de operationele parameters definieert. Het kubelet proces neemt vervolgens de verantwoordelijkheid voor het onderhouden van de status van het werk op de node server. Het controleert de container-runtime om containers te starten of te vernietigen indien nodig.

kube-proxy

Om individuele hostsubnetting te beheren en services beschikbaar te maken voor andere componenten, wordt op elke nodeserver een kleine proxyservice genaamd kube-proxy uitgevoerd. Dit proces stuurt verzoeken door naar de juiste containers, kan primitieve load balancing uitvoeren en is over het algemeen verantwoordelijk voor het zorgen dat de netwerkomgeving voorspelbaar en toegankelijk is, maar geïsoleerd waar nodig.

Kubernetes-objecten en Workloads

Hoewel containers het onderliggende mechanisme zijn dat wordt gebruikt om gecontaineriseerde applicaties te implementeren, gebruikt Kubernetes extra abstractielagen over de containerinterface om schaalbaarheid, veerkrachtigheid en levenscyclusbeheerfuncties te bieden. In plaats van containers rechtstreeks te beheren, definiëren en communiceren gebruikers met instanties samengesteld uit verschillende primitieven die worden geleverd door het Kubernetes-objectmodel. We zullen hieronder de verschillende typen objecten bespreken die kunnen worden gebruikt om deze workloads te definiëren.

Pods

A pod is the most basic unit that Kubernetes deals with. Containers themselves are not assigned to hosts. Instead, one or more tightly coupled containers are encapsulated in an object called a pod.

A pod generally represents containers that should be controlled as a single application. Pods consist of containers that operate closely together, share a life cycle, and should always be scheduled on the same node. They are managed entirely as a unit and share their environment, volumes, and IP space. In spite of their containerized implementation, you should generally think of pods as a single, monolithic application to best conceptualize how the cluster will manage the pod’s resources and scheduling.

Gewoonlijk bestaan pods uit een hoofdcontainer die voldoet aan het algemene doel van de workload en optioneel enkele hulpcontainers die nauw verwante taken vergemakkelijken. Dit zijn programma’s die baat hebben bij het draaien en beheren in hun eigen containers, maar nauw verbonden zijn met de hoofdapplicatie. Bijvoorbeeld, een pod kan één container hebben die de primaire toepassingsserver uitvoert en een hulpcontainer die bestanden ophaalt naar het gedeelde bestandssysteem wanneer er wijzigingen worden gedetecteerd in een externe repository. Horizontaal schalen wordt over het algemeen afgeraden op podniveau omdat er andere objecten op een hoger niveau zijn die beter geschikt zijn voor de taak.

Over het algemeen zouden gebruikers pods niet zelf moeten beheren, omdat ze niet enkele van de functies bieden die typisch nodig zijn in applicaties (zoals geavanceerd levenscyclusbeheer en schaalbaarheid). In plaats daarvan worden gebruikers aangemoedigd om te werken met objecten op een hoger niveau die pods of podsjablonen als basisonderdelen gebruiken maar aanvullende functionaliteit implementeren.

Reproductiecontrollers en Reproductiesets

Vaak, bij het werken met Kubernetes, in plaats van het werken met enkele pods, zult u in plaats daarvan groepen identieke, gerepliceerde pods beheren. Deze worden gemaakt van podsjablonen en kunnen horizontaal worden geschaald door controllers die bekend staan als reproductiecontrollers en reproductiesets.

A replication controller is an object that defines a pod template and control parameters to scale identical replicas of a pod horizontally by increasing or decreasing the number of running copies. This is an easy way to distribute load and increase availability natively within Kubernetes. The replication controller knows how to create new pods as needed because a template that closely resembles a pod definition is embedded within the replication controller configuration.

De replicatiecontroller is verantwoordelijk voor het waarborgen dat het aantal pods dat in de cluster is ingezet overeenkomt met het aantal pods in zijn configuratie. Als een pod of onderliggende host uitvalt, zal de controller nieuwe pods starten om te compenseren. Als het aantal replica’s in de configuratie van een controller verandert, start de controller containers op of worden containers beëindigd om het gewenste aantal overeen te laten komen. Replicatiecontrollers kunnen ook rolling updates uitvoeren om een set pods geleidelijk aan naar een nieuwe versie te migreren, waarbij de impact op de beschikbaarheid van de applicatie wordt geminimaliseerd.

Replicatiesets zijn een iteratie op het ontwerp van de replicatiecontroller met meer flexibiliteit in hoe de controller de pods identificeert die hij moet beheren. Replicatiesets beginnen replicatiecontrollers te vervangen vanwege hun grotere mogelijkheden voor het selecteren van replica’s, maar ze kunnen geen rolling updates uitvoeren om back-ends naar een nieuwe versie te schakelen zoals replicatiecontrollers kunnen. In plaats daarvan zijn replicatiesets bedoeld om te worden gebruikt binnen aanvullende, hogere eenheden die die functionaliteit bieden.

Net als pods zijn zowel replicatiecontrollers als replicatiesets zelden de eenheden waarmee je rechtstreeks zult werken. Hoewel ze voortbouwen op het pod-ontwerp om horizontale schaalbaarheid en betrouwbaarheidsgaranties toe te voegen, ontbreken sommige van de gedetailleerde levenscyclusbeheermogelijkheden die te vinden zijn in complexere objecten.

Deployments

Implementaties zijn een van de meest voorkomende workloads om rechtstreeks te maken en te beheren. Implementaties gebruiken replicatiesets als bouwstenen en voegen flexibele levenscyclusbeheerfunctionaliteit toe aan het geheel.

Hoewel implementaties gebouwd met replicatiesets dezelfde functionaliteit lijken te dupliceren die replicatiecontrollers bieden, lossen implementaties veel van de pijnpunten op die bestonden in de uitvoering van rollende updates. Bij het bijwerken van toepassingen met replicatiecontrollers moeten gebruikers een plan indienen voor een nieuwe replicatiecontroller die de huidige controller zou vervangen. Bij het gebruik van replicatiecontrollers zijn taken zoals het bijhouden van geschiedenis, herstellen van netwerkstoringen tijdens de update en terugdraaien van slechte wijzigingen moeilijk of blijven de verantwoordelijkheid van de gebruiker.

Implementaties zijn een object op hoog niveau dat is ontworpen om het levenscyclusbeheer van gerepliceerde pods te vergemakkelijken. Implementaties kunnen eenvoudig worden aangepast door de configuratie te wijzigen en Kubernetes zal de replicatiesets aanpassen, overgangen tussen verschillende applicatieversies beheren en indien gewenst automatisch gebeurtenisgeschiedenis en terugdraaimogelijkheden behouden. Vanwege deze functies zullen implementaties waarschijnlijk het type Kubernetes-object zijn waarmee u het meest frequent werkt.

StatefulSets

Stateful sets zijn gespecialiseerde pod-controllers die ordenings- en uniekheidsgaranties bieden. Ze worden voornamelijk gebruikt om meer gedetailleerde controle te hebben wanneer je speciale vereisten hebt met betrekking tot implementatievolgorde, persistent gegevens, of stabiel netwerken. Bijvoorbeeld, stateful sets worden vaak geassocieerd met gegevensgerichte toepassingen, zoals databases, die toegang nodig hebben tot dezelfde volumes, zelfs als ze opnieuw worden ingepland naar een nieuwe node.

Stateful sets bieden een stabiele netwerkidentificator door voor elke pod een unieke, op nummers gebaseerde naam te creëren die behouden blijft, zelfs als de pod naar een andere node moet worden verplaatst. Op dezelfde manier kunnen persistente opslagvolumes worden overgedragen met een pod wanneer herplanning nodig is. De volumes blijven behouden, zelfs nadat de pod is verwijderd om onbedoeld gegevensverlies te voorkomen.

Bij het implementeren of aanpassen van de schaal voeren stateful sets bewerkingen uit volgens de genummerde identificator in hun naam. Dit biedt meer voorspelbaarheid en controle over de uitvoeringsvolgorde, wat in sommige gevallen nuttig kan zijn.

Daemon Sets

Daemon sets zijn een andere gespecialiseerde vorm van pod-controller die een kopie van een pod uitvoeren op elke node in de cluster (of een subset, indien gespecificeerd). Dit is meestal handig bij het implementeren van pods die helpen bij onderhoudswerkzaamheden en diensten bieden voor de Kubernetes-nodes zelf.

Bijvoorbeeld, het verzamelen en doorsturen van logs, het aggregeren van metingen, en het draaien van services die de mogelijkheden van de node zelf vergroten, zijn populaire kandidaten voor daemon sets. Omdat daemon sets vaak fundamentele services leveren en nodig zijn in de hele vloot, kunnen ze podplanningbeperkingen omzeilen die voorkomen dat andere controllers pods toewijzen aan bepaalde hosts. Als voorbeeld, vanwege zijn unieke verantwoordelijkheden, wordt de master server vaak geconfigureerd om niet beschikbaar te zijn voor normale podplanning, maar daemon sets hebben de mogelijkheid om de beperking op podniveau te negeren om ervoor te zorgen dat essentiële services worden uitgevoerd.

Opdrachten en Cron-opdrachten

De workloads die we tot nu toe hebben beschreven, zijn allemaal uitgegaan van een langdurige, serviceachtige levenscyclus. Kubernetes gebruikt een workload genaamd opdrachten om een meer op taken gebaseerde workflow te bieden waarbij de draaiende containers worden verwacht succesvol af te sluiten nadat ze hun werk hebben voltooid. Opdrachten zijn handig als u eenmalige of batchverwerking moet uitvoeren in plaats van een continue service te draaien.

Het bouwen op banen zijn cron banen. Net als de conventionele cron daemons op Linux en Unix-achtige systemen die scripts uitvoeren op een schema, bieden cron banen in Kubernetes een interface om banen met een planningscomponent uit te voeren. Cron banen kunnen worden gebruikt om een taak in de toekomst uit te voeren of op regelmatige, terugkerende basis. Kubernetes cron banen zijn in feite een herimplementatie van het klassieke cron-gedrag, waarbij het cluster als platform wordt gebruikt in plaats van een enkel besturingssysteem.

Andere Kubernetes Componenten

Naast de workloads die je kunt uitvoeren op een cluster, biedt Kubernetes een aantal andere abstracties die je helpen bij het beheren van je applicaties, het controleren van netwerken en het mogelijk maken van persistentie. We zullen hier een paar van de meer gebruikelijke voorbeelden bespreken.

Kubernetes Services

Tot nu toe hebben we de term “service” gebruikt in de conventionele, Unix-achtige zin: om langlopende processen aan te duiden, vaak netwerkverbonden, in staat om te reageren op verzoeken. In Kubernetes is een service echter een component die fungeert als een basisinterne load balancer en ambassadeur voor pods. Een service groepeert logische verzamelingen van pods die dezelfde functie uitvoeren om ze als één entiteit weer te geven.

Dit stelt u in staat om een dienst uit te rollen die alle backend-containers van een bepaald type kan bijhouden en routeren. Interne gebruikers hoeven alleen maar op de stabiele eindpunt te vertrouwen die door de dienst wordt geleverd. Ondertussen stelt de abstractie van de dienst u in staat om de backend-werkunits uit te schalen of te vervangen indien nodig. Het IP-adres van een dienst blijft stabiel ongeacht wijzigingen in de pods waarnaar het routes. Door een dienst uit te rollen, verkrijgt u eenvoudig vindbaarheid en kunt u uw containerontwerpen vereenvoudigen.

Telkens wanneer u toegang moet bieden tot een of meer pods aan een andere toepassing of aan externe gebruikers, moet u een dienst configureren. Bijvoorbeeld, als u een set pods heeft die webservers draaien die toegankelijk moeten zijn vanaf het internet, zal een dienst de nodige abstractie bieden. Op dezelfde manier, als uw webservers gegevens moeten opslaan en ophalen, wilt u een interne dienst configureren om ze toegang te geven tot uw databasepods.

Hoewel diensten standaard alleen beschikbaar zijn met behulp van een intern routeerbaar IP-adres, kunnen ze beschikbaar worden gesteld buiten het cluster door een van verschillende strategieën te kiezen. De NodePort-configuratie werkt door een statische poort te openen op de externe netwerkinterface van elke node. Verkeer naar de externe poort wordt automatisch gerouteerd naar de juiste pods met behulp van een interne cluster-IP-dienst.

Als alternatief creëert het service type LoadBalancer een externe load balancer om naar de dienst te routeren met behulp van de Kubernetes load balancer-integratie van een cloudprovider. De cloud controller manager zal het juiste bronmateriaal creëren en configureren met behulp van de interne serviceadressen van de dienst.

Volumes en Persistente Volumes

Het betrouwbaar delen van gegevens en het garanderen van de beschikbaarheid ervan tussen het opnieuw opstarten van containers is een uitdaging in veel gecontaineriseerde omgevingen. Container runtimes bieden vaak een mechanisme om opslag aan een container te koppelen die aanhoudt na de levensduur van de container, maar implementaties ontbreken meestal aan flexibiliteit.

Om dit aan te pakken, gebruikt Kubernetes zijn eigen abstractie van volumes die het delen van gegevens mogelijk maakt voor alle containers binnen een pod en beschikbaar blijft totdat de pod wordt beëindigd. Dit betekent dat sterk gekoppelde pods gemakkelijk bestanden kunnen delen zonder complexe externe mechanismen. Containerstoringen binnen de pod hebben geen invloed op de toegang tot de gedeelde bestanden. Zodra de pod is beëindigd, wordt het gedeelde volume vernietigd, dus het is geen goede oplossing voor echt persistente gegevens.

Persistente volumes zijn een mechanisme voor het abstraheren van robuustere opslag die niet gekoppeld is aan de levenscyclus van de pod. In plaats daarvan stellen ze beheerders in staat opslagbronnen voor het cluster te configureren die gebruikers kunnen aanvragen en claimen voor de pods die ze uitvoeren. Zodra een pod klaar is met een persistent volume, bepaalt het beleid voor het terugvorderen van het volume of het volume wordt behouden totdat het handmatig wordt verwijderd of direct met de gegevens wordt verwijderd. Persistente gegevens kunnen worden gebruikt om te beschermen tegen storingen op knooppuntniveau en om grotere hoeveelheden opslag toe te wijzen dan lokaal beschikbaar is.

Labels en annotaties

A Kubernetes organizational abstraction related to, but outside of the other concepts, is labeling. A label in Kubernetes is a semantic tag that can be attached to Kubernetes objects to mark them as a part of a group. These can then be selected for when targeting different instances for management or routing. For instance, each of the controller-based objects use labels to identify the pods that they should operate on. Services use labels to understand the backend pods they should route requests to.

Labels worden gegeven als eenvoudige sleutel-waardeparen. Elk element kan meer dan één label hebben, maar elk element kan slechts één invoer hebben voor elke sleutel. Gewoonlijk wordt een “naam” sleutel gebruikt als een algemene identificator, maar u kunt objecten ook classificeren op basis van andere criteria zoals ontwikkelingsfase, openbare toegankelijkheid, toepassingsversie, enzovoort.

Annotations zijn een vergelijkbaar mechanisme waarmee u willekeurige sleutel-waarde-informatie aan een object kunt koppelen. Terwijl labels moeten worden gebruikt voor semantische informatie die nuttig is om een pod te koppelen aan selectiecriteria, zijn annotaties meer vrij van vorm en kunnen ze minder gestructureerde gegevens bevatten. Over het algemeen zijn annotaties een manier om rijke metadata toe te voegen aan een object die niet nuttig is voor selectiedoeleinden.

Conclusie