Ein Azure Virtual Network (VNet) ist eine isolierte Netzwerkumgebung in Azure.

Azure VNet bietet vollständige Kontrolle über die Netzwerkkonfiguration, einschließlich:

  • IP-Adressbereiche
  • Subnetze
  • Routing-Tabellen
  • Netzwerk-Gateways

Für SystemLink Enterprise ist ein ordnungsgemäß konfiguriertes VNet für Sicherheit, Skalierbarkeit und Netzwerkisolierung unerlässlich.

Konfigurieren Sie Ihr VNet, um Rechen- und Speicherinfrastruktur in privaten Subnetzen zu isolieren, unabhängig von internetseitigen Gateways und Load Balancern. Diese Konfiguration folgt den bewährten Methoden der Cloud-Sicherheit und stellt sicher, dass sensible Workloads nicht direkt über das Internet zugänglich sind.

Eine allgemeine Beschreibung der Architektur finden Sie im Azure SystemLink Enterprise Kubernetes Architekturdiagramm.

Subnetzarchitektur

Konfigurieren Sie Ihr VNet mit öffentlichen und privaten Subnetzen, um internetorientierte Komponenten von der internen Infrastruktur zu trennen.

Verwenden Sie die folgenden Komponenten in privaten Subnetzen ohne direkten Internetzugang:

  • AKS-Cluster-Knoten: Worker-Knoten, die SystemLink Enterprise-Pods hosten, einschließlich Webdiensten, Webanwendungen und unterstützender Infrastruktur.
  • Datenbanken: Azure Database for PostgreSQL oder selbstverwaltete Datenbankinstanzen.
  • Private Endpunkte für Azure Storage: Konfigurieren Sie private Endpunkte für den Zugriff auf Azure Blob Storage von privaten Subnetzen aus, ohne das öffentliche Internet zu verwenden.

Stellen Sie die folgenden Komponenten in öffentlichen Subnetzen mit Internetzugang bereit:

  • Application Gateway: Load Balancer für HTTPS-Datenverkehr mit der SystemLink Webanwendung und API.
  • Azure Load Balancer: TCP Load Balancer für Salt Master Traffic (Port 4505 und 4506).
  • NAT Gateway: Aktivieren Sie den ausgehenden Internetzugang für Ressourcen in privaten Subnetzen.

Adress-Raumplanung

Planen Sie Ihren VNet-Adressraum, um ausreichende IP-Adressen für SystemLink Enterprise und zukünftiges Wachstum sicherzustellen.

  • Empfohlene VNet-Größe: /16 CIDR-Block (65.536 IP-Adressen) bietet Flexibilität bei der Skalierung
  • Minimale VNet-Größe: /20 CIDR-Block (4.096 IP-Adressen) für kleinere bis mittlere Verteilungen

Zuweisen von Subnetzen basierend auf folgenden Überlegungen:

  • Private Subnetze für AKS-Knoten: Größe basierend auf der maximal erwarteten Knotenanzahl. Jeder AKS-Knoten benötigt eine IP-Adresse aus dem Subnetz-Adressraum.
  • Private Subnetze für Pods: Wenn Sie Azure-CNI-Netzwerke verwenden, weisen Sie zusätzlichen Adressraum für Pod-IP-Adressen zu. Jeder Pod benötigt seine eigene IP-Adresse.
    • Beginnen Sie mit kubenet networking (Standard), wo Pods einen separaten Adressraum verwenden, es sei denn, Sie haben spezifische Anforderungen für die Integration von Pod-Level-Netzwerken.
    • Überwachen Sie die IP-Nutzung sorgfältig mit Azure CNI. Jeder Knoten kann je nach VM-Größe und maximaler Pods pro Knotenkonfiguration 10-100+ IP-Adressen verbrauchen.
    • Plan für Wachstum. Stellen Sie sicher, dass die Subnetzgröße eine erhebliche Skalierung Ihrer Arbeitslast unterstützt.
  • Öffentliche Subnetze: Für Load Balancer und NAT-Gateways ist eine geringere Zuweisung wie /24 ausreichend.
  • Verteilung auf mehrere Zonen: Erstellen Sie Subnetzpaare (öffentlich/privat), die für eine hohe Verfügbarkeit über alle verfügbaren Zonen verteilt sind.
Tabelle 61. Beispiel: Adresszuweisung (VNet mit 10.0.0.0/16)
Subnetztyp Verfügbarkeitsbereich Adressbereich Verfügbare IPs
Privat (AKS-Knoten) Bereich 1 10.0.0.0/19 8.192
Privat (AKS-Knoten) Bereich 2 10.0.32.0/19 8.192
Privat (Datenbanken) Bereich 1 10.0.64.0/24 256
Privat (Datenbanken) Bereich 2 10.0.65.0/24 256
Öffentlich Bereich 1 10.0.128.0/24 256
Öffentlich Bereich 2 10.0.129.0/24 256
Hinweis Azure reserviert die ersten vier Adressen und die letzten IP-Adressen pro Subnetz. Planen Sie bei der Berechnung verfügbarer Adressen entsprechend.

Best Practices für Sicherheit

Beachten Sie beim Konfigurieren Ihres VNet für SystemLink Enterprise die folgenden Sicherheitsrichtlinien:

  • Kein direkter Internetzugang für die Berechnung und Speicherung: Alle AKS-Knoten, Datenbanken und internen Dienste müssen sich in privaten Subnetzen ohne Internet-Gateway-Verbindung befinden.
  • Datenflussisolierung: Internetverkehr fließt über das Internet, das öffentliche Application Gateway/Load Balancer, den privaten Ingress Controller und dann die privaten SystemLink Dienste.
  • Ausgehendes Internet über NAT: Verwenden Sie NAT Gateway in öffentlichen Subnetzen, um ausgehenden Internetzugang für private Subnetzressourcen bereitzustellen. Verwenden Sie NAT Gateway mit Zonenredundanz für hohe Verfügbarkeit.
  • Private Endpunkte: Verwenden Sie private Endpunkte für Azure-Dienste (Blob Storage, Container Registry), um Internetverbindungen zu vermeiden und Datenübertragungskosten zu reduzieren.
  • Netzwerksicherheitsgruppen (NSGs): Konfigurieren Sie NSGs so, dass sie nur den notwendigen Datenverkehr zwischen Komponenten zulassen. Verwenden Sie das Prinzip der kleinsten Berechtigungen.

Hinweise zur Verfügbarkeitszone

Übertragen von SystemLink Enterprise auf mehrere Verfügbarkeitszonen für hohe Verfügbarkeit und Fehlertoleranz:

  • Minimale Verteilung: Verwenden Sie mindestens zwei Verfügbarkeitszonen mit zonenübergreifender Subnetzverteilung.
  • AKS-Knoten-Pools: Verteilen Sie Worker-Knoten mit Hilfe von zonenredundanten Knoten-Pools auf Verfügbarkeitszonen.
  • Datenbankzonenredundanz: Aktivieren Sie zonenredundante Verteilungen für Azure Database for PostgreSQL.
  • Load Balancer-Verteilung: Konfigurieren Sie Application Gateway und Load Balancer mit Zonenredundanz, um den Traffic auf die verfügbaren Zonen zu verteilen.