Provisionnement des équilibreurs de charge OCI pour les services Kubernetes de type LoadBalancer

oci.oraclecloud.com/load-balancer-type: "lb"

lb est la valeur par défaut de l'annotation oci.oraclecloud.com/load-balancer-type. Si vous n'incluez pas explicitement l'annotation dans la définition de service, la valeur par défaut de l'annotation est utilisée.

Prenons par exemple le fichier de configuration nginx_lb.yaml. Il définit un déploiement (kind: Deployment) pour l'application nginx, puis un service de type LoadBalancer (type: LoadBalancer) qui équilibre le trafic HTTP sur le port 80 pour l'application nginx.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

La première partie du fichier de configuration définit un déploiement Nginx, demandant qu'il soit hébergé sur 3 pods exécutant l'image nginx:latest, et accepte le trafic vers les conteneurs sur le port 80.

La deuxième partie du fichier de configuration définit le service Nginx, qui utilise le type LoadBalancer pour équilibrer le trafic Nginx sur le port 80 entre les pods disponibles.

Pour créer le déploiement et le service définis dans nginx_lb.yaml lors de la connexion au cluster Kubernetes, entrez la commande suivante :

kubectl apply -f nginx_lb.yaml

Cette commande génère les éléments suivants après la création du déploiement et de l'équilibreur de charge :

deployment "my-nginx" created
service "my-nginx-svc" created

L'équilibreur de charge peut prendre quelques minutes pour passer d'un état en attente à un état totalement opérationnel. Pour visualiser l'état en cours de votre cluster, saisissez ce qui suit :

kubectl get all

La sortie de la commande ci-dessus indique l'état en cours :

NAME                                  READY     STATUS    RESTARTS   AGE
po/my-nginx-431080787-0m4m8           1/1       Running   0          3m
po/my-nginx-431080787-hqqcr           1/1       Running   0          3m
po/my-nginx-431080787-n8125           1/1       Running   0          3m

NAME               CLUSTER-IP      EXTERNAL-IP      PORT(S)        AGE
svc/kubernetes     203.0.113.1     <NONE>           443/TCP        3d
svc/my-nginx-svc   203.0.113.7     192.0.2.22       80:30269/TCP   3m

NAME                      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deploy/my-nginx           3         3         3            3           3m

NAME                            DESIRED   CURRENT   READY     AGE
rs/my-nginx-431080787           3         3         3         3m

La sortie indique que le déploiement my-nginx est exécuté sur trois pods (entrées po/my-nginx). Elle indique également que l'équilibreur de charge est en cours d'exécution (svc/my-nginx-svc) et qu'il dispose d'une adresse IP externe (192.0.2.22) que les clients peuvent utiliser pour se connecter à l'application déployée sur les pods.

Lorsque le moteur Kubernetes provisionne un équilibreur de charge pour un service Kubernetes de type LoadBalancer, vous pouvez indiquer que vous voulez mettre fin à SSL sur l'équilibreur de charge. Cette configuration est appelée SSL frontal. Pour implémenter SSL frontal, vous définissez un processus d'écoute sur un port tel que 443 et associez un certificat SSL au processus d'écoute.

Vous pouvez implémenter le cryptage SSL point à point complet entre les clients et les pods d'application exécutés sur les noeuds de processus actif. Pour ce faire, créez un équilibreur de charge avec terminaison SSL (comme décrit dans cette section) et associez également un certificat SSL à l'ensemble de back-ends de l'équilibreur de charge (reportez-vous à Implémentation de SSL/TLS entre l'équilibreur de charge et les noeuds de processus actif).

Cet exemple fournit une procédure guidée de configuration et de création d'un équilibreur de charge avec la prise en charge SSL.

Examinez le fichier de configuration nginx-demo-svc-ssl.yaml qui définit un déploiement Nginx et l'affiche via un équilibreur de charge traitant le trafic HTTP sur le port 80 et le trafic HTTPS sur le port 443. L'exemple suivant crée un équilibreur de charge Oracle Cloud Infrastructure en définissant un service de type LoadBalancer (type: LoadBalancer).

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
---
kind: Service
apiVersion: v1
metadata:
  name: nginx-service
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    service.beta.kubernetes.io/oci-load-balancer-ssl-ports: "443"
    oci.oraclecloud.com/oci-load-balancer-listener-ssl-config: '{"CipherSuiteName":"oci-default-http2-tls-12-13-ssl-cipher-suite-v1", "Protocols":["TLSv1.3"]}'
    service.beta.kubernetes.io/oci-load-balancer-tls-secret: ssl-certificate-secret
spec:
  selector:
    app: nginx
  type: LoadBalancer
  ports:
  - name: http
    port: 80
    targetPort: 80
  - name: https
    port: 443
    targetPort: 80

Les annotations de l'équilibreur de charge sont particulièrement importantes, comme décrit ici.

Les ports sur lesquels le trafic HTTP doit être pris en charge sont définis par la valeur de l'annotation service.beta.kubernetes.io/oci-load-balancer-ssl-ports. Vous pouvez déclarer plusieurs ports SSL en utilisant une liste séparée par des virgules comme valeur de l'annotation. Par exemple, vous pouvez définir la valeur de l'annotation sur "443, 3000" pour que SSL soit pris en charge sur les ports 443 et 3000.

Le mécanisme de cryptage à utiliser avec l'équilibreur de charge est défini par la valeur de l'annotation oci.oraclecloud.com/oci-load-balancer-listener-ssl-config. Les mécanismes de cryptage déterminent la sécurité, la compatibilité et la vitesse du trafic HTTPS (pour plus d'informations, reportez-vous à Mécanismes de cryptage pour les équilibreurs de charge). Vous indiquez à la fois le nom du mécanisme de cryptage (par exemple, oci-default-http2-TLS-12-13-ssl-cipher-suite-v1) et la version de TLS (par exemple, TLSv1.3). Vous pouvez indiquer un mécanisme de cryptage prédéfini préconfiguré par Oracle Cloud Infrastructure (reportez-vous à Mécanismes de cryptage d'équilibreur de charge prédéfinis) ou un mécanisme de cryptage que vous avez créé vous-même. Si vous n'incluez pas l'annotation oci.oraclecloud.com/oci-load-balancer-listener-ssl-config mais que vous incluez l'annotation service.beta.kubernetes.io/oci-load-balancer-tls-secret, le mécanisme de cryptage oci-default-ssl-cipher-suite-v1 est utilisé.

La clé secrète TLS requise, ssl-certificate-secret, doit être créée dans Kubernetes. Cet exemple crée un certificat auto-signé et l'utilise. Toutefois, dans un environnement de production, le scénario le plus courant consiste à utiliser un certificat public signé par une autorité de certification.

La commande suivante crée un certificat auto-signé tls.crt avec la clé correspondante tls.key :

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=nginxsvc/O=nginxsvc"

Maintenant que vous avez créé le certificat, vous devez le stocker avec sa clé en tant que clé secrète dans Kubernetes. Le nom de la clé secrète doit correspondre au nom de l'annotation service.beta.kubernetes.io/oci-load-balancer-tls-secret de la définition de l'équilibreurs de charge. Utilisez la commande suivante pour créer une clef secrète TLS dans Kubernetes, dont la clé et la valeur de certificat sont définies respectivement par --key et --cert.

kubectl create secret tls ssl-certificate-secret --key tls.key --cert tls.crt

Vous devez créer la clé secrète Kubernetes pour pouvoir créer le service, car le service fait référence à la clé secrète dans sa définition. Créez le service à l'aide de la commande suivante :

kubectl create -f manifests/demo/nginx-demo-svc-ssl.yaml

Surveillez le service et attendez qu'une adresse IP publique (EXTERNAL-IP) soit affectée au service Nginx (nginx-service) en saisissant la commande suivante :

kubectl get svc --watch

La sortie de la commande ci-dessus indique l'adresse IP de l'équilibreur de charge à utiliser pour la connexion au service.

NAME            CLUSTER-IP     EXTERNAL-IP      PORT(S)        AGE
nginx-service   192.0.2.1      198.51.100.1     80:30274/TCP   5m

L'équilibreur de charge est à présent en cours d'exécution, ce qui signifie que le service est désormais accessible comme suit :

• avec http, en saisissant :

  curl http://198.51.100.1

• avec https, en saisissant :

  curl --insecure https://198.51.100.1

  L'indicateur "--insecure" permet d'accéder au service à l'aide du protocole HTTPS car des certificats auto-signés sont utilisés dans cet exemple. N'utilisez pas cet indicateur dans un environnement de production où le certificat public a été signé par une autorité de certification.

Remarque : lorsqu'un cluster est supprimé, l'équilibreur de charge créé de façon dynamique lors de la création du service n'est pas supprimé. Avant de supprimer un cluster, supprimez le service, ce qui entraînera la suppression de l'équilibreur de charge. La syntaxe de cette commande est la suivante :

kubectl delete svc SERVICE_NAME

Par exemple, pour supprimer le service de l'exemple précédent, entrez la commande suivante :

kubectl delete svc nginx-service

Lorsque le moteur Kubernetes provisionne un équilibreur de charge pour un service Kubernetes de type LoadBalancer, vous pouvez indiquer que vous voulez implémenter SSL entre l'équilibreur de charge et les serveurs back-end (noeuds de processus actif) dans l'ensemble de back-ends. Cette configuration est appelée SSL back-end. Pour implémenter SSL back-end, vous devez associer un certificat SSL à l'ensemble de back-ends de l'équilibreur de charge.

Vous pouvez implémenter le cryptage SSL point à point complet entre les clients et les pods d'application exécutés sur les noeuds de processus actif. Pour ce faire, associez un certificat SSL à l'ensemble de back-ends de l'équilibreur de charge (comme décrit dans cette section), ainsi que créez un équilibreur de charge avec terminaison SSL (reportez-vous à Terminaison de SSL/TLS dans l'équilibreur de charge).

Les mécanismes de cryptage déterminent la sécurité, la compatibilité et la vitesse du trafic HTTPS (pour plus d'informations, reportez-vous à Mécanismes de cryptage pour les équilibreurs de charge). Pour indiquer le mécanisme de cryptage à utiliser avec l'ensemble de back-ends de l'équilibreur de charge, ajoutez l'annotation suivante dans la section des métadonnées du fichier manifeste :

oci.oraclecloud.com/oci-load-balancer-backendset-ssl-config: '{"CipherSuiteName":"<cipher-suite-name>", "Protocols":["<tls-version>"]}'

où :

• "CipherSuiteName":"<cipher-suite-name>" est le nom d'un mécanisme de cryptage prédéfini préconfiguré par Oracle Cloud Infrastructure (reportez-vous à Mécanismes de cryptage d'équilibreur de charge prédéfinis) ou d'un mécanisme de cryptage que vous avez vous-même créé. Par exemple, "CipherSuiteName":"oci-default-http2-tls-12-13-ssl-cipher-suite-v1"
• "Protocols":["<tls-version>"] indique une ou plusieurs versions de TLS, dans une liste séparée par des virgules. Par exemple, "Protocols":["TLSv1.2", "TLSv1.3"]

Par exemple :

oci.oraclecloud.com/oci-load-balancer-backendset-ssl-config: '{"CipherSuiteName":"oci-default-http2-tls-12-13-ssl-cipher-suite-v1", "Protocols":["TLSv1.2", "TLSv1.3"]}'

Si vous n'incluez pas l'annotation oci.oraclecloud.com/oci-load-balancer-backendset-ssl-config mais que vous incluez l'annotation service.beta.kubernetes.io/oci-load-balancer-tls-backendset-secret, le mécanisme de cryptage oci-wider-compatible-ssl-cipher-suite-v1 est utilisé.

Pour indiquer le certificat à associer à l'ensemble de back-ends, ajoutez l'annotation suivante dans la section des métadonnées du fichier manifeste :

service.beta.kubernetes.io/oci-load-balancer-tls-backendset-secret: <value>

où <value> est le nom d'une clé secrète Kubernetes que vous avez créée pour contenir un certificat signé et la clé privée du certificat. Vous devez créer la clé secrète Kubernetes pour pouvoir créer le service, car le service fait référence à la clé secrète dans sa définition.

L'exemple suivant crée et utilise un certificat auto-signé, ce qui est généralement acceptable pour la communication interne entre l'équilibreur de charge et l'ensemble de back-ends. Toutefois, si vous préférez, vous pouvez utiliser un certificat public signé par une autorité de certification.

Par exemple :

1. Générez une clé privée en saisissant la commande suivante :

   openssl genrsa -out ca.key 2048

2. Générez un certificat en saisissant :

   openssl req -x509 -new -nodes -key ca.key -subj "/CN=nginxsvc/O=nginxsvc" -days 10000 -out ca.crt

3. Stockez le certificat et la clé en tant que clé secrète dans Kubernetes en saisissant ce qui suit :

   kubectl create secret generic ca-ser-secret --from-file=tls.crt=tls.crt --from-file=tls.key=tls.key --from-file=ca.crt=ca.crt
4. Définissez un déploiement Nginx et exposez-le via un équilibreur de charge qui sert http sur le port 80 et https sur le port 443.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
---
apiVersion: v1
metadata:
  name: nginx-service
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    oci.oraclecloud.com/oci-load-balancer-backendset-ssl-config: '{"CipherSuiteName":"oci-default-http2-tls-12-13-ssl-cipher-suite-v1", "Protocols":["TLSv1.2", "TLSv1.3"]}'
    service.beta.kubernetes.io/oci-load-balancer-tls-backendset-secret: ca-ser-secret
    service.beta.kubernetes.io/oci-load-balancer-ssl-ports: "443" 
spec:
  selector:
    app: nginx
  type: LoadBalancer
  ports:
  - name: http
    port: 80
    targetPort: 80
  - name: https
    port: 443
    targetPort: 443

La communication entre l'équilibreur de charge et les noeuds de processus actif de l'ensemble de back-ends est cryptée à l'aide de la clé et du certificat stockés dans la clé secrète Kubernetes ca-ser-secret que vous avez créée précédemment.

La forme d'un équilibreur de charge Oracle Cloud Infrastructure spécifie sa bande passante totale maximale (c'est-à-dire, entrante et sortante). Par défaut, les équilibreurs de charge sont créés avec une forme de 100 Mbits/s. D'autres formes sont disponibles, notamment 400 Mbits/s et 8 000 Mbits/s.

Afin de spécifier une autre forme pour un équilibreur de charge, ajoutez l'annotation suivante dans la section des métadonnées du fichier manifeste :

service.beta.kubernetes.io/oci-load-balancer-shape: <value>

où value représente la bande passante de la forme (par exemple, 100 Mbits/s, 400 Mbits/s ou 8 000 Mbits/s).

Par exemple :

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    service.beta.kubernetes.io/oci-load-balancer-shape: 400Mbps
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Un quota d'équilibreur de charge suffisant doit être disponible dans la région pour la forme que vous indiquez. Entrez la commande kubectl suivante pour vérifier que la création de l'équilibreur de charge n'a pas échoué en raison d'un quota insuffisant :

kubectl describe service <service-name>

Oracle vous recommande d'implémenter des services Kubernetes de type LoadBalancer en tant qu'équilibreurs de charge flexibles économiques plutôt qu'en tant qu'équilibreurs de charge à forme fixe (dynamique) (reportez-vous à Spécification de formes d'équilibreur de charge flexibles).

La forme d'un équilibreur de charge Oracle Cloud Infrastructure spécifie sa bande passante totale maximale (c'est-à-dire, entrante et sortante). Comme décrit dans Spécification d'autres formes d'équilibreur de charge, vous pouvez spécifier différentes formes d'équilibreur de charge.

De plus, vous pouvez spécifier une forme flexible pour un équilibreur de charge Oracle Cloud Infrastructure en définissant une bande passante minimale et maximale pour celui-ci.

Afin de spécifier une forme flexible pour un équilibreur de charge, ajoutez les annotations suivantes dans la section des métadonnées du fichier manifeste :

service.beta.kubernetes.io/oci-load-balancer-shape: "flexible"
service.beta.kubernetes.io/oci-load-balancer-shape-flex-min: "<min-value>"
service.beta.kubernetes.io/oci-load-balancer-shape-flex-max: "<max-value>"

où :

• "<min-value>" est la bande passante minimale de l'équilibreur de charge, en Mbps (par exemple, "10")
• "<max-value>" est la bande passante maximale de l'équilibreur de charge, en Mbps (par exemple, "100")

Vous n'incluez pas d'unité de mesure lorsque vous spécifiez des valeurs de bande passante pour les formes flexibles d'équilibreur de charge (contrairement aux formes prédéfinies). Par exemple, spécifiez la bande passante minimale avec la valeur 10 plutôt qu'avec la valeur 10 Mbits/s.

Par exemple :

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    service.beta.kubernetes.io/oci-load-balancer-shape: "flexible"
    service.beta.kubernetes.io/oci-load-balancer-shape-flex-min: "10"
    service.beta.kubernetes.io/oci-load-balancer-shape-flex-max: "100"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Lors du provisionnement d'un équilibreur de charge Oracle Cloud Infrastructure pour un service Kubernetes de type LoadBalancer, vous pouvez indiquer le temps d'inactivité maximal (en secondes) autorisé entre deux opérations d'envoi ou de réception successives entre le client et les serveurs back-end.

Pour spécifier explicitement un temps d'inactivité maximal, ajoutez l'annotation suivante à la section des métadonnées du fichier manifeste :

service.beta.kubernetes.io/oci-load-balancer-connection-idle-timeout: <value>

où value est le nombre de secondes.

Par exemple :

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    service.beta.kubernetes.io/oci-load-balancer-connection-idle-timeout: 100
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Si vous n'indiquez pas explicitement de durée d'inactivité maximale, une valeur par défaut est utilisée. La valeur par défaut dépend du type de processus d'écoute :

• Pour les processus d'écoute TCP, la durée d'inactivité maximale par défaut est de 300 secondes.
• Pour les processus d'écoute HTTP, la durée d'inactivité maximale par défaut est de 60 secondes.

Lorsque le moteur Kubernetes provisionne un équilibreur de charge pour un service Kubernetes de type LoadBalancer, vous pouvez indiquer la taille maximale de l'en-tête HTTP accepté par les processus d'écoute de l'équilibreur de charge. Vous indiquez la taille maximale de l'en-tête HTTP en utilisant une annotation pour indiquer la taille (en Ko) du tampon utilisé pour lire l'en-tête. Les valeurs autorisées pour la taille de tampon sont 8, 16, 32 et 64. L'annotation est utilisée pour définir une règle d'en-tête HTTP pour l'équilibreur de charge. La règle d'en-tête HTTP s'applique à tous les processus d'écoute de l'équilibreur de charge, sur tous les ports.

Pour plus d'informations sur les règles d'en-tête HTTP, reportez-vous à Règles d'en-tête HTTP.

Pour indiquer la taille maximale de l'en-tête HTTP acceptée par les processus d'écoute de l'équilibreur de charge, ajoutez l'annotation oci.oraclecloud.com/oci-load-balancer-rule-sets dans la section des métadonnées du fichier manifeste. Notez que vous indiquez la valeur de l'annotation au format JSON, comme suit :

oci.oraclecloud.com/oci-load-balancer-rule-sets:  |
      {
        "<rule-set-name>": {
          "items": [
            {
              "action": "HTTP_HEADER",
              "httpLargeHeaderSizeInKB": <value>
            }
          ]
        }
      }

où :

• <rule-set-name> est votre choix de nom pour l'ensemble de règles (entre 1 et 32 caractères). Par exemple, header-size.
• <value> est la taille maximale de l'en-tête HTTP en Ko. Il s'agit de 8, 16, 32 ou 64.

Par exemple :

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    oci.oraclecloud.com/oci-load-balancer-rule-sets: |
      {
        "header-size": {
          "items": [
            {
              "action": "HTTP_HEADER",
              "httpLargeHeaderSizeInKB": 16
            }
          ]
        }
      }
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Pour modifier ensuite la taille maximale de l'en-tête HTTP, mettez à jour l'annotation et appliquez de nouveau le manifeste.

Lorsque vous appliquez un manifeste contenant l'annotation oci.oraclecloud.com/oci-load-balancer-rule-sets, Kubernetes Engine suppose la gestion de tous les ensembles de règles de l'équilibreur de charge. Kubernetes Engine ajoute non seulement l'ensemble de règles d'en-tête HTTP indiqué par l'annotation, mais supprime également tous les autres ensembles de règles actuellement associés à l'équilibreur de charge. Notez les points suivants :

• Si vous souhaitez supprimer ultérieurement l'ensemble de règles d'en-tête HTTP de l'équilibreur de charge, indiquez un objet JSON vide en tant que valeur de l'annotation oci.oraclecloud.com/oci-load-balancer-rule-sets comme suit :

  oci.oraclecloud.com/oci-load-balancer-rule-sets: "{}"

  Lorsque vous indiquez un objet JSON vide comme valeur de l'annotation, Kubernetes Engine supprime tous les ensembles de règles associés à l'équilibreur de charge et abandonne la gestion des ensembles de règles de l'équilibreur de charge.

• Si vous enlevez simplement l'annotation oci.oraclecloud.com/oci-load-balancer-rule-sets du manifeste et que vous l'appliquez, Kubernetes Engine abandonne la gestion des ensembles de règles de l'équilibreur de charge. Si vous enlevez l'annotation, Kubernetes Engine ne supprime aucun des ensembles de règles associés à l'équilibreur de charge.

Si vous apportez des modifications directes aux ensembles de règles de l'équilibreur de charge (ce qui n'est pas recommandé) plutôt que d'utiliser l'annotation oci.oraclecloud.com/oci-load-balancer-rule-sets, notez le point suivant. Si vous appliquez ensuite un manifeste contenant l'annotation oci.oraclecloud.com/oci-load-balancer-rule-sets, Kubernetes Engine ajoute l'ensemble de règles d'en-tête HTTP indiqué par l'annotation et supprime tout autre ensemble de règles associé à l'équilibreur de charge. Par conséquent, si vous voulez conserver les modifications directes apportées aux ensembles de règles de l'équilibreur de charge, n'incluez pas l'annotation oci.oraclecloud.com/oci-load-balancer-rule-sets dans le manifeste.

Lorsque le moteur Kubernetes provisionne un équilibreur de charge pour un service Kubernetes de type LoadBalancer, vous pouvez définir le type de trafic accepté par le processus d'écoute en indiquant le protocole sur lequel le processus d'écoute accepte les demandes de connexion.

Si vous n'indiquez pas explicitement de protocole, "TCP" est utilisé comme valeur par défaut.

Afin d'indiquer explicitement le protocole de processus d'écoute d'équilibreur de charge lorsque le moteur Kubernetes provisionne un équilibreur de charge pour un service Kubernetes de type LoadBalancer, ajoutez l'annotation suivante à la section des métadonnées du fichier manifeste :

service.beta.kubernetes.io/oci-load-balancer-backend-protocol: <value>

où <value> est le protocole qui définit le type de trafic accepté par le processus d'écoute. Par exemple, "HTTP". Les protocoles valides incluent "HTTP", "TCP" et "GRPC".

Par exemple :

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    service.beta.kubernetes.io/oci-load-balancer-backend-protocol: "HTTP"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Notez que si vous spécifiez GRPC comme protocole, vous devez configurer les deux éléments suivants :

• SSL frontal, à l'aide des annotations service.beta.kubernetes.io/oci-load-balancer-ssl-ports, oci.oraclecloud.com/oci-load-balancer-ssl-listener-config et service.beta.kubernetes.io/oci-load-balancer-tls-secret. Pour plus d'informations, reportez-vous à Terminaison de SSL/TLS dans l'équilibreur de charge.
• SSL back-end, à l'aide des annotations oci.oraclecloud.com/oci-load-balancer-backendset-ssl-config et service.beta.kubernetes.io/oci-load-balancer-tls-backendset-secret. Pour plus d'informations, reportez-vous à Implémentation de SSL/TLS entre les noeuds d'équilibreur de charge et de processus actif.

Par exemple :

apiVersion: v1
kind: Service
metadata:
  name: hello-grpc-service
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    service.beta.kubernetes.io/oci-load-balancer-ssl-ports: "443"
    service.beta.kubernetes.io/oci-load-balancer-tls-secret: ssl-certificate-secret
    service.beta.kubernetes.io/oci-load-balancer-backend-protocol: "GRPC"
    oci.oraclecloud.com/oci-load-balancer-listener-ssl-config: '{"CipherSuiteName":"oci-default-http2-ssl-cipher-suite-v1", "Protocols":["TLSv1.2"]}'
    oci.oraclecloud.com/oci-load-balancer-backendset-ssl-config: '{"CipherSuiteName":"oci-default-http2-ssl-cipher-suite-v1", "Protocols":["TLSv1.2"]}'
    service.beta.kubernetes.io/oci-load-balancer-tls-backendset-secret: ca-ser-secret
spec:
  type: LoadBalancer
  selector:
    app: hello-grpc
  ports:
    - port: 443
      name: grpc
      targetPort: 50051

Vous pouvez utiliser la fonctionnalité de gestion des listes de sécurité pour configurer le mode de gestion des règles de liste de sécurité pour un équilibreur de charge Oracle Cloud Infrastructure provisionné par Kubernetes Engine pour un service Kubernetes de type LoadBalancer. Cette fonctionnalité est utile si vous découvrez Kubernetes ou pour les déploiements de base.

Afin d'indiquer comment la fonctionnalité de gestion des listes de sécurité Kubernetes gère les listes de sécurité lorsque Kubernetes Engine provisionne un équilibreur de charge pour un service Kubernetes de type LoadBalancer, ajoutez l'annotation suivante dans la section des métadonnées du fichier manifeste :

service.beta.kubernetes.io/oci-load-balancer-security-list-management-mode: <value>

où <value> prend l'une des valeurs suivantes :

• "None" : (recommandé) aucune gestion des listes de sécurité n'est activée. Vous devez configurer une règle de sécurité qui autorise le trafic entrant vers les ports appropriés pour les plages de ports de noeud, le port d'état du proxy Kube et les plages de ports de vérification de l'état. En outre, vous devez configurer des règles de sécurité qui autorisent le trafic entrant vers les équilibreurs de charge (reportez-vous à Règles de sécurité pour les équilibreurs de charge et les équilibreurs de charge réseau).
• "All" : (par défaut) toutes les règles de liste de sécurité requises pour les services d'équilibreur de charge sont gérées.
• "Frontend" : seules les règles de liste de sécurité pour le trafic entrant vers les services d'équilibreur de charge sont gérées. Vous devez configurer une règle de sécurité qui autorise le trafic entrant vers les ports appropriés pour les plages de ports de noeud, le port d'état du proxy Kube et les plages de ports de vérification de l'état.

Oracle recommande de définir explicitement service.beta.kubernetes.io/oci-load-balancer-security-list-management-mode sur None.

Dans les clusters avec des noeuds gérés, si vous n'indiquez pas explicitement de mode de gestion ou si vous indiquez une valeur non valide, toutes les règles de liste de sécurité sont gérées (équivalent à "All"). Notez que dans ce cas, Kubernetes Engine crée une règle de sécurité qui autorise le trafic entrant à partir de 0.0.0.0/0 (ou des plages de ports source spécifiées dans le fichier manifeste) vers les ports de processus d'écoute. Dans les clusters avec des noeuds virtuels, la gestion des listes de sécurité n'est jamais activée et vous devez toujours configurer manuellement les règles de sécurité (équivalent à "None").

Le nombre de règles entrantes et sortantes autorisées dans une liste de sécurité est limité (reportez-vous à Limites de liste de sécurité). Si le nombre de règles entrantes ou sortantes dépasse la limite et que <value> est défini sur "All" ou "Frontend", la création ou la mise à jour de l'équilibreur de charge échoue.

Par exemple :

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    service.beta.kubernetes.io/oci-load-balancer-security-list-management-mode: "Frontend"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx