Configuration d'un chemin privé Network Load Balancer for VPC

{: tag-vpc}[Virtual Private Cloud] 4.16 et versions ultérieures

Dans les environnements VPC entièrement privés, sans accès public à l'Internet, vous pouvez utiliser un équilibreur de charge Private Path Network pour équilibrer le trafic réseau circulant vers les applications exécutées dans vos clusters VPC. Pour plus d'informations, voir les cas d'utilisation du service Private Path.

Prérequis

  1. Accédez à votre cluster Red Hat OpenShift.

  2. Si vous n'avez pas encore d'application en cours d'exécution, déployez une application sur votre cluster. Prenez soin d'ajouter un libellé à votre déploiement dans la section "metadata" de votre fichier de configuration de déploiement. Ce libellé personnalisé identifie tous les pods dans lesquels s'exécute votre application afin de pouvoir les inclure dans l'équilibrage de charge.

Configuration du service LoadBalancer

  1. Copiez la configuration LoadBalancer et enregistrez-la dans un fichier appelé lb.yaml.

    apiVersion: v1
kind: Service
metadata:
  name: <app_name>-vpc-nlb-<VPC_zone>
  annotations:
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "my-load-balancer"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "private-path" # Required
    service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private" # Required
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets: "<subnet_ID>"
spec:
  type: LoadBalancer
  selector:
    <selector_key>: <selector_value>
  ports:
   - name: http
     protocol: TCP
     port: 8080
     targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
   - name: https
     protocol: TCP
     port: 443
     targetPort: 443 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
  externalTrafficPolicy: Local # Specify Local or Cluster.

  2. Personnalisez les champs en fonction de votre cas d'utilisation. Pour une liste complète des annotations, voir Annotations et spécifications.

  3. Sauvegardez vos modifications.

  4. Déployez le service Load Balancer sur votre cluster.

    oc apply -f lb.yaml

Création d'un service Private Path

Suivez les instructions pour créer un service de chemin privé.

Configuration d'une passerelle privée virtuelle pour points finaux

Maintenant que vous avez configuré un service d'équilibreur de charge, vous devez définir une passerelle VPE (Virtual Private Endpoint) pour accéder aux applications de votre cluster.

Pour plus d'informations, voir Création d'une passerelle de point d'extrémité dans l'interface utilisateur.

Connexion à vos applications par l'intermédiaire de votre VPE

Pour plus d'informations sur la connexion à vos applications via votre VPE, voir Accéder à votre point de terminaison privé virtuel après avoir configuré votre passerelle de point de terminaison.

Annotations et spécifications

Examinez les annotations et les spécifications obligatoires et facultatives de VPC NLB.

Annotations et spécifications requises

externalTrafficPolicy
Spécifiez Local ou Cluster.
Définissez la valeur Local pour conserver l'adresse IP source des demandes client émises vers vos applications. Ce paramètre empêche le trafic entrant d'être transféré vers un autre nœud. Cette option configure également les contrôles d'intégrité HTTP.
Si Cluster est défini, DSR n'est implémenté qu'à partir du noeud worker auquel l'équilibreur de charge de réseau VPC achemine initialement la demande entrante. Une fois la demande reçue, elle est transmise à un nœud de travail qui contient le module d'application, qui peut se trouver dans une zone différente. La réponse du pod d'application est envoyée au noeud worker d'origine et ce dernier utilise DSR pour envoyer la réponse directement au client, en contournant l'équilibreur de charge de réseau VPC. Cette option configure également les contrôles d'intégrité TCP.

Annotations et spécifications facultatives

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name
Ajoutez un nom unique pour que votre équilibreur de charge VPC soit persistant. Les équilibreurs de charge VPC persistants ne sont pas supprimés lorsque le cluster auquel ils appartiennent est supprimé. Pour plus d'informations, voir Équilibreurs de charge VPC persistants. Cette annotation ne peut être définie que lors de la création de l'équilibreur de charge. Il ne peut pas être utilisé dans une opération de mise à jour.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol
Cette annotation définit le protocole de contrôle de santé sur la ressource d'équilibreur de charge VPC associée au service d'équilibreur de charge Kubernetes. Les options disponibles sont http, https ou tcp. Habituellement, le protocole de contrôle de santé VPC LB est déterminé par la valeur du paramètre externalTrafficPolicy dans la spécification de service de l'équilibreur de charge Kubernetes. Toutefois, cette annotation ne tient pas compte de cette logique. Cette annotation ne modifie pas la façon dont Kubernetes, et kube-proxy en particulier, se comporte par rapport aux différents paramètres de externalTrafficPolicy
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-port
Le port de l' TCP, utilisé pour les contrôles d'intégrité. Cette annotation ne s'applique que si ibm-load-balancer-cloud-provider-vpc-health-check-protocol est également spécifié. Si le port TCP spécifié se situe en dehors de la plage de ports des nœuds Kubernetes (30 000-32 767), le groupe de sécurité VPC appliqué aux nœuds de travail du cluster doit être modifié afin d'autoriser le trafic entrant sur ce port. Si cette annotation est appliquée à un service de répartition de charge « Kubernetes » associé à un ALB VPC, les règles sortantes du groupe de sécurité attribué à l’ALB VPC doivent être modifiées afin d’autoriser le trafic sortant vers le port TCP spécifié. Pour plus d'informations, voir Comprendre la mise en réseau sécurisée par défaut des clusters VPC et Créer et gérer des groupes de sécurité VPC.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets
Annotation permettant de spécifier le sous-réseau à utiliser pour attribuer les adresses IP à la ppNLB. Ces adresses IP ne sont utilisées qu'en interne. La valeur peut être un identifiant de sous-réseau VPC, un nom de sous-réseau VPC ou une adresse CIDR de sous-réseau VPC. Vous ne devez spécifier qu'un seul sous-réseau. Tout le trafic entrant semble provenir de ces adresses IP. Bien que toutes les adresses se trouvent dans une seule zone, la ppNLB gère toujours le trafic entrant de toutes les zones. Si cette zone spécifique est mise hors service, le trafic entrant en provenance des autres zones continue de fonctionner. Si vous ne spécifiez pas cette annotation, le sous-réseau est automatiquement sélectionné et le sous-réseau du nœud de travail en grappe qui a le plus d'adresses IP libres disponibles est utilisé. Pour afficher les sous-réseaux dans tous les groupes de ressources, exécutez ibmcloud oc subnets --provider vpc-gen2 --vpc-id VPC_ID --zone ZONE.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector
Annotation permettant de spécifier un sélecteur d'étiquette de nœud de travail. Vous pouvez configurer des nœuds de travail spécifiques dans votre cluster pour recevoir du trafic en spécifiant des clés de sélection d'étiquettes. Vous ne pouvez inclure qu'un seul sélecteur d'étiquette dans l'annotation, et ce sélecteur doit être spécifié au format "key=value". Si cette annotation n'est pas spécifiée, tous les nœuds de travail de votre cluster sont configurés pour recevoir le trafic provenant du VPC NLB. Cette annotation prévaut sur l'annotation service.kubernetes.io/ibm-load-balancer-cloud-provider-zone, et toutes les étiquettes dedicated: edge présentes sur les nœuds de travail sont ignorées. Pour limiter le trafic à une zone spécifique, vous pouvez utiliser cette annotation pour spécifier les nœuds de travail dans cette zone. Notez que la définition d'une nouvelle étiquette sur un nœud de travailleur de cluster ne configure pas automatiquement le nœud de travailleur pour recevoir du trafic ; vous devez recréer ou mettre à jour le VPC NLB pour que le nœud de travailleur nouvellement étiqueté reçoive du trafic.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-path
Le chemin d'accès au contrôle de santé URL pour les contrôles de santé HTTP et HTTPs. Cette annotation ne s'applique que si ibm-load-balancer-cloud-provider-vpc-health-check-protocol vaut http ou https. Le chemin d'accès URL doit être au format d'une cible de demande de forme d'origine. Si cette annotation n'est pas spécifiée et que l'annotation ibm-load-balancer-cloud-provider-vpc-health-check-protocol est définie sur http ou https, la valeur par défaut / est appliquée.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-delay
Facultatif. Nombre de secondes d'attente entre les tentatives de contrôle de l'état de santé. Par défaut, cette valeur est fixée à 5, avec un minimum de 2 et un maximum de 60. Cette valeur doit être supérieure à la valeur ibm-load-balancer-cloud-provider-vpc-health-check-timeout, qui est fixée à 2 par défaut.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout
Facultatif. Nombre de secondes d'attente pour une réponse à un contrôle de santé. Par défaut, cette valeur est fixée à 2, avec un minimum de 1 et un maximum de 59. Cette valeur doit être inférieure à la valeur ibm-load-balancer-cloud-provider-vpc-health-check-delay, qui est fixée à 5 par défaut.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-retries
Nombre maximal de tentatives de contrôle de santé pour l'équilibreur de charge VPC. Par défaut, cette valeur est fixée à 2, avec un minimum de 1 et un maximum de 10.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-member-quota
Optionnel. Le nombre de nœuds de travail par zone vers lesquels l'équilibreur de charge se dirige. La valeur par défaut est de 8. Pour un cluster dont les nœuds de travail sont répartis dans trois zones, cela signifie que l'équilibreur de charge achemine le trafic vers 24 nœuds de travail au total. Le nombre total de nœuds de travail dans toutes les zones vers lesquelles l'équilibreur de charge se dirige ne peut pas dépasser 50. Si la grappe compte moins de 50 nœuds de travail dans toutes les zones, spécifiez 0 pour router vers tous les nœuds de travail d'une zone.
selector
Clé de libellé (<selector_key>) et valeur (<selector_value>) que vous avez utilisées dans la section spec.template.metadata.labels du déploiement de votre application YAML. Ce libellé personnalisé identifie tous les pods dans lesquels s'exécute votre application afin de pouvoir les inclure dans l'équilibrage de charge.
port
Port sur lequel le service est à l'écoute.
targetPort
Facultatif : Port vers lequel le service achemine le trafic. L'application s'exécutant dans le pod doit être à l'écoute du trafic entrant de type « TCP » sur ce port de destination. Le port cible est souvent défini de manière statique dans l'image qui tourne dans le module d'application. Le port cible configuré dans le pod est différent du port du nœud pour le service et peut également être différent du port externe configuré sur le VPC LB.