Créer des load balancers dans OKS
Vos clients peuvent accéder librement à vos clusters grâce aux load balancers OKS. Un load balancer OKS est un point d’entrée d’un cluster Kubernetes. Il détecte les demandes de création de load balancer dans les manifestes qui sont appliqués au cluster, crée le Load Balancing Unit (LBU) correspondant, et attache ce nouveau LBU à votre cluster. Les load balancers OKS prennent en charge les protocoles TCP/SSL et HTTP/HTTPS.
Pour en savoir plus sur les load balancers, voir À propos des load balancers.
Créer un load balancer
Pour créer un load balancer, vous devez attacher les annotations nécessaires à vos manifestes.
Dans l’exemple suivant, nous allons créer un load balancer basique autorisant l’accès HTTPS aux ressources du cluster.
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: echoheaders
namespace: default
labels:
app: echoheaders
spec:
replicas: 1
selector:
matchLabels:
app: echoheaders
template:
metadata:
labels:
app: echoheaders
spec:
containers:
- name: echoheaders
image: gcr.io/google_containers/echoserver:1.10
imagePullPolicy: IfNotPresent
ports:
- containerPort: 8080
protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
name: echoheaders-lb-public
namespace: default
labels:
app: echoheaders
annotations:
service.beta.kubernetes.io/osc-load-balancer-name: "simple-lb-test"
spec:
ports:
- port: 80
name: http
protocol: TCP
targetPort: 8080
selector:
app: echoheaders
type: LoadBalancerCette micro-application surveillerait les requêtes HTTP sur le port TCP 80 et renverrait les en-têtes de requête reçus en réponse.
Utiliser des annotations dans vos load balancers
Le tableau ci-dessous liste les différentes annotations supportées par vos load balancers OKS.
|
Sauf indication spécifique, les listes doivent être séparées par des virgules. |
| Annotation | Mutabilité | Description | Valeur par défaut | ||||
|---|---|---|---|---|---|---|---|
|
Non |
Le nom du load balancer. |
Au-delà de 31 caractères, la valeur est tronquée. |
||||
|
Non |
Le type de load balancer ( |
|
||||
|
Non |
Le nombre de load balancers à créer pour le service.
|
|
||||
|
Non |
La liste des Sous-régions dans lesquelles créer les load balancers. Par exemple :
|
Assigné automatiquement. |
||||
|
Non |
La liste des noms à attribuer aux load balancers. Par exemple :
|
Au-delà de 31 caractères, la valeur est tronquée. |
||||
|
Oui |
La liste des noms de node pools à utiliser comme VM backend sur le LBU. Par exemple : |
|
||||
|
Non |
Le nom facultatif de l’IP pool auquel est liée l’IP publique à utiliser pour le load balancer. Par exemple : |
Aucune |
||||
|
Oui |
La liste des paires clé-valeur à enregistrer comme tags additionnels dans le LBU. Par exemple : |
Aucune |
||||
|
Oui |
La liste des CIDR autorisées à accéder au load balancer. |
|
||||
|
Oui |
La durée entre deux requêtes de health check (entre 5 et 600 secondes). |
|
||||
|
Oui |
Le nombre de requêtes de health check qui doivent réussir de manière consécutive pour considérer le nœud comme sain (entre 2 et 10). |
|
||||
|
Oui |
Le chemin d’accès facultatif vers l’URL pour les requêtes de health check, uniquement utilisé pour les protocoles de health check HTTP ou HTTPS. Par exemple : |
Aucune |
||||
|
Oui |
Le numéro de port pour les requêtes de health check (entre 1 et 65 535). |
Automatiquement attribué au nodePort du service. |
||||
|
Oui |
Le protocole pour les requêtes de health check (parmi HTTP/HTTPS/TCP/SSL). |
Automatiquement assigné au protocole du service. |
||||
|
Oui |
Le temps d’attente maximum d’une réponse avant de considérer le nœud comme non sain (entre 2 et 60 secondes). |
|
||||
|
Oui |
Le nombre de requêtes de health check qui doivent échouer de manière consécutive pour considérer le nœud comme non sain (entre 2 et 10). |
|
||||
|
Oui |
La durée d’inactivité de la connexion en secondes, c’est-à-dire qu’aucune donnée n’est envoyée, avant sa fermeture par le load balancer. |
|
||||
|
Oui |
Spécifie s’il faut activer ou désactiver le protocole proxy pour transférer les informations de connexion du client (comme les IP du client) aux VM backend du load balancer ( |
Aucune |
||||
|
Oui |
Le mode IP de l’Ingress ( |
|
||||
|
Oui |
La ou les adresses externes renvoyées de l’Ingress du load balancer ( |
|
Créer des load balancers multi-Sous-régions
Vous pouvez créer des load balancers afin de répartir le trafic entre plusieurs Sous-régions. Cela améliore la disponibilité du service si une Sous-région devient indisponible, car le trafic peut continuer à être acheminé via les load balancers déployés dans les autres Sous-régions, au lieu de dépendre d’un seul load balancer, qui constituerait alors un point de défaillance unique (SPoF). Les load balancers multi-Sous-régions peuvent être configurés selon l’un des schémas suivants :
-
Interne : Crée un load balancer pour le trafic privé au sein du réseau.
-
Relié à Internet : Crée un load balancer accessible depuis Internet.
L’exemple suivant crée trois load balancers reliés à Internet, chacun déployé dans une Sous-région différente :
apiVersion: v1
kind: Service
metadata:
name: echoheaders
annotations:
service.beta.kubernetes.io/osc-load-balancer-scheme: internet-facing
service.oks.outscale.com/oks-load-balancer-instances: "3"
service.oks.outscale.com/oks-load-balancer-zones: eu-west-2a,eu-west-2b,eu-west-2c
service.oks.outscale.com/osc-load-balancer-name: ext-a,ext-b,ext-c
spec:
ports:
- port: 80
targetPort: 8080
protocol: TCP
selector:
app: echoheaders
type: LoadBalancerDans cet exemple, les load balancers sont créés comme suit :
-
ext-adans la Sous-régioneu-west-2a -
ext-bdans la Sous-régioneu-west-2b -
ext-cdans la Sous-régioneu-west-2c
Pour créer un load balancer interne couvrant plusieurs Sous-régions, vous pouvez définir service.beta.kubernetes.io/osc-load-balancer-scheme sur internal.
Pages connexes