Cette page explique le fonctionnement d'Ingress pour les équilibreurs de charge d'application externes dans Google Kubernetes Engine (GKE). Vous pouvez également apprendre à configurer et utiliser Ingress pour l'équilibrage de charge externe.
Pour obtenir des informations générales sur l'utilisation de l'équilibrage de charge dans GKE, consultez la page Ingress pour les équilibreurs de charge d'application externes.
La mise en réseau Google Kubernetes Engine (GKE) est basée sur Cloud Load Balancing. Avec Cloud Load Balancing, une seule adresse IP Anycast permet au routage de déterminer le chemin le plus économique vers l'équilibreur de charge Google Cloud le plus proche.
Compatibilité des fonctionnalités Google Cloud
Vous pouvez utiliser un objet BackendConfig pour configurer un équilibreur de charge d'application externe afin d'utiliser des fonctionnalités telles que :
Un objet BackendConfig est une ressource personnalisée qui contient des informations de configuration concernant les fonctionnalités Google Cloud. Pour en savoir plus sur les fonctionnalités compatibles, consultez la page Configuration d'entrée.
Compatibilité avec WebSocket
Avec les équilibreurs de charge d'application externes, le protocole WebSocket fonctionne sans aucune configuration.
Si vous comptez utiliser le protocole WebSocket, il peut être opportun de spécifier un délai avant expiration supérieur à la valeur par défaut de 30 secondes. Pour le trafic WebSocket envoyé via un équilibreur de charge d'application externe Google Cloud, le délai avant expiration du service de backend est interprété comme la durée maximale pendant laquelle une connexion WebSocket peut rester ouverte, qu'elle soit inactive ou non.
Pour définir la valeur de délai avant expiration associée à un service de backend configuré via une entrée, créez un objet BackendConfig, puis incluez l'annotation beta.cloud.google.com/backend-config
dans le fichier manifeste du service.
Pour plus d'informations sur la configuration, consultez la section Délai avant expiration de réponse du service de backend.
Adresses IP statiques pour les équilibreurs de charge HTTPS
Lorsque vous créez un objet Entrée, vous obtenez une adresse IP externe stable que les clients peuvent utiliser pour accéder à vos services et, par la suite, à vos conteneurs en cours d'exécution. Cette adresse IP est stable dans le sens où elle dure toute la vie de l'objet Entrée. Si vous supprimez votre entrée pour en créer une autre à partir du même fichier manifeste, il n'est pas garanti que vous obteniez la même adresse IP externe.
Si vous souhaitez conserver une adresse IP permanente identique lors de la suppression de votre objet Ingress et de la création d'un nouvel objet, vous devez réserver une adresse IP externe statique globale. Incluez ensuite dans le manifeste de votre entrée une annotation donnant le nom de cette adresse IP statique réservée. Si vous modifiez un Ingress existant pour utiliser une adresse IP statique au lieu d'une adresse IP éphémère, GKE peut modifier l'adresse IP de l'équilibreur de charge lorsque GKE recrée la règle de transfert de l'équilibreur de charge.
Par exemple, supposons que vous ayez réservé une adresse IP externe statique globale nommée my-static-address
. Dans votre fichier manifeste d'entrée, incluez une annotation kubernetes.io/ingress.global-static-ip-name
comme illustré ci-dessous :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
annotations:
kubernetes.io/ingress.global-static-ip-name: my-static-address
Configurer HTTPS (TLS) entre le client et l’équilibreur de charge
Un équilibreur de charge HTTP(S) joue le rôle de proxy entre vos clients et votre application. Si vous souhaitez accepter les requêtes HTTPS émanant de vos clients, l'équilibreur de charge doit disposer d'un certificat lui permettant de leur prouver son identité. L'équilibreur de charge doit également disposer d'une clé privée pour mener à bien la négociation HTTPS.
Lorsque l'équilibreur de charge accepte une requête HTTPS d'un client, le trafic entre le client et l'équilibreur de charge est chiffré via TLS. Cependant, l'équilibreur de charge interrompt ce chiffrement TLS et transfère la requête sans chiffrement à l'application. Pour plus d'informations sur la manière de chiffrer le trafic entre l'équilibreur de charge et votre application, consultez la section HTTPS entre l'équilibreur de charge et votre application.
Vous pouvez utiliser des certificats SSL gérés par Google ou des certificats que vous gérez vous-même. Pour en savoir plus sur la création d'un objet Ingress utilisant des certificats gérés par Google, consultez la page Utiliser des certificats SSL gérés par Google.
Pour fournir à un équilibreur de charge HTTP(S) un certificat et une clé que vous avez créés vous-même, créez un objet Secret Kubernetes. L'objet Secret contient le certificat et la clé. Ajoutez l'objet Secret au champ tls
de votre fichier manifeste Ingress
, comme illustré dans l'exemple suivant :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress-2
spec:
tls:
- secretName: SECRET_NAME
rules:
- http:
paths:
- path: /*
pathType: ImplementationSpecific
backend:
service:
name: SERVICE_NAME
port:
number: 60000
Ce fichier manifeste comprend les valeurs suivantes :
SECRET_NAME
: nom de l'objet Secret que vous avez créé.SERVICE_NAME
: nom de votre service de backend.
Les modifications apportées aux objets Secret sont collectées périodiquement. Ainsi, si vous modifiez les données contenues dans l'objet Secret, ces modifications seront appliquées à l'équilibreur de charge en moins de 10 minutes.
Pour en savoir plus, consultez la section Utiliser plusieurs certificats SSL dans l'équilibrage de charge HTTPS avec un objet Ingress.
Pour sécuriser un objet Ingress chiffré HTTPS pour vos clusters GKE, consultez l'exemple Entrée sécurisée.
Désactiver HTTP
Si vous souhaitez que tout le trafic entre le client et l'équilibreur de charge HTTP(S) utilise le protocole HTTPS, vous pouvez désactiver HTTP en incluant l'annotation kubernetes.io/ingress.allow-http
dans le fichier manifeste d'entrée. Définissez la valeur de cette annotation sur "false"
.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress-2
annotations:
kubernetes.io/ingress.allow-http: "false"
spec:
tls:
- secretName: SECRET_NAME
...
Ces fichiers manifestes incluent SECRET_NAME
, qui correspond au nom de l'objet Secret que vous avez créé.
Certificats prépartagés pour les équilibreurs de charge
Au lieu d'utiliser des objets Secret Kubernetes pour fournir des certificats à l'équilibreur de charge pour l'interruption du trafic HTTP(S), vous pouvez utiliser des certificats précédemment importés dans votre projet Google Cloud. Pour plus d'informations, consultez les pages Utiliser des certificats prépartagés et Utiliser plusieurs certificats SSL dans l'équilibrage de charge HTTPS avec Ingress.
HTTPS (TLS) entre l'équilibreur de charge et votre application
Un équilibreur de charge HTTP(S) joue le rôle de proxy entre vos clients et votre application. Les clients peuvent utiliser HTTP ou HTTPS afin de communiquer avec le proxy de l'équilibreur de charge. La connexion du proxy de l'équilibreur de charge à votre application utilise le protocole HTTP par défaut. Toutefois, si votre application, qui s'exécute dans un pod GKE, est capable de recevoir des requêtes HTTPS, vous pouvez configurer l'équilibreur de charge pour qu'il utilise HTTPS lorsqu'il transfère les requêtes à votre application.
Pour configurer le protocole utilisé entre l'équilibreur de charge et votre application, incluez l'annotation cloud.google.com/app-protocols
dans votre fichier manifeste de service.
Ce fichier manifeste de service doit inclure type: NodePort
, sauf si vous utilisez l'équilibrage de charge natif en conteneurs.
Si vous utilisez l'équilibrage de charge natif en conteneurs, utilisez type: ClusterIP
.
Le fichier manifeste de service suivant spécifie deux ports. L'annotation indique que lorsqu'un équilibreur de charge HTTP(S) cible le port 80 du service, il doit utiliser le protocole HTTP. Lorsque l'équilibreur de charge cible le port 443 du service, il doit utiliser le protocole HTTPS.
Le fichier manifeste du service doit inclure une valeur name
dans l'annotation de port. Vous ne pouvez modifier le port de service qu'en vous référant à la name
qui lui est attribuée, et non par sa valeur targetPort
.
apiVersion: v1
kind: Service
metadata:
name: my-service-3
annotations:
cloud.google.com/app-protocols: '{"my-https-port":"HTTPS","my-http-port":"HTTP"}'
spec:
type: NodePort
selector:
app: metrics
department: sales
ports:
- name: my-https-port
port: 443
targetPort: 8443
- name: my-http-port
port: 80
targetPort: 50001
Étapes suivantes
Configurez un équilibreur de charge d'application externe en créant un objet Deployment, un objet Service et un objet Ingress.
Apprenez à exposer des applications à l'aide des services.
Lisez une présentation de la mise en réseau dans GKE.
En savoir plus sur la configuration des fonctionnalités d'entrée.
Découvrez comment activer les redirections HTTP vers HTTPS.