Utiliser un équilibreur de charge TCP/UDP interne

Cette page explique comment créer un équilibreur de charge TCP/UDP interne sur Google Kubernetes Engine (GKE).

Présentation

L'équilibrage de charge TCP/UDP interne rend les services du cluster accessibles aux applications qui s'exécutent sur le même réseau VPC, mais en dehors du cluster, et qui sont situées dans la même région Google Cloud. Par exemple, supposons que vous ayez un cluster dans la région us-west1 et que vous deviez rendre l'un de ses services accessible aux instances de machine virtuelle (VM) Compute Engine s'exécutant dans cette région sur le même réseau VPC.

Vous pouvez créer un équilibreur de charge TCP/UDP interne en créant une ressource de service avec une spécification type: LoadBalancer et une annotation. L'annotation dépend de la version de votre cluster GKE.

Pour GKE versions 1.17 et ultérieures, utilisez l'annotation networking.gke.io/load-balancer-type: "Internal".

Pour les versions antérieures, utilisez l'annotation cloud.google.com/load-balancer-type: "Internal".

Sans équilibrage de charge TCP/UDP interne, vous devez configurer un équilibreur de charge externe et des règles de pare-feu pour rendre l'application accessible en dehors du cluster.

L'équilibrage de charge TCP/UDP interne crée une adresse IP interne pour l'objet Service qui reçoit le trafic des clients dans le même réseau VPC et la même région de calcul. Si vous activez l'accès mondial, les clients de n'importe quelle région du même réseau VPC peuvent accéder à l'objet Service. En outre, les clients d'un réseau VPC connectés au réseau de l'équilibreur de charge à l'aide de l'appairage de réseaux VPC peuvent également accéder à cet objet Service.

Tarifs

Les frais sont facturés d'après le modèle de tarification de Compute Engine. Pour plus d'informations, consultez la section sur la tarification de l'équilibrage de charge et des règles de transfert, ainsi que la page Compute Engine sur le Simulateur de coût Google Cloud.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

Assurez-vous d'avoir activé l'API Google Kubernetes Engine.

Activer l'API Google Kubernetes Engine

Assurez-vous d'avoir installé le SDK Cloud.

Configurez les paramètres gcloud par défaut à l'aide de l'une des méthodes suivantes :

Utilisez gcloud init pour suivre les instructions permettant de définir les paramètres par défaut.
Utilisez gcloud config pour définir individuellement l'ID, la zone et la région de votre projet.

Utiliser gcloud init

Si le message d'erreur One of [--zone, --region] must be supplied: Please specify location s'affiche, effectuez les tâches ci-dessous.

Exécutez gcloud init et suivez les instructions :
```
gcloud init
```
Si vous utilisez SSH sur un serveur distant, utilisez l'option --console-only pour empêcher la commande d'ouvrir un navigateur :
```
gcloud init --console-only
```
Suivez les instructions pour autoriser gcloud à utiliser votre compte Google Cloud.
Créez ou sélectionnez une configuration.
Choisissez un projet Google Cloud.
Choisissez une zone Compute Engine par défaut pour les clusters zonaux ou une région pour les clusters régionaux ou Autopilot.

Remarque : Vous pouvez remplacer ces paramètres par défaut dans les commandes gcloud à l'aide des options --project, --zone et --region.

Utiliser gcloud config

Définissez votre ID de projet par défaut :
```
gcloud config set project PROJECT_ID
```
Si vous utilisez des clusters zonaux, définissez votre zone de calcul par défaut :
```
gcloud config set compute/zone COMPUTE_ZONE
```
Si vous utilisez des clusters Autopilot ou régionaux, définissez votre région de calcul par défaut :
```
gcloud config set compute/region COMPUTE_REGION
```
Mettez à jour gcloud vers la dernière version :
```
gcloud components update
```

Remarque : Vous pouvez remplacer ces paramètres par défaut dans les commandes gcloud à l'aide des options --project, --zone et --region.

Créer un objet Deployment

Le fichier manifeste suivant décrit un déploiement qui exécute 3 instances dupliquées d'une application Hello World.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-app
spec:
  selector:
    matchLabels:
      app: hello
  replicas: 3
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
      - name: hello
        image: "us-docker.pkg.dev/google-samples/containers/gke/hello-app:2.0"

Le code source et le fichier Dockerfile de cet exemple d'application sont disponibles sur GitHub. Comme aucune variable d'environnement PORT n'est spécifiée, les conteneurs écoutent sur le port par défaut 8080.

Pour créer l'objet Deployment, créez le fichier my-deployment.yaml à partir du fichier manifeste, puis exécutez la commande suivante dans la fenêtre de votre terminal ou votre interface système :

kubectl apply -f my-deployment.yaml

Créer un équilibreur de charge TCP interne

Dans les sections suivantes, nous expliquons comment créer un équilibreur de charge TCP interne à l'aide d'un objet Service.

Écrire le fichier de configuration de l'objet Service

Dans l'exemple ci-dessous, un objet Service crée un équilibreur de charge TCP interne :

apiVersion: v1
kind: Service
metadata:
  name: ilb-service
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
  labels:
    app: hello
spec:
  type: LoadBalancer
  selector:
    app: hello
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP

Configuration minimale de l'objet Service

Le fichier manifeste doit contenir les éléments suivants :

name, qui est le nom de l'objet Service (dans cet exemple, ilb-service)
Annotation qui spécifie un équilibreur de charge TCP/UDP interne. L'annotation dépend de la version de votre cluster GKE. Pour GKE versions 1.17 et ultérieures, utilisez l'annotation networking.gke.io/load-balancer-type: "Internal". Pour les versions antérieures, utilisez l'annotation cloud.google.com/load-balancer-type: "Internal".
type: LoadBalancer
Un champ spec: selector, afin de spécifier les pods que l'objet Service doit cibler, par exemple app: hello
port, qui est le port sur lequel l'objet Service est exposé, et targetPort, qui est le port sur lequel les conteneurs écoutent

Déployer l'objet Service

Pour créer l'équilibreur de charge TCP interne, créez le fichier my-service.yaml à partir du fichier manifeste, puis exécutez la commande suivante dans la fenêtre de votre terminal ou votre interface système :

kubectl apply -f my-service.yaml

Inspecter l'objet Service

Après le déploiement, inspectez l'objet Service pour vérifier qu'il a été configuré correctement.

Pour obtenir des informations détaillées sur l'objet Service, exécutez la commande suivante :

kubectl get service ilb-service --output yaml

Dans le résultat, vous pouvez voir l'adresse IP de l'équilibreur de charge interne sous status.loadBalancer.ingress. Notez qu'elle est différente de la valeur de clusterIP. Dans cet exemple, l'adresse IP de l'équilibreur de charge est 10.128.15.193 :

apiVersion: v1
kind: Service
metadata:
  ...
  labels:
    app: hello
  name: ilb-service
  ...
spec:
  clusterIP: 10.0.9.121
  externalTrafficPolicy: Cluster
  ports:
  - nodePort: 30835
    port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    app: hello
  sessionAffinity: None
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 10.128.15.193

Tous les pods comportant le libellé app: hello sont membres de cet objet Service. Il s'agit des pods pouvant être les destinataires finaux des requêtes envoyées à votre équilibreur de charge interne.

Les clients appellent l'objet Service à l'aide de l'adresse IP loadBalancer et du port TCP spécifié dans le champ port de son fichier manifeste. La requête est transmise à l'un des pods membres du port TCP spécifié dans le champ targetPort. Ainsi, dans l'exemple précédent, un client appelle l'objet Service à l'adresse 10.128.15.193 sur le port TCP 80. La requête est transmise à l'un des pods membres sur le port TCP 8080. Notez que le pod membre doit avoir un conteneur qui écoute sur le port 8080.

La valeur nodePort de 30835 est superflue. Elle n'est pas pertinente pour votre équilibreur de charge interne.

Afficher la règle de transfert de l'équilibreur de charge

Un équilibreur de charge interne est mis en œuvre en tant que règle de transfert. La règle de transfert comporte un service de backend, qui possède un groupe d'instances.

L'adresse de l'équilibreur de charge interne, 10.128.15.193 dans l'exemple précédent, est identique à l'adresse de la règle de transfert. Pour afficher la règle de transfert qui met en œuvre votre équilibreur de charge interne, commencez par répertorier toutes les règles de transfert de votre projet :

gcloud compute forwarding-rules list --filter="loadBalancingScheme=INTERNAL"

Dans le résultat, recherchez la règle de transfert qui possède la même adresse que votre équilibreur de charge interne, 10.128.15.193 dans cet exemple.

NAME                          ... IP_ADDRESS  ... TARGET
...
aae3e263abe0911e9b32a42010a80008  10.128.15.193   us-central1/backendServices/aae3e263abe0911e9b32a42010a80008

Le résultat affiche le service de backend associé (ae3e263abe0911e9b32a42010a80008, dans cet exemple).

Décrivez le service de backend :

gcloud compute backend-services describe aae3e263abe0911e9b32a42010a80008 --region us-central1

Le résultat affiche le groupe d'instances associé (k8s-ig--2328fa39f4dc1b75, dans cet exemple) :

backends:
- balancingMode: CONNECTION
  group: .../us-central1-a/instanceGroups/k8s-ig--2328fa39f4dc1b75
...
kind: compute#backendService
loadBalancingScheme: INTERNAL
name: aae3e263abe0911e9b32a42010a80008
...

Fonctionnement de l'abstraction Service

Lorsqu'un paquet est géré par votre règle de transfert, il est transféré vers l'un de vos nœuds de cluster. Lorsque le paquet arrive sur le nœud de cluster, les adresses et le port sont les suivants :

Adresse IP de destination	Règle de transfert (10.128.15.193 dans cet exemple)
Port TCP de destination	Champ `port` du service (80 dans cet exemple)

Notez que la règle de transfert (soit votre équilibreur de charge interne) ne modifie pas l'adresse IP de destination ni le port de destination. À la place, les règles iptables du nœud de cluster acheminent le paquet vers un pod approprié. Les règles iptables remplacent l'adresse IP de destination par une adresse IP de pod et le port de destination par la valeur targetPort de l'objet Service (8080 dans cet exemple).

Vérifier l'équilibreur de charge TCP interne

Connectez-vous via SSH à une instance de VM et exécutez la commande suivante :

curl LOAD_BALANCER_IP

Remplacez LOAD_BALANCER_IP par votre adresse IP LoadBalancer Ingress.

La réponse affiche le résultat de hello-app :

Hello, world!
Version: 2.0.0
Hostname: hello-app-77b45987f7-pw54n

L'exécution de la commande à l'extérieur du même réseau VPC ou de la même région entraîne une erreur de dépassement de délai. Si vous configurez l'accès mondial, les clients de n'importe quelle région du même réseau VPC peuvent accéder à l'équilibreur de charge.

Effectuer un nettoyage

Vous pouvez supprimer les objets Deployment et Service à l'aide de kubectl delete ou de Cloud Console.

kubectl

Supprimer l'objet Deployment

Pour supprimer l'objet Deployment, exécutez la commande suivante :

kubectl delete deployment hello-app

Supprimer l'objet Service

Pour supprimer l'objet Service, exécutez la commande suivante :

kubectl delete service ilb-service

Console

Supprimer l'objet Deployment

Pour supprimer le déploiement, procédez comme suit :

Accédez à la page Charges de travail dans Cloud Console.

Accéder à la page Charges de travail
Sélectionnez le déploiement que vous souhaitez supprimer, puis cliquez sur Supprimer.
Lorsque vous êtes invité à confirmer l'opération, cochez la case Supprimer l'autoscaler horizontal de pods associé au déploiement sélectionné, puis cliquez sur Supprimer.

Supprimer l'objet Service

Pour supprimer le service, procédez comme suit :

Accédez à la page Services et entrées de Cloud Console.

Accéder à la page Services et entrées
Sélectionnez le service que vous souhaitez supprimer, puis cliquez sur Supprimer.
Lorsque vous êtes invité à confirmer votre choix, cliquez sur Supprimer.

Utiliser le sous-paramètre d'équilibreur de charge TCP/UDP interne

Le sous-paramètre de l'équilibreur de charge interne pour GKE améliore l'évolutivité de l'équilibreur de charge TCP/UDP interne en partitionnant les backends en groupes plus petits qui se chevauchent. Le sous-paramètre vous permet de configurer des équilibreurs de charge TCP/UDP internes sur des clusters comportant plus de 250 nœuds.

Vous pouvez activer le sous-paramètre lorsque vous créez un cluster ou en modifiant un cluster existant.

Architecture

Le sous-paramètre modifie le déploiement des équilibreurs de charge TCP/UDP internes. Sans sous-paramètre, le contrôleur GKE place tous les nœuds d'un cluster dans un ou plusieurs groupes d'instances zonaux non gérés, qui sont partagés par tous les équilibreurs de charge internes du cluster GKE. Par exemple, tous les équilibreurs de charge TCP/UDP internes dans un cluster GKE à 40 nœuds partagent les mêmes 40 nœuds que les backends.

Avec le sous-paramètre d'équilibreur de charge TCP/UDP interne, le contrôleur GKE place les nœuds dans GCE_VM_IP zonal network endpoint groups (NEGs). Contrairement aux groupes d'instances, les nœuds peuvent appartenir à plusieurs NEG zonaux et chacun des NEG zonaux peut être référencé par un équilibreur de charge TCP/UDP interne. Le contrôleur GKE crée un NEG pour chaque service à l'aide d'un sous-ensemble de nœuds GKE en tant que membres. Par exemple, un cluster GKE de 40 nœuds peut comporter un équilibreur de charge TCP/UDP interne avec 25 nœuds dans un NEG zonal backend, et un autre équilibreur de charge TCP/UDP interne avec 25 nœuds dans un autre backend NEG zonal.

Le schéma suivant montre deux services différents dans un cluster sur lequel un sous-paramètre d'équilibreur de charge TCP/UDP interne est activé. Chaque service dispose de deux pods programmés sur trois nœuds. Google Cloud crée un NEG GCE_VM_IP pour chaque service. Le contrôleur GKE sélectionne un sous-ensemble de nœuds du cluster comme membres du NEG et utilise l'adresse IP de chaque nœud sélectionné comme points de terminaison.

Adresses IP virtuelles de nœud utilisées comme points de terminaison pour les services lors du sous-paramétrage. — **Schéma** : exemple de sous-paramétrage dans un cluster avec des services.

Sélection du sous-paramètrage des nœuds du backend

Lorsque vous activez le sous-paramétrage pour votre cluster, le contrôleur GKE détermine automatiquement comment sous-paramétrer les nœuds. Vous pouvez utiliser la valeur Local ou Cluster pour externalTrafficPolicy, mais la sélection du sous-paramétrage des nœuds du backend diffère pour chaque valeur.

externalTrafficPolicy: Cluster : les requêtes des clients sont envoyées à l'adresse IP du nœud et équilibrées en charge vers un pod de backend. Le pod de backend peut se trouver sur le même nœud ou sur un nœud différent. Le contrôleur GKE sélectionne un sous-ensemble aléatoire de 25 nœuds. Cette distribution permet d'éviter les points de défaillance uniques. Si les pods de backend sont hébergés sur plus de 25 nœuds, ils reçoivent toujours le trafic, mais ce trafic entre dans le cluster via un maximum de 25 nœuds faisant partie du sous-ensemble. Si le cluster comporte moins de 25 nœuds, tous les nœuds font partie du sous-ensemble.
externalTrafficPolicy: Local : les requêtes des clients sont envoyées à l'adresse IP du nœud et la charge n'est équilibrée que pour les pods de backend exécutés sur le même nœud. Par conséquent, le sous-ensemble de nœuds de backend ne contient que des nœuds qui hébergent l'un des pods des objets de service. La taille du sous-ensemble correspond au nombre de nœuds qui hébergent des pods depuis ce service, avec un maximum de 250 nœuds. Ne programmez pas ces services sur plus de 250 nœuds, car les nœuds supplémentaires ne reçoivent pas de trafic de l'équilibreur de charge.

Conditions requises et limites

Le sous-paramètre pour GKE présente les exigences et limitations suivantes :

Vous pouvez activer le sous-paramètre dans les clusters nouveaux et existants dans les versions 1.18.19-gke.1400 et ultérieures de GKE.
Le module complémentaire HttpLoadBalancing doit être activé sur le cluster. Il est activé par défaut. Un cluster sur lequel ce module complémentaire est désactivé ne peut pas utiliser le sous-paramètre.
SDK Cloud version 345.0.0 et versions ultérieures.
Le sous-paramètre ne peut pas être utilisé avec les clusters Autopilot.
Les quotas des groupes de points de terminaison du réseau s'appliquent. Google Cloud crée un NEG par équilibreur de charge TCP/UDP interne par zone.
Des quotas pour les règles de transfert, services de backend et autres ressources réseau s'appliquent.
Le sous-paramètre ne peut pas être désactivé une fois qu'il est activé dans un cluster.
Le sous-paramètre ne peut pas être utilisé avec l'annotation pour partager des services de backend, alpha.cloud.google.com/load-balancer-backend-share.

Activer le sous-paramètre d'équilibreur de charge interne dans un nouveau cluster

Vous pouvez créer un cluster avec un sous-paramètre d'équilibreur de charge interne activé à l'aide de l'outil de ligne de commande gcloud ou de Cloud Console :

Console

Accédez à la page Google Kubernetes Engine dans Cloud Console.

Accéder à Google Kubernetes Engine
Cliquez sur Créer.
Configurez le cluster selon vos besoins.
Dans le volet de navigation, sous Cluster, cliquez sur Réseau.
Cochez la case Activer le sous-paramètre pour les équilibreurs de charge internes L4.
Cliquez sur Create (Créer).

gcloud

gcloud container clusters create CLUSTER_NAME \
    --cluster-version=VERSION \
    --enable-l4-ilb-subsetting \
    --region=COMPUTE_REGION

Remplacez l'élément suivant :

CLUSTER_NAME : nom du nouveau cluster
VERSION : version de GKE, qui doit être 1.18.19-gke.1400 ou ultérieure. Vous pouvez également utiliser l'option --release-channel pour sélectionner une version disponible. La version disponible doit correspondre à la version 1.18.19-gke.1400 ou ultérieure par défaut.
COMPUTE_REGION : région de calcul du cluster.

Activer le sous-paramètre d'équilibreur de charge interne dans un cluster existant

Vous pouvez activer le sous-paramètre d'équilibrage de charge interne pour un cluster existant à l'aide de l'outil gcloud ou de Google Cloud Console. Vous ne pouvez pas désactiver le sous-paramètre d'équilibrage de charge interne après l'avoir activé dans un cluster.

Console

Dans Cloud Console, accédez à la page Google Kubernetes Engine.

Accéder à Google Kubernetes Engine
Dans la liste des clusters, cliquez sur le nom du cluster que vous souhaitez modifier.
Sous Mise en réseau, à côté du champ Sous-paramètre pour les équilibreurs de charge internes L4, cliquez sur Activer le sous-paramètre pour les équilibreurs de charge internes L4.
Cochez la case Activer le sous-paramètre pour les équilibreurs de charge internes L4.
Cliquez sur Save Changes (Enregistrer les modifications).

gcloud

gcloud container clusters update CLUSTER_NAME \
    --enable-l4-ilb-subsetting

Remplacez les éléments suivants :

CLUSTER_NAME : nom du cluster.

Vérifier le sous-paramètre de l'équilibreur de charge interne

Pour vérifier que le sous-paramètre de l'équilibreur de charge interne fonctionne correctement pour votre cluster, procédez comme suit :

Déployez une charge de travail.

Le fichier manifeste suivant décrit un déploiement qui exécute un exemple d'image de conteneur d'application Web. Enregistrez le manifeste sous le nom ilb-deployment.yaml :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ilb-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: ilb-deployment
  template:
    metadata:
      labels:
        app: ilb-deployment
    spec:
      containers:
      - name: hello-app
        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0

Appliquez le fichier manifeste à votre cluster :
```
kubectl apply -f ilb-deployment.yaml
```

Créez un service.

Le fichier manifeste ci-dessous décrit un service qui crée un équilibreur de charge interne sur le port TCP 8080. Enregistrez le manifeste sous le nom ilb-svc.yaml :

apiVersion: v1
kind: Service
metadata:
  name: ilb-svc
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
spec:
  type: LoadBalancer
  externalTrafficPolicy: Cluster
  selector:
    app: ilb-deployment
  ports:
  - name: tcp-port
    protocol: TCP
    port: 8080
    targetPort: 8080

Appliquez le fichier manifeste à votre cluster :
```
kubectl apply -f ilb-svc.yaml
```
Inspectez le service :
```
kubectl get svc ilb-svc -o=jsonpath="{.metadata.annotations.cloud\.google\.com/neg-status}"
```
Le résultat ressemble à ce qui suit :
```
{"network_endpoint_groups":{"0":"k8s2-knlc4c77-default-ilb-svc-ua5ugas0"},"zones":["us-central1-c"]}
```
La réponse indique que GKE a créé un groupe de points de terminaison du réseau nommé k8s2-knlc4c77-default-ilb-svc-ua5ugas0. Cette annotation est présente dans les services de type LoadBalancer qui utilisent un sous-paramètre GKE et ne figure pas dans les services qui n'utilisent pas de sous-paramètre.

Dépannage

Pour déterminer la liste de nœuds d'un sous-ensemble d'un service, exécutez la commande suivante :

gcloud compute network-endpoint-groups list-network-endpoints NEG_NAME \
    --zone=COMPUTE_ZONE

Remplacez l'élément suivant :

NEG_NAME : nom du groupe de points de terminaison du réseau créé par le contrôleur GKE.
COMPUTE_ZONE : zone de calcul du groupe de points de terminaison du réseau à utiliser.

Pour déterminer la liste des nœuds sains pour un équilibreur de charge TCP/UDP interne, utilisez la commande suivante :

gcloud compute backend-services get-health SERVICE_NAME \
    --region=COMPUTE_REGION

Remplacez l'élément suivant :

SERVICE_NAME : nom du service de backend. Cette valeur est identique au nom du groupe de points de terminaison du réseau créé par le contrôleur GKE.
COMPUTE_REGION : région de calcul du service de backend à utiliser.

Problèmes connus

Délai d'expiration de la connexion toutes les 10 minutes

Les services LoadBalancer internes créés avec le sous-paramètre peuvent observer des interruptions du trafic environ toutes les 10 minutes. Ce bug a été corrigé dans les versions suivantes :

1.18.19-gke.1700 et versions ultérieures
1.19.10-gke.1000 et versions ultérieures
1.20.6-gke.1000 et versions ultérieures

Créer un équilibreur de charge TCP/UDP interne avec Private Service Connect

En tant que producteur de services, vous pouvez utiliser des rattachements de service pour mettre vos services à la disposition des clients de services d'autres réseaux VPC via Private Service Connect. Vous pouvez créer, gérer et supprimer des rattachements de service à l'aide d'une ressource personnalisée ServiceAttachment.

Conditions requises et limites

Des limites s'appliquent à Private Service Connect.
Vous pouvez créer un rattachement de service dans les versions 1.21.4-gke.300 et ultérieures de GKE.
Vous ne pouvez pas utiliser le même sous-réseau dans plusieurs configurations de rattachement de service.
Vous devez créer un service GKE qui utilise un équilibreur de charge TCP/UDP interne.
Vous ne pouvez pas créer de rattachement de service dans des clusters Autopilot.
Vous ne pouvez pas créer de rattachement de service dans des clusters GKE pour lesquels le sous-paramètre d'équilibreur de charge TCP/UDP interne est activé.

Créer un rattachement de service

Créez un sous-réseau.

Vous devez créer un sous-réseau pour chaque ServiceAttachment.
```
gcloud beta compute networks subnets create SUBNET_NAME \
    --project PROJECT_ID \
    --network NETWORK_NAME \
    --region REGION \
    --range SUBNET_RANGE \
    --purpose PRIVATE_SERVICE_CONNECT
```
Remplacez les éléments suivants :
- SUBNET_NAME : nom du nouveau sous-réseau.
- PROJECT_ID : ID de votre projet Google Cloud.
- NETWORK_NAME : nom du réseau VPC utilisé pour le sous-réseau.
- REGION : région du nouveau sous-réseau. Vous devez utiliser la même région que le service que vous créez.
- SUBNET_RANGE : plage d'adresses IP à utiliser pour le sous-réseau.

Déployez une charge de travail.

Le fichier manifeste suivant décrit un déploiement qui exécute un exemple d'image de conteneur d'application Web. Enregistrez le manifeste sous le nom my-deployment.yaml :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: psc-ilb
spec:
  replicas: 3
  selector:
    matchLabels:
      app: psc-ilb
  template:
    metadata:
      labels:
        app: psc-ilb
    spec:
      containers:
      - name: whereami
        image: gcr.io/google-samples/whereami:v1.2.1
        ports:
          - name: http
            containerPort: 8080
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
            scheme: HTTP
          initialDelaySeconds: 5
          timeoutSeconds: 1

Appliquez le fichier manifeste à votre cluster :
```
kubectl apply -f my-deployment.yaml
```
Créer un service Le fichier manifeste suivant décrit un service qui crée un équilibreur de charge TCP/UDP interne sur le port TCP 8080. Enregistrez le manifeste sous le nom my-service.yaml :
```
 apiVersion: v1
 kind: Service
 metadata:
   name: SERVICE_NAME
   annotations:
     cloud.google.com/load-balancer-type: "Internal"
 spec:
   type: LoadBalancer
   selector:
     app: psc-ilb
   ports:
   - port: 80
     targetPort: 8080
     protocol: TCP
```
Remplacez les éléments suivants :
- SERVICE_NAME : nom du nouveau service.
Appliquez le fichier manifeste à votre cluster :
```
kubectl apply -f my-service.yaml
```
Créez des ServiceAttachment.

Le fichier manifeste suivant décrit un ServiceAttachment qui expose le service que vous avez créé aux clients de service. Enregistrez le manifeste sous le nom my-psc.yaml :
```
apiVersion: networking.gke.io/v1beta1
kind: ServiceAttachment
metadata:
 name: SERVICE_ATTACHMENT_NAME
 namespace: default
spec:
 connectionPreference: ACCEPT_AUTOMATIC
 natSubnets:
 - SUBNET_NAME
 proxyProtocol: false
 resourceRef:
   kind: Service
   name: SERVICE_NAME
```
Remplacez les éléments suivants :
- SERVICE_ATTACHMENT_NAME : nom du nouveau rattachement de service.
Remarque : La ressource ServiceAttachment présentera des événements d'erreur jusqu'à ce que le contrôleur GKE crée l'équilibreur de charge TCP/UDP interne défini. par le service. Une fois l'équilibreur de charge TCP/UDP interne provisionné, les erreurs ne sont plus publiées.

Le champ ServiceAttachment comporte les champs suivants :
- connectionPreference : préférence de connexion qui détermine la façon dont les clients se connectent au service. Vous pouvez utiliser l'approbation automatique du projet à l'aide de ACCEPT_AUTOMATIC ou l'approbation explicite du projet à l'aide de ACCEPT_MANUAL. Pour plus d'informations, consultez la page Publier des services à l'aide de Private Service Connect.
- natSubnets : liste des noms de ressources de sous-réseau à utiliser pour le rattachement de service.
- proxyProtocol : si ce paramètre est défini sur "true", l'adresse IP source du consommateur et l'ID de connexion Private Service Connect sont disponibles dans les requêtes. Ce champ est facultatif et est défini par défaut sur "false" si ce champ n'est pas renseigné.
- consumerAllowList : liste des projets de consommateur autorisés à se connecter au ServiceAttachment. Ce champ ne peut être utilisé que lorsque la valeur de connectionPreference est définie sur ACCEPT_MANUAL. Pour plus d'informations sur ce champ, consultez la section Publier des services à l'aide de Private Service Connect.
  - project : ID ou numéro du projet client.
  - connectionLimit : limite de connexion du projet client. Ce champ est facultatif.
  - forceSendFields : noms des champs à inclure dans les requêtes API. Ce champ est facultatif.
  - nullFields : noms des champs à inclure dans les requêtes API avec une valeur nulle. Ce champ est facultatif.
- consumerRejectList : liste des ID ou numéros du projet client qui ne sont pas autorisés à se connecter à ServiceAttachment. Ce champ ne peut être utilisé que lorsque la valeur de connectionPreference est définie sur ACCEPT_MANUAL. Pour plus d'informations sur ce champ, consultez la section Publier des services à l'aide de Private Service Connect.
- resourceRef : référence à la ressource Kubernetes.
  - kind : type de ressource Kubernetes. Vous devez utiliser Service.
  - name : nom de la ressource Kubernetes qui doit se trouver dans le même espace de noms que l'équilibreur de charge TCP/UDP interne.
Remarque : Une fois qu'un rattachement de service est connecté à un équilibreur de charge TCP/UDP interne, vous ne pouvez pas supprimer ni mettre à jour l'équilibreur de charge TCP/UDP interne. Si vous tentez de supprimer ou de mettre à jour l'équilibreur de charge TCP/UDP interne, un message d'erreur s'affiche. Pour en savoir plus, consultez la section Dépannage.
Appliquez le fichier manifeste à votre cluster :
```
kubectl apply -f my-psc.yaml
```

Vérifiez que le contrôleur Private Service Connect a créé le rattachement de service :

gcloud beta compute service-attachments list

La sortie affiche un rattachement de service avec un nom généré automatiquement :

NAME        REGION       PRODUCER_FORWARDING_RULE          CONNECTION_PREFERENCE
k8s1-sa-... us-central1  a3fea439c870148bdba5e59c9ea9451a  ACCEPT_AUTOMATIC

Afficher un rattachement de service

Vous pouvez afficher les détails d'un ServiceAttachment à l'aide de la commande suivante :

kubectl describe serviceattachment SERVICE_ATTACHMENT_NAME /
    --project PROJECT_ID

Le résultat ressemble à ce qui suit :

 kubectl describe serviceattachment foo-sa
Name:        <sa-name>
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1beta1
Kind:         ServiceAttachment
Metadata:
  ...
Status:
  Forwarding Rule URL:      https://www.googleapis.com/compute/beta/projects/<project>/regions/<region>/forwardingRules/<fr-name>
  Last Modified Timestamp:  2021-07-08T01:32:39Z
  Service Attachment URL:   https://www.googleapis.com/compute/beta/projects/<projects>/regions/<region>/serviceAttachments/<gce-service-attachment-name>
Events:                     <none>

Utiliser un rattachement de service

Pour utiliser votre service à partir d'un autre projet, procédez comme suit :

Obtenez l'URL du ServiceAttachment :

kubectl get serviceattachment SERVICE_ATTACHMENT_NAME -o=jsonpath="{.status.serviceAttachmentURL}"

Le résultat ressemble à ce qui suit :

  serviceAttachmentURL: https://www.googleapis.com/compute/alpha/projects/<project>/region/<region>/serviceAttachments/k8s1-...my-sa

Créez un point de terminaison Private Service Connect à l'aide de l'URL du ServiceAttachment.

Vérifiez que vous pouvez vous connecter au service que vous avez déployé dans le projet producteur en utilisant une commande curl à partir d'une VM du projet client :

curl PSC_IP_ADDRESS

Remplacez PSC_IP_ADDRESS par l'adresse IP de la règle de transfert dans le projet du client.

Le résultat ressemble à ce qui suit :

{
  "cluster_name":"cluster",
  "host_header":"10.128.15.200",
  "node_name":"gke-psc-default-pool-be9b6e0e-dvxg.c.gke_project.internal",
  "pod_name":"foo-7bf648dcfd-l5jf8",
  "pod_name_emoji":"👚",
  "project_id":"gke_project",
  "timestamp":"2021-06-29T21:32:03",
  "zone":"us-central1-c"
}

Mettre à jour un rattachement de service

Pour mettre à jour un élément ServiceAttachment, procédez comme suit :

Modifiez le manifeste ServiceAttachment dans my-psc.yaml :

apiVersion: networking.gke.io/v1beta1
kind: ServiceAttachment
metadata:
  name: my-sa
  namespace: default
spec:
  connectionPreference: ACCEPT_AUTOMATIC
  natSubnets:
  - my-nat-subnet
  proxyProtocol: false
  resourceRef:
    kind: Service
    name: ilb-service

Appliquez le fichier manifeste à votre cluster :
```
kubectl apply -f my-psc.yaml
```

Nettoyer

Vous ne pouvez pas supprimer un équilibreur de charge TCP/UDP interne connecté à un rattachement de service. Vous devez supprimer le rattachement de service et le service GKE séparément.

Supprimez le rattachement de service :
```
kubectl delete serviceattachment SERVICE_ATTACHMENT_NAME --wait=false
```
Cette commande marque la suppression du rattachement de service, mais la ressource continue d'exister. Vous pouvez également attendre la fin de la suppression en omettant l'option --wait.
Supprimez le service :
```
kubectl delete svc SERVICE_NAME
```

Supprimez le sous-réseau :

gcloud compute networks subnets delete SUBNET_NAME

Dépannage

Vous pouvez afficher les messages d'erreur à l'aide de la commande suivante :

kubectl get events -n NAMESPACE

Remplacez NAMESPACE par l'espace de noms de l'équilibreur de charge TCP/UDP interne.

Un message d'erreur semblable à celui-ci s'affiche si vous essayez de supprimer un équilibreur de charge TCP/UDP interne utilisé par un rattachement de service. Vous devez supprimer ServiceAttachment pour pouvoir supprimer l'équilibreur de charge TCP/UDP interne.

Error syncing load balancer: failed to ensure load balancer: googleapi:
Error 400: The forwarding_rule resource '<fwd-rule-URL>' is already being used
by '<svc-attachment-URL>', resourceInUseByAnotherResource.

Paramètres de l'objet Service

Pour en savoir plus sur les paramètres des équilibreurs de charge que vous pouvez configurer, consultez la page Configurer l'équilibrage de charge TCP/UDP. De plus, les services LoadBalancer internes sont compatibles avec les paramètres supplémentaires suivants :

Fonctionnalité	Résumé	Champ de service	Compatibilité de la version de GKE
Sous-réseau d'équilibreur de charge	Spécifie le sous-réseau à partir duquel l'équilibreur de charge doit provisionner automatiquement une adresse IP.	`metadata:annotations: networking.gke.io/internal-load-balancer-subnet`	En version bêta dans GKE 1.17 et versions ultérieures, et 1.16.8-gke.10 et versions ultérieures En disponibilité générale dans GKE 1.17.9-gke.600 et versions ultérieures
Accès mondial	Autorise l'adresse IP virtuelle de l'équilibreur de charge TCP/UDP interne à être accessible par les clients dans toutes les régions Google Cloud	`metadata:annotations: networking.gke.io/internal-load-balancer-allow-global-access`	En version bêta dans GKE 1.16 et versions ultérieures En disponibilité générale dans GKE 1.17.9-gke.600 et versions ultérieures

Sous-réseau d'équilibreur de charge

Par défaut, GKE déploie un équilibreur de charge TCP/UDP interne à l'aide de la plage du sous-réseau de nœud. Le sous-réseau peut être spécifié par l'utilisateur pour chaque objet Service à l'aide de l'annotation networking.gke.io/internal-load-balancer-subnet. Cela permet de mettre en place des pare-feu séparés pour les adresses IP d'équilibreurs de charge internes et pour les adresses IP de nœuds, ou de partager le même sous-réseau de l'objet Service sur plusieurs clusters GKE. Ce paramètre n'est pertinent que pour les services d'équilibreur de charge TCP/UDP internes.

Le sous-réseau doit exister avant d'être référencé par la ressource Service, car GKE ne gère pas le cycle de vie du sous-réseau lui-même. Le sous-réseau doit également se trouver dans le même VPC et la même région que le cluster GKE. Dans cette étape, il est créé hors bande depuis GKE :

gcloud compute networks subnets create gke-vip-subnet \
    --network=default \
    --range=10.23.0.0/24 \
    --region=us-central1

La définition de l'objet Service suivante utilise internal-load-balancer-subnet pour référencer le sous-réseau par son nom. Par défaut, une adresse IP disponible du sous-réseau est automatiquement sélectionnée. Vous pouvez également spécifier loadBalancerIP, mais il doit faire partie du sous-réseau référencé.

Il existe plusieurs façons de partager ce sous-réseau d'équilibreur de charge interne pour exécuter différents cas d'utilisation :

Plusieurs sous-réseaux pour des groupes d'objets Service dans le même cluster
Un seul sous-réseau pour tous les objets Service d'un cluster
Un seul sous-réseau partagé entre plusieurs clusters et plusieurs objets Service

apiVersion: v1
kind: Service
metadata:
  name: ilb-service
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
    networking.gke.io/internal-load-balancer-subnet: "gke-vip-subnet"
  labels:
    app: hello
spec:
  type: LoadBalancer
  loadBalancerIP: 10.23.0.15
  selector:
    app: hello
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP

Accès mondial

L'accès mondial est un paramètre facultatif pour les services LoadBalancer internes. Il permet aux clients de n'importe quelle région de votre réseau VPC d'accéder à l'équilibreur de charge TCP/UDP interne. Sans accès mondial, le trafic provenant des clients de votre réseau VPC doit se trouver dans la même région que l'équilibreur de charge. L'accès mondial permet aux clients de n'importe quelle région d'accéder à l'équilibreur de charge. Les instances backend doivent toujours se trouver dans la même région que l'équilibreur de charge.

L'accès mondial est activé pour chaque objet Service à l'aide de l'annotation suivante : networking.gke.io/internal-load-balancer-allow-global-access: "true".

L'accès mondial n'est pas compatible avec les anciens réseaux. Les coûts normaux du trafic interrégional s'appliquent lorsque l'accès mondial est utilisé entre les régions. Pour plus d'informations sur la tarification du réseau pour ce qui est des sorties entre régions, consultez la page Tarifs du réseau. L'accès mondial est disponible en version bêta sur les clusters GKE 1.16 et versions ultérieures, et est disponible pour tous les utilisateurs sur la version 1.17.9-gke.600 et versions ultérieures.

Pour les clients sur site, l'accès mondial leur permet d'accéder à l'équilibreur de charge à l'aide de Cloud VPN ou de Cloud Interconnect (VLAN) dans n'importe quelle région. Pour en savoir plus, consultez la section Utiliser Cloud VPN et Cloud Interconnect.

Adresse IP partagée

L'équilibreur de charge TCP/UDP interne permet le partage d'une adresse IP virtuelle entre plusieurs règles de transfert. Cela permet d'augmenter le nombre de ports simultanés sur la même adresse IP ou d'accepter le trafic UDP et TCP sur la même adresse IP. Elle autorise jusqu'à 50 ports exposés par adresse IP. Les adresses IP partagées sont compatibles de manière native sur les clusters GKE avec des services LoadBalancer internes. Lors du déploiement, le champ loadBalancerIP du service indique l'adresse IP à partager entre les services.

Limites

Une adresse IP partagée pour plusieurs équilibreurs de charge présente les limitations et les capacités suivantes :

Chaque service (ou règle de transfert) peut avoir un maximum de cinq ports.
Un maximum de dix services (règles de transfert) peuvent partager une adresse IP. Cela entraîne un maximum de 50 ports par adresse IP partagée.
Les tuples de protocole/port ne peuvent pas se chevaucher entre des services partageant la même adresse IP.
Une combinaison de services TCP uniquement et UDP uniquement est prise en charge sur la même adresse IP partagée. Cependant, vous ne pouvez pas exposer les ports TCP et UDP dans le même service.

Activer l'adresse IP partagée

Pour permettre à un service LoadBalancer interne d'utiliser une adresse IP commune, procédez comme suit :

Créez une adresse IP interne statique avec --purpose SHARED_LOADBALANCER_VIP. Une adresse IP doit être créée dans ce but afin d'en permettre le partage. Si vous créez l'adresse IP interne statique dans un VPC partagé, vous devez créer l'adresse IP dans le même projet de service que l'instance qui utilisera l'adresse IP, même si la valeur de l'adresse IP proviendra de la plage d'adresses IP disponibles dans un sous-réseau partagé sélectionné du réseau VPC partagé. Pour en savoir plus, reportez-vous à la section Réserver une adresse IP interne statique de la page Provisionner un VPC partagé.
Déployez jusqu'à dix services LoadBalancer internes à l'aide de cette adresse IP statique dans le champ loadBalancerIP. Les équilibreurs de charge TCP/UDP internes sont rapprochés par le contrôleur de service GKE et déployés à l'aide de la même adresse IP d'interface.

L'exemple suivant montre comment effectuer cette opération pour prendre en charge plusieurs ports TCP et UDP avec la même adresse IP d'équilibreur de charge interne.

Créez une adresse IP statique dans la même région que votre cluster GKE. Le sous-réseau doit être le même que celui utilisé par l'équilibreur de charge, qui est par défaut le même que celui utilisé par les adresses IP des nœuds du cluster GKE.

Si votre cluster et le réseau VPC se trouvent dans le même projet :
```
gcloud compute addresses create IP_ADDR_NAME \
    --project=PROJECT_ID \
    --subnet=SUBNET \
    --address=IP_ADDRESS \
    --region=COMPUTE_REGION \
    --purpose=SHARED_LOADBALANCER_VIP
```
Si votre cluster se trouve dans un projet de service VPC partagé, mais utilise un réseau VPC partagé dans un projet hôte :
```
gcloud compute addresses create IP_ADDR_NAME \
    --project=SERVICE_PROJECT_ID \
    --subnet=projects/HOST_PROJECT_ID/regions/REGION/subnetworks/SUBNET \
    --address=IP_ADDRESS \
    --region=COMPUTE_REGION \
    --purpose=SHARED_LOADBALANCER_VIP
```
Remplacez l'élément suivant :
- IP_ADDR_NAME : nom de l'objet d'adresse IP.
- SERVICE_PROJECT_ID : ID du projet de service.
- PROJECT_ID : ID de votre projet (un seul projet).
- HOST_PROJECT_ID : ID du projet hôte de VPC partagé.
- COMPUTE_REGION : région de calcul contenant le sous-réseau partagé.
- ADDRESS : adresse IP interne non utilisée de la plage d'adresses IP principale du sous-réseau sélectionné. Si vous ne spécifiez pas d'adresse IP, Google Cloud sélectionne une adresse IP interne inutilisée dans la plage d'adresses IP principale du sous-réseau sélectionné. Pour déterminer une adresse sélectionnée automatiquement, vous devez exécuter gcloud compute addresses describe.
- SUBNET : nom du sous-réseau partagé.

Enregistrez la configuration de service TCP suivante dans un fichier nommé tcp-service.yaml, puis déployez-la sur votre cluster. Remplacez IP_ADDRESS par l'adresse IP que vous avez choisie à l'étape précédente.

apiVersion: v1
kind: Service
metadata:
  name: tcp-service
  namespace: default
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
spec:
  type: LoadBalancer
  loadBalancerIP: IP_ADDRESS
  selector:
    app: myapp
  ports:
  - name: 8001-to-8001
    protocol: TCP
    port: 8001
    targetPort: 8001
  - name: 8002-to-8002
    protocol: TCP
    port: 8002
    targetPort: 8002
  - name: 8003-to-8003
    protocol: TCP
    port: 8003
    targetPort: 8003
  - name: 8004-to-8004
    protocol: TCP
    port: 8004
    targetPort: 8004
  - name: 8005-to-8005
    protocol: TCP
    port: 8005
    targetPort: 8005

Appliquez la définition de service suivante à votre cluster :
```
kubectl apply -f tcp-service.yaml
```

Enregistrez la configuration de service UDP suivante dans un fichier nommé udp-service.yaml, puis déployez-la. Elle utilise également l'IP_ADDRESS que vous avez spécifiée à l'étape précédente.

apiVersion: v1
kind: Service
metadata:
  name: udp-service
  namespace: default
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
spec:
  type: LoadBalancer
  loadBalancerIP: IP_ADDRESS
  selector:
    app: my-udp-app
  ports:
  - name: 9001-to-9001
    protocol: UDP
    port: 9001
    targetPort: 9001
  - name: 9002-to-9002
    protocol: UDP
    port: 9002
    targetPort: 9002

Appliquez ce fichier à votre cluster :
```
kubectl apply -f udp-service.yaml
```

Vérifiez que l'adresse IP virtuelle est partagée entre les règles de transfert de l'équilibreur de charge en les répertoriant et en filtrant l'adresse IP statique. Cela montre qu'il existe une règle de transfert UDP et TCP, qui écoute sur sept ports différents sur l'IP_ADDRESS partagée, qui dans cet exemple est 10.128.2.98.

gcloud compute forwarding-rules list | grep 10.128.2.98
ab4d8205d655f4353a5cff5b224a0dde                         us-west1   10.128.2.98     UDP          us-west1/backendServices/ab4d8205d655f4353a5cff5b224a0dde
acd6eeaa00a35419c9530caeb6540435                         us-west1   10.128.2.98     TCP          us-west1/backendServices/acd6eeaa00a35419c9530caeb6540435

Tous les ports

Les règles de transfert internes acceptent jusqu'à cinq ports par règle de transfert ou un paramètre facultatif --ports=ALL qui transfère tous les ports de la règle de transfert.

Exigences

Tous les ports sur GKE présentent les exigences et limitations suivantes :

Disponible uniquement lorsque --enable-l4-ilb-subsetting est activé
Uniquement disponible avec les services d'équilibreur de charge interne
Accepte n'importe quel nombre de ports sur un maximum de 100 plages de ports contiguës

Le contrôleur GKE active automatiquement tous les ports de la règle de transfert lorsqu'un service dispose de plus de cinq ports. Par exemple, le fichier manifeste de service suivant comporte six ports configurés sur deux plages contiguës :

apiVersion: v1
kind: Service
metadata:
  name: all-ports
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
spec:
  type: LoadBalancer
  selector:
    app: myapp
  ports:
  - port: 8081
    targetPort: 8081
    name: 8081-to-8081
    protocol: TCP
  - port: 8082
    targetPort: 8082
    name: 8082-to-8082
    protocol: TCP
  - port: 8083
    targetPort: 8083
    name: 8083-to-8083
    protocol: TCP
  - port: 9001
    targetPort: 9001
    name: 9001-to-9001
    protocol: TCP
  - port: 9002
    targetPort: 9002
    name: 9002-to-9002
    protocol: TCP
  - port: 9003
    targetPort: 9003
    name: 9003-to-9003
    protocol: TCP

Le contrôleur GKE active tous les ports de la règle de transfert, car le service dispose de plus de cinq ports. Cependant, le contrôleur GKE crée uniquement des ports de pare-feu pour les ports spécifiés dans le service. Toutes les autres règles sont bloquées par des pare-feu VPC.

Restrictions applicables aux équilibreurs de charge TCP/UDP internes

Pour les clusters exécutant Kubernetes 1.7.4 ou version ultérieure, vous pouvez utiliser des équilibreurs de charge internes avec des sous-réseaux en mode personnalisé, en complément des sous-réseaux en mode automatique.
Les clusters exécutant Kubernetes 1.7.X et versions ultérieures acceptent l'utilisation d'une adresse IP réservée pour l'équilibreur de charge TCP/UDP interne si vous créez l'adresse IP réservée avec l'option --purpose définie sur SHARED_LOADBALANCER_VIP. Pour obtenir des instructions détaillées, consultez la page Activer l'adresse IP partagée. GKE ne conserve l'adresse IP d'un équilibreur de charge TCP/UDP interne que si le service fait référence à une adresse IP interne à cette fin. Sinon, GKE peut modifier l'adresse IP de l'équilibreur de charge (spec.loadBalancerIP) si le service est mis à jour (par exemple, si les ports sont modifiés).
Même si l'adresse IP de l'équilibreur de charge change (voir point précédent), spec.clusterIP reste constant.

Restrictions applicables aux équilibreurs de charge UDP internes

Les équilibreurs de charge UDP internes ne sont pas compatibles avec sessionAffinity: ClientIP.

Limites

Un service Kubernetes avec type: LoadBalancer et l'annotation networking.gke.io/load-balancer-type: Internal crée un équilibreur de charge interne qui cible le service Kubernetes. Le nombre de ces services est limité par le nombre de règles de transfert internes que vous pouvez créer dans un réseau VPC. Pour plus d'informations, consultez la section Par réseau.

Le nombre maximal de nœuds dans un cluster GKE avec un équilibreur de charge TCP/UDP interne dépend de la valeur de externalTrafficPolicy :

externalTrafficPolicy: Cluster : le backend de l'équilibreur de charge TCP/UDP interne utilise un maximum de 250 nœuds sélectionnés de manière aléatoire. Si le cluster comporte plus de 250 nœuds, tout le trafic de l'équilibreur de charge entre dans le cluster via les 250 nœuds et est transféré vers un pod correspondant sélectionné de manière aléatoire. Il n'est pas recommandé d'utiliser ce mode avec plus de 250 nœuds.
externalTrafficPolicy: Local : le backend de l'équilibreur de charge TCP/UDP interne utilise un maximum de 250 nœuds sélectionnés de manière aléatoire. Si aucun des 250 nœuds sélectionnés n'exécute les pods de backend pour le service d'équilibrage de charge TCP/UDP interne, les connexions à l'adresse IP LoadBalancer échouent. L'utilisation de ce mode avec plus de 250 nœuds n'est pas disponible.

Pour supprimer cette limitation, activez le sous-paramètre de l'équilibreur de charge interne.

Pour plus d'informations sur les limites de VPC, consultez la page Quotas et limites.

Utiliser un équilibreur de charge TCP/UDP interne

Présentation

Tarifs

Avant de commencer

Utiliser gcloud init

Utiliser gcloud config

Créer un objet Deployment

Créer un équilibreur de charge TCP interne

Écrire le fichier de configuration de l'objet Service

Configuration minimale de l'objet Service

Déployer l'objet Service

Inspecter l'objet Service

Afficher la règle de transfert de l'équilibreur de charge

Fonctionnement de l'abstraction Service

Vérifier l'équilibreur de charge TCP interne

Effectuer un nettoyage

kubectl

Supprimer l'objet Deployment

Supprimer l'objet Service

Console

Supprimer l'objet Deployment

Supprimer l'objet Service

Utiliser le sous-paramètre d'équilibreur de charge TCP/UDP interne

Architecture

Sélection du sous-paramètrage des nœuds du backend

Conditions requises et limites

Activer le sous-paramètre d'équilibreur de charge interne dans un nouveau cluster

Console

gcloud

Activer le sous-paramètre d'équilibreur de charge interne dans un cluster existant

Console

gcloud

Vérifier le sous-paramètre de l'équilibreur de charge interne

Dépannage

Problèmes connus

Délai d'expiration de la connexion toutes les 10 minutes

Créer un équilibreur de charge TCP/UDP interne avec Private Service Connect

Conditions requises et limites

Créer un rattachement de service

Afficher un rattachement de service

Utiliser un rattachement de service

Mettre à jour un rattachement de service

Nettoyer

Dépannage

Paramètres de l'objet Service

Sous-réseau d'équilibreur de charge

Accès mondial

Adresse IP partagée

Limites

Activer l'adresse IP partagée

Tous les ports

Exigences

Restrictions applicables aux équilibreurs de charge TCP/UDP internes

Restrictions applicables aux équilibreurs de charge UDP internes

Limites

Étape suivante