Exposer votre application déployée sur un OVHcloud Managed Kubernetes Service

Objectif

Dans ce tutoriel, nous expliquons comment utiliser les services sur OVHcloud Managed Kubernetes Service pour exposer votre application en faisant entrer le trafic externe dans votre cluster. Nous commencerons par lister les principales méthodes permettant d'exposer des services Kubernetes en dehors du cluster, avec leurs avantages et inconvénients. Puis nous verrons un exemple complet de déploiement d'un service LoadBalancer.

Avant de commencer

Ce tutoriel suppose que vous disposez déjà d'un cluster OVHcloud Managed Kubernetes fonctionnel et de connaissances de base sur son utilisation. Pour en savoir plus sur ces sujets, consultez le guide de démarrage rapide d'OVHcloud Managed Kubernetes Service.

Quelques notions : ClusterIP, NodePort, Ingress et LoadBalancer

Lorsque vous commencez à utiliser Kubernetes pour des applications réelles, l'une des premières questions est de savoir comment faire entrer le trafic externe dans votre cluster. La documentation officielle donne une explication complète mais plutôt aride sur le sujet ; ici, nous essayons d'expliquer les concepts de manière minimale, en ne donnant que les informations essentielles.

Il existe plusieurs façons d'acheminer le trafic externe vers votre cluster :

• Utiliser le proxy Kubernetes et ClusterIP : le ServiceType Kubernetes par défaut est ClusterIP, qui expose le Service sur une IP interne au cluster. Pour atteindre la ClusterIP depuis une source externe, vous pouvez ouvrir un proxy Kubernetes entre la source externe et le cluster. Cette méthode n'est généralement utilisée qu'en développement.

• Exposer les services en tant que NodePort : déclarer un Service de type NodePort expose le service sur l'IP de chaque nœud à un port statique (le NodePort). Vous pouvez alors accéder au Service depuis l'extérieur du cluster en appelant <NodeIp>:<NodePort>. Cette méthode peut être utilisée en production, avec certaines limitations.

• Exposer les services en tant que LoadBalancer : déclarer un Service de type LoadBalancer l'expose de manière externe à l'aide du load balancer d'un fournisseur cloud. Le fournisseur cloud provisionne un load balancer pour le Service et le mappe à son NodePort attribué automatiquement. C'est la méthode la plus largement utilisée dans les environnements de production.

Utiliser le proxy Kubernetes et ClusterIP

Le ServiceType Kubernetes par défaut est ClusterIP, qui expose le Service sur une IP interne au cluster. Pour atteindre la ClusterIP depuis un ordinateur externe, vous pouvez ouvrir un proxy Kubernetes entre cet ordinateur externe et le cluster.

Vous pouvez utiliser kubectl pour créer un tel proxy. Une fois le proxy actif, vous êtes directement connecté au cluster et pouvez utiliser l'IP interne des Services (ClusterIP).

Cette méthode n'est pas adaptée à un environnement de production, mais elle est intéressante pour le développement, le débogage ou d'autres opérations rapides.

Exposer les services en tant que NodePort

Déclarer un service de type NodePort expose le Service sur l'IP de chaque nœud à un port statique, le NodePort (un port fixe pour ce Service, dans la plage par défaut 30000-32767). Vous pouvez alors accéder au Service depuis l'extérieur du cluster en appelant <NodeIp>:<NodePort>. Chaque service que vous déployez en NodePort sera exposé sur son propre port, sur chaque nœud.

Il est plutôt fastidieux d'utiliser des Services NodePort en production. Comme vous utilisez des ports non standard, vous devez souvent mettre en place un load balancer externe qui écoute sur des ports standard et redirige le trafic vers <NodeIp>:<NodePort>.

$ kubectl cluster-info
Kubernetes control plane is running at https://xxxxxx.c1.gra9.k8s.ovh.net
CoreDNS is running at https://xxxxxxx.c1.gra9.k8s.ovh.net/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
Metrics-server is running at https://xxxxxx.c1.gra9.k8s.ovh.net/api/v1/namespaces/kube-system/services/https:metrics-server:/proxy

Exposer les services en tant que LoadBalancer

Déclarer un service de type LoadBalancer l'expose de manière externe à l'aide du load balancer d'un fournisseur cloud. Le fournisseur cloud provisionne un load balancer pour le Service et le mappe à son NodePort attribué automatiquement. La façon dont le trafic provenant de ce load balancer externe est acheminé vers les pods du Service dépend du fournisseur du cluster.

Le LoadBalancer est la meilleure option pour un environnement de production, avec deux réserves :

• Chaque Service de type LoadBalancer que vous déployez obtiendra sa propre IP.
• Le LoadBalancer est généralement facturé en fonction du nombre de services exposés, ce qui peut s'avérer coûteux.

Load balancers pris en charge

OVHcloud fournit actuellement deux types de load balancers pouvant être utilisés avec les Managed Kubernetes Services :

• Load Balancer for Managed Kubernetes, ce type de load balancer ne peut être utilisé que pour exposer des ressources d'un Managed Kubernetes Service. Il prend en charge jusqu'à 2000 requêtes/seconde et une bande passante de 200 Mbit/s. Veuillez noter que ce Loadbalancer sera obsolète à partir de la version 1.32 de Kubernetes pour MKS et des versions ultérieures.
• Public Load Balancer, basé sur le projet OpenStack Octavia, ce type de load balancer peut également être utilisé avec les instances OVHcloud standard. Vous pouvez choisir entre trois tailles de Load Balancer (S, M, L), offrant jusqu'à 40 000 requêtes/seconde et une bande passante de 2 Gbit/s. Parmi les autres avantages figurent la possibilité d'exposer votre Load Balancer de manière privée (private-to-private) ou publique (public-to-private ou public-to-public) à l'aide de Floating IP, la possibilité de collecter des métriques, ainsi que les protocoles TCP/UDP.

Annotations prises en charge

Plusieurs annotations sont disponibles pour personnaliser votre load balancer :

• service.beta.kubernetes.io/ovh-loadbalancer-proxy-protocol : utilisée sur le service pour activer le proxy protocol sur l'ensemble des backends. Valeurs prises en charge : v1, v2, v2_ssl, v2_ssl_cn.

Les services OVHcloud Load Balancer gèrent 4 modes ProxyProtocol :

• service.beta.kubernetes.io/ovh-loadbalancer-allowed-sources : utilisée sur le service pour spécifier les plages d'IP source client autorisées. Valeur : liste de CIDR séparés par des virgules. Par exemple : 10.0.0.0/24,172.10.0.1. Obsolète, utilisez plutôt le spec loadBalancerSourceRanges, voir Restrict Access For LoadBalancer Service.

• service.beta.kubernetes.io/ovh-loadbalancer-balance : utilisée sur le service pour définir l'algorithme à utiliser pour la répartition de charge. Valeurs prises en charge : first, leastconn, roundrobin, source. Valeur par défaut : roundrobin.

Qu'en est-il de l'Ingress

Selon la documentation officielle, un Ingress est un objet d'API qui gère l'accès externe aux services d'un cluster, généralement en HTTP. Quelle est la différence avec le LoadBalancer ou le NodePort ?

Ingress n'est pas un type de Service, mais un objet qui agit comme un reverse proxy et un point d'entrée unique vers votre cluster, qui achemine les requêtes vers les différents services. L'Ingress le plus basique est le contrôleur NGINX Ingress, où NGINX joue le rôle de reverse proxy, mais assure également la fonction SSL.

Un Ingress est exposé à l'extérieur du cluster via ClusterIP et le proxy Kubernetes, NodePort ou LoadBalancer, et il achemine le trafic entrant selon des règles configurées.

Le principal avantage d'utiliser un Ingress derrière un LoadBalancer est le coût : vous pouvez avoir de nombreux services derrière un seul LoadBalancer.

Déployer des services LoadBalancer sur des clusters OVHcloud Managed Kubernetes

Sur notre OVHcloud Managed Kubernetes, nous proposons un service de répartition de charge vous permettant d'utiliser le ServiceType LoadBalancer.

Déployer un service LoadBalancer Hello World

Créez un fichier hello.yml pour notre image Docker ovhplatform/hello, en définissant le type de service comme LoadBalancer :

apiVersion: v1
kind: Service
metadata:
  name: hello-world
  labels:
    app: hello-world
spec:
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: http
  selector:
    app: hello-world
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-world-deployment
  labels:
    app: hello-world
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hello-world
  template:
    metadata:
      labels:
        app: hello-world
    spec:
      containers:
      - name: hello-world
        image: ovhplatform/hello:1.1
        ports:
        - containerPort: 80

Et appliquez le fichier :

kubectl apply -f hello.yml

Après avoir appliqué le fichier YAML, un nouveau service hello-world et le déploiement hello-world-deployment correspondant sont créés :

$ kubectl apply -f hello.yml

service/hello-world unchanged
deployment.apps/hello-world-deployment configured

Lister les services

Utilisez à présent kubectl pour observer votre service :

kubectl get service hello-world -w

Vous devriez voir votre service nouvellement créé :

$ kubectl get services
NAME          TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)            AGE
hello-world   LoadBalancer   10.3.81.234   `<pending>`       80:31699/TCP       9s

Comme la création du LoadBalancer est asynchrone et que le provisionnement du load balancer peut prendre plusieurs minutes, vous obtiendrez certainement un EXTERNAL-IP à l'état <pending>.

Si vous réessayez quelques minutes plus tard, vous devriez obtenir un EXTERNAL-IP :

$ kubectl get service hello-world
NAME          TYPE           CLUSTER-IP    EXTERNAL-IP       PORT(S)        AGE
hello-world   LoadBalancer   10.3.81.234   xxx.xxx.xxx.xxx   80:31699/TCP   4m

Pour chaque service que vous déployez avec le type LoadBalancer, vous obtiendrez une nouvelle IPv4 au format xxx.xxx.xxx.xxx pour accéder au service.

Tester votre service

Si vous pointez votre navigateur web vers la valeur EXTERNAL-IP, le service hello-world vous répondra :

Suppression (nettoyage)

Pour finir, vous pouvez procéder au nettoyage en supprimant le service et le déploiement.

Commencez par supprimer le service :

kubectl delete service hello-world

Si vous listez les services, vous constaterez que hello-world n'existe plus :

$ kubectl delete service hello-world
service "hello-world" deleted

$ kubectl get services -l app=hello-world
No resources found.

Vous pouvez ensuite supprimer le déploiement :

kubectl delete deploy hello-world-deployment

Et si vous listez à présent votre déploiement, vous ne trouverez plus aucune ressource :

$ kubectl delete deploy hello-world-deployment
deployment.apps "hello-world-deployment" deleted

$ kubectl get deployments -l app=hello-world
No resources found.

Si vous listez maintenant les pods :

kubectl get pod -n default -l app=hello-world

Vous constaterez que le pod créé pour hello-world a également été supprimé :

$ kubectl get pod -l app=hello-world
No resources found

Aller plus loin

• Pour une formation ou une assistance technique sur la mise en œuvre de nos solutions, contactez votre commercial ou consultez la page Professional Services pour obtenir un devis et faire analyser votre projet par nos experts.

• Échangez avec notre communauté d'utilisateurs.