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é.

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.

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.

L'exemple de service suivant montre comment configurer un équilibrage de charge pris en charge avec une adresse IP statique. Dans la spécification de service, vous incluez le paramètre 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é.

NE PAS AUTORISER LES CORRECTIFS 
- apiGroups:
  - ""
  resources:
  - services/status
  verbs:
  - patch
Pour vérifier si un développeur dispose des autorisations de correctif, exécutez la commande suivante en tant qu'utilisateur : 
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, reportez-vous à .Accorder aux développeurs l'accès vCenter SSO aux clusters Service TKG. Pour obtenir un exemple de modèle de rôle que vous pouvez personnaliser, consultez Appliquer la stratégie de sécurité de l'espace par défaut aux clusters de TKG. Pour obtenir un exemple de restriction d'accès à un cluster, consultez https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-example.