Delen via

Moderne toepassingsplatformclusters beheren

  • Artikel

De Cloud Adoption Framework biedt een kernmethodologie voor het definiëren van operationele beheerprocessen voor de cloud in agnostische zin. De richtlijnen helpen bij het vaststellen van een basislijn voor operationeel beheer en andere gespecialiseerde lagen van bewerkingen. Deze richtlijnen zijn mogelijk nog steeds van toepassing op organisaties met een combinatie van IaaS (Infrastructure as a Service), Platform as a Service (PaaS) en workloads in containers. In dit artikel wordt beschreven wat u moet integreren in uw bestaande bewerkingen om u voor te bereiden op containerbeheer. Ook worden de voordelen van het integreren van Azure Kubernetes Service (AKS) in uw containerbeheerstrategie uitgelicht.

Bedrijfsuitlijning voor operationele beheerbehoeften

Containers verwijderen afhankelijkheden van verschillende lagen van de infrastructuur, wat leidt tot verbeterde mogelijkheden voor operationeel beheer. Als u deze operationele verbeteringen wilt realiseren, moet u mogelijk uw algehele strategie voor cloudbeheer herzien, te beginnen met de bedrijfsafstemming.

Als u de juiste werkwijzen voor operationeel beheer wilt instellen, moet u begrijpen hoe containers worden gebruikt in uw cloudacceptatieplannen en welke voordelen u wilt realiseren van deze verschuiving naar gecontaineriseerde workloads.

  • Beheert u meerdere technologische oplossingen, zoals containers, IaaS en PaaS, in uw cloudplatform?
  • Ondersteunen gecentraliseerde teams bewerkingen en beheer van de container of het AKS-platform? Verschuift deze verantwoordelijkheid naar de afzonderlijke workloadteams?
  • Ondersteunen gecentraliseerde teams bewerkingen en beheer van de workloads die in elke container of pod worden uitgevoerd? Verschuift deze verantwoordelijkheid naar de afzonderlijke workloadteams?
  • Gebruikt u containers voor bedrijfskritieke workloads?
  • Gebruikt u alleen containers voor minder kritieke workloads of werkbelastingen voor nutsvoorzieningen om de kosten te verlagen?
  • Hoe belangrijk zijn de prestaties en betrouwbaarheid van uw afzonderlijke workloads?
  • Zijn de toepassingen in uw containers statusloos? Moet u de status behouden om de workloads in de containers te beveiligen en te herstellen?

Deze basisvragen bepalen hoe u containers en AKS het beste kunt integreren in uw strategie voor operationeel beheer.

Basislijn voor operationele bewerkingen

Het implementeren van een basislijn voor bewerkingen biedt gecentraliseerde toegang tot de hulpprogramma's die nodig zijn voor het uitvoeren en beheren van alle assets in uw cloudomgeving. Als u geen basislijn voor bewerkingen hebt voor uw niet-gecontaineriseerde assets, kunt u de basislijn voor bewerkingen implementeren die zijn gedefinieerd in de methodologie Beheren.

Uw bewerkingsbasislijn moet hulpprogramma's en configuraties bevatten voor zichtbaarheid, bewaking, operationele naleving, optimalisatie en beveiliging/herstel.

Basislijn voor operationeel beheer

De bewerkingsbasislijn die in de bovenstaande artikelen wordt beschreven, biedt geen ondersteuning voor uw containers of AKS-platform. Het biedt echter de basis voor hulpprogramma's die kan worden uitgebreid om containers te ondersteunen, zoals Azure Monitor, Azure Backup en andere hulpprogramma's.

Als het grootste deel van uw portfolio in de cloud wordt gehost in containers, kunt u overwegen om de gespecialiseerde platformbewerkingen in de volgende sectie op te nemen in uw basislijn voor bewerkingen.

Platformbewerkingen

Tenzij deze implementatie de eerste of enige implementatie in de cloud van uw organisatie is, moet u een basislijn voor bewerkingen hebben. In deze sectie worden enkele hulpprogramma's beschreven die u mogelijk wilt opnemen voor het beheren van de container- of AKS-implementatie.

Inventaris en zichtbaarheid

Bewakingscontainers en AKS-clusters maken gebruik van de hulpprogramma's, dashboards en waarschuwingen die zijn opgenomen in de basislijn voor bewerkingen. Mogelijk moet u echter meer configuraties uitvoeren om de gegevens van uw containers over te brengen naar hulpprogramma's voor bewerkingsbewaking, zoals Azure Monitor voor containers. Zie het overzicht van Azure Monitor voor containers voor het verzamelen van de gegevens die nodig zijn om container- en AKS-platformbewerkingen toe te voegen aan uw bewerkingsbasislijn.

Zodra u Azure Monitor hebt geconfigureerd voor het verzamelen van gegevens in uw containers, kunt u de volgende gebieden bewaken als onderdeel van uw gecentraliseerde beheerprocessen:

  • Clusters identificeren die worden uitgevoerd in verschillende regio's, idealiter gekoppeld aan een servicestructuurvermelding en belangrijke feiten voor deze clusters identificeren
    • Clusterknooppuntgroep, netwerken en opslagtopologieën van deze clusters identificeren
    • Stratificatie van AKS-versie en versie van knooppuntinstallatiekopieën identificeren.
  • Resourcegebruik van clusterknooppunten identificeren (proces, geheugen en opslag)
  • Containers identificeren die worden uitgevoerd op de knooppunten en hun bijdrage aan het knooppuntgebruik
  • Inzicht in het gedrag van clusters onder gemiddelde en zwaarste belasting. Deze kennis kan u helpen bij het identificeren van capaciteitsbehoeften en het bepalen van de maximale belasting die het cluster kan dragen.
  • Configureer waarschuwingen om u proactief op de hoogte te stellen of vast te leggen wanneer het CPU- en geheugengebruik op knooppunten of containers uw drempelwaarden overschrijdt, of wanneer er een statuswijziging optreedt in het cluster in het statuspakket van de infrastructuur of knooppunten.
  • Query's gebruiken om een algemene set waarschuwingen, dashboards en gedetailleerde gedetailleerde analyse uit te voeren

Deze gegevens ondersteunen ook teams voor workloadbewerkingen door gedetailleerde informatie te verstrekken over de workloads die worden uitgevoerd op het containerplatform:

  • Controleer het resourcegebruik van workloads die op de host worden uitgevoerd en die niet zijn gerelateerd aan de standaardprocessen die ondersteuning bieden voor de pod.
  • Integreer met Prometheus om metrische gegevens van toepassingen weer te geven.
  • Bewaak containerworkloads die zijn geïmplementeerd in de on-premises AKS-engine en de AKS-engine in Azure Stack.
  • Containerworkloads bewaken die zijn geïmplementeerd in Azure Red Hat OpenShift.
  • Containerworkloads bewaken die zijn geïmplementeerd in Kubernetes met Azure Arc (preview).

Naleving van bewerkingen

Het patchen, afstemmen en aanpassen van de grootte vindt plaats op een paar verschillende niveaus in een containeromgeving. De operators kunnen in een aantal verschillende teams zitten, afhankelijk van uw gewenste operationele benadering. Om de naleving van bewerkingen te handhaven, bewaakt een operator het gebruik, wijzigt het formaat van assets om de prestaties en kosten in balans te houden en patcht de onderliggende systemen om risico's en configuratiedrift te minimaliseren. Centrale IT-organisaties leveren deze taken meestal als onderdeel van de basislijn voor bewerkingen voor IaaS- en PaaS-oplossingen.

In een clusteromgeving in Azure worden deze taken op meerdere niveaus uitgevoerd: AKS-cluster, knooppuntinstallatiekopieën en knooppuntbesturingssystemen. Al deze bewerkingstaken worden meer afhankelijk van een begrip en werkrelatie van de workloads die worden uitgevoerd in de clusters of op afzonderlijke knooppuntgroepen. Met de volgende instructies kunt u evalueren wat en of u wilt doen om uw containeromgevingen te beheren.

  • Als de grootte en patching van het AKS-cluster, de knooppuntinstallatiekopie of het knooppuntbesturingssysteem wordt geleverd als onderdeel van de implementatiepijplijn voor de toepassing of afhankelijk is van de toepassingsarchitectuur of -configuratie, kunt u het beste de operationele naleving verplaatsen naar het workloadteam voor gedetailleerde controle. Omdat werkbelastingen vaak afhankelijk zijn van indelingsfuncties, is dit het meest voorkomende patroon omdat een onverwachte wijziging van de AKS-versie of een wijziging van de knooppuntinstallatiekopie catastrofaal kan zijn voor de workload of de runtime-hulpprogramma's.
  • Voor de minder algemene gecentraliseerde clusters, die een portfolio van workloads en een verscheidenheid aan toepassingen ondersteunen, is het gecentraliseerde operations-team mogelijk nog steeds verantwoordelijk voor operationele nalevingstaken. De volgende handleidingen helpen bij het uitvoeren van deze taken in uw clusters. Het uitvoeren van deze taken op een terugkerende basis zorgt voor platformspecifieke bewerkingen. Er is sprake van een opmerkelijk risico in een benadering van centrale bewerkingen en het zorgvuldig testen van upgrades in preproductieomgevingen, duidelijk en nageleefd gepland onderhoud en noodplannen voor niet-compatibele workloads moeten allemaal aanwezig zijn. Een slechte upgrade kan een Single Point of Failure zijn. Op dezelfde manier kan één workload die niet kan worden bijgewerkt, ertoe leiden dat een cluster niet meer wordt ondersteund. Multitenant-clusters plannen en beheren met zorgvuldigheid.

Volg voor beide clustertypen de onderstaande richtlijnen voor upgrades, knooppuntinstallatiekopieën en updates van knooppuntbesturingssystemen:

Beveiliging en herstel

AKS-knooppunten zijn kortstondig van aard en daarom worden er geen back-ups van gemaakt op een manier die afzonderlijk kan worden hersteld. Het herstellen van een incident kan betekenen dat workloads opnieuw moeten worden geïmplementeerd in een nieuwe knooppuntgroep of een geheel nieuw cluster, afhankelijk van het bereik van het incident.

  • Kies ervoor om een SLA voor uptime toe te voegen aan uw cluster.
  • Voor hogere SLA's kunt u ook best practices voor BCDR voor meerdere regio's overwegen om extra beveiliging te bieden.
  • Aangezien clusters geen status mogen bevatten, wordt extern statusherstel afgehandeld met behulp van bestaande richtlijnen voor bewerkingen. Als u status in uw clusters hebt aangebracht, moet u de best practices voor opslag van operators volgen en een strategie hebben om een back-up van deze gegevens te maken en te herstellen voor een bepaalde workload. Het gebruik van hulpprogramma's zoals Velero is een voorbeeld van platformspecifieke bewerkingen, waarmee uw basislijn voor bewerkingen wordt uitgebreid.
    • Als uw portfolio van toepassingen de status inconsistent toepast, moet het centrale operations-team niet proberen beide oplossingen te onderhouden. Standaardiseer in plaats daarvan de gewenste statushulpprogrammaketen voor alle containers, maar verschuif de verantwoordelijkheid voor alternatieve hersteloplossingen naar teams voor workloadbewerkingen. Deze aanpak biedt ontwerpvrijheid voor de ontwikkelaars, houdt de centrale kosten lager en biedt een kostenreductiestimulanatie voor workloadteams om te voldoen aan de standaard.

Workloadbewerkingen

De bovenstaande sectie platformbewerkingen illustreert een algemeen gesprek bij het beheren van AKS-clusters. Zijn Kubernetes-clusters een technologieplatform dat centraal moet worden beheerd? Of zijn ze een workloadhulpprogramma dat moet worden beheerd door de teams die eigenaar zijn van elk van de workloads? Die vraag verschilt voor verschillende organisaties. De constante die in de meeste organisaties wordt gezien, is dat containers en AKS zijn ontworpen om de workloadteams meer flexibiliteit te bieden in de wijze waarop ze elke workload willen uitvoeren, en om specifieke functies voor die workloads te bieden die in hun architectuur kunnen worden gebruikt om de eigenaren en klanten van de toepassing ten goede te komen.

Workloadbewerkingen kunnen voortbouwen op uw bestaande bewerkingsbasislijn en platformspecifieke bewerkingen. U kunt een AKS-cluster ook veilig beheren met behulp van volledig gedecentraliseerde workloadbewerkingen. In beide gevallen kunt u, wanneer u bewerkingen moet uitbreiden om u te richten op specifieke resultaten voor een specifieke workload, het Azure Well-Architected Framework en Microsoft Azure Well-Architected Review gebruiken om zeer specifiek te zijn over de typen operationele processen en hulpprogramma's die u voor uw workload moet gebruiken.

Volgende stap: Uw volgende migratie-iteratie

Zodra de migratie van het moderne toepassingsplatform is voltooid, kan het cloudacceptatieteam beginnen met uw volgende scenariospecifieke migratie. Als er aanvullende platformen zijn die moeten worden gemigreerd, kan deze reeks artikelen ook opnieuw worden gebruikt om uw volgende moderne toepassingsplatformmigratie of -implementatie te begeleiden.