Sie können einen Kubernetes-Dienst vom Typ LoadBalancer für die Verwendung einer statischen IP-Adresse konfigurieren. Beachten Sie bei der Implementierung dieser Funktion eine wichtige Sicherheitsüberlegung und die Anleitung für die Cluster-Härtung. Diese stellen eine wichtige Mindestanforderungen an die Komponenten dar.

Verwenden einer statischen IP-Adresse für einen Dienst vom Typ LoadBalancer

Wenn Sie einen Kubernetes-Dienst von Typ LoadBalancer definieren, erhalten Sie in der Regel eine vom Lastausgleichsdienst zugewiesene flüchtige IP-Adresse.

Alternativ können Sie eine statische IP-Adresse für den Lastausgleichsdienst angeben. Beim Erstellen des Diensts wird die Instanz des Lastausgleichsdiensts mit der von Ihnen zugewiesenen statischen IP-Adresse bereitgestellt.

In folgendem Beispieldienst wird die Konfiguration eines unterstützten Lastausgleichsdiensts mit einer statischen IP-Adresse dargestellt. In die Dienstspezifikation nehmen Sie den Parameter loadBalancerIP und einen IP-Adresswert auf, der als 10.11.12.49 in diesem Beispiel angegeben wird. 
kind: Service
apiVersion: v1
metadata:
  name: load-balancer-service-with-static-ip
spec:
  selector:
    app: hello-world
    tier: frontend
  ports:
  - protocol: "TCP"
    port: 80
    targetPort: 80
  type: LoadBalancer
  loadBalancerIP: 10.11.12.49

Für den NSX Advanced Load Balancer verwenden Sie eine IP-Adresse aus dem IPAM-Pool, der für den Lastausgleichsdienst bei dessen Installation konfiguriert wurde. Wenn der Dienst erstellt und die statische IP-Adresse zugewiesen wurde, markiert der Lastausgleichsdienst ihn als zugeteilt und verwaltet den Lebenszyklus der IP-Adresse wie eine flüchtige IP-Adresse. Wenn der Dienst folglich entfernt wird, wird die Zuweisung der IP-Adresse aufgehoben, und die IP-Adresse kann neu zugeteilt werden.

Für den NSX-T Load Balancer stehen zwei Optionen zur Verfügung. Der Standardmechanismus ist mit dem NSX Advanced Load Balancer identisch: Verwenden Sie eine IP-Adresse aus dem IP-Pool, der für den Lastausgleichsdienst bei dessen Installation konfiguriert wurde. Wenn die statische IP-Adresse zugewiesen wird, markiert der Lastausgleichsdienst die Adresse automatisch als zugewiesen und verwaltet deren Lebenszyklus.

Die zweite NSX-T-Option besteht in der manuellen Vorabzuteilung der statischen IP-Adresse. In diesem Fall verwenden Sie eine IP-Adresse, die nicht Teil des dem Lastausgleichsdienst zugewiesenen externen Lastausgleichsdienst-IP-Pools ist, sondern aus einem dynamischen IP-Pool stammt. In diesem Fall verwalten Sie die Zuteilung und den Lebenszyklus der IP-Adresse manuell mithilfe von NSX Manager.

Wichtige Sicherheitsüberlegung und Härtungsanforderung

Bei Verwendung dieser Funktion ist ein potenzielles Sicherheitsproblem zu beachten. Wenn ein Entwickler den Wert Service.status.loadBalancerIP patchen kann, ist er unter Umständen in der Lage, den für die gepatchte IP-Adresse bestimmten Datenverkehr im Cluster zu übernehmen. Wenn insbesondere eine Rolle oder ClusterRole mit der Berechtigung patch an einen Dienst oder ein Benutzerkonto auf einem Cluster gebunden ist, auf dem diese Funktion implementiert ist, kann der Besitzer dieses Kontos seine eigenen Anmeldedaten verwenden, um kubectl-Befehle auszugeben und die dem Lastausgleichsdienst zugewiesene statische IP-Adresse zu ändern.

Um bei Verwendung der statischen IP-Zuteilung für einen Lastausgleichsdienst die möglichen Auswirkungen auf die Sicherheit zu vermeiden, müssen Sie jeden Cluster absichern, auf dem Sie diese Funktion implementieren. Hierzu darf die Rolle oder ClusterRole, die Sie für einen beliebigen Entwickler definieren, das Verb patch für apiGroups:"" und resources: services/status nicht zulassen. Der beispielhafte Rollenausschnitt zeigt, was Sie bei der Implementierung dieser Funktion nicht tun sollten.

PATCH NICHT ZULASSEN 
- apiGroups:
  - ""
  resources:
  - services/status
  verbs:
  - patch
Um zu überprüfen, ob ein Entwickler über Patch-Berechtigungen verfügt, führen Sie den folgenden Befehl als entsprechender Benutzer aus: 
kubectl --kubeconfig <KUBECONFIG> auth can-i patch service/status

Wenn durch den Befehl yes ausgegeben wird, verfügt der Benutzer über Patch-Berechtigungen. Weitere Informationen finden Sie unter Überprüfen des API-Zugriffs in der Kubernetes-Dokumentation.

Informationen zum Gewähren von Entwicklerzugriff auf einen Cluster finden Sie unter Gewähren von vCenter SSO-Zugriff auf TKG-Dienst-Cluster für Entwickler. Ein Beispiel einer anzupassenden Rollenvorlage finden Sie unter Anwenden der standardmäßigen Pod-Sicherheitsrichtlinie auf TKG-Dienstcluster. Ein Beispiel zur Einschränkung des Clusterzugriffs finden Sie unter https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-example.