Grundlegende Anleitungen für Vorgänge für Azure Red Hat OpenShift

Azure Red Hat OpenShift bietet hoch skalierbare, vollständig verwaltete OpenShift-Cluster bei Bedarf. Indem Sie Ihre Lösung ordnungsgemäß mit Management und Überwachung entwerfen, können Sie auf operative Exzellenz und Kundenerfolg hinarbeiten.

Entwurfsüberlegungen

Berücksichtigen Sie die folgenden Faktoren:

• Überprüfen Sie die Azure Red Hat OpenShift-Verantwortungsmatrix , um zu verstehen, wie die Verantwortlichkeiten für Cluster zwischen Microsoft, Red Hat und Kunden geteilt werden.
• Beachten Sie die Grenzwerte und unterstützten Regionen des virtuellen Azure-Computers. Stellen Sie sicher, dass kapazität verfügbar ist, um Ressourcen bereitzustellen.
• Beachten Sie, wie Workloads logisch innerhalb eines Clusters und physisch in separaten Clustern isoliert werden können.
• Seien Sie sich bewusst, wie Kubernetes die Gesundheit Ihrer Workloads erfassen kann.
• Achten Sie auf verschiedene virtuelle Computergrößen und die Auswirkungen der Verwendung eines oder des anderen.
• Achten Sie darauf, wie Sie Azure Red Hat OpenShift überwachen und protokollieren können, um Einblicke in die Integrität Ihrer Ressourcen zu erhalten und potenzielle Probleme zu erkennen. Sowohl der Cluster als auch die oben ausgeführten Anwendungen können viele Ereignisse generieren. Verwenden Sie Warnungen, um zwischen Protokolleinträgen für historische Zwecke und Einträge zu unterscheiden, die sofortige Maßnahmen erfordern.
• Beachten Sie wichtige Systemupdates und -upgrades. Kritische Patchupdates werden automatisch von Azure Red Hat OpenShift Site Reliability Engineers (SRE) auf Cluster angewendet. Kunden, die Patch-Updates im Voraus installieren möchten, können dies tun.
• Beachten Sie die Ressourcenbeschränkungen des Clusters und einzelner Workloads.
• Beachten Sie die Unterschiede zwischen horizontaler Pod-Autoskalierung und Clusterautoskalierung.
• Überprüfen Sie den Supportlebenszyklus , und verstehen Sie die Versionssupportrichtlinie. Azure Red Hat OpenShift unterstützt nur die aktuellen und vorherigen allgemein verfügbaren Nebenversionen der Red Hat OpenShift Container Platform. Supportanfragen erfordern, dass sich der Cluster in einer unterstützten Version befindet.
• Überprüfen Sie die Clusterkonfigurationsanforderungen , um die Unterstützung des Clusters zu gewährleisten.
• Überprüfen Sie namespaceübergreifendes Netzwerk, um den Datenverkehr innerhalb des Clusters mithilfe von Netzwerkrichtlinien zu sichern.

Designempfehlungen

• Azure Red Hat OpenShift verfügt über ein umfangreiches Operator-Ökosystem und sollte verwendet werden, um operative Aktivitäten mit Effizienz und Genauigkeit auszuführen und zu automatisieren.
• Fügen Sie Ihren Pods Integritätssonden hinzu, um den Anwendungsstatus zu überwachen. Stellen Sie sicher, dass Pods livenessProbe und readinessProbe enthalten. Verwenden Sie Startsonden, um den Punkt zu bestimmen, an dem die Anwendung gestartet wurde.
• Verwenden Sie virtuelle Computergrößen, die groß genug sind, um mehrere Containerinstanzen zu enthalten, sodass Sie die Vorteile einer erhöhten Dichte, aber nicht so groß erhalten, dass Ihr Cluster die Arbeitsauslastung eines fehlerhaften Knotens nicht verarbeiten kann.
• Regeln Sie Clusterfunktionen mithilfe von Einlass-Plug-Ins, die häufig zum Erzwingen von Sicherheitsrichtlinien, Ressourcenbeschränkungen oder Konfigurationsanforderungen verwendet werden.
• Verwenden Sie Pod-Anforderungen und -Grenzwerte, um die Computeressourcen in einem Cluster zu verwalten. Pod-Anforderungen und -Grenzwerte informieren den Kubernetes-Scheduler, der Computeressourcen einem Pod zuweist. Einschränken des Ressourcenverbrauchs in einem Projekt mithilfe von Grenzwerten.
• Optimieren Sie die CPU- und Arbeitsspeicheranforderungswerte, und maximieren Sie die Effizienz der Clusterressourcen mithilfe der vertikalen Pod-Autoskalierung.
• Die OpenShift-Webkonsole enthält alle Metriken auf Knotenebene. Richten Sie einen Überwachungsprozess mithilfe der integrierten Prometheus- oder Container Insights-Integration ein.
  • Prometheus ist vorinstalliert und für Azure Red Hat OpenShift 4.x-Cluster konfiguriert.
  • Containereinblicke können durch Onboarding des Clusters in Azure Arc-fähige Kubernetes aktiviert werden.
  • Die OpenShift-Protokollierung stellt Protokollaggregatoren, Speicher und Visualisierungskomponenten bereit.
• Automatisieren Sie den Anwendungsübermittlungsprozess über DevOps-Praktiken und CI/CD-Lösungen, z. B. Pipelines/GitOps, die von openShift Container Platform bereitgestellt werden.
• Definieren Sie die Ressourcendefinitionen ClusterAutoscaler und MachineAutoscaler, um zu beschreiben, wie Sie Ihren Cluster anpassen können, wenn er Ressourcen knapp werden, damit Sie den Betrieb fortsetzen können. ClusterAutoscaler berücksichtigt Ressourcen aller Knoten im Cluster, einschließlich Steuerebenenknoten. Wenn Sie die Steuerebenenknoten des Clusters skalieren, verringern Sie die verbleibende Kapazität für autoskalierende Arbeitsknoten.
• Führen Sie Maschinenzustandsprüfungen durch, um beschädigte Maschinen in einem Maschinenpool automatisch zu reparieren.
• Skalieren Sie Pods so, dass sie den Bedarf mithilfe der horizontalen Pod-Autoskalierung erfüllen.
• Verwenden Sie ein Benachrichtigungssystem, um Benachrichtigungen bereitzustellen, wenn direkte Aktionen erforderlich sind: Metrikwarnungen für Containereinblicke oder integrierte Benutzeroberfläche für Warnungen.

Business Continuity & Disaster Recovery (BCDR)

Ihre Organisation muss geeignete Azure Red Hat OpenShift-Funktionen auf Plattformebene entwerfen, um ihre spezifischen Anforderungen zu erfüllen. Diese Anwendungsdienste haben Anforderungen im Zusammenhang mit dem Ziel der Wiederherstellungszeit (Recovery Time Objective, RTO) und dem Ziel des Wiederherstellungspunkts (Recovery Point Objective, RPO). Es gibt mehrere Überlegungen zur Bewältigung von Katastrophenfällen. Der erste Schritt besteht darin, eine Sla (Service Level Agreement) für Ihre Infrastruktur und Anwendung zu definieren. Erfahren Sie mehr über das SLA für Azure Red Hat OpenShift. Informationen zu monatlichen Uptime-Berechnungen finden Sie im SLA-Detailabschnitt .

Entwurfsüberlegungen für BCDR

Berücksichtigen Sie die folgenden Faktoren:

• Der Azure Red Hat OpenShift-Cluster sollte mehrere Computersätze verwenden, um die mindestverfügbarkeit für Ihre Anwendung bereitzustellen.
• Festlegen von Pod-Anforderungen und -Grenzwerten. Das Festlegen dieser Grenzwerte ermöglicht Kubernetes:
  • Weisen Sie den Pods CPU- und Arbeitsspeicherressourcen effizient zu.
  • Höhere Containerdichte auf einem Knoten erzielen.
  • Erhöhen Sie die Zuverlässigkeit mit reduzierten Kosten aufgrund einer besseren Verwendung von Hardware.
• Verteilen Sie Knoten über alle verfügbaren Zonen, um eine höhere Verfügbarkeit zu erzielen.
  • Wählen Sie eine Region aus, die Verfügbarkeitszonen unterstützt.
  • Um den vollständigen Vorteil der Verwendung mehrerer Zonen zu erreichen, müssen alle Dienstabhängigkeiten auch Zonen unterstützen. Wenn ein abhängiger Dienst keine Zonen unterstützt, kann ein Zonenfehler dazu führen, dass dieser Dienst fehlschlägt. Überprüfen Sie die Datenträgertypen, die beim Verteilen der Workload über Zonen hinweg verwendet werden.
  • Um eine höhere Verfügbarkeit zu erreichen, als es Verfügbarkeitszonen ermöglichen, betreiben Sie mehrere Cluster in verschiedenen gekoppelten Regionen. Wenn eine Azure-Ressource Georedundanz unterstützt, stellen Sie den Standort bereit, an dem der redundante Dienst seine sekundäre Region hat.
• Erstellen Sie konsequent Sicherungen für Anwendungen und Daten.
  • Ein nicht zustandsbehafteter Dienst kann effizient repliziert werden.
  • Wenn Sie den Zustand im Cluster speichern müssen, sichern Sie die Daten häufig in der gekoppelten Region.
• Aktualisieren und verwalten Sie Ihre Cluster.
  • Halten Sie Ihren Cluster immer auf dem neuesten Stand. Suchen Sie nach Cluster-Upgrades.
  • Beachten Sie den Release- und Abkündigungsprozess.
  • Steuern von Upgrades durch Zeitpläne.
  • Überprüfen Sie die Notwendigkeit eines Canary-Rollout-Updates für kritische Workloads.
• Für netzwerkkonnektivität, wenn ein Failover auftritt:
  • Wenn Sie Datenverkehr über Regionen verteilen müssen, sollten Sie Azure Front Door verwenden.
• Für geplante und ungeplante Failovers:
  • Wenn Sie jeden Azure-Dienst einrichten, wählen Sie Features aus, die die Notfallwiederherstellung unterstützen. Wenn z. B. die Azure-Containerregistrierung ausgewählt wird, aktivieren Sie sie für die Georeplikation. Wenn eine Region ausfällt, können Sie weiterhin Bilder aus der replizierten Region beziehen.
• Verwalten Sie DevOps-Kompetenzen im Ingenieurwesen, um Service-Level-Ziele zu erreichen.

Entwurfsempfehlungen für BCDR

Im Folgenden sind bewährte Methoden für Ihr Design aufgeführt:

• Azure Red Hat OpenShift-Cluster werden mit drei Steuerebenenknoten und drei oder mehr Arbeitsknoten bereitgestellt. Stellen Sie sicher, dass der Cluster in einer Region erstellt wird, die Verfügbarkeitszonen unterstützt, damit die Knoten über die Zonen verteilt werden.
• Stellen Sie diese Knoten für hohe Verfügbarkeit in verschiedenen Verfügbarkeitszonen bereit. Da Sie für jede Verfügbarkeitszone unterschiedliche Computersätze benötigen, erstellen Sie mindestens drei Computersätze.
• Führen Sie keine zusätzlichen Workloads auf den Knoten der Steuerebene aus. Während sie auf den Knoten der Steuerungsebene geplant werden können, verursacht dies zusätzliche Ressourcennutzungs- und Stabilitätsprobleme, die sich auf den gesamten Cluster auswirken können.
• Erstellen Sie Infrastrukturcomputersätze, die Infrastrukturkomponenten enthalten sollen. Wenden Sie bestimmte Kubernetes-Bezeichnungen auf diese Computer an, und aktualisieren Sie dann die Infrastrukturkomponenten so, dass sie nur auf diesen Computern ausgeführt werden.
• Entfernen Sie nach Möglichkeit immer den Service-Status aus den Containern. Verwenden Sie stattdessen eine Azure-Plattform als Dienst (PaaS), die die Multiregion-Replikation unterstützt.
• Bereitstellungen sollten die Anforderungen an Pod-Ressourcen angeben. Der Planer kann den Pod dann ordnungsgemäß planen. Die Zuverlässigkeit verringert sich erheblich, wenn Pods nicht zugewiesen werden.
• Richten Sie mehrere Replikas im Deployment ein, um Unterbrechungen wie Hardwarefehler zu bewältigen. Bei geplanten Ereignissen wie Updates und Upgrades kann ein Unterbrechungsbudget sicherstellen, dass die erforderliche Anzahl von Pod-Replikaten vorhanden ist, um die erwartete Anwendungslast zu bewältigen.
• Verwenden Sie Podtopologieeinschränkungen, um Pods auf Knoten im gesamten Cluster automatisch anzusetzen.
• Ihre Anwendungen verwenden möglicherweise Speicher für ihre Daten und sollten bei Bedarf die Verfügbarkeit in allen Regionen sicherstellen:
  • Verwenden des RWX-Speichers mit der integrierten Azure Files-Speicherklasse.
  • Verwenden von CSI-Treibern für die Speicherbereitstellung.
• Erstellen Sie anwendungssicherung und planen Sie die Wiederherstellung:
  • Schließen Sie persistente Volumes in die Sicherung ein.
• Schätzen sie die Grenzwerte für pod-Ressourcen. Testen und Einrichten eines Basisplans Beginnen Sie mit gleichen Werten für Anforderungen und Grenzwerte. Optimieren Sie diese Werte dann schrittweise, bis Sie einen Schwellenwert festgelegt haben, der zu Instabilität im Cluster führen kann. Pod-Grenzwerte können in Ihren Bereitstellungsmanifesten angegeben werden. Vertikale Pod-Autoskalierung optimiert die CPU- und Speicheranforderungswerte und kann die Effizienz von Clusterressourcen maximieren.
  • Die integrierten Features können Fehler und Unterbrechungen in der Dienstarchitektur behandeln. Diese Konfigurationen helfen dabei, die Entwurfs- und Bereitstellungsautomatisierung zu vereinfachen. Wenn eine Organisation einen Standard für SLA, RTO und RPO definiert, kann sie in Kubernetes und Azure integrierte Dienste verwenden, um Geschäftsziele zu erreichen.
• Ziehen Sie blau/grün oder Canary-Strategien in Betracht, um neue Versionen von Anwendungen bereitzustellen.
• Legen Sie Pod-Prioritäten und Pod-Unterbrechungsbudgets fest, um die Anzahl der Pod-Replikate zu begrenzen, die der Cluster für Wartungsvorgänge abbauen darf, und so die Verfügbarkeit sicherzustellen.
• Erzwingen Sie Ressourcenkontingente für Dienstnamespaces. Das Ressourcenkontingent für einen Namespace stellt sicher, dass Podanforderungen und Grenzwerte für eine Bereitstellung ordnungsgemäß festgelegt sind.
  • Das Festlegen von Ressourcenkontingenten auf Clusterebene kann Beim Bereitstellen von Partnerdiensten, die keine ordnungsgemäßen Anforderungen und Grenzwerte aufweisen, Probleme verursachen.
• Speichern Sie Ihre Containerimages in der Azure-Containerregistrierung und geo-replizieren Sie die Registrierung in jede geografische Region.
• Verwenden Sie mehrere Regionen und Peeringstandorte für die Azure ExpressRoute-Konnektivität . Wenn sich ein Ausfall auf den Standort einer Azure-Region oder eines Peeringanbieters auswirkt, kann eine redundante Hybridnetzwerkarchitektur dazu beitragen, eine unterbrechungsfreie standortübergreifende Konnektivität sicherzustellen.
• Verbinden Sie Regionen mit globalem virtuellen Netzwerkpeering. Wenn die Cluster miteinander kommunizieren müssen, können beide virtuellen Netzwerke miteinander verbunden werden, indem virtuelle Netzwerk-Peerings hergestellt werden. Diese Technologie verbindet virtuelle Netzwerke miteinander, um eine hohe Bandbreite über das Backbone-Netzwerk von Microsoft hinweg zu ermöglichen, auch über verschiedene geografische Regionen hinweg.
• Verwenden Sie das geteilte TCP-basierte Anycast-Protokoll , Azure Front Door, um Ihre Endbenutzer umgehend mit dem nächstgelegenen Front Door POP (Point of Presence) zu verbinden. Zu den weiteren Features von Azure Front Door gehören:
  • TLS-Terminierung
  • Benutzerdefinierte Domäne
  • Firewall für Webanwendungen
  • URL rewrite
  • Sitzungsaffinität

Nächste Schritte

Erfahren Sie mehr über Entwurfsaspekte und Empfehlungen für die Plattformautomatisierung und DevOps in Ihren Azure-Zielzonen.