Einheit 2.3: Lastverteilung und Sicherheit als Code

Einführung

Ihr TaskBoard-Netzwerkstack aus Einheit 2.2 besteht aus drei Ebenen, die miteinander verbunden sind: einem öffentlichen Load Balancer, einem Anwendungs-Load Balancer und einem Datenbank-Load Balancer. Die Dedicated Server sind über den Anwendungs-Load Balancer erreichbar, aber noch nicht geschützt, und es gibt noch keine Filterung des Datenverkehrs, der ihre Netzwerk-Schnittstellen (NICs) erreicht. In dieser Einheit konfigurieren Sie den Rand.

Sie werden einen Load Balancer vor die Dedicated Server stellen, der Anfragen über pfadbasierte Routing auf die Anwendungsserver verteilt. Sie werden sehen, wann ein Network Load Balancer das richtige Werkzeug ist, und Sie werden jede Ebene mit Network Security Group-Regeln absichern. Die wichtige IONOS-spezifische Lektion hier ist, wo die Sicherheit tatsächlich bindet: NSGs werden auf der Server-NIC-Ebene angewendet, nie auf der Load Balancer- und nie auf den Knoten-Ebene. Wenn Sie das falsch machen, werden Sie Stunden damit verbringen, sich zu fragen, warum Ihre Firewall-Regeln keinen Effekt auf den Datenverkehr haben, der durch den Application Load Balancer (ALB) ankommt. Alles in dieser Einheit ist Code: die Ansible-Ressourcen und die rohen Cloud-Dedicated Server-Aufrufe darunter.

1. Anwendung Load Balancer als Code

Die ionoscloud_application_loadbalancer-Ressource bereitstellt eine Layer-7-Load Balancer, die HTTP und HTTPS beendet und über anwendungsspezifische Attribute routet. Der ALB sitzt zwischen einem Listener-LAN, wo Clients ihn erreichen, und einem Ziel-LAN, wo Ihre Backends leben. Für die TaskBoard-API ist der Listener-LAN die öffentliche LAN und das Ziel-LAN ist die App-LAN.

Ein ALB wird aus drei Ressourcentypen aufgebaut: dem Load Balancer selbst, einer oder mehreren Zielgruppen, die Backend-Ziele registrieren, und Weiterleitungsregeln, die einen Listener mit diesen Zielen verknüpfen. Eine Zielgruppe ist eine logische Gruppierung von registrierten Zielen, wobei jedes Ziel ein beliebiges Objekt mit einer IP-Adresse in Ihrem VDC ist, wie z.B. ein VM oder ein weiteres Load Balancer. Sie können die gleiche Zielgruppe über mehrere Weiterleitungsregeln hinweg wiederverwenden.

1.1 Bereitstellung des Load Balancer und der Zielgruppe

Beginnen Sie mit dem Load Balancer und einer Zielgruppe. Jedes Ziel wird mit einer IP, einem Port und einem Gewicht registriert. Der Zielgewichtsbereich ist 1 - 256, und Sie verwenden ihn, um proportional mehr Datenverkehr an größere Backends zu senden. Die LAN-Zielgruppe kann aus verschiedenen Ressourcen bestehen, wie z.B. einem Load Balancer oder einem LAN. Sie können auch mehrere Zielgruppen für verschiedene Load Balancer-Instanzen erstellen, wie z.B. eine Zielgruppe für die öffentliche LAN und eine weitere für die interne LAN. Die Load Balancer-Instanz kann auch mit anderen Ressourcen kombiniert werden, wie z.B. einem IP oder einem VM, um eine umfassende Netzwerkinfrastruktur zu erstellen. Die Kombination von Load Balancer-Instanzen und Zielgruppen ermöglicht eine flexible und skalierbare Architektur für Ihre Anwendungen.

resource "ionoscloud_application_loadbalancer" "taskboard_api" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-api-alb"
  listener_lan  = ionoscloud_lan.public.id
  target_lan    = ionoscloud_lan.app.id
  ips           = [ionoscloud_ipblock.alb_ip.ips[0]]
}

resource "ionoscloud_target_group" "api_targets" {
  name      = "taskboard-api-tg"
  algorithm = "ROUND_ROBIN"
  protocol  = "HTTP"

  targets {
    ip                 = ionoscloud_server.api_1.nics[0].ips[0]
    port               = 8080
    weight             = 10
    health_check_enabled = true
  }
  targets {
    ip                 = ionoscloud_server.api_2.nics[0].ips[0]
    port               = 8080
    weight             = 10
    health_check_enabled = true
  }
}

Ein öffentliches ALB erfordert einen reservierten öffentlichen IP, weshalb das ips-Argument auf ein ionoscloud_ipblock verweist. Die unterstützten Lastverteilungs-Algorithmen sind Round Robin, Least Connections, Random und Source IP, wobei Round Robin der Standard ist.

1.2 Weiterleitungsregeln und Listener

Weiterleitungsregeln definieren, wie Client-Datenverkehr auf die Ziele verteilt wird, und mehr als eine Regel kann für das gleiche Load Balancer erstellt werden. Eine Weiterleitungsregel bindet einen Listener IP und Port an eine HTTP-Regel, die übereinstimmende Anfragen an eine Zielgruppe weiterleitet.

resource "ionoscloud_application_loadbalancer_forwardingrule" "api_http" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  application_loadbalancer_id = ionoscloud_application_loadbalancer.taskboard_api.id
  name          = "taskboard-api-fwd"
  protocol      = "HTTP"
  listener_ip   = ionoscloud_ipblock.alb_ip.ips[0]
  listener_port = 80

  http_rules {
    name           = "forward-api"
    type           = "FORWARD"
    target_group   = ionoscloud_target_group.api_targets.id
  }
}

Der ALB unterstützt die HTTP- und HTTPS-Protokolle über HTTP1 und HTTP2. Jenseits der einfachen pfadbasierten Weiterleitung umfassen die Routingtypen hostnamebasiertes, query-string-basiertes, headerbasiertes, methodenbasiertes, cookiebasiertes, Quell-IP-basiertes Routing, URL-Weiterleitung und statische feste Antworten. Ein ALB in Ihrem Vertrag kann zwischen 1 und 10 Listener aufweisen, und Sie können bis zu 5 ALBs pro Vertrag bereitstellen.

1.3 TLS, WebSocket und gRPC

Der ALB unterstützt TLS-Entlastung, sodass er HTTPS beendet und einfaches HTTP an Ihre Backends weiterleitet, wodurch die Zertifikatsverwaltung von Ihren Anwendungsservern entfernt wird. SNI wird unterstützt, was es einem einzelnen Listener ermöglicht, mehrere Zertifikate nach Hostname zu bedienen. WebSocket und gRPC werden beide unterstützt, sodass der gleiche ALB eine REST-API- und eine Streaming-Endpunkt ohne separaten Proxy bedient. Der rohe API-Aufruf zum Erstellen eines WebSocket-fähigen ALB zielt auf die applicationloadbalancers-Sammlung ab, um eine HTTP- und eine HTTPS-Instanz zu erstellen, die von einem TLS- und einem API-Dienst unterstützt wird, der auf einem IP- und einem REST-System basiert, das von einem API-Prozess gesteuert wird, der in einem HTTPS- und einem HTTP-Kontext ausgeführt wird.

curl -X POST \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer '"$IONOS_TOKEN" \
  https://api.ionos.com/cloudapi/v6/datacenters/$DC_ID/applicationloadbalancers \
  -d '{"properties":{"name":"alb-websocket","listenerLan":1,"targetLan":2,"ips":["1.2.3.4"]}}'

2. Netzwerk-Load Balancer als Code

Wenn Sie rohe L4-Durchsatzleistung benötigen und keine Anwendungs-Schicht-Weiterleitung benötigen, bereit die ionoscloud_networkloadbalancer-Ressource eine Layer-4-Load Balancer vor. Der NLB operiert auf der OSI-Schicht 4 und verteilt TCP-Datenverkehr auf Ziele ohne Inspektion der Nutzlast.

Der NLB verfügt über eine einzelne Listener-Schnittstelle, die mehrere IPs mit unterschiedlichen Weiterleitungsregeln unterstützen kann. Ein öffentlicher NLB ist dem Internet ausgesetzt und akzeptiert Client-Verbindungen direkt, wobei er als Randgerät für Nord-Süd-Datenverkehr dient. Seine Lastverteilungs-Algorithmen sind dieselben wie bei der ALB: Round Robin, Least Connections, Random und Source IP.

2.1 Bereitstellung eines NLB mit Weiterleitungsregeln

resource "ionoscloud_networkloadbalancer" "taskboard_nlb" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-nlb"
  listener_lan  = ionoscloud_lan.public.id
  target_lan    = ionoscloud_lan.app.id
  ips           = [ionoscloud_ipblock.nlb_ip.ips[0]]
}

resource "ionoscloud_networkloadbalancer_forwardingrule" "tcp" {
  datacenter_id          = ionoscloud_datacenter.taskboard.id
  networkloadbalancer_id = ionoscloud_networkloadbalancer.taskboard_nlb.id
  name          = "taskboard-tcp-fwd"
  algorithm     = "SOURCE_IP"
  protocol      = "TCP"
  listener_ip   = ionoscloud_ipblock.nlb_ip.ips[0]
  listener_port = 5432

  targets {
    ip     = ionoscloud_server.db_1.nics[0].ips[0]
    port   = 5432
    weight = 1
  }

  health_check {
    client_timeout = 50000
    connect_timeout = 5000
    target_timeout  = 50000
    retries         = 3
  }
}

Das NLB-Protokoll-Set umfasst nur TCP; UDP wird nicht unterstützt und HTTP-Gesundheitsprüfungen werden nicht unterstützt, sodass die Gesundheitsprüfung auf TCP basiert. Sitzungs-Adhäsion auf dem NLB verwendet Source IP-Affinität: Eine Client-Sitzung bleibt auf dem gleichen Ziel, solange ihre TCP-Sitzungen aktiv sind. Das Standard-Ziel-Gewicht beträgt 1 mit einem Maximum von 256 und die Standard-Gesundheitsprüfung umfasst 3 Wiederholungen. Sie können bis zu 5 NLBs pro Vertrag bereitstellen.

2.2 Auswahl zwischen ALB und NLB

Die Entscheidung wird durch die Schicht bestimmt, die Ihre Routing-Anforderungen inspizieren muss. Die folgende Tabelle fasst die beiden Optionen für Code-Zeit-Entscheidungen zusammen:

Wählen Sie den ALB, wenn Sie nach URL-Pfad, Host oder Header routen oder wenn Sie möchten, dass der Load Balancer den TLS-Verkehr beendet. Die TaskBoard-API verwendet einen ALB, damit /api/tasks und /api/health geroutet und TLS-Verkehr am Rand beendet werden können. Wählen Sie den NLB für nicht-HTTP-TCP-Dienste, bei denen Sie eine minimale L4-Verteilung wünschen und die Anwendung ihre eigenen Protokoll-Bedenken selbst handhabt.

3. Network Security Groups als Code

Eine Netzwerksicherheitsgruppe ist eine Zustands-Firewall, die Sie Ihren virtuellen Maschinen und Netzwerkkarten zuordnen. Die IONOS-spezifische Regel, die alles in diesem Abschnitt regelt: NSGs binden auf der Server-Netzwerkkarten-Ebene. Sie gelten nicht für den Managed ALB oder NLB, und Managed Kubernetes Node-Poolknoten sind von NSGs ausgeschlossen. Sie sichern Lastenausgleichs-Backends, indem Sie Regeln auf den Backend-Netzwerkkarten und nicht auf dem Load Balancer schreiben.

Die Standardaktion einer NSG ist "deny-all", sodass der Datenverkehr blockiert wird, es sei denn, eine explizite Regel erlaubt ihn. Regeln haben eine Richtung, entweder INGRESS oder EGRESS, und beide Richtungen werden unterstützt. Die unterstützten Protokolle sind TCP, UDP, ICMP, ICMPv6, GRE, VRRP, ESP, AH und ANY.

3.1 Anfügen von NSGs und Schreiben von Regeln

Die Anfügegranularität ist pro-VM, was alle Netzwerkkarten dieser VM umfasst, oder pro-Netzwerkkarte für eine granulare Steuerung. Wenn eine VM Mitglied einer NSG ist, erben alle Netzwerkkarten der VM die Firewall-Regeln implizit. Jede Netzwerkkarte kann bis zu 10 NSGs tragen, ein VDC kann bis zu 200 NSGs halten, und jede NSG kann bis zu 100 Regeln halten.

resource "ionoscloud_nsg" "app_tier" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-app-nsg"
  description   = "App tier: allow ALB to API port only"
}

resource "ionoscloud_nsg_firewallrule" "allow_api_from_app_lan" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  nsg_id        = ionoscloud_nsg.app_tier.id
  protocol      = "TCP"
  name          = "allow-api-8080"
  type          = "INGRESS"
  source_ip     = "10.0.1.0/24"
  port_range_start = 8080
  port_range_end   = 8080
}

Da die Firewall zustandsbehaftet ist, schreiben Sie nur die Eingangsregel für einen eingehenden TCP-Service; der Rückverkehr wird automatisch ohne eine entsprechende Ausgangsregel zugelassen.

3.2 Die rohe API und Regel-Eigenschaften

Unter den Terraform-Ressourcen ist eine NSG die security-group API-Entität, und jede Regel ist eine firewall-rule-Entität. Nur Vertragsadministratoren, Besitzer und Benutzer mit Berechtigungen zum betreffenden VDC können NSGs über die API erstellen und verwalten. Die POST-Anfrage zum Hinzufügen einer Regel zielt auf die Sicherheitsgruppe in einem Rechenzentrum ab:

curl -X POST \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer '"$IONOS_TOKEN" \
  https://api.ionos.com/cloudapi/v6/datacenters/$DC_ID/securitygroups/$NSG_ID/rules \
  -d '{"properties":{"name":"allow-api-8080","protocol":"TCP","type":"INGRESS","sourceIp":"10.0.1.0/24","portRangeStart":8080,"portRangeEnd":8080}}'

Die Regel-Eigenschaftsnamen sind name, protocol, sourceMac, ipVersion, sourceIp, targetIp, portRangeStart, portRangeEnd, icmpCode, icmpType und type. Eine Standard-NSG enthält 4 vordefinierte Regeln: alle IPv4-Ausgangsregeln zulassen, alle IPv6-Ausgangsregeln zulassen, IPv4-Eingangsregeln nur von 10.0.0.0/24 zulassen und IPv6-Eingangsregeln nur von dem zugeteilten /56 CIDR des Rechenzentrums zulassen. Die Netto-Wirkung ist, dass alle ausgehenden Datenverkehre zugelassen werden, während eingehende Datenverkehre blockiert werden, außer für die explizit zugelassenen Bereiche.

4. Sicherung der Lastausgleichsebene

Die Kernarchitekturfolge der Bindung von Netzwerksicherheitsgruppen (NSGs) an Netzwerkadapter (NICs) ist, dass der Application Load Balancer (ALB) keine Sicherheitsgrenze darstellt, die mit Firewall-Regeln konfiguriert werden kann. Der Datenverkehr, den der ALB an den Backend-Server weiterleitet, erreicht den Backend-NIC, und dort findet die Filterung statt. Daher schreiben Sie Ihre NSG-Regeln so, dass nur der Datenverkehr von Load Balancer zugelassen wird.

Für die TaskBoard-App-Ebene befindet sich der ALB auf dem Listener (öffentlichen) LAN und leitet den Datenverkehr in die App-LAN weiter. Die App-Server-NICs sollten nur TCP-Datenverkehr auf dem API-Port von dem App-LAN-Subnetz akzeptieren und alles andere ablehnen. Die DB-Ebenen-NICs sollten nur PostgreSQL-Datenverkehr von der App-LAN akzeptieren, niemals von dem öffentlichen LAN.

4.1 Regeln für die Ebenenisolierung

Die NICs der App-Server sollten so konfiguriert werden, dass sie nur Datenverkehr von der App-LAN-Ebene akzeptieren, und die DB-Ebenen-NICs sollten so konfiguriert werden, dass sie nur Datenverkehr von der App-LAN-Ebene akzeptieren. Dies stellt sicher, dass der Datenverkehr zwischen den Ebenen isoliert und gesichert wird, und dass nur autorisierter Datenverkehr zwischen den Ebenen fließen kann. Die Verwendung von LAN-Regeln ermöglicht eine feinere Kontrolle über den Datenverkehr und stellt sicher, dass die Sicherheitsanforderungen der Anwendung erfüllt werden. Durch die Kombination von ALB und NSG-Regeln kann eine sichere und skalierbare Architektur für die TaskBoard-App erstellt werden, die die Anforderungen an Hochverfügbarkeit und Skalierbarkeit erfüllt, und die durch die Verwendung von LAN-Regeln unterstützt wird.

# DB tier: PostgreSQL reachable only from the app subnet
resource "ionoscloud_nsg" "db_tier" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-db-nsg"
}

resource "ionoscloud_nsg_firewallrule" "allow_pg_from_app" {
  datacenter_id    = ionoscloud_datacenter.taskboard.id
  nsg_id           = ionoscloud_nsg.db_tier.id
  protocol         = "TCP"
  name             = "allow-pg-from-app"
  type             = "INGRESS"
  source_ip        = "10.0.1.0/24"
  port_range_start = 5432
  port_range_end   = 5432
}

Da db_tier eine benutzerdefinierte NSG ohne eigene Regeln ist, die über diejenige hinausgehen, die Sie gerade geschrieben haben, erhält sie nicht die vordefinierten Standardregeln der Plattform (diese gelten nur für die eigene Standard-NSG des VDC); dieser Stapel bietet Ihnen eingehenden PostgreSQL vom App-Subnetz aus und Sie müssen eine explizite Ausgangsregel auf db_tier hinzufügen, wenn der Datenbankserver eine ausgehende Konnektivität benötigt (zum Beispiel DNS, NTP oder Patching). Es gibt keine Regel, die den öffentlichen LAN erwähnt, sodass die Datenbank aus dem Internet heraus per Konstruktion nicht erreichbar ist.

4.2 Anfügen der NSG an die Backend-NICs

Die NSG wird erst wirksam, wenn sie an die NICs angefügt ist, die sie schützen soll. Fügen Sie die App-Tier-NSG an die API-Server-NICs und die db-Tier-NSG an die Datenbankserver-NICs an. Da die Mitgliedschaft von allen NICs eines Mitglieds VM geerbt wird, können Sie sie auf VM-Ebene anfügen, wenn ein Server eine einzelne relevante NIC hat.

resource "ionoscloud_nsg_share" "api_nics" {
  for_each      = toset([ionoscloud_server.api_1.id, ionoscloud_server.api_2.id])
  datacenter_id = ionoscloud_datacenter.taskboard.id
  server_id     = each.value
  nsg_id        = ionoscloud_nsg.app_tier.id
}

Das Ergebnis ist eine Verteidigung in der Tiefe, die vollständig in Terraform geschrieben ist: der ALB verteilt und beendet TLS, während die NSGs auf den Backend-NICs durchsetzen, dass nur der beabsichtigte Datenverkehr jeden Tier erreicht.

API Referenz-Quick-Card

Wichtige API-Endpunkte für Lastverteilung und Sicherheit:

Basis-URL: https://api.ionos.com/cloudapi/v6 Authentifizierung: Authorization: Bearer <token>

Code-Labor

Ziel: Bereitstellung eines Application Load Balancers (ALB) für die TaskBoard API mit Terraform, Hinzufügen von NSG-Regeln zu den App- und DB-Ebenen und Überprüfung der Routing- und Isolationsfunktionen.

Voraussetzungen:

• IONOS Cloud-Konto mit API-Token (IONOS_TOKEN exportiert)
• Terraform mit dem ionoscloud-Anbieter konfiguriert
• Der TaskBoard-Netzwerkstack aus Einheit 2.2 bereits angewendet (Rechenzentrum, LANs, Server)

Schritt 1: Reservieren einer öffentlichen IP für den ALB

resource "ionoscloud_ipblock" "alb_ip" {
  location = "de/fra"
  size     = 1
  name     = "taskboard-alb-ip"
}

Die Erwarteten Ausgaben:

ionoscloud_ipblock.alb_ip: Creation complete after 8s [id=...]

Schritt 2: Hinzufügen des Load Balancer und der Zielgruppe

terraform apply -target=ionoscloud_application_loadbalancer.taskboard_api \
  -target=ionoscloud_target_group.api_targets

Die Erwarteten Ausgaben:

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Schritt 3: Hinzufügen der Weiterleitungsregel

terraform apply -target=ionoscloud_application_loadbalancer_forwardingrule.api_http

Die erwartete Ausgabe:

ionoscloud_application_loadbalancer_forwardingrule.api_http: Creation complete

Schritt 4: Erstellen und Anfügen des app-tier NSG

terraform apply \
  -target=ionoscloud_nsg.app_tier \
  -target=ionoscloud_nsg_firewallrule.allow_api_from_app_lan \
  -target=ionoscloud_nsg_share.api_nics

Die Erwarteten Ausgaben:

Apply complete! Resources: 4 added, 0 changed, 0 destroyed.

Schritt 5: Erstellen des DB-Tier-NSG mit der Isolationsregel

terraform apply -target=ionoscloud_nsg.db_tier \
  -target=ionoscloud_nsg_firewallrule.allow_pg_from_app

Das erwartete Ergebnis:

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Schritt 6: Überprüfen Sie die ALB-Routen zum API

curl -i http://$(terraform output -raw alb_ip)/api/health

Die Erwarteten Ausgaben:

HTTP/1.1 200 OK
{"status":"ok"}

Schritt 7: Überprüfen der DB-Isolation von der öffentlichen Seite

nc -zv -w 5 $(terraform output -raw db_public_check) 5432

Das erwartete Ergebnis:

nc: connect to ... port 5432 (tcp) timed out: Operation now in progress

Validierungs-Checkliste:

• [ ] ALB gibt 200 auf /api/health durch die reservierte öffentliche IP zurück
• [ ] App-NICs akzeptieren TCP 8080 nur vom App-Subnetz
• [ ] PostgreSQL auf der Datenbank-Ebene ist von außerhalb des App-Subnetzes aus nicht erreichbar

Aufräumen:

terraform destroy \
  -target=ionoscloud_application_loadbalancer_forwardingrule.api_http \
  -target=ionoscloud_application_loadbalancer.taskboard_api \
  -target=ionoscloud_target_group.api_targets \
  -target=ionoscloud_nsg.app_tier \
  -target=ionoscloud_nsg.db_tier \
  -target=ionoscloud_ipblock.alb_ip

Häufige Fehlerquellen

Entwicklerfehler, die bei der Lastverteilung und Sicherheit auf IONOS Cloud vermieden werden sollten:

1. Versuch, ein NSG an den Load Balancer anzuhängen

   • Problem: Sie schreiben Firewall-Regeln, die den Datenverkehr am ALB filtern sollen, aber sie haben keine Auswirkungen.
   • Warum es passiert: NSGs binden nur auf der Server-NIC-Ebene. Sie gelten nicht für den Managed ALB oder NLB, und Managed Kubernetes-Node-Poolknoten sind vollständig ausgeschlossen.
   • Lösung: Schreiben Sie die Regeln auf den Backend-NICs. Erlauben Sie nur den lastverteilten Datenverkehr und isolieren Sie jede Ebene auf ihren eigenen NICs.

2. Schreiben von Egress-Regeln für eingehende Dienste

   • Problem: Sie fügen eine Eingangsregel für TCP 8080 hinzu und eine entsprechende Ausgangsregel für die Antwort, dann verhält sich der Datenverkehr inkonsistent oder Sie öffnen die NSG zu sehr.
   • Warum es passiert: Die IONOS-NSG ist ein Zustands-Firewall, daher ist der Rückdatenverkehr für eine zugelassene Eingangsverbindung automatisch erlaubt.
   • Lösung: Schreiben Sie nur die Eingangsregel für einen eingehenden Dienst. Reservieren Sie Ausgangsregeln für Verbindungen, die Ihr Server initiiert.

3. Vergessen, dass der ALB eine reservierte öffentliche IP benötigt

   • Problem: terraform apply schlägt fehl, wenn ein öffentlicher ALB erstellt wird, da keine verwendbare öffentliche IP bereitgestellt wird.
   • Warum es passiert: Ein öffentlicher ALB benötigt eine reservierte öffentliche IP, die über das ips-Argument bereitgestellt wird.
   • Lösung: Stellen Sie zunächst eine ionoscloud_ipblock bereit und verweisen Sie auf ionoscloud_ipblock.alb_ip.ips[0] in beiden dem Load Balancer und dem Weiterleitungsregel-Listener.

Zusammenfassung

Sie können jetzt einen gemanagten Load Balancer vor einer Ebene platzieren und diese Ebene vollständig im Code sichern. Der ALB handhabt Layer-7-Weiterleitungen, TLS-Entlastung und Protokolle wie WebSocket und gRPC, während der NLB eine minimale Überhead-Layer-4-TCP-Verteilung bietet. Network Security Groups erzwingen pro-NIC, Zustands-behaftete, Verweigerungs-Filter und Sie sichern lastverteilte Backends, indem Sie Regeln auf den Backend-NICs schreiben, da der Load Balancer selbst nicht ein NSG-Ziel ist.

Für TaskBoard sitzt der API jetzt hinter einem ALB auf dem öffentlichen LAN, die App-NICs akzeptieren nur weitergeleiteten API-Verkehr vom App-Subnetz und die Datenbank ist nur vom App-Tier aus erreichbar. Die nächste Einheit bereitstellt die Speicherebene, von der diese Server abhängen.

Wichtige Punkte:

• Der ALB wird aus drei Ressourcen aufgebaut: ionoscloud_application_loadbalancer, ionoscloud_target_group und ionoscloud_forwardingrule
• Wählen Sie den ALB für HTTP- und HTTPS-Anwendungsweiterleitungen und TLS-Entlastung; wählen Sie den NLB für L4-TCP-Verteilung
• NSGs binden auf der Server-NIC-Ebene nur, nie an den ALB, NLB oder Managed Kubernetes-Knoten
• NSGs sind standardmäßig auf Verweigerung gesetzt und zustandsbehaftet, daher schreiben Sie nur Eingangsregeln für eingehende Dienste
• Sichern Sie eine lastverteilte Ebene, indem Sie auf den Backend-NICs filtern und jede Ebene mit ihrer eigenen NSG isolieren

Wichtige Begriffe:

• Zielgruppe: Eine logische Gruppierung von registrierten Zielen (IP, Port, Gewicht), an die ein ALB den Verkehr verteilt; wiederverwendbar über Weiterleitungsregeln.
• Weiterleitungsregel: Eine Regel, die einen Listener-IP und Port mit Zielen bindet und definiert, wie der Load Balancer den Clientenverkehr verteilt.
• Listener: Die clientseitige Schnittstelle eines Load Balancer, die Verbindungen auf einem exponierten IP und konfiguriertem Port akzeptiert.
• Netzwerksicherheitsgruppe (NSG): Eine zustandsbehaftete, Verweigerungs-Firewall, die pro-VM oder pro-NIC angehängt wird und bis zu 100 Regeln enthält.
• TLS-Entlastung: Beenden von HTTPS am ALB und Weiterleiten von plain HTTP an Backends, Entfernen von Zertifikathandling von Anwendungsservern.

Nächste Schritte

Weiterlernen: Einheit 2.4: Speicherbereitstellung als Code

Verwandte Themen:

• Einheit 2.2: Netzwerk und Konnektivität als Code
• Einheit 5.2: Sicherheitsautomatisierung