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.
Mindestanforderungen
| Komponente | Mindestanforderung | Weitere Informationen |
|---|---|---|
| vCenter Server und ESXi | vSphere 7.0 Update 2 | Weitere Informationen finden Sie in den Versionshinweisen. |
| Supervisor-Cluster | v1.19.1+vmware.2-vsc0.0.8-17610687 |
Weitere Informationen finden Sie unter Aktualisieren des Supervisor-Clusters durch Ausführen eines vSphere-Namespace-Updates. |
| Lastausgleichsdienst | NSX-T Data Center v3.1 oder NSX Advanced 20.1.x |
Weitere Informationen finden Sie in den Versionshinweisen. |
| Tanzu Kubernetes-Version | Eine der neuesten Tanzu Kubernetes-Versionen. | Weitere Informationen finden Sie unter Überprüfen der Tanzu Kubernetes-Cluster-Kompatibilität für ein Update. |
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. Weitere Informationen hierzu finden Sie unter Beispiel für einen Load Balancer für den Tanzu Kubernetes-Dienst.
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.
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.
- apiGroups: - "" resources: - services/status verbs: - patch
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 des Entwicklerzugriffs auf Tanzu Kubernetes-Cluster. Ein Beispiel einer anzupassenden Rollenvorlage finden Sie unter Beispielrolle für die Pod-Sicherheitsrichtlinie. Ein Beispiel zur Einschränkung des Clusterzugriffs finden Sie unter https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-example.
