Richtlijnen voor operations-basislijnen voor Azure Red Hat OpenShift

  • Artikel

Azure Red Hat OpenShift biedt zeer schaalbare, volledig beheerde OpenShift-clusters op aanvraag. Door uw oplossing goed te ontwerpen met het beheer en de bewaking in het achterhoofd, kunt u werken aan operationele uitmuntendheid en klantsucces.

Overwegingen bij het ontwerpen

Houd rekening met de volgende factoren:

  • Bekijk de Azure Red Hat OpenShift-verantwoordelijkheidsmatrix om te begrijpen hoe verantwoordelijkheden voor clusters worden gedeeld tussen Microsoft, Red Hat en klanten.
  • Houd rekening met limieten voor virtuele Azure-machines en ondersteunde regio's. Zorg ervoor dat er capaciteit beschikbaar is om resources te implementeren.
  • Houd rekening met manieren om workloads logisch te isoleren binnen een cluster en fysiek in afzonderlijke clusters.
  • Houd rekening met manieren om Kubernetes inzicht te geven in de status van uw workloads.
  • Houd rekening met de verschillende grootten van virtuele machines en het effect van het gebruik van de ene of de andere.
  • Houd rekening met manieren om Azure Red Hat OpenShift te bewaken en te registreren om inzicht te krijgen in de status van uw resources en om potentiële problemen te voorzien. Zowel het cluster als de toepassingen die bovenaan worden uitgevoerd, kunnen veel gebeurtenissen genereren. Gebruik waarschuwingen om onderscheid te maken tussen logboekvermeldingen voor historische doeleinden en vermeldingen waarvoor onmiddellijke actie is vereist.
  • Houd rekening met belangrijke systeemupdates en -upgrades. Essentiële patchupdates worden automatisch toegepast op clusters door Azure Red Hat OpenShift Site Reliability Engineers (SRE). Klanten die patch-updates vooraf willen installeren, kunnen dit doen.
  • Houd rekening met resourcebeperkingen van het cluster en afzonderlijke workloads.
  • Houd rekening met de verschillen tussen automatische schaalaanpassing van horizontale pods en automatische schaalaanpassing van clusters.
  • Bekijk de ondersteuningslevenscyclus en begrijp het versieondersteuningsbeleid. Azure Red Hat OpenShift ondersteunt alleen de huidige en eerdere algemeen beschikbare secundaire releases van Red Hat OpenShift Container Platform. Voor ondersteuningsaanvragen moet het cluster zich binnen een ondersteunde versie bevinden.
  • Bekijk de vereisten voor clusterconfiguratie om de ondersteuning van clusters te behouden.
  • Controleer netwerken tussen naamruimten om verkeer binnen het cluster te beveiligen met behulp van netwerkbeleid.

Ontwerpaanbeveling

  • Azure Red Hat OpenShift heeft een uitgebreid operatorecosysteem en moet worden gebruikt om operationele activiteiten met efficiëntie en nauwkeurigheid uit te voeren en te automatiseren.
  • Voeg statustests toe aan uw pods om de toepassingsstatus te bewaken. Zorg ervoor dat pods livenessProbe en readinessProbe bevatten. Gebruik Opstarttests om het punt te bepalen waarop de toepassing is gestart.
  • Gebruik virtuele-machinegrootten die groot genoeg zijn om meerdere containerinstanties te bevatten, zodat u de voordelen van een verhoogde dichtheid krijgt, maar niet zo groot dat uw cluster de workload van een mislukkend knooppunt niet kan verwerken.
  • Clusterfuncties reguleren met behulp van toegangsinvoegtoepassingen, die vaak worden gebruikt voor het afdwingen van beveiligingsbeleid, resourcebeperkingen of configuratievereisten.
  • Gebruik podaanvragen en -limieten om de rekenresources binnen een cluster te beheren. Podaanvragen en -limieten informeren de Kubernetes-planner, die rekenresources toewijst aan een pod. Beperk het resourceverbruik in een project met behulp van limietbereiken.
  • Optimaliseer de waarden voor CPU- en geheugenaanvragen en maximaliseer de efficiëntie van de clusterresources met behulp van verticale automatische schaalaanpassing van pods.
  • De OpenShift-webconsole bevat alle metrische gegevens op knooppuntniveau. Stel een bewakingsproces in met behulp van de ingebouwde Prometheus- of Container Insights-integratie.
    • Prometheus is vooraf geïnstalleerd en geconfigureerd voor Azure Red Hat OpenShift 4.x-clusters.
    • Container Insights kan worden ingeschakeld door het cluster te onboarden naar Kubernetes met Azure Arc.
    • OpenShift-logboekregistratie implementeert logboekaggregators, opslag en visualisatieonderdelen.
  • Automatiseer het leveringsproces van toepassingen via DevOps-procedures en CI/CD-oplossingen, zoals pijplijnen/GitOps die worden geleverd door OpenShift Container Platform.
  • Definieer ClusterAutoScaler en MachineAutoScaler om machines te schalen wanneer uw cluster geen resources meer heeft om meer implementaties te ondersteunen.
  • Implementeer statuscontroles van machines om beschadigde machines in een machinegroep automatisch te herstellen.
  • Schaal pods om aan de vraag te voldoen met behulp van horizontale automatische schaalaanpassing van pods.
  • Gebruik een waarschuwingssysteem om meldingen te geven wanneer er directe actie nodig is: Metrische waarschuwingen voor Container Insights of ingebouwde gebruikersinterface voor waarschuwingen.

Bedrijfscontinuïteit en herstel na noodgeval (BCDR)

Uw organisatie moet geschikte Azure Red Hat OpenShift-platformmogelijkheden ontwerpen om te voldoen aan de specifieke vereisten. Deze toepassingsservices hebben vereisten met betrekking tot RTO (Recovery Time Objective) en Recovery Point Objective (RPO). Er zijn meerdere overwegingen die moeten worden aangepakt voor herstel na noodgevallen. 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 Red Hat OpenShift. Zie de sectie SLA-details voor informatie over berekeningen van de maandelijkse uptime.

Ontwerpoverwegingen voor BCDR

Houd rekening met de volgende factoren:

  • Het Azure Red Hat OpenShift-cluster moet meerdere machinesets gebruiken om het minimale beschikbaarheidsniveau voor uw toepassing te bieden.
  • Podaanvragen en -limieten instellen. Als u deze limieten instelt, kan Kubernetes:
    • Wijs efficiënt CPU- en geheugenresources toe aan de pods.
    • Een hogere containerdichtheid hebben op een knooppunt.
    • Verhoog de betrouwbaarheid met lagere kosten door beter gebruik van hardware.
  • Verspreid knooppunten over alle beschikbare zones voor een hogere beschikbaarheid.
    • Kies een regio die ondersteuning biedt voor Beschikbaarheidszones.
    • Voor volledig zonegebonden voordeel moeten alle serviceafhankelijkheden ook zones ondersteunen. Als een afhankelijke service geen ondersteuning biedt voor zones, is het mogelijk dat een zonefout ertoe kan leiden dat die service mislukt. Controleer de schijftypen die worden gebruikt bij het spreiden van de workload over zones.
    • Voor een hogere beschikbaarheid dan wat Beschikbaarheidszones kunt bereiken, voert u meerdere clusters uit in verschillende gekoppelde regio's. Als een Azure-resource ondersteuning biedt voor geo-redundantie, geeft u de locatie op waar de redundante service de secundaire regio heeft.
  • 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.
  • Uw clusters upgraden en onderhouden.
    • Houd uw cluster altijd up-to-date. Controleer op clusterupgrades.
    • Houd rekening met het release- en afschaffingsproces.
    • Beheer upgrades via planningen.
    • Bekijk de noodzaak van een canary-implementatieupdate voor kritieke workloads.
  • Voor netwerkconnectiviteit als er een failover optreedt:
  • Voor geplande en niet-geplande failovers:
    • Kies bij het instellen van elke Azure-service functies die ondersteuning bieden voor herstel na noodgevallen. Als bijvoorbeeld Azure Container Registry is gekozen, schakelt u dit in voor geo-replicatie. Als een regio uitvalt, kunt u nog steeds installatiekopieën ophalen uit de gerepliceerde regio.
  • Technische DevOps-mogelijkheden onderhouden om serviceniveaudoelen te bereiken.

Ontwerpaanbeveling voor BCDR

Hier volgen aanbevolen procedures voor uw ontwerp:

  • Azure Red Hat OpenShift-clusters worden ingericht met drie besturingsvlakknooppunten en drie of meer werkknooppunten. Zorg ervoor dat het cluster is gemaakt in een regio die ondersteuning biedt voor Beschikbaarheidszones, zodat de knooppunten verspreid zijn over de zones.
  • Voor hoge beschikbaarheid implementeert u deze knooppunten naar verschillende Beschikbaarheidszones. Omdat u voor elke beschikbaarheidszone verschillende machinesets nodig hebt, moet u ten minste drie machinesets maken.
  • Voer geen extra workloads uit op de besturingsvlakknooppunten. Hoewel ze kunnen worden gepland op de besturingsvlakknooppunten, veroorzaakt dit extra resourcegebruik en stabiliteitsproblemen die van invloed kunnen zijn op het hele cluster.
  • Maak infrastructuurcomputersets voor infrastructuuronderdelen. Pas specifieke Kubernetes-labels toe op deze machines en werk vervolgens de infrastructuuronderdelen bij zodat deze alleen op deze machines worden uitgevoerd.
  • Verwijder waar mogelijk de servicestatus uit containers. Gebruik in plaats daarvan een Azure PaaS (Platform as a Service) die ondersteuning biedt voor replicatie in meerdere regio's.
  • Implementaties moeten vereisten voor podresources opgeven. De planner kan vervolgens de pod op de juiste manier plannen. Betrouwbaarheid wordt aanzienlijk afgeschreven wanneer pods niet zijn 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 toepassingsbelasting te verwerken.
  • Gebruik podtopologiebeperkingen om pods automatisch te plannen op knooppunten in het hele cluster.
  • Uw toepassingen kunnen gebruikmaken van opslag voor hun gegevens en moeten indien nodig zorgen voor beschikbaarheid in verschillende regio's:
  • Maak een back-up van de toepassing en plan het herstel:
  • Resourcelimieten voor pods schatten. Test en stel een basislijn vast. Begin met gelijke waarden voor aanvragen en limieten. Stem deze waarden vervolgens geleidelijk af totdat u een drempelwaarde hebt ingesteld die instabiliteit in het cluster kan veroorzaken. Podlimieten kunnen worden opgegeven in uw implementatiemanifesten. Verticale automatische schaalaanpassing van pods optimaliseert de CPU- en geheugenaanvraagwaarden en kan de efficiëntie van clusterresources maximaliseren.
    • De ingebouwde functies kunnen fouten en onderbrekingen in de servicearchitectuur afhandelen. Deze configuraties helpen bij het vereenvoudigen van zowel ontwerp- als implementatieautomatisering. Wanneer een organisatie een standaard definieert voor de SLA, RTO en RPO, kan deze gebruikmaken van services die zijn ingebouwd in Kubernetes en Azure om bedrijfsdoelen te bereiken.
  • Overweeg blauw/groen of kanariestrategieën om nieuwe releases van toepassingen te implementeren.
  • Stel podprioriteit/budgetten voor podonderbreking in om het aantal podreplica's te beperken dat het cluster mag verwijderen voor onderhoudsbewerkingen, waardoor de beschikbaarheid wordt gegarandeerd.
  • Resourcequota afdwingen voor 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 geen juiste aanvragen en limieten hebben.
  • Sla uw containerinstallatiekopieën op in Azure Container Registry en repliceer het register geo-repliceren naar elke regio.
  • Gebruik meerdere regio's en peeringlocaties voor Azure ExpressRoute-connectiviteit . Als er een storing optreedt die van invloed is op de locatie van een Azure-regio of peeringprovider, kan een redundante hybride netwerkarchitectuur zorgen voor ononderbroken cross-premises connectiviteit.
  • Regio's met elkaar verbinden 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 om hoge bandbreedte te bieden in het backbone-netwerk van Microsoft, zelfs in verschillende geografische regio's.
  • Gebruik het gesplitste TCP-gebaseerde anycast-protocol , Azure Front Door, om uw eindgebruikers onmiddellijk te verbinden met het dichtstbijzijnde Front Door POP (point of presence). Meer functies van Azure Front Door zijn:
    • TLS-beëindiging
    • Aangepast domein
    • Web Application Firewall
    • URL opnieuw genereren
    • Sessieaffiniteit

Volgende stappen

Meer informatie over ontwerpoverwegingen en aanbevelingen voor platformautomatisering en DevOps in uw Azure-landingszones.