Hoe Kubernetes-implementaties werken
De app voor het traceren van drones heeft verschillende onderdelen die afzonderlijk van elkaar worden geïmplementeerd. Het is uw taak om implementaties voor deze onderdelen te configureren op het cluster. Hier bekijkt u enkele van de implementatieopties die voor u beschikbaar zijn om deze onderdelen te implementeren.
Pod-implementatieopties
Er zijn verschillende opties voor het beheren van de implementatie van pods in een Kubernetes-cluster wanneer u kubectl gebruikt. De opties zijn:
- Podsjablonen
- Replicatiecontrollers
- Replicasets
- Installaties
U kunt een van deze vier Kubernetes-objecttypedefinities gebruiken om een pod of pods te implementeren. Deze bestanden maken gebruik van YAML om de beoogde status van de pods of pods te beschrijven die moeten worden geïmplementeerd.
Wat is een pod-sjabloon?
Met een podsjabloon kunt u de configuratie definiëren van de pod die u wilt implementeren. De sjabloon bevat informatie zoals de naam van de containerinstallatiekopieën en welk containerregister moet worden gebruikt om de installatiekopieën op te halen. De sjabloon bevat ook runtimeconfiguratiegegevens, zoals poorten die moeten worden gebruikt. Sjablonen worden gedefinieerd met behulp van YAML. Dit werkt op dezelfde manier als wanneer u Docker-bestanden maakt.
U kunt sjablonen gebruiken om pods handmatig te implementeren. Een handmatig geïmplementeerde pod wordt echter niet opnieuw gestart nadat deze is mislukt, wordt verwijderd of wordt beëindigd. Als u de levenscyclus van een pod wilt beheren, moet u een Kubernetes-object op een hoger niveau maken.
Wat is een replicatiecontroller?
Een replicatiecontroller maakt gebruik van podsjablonen en definieert een opgegeven aantal pods dat moet worden uitgevoerd. De controller zorgt ervoor dat u meerdere instanties van dezelfde pod kunt uitvoeren en dat pods altijd worden uitgevoerd op een of meer knooppunten in het cluster. De controller vervangt actieve pods op deze manier door nieuwe pods als ze mislukken, worden verwijderd of worden beëindigd.
Stel dat u de front-endwebsite voor dronetracking implementeert en dat gebruikers toegang krijgen tot de website. Als alle pods om welke reden dan ook mislukken, is de website niet beschikbaar voor uw gebruikers tenzij u nieuwe pods start. Een replicatiecontroller helpt u ervoor te zorgen dat uw website altijd beschikbaar is.
Wat is een replicaset?
Replicasets vervangen de replicatiecontroller als de voorkeursmethode voor het implementeren van replica's. Een replicaset bevat dezelfde functionaliteit als een replicatiecontroller, maar heeft een extra configuratieoptie om een selectorwaarde op te nemen.
Met een selector kan de replicaset alle pods waarnemen die hieronder worden uitgevoerd. Met deze functie kunt u pods beheren die zijn gelabeld met dezelfde waarde als de selectorwaarde, maar die niet zijn gemaakt met de gerepliceerde set.
Wat is een implementatie?
Met een implementatie maakt u een beheerobject op één niveau hoger dan een replicaset en kunt u updates voor pods in een cluster implementeren en beheren.
Stel dat er vijf instanties van uw app zijn geïmplementeerd in uw cluster. Er zijn vijf pods waarop versie 1.0.0 van uw app wordt uitgevoerd.
Als u besluit uw app handmatig bij te werken, kunt u alle pods verwijderen en vervolgens nieuwe pods starten met versie 2.0.0 van uw app. Met deze strategie ondervindt uw app downtime.
In plaats daarvan wilt u een rolling update uitvoeren waarbij u pods start met de nieuwe versie van uw app voordat u de pods met de oudere app-versie verwijdert. Rolling updates starten één pod tegelijk in plaats van alle oudere pods tegelijk te verwijderen. Implementaties respecteren het aantal replica's dat is geconfigureerd in de sectie die informatie over replicasets bevat. Het onderhoudt het aantal pods dat is opgegeven in de replicaset, omdat deze oude pods vervangt door nieuwe pods.
Implementaties bieden standaard een strategie voor doorlopende updates voor het bijwerken van pods. U kunt ook een strategie gebruiken om opnieuw pods te maken. Deze strategie beëindigt pods voordat nieuwe pods worden gestart.
Implementaties bieden u ook een terugdraaistrategie, die u kunt uitvoeren met behulp van kubectl.
Implementaties maken gebruik van op YAML gebaseerde definitiebestanden en maken het eenvoudig om implementaties te beheren. Onthoud dat u met implementaties allerlei wijzigingen kunt toepassen op uw cluster. U kunt bijvoorbeeld nieuwe versies van een app implementeren, labels bijwerken en andere replica's van uw pods uitvoeren.
kubectl bevat handige syntaxis om automatisch een implementatie te maken wanneer u de opdracht kubectl run gebruikt om een pod te implementeren. Met deze opdracht maakt u een implementatie met de vereiste replicaset en pods. U maakt met de opdracht echter geen definitiebestand. Het is een best practice om alle implementaties met implementatiedefinitiebestanden te beheren en wijzigingen bij te houden met behulp van een versiebeheersysteem.
Implementatieoverwegingen
Kubernetes heeft specifieke vereisten over de manier waarop u netwerken en opslag voor een cluster configureert. Hoe u deze twee aspecten configureert, is van invloed op uw beslissingen over de wijze waarop u uw apps in het clusternetwerk beschikbaar maakt en gegevens opslaat.
Elk van de services in de app voor het traceren van drones heeft bijvoorbeeld specifieke vereisten voor gebruikerstoegang, netwerktoegang tussen processen en gegevensopslag. Laten we nu eens kijken naar deze Kubernetes-clusteraspecten en hoe ze van invloed zijn op de implementatie van apps.
Kubernetes-netwerken
Stel dat u een cluster met één besturingsvlak en twee knooppunten hebt. Wanneer u knooppunten toevoegt aan Kubernetes, wordt er vanaf een intern privénetwerkbereik automatisch een IP-adres toegewezen aan elk knooppunt. Stel dat uw lokale netwerkbereik 192.168.1.0/24 is.
Voor elke pod die u implementeert, wordt een IP-adres uit een groep met IP-adressen toegewezen. Stel dat uw configuratie gebruikmaakt van het netwerkbereik 10.32.0.0/12, zoals in de volgende afbeelding wordt weergegeven.
De pods en knooppunten kunnen standaard niet met elkaar communiceren wanneer verschillende IP-adresbereiken worden gebruikt.
Wat het nog lastiger maakt, is dat pods tijdelijk zijn. Het IP-adres van de pod is tijdelijk en kan niet worden gebruikt om opnieuw verbinding te maken met een onlangs gemaakte pod. Deze configuratie is van invloed op de manier waarop uw app communiceert met de interne onderdelen en hoe u en services er extern mee communiceren.
Om de communicatie te vereenvoudigen, verwacht Kubernetes dat u netwerken zodanig configureert dat:
- Pods met elkaar kunnen communiceren tussen knooppunten zonder Network Address Translation (NAT).
- Knooppunten kunnen communiceren met alle pods en andersom zonder NAT.
- Agents op een knooppunt kunnen communiceren met alle knooppunten en pods.
Kubernetes biedt verschillende netwerkopties die u kunt installeren om netwerken te configureren. Voorbeelden hiervan zijn Antrea, Cisco Application Centric Infrastructure (ACI), Cilium, Flannel, Kubenet, VMware NSX-T en Weave Net.
Cloudproviders bieden ook hun eigen netwerkoplossingen. Azure Kubernetes Service (AKS) ondersteunt bijvoorbeeld de Azure Virtual Network Container Network Interface (CNI), Kubenet, Flannel, Cilium en Antrea.
Kubernetes-services
Een Kubernetes-service is een Kubernetes-object dat stabiele netwerkmogelijkheden biedt voor pods. Een Kubernetes-service maakt communicatie mogelijk tussen knooppunten, pods en gebruikers van uw app (zowel intern als extern) naar het cluster.
Kubernetes wijst bij het maken een IP-adres toe aan een service op dezelfde manier als een knooppunt of pod. Deze adressen worden toegewezen vanuit het IP-bereik van een servicecluster; bijvoorbeeld 10.96.0.0/12. Aan een service wordt ook een DNS-naam toegewezen op basis van de servicenaam, en een IP-poort.
In de app voor het traceren van drones is netwerkcommunicatie als volgt:
De website en RESTful API zijn toegankelijk voor gebruikers buiten het cluster.
De service voor de geheugencache en de service voor de berichtenwachtrij zijn toegankelijk voor respectievelijk de front-end en de RESTful-API, maar niet voor externe gebruikers.
De berichtenwachtrij heeft toegang nodig tot de gegevensverwerkingsservice, maar niet tot externe gebruikers.
De NoSQL-database is toegankelijk voor de cache in het geheugen en de gegevensverwerkingsservice, maar niet voor externe gebruikers.
Ter ondersteuning van deze scenario's kunt u drie typen services configureren om de onderdelen van uw app zichtbaar te maken.
| Service | Beschrijving |
|---|---|
| ClusterIP | Het adres dat is toegewezen aan een service waardoor de service beschikbaar is voor een set services in het cluster. Bijvoorbeeld communicatie tussen de front- en back-endonderdelen van uw app. |
| NodePort | De knooppuntpoort tussen 30000 en 32767 die het Kubernetes-besturingsvlak aan de service toewijst; Bijvoorbeeld 192.169.1.11 op clusters01. Vervolgens configureert u de service met een doelpoort in de pod die u beschikbaar wilt maken. Configureer bijvoorbeeld poort 80 in de pod die wordt uitgevoerd op een van de front-ends. U hebt nu toegang tot de front-end via een knooppunt-IP en poortadres. |
| LoadBalancer | De load balancer waarmee de belasting kan worden verdeeld tussen knooppunten waarop uw app wordt uitgevoerd en de pod beschikbaar kan worden gemaakt voor toegang tot openbare netwerken. Doorgaans configureert u load balancers wanneer u cloudproviders gebruikt. In dit geval wordt verkeer van de externe load balancer omgeleid naar de pods waarop uw app wordt uitgevoerd. |
In de app voor het traceren van drones kunt u besluiten om de traceringswebsite en de RESTful-API beschikbaar te maken met behulp van een LoadBalancer en de gegevensverwerkingsservice met behulp van een ClusterIP.
Pods groeperen
Pods beheren op IP-adres is niet praktisch. IP-adressen van pods veranderen wanneer controllers deze opnieuw maken. Bovendien hebt u misschien een groot aantal pods die worden uitgevoerd.
Met een serviceobject kunt u zich richten op specifieke pods in uw cluster en deze beheren door gebruik te maken van selectorlabels. U stelt het selectorlabel in een servicedefinitie zo in dat dit overeenkomt met het podlabel dat is gedefinieerd in het definitiebestand van de pod.
Stel dat u veel pods hebt die worden uitgevoerd. Er bevinden zich slechts een paar van deze pods aan het front-end en u wilt een LoadBalancer-service instellen die alleen gericht is op de front-endpods. U kunt uw service toepassen om deze pods beschikbaar te maken door te verwijzen naar het podlabel als een selectorwaarde in het definitiebestand van de service. De service groepeert alleen de pods die overeenkomen met het label. Als een pod wordt verwijderd en opnieuw wordt gemaakt, wordt de nieuwe pod automatisch aan de servicegroep toegevoegd door middel van het overeenkomende label.
Kubernetes-opslag
Kubernetes maakt gebruik van hetzelfde opslagvolumeconcept als Docker. Docker-volumes worden minder beheerd dan de Kubernetes-volumes, omdat de levensduur van Docker-volumes niet wordt beheerd. De levensduur van het Kubernetes-volume is een expliciete levensduur die overeenkomt met de levensduur van de pod. Deze levensduurovereenkomst betekent dat een volume langer meegaat dan de containers die worden uitgevoerd in de pod. Maar als de pod wordt verwijderd, wordt het volume ook verwijderd.
Kubernetes biedt opties voor het inrichten van permanente opslag met het gebruik van PersistentVolumes. U kunt ook specifieke opslag aanvragen voor pods met behulp van PersistentVolumeClaims.
Houd rekening met beide opties bij het implementeren van app-onderdelen waarvoor persistente opslag vereist is, zoals bij berichtenwachtrijen en databases.
Overwegingen bij cloudintegratie
Kubernetes bepaalt niet de technologiestack die u gebruikt in uw cloud-app. In een cloudomgeving, zoals Azure, kunt u verschillende services buiten het Kubernetes-cluster gebruiken.
Denk nog eens terug aan eerdere informatie dat Kubernetes geen van de volgende services biedt:
- Middleware
- Frameworks voor gegevensverwerking
- Databases
- Caches
- Clusteropslagsystemen
In deze oplossing voor het traceren van drones zijn er drie services die middlewarefunctionaliteit bieden: een NoSQL-database, een cacheservice in het geheugen en een berichtenwachtrij. U kunt MongoDB Atlas selecteren voor de NoSQL-oplossing, Redis voor het beheren van cache in het geheugen en RabbitMQ of Kafka, afhankelijk van de behoeften van uw berichtenwachtrij.
Wanneer u een cloudomgeving als Azure gebruikt, wordt het aanbevolen om services te gebruiken buiten het Kubernetes-cluster. Deze beslissing kan de configuratie en het beheer van het cluster vereenvoudigen. U kunt bijvoorbeeld Azure Cache voor Redis gebruiken voor de cacheservices in het geheugen, Azure Service Bus-berichten voor de berichtenwachtrij en Azure Cosmos DB voor de NoSQL-data base.