Cette page explique comment créer un équilibreur de charge TCP/UDP interne Compute Engine sur Google Kubernetes Engine.
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 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.
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
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: "gcr.io/google-samples/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'annotationcloud.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 exempleapp: hello
port
, qui est le port sur lequel l'objet Service est exposé, ettargetPort
, 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
Où load-balancer-ip est 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 l'objet Deployment, procédez comme suit :
Accédez au menu "Charges de travail" de Google Kubernetes Engine dans Cloud Console.
Sélectionnez le déploiement que vous souhaitez supprimer, puis cliquez sur delete 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 l'objet Service, procédez comme suit :
Accédez au menu "Services" de Google Kubernetes Engine dans Cloud Console.
Sélectionnez le service que vous souhaitez supprimer, puis cliquez sur delete Supprimer.
Lorsque vous êtes invité à confirmer votre choix, cliquez sur Supprimer.
Utiliser le sous-paramètre d'équilibreur de charge TCP/UDP interne (aperçu)
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 de l'équilibreur de charge TCP/UDP interne. 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.
Lorsque vous activez le sous-paramètre pour votre cluster, le contrôleur GKE détermine automatiquement la création des sous-ensembles de nœuds en fonction de externalTrafficPolicy
.
Lorsque la valeur est externalTrafficPolicy=Cluster
, le nombre maximal de backends dans le sous-ensemble est de 25 nœuds. Le contrôleur GKE sélectionne les nœuds en tant que membres d'un sous-ensemble de manière aléatoire.
Lorsque la valeur est externalTrafficPolicy=Local
, le nombre maximal de backends dans le sous-ensemble est de 250 nœuds. Le contrôleur GKE sélectionne des nœuds de manière aléatoire parmi les nœuds qui hébergent les pods du service. Si les pods de backend du service sont planifiés sur plus de 250 nœuds, un maximum de 250 nœuds et les pods s'exécutant sur ceux-ci reçoivent du trafic de l'équilibreur de charge interne.
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 et ultérieures de GKE.
- SDK Cloud version 22.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.
- 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
Pour créer un cluster avec le sous-paramètre d'équilibreur de charge interne activé, spécifiez l'option --enable-l4-ilb-subsetting
:
gcloud beta container clusters create CLUSTER_NAME \
--cluster-version VERSION \
--enable-l4-ilb-subsetting
{--zone ZONE_NAME | --region REGION_NAME}
Remplacez l'élément suivant :
CLUSTER_NAME
: nom du nouveau clusterVERSION
: version de GKE, qui doit être 1.18 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 ou ultérieure.ZONE_NAME
ouREGION_NAME
: l'emplacement du cluster. Ces arguments sont mutuellement exclusifs. Pour plus d'informations, consultez la section Types de clusters.
Activer le sous-paramètre d'équilibreur de charge interne dans un cluster existant
Pour activer le sous-paramètre d'équilibreur de charge interne dans un cluster existant, spécifiez l'option --enable-l4-ilb-subsetting
:
gcloud beta container clusters update CLUSTER_NAME \
--enable-l4-ilb-subsetting
Remplacez l'élément suivant :
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: gcr.io/google-samples/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 typeLoadBalancer
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 ZONE
Remplacez l'élément suivant :
NEG_NAME
: nom du groupe de points de terminaison du réseau créé par le contrôleur GKE.ZONE
: zone du groupe de points de terminaison du réseau à utiliser.
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 | Rend l'adresse IP virtuelle de l'équilibreur de charge TCP/UDP accessible par les clients de toutes les régions GCP. | metadata:annotations:
networking.gke.io/internal-load-balancer-allow-global-access |
En version bêta dans GKE 1.16+
En disponibilité générale dans GKE 1.17.9-gke.600+ |
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 LoadBalancer 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.
Adresse IP partagée (bêta)
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.
gcloud
Si vous réservez une adresse IP statique dans le projet contenant le réseau, exécutez la commande suivante :
gcloud compute addresses create IP_ADDR_NAME \ --project PROJECT_ID \ --subnet SUBNET \ --region REGION --purpose SHARED_LOADBALANCER_VIP
Si vous réservez une adresse IP statique dans le projet de service d'un VPC partagé, exécutez la commande suivante :
gcloud compute addresses create IP_ADDR_NAME \ --project SERVICE_PROJECT_ID \ --subnet projects/HOST_PROJECT_ID/regions/REGION/subnetworks/SUBNET \ --region REGION --purpose SHARED_LOADBALANCER_VIP
Remplacez l'élément suivant :
IP_ADDR_NAME
par le nom d'un objet d'adresse IP ;SERVICE_PROJECT_ID
par l'ID du projet de service ;PROJECT_ID
par l'ID de votre projet (un seul projet).HOST_PROJECT_ID
par l'ID du projet hôte du VPC partagé ;REGION
par la région hébergeant le sous-réseau partagé ;SUBNET
par le 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. Elle utilise l'adresse IP partagée10.128.2.98
.apiVersion: v1 kind: Service metadata: name: tcp-service namespace: default annotations: networking.gke.io/load-balancer-type: "Internal" spec: type: LoadBalancer loadBalancerIP: 10.128.2.98 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'adresse IP partagée10.128.2.98
.apiVersion: v1 kind: Service metadata: name: udp-service namespace: default annotations: networking.gke.io/load-balancer-type: "Internal" spec: type: LoadBalancer loadBalancerIP: 10.128.2.98 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'adresse IP partagée
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 (aperçu)
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:
cloud.google.com/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.3 et versions antérieures, vous ne pouvez utiliser que des équilibreurs de charge TCP/UDP internes avec des sous-réseaux en mode automatique. Par contre, pour les clusters exécutant Kubernetes 1.7.4 et versions ultérieures, vous pouvez utiliser des équilibreurs de charge internes avec des sous-réseaux en mode personnalisé, en plus des sous-réseaux en mode automatique.
- Pour les clusters exécutant Kubernetes 1.7.X ou versions ultérieures, lorsque l'adresse ClusterIP reste inchangée, les équilibreurs de charge TCP/UDP internes ne peuvent pas utiliser d'adresses IP réservées.
Le champ
spec.loadBalancerIP
peut tout de même être défini à l'aide d'une adresse IP inutilisée afin d'attribuer une adresse IP interne spécifique. Les modifications apportées aux ports, aux protocoles ou à l'affinité de session peuvent entraîner la modification de ces adresses IP.
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 interne est de 250. Pour supprimer cette limitation, activez le sous-paramètre de l'équilibreur de charge interne. Sinon, en cas d'activation de l'autoscaling sur votre cluster, assurez-vous qu'il ne dépasse pas 250 nœuds.
Pour plus d'informations sur les limites de VPC, consultez la page Quotas et limites.
Étape suivante
- Lisez la présentation du réseau GKE.
- Obtenez plus d'informations sur les équilibreurs de charge Compute Engine.
- Découvrez-en plus sur les adresses IP d'alias.
- Obtenez plus d'informations sur l'agent de masquage d'adresses IP.
- Familiarisez-vous avec la configuration des réseaux autorisés.