Vous pouvez configurer un service Kubernetes de type LoadBalancer pour utiliser une adresse IP statique. Tenez compte des exigences minimales de composants, élément important de sécurité à prendre en compte et des conseils de renforcement du cluster lors de la mise en œuvre de cette fonctionnalité.
Exigences minimales
| Composant | Configuration minimale requise | Plus d'informations |
|---|---|---|
| vCenter Server et ESXi | vSphere 7.0 Update 2 | Consultez les Notes de mise à jour. |
| Cluster superviseur | v1.19.1+vmware.2-vsc0.0.8-17610687 |
Reportez-vous à la section Mettre à jour le Cluster superviseur en effectuant une mise à jour des espaces de noms vSphere. |
| Équilibrage de charge | NSX-T Data Center 3.1 Ou NSX Advanced 20.1.x |
Consultez les Notes de mise à jour. |
| Version de Tanzu Kubernetes | L'une des dernières versions de Tanzu Kubernetes. | Reportez-vous à la section Vérifier la compatibilité du cluster Tanzu Kubernetes pour la mise à jour. |
Utilisation d'une adresse IP statique pour un service de type LoadBalancer
Généralement, lorsque vous définissez un service Kubernetes de Type LoadBalancer vous obtenez une adresse IP éphémère attribuée par l'équilibrage de charge. Reportez-vous à la section Exemple d'équilibrage de charge du service Tanzu Kubernetes.
Vous pouvez également spécifier une adresse IP statique pour l'équilibrage de charge. Lors de la création du service, l'instance de l'équilibrage de charge est provisionnée avec l'adresse IP statique que vous avez affectée.
loadBalancerIP et une valeur d'adresse IP, qui est
10.11.12.49 dans cet exemple.
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
Pour NSX Advanced Load Balancer, vous utilisez une adresse IP du pool IPAM configuré pour l'équilibrage de charge lors de son installation. Lorsque le service est créé et que l'adresse IP statique est attribuée, l'équilibrage de charge la marque comme étant allouée et gère le cycle de vie de l'adresse IP de la même manière qu'une adresse IP éphémère. Autrement dit, si le service est supprimé, l'adresse IP est désaffectée et rendue disponible pour réallocation.
Pour l'équilibrage de charge NSX-T, vous avez deux options. Le mécanisme par défaut est le même que celui de NSX Advanced Load Balancer : utilisez une adresse IP provenant du pool d'adresses IP configuré pour l'équilibrage de charge lors de son installation. Lorsque l'adresse IP statique est attribuée, l'équilibrage de charge la marque automatiquement comme étant allouée et gère son cycle de vie.
La deuxième option NSX-T consiste à pré-allouer manuellement l'adresse IP statique. Dans ce cas, vous utilisez une adresse IP qui ne fait pas partie du pool d'adresses IP de l'équilibrage de charge externe attribué à l'équilibrage de charge, mais qui est plutôt prise à partir d'un pool d'adresses IP flottantes. Dans ce cas, vous administrez manuellement l'allocation et le cycle de vie de l'adresse IP à l'aide de NSX Manager.
Considérations importantes en matière de sécurité et exigences de renforcement
Il existe un problème de sécurité potentiel à prendre en compte lors de l’utilisation de cette fonctionnalité. Si un développeur est en mesure de corriger la valeur Service.status.loadBalancerIP, il peut pirater le trafic dans le cluster destiné à l'adresse IP corrigée. En outre, si un rôle ou clusterRole avec l'autorisation patch est lié à un service ou à un compte d'utilisateur sur un cluster dans lequel cette fonctionnalité est implémentée, ce propriétaire de compte peut utiliser ses propres informations d'identification pour émettre des commandes kubectl et modifier l'adresse IP statique attribuée à l'équilibrage de charge.
Pour éviter les implications de sécurité potentielles de l'utilisation de l'allocation d'adresses IP statiques pour un service d'équilibrage de charge, vous devez renforcer la sécurité de chaque cluster sur lequel vous implémentez cette fonctionnalité. Pour ce faire, le rôle ou clusterRole que vous définissez pour tout développeur ne doit pas autoriser le verbe patch pour apiGroups:"" et resources: services/status. L'exemple d'extrait de rôle montre ce qu'il faut éviter de faire lors de l'implémentation de cette fonctionnalité.
- apiGroups: - "" resources: - services/status verbs: - patch
kubectl --kubeconfig <KUBECONFIG> auth can-i patch service/status
Si la commande renvoie yes, l'utilisateur dispose des autorisations de correctif. Pour plus d'informations, consultez Vérification de l'accès à l'API dans la documentation Kubernetes.
Pour accorder aux développeurs l'accès à un cluster, consultez Accorder aux développeurs l'accès aux clusters Tanzu Kubernetes. Pour obtenir un exemple de modèle de rôle que vous pouvez personnaliser, consultez Exemple de rôle pour la stratégie de sécurité de l'espace. Pour obtenir un exemple de restriction d'accès à un cluster, consultez https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-example.
