Delen via

Overwegingen voor operationsbeheer voor Azure Kubernetes Service

  • Artikel

Kubernetes is een relatief nieuwe technologie die zich snel ontwikkelt met een indrukwekkend ecosysteem. Daarom kan het lastig zijn om het te beheren en te beveiligen.

Basislijn voor bewerkingen voor AKS

U kunt werken aan operationele uitmuntendheid en het succes van klanten door uw Azure Kubernetes Service-oplossing (AKS) goed te ontwerpen met beheer en bewaking in het achterhoofd.

Ontwerpoverwegingen

Houd rekening met de volgende factoren:

  • Houd rekening met AKS-limieten. Gebruik meerdere AKS-exemplaren om deze limieten te overschrijden.
  • Houd rekening met manieren om workloads logisch te isoleren binnen een cluster en fysiek in afzonderlijke clusters.
  • Houd rekening met manieren om het resourceverbruik te beheren door workloads.
  • Houd rekening met manieren om Kubernetes inzicht te geven in de status van uw workloads.
  • Houd rekening met verschillende grootten van virtuele machines en de impact van het gebruik van een of de andere. Grotere VM's kunnen meer belasting verwerken. Kleinere VM's kunnen gemakkelijker worden vervangen door anderen wanneer ze niet beschikbaar zijn voor gepland en ongepland onderhoud. Houd ook rekening met knooppuntgroepen en VM's in een schaalset, zodat virtuele machines van verschillende grootten in hetzelfde cluster zijn toegestaan. Grotere VM's zijn optimaler omdat AKS een kleiner percentage van de resources reserveert, waardoor er meer resources beschikbaar zijn voor uw workloads.
  • Houd rekening met manieren om AKS te bewaken en te registreren. Kubernetes bestaat uit verschillende onderdelen en bewaking en logboekregistratie moet inzicht bieden in de status, trends en potentiële problemen.
  • Op basis van bewaking en logboekregistratie kunnen er veel gebeurtenissen worden gegenereerd door Kubernetes of toepassingen die bovenaan worden uitgevoerd. Waarschuwingen kunnen helpen onderscheid te maken tussen logboekvermeldingen voor historische doeleinden en logboekvermeldingen waarvoor onmiddellijke actie is vereist.
  • Houd rekening met updates en upgrades die u moet doen. Op Kubernetes-niveau zijn er primaire, secundaire en patchversies. De klant moet deze updates toepassen om ondersteund te blijven volgens het beleid in upstream Kubernetes. Op het niveau van de werkrolhost moeten de kernelpatches van het besturingssysteem mogelijk opnieuw worden opgestart, wat de klant moet doen en upgraden naar nieuwe besturingssysteemversies. Naast het handmatig bijwerken van een cluster, kunt u een kanaal voor automatische upgrade instellen op uw cluster.
  • Houd rekening met de resourcebeperkingen en afzonderlijke workloads van het cluster.
  • Houd rekening met de verschillen tussen horizontale automatische schaalaanpassing van pods en automatische schaalaanpassing van clusters
  • Overweeg om verkeer tussen pods te beveiligen met behulp van netwerkbeleid en de invoegtoepassing Azure-beleid
  • Voor hulp bij het oplossen van problemen met uw toepassing en services die worden uitgevoerd op AKS, moet u mogelijk de logboeken bekijken die zijn gegenereerd door onderdelen van het besturingsvlak. Mogelijk wilt u resourcelogboeken inschakelen voor AKS , omdat logboekregistratie niet standaard is ingeschakeld.

Aanbevelingen

  • Inzicht in AKS-limieten:

  • Gebruik logische isolatie op naamruimteniveau om toepassingen, teams, omgevingen en bedrijfseenheden te scheiden. Multitenancy en clusterisolatie. Daarnaast kunnen knooppuntgroepen helpen bij knooppunten met verschillende knooppuntspecificaties en onderhoud, zoals Kubernetes, meerdere knooppuntgroepen upgraden

  • Resourcequota plannen en toepassen op naamruimteniveau. Als pods geen resourceaanvragen en -limieten definiëren, negeert u de implementatie met behulp van beleid, enzovoort. Dit geldt niet voor kube-system pods, omdat niet alle kube-system-pods aanvragen en limieten hebben. Bewaak het resourcegebruik en pas zo nodig quota aan. Basic Scheduler-functies

  • Voeg statustests toe aan uw pods. Zorg ervoor dat pods statustests readinessProbestartupProbe en AKS-statustests bevatten.livenessProbe

  • Gebruik VM-grootten die groot genoeg zijn om meerdere containerinstanties te bevatten, zodat u de voordelen krijgt van een verhoogde dichtheid, maar niet zo groot dat uw cluster de werkbelasting van een mislukt knooppunt niet kan verwerken.

  • Gebruik een bewakingsoplossing. Azure Monitor-containerinzichten is standaard ingesteld en biedt eenvoudige toegang tot veel inzichten. U kunt Prometheus-integratie gebruiken als u dieper wilt inzoomen of ervaring wilt hebben met Prometheus. Als u ook een bewakingstoepassing op AKS wilt uitvoeren, moet u ook Azure Monitor gebruiken om die toepassing te bewaken.

  • Gebruik metrische waarschuwingen voor containerinzichten van Azure Monitor om meldingen te geven wanneer er direct actie moet worden ondernomen.

  • Gebruik de functie voor automatisch schalen van knooppuntgroepen samen met horizontale schaalaanpassing van pods om te voldoen aan de toepassingsvereisten en om piekuren te beperken.

  • Gebruik Azure Advisor om best practice-aanbevelingen te krijgen voor kosten, beveiliging, betrouwbaarheid, operationele uitmuntendheid en prestaties. Gebruik ook Microsoft Defender voor Cloud om bedreigingen zoals beveiligingsproblemen met installatiekopieën te voorkomen en te detecteren.

  • Gebruik Kubernetes met Azure Arc om niet-AKS Kubernetes-clusters in Azure te beheren met behulp van Azure Policy, Defender voor Cloud, GitOps enzovoort.

  • Gebruik podaanvragen en -limieten om de rekenresources binnen een AKS-cluster te beheren. Podaanvragen en -limieten informeren de Kubernetes-planner over welke rekenresources aan een pod moeten worden toegewezen.

Bedrijfscontinuïteit/herstel na noodgevallen om AKS te beveiligen en te herstellen

Uw organisatie moet geschikte mogelijkheden op platformniveau van Azure Kubernetes Service (AKS) ontwerpen om te voldoen aan de specifieke vereisten. Deze toepassingsservices hebben vereisten met betrekking tot RTO (Recovery Time Objective) en RPO (Recovery Point Objective). Er zijn meerdere overwegingen voor herstel na noodgevallen van AKS. De eerste stap is het definiëren van een SLA (Service Level Agreement) voor uw infrastructuur en toepassing. Meer informatie over de SLA voor Azure Kubernetes Service (AKS). Zie de sectie MET SLA-details voor informatie over maandelijkse uptimeberekeningen.

Ontwerpoverwegingen

Houd rekening met de volgende factoren:

  • Het AKS-cluster moet meerdere knooppunten in een knooppuntgroep gebruiken om het minimale beschikbaarheidsniveau voor uw toepassing te bieden.

  • Podaanvragen en -limieten instellen. Als u deze limieten instelt, kan Kubernetes:

    • Geef efficiënt CPU- en geheugenbronnen aan de pods.
    • Hogere containerdichtheid op een knooppunt hebben.

    Limieten kunnen ook de betrouwbaarheid verhogen met lagere kosten vanwege een beter gebruik van hardware.

  • AKS-geschiktheid voor Beschikbaarheidszones of beschikbaarheidssets.

    • Kies een regio die ondersteuning biedt voor Beschikbaarheidszones.
    • Beschikbaarheidszones kan alleen worden ingesteld wanneer de knooppuntgroep wordt gemaakt en later niet meer kan worden gewijzigd. Ondersteuning voor meerdere zone's is alleen van toepassing op knooppuntgroepen.
    • Voor volledig zonegebonden voordeel moeten alle serviceafhankelijkheden ook zones ondersteunen. Als een afhankelijke service geen ondersteuning biedt voor zones, kan een zonefout ertoe leiden dat die service mislukt.
    • Voer meerdere AKS-clusters uit in verschillende gekoppelde regio's voor hogere beschikbaarheid dan wat Beschikbaarheidszones kunnen bereiken. Als een Azure-resource georedundantie ondersteunt, geeft u de locatie op waar de redundante service de secundaire regio heeft.

  • U moet de richtlijnen voor herstel na noodgevallen in AKS kennen. Overweeg vervolgens of ze van toepassing zijn op de AKS-clusters die u gebruikt voor Azure Dev Spaces.

  • Maak consistent back-ups voor toepassingen en gegevens.

    • Een niet-stateful service kan efficiënt worden gerepliceerd.
    • Als u de status in het cluster wilt opslaan, maakt u regelmatig een back-up van de gegevens in de gekoppelde regio. Een overweging is dat het opslaan van de status in het cluster ingewikkeld kan zijn.

  • Clusterupdate en onderhoud.

    • Houd uw cluster altijd up-to-date.
    • Houd rekening met het release- en afschaffingsproces.
    • Plan uw updates en onderhoud.

  • Netwerkverbinding als er een failover optreedt.

    • Kies een verkeersrouter die verkeer over zones of regio's kan verdelen, afhankelijk van uw behoeften. Met deze architectuur wordt Azure Load Balancer geïmplementeerd omdat het niet-webverkeer over zones kan verdelen.
    • Als u verkeer wilt distribueren tussen regio's, kunt u Overwegen Om Azure Front Door te gebruiken.

  • Geplande en niet-geplande failovers.

    • Kies bij het instellen van elke Azure-service functies die ondersteuning bieden voor herstel na noodgevallen. Deze architectuur maakt bijvoorbeeld Azure Container Registry mogelijk voor geo-replicatie. U kunt nog steeds installatiekopieën ophalen uit de gerepliceerde regio als een regio uitvalt.

  • Houd technische DevOps-mogelijkheden bij om doelstellingen op serviceniveau te bereiken.

  • Bepaal of u een SLA met financiële ondersteuning nodig hebt voor uw Kubernetes API-servereindpunt.

Ontwerpaanaanvelingen

Hier volgen de aanbevolen procedures voor uw ontwerp:

  • Gebruik drie knooppunten voor de systeemknooppuntgroep. Voor de gebruikersknooppuntgroep begint u met niet minder dan twee knooppunten. Als u een hogere beschikbaarheid nodig hebt, stelt u meer knooppunten in.

  • Isoleer uw toepassing van de systeemservices door deze in een afzonderlijke knooppuntgroep te plaatsen. Op deze manier worden Kubernetes-services uitgevoerd op toegewezen knooppunten en concurreren ze niet met andere services. Gebruik tags, labels en taints om de knooppuntgroep te identificeren om uw workload te plannen.

  • Regelmatige onderhoud van uw cluster, bijvoorbeeld het maken van tijdige updates, is van cruciaal belang voor betrouwbaarheid. Houd rekening met het ondersteuningsvenster voor Kubernetes-versies op AKS en plan uw updates. Ook wordt het aanbevolen om de status van de pods te bewaken via tests.

  • Verwijder waar mogelijk de servicestatus uit containers. Gebruik in plaats daarvan een Azure Platform as a Service (PaaS) die ondersteuning biedt voor replicatie in meerdere regio's.

  • Zorg ervoor dat podbronnen. Het wordt ten zeerste aanbevolen dat implementaties vereisten voor podresources opgeven. De scheduler kan vervolgens de pod op de juiste manier plannen. Betrouwbaarheid wordt afgeschaft wanneer pods niet worden gepland.

  • Stel meerdere replica's in de implementatie in om onderbrekingen zoals hardwarefouten af te handelen. Voor geplande gebeurtenissen, zoals updates en upgrades, kan een onderbrekingsbudget ervoor zorgen dat het vereiste aantal podreplica's bestaat om de verwachte belasting van de toepassing af te handelen.

  • Uw toepassingen kunnen Azure Storage gebruiken voor hun gegevens. Omdat uw toepassingen zijn verdeeld over meerdere AKS-clusters in verschillende regio's, moet u de opslag gesynchroniseerd houden. Hier volgen twee veelvoorkomende manieren om opslag te repliceren:

    • Asynchrone replicatie op basis van infrastructuur
    • Asynchrone replicatie op basis van toepassingen

  • Limieten voor pods schatten. Test en stel een basislijn in. Begin met gelijke waarden voor aanvragen en limieten. Pas deze waarden geleidelijk aan totdat u een drempelwaarde hebt ingesteld die instabiliteit in het cluster kan veroorzaken. Podlimieten kunnen worden opgegeven in uw implementatiemanifesten.

    De ingebouwde functies bieden een oplossing voor de complexe taak voor het afhandelen van fouten en onderbrekingen in de servicearchitectuur. Deze configuraties helpen zowel ontwerp- als implementatieautomatisering te vereenvoudigen. Wanneer een organisatie een standaard voor de SLA, RTO en RPO heeft gedefinieerd, kan deze ingebouwde services gebruiken voor Kubernetes en Azure om de bedrijfsdoelen te bereiken.

  • Budgetten voor podonderbreking instellen. Met deze instelling wordt gecontroleerd hoeveel replica's in een implementatie u kunt uitschakelen tijdens een update- of upgrade-gebeurtenis.

  • Resourcequota afdwingen voor de servicenaamruimten. Het resourcequotum voor een naamruimte zorgt ervoor dat podaanvragen en -limieten correct zijn ingesteld voor een implementatie.

    • Het instellen van resourcequota op clusterniveau kan problemen veroorzaken bij het implementeren van partnerservices die niet over de juiste aanvragen en limieten beschikken.

  • Sla uw containerinstallatiekopieën op in Azure Container Registry en repliceer het register naar elke AKS-regio.

  • Gebruik de SLA uptime om een sla met financiële ondersteuning mogelijk te maken voor alle clusters die productieworkloads hosten. De SLA voor uptime garandeert een beschikbaarheid van 99,95 procent voor het Kubernetes-API-servereindpunt voor clusters die gebruikmaken van Beschikbaarheidszones en 99,9 procent voor clusters die niet gebruikmaken van Beschikbaarheidszones. Uw knooppunten, knooppuntgroepen en andere resources vallen onder hun SLA. AKS biedt een gratis laag met een serviceniveaudoelstelling (SLO) van 99,5% voor de onderdelen van het besturingsvlak. Clusters waarvoor de SLA uptime is ingeschakeld, mogen niet worden gebruikt voor productieworkloads.

  • Gebruik meerdere regio's en peeringlocaties voor Azure ExpressRoute-connectiviteit .

    Als er een storing optreedt die van invloed is op een Azure-regio of peeringproviderlocatie, kan een redundante hybride netwerkarchitectuur zorgen voor ononderbroken cross-premises connectiviteit.

  • Koppel regio's met wereldwijde peering van virtuele netwerken. Als de clusters met elkaar moeten communiceren, kunnen beide virtuele netwerken met elkaar worden verbonden via peering van virtuele netwerken. Deze technologie verbindt virtuele netwerken met elkaar en biedt hoge bandbreedte in het backbone-netwerk van Microsoft, zelfs in verschillende geografische regio's.

  • Met behulp van gesplitst TCP-anycast-protocol zorgt Azure Front Door ervoor dat uw eindgebruikers onmiddellijk verbinding maken met het dichtstbijzijnde Front Door-aanwezigheidspunt. Andere functies van Azure Front Door zijn:

    • TLS-beëindiging
    • Aangepast domein
    • Web Application Firewall
    • URL opnieuw genereren
    • Sessieaffiniteit

    Bekijk de behoeften van uw toepassingsverkeer om te zien welke oplossing het meest geschikt is.