Aprovisionamiento de equilibradores de carga de OCI para servicios de Kubernetes de tipo LoadBalancer

Descubra cómo aprovisionar un equilibrador de carga de OCI para un servicio de Kubernetes de tipo LoadBalancer mediante Kubernetes Engine (OKE).

Un equilibrador de carga de Oracle Cloud Infrastructure (OCI) es un proxy de capa 4 (TCP) y capa 7 (HTTP) de OSI, que soporta funciones como la terminación de SSL y las políticas de enrutamiento HTTP avanzadas. Proporciona la máxima flexibilidad, con escalado y reducción receptivos. Puede elegir un ancho de banda mínimo personalizado y un ancho de banda máximo opcional, tanto entre 10 Mbps como entre 8 000 Mbps. El ancho de banda mínimo siempre está disponible y proporciona una preparación instantánea para las cargas de trabajo.

Para obtener más información sobre los equilibradores de carga de OCI, consulte Visión general de Load Balancer.

El aprovisionamiento de un equilibrador de carga de OCI para un servicio de Kubernetes de tipo LoadBalancer le permite:

tráfico de capa 4 y capa 7 (TCP y HTTP) de transporte de equilibrio de carga
terminar SSL/TLS en el equilibrador de carga

Tenga en cuenta que cuando Kubernetes Engine aprovisiona un equilibrador de carga de OCI para un servicio de Kubernetes de tipo LoadBalancer, las reglas de seguridad para permitir el tráfico entrante y saliente hacia y desde la subred del equilibrador de carga se crean automáticamente por defecto. Consulte Reglas de seguridad para equilibradores de carga y equilibradores de carga de red.

Utilice las métricas de equilibrador de carga de OCI para supervisar el estado de un equilibrador de carga de OCI aprovisionado para un servicio de Kubernetes de tipo LoadBalancer (consulte Métricas de equilibrador de carga).

Especificación de la anotación para un equilibrador de carga de OCI

Para aprovisionar un equilibrador de carga de Oracle Cloud Infrastructure para un servicio de Kubernetes de tipo LoadBalancer, defina un servicio de tipo LoadBalancer que incluya la siguiente anotación en la sección de metadatos del archivo de manifiesto:

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

Tenga en cuenta que lb es el valor por defecto de la anotación oci.oraclecloud.com/load-balancer-type. Si no incluye explícitamente la anotación en la definición del servicio, se utiliza el valor por defecto de la anotación.

Por ejemplo, observe el siguiente archivo de configuración, nginx_lb.yaml. Define un despliegue (kind: Deployment) para la aplicación nginx, seguido de una definición de un servicio de tipo LoadBalancer (type: LoadBalancer) que equilibra el tráfico http en el puerto 80 para la aplicación 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 primera parte del archivo de configuración define un despliegue de Nginx, solicitando que se aloje en 3 pods que ejecuten la imagen nginx:latest y acepten el tráfico a los contenedores en el puerto 80.

La segunda parte del archivo de configuración define el servicio de Nginx, que utiliza el tipo LoadBalancer para equilibrar el tráfico de Nginx en el puerto 80 entre los pods disponibles.

Para crear el despliegue y el servicio definidos en nginx_lb.yaml mientras está conectado al cluster de Kubernetes, introduzca el comando:

kubectl apply -f nginx_lb.yaml

Este comando muestra lo siguiente tras la creación correcta del despliegue y el equilibrador de carga:

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

El equilibrador de carga puede tardar unos minutos en pasar de un estado pendiente a estar totalmente operativo. Para ver el estado actual del cluster, introduzca:

kubectl get all

La salida del comando anterior muestra el estado actual:


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 salida muestra que el despliegue de my-nginx se está ejecutando en 3 pods (las entradas po/my-nginx), que el equilibrador de carga está en ejecución (svc/my-nginx-svc) y tiene una IP externa (192.0.2.22) que los clientes pueden utilizar para conectarse a la aplicación desplegada en los pods.

Terminación de SSL/TLS en el equilibrador de carga (SSL de frontend)

Al aprovisionar un equilibrador de carga de Oracle Cloud Infrastructure (OCI) para un servicio de Kubernetes de tipo LoadBalancer, puede configurarlo para que termine el tráfico SSL/TLS. Esta configuración, a menudo denominada SSL de frontend, garantiza que el tráfico cifrado de Internet se descifra en el equilibrador de carga antes de reenviarse a los nodos de trabajador.

La implantación de la terminación SSL en el nivel del equilibrador de carga descarga el proceso de descifrado intensivo de los pods de aplicación, lo que simplifica la gestión de certificados y mejora el rendimiento del backend.

Tenga en cuenta que puede implantar el cifrado SSL de punto a punto completo entre los clientes y los pods de aplicaciones que se ejecutan en nodos de trabajador. Para ello, configure la terminación SSL en el equilibrador de carga (como se describe en esta sección) e implante también SSL de backend entre el equilibrador de carga y los nodos de trabajador (consulte Implantación de SSL/TLS entre el equilibrador de carga y los nodos de trabajador (SSL de backend)).

Elija un método de gestión de certificados para Frontend SSL

Según sus requisitos de seguridad y cómo gestione el ciclo de vida del certificado, elija uno de los siguientes métodos para implantar el SSL de frontend:

Secretos de Kubernetes: lo mejor para los certificados gestionados dentro del cluster o por proveedores de terceros (como Let's Encrypt). Para obtener más información sobre los pasos de implantación, consulte Finalización de SSL/TLS en el equilibrador de carga mediante secretos de Kubernetes.
Servicio OCI Certificates: recomendado para entornos de producción, este método aprovecha la gestión nativa de certificados de OCI para activar funciones como la rotación automática de certificados sin necesidad de actualizaciones de manifiesto. Para obtener más información, consulte Terminación de SSL/TLS en el equilibrador de carga mediante el servicio OCI Certificates.

Tenga en cuenta que estos métodos se excluyen mutuamente para un servicio determinado de tipo LoadBalancer. Debe seleccionar un secreto de Kubernetes o una asignación de certificado de OCI nativo para evitar conflictos de configuración.

Configuración de conjuntos de cifrado y protocolos para listeners

Independientemente del método de gestión de certificados que elija, puede especificar el conjunto de cifrado y los protocolos SSL que utiliza el equilibrador de carga para el listener de frontend.

Los conjuntos de cifrado determinan la seguridad, la compatibilidad y la velocidad del tráfico HTTPS (para obtener más información, consulte Conjuntos de cifrado para equilibradores de carga). Para especificar el conjunto de cifrado que se utilizará con el listener de frontend del equilibrador de carga, agregue la siguiente anotación en la sección de metadatos del archivo de manifiesto:

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

donde:

"CipherSuiteName":"<cipher-suite-name>" es el nombre de un conjunto de cifrado predefinido preconfigurado por Oracle Cloud Infrastructure (consulte Juegos de cifrado de equilibrador de carga predefinidos) o un conjunto de cifrado que haya creado usted mismo. Por ejemplo, "CipherSuiteName":"oci-default-http2-tls-12-13-ssl-cipher-suite-v1"
"Protocols":["<tls-version>"] especifica una o más versiones de TLS, en una lista delimitada por comas. Por ejemplo, "Protocols":["TLSv1.2", "TLSv1.3"]

Por ejemplo:

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

Si no incluye la anotación oci.oraclecloud.com/oci-load-balancer-ssl-config, pero sí la anotación service.beta.kubernetes.io/oci-load-balancer-tls-secret, se utiliza el conjunto de cifrado oci-default-ssl-cipher-suite-v1.

Terminación de SSL/TLS en el equilibrador de carga mediante secretos de Kubernetes

Los secretos de Kubernetes proporcionan una forma de gestionar certificados SSL/TLS localmente en el cluster. Este método es estándar para certificados gestionados manualmente o por proveedores de terceros (como Let's Encrypt). Si bien este método ofrece control directo sobre los datos del certificado dentro de Kubernetes, requiere actualizaciones manuales del secreto cada vez que caduca un certificado.

Este ejemplo proporciona un tutorial sobre la configuración y la creación de un equilibrador de carga con soporte SSL.

Tenga en cuenta el siguiente archivo de configuración, nginx-demo-svc-ssl.yaml, que define un despliegue de Nginx y lo expone a través de un equilibrador de carga que sirve http en el puerto 80 y https en el puerto 443. Este ejemplo crea un equilibrador de carga de Oracle Cloud Infrastructure, definiendo un servicio con un tipo de 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

Las anotaciones del equilibrador de carga tienen una importancia concreta, como se describe aquí.

Los puertos en los que soporta tráfico https se definen mediante el valor de la anotación service.beta.kubernetes.io/oci-load-balancer-ssl-ports. Puede declarar varios puertos SSL mediante una lista separada por comas para el valor de la anotación. Por ejemplo, puede definir el valor de la anotación en "443, 3000" para que soporte SSL en los puertos 443 y 3000.

El conjunto de cifrado que se utilizará con el equilibrador de carga está definido por el valor de la anotación oci.oraclecloud.com/oci-load-balancer-listener-ssl-config.

Se debe crear el secreto de TLS requerido ssl-certificate-secret en Kubernetes. En este ejemplo, se crea y utiliza un certificado autofirmado. Sin embargo, en un entorno de producción, el escenario más común es utilizar un certificado público que haya sido firmado por una autoridad de certificación.

El siguiente comando crea un certificado autofirmado, tls.crt, con su clave correspondiente, tls.key:

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

Ahora que ha creado el certificado, debe almacenarlo con su clave como un secreto en Kubernetes. El nombre del secreto debe coincidir con el nombre de la anotación service.beta.kubernetes.io/oci-load-balancer-tls-secret de la definición del equilibrio de carga. Utilice el siguiente comando para crear un secreto TLS en Kubernetes, cuyos valores de clave y certificado están definidos por --key y --cert, respectivamente.

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

Debe crear el secreto de Kubernetes antes de crear el servicio, ya que el servicio hace referencia al secreto en su definición. Cree el servicio con el siguiente comando:

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

Observe el servicio y espere a que se asigne una dirección IP pública (EXTERNAL-IP) al servicio de Nginx (nginx-service) introduciendo:

kubectl get svc --watch

La salida del comando anterior muestra la IP del equilibrador de carga que se va a utilizar para conectarse al servicio.


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

El equilibrador de carga se está ejecutando, lo que significa que ahora se puede acceder al servicio de la siguiente manera:

mediante http, introduciendo:
```
curl http://198.51.100.1
```
mediante https, introduciendo:
```
curl --insecure https://198.51.100.1
```
El indicador "--insecure" se utiliza para acceder al servicio mediante https debido al uso de certificados autofirmados en este ejemplo. No utilice este indicador en un entorno de producción donde la autoridad de certificación firmó el certificado público.

Nota: Cuando se suprime un cluster, no se elimina un equilibrador de carga creado de forma dinámica cuando se crea un servicio. Antes de suprimir un cluster, suprima el servicio que, a su vez, provocará la eliminación del equilibrador de carga. La sintaxis para este comando es:

kubectl delete svc SERVICE_NAME

Por ejemplo, para suprimir el servicio del ejemplo anterior, introduzca:

kubectl delete svc nginx-service

Actualización de los certificados TLS de equilibradores de carga existentes mediante secretos de Kubernetes

Para actualizar el certificado TLS de un equilibrador de carga existente:

Obtenga un nuevo certificado TLS. En un entorno de producción, el escenario más común es utilizar un certificado público que haya sido firmado por una autoridad de certificación.

Cree un nuevo secreto de Kubernetes. Por ejemplo, introduzca:

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

Modifique la definición de servicio para hacer referencia al nuevo secreto de Kubernetes cambiando la anotación service.beta.kubernetes.io/oci-load-balancer-tls-secret en la configuración de servicio. Por ejemplo:


apiVersion: v1
kind: Service
metadata:
  name: nginx-service
  annotations:
    service.beta.kubernetes.io/oci-load-balancer-ssl-ports: "443"
    service.beta.kubernetes.io/oci-load-balancer-tls-secret: new-ssl-certificate-secret
spec:
  selector:
    app: nginx
  type: LoadBalancer
  ports:
  - name: http
    port: 80
    targetPort: 80
  - name: https
    port: 443
    targetPort: 80

Actualice el servicio. Por ejemplo, introduzca:
```
kubectl apply -f new-nginx-demo-svc-ssl.yaml
```

Terminación de SSL/TLS en el equilibrador de carga mediante el servicio OCI Certificates

El servicio OCI Certificates proporciona una forma de gestionar certificados SSL/TLS de forma nativa en Oracle Cloud Infrastructure. Este método se recomienda para entornos de producción, ya que permite al equilibrador de carga de OCI consumir automáticamente certificados renovados, lo que ofrece varias ventajas empresariales:

Rotación sin tiempo de inactividad: cuando se renueva un certificado en OCI, el equilibrador de carga selecciona automáticamente la nueva versión sin necesidad de una aplicación de manifiesto.
Gestión centralizada: gestiona todos los certificados de frontend desde un único panel de control de OCI en lugar de en varios espacios de nombres de Kubernetes.
Seguridad mejorada: las claves privadas se almacenan de forma segura en OCI y nunca se exponen como texto sin formato en el cluster de Kubernetes.

Requisitos para la integración de certificados de OCI

Para utilizar esta integración nativa, debe asegurarse de que se cumplen las siguientes condiciones:

Política de IAM: otorgue el permiso de entidad de recurso del cluster para gestionar certificados en el compartimento:

Allow any-user to manage certificate-authority-family in compartment <compartment-name> where ALL {request.principal.type = 'cluster'}

OCID de certificado: debe tener el OCID del certificado de hoja que desea que el equilibrador de carga presente a los clientes. El certificado debe estar en la misma región que el equilibrador de carga.
Estado de recurso: el certificado debe crearse o importarse en el servicio OCI Certificates y debe tener un estado Activo.

Configuración de la asignación de certificados

Dado que un equilibrador de carga de OCI puede soportar varios certificados para diferentes listeners, debe utilizar ConfigMap para asignar puertos de listener a sus respectivos recursos de certificado de certificados de OCI. Al aplicar ConfigMap, se dispara inmediatamente una actualización del equilibrador de carga de OCI.

Crear ConfigMap: cree un ConfigMap en el mismo espacio de nombres que el servicio de tipo LoadBalancer y defina una asignación en la que la clave sea el puerto del listener y el valor sea una matriz JSON que contenga el OCID del certificado de hoja.
Por ejemplo:
```
apiVersion:v1
kind:ConfigMap
metadata:
  name:lb-tls-mapping
data:
  "443":"[\"ocid1.certificate.oc1.iad.example_leaf_ocid\"]"
```
Anotar el servicio: agregue la anotación oci-load-balancer.oraclecloud.com/tls-certificate-map al manifiesto del servicio de tipo LoadBalancer para enlazarlo a ConfigMap.

Nota: Las anotaciones tls-certificate-map y oci-load-balancer-tls-secret se excluyen mutuamente. Si se proporcionan ambos, el equilibrador de carga no se podrá aprovisionar con un error sslConfiguration violation.

Ejemplo de manifiesto SSL de frontend

apiVersion: v1
kind: Service
metadata:
  name: secure-frontend-service
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    service.beta.kubernetes.io/oci-load-balancer-ssl-ports: "443"
    oci-load-balancer.oraclecloud.com/tls-certificate-map: "lb-tls-mapping"
spec:
  selector:
    app: my-app
  type: LoadBalancer
  ports:
  - name: https
    port: 443
    targetPort: 8080
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: lb-tls-mapping
data:
  "443": "[\"ocid1.certificate.oc1.iad.example_leaf_ocid\"]"

Implantación de SSL/TLS entre el equilibrador de carga y los nodos de trabajador (SSL de backend)

Cuando Kubernetes Engine aprovisiona un equilibrador de carga para un servicio de Kubernetes de tipo LoadBalancer, puede especificar que desea implantar SSL entre el equilibrador de carga y los servidores de backend (nodos de trabajador) en el juego de backends. Esta configuración se conoce como SSL de backend. Para implantar el SSL de backend, debe asociar un certificado SSL al juego de backends del equilibrador de carga.

Tenga en cuenta que puede implantar el cifrado SSL de punto a punto completo entre los clientes y los pods de aplicaciones que se ejecutan en nodos de trabajador. Para ello, asocie un certificado SSL al juego de backends del equilibrador de carga (como se describe en esta sección) y también cree un equilibrador de carga con la terminación SSL (consulte Finalización de SSL/TLS en el equilibrador de carga (SSL de asistencia)).

Mientras que la terminación SSL de frontend protege la conexión entre el cliente y el equilibrador de carga, SSL de backend protege la conexión entre el equilibrador de carga y los nodos de trabajador. Esta configuración garantiza que el tráfico permanezca cifrado incluso mientras viaja a través de la red virtual en la nube (VCN) interna, lo que proporciona una capa adicional de defensa en profundidad.

Al implantar SSL de backend, el equilibrador de carga descifra el tráfico entrante mediante un certificado de frontend, realiza las inspecciones o el enrutamiento necesarios de la capa 7 y, a continuación, vuelve a cifrar el tráfico antes de enviarlo a los pods de destino. Este es un requisito común para los entornos de alta seguridad, donde el tráfico de texto no cifrado está restringido en cada salto.

Método de gestión de certificados para SSL de backend

Al implantar SSL de backend, se utilizan secretos de Kubernetes para gestionar el cifrado de backend mediante certificados almacenados en el cluster. Este método requiere actualizaciones manuales en el secreto y el manifiesto cuando caducan los certificados. Para obtener más información sobre la implantación, consulte Implantación de SSL/TLS entre el equilibrador de carga y los nodos de trabajador mediante secretos de Kubernetes.

Tenga en cuenta que los pods de aplicación se deben configurar para aceptar y terminar las conexiones SSL/TLS en sus puertos de destino.

Configuración de conjuntos de cifrado y protocolos para juegos de backends

Puede especificar el conjunto de cifrado y los protocolos SSL que utiliza el equilibrador de carga para el conjunto de backends.

Los conjuntos de cifrado determinan la seguridad, la compatibilidad y la velocidad del tráfico HTTPS (para obtener más información, consulte Conjuntos de cifrado para equilibradores de carga). Para especificar el conjunto de cifrado que se utilizará con el juego de backends del equilibrador de carga, agregue la siguiente anotación en la sección de metadatos del archivo de manifiesto:

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

donde:

"CipherSuiteName":"<cipher-suite-name>" es el nombre de un conjunto de cifrado predefinido preconfigurado por Oracle Cloud Infrastructure (consulte Conjuntos de cifrado de equilibrador de carga predefinidos) o un conjunto de cifrado que usted mismo ha creado. Por ejemplo, "CipherSuiteName":"oci-default-http2-tls-12-13-ssl-cipher-suite-v1"
"Protocols":["<tls-version>"] especifica una o más versiones de TLS, en una lista delimitada por comas. Por ejemplo, "Protocols":["TLSv1.2", "TLSv1.3"]

Por ejemplo:

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 no incluye la anotación oci.oraclecloud.com/oci-load-balancer-backendset-ssl-config, pero sí incluye la anotación service.beta.kubernetes.io/oci-load-balancer-tls-backendset-secret, se utiliza el conjunto de cifrado oci-wider-compatible-ssl-cipher-suite-v1.

Implantación de SSL/TLS entre el equilibrador de carga y los nodos de trabajador mediante secretos de Kubernetes

Los secretos de Kubernetes proporcionan una forma de gestionar certificados SSL/TLS localmente en el cluster para la comunicación de backend. Este método se utiliza cuando gestiona sus propios certificados o utiliza una autoridad de certificación de terceros para proteger el enlace entre el equilibrador de carga y los nodos de trabajador. Garantiza que el tráfico interno esté cifrado, pero requiere la rotación manual del certificado de CA almacenado en el secreto.

Para especificar el certificado que se va a asociar al juego de backends, agregue la siguiente anotación en la sección de metadatos del archivo de manifiesto:

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

donde <value> es el nombre de un secreto de Kubernetes que ha creado para contener un certificado firmado y la clave privada del certificado. Tenga en cuenta que debe crear el secreto de Kubernetes antes de crear el servicio, ya que el servicio hace referencia al secreto en su definición.

En el siguiente ejemplo se crea y utiliza un certificado autofirmado, que suele ser aceptable para la comunicación interna entre el equilibrador de carga y el juego de backends. Sin embargo, si lo prefiere, puede utilizar un certificado público firmado por una autoridad de certificación.

Por ejemplo:

Para generar una clave privada, introduzca:
openssl genrsa -out ca.key 2048
Genere un certificado introduciendo:
openssl req -x509 -new -nodes -key ca.key -subj "/CN=nginxsvc/O=nginxsvc" -days 10000 -out ca.crt
Almacene el certificado y la clave como secreto en Kubernetes introduciendo:
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
Defina un despliegue de Nginx y expórtelo mediante un equilibrador de carga que sirva http en el puerto 80 y https en el puerto 443.

Este ejemplo crea un equilibrador de carga de Oracle Cloud Infrastructure, definiendo un servicio con un tipo de 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
---
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 comunicación entre el equilibrador de carga y los nodos de trabajador del juego de backends se cifra mediante la clave y el certificado almacenados en el secreto de Kubernetes ca-ser-secret que ha creado anteriormente.

Especificación de unidades de computación de equilibrador de carga alternativas

La unidad de computación de un equilibrador de carga de Oracle Cloud Infrastructure especifica su ancho de banda total máximo (es decir, entrada más salida). Por defecto, los equilibradores de carga se crean con una unidad de computación de 100 Mbps. Hay otras unidades disponibles, incluidos 400 Mbps y 8000 Mbps.

Para especificar una unidad alternativa para un equilibrador de carga, agregue la siguiente anotación en la sección de metadatos del archivo de manifiesto:

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

donde value es el ancho de banda de la unidad de computación (por ejemplo, 100 Mbps, 400 Mbps, 8000 Mbps).

Por ejemplo:


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

Debe haber suficiente cuota de equilibrador de carga disponible en la región para la unidad de computación que especifique. Introduzca el siguiente comando de kubectl para confirmar que la creación del equilibrador de carga no ha fallado debido a la falta de cuota:

kubectl describe service <service-name>

Tenga en cuenta que Oracle recomienda implantar servicios de Kubernetes de tipo LoadBalancer como equilibradores de carga flexibles rentables en lugar de como equilibradores de carga de unidad fija (dinámicos) (consulte Especificación de unidades de equilibrador de carga flexibles).

Especificación de unidades de equilibrador de carga flexibles

La unidad de computación de un equilibrador de carga de Oracle Cloud Infrastructure especifica su ancho de banda total máximo (es decir, entrada más salida). Como se describe en Especificación de unidades de equilibrador de carga alternativas, puede especificar diferentes unidades de equilibrador de carga.

Además, también puede especificar una unidad flexible para un equilibrador de carga de Oracle Cloud Infrastructure definiendo un ancho de banda mínimo y máximo para el equilibrador de carga.

Para especificar una unidad flexible para un equilibrador de carga, agregue la siguiente anotación en la sección de metadatos del archivo de manifiesto:

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>"

donde:

"<min-value>" es el ancho de banda mínimo para el equilibrador de carga, en Mbps (por ejemplo, "10"
"<max-value>" es el ancho de banda máximo para el equilibrador de carga, en Mbps (por ejemplo, "100")

Tenga en cuenta que no debe incluir una unidad de medida al especificar valores de ancho de banda para unidades de equilibrador de carga flexibles (a diferencia de para las unidades predefinidas). Por ejemplo, especifique el ancho de banda mínimo como 10 en lugar de 10Mbps.

Por ejemplo:


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

Especificación de timeout de conexión de equilibrador de carga

Al aprovisionar un equilibrador de carga de Oracle Cloud Infrastructure para un servicio de Kubernetes de tipo LoadBalancer, puede especificar el tiempo máximo de inactividad (en segundos) permitido entre dos operaciones de recepción sucesivas o dos operaciones de envío sucesivas entre el cliente y los servidores backend.

Para especificar explícitamente un tiempo de inactividad máximo, agregue la siguiente anotación en la sección de metadatos del archivo de manifiesto:

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

donde value es el número de segundos.

Por ejemplo:


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

Tenga en cuenta que si no especifica explícitamente un tiempo de inactividad máximo, se utilizará un valor por defecto. El valor por defecto depende del tipo de listener:

para listeners TCP, el tiempo máximo de inactividad por defecto es 300 segundos
para listeners HTTP, el tiempo máximo de inactividad por defecto es 60 segundos

Especificación del número máximo de conexiones permitidas del equilibrador de carga a los servidores de backend

Al aprovisionar un equilibrador de carga de Oracle Cloud Infrastructure para un servicio de Kubernetes de tipo LoadBalancer, puede especificar el número máximo de conexiones simultáneas que el equilibrador de carga puede realizar en los servidores backend (nodos de trabajador) del juego de backends.

Para especificar explícitamente el número máximo de conexiones simultáneas que se permiten entre el equilibrador de carga y cada servidor backend individual del juego de backends, agregue la siguiente anotación en la sección de metadatos del archivo de manifiesto:

oci-load-balancer.oraclecloud.com/backendset-backend-max-connections: "<value>"

donde <value> es un valor válido para el número de conexiones permitidas, de la siguiente manera:

Un número entre "256" y "65535" (incluido). Si especifica un número fuera de este rango (aparte de 0), se devuelve un error.
"0". Si especifica 0 como el número máximo de conexiones permitidas, se permite un número infinito de conexiones entre el equilibrador de carga y cada servidor backend individual del juego de backends.

Por ejemplo:


apiVersion: v1
kind: Service
metadata:
  name: nginx-service
  annotations:
    oci-load-balancer.oraclecloud.com/backendset-backend-max-connections: "256"
spec:
  selector:
    app: nginx
  type: LoadBalancer
  ports:
    - name: http
      port: 80
      targetPort: 80

Tenga en cuenta lo siguiente:

El número que especifique para la anotación no solo se utiliza como valor de la propiedad backendMaxConnections del juego de backends, sino que también lo hereda cada servidor backend individual como valor de su propiedad maxConnections. Como resultado, el número que especifique se utiliza como el número de conexiones permitidas entre el equilibrador de carga y cada servidor backend individual del juego de backends, y no como el número total general de conexiones permitidas entre el equilibrador de carga y el juego de backends.
Si no incluye la anotación en el manifiesto (o, posteriormente, elimina la anotación), se permite un número infinito de conexiones entre el equilibrador de carga y cada servidor backend.
Para obtener información relacionada sobre la especificación del número máximo de conexiones simultáneas al listener del equilibrador de carga permitidas desde la misma dirección IP de origen, consulte Especificación del número máximo de reglas de conexión del listener.

Especificación de Reglas de Máximo de Conexiones de Listener

Cuando Kubernetes Engine aprovisiona un equilibrador de carga de Oracle Cloud Infrastructure para un servicio de Kubernetes de tipo LoadBalancer, puede especificar el número máximo de conexiones simultáneas al listener del equilibrador de carga que se permiten desde la misma dirección IP de origen. Puede utilizar una anotación para definir un valor de máximo de conexiones de listener por defecto que se aplique a todas las direcciones IP. La anotación define una regla de conexión máxima del listener para el equilibrador de carga. Si no define este valor máximo por defecto, no hay límite en el número de conexiones que una dirección IP puede realizar al listener.

Para obtener más información sobre las reglas de conexión máximas del listener, consulte Reglas de conexión máximas del listener en la documentación de OCI Load Balancer.

Para especificar el número máximo de conexiones de listener simultáneas que se permiten desde la misma dirección IP de origen, agregue la anotación oci.oraclecloud.com/oci-load-balancer-rule-sets en la sección de metadatos del archivo de manifiesto. Tenga en cuenta que especifica el valor de la anotación como JSON con formato, de la siguiente manera:

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

donde:

<rule-set-name> es el nombre que elija para el juego de reglas (entre 1 y 32 caracteres de longitud). Por ejemplo, IpLimitRuleSet .
<value> es el número máximo de conexiones simultáneas de listener que se permiten desde la misma dirección IP de origen.

Por ejemplo:


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: |
      {
        "IpLimitRuleSet": {
          "items": [
            {
              "action": "IP_BASED_MAX_CONNECTIONS",
              "maxConnectionsPerIp": 20
            }
          ]
        }
      }
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Esta configuración crea un juego de reglas de conexión de listener máximo denominado IpLimitRuleSet que restringe cada dirección IP de origen a un máximo de 20 conexiones simultáneas.

Para cambiar posteriormente el número máximo de conexiones simultáneas, actualice la anotación oci.oraclecloud.com/oci-load-balancer-rule-sets y vuelva a aplicar el manifiesto.

Al utilizar la anotación oci.oraclecloud.com/oci-load-balancer-rule-sets, tenga en cuenta lo siguiente:

Al aplicar un manifiesto que contiene la anotación oci.oraclecloud.com/oci-load-balancer-rule-sets, tenga en cuenta que Kubernetes Engine asume la gestión de todos los juegos de reglas del equilibrador de carga. Kubernetes Engine no solo agrega el juego de reglas especificado por la anotación, sino que también suprime cualquier otro juego de reglas asociado actualmente al equilibrador de carga.
Si posteriormente desea suprimir un juego de reglas, especifique un objeto JSON vacío como valor de la anotación oci.oraclecloud.com/oci-load-balancer-rule-sets de la siguiente forma:
```
oci.oraclecloud.com/oci-load-balancer-rule-sets: "{}"
```
Al especificar un objeto JSON vacío como valor de la anotación, el motor de Kubernetes suprime todos los juegos de reglas asociados al equilibrador de carga y abandona la gestión de los juegos de reglas del equilibrador de carga.
Si simplemente elimina la anotación oci.oraclecloud.com/oci-load-balancer-rule-sets del manifiesto y aplica el manifiesto, Kubernetes Engine renuncia a la gestión de los juegos de reglas del equilibrador de carga. Tenga en cuenta que si elimina la anotación, Kubernetes Engine no suprime ninguno de los juegos de reglas asociados al equilibrador de carga.
Si realiza cambios directos en los juegos de reglas del equilibrador de carga (que no se recomienda) en lugar de utilizar la anotación oci.oraclecloud.com/oci-load-balancer-rule-sets, tenga en cuenta el siguiente punto. Si posteriormente aplica un manifiesto que contiene la anotación oci.oraclecloud.com/oci-load-balancer-rule-sets, el motor de Kubernetes agrega el juego de reglas especificado por la anotación y suprime cualquier otro juego de reglas asociado al equilibrador de carga. Por lo tanto, si desea mantener los cambios directos que ha realizado en los juegos de reglas del equilibrador de carga, no incluya la anotación oci.oraclecloud.com/oci-load-balancer-rule-sets en el manifiesto.

Especificación de Reglas de Cabecera HTTP

Cuando Kubernetes Engine aprovisiona un equilibrador de carga para un servicio de Kubernetes de tipo LoadBalancer, puede especificar el tamaño máximo de la cabecera HTTP que aceptan los listeners del equilibrador de carga. Para especificar el tamaño máximo de la cabecera HTTP, utilice una anotación para especificar el tamaño (en KB) del buffer utilizado para leer la cabecera. Los valores permitidos para el tamaño de buffer son 8, 16, 32 y 64. La anotación define una regla de cabecera HTTP para el equilibrador de carga. La regla de cabecera HTTP se aplica a todos los listeners del equilibrador de carga, en todos los puertos.

Para obtener más información sobre las reglas de cabecera HTTP, consulte Reglas de cabecera HTTP en la documentación de OCI Load Balancer.

Para especificar el tamaño máximo de la cabecera HTTP aceptada por los listeners del equilibrador de carga, agregue la anotación oci.oraclecloud.com/oci-load-balancer-rule-sets en la sección de metadatos del archivo de manifiesto. Tenga en cuenta que especifica el valor de la anotación como JSON con formato, de la siguiente forma:

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

donde:

<rule-set-name> es el nombre que elige para el juego de reglas (entre 1 y 32 caracteres de longitud). Por ejemplo, header-size .
<value> es el tamaño máximo de la cabecera HTTP en KB y es uno de los siguientes: 8, 16, 32 o 64.

Por ejemplo:


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

Para cambiar posteriormente el tamaño máximo de la cabecera HTTP, actualice la anotación oci.oraclecloud.com/oci-load-balancer-rule-sets y vuelva a aplicar el manifiesto.

Al utilizar la anotación oci.oraclecloud.com/oci-load-balancer-rule-sets, tenga en cuenta lo siguiente:

Al aplicar un manifiesto que contiene la anotación oci.oraclecloud.com/oci-load-balancer-rule-sets, tenga en cuenta que Kubernetes Engine asume la gestión de todos los juegos de reglas del equilibrador de carga. Kubernetes Engine no solo agrega el juego de reglas especificado por la anotación, sino que también suprime cualquier otro juego de reglas asociado actualmente al equilibrador de carga.
Si posteriormente desea suprimir un juego de reglas, especifique un objeto JSON vacío como valor de la anotación oci.oraclecloud.com/oci-load-balancer-rule-sets de la siguiente forma:
```
oci.oraclecloud.com/oci-load-balancer-rule-sets: "{}"
```
Al especificar un objeto JSON vacío como valor de la anotación, el motor de Kubernetes suprime todos los juegos de reglas asociados al equilibrador de carga y deja de gestionar los juegos de reglas del equilibrador de carga.
Si simplemente elimina la anotación oci.oraclecloud.com/oci-load-balancer-rule-sets del manifiesto y aplica el manifiesto, Kubernetes Engine deja de gestionar los juegos de reglas del equilibrador de carga. Tenga en cuenta que si elimina la anotación, Kubernetes Engine no suprime ninguno de los juegos de reglas asociados al equilibrador de carga.
Si realiza cambios directos en los juegos de reglas del equilibrador de carga (que no se recomienda) en lugar de utilizar la anotación oci.oraclecloud.com/oci-load-balancer-rule-sets, tenga en cuenta el siguiente punto. Si posteriormente aplica un manifiesto que contiene la anotación oci.oraclecloud.com/oci-load-balancer-rule-sets, el motor de Kubernetes agrega el juego de reglas especificado por la anotación y suprime cualquier otro juego de reglas asociado al equilibrador de carga. Por lo tanto, si desea mantener los cambios directos que ha realizado en los juegos de reglas del equilibrador de carga, no incluya la anotación oci.oraclecloud.com/oci-load-balancer-rule-sets en el manifiesto.

Especificación de Protocolos de Listener

Cuando Kubernetes Engine aprovisiona un equilibrador de carga para un servicio de Kubernetes de tipo LoadBalancer, puede definir el tipo de tráfico aceptado por el listener especificando el protocolo en el que el listener acepta las solicitudes de conexión.

Tenga en cuenta que si no especifica explícitamente un protocolo, "TCP" se utilizará como valor por defecto.

Para especificar explícitamente el protocolo de listener de equilibrador de carga cuando Kubernetes Engine aprovisione un equilibrador de carga para un servicio de Kubernetes de tipo LoadBalancer, agregue la siguiente anotación en la sección de metadatos del archivo de manifiesto:

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

donde <value> es el protocolo que define el tipo de tráfico aceptado por el listener. Por ejemplo, "HTTP". Los protocolos válidos incluyen "HTTP", "TCP" y "GRPC".

Por ejemplo:


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

Tenga en cuenta que si especifica GRPC como protocolo, debe configurar las dos opciones siguientes:

SSL de frontend, mediante las anotaciones service.beta.kubernetes.io/oci-load-balancer-ssl-ports, oci.oraclecloud.com/oci-load-balancer-ssl-listener-config y service.beta.kubernetes.io/oci-load-balancer-tls-secret. Para obtener más información, consulte Terminación de SSL/TLS en el equilibrador de carga (SSL de frontend).
SSL de backend, mediante las anotaciones oci.oraclecloud.com/oci-load-balancer-backendset-ssl-config y service.beta.kubernetes.io/oci-load-balancer-tls-backendset-secret. Para obtener más información, consulte Implantación de SSL/TLS entre el equilibrador de carga y los nodos de trabajador (SSL de backend).

Por ejemplo:


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

Especificación de opciones de gestión de lista de seguridad al aprovisionar un equilibrador de carga de OCI

Nota

Puede encontrar escalabilidad y otros problemas si utiliza la función de gestión de lista de seguridad de Kubernetes en despliegues complejos y con herramientas como Terraform. Por estos motivos, Oracle no recomienda utilizar la función de gestión de lista de seguridad de Kubernetes en entornos de producción.

Tenga en cuenta también que la capacidad de utilizar listas de seguridad para gestionar reglas de seguridad quedará en desuso en futuras versiones. Por este motivo, Oracle recomienda el uso de grupos de seguridad de red (NSG) y la anotación oci.oraclecloud.com/security-rule-management-mode (consulte Especificación de opciones de gestión de reglas de seguridad para equilibradores de carga y equilibradores de carga de red).

Puede utilizar la función de gestión de listas de seguridad para configurar cómo se gestionan las reglas de listas de seguridad para un equilibrador de carga de Oracle Cloud Infrastructure aprovisionado por Kubernetes Engine para un servicio de Kubernetes de tipo LoadBalancer. Esta función es útil si es no está familiarizado con Kubernetes o para despliegues básicos.

Para especificar cómo la función de gestión de lista de seguridad de Kubernetes gestiona las listas de seguridad cuando Kubernetes Engine aprovisiona un equilibrador de carga para un servicio de Kubernetes de tipo LoadBalancer, agregue la siguiente anotación en la sección de metadatos del archivo de manifiesto:

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

donde <value> es uno de:

"None": (recomendado) no está activada la gestión de listas de seguridad. Debe configurar una regla de seguridad que permita tráfico entrante a los puertos adecuados para rangos de puertos de nodo, el puerto de estado de kube-proxy y los rangos de puertos de comprobación del sistema. Además, debe configurar reglas de seguridad para permitir tráfico entrante a equilibradores de carga (consulte Reglas de seguridad para equilibradores de carga y equilibradores de carga de red).
"All": (por defecto) todas las reglas de la lista de seguridad necesarias para los servicios de equilibrador de carga están gestionadas.
"Frontend": solo se gestionan reglas de lista de seguridad para entrada a servicios de equilibrador de carga. Debe configurar una regla de seguridad que permita tráfico entrante a los puertos adecuados para rangos de puertos de nodo, el puerto de estado de kube-proxy y los rangos de puertos de comprobación del sistema.

Oracle recomienda definir explícitamente service.beta.kubernetes.io/oci-load-balancer-security-list-management-mode en None.

En clusters con nodos gestionados, si no especifica explícitamente un modo de gestión o especifica un valor no válido, se gestionan todas las reglas de la lista de seguridad (equivalente a "All"). Tenga en cuenta que, en este caso, Kubernetes Engine crea una regla de seguridad que permite el tráfico entrante desde 0.0.0.0/0 (o desde los rangos de puertos de origen especificados en el archivo de manifiesto) a los puertos del listener. En clusters con nodos virtuales, la gestión de listas de seguridad nunca está activada y siempre tiene que configurar manualmente las reglas de seguridad (equivalente a "None").

Tenga en cuenta que hay límites en el número de reglas de entrada y salida permitidas en una lista de seguridad (consulte Límites de lista de seguridad). Si el número de reglas de entrada o salida supera el límite y <value> está definido en "All" o "Frontend", la creación o actualización del equilibrador de carga falla.

Por ejemplo:


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

Documentación de Oracle Cloud Infrastructure

Aprovisionamiento de equilibradores de carga de OCI para servicios de Kubernetes de tipo LoadBalancer

Especificación de la anotación para un equilibrador de carga de OCI

Terminación de SSL/TLS en el equilibrador de carga (SSL de frontend)

Elija un método de gestión de certificados para Frontend SSL

Configuración de conjuntos de cifrado y protocolos para listeners

Terminación de SSL/TLS en el equilibrador de carga mediante secretos de Kubernetes

Actualización de los certificados TLS de equilibradores de carga existentes mediante secretos de Kubernetes

Terminación de SSL/TLS en el equilibrador de carga mediante el servicio OCI Certificates

Requisitos para la integración de certificados de OCI

Configuración de la asignación de certificados

Ejemplo de manifiesto SSL de frontend

Implantación de SSL/TLS entre el equilibrador de carga y los nodos de trabajador (SSL de backend)

Método de gestión de certificados para SSL de backend

Configuración de conjuntos de cifrado y protocolos para juegos de backends

Implantación de SSL/TLS entre el equilibrador de carga y los nodos de trabajador mediante secretos de Kubernetes

Especificación de unidades de computación de equilibrador de carga alternativas

Especificación de unidades de equilibrador de carga flexibles

Especificación de timeout de conexión de equilibrador de carga

Especificación del número máximo de conexiones permitidas del equilibrador de carga a los servidores de backend

Especificación de Reglas de Máximo de Conexiones de Listener

Especificación de Reglas de Cabecera HTTP

Especificación de Protocolos de Listener

Especificación de opciones de gestión de lista de seguridad al aprovisionar un equilibrador de carga de OCI