Es posible que parte de la información de esta página (o toda) no se aplique a Cloud de Confiance de S3NS. Consulta Diferencias con Google Cloud para obtener más información.

Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Protege el tráfico de Ingress de GKE

Autopilot Standard

En esta página, se muestra cómo proteger y optimizar el tráfico para Ingress de Google Kubernetes Engine (GKE). Puedes configurar certificados SSL entre el cliente y el balanceador de cargas, y proteger el tráfico entre el balanceador de cargas y tu aplicación de backend. Antes de continuar, asegúrate de estar familiarizado con la forma en que GKE protege Ingress con HTTPS.

Esta página está dirigida a especialistas en herramientas de redes que diseñan la red para su organización y que instalan, configuran y admiten equipos de red. Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que hacemos referencia en el contenido deCloud de Confiance by S3NS , consulta Roles y tareas comunes del usuario de GKE.

Protege y optimiza el tráfico entre el cliente y el balanceador de cargas

Para aceptar solicitudes HTTPS de los clientes, el balanceador de cargas debe contar con un certificado para que pueda demostrar su identidad a los clientes. El balanceador de cargas también debe tener una clave privada para completar el protocolo de enlace HTTPS. Para obtener más información sobre cómo proporcionar certificados SSL a un balanceador de cargas de HTTP(S), consulta Configura TLS entre el cliente y el balanceador de cargas.

Usa certificados administrados por Google

Para configurar uno o más certificados SSL administrados por Google y asociarlos con un Ingress, debes seguir estos pasos:

Crea uno o más objetos ManagedCertificate en el mismo espacio de nombres que el Ingress. Puedes especificar hasta 15 certificados para el balanceador de cargas
Agrega la anotación networking.gke.io/managed-certificates al Ingress para asociar los objetos ManagedCertificate a un Ingress. Esta anotación es una lista separada por comas de objetos ManagedCertificate.

Limitaciones

En esta sección, se describen las limitaciones de los certificados administrados por Google. Si necesitas certificados autoadministrados o si ya posees certificados SSL que deseas configurar en el Ingress, consulta la sección sobre cómo configurar HTTPS (TLS) entre el cliente y el balanceador de cargas.

Los certificados administrados por Google son menos flexibles que los certificados que tú obtienes y administras. Los certificados administrados por Google admiten hasta 100 dominios sin comodines. A diferencia de los certificados autoadministrados, los certificados administrados por Google no admiten dominios comodines.
La cantidad y el tipo de certificados admitidos por un Ingress están definidos por los límites de los certificados SSL administrados por Google.
No se admiten las actualizaciones en los certificados administrados por Google. Para obtener más información, consulta Actualiza un certificado administrado por Google de forma manual.
Si el certificado se revoca directamente con la autoridad certificadora, Google no lo rotará de forma automática. Debes borrar el ManagedCertificate y crear uno nuevo.
Ingress de GKE no admite certificados administrados por el Administrador de certificados. Para usar certificados administrados por el Administrador de certificados, usa la API de Gateway.

Requisitos previos

Debes ser dueño del nombre de dominio. El nombre de dominio no debe tener más de 63 caracteres. Puedes usar cualquier registrador de nombres de dominio para obtener un nombre de dominio.

Nota: Google Domains ya no está en funcionamiento. Squarespace ahora administra los dominios que se compraron anteriormente en Google Domains. Puedes administrar tu dominio y sus registros DNS desde tu cuenta de Squarespace.
Si usas un clúster de GKE Standard, el complemento HttpLoadBalancing debe estar habilitado.
Tu manifiesto de Ingress debe incluir la anotación kubernetes.io/ingress.class: "gce". No se admite el campo ingressClassName.
Debes aplicar los recursos Ingress y ManagedCertificate en el mismo proyecto y espacio de nombres.
Crea una dirección IP externa (estática) reservada. Reservar una dirección IP estática ayuda a garantizar que te pertenece, incluso si borras el Ingress. Si no reservas una dirección IP, es posible que esta cambie y requiera que vuelvas a configurar los registros DNS de tu dominio. Usa Google Cloud CLI o la consola de Cloud de Confiance para crear una dirección IP reservada.
gcloud
Para crear una dirección IP reservada, ejecuta el siguiente comando:
gcloud compute addresses create ADDRESS_NAME --global
Reemplaza ADDRESS_NAME por el nombre de la dirección IP reservada que creas.

Para encontrar la dirección IP estática que creaste, ejecuta el siguiente comando:
gcloud compute addresses describe ADDRESS_NAME --global
El resultado es similar a este:
address: 203.0.113.32 ...
Console
Para crear una dirección IP reservada, sigue estos pasos:
1. Ve a la página Direcciones IP externas en la consola de Cloud de Confiance .
  
  Ir a Direcciones IP externas
2. Especifica un nombre para la dirección IP (por ejemplo, example-ip-address).
3. Especifica si deseas una dirección IPv4 o IPv6.
4. Selecciona la opción Global para Tipo.
5. Haz clic en Reservar. La dirección IP aparece en la columna Dirección externa.
Config Connector
Nota: En este paso, se necesita Config Connector. Sigue las instrucciones de instalación para instalar Config Connector en el clúster.
apiVersion: compute.cnrm.cloud.google.com/v1beta1 kind: ComputeAddress metadata: name: example-ip-address spec: location: global
Para implementar este manifiesto, descárgalo en tu máquina como compute-address.yaml y ejecuta lo siguiente:
kubectl apply -f compute-address.yaml

Configura un certificado administrado por Google

Crea un objeto ManagedCertificate. Este recurso especifica los dominios para el certificado SSL. Los dominios de comodín no son compatibles.

En el siguiente manifiesto, se describe un objeto ManagedCertificate. Guarda el manifiesto como managed-cert.yaml.
```
apiVersion: networking.gke.io/v1
kind: ManagedCertificate
metadata:
  name: FIRST_CERT_NAME
spec:
  domains:
    - FIRST_DOMAIN
---
apiVersion: networking.gke.io/v1
kind: ManagedCertificate
metadata:
  name: SECOND_CERT_NAME
spec:
  domains:
    - SECOND_DOMAIN
```
Reemplaza lo siguiente:
- FIRST_CERT_NAME: Es el nombre de tu primer objeto ManagedCertificate.
- FIRST_DOMAIN: Es el primer dominio que posees.
- SECOND_CERT_NAME: Es el nombre del segundo objeto ManagedCertificate.
- SECOND_DOMAIN: Es el segundo dominio que posees.
Los nombres de los objetos ManagedCertificate son diferentes de los nombres de los certificados reales que crean. Solo necesitas conocer los nombres de los objetos ManagedCertificate para usarlos en tu Ingress.
Aplica el manifiesto al clúster:
```
kubectl apply -f managed-cert.yaml
```
Sigue las instrucciones para crear un Deployment y un Service y, así, exponer tu aplicación a Internet.

Para que este objeto ManagedCertificate se convierta en Active, adjúntalo a tu Ingress con la anotación networking.gke.io/managed-certificates, como en el siguiente ejemplo. No es necesario que ManagedCertificate sea Active para que puedas conectarlo a un Ingress. Si migras un Ingress existente desde certificados autoadministrados, sigue los pasos que se indican en Migra a certificados administrados por Google desde certificados autoadministrados.

 apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:
   name: my-gmc-ingress
   annotations:
     networking.gke.io/managed-certificates: "FIRST_CERT_NAME,SECOND_CERT_NAME"
 spec:
   rules:
   - host: FIRST_DOMAIN
     http:
       paths:
       - pathType: ImplementationSpecific
         backend:
           service:
             name: my-mc-service
             port:
               number: 60001
   - host: SECOND_DOMAIN
     http:
       paths:
       - pathType: ImplementationSpecific
         backend:
           service:
             name: my-mc-service
             port:
               number: 60002
 ```

Replace <code><var>FIRST_DOMAIN</var></code> and
<code><var>SECOND_DOMAIN</var></code> with your domain names.

This manifest describes an Ingress that lists pre-shared certificate
resources in an annotation.

Note: It might take several hours for Cloud de Confiance to provision the load
balancer and the managed certificates, and for the load balancer to begin
using the new certificates. For more information, see
[Deploy a Google-managed certificate with load balancer authorization](/certificate-manager/docs/deploy-google-managed-lb-auth#wait_until_the_certificate_has_been_activated).

Espera a que los certificados administrados por Google terminen de aprovisionarse. Este proceso puede llevar hasta 60 minutos. Puedes verificar el estado de los certificados con el siguiente comando:
```
kubectl describe managedcertificate managed-cert
```
El resultado es similar a lo siguiente:
```
Name:         managed-cert
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1
Kind:         ManagedCertificate
(...)
Spec:
 Domains:
   FQDN_1
   FQDN_2
Status:
 CertificateStatus: Active
(...)
```
El valor del campo Status.CertificateStatus indica que se aprovisionó el certificado. Si Status.CertificateStatus no es Active, el certificado aún no se aprovisionó.
Para verificar que SSL funcione, visita los dominios con el prefijo https://. Tu navegador indica que la conexión es segura y puedes ver los detalles del certificado.

Migra a certificados administrados por Google desde certificados autoadministrados

Cuando migras un Ingress desde el uso de certificados SSL autoadministrados a certificados SSL administrados por Google, no quites los certificados SSL autoadministrados antes de que los certificados SSL administrados por Google se activen.

Para migrar de certificados SSL autoadministrados a certificados SSL administrados por Google sin interrumpir el tráfico, sigue estos pasos:

Crea un recurso ManagedCertificate y aplícalo a tu clúster, como se describe en Configura un certificado administrado por Google.
Actualiza el manifiesto de Ingress para agregar la anotación networking.gke.io/managed-certificates que apunta al nuevo recurso ManagedCertificate. Mantén tu certificado autoadministrado existente en la anotación ingress.gcp.kubernetes.io/pre-shared-cert, como en el siguiente ejemplo:
```
metadata:
  annotations:
    ingress.gcp.kubernetes.io/pre-shared-cert: "EXISTING_SELF_MANAGED_CERT_NAME"
    networking.gke.io/managed-certificates: "NEW_MANAGED_CERT_NAME"
```
Reemplaza lo siguiente:
- EXISTING_SELF_MANAGED_CERT_NAME: el nombre de tu recurso de certificado SSL autoadministrado existente.
- NEW_MANAGED_CERT_NAME: Es el nombre de tu objeto ManagedCertificate nuevo.
Advertencia: No borres la anotación ingress.gcp.kubernetes.io/pre-shared-cert de tu manifiesto de Ingress. El controlador ManagedCertificate de GKE usa esta anotación en el recurso Ingress para adjuntar certificados administrados por Google al balanceador de cargas. Si borras la anotación, se quitarán todos los certificados del balanceador de cargas y se puede producir una interrupción del servicio mientras el controlador concilia el estado.
Aplica el manifiesto de Ingress actualizado:
```
kubectl apply -f INGRESS_MANIFEST.yaml
```
Reemplaza INGRESS_MANIFEST por el nombre de tu archivo de manifiesto de Ingress.

El controlador ManagedCertificate crea el recurso de certificado SSL de Compute Engine (con un nombre generado que comienza con mcrt-) después de que creas el recurso ManagedCertificate. La aplicación del manifiesto de Ingress activa una sincronización, que agrega el nombre del certificado mcrt- generado a la anotación ingress.gcp.kubernetes.io/pre-shared-cert en el Ingress activo para que el controlador de Ingress lo adjunte al proxy de destino del balanceador de cargas. Mientras Cloud de Confiance aprovisiona el certificado nuevo, el balanceador de cargas sigue entregando tráfico con el certificado autoadministrado activo existente que definiste en la anotación ingress.gcp.kubernetes.io/pre-shared-cert.
Espera hasta que el estado del recurso ManagedCertificate sea Active, lo que puede tardar hasta 60 minutos. Una vez que finaliza el aprovisionamiento, el certificado autoadministrado y el certificado administrado por Google están activos en el balanceador de cargas. Verifica el estado y recupera el ID del certificado mcrt- generado describiendo el recurso ManagedCertificate:
```
kubectl describe managedcertificate NEW_MANAGED_CERT_NAME
```
El resultado es similar a lo siguiente:
```
Name:         NEW_MANAGED_CERT_NAME
Namespace:    default
(...)
Spec:
  Domains:
    DOMAIN
Status:
  Certificate Name:    MCRT_CERT_ID
  Certificate Status:  Active
  Domain Status:
    Domain:  DOMAIN
    Status:  Active
```
Toma nota del valor del campo Certificate Name en la sección Status (por ejemplo, mcrt-a1b2c3d4-e5f6-7890-abcd-ef1234567890).
En el manifiesto de Ingress, reemplaza el ID del certificado autoadministrado que se encuentra en la anotación ingress.gcp.kubernetes.io/pre-shared-cert por el ID del certificado administrado por Google:
```
metadata:
  annotations:
    ingress.gcp.kubernetes.io/pre-shared-cert: "MCRT_CERT_ID"
    networking.gke.io/managed-certificates: "NEW_MANAGED_CERT_NAME"
```
Reemplaza MCRT_CERT_ID por el valor de Certificate Name (que comienza con mcrt-) del paso anterior.
Aplica el manifiesto de Ingress actualizado:
```
kubectl apply -f INGRESS_MANIFEST.yaml
```
Cuando aplicas este cambio, se desconecta el certificado autoadministrado antiguo del balanceador de cargas, mientras que se mantiene el certificado administrado por Google activo (MCRT_CERT_ID) conectado en la anotación ingress.gcp.kubernetes.io/pre-shared-cert. Este cambio cambia todo el tráfico al certificado administrado por Google sin interrupciones.
Después de desconectar el certificado autoadministrado anterior del balanceador de cargas, puedes borrarlo de forma segura si ya no es necesario, ya que el controlador de Ingress no administra ni recopila como elementos no utilizados los recursos de certificado SSL de Compute Engine precompartidos:
```
gcloud compute ssl-certificates delete EXISTING_SELF_MANAGED_CERT_NAME
```

Para evitar problemas de conciliación de anotaciones y obtener compatibilidad integrada con los certificados comodín, migra de Ingress a la API de GKE Gateway combinada con el Administrador de certificados.

Quita un certificado administrado por Google

Para quitar un certificado administrado por Google de tu clúster, debes borrar el objeto ManagedCertificate y quitar la anotación de Ingress que hace referencia a él.

Borra el objeto ManagedCertificate:

kubectl delete -f managed-cert.yaml

El resultado es similar a lo siguiente:

managedcertificate.networking.gke.io "managed-cert" deleted

Quita la anotación del Ingress:

kubectl annotate ingress managed-cert-ingress networking.gke.io/managed-certificates-

Observa el signo menos, -, al final del comando.

Libera la dirección IP estática que reservaste para tu balanceador de cargas.

Puedes usar Google Cloud CLI, la consola de Cloud de Confiance o Config Connector para liberar una dirección IP reservada.
gcloud
Usa el siguiente comando para liberar la dirección IP reservada:
gcloud compute addresses delete ADDRESS_NAME --global
Reemplaza ADDRESS_NAME por el nombre de la dirección IP.
Console
Para liberar la dirección IP reservada, sigue estos pasos:
1. Ve a la página Direcciones IP externas en la consola de Cloud de Confiance .
  
  Ir a Direcciones IP externas
2. Selecciona la casilla de verificación junto a la dirección IP que deseas liberar.
3. Haz clic en Liberar dirección IP.
Config Connector
Nota: En este paso, se necesita Config Connector. Sigue las instrucciones de instalación para instalar Config Connector en el clúster.
apiVersion: compute.cnrm.cloud.google.com/v1beta1 kind: ComputeAddress metadata: name: example-ip-address spec: location: global
Para implementar este manifiesto, descárgalo en tu máquina como compute-address.yaml y ejecuta lo siguiente:
kubectl delete -f compute-address.yaml

Crea certificados y claves

Para usar certificados previamente compartidos o Secrets de Kubernetes, primero necesitas uno o más certificados con las claves privadas correspondientes. Cada certificado debe tener un nombre común (CN, por sus siglas en inglés) que sea igual a un nombre de dominio de tu propiedad. Si ya tienes dos archivos de certificado con los valores adecuados para el nombre común, puedes pasar a la siguiente sección.

Crea tu primera clave:

openssl genrsa -out test-ingress-1.key 2048

Crea tu primera solicitud de firma de certificado:
```
openssl req -new -key test-ingress-1.key -out test-ingress-1.csr \
    -subj "/CN=FIRST_DOMAIN"
```
Reemplaza FIRST_DOMAIN por un nombre de dominio de tu propiedad, como example.com.

Crea el primer certificado:

openssl x509 -req -days 365 -in test-ingress-1.csr -signkey test-ingress-1.key \
    -out test-ingress-1.crt

Crea tu segunda clave:

openssl genrsa -out test-ingress-2.key 2048

Crea tu segunda solicitud de firma de certificado:
```
openssl req -new -key test-ingress-2.key -out test-ingress-2.csr \
    -subj "/CN=SECOND_DOMAIN"
```
Reemplaza SECOND_DOMAIN por otro nombre de dominio de tu propiedad, como examplepetstore.com.

Crea el segundo certificado:

openssl x509 -req -days 365 -in test-ingress-2.csr -signkey test-ingress-2.key \
    -out test-ingress-2.crt

Para obtener más información sobre los certificados y las claves, consulta la Descripción general de certificados SSL.

Ahora tienes dos archivos de certificado y dos archivos de claves.

En las tareas restantes, se usan los siguientes marcadores de posición para hacer referencia a tus dominios, certificados y claves:

FIRST_CERT_FILE es la ruta de acceso a tu primer archivo de certificado.
FIRST_KEY_FILE es la ruta al archivo de claves que acompaña a tu primer certificado.
FIRST_DOMAIN es un nombre de dominio de tu propiedad.
FIRST_SECRET_NAME: El nombre del Secret que contiene tu primer certificado y clave.
SECOND_CERT_FILE es la ruta a tu segundo archivo de certificado.
SECOND_KEY_FILE es la ruta al archivo de claves que acompaña a tu segundo certificado.
SECOND_DOMAIN es un segundo nombre de dominio de tu propiedad.
SECOND_SECRET_NAME: El nombre del Secret que contiene tu segundo certificado y clave.

Usa certificados ya compartidos

Puedes usar certificados SSL autoadministrados que subas a tu proyecto de Cloud de Confiance . Estos se denominan certificados ya compartidos. Puedes especificar uno o más certificados previamente compartidos para un Ingress.

Para usar varios certificados previamente compartidos, sigue estos pasos:

Para cada uno de tus pares de certificados y claves, crea un recurso de certificado SSL visible de forma pública en Cloud de Confiance.
```
 gcloud compute ssl-certificates create FIRST_CERT_NAME \
     --certificate=FIRST_CERT_FILE \
     --private-key=FIRST_KEY_FILE
 ```

```sh
 gcloud compute ssl-certificates create SECOND_CERT_NAME \
     --certificate=SECOND_CERT_FILE \
     --private-key=SECOND_KEY_FILE
 ```

Replace the following:
```
- FIRST_CERT_NAME, SECOND_CERT_NAME: Son los nombres de tu primer y segundo certificado.
- FIRST_CERT_FILE, SECOND_CERT_FILE: Son el primer y el segundo archivo de certificado.
- FIRST_KEY_FILE:, SECOND_KEY_FILE: Son el primer y el segundo archivo de claves.

En el manifiesto de Ingress, agrega la anotación ingress.gcp.kubernetes.io/pre-shared-cert. El valor de la anotación es una lista separada por comas de los nombres de tus certificados. Además, en la sección spec.rules, incluye los campos host para especificar los dominios de tus servicios.

 apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:
   name: my-psc-ingress
   annotations:
     ingress.gcp.kubernetes.io/pre-shared-cert: "FIRST_CERT_NAME,SECOND_CERT_NAME"
 spec:
   rules:
   - host: FIRST_DOMAIN
     http:
       paths:
       - pathType: ImplementationSpecific
         backend:
           service:
             name: my-mc-service
             port:
               number: 60001
   - host: SECOND_DOMAIN
     http:
       paths:
       - pathType: ImplementationSpecific
         backend:
           service:
             name: my-mc-service
             port:
               number: 60002
 ```

Replace <code><var>FIRST_DOMAIN</var></code> and
<code><var>SECOND_DOMAIN</var></code> with your domain names.

This manifest describes an Ingress that lists pre-shared certificate
resources in an annotation.

Usa Secrets de Kubernetes

Para proporcionar un balanceador de cargas de HTTP(S) con certificados y claves que hayas creado tú, crea uno o más objetos Secret de Kubernetes. Cada Secret contiene un certificado y una clave. Debes agregar los Secrets al campo tls del manifiesto de Ingress. El balanceador de cargas usa la indicación de nombre del servidor (SNI) para determinar qué certificado presentar al cliente, según el nombre de dominio en el protocolo de enlace TLS.

Para usar varios certificados, sigue estos pasos:

Crea un Secret para cada uno de tus pares de certificado y clave:

 kubectl create secret tls FIRST_SECRET_NAME \
     --cert=FIRST_CERT_FILE \
     --key=FIRST_KEY_FILE
 ```

```sh
 kubectl create secret tls SECOND_SECRET_NAME \
     --cert=SECOND_CERT_FILE \
     --key=SECOND_KEY_FILE
 ```

En el manifiesto de Ingress, en la sección spec.tls, enumera los Secrets que creaste. Además, en la sección spec.rules, incluye los campos host para especificar los dominios de tus servicios.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-mc-ingress
spec:
  tls:
  - secretName: FIRST_SECRET_NAME
  - secretName: SECOND_SECRET_NAME
  rules:
  - host: FIRST_DOMAIN
    http:
      paths:
      - pathType: ImplementationSpecific
        backend:
          service:
            name: my-mc-service
            port:
              number: 60001
  - host: SECOND_DOMAIN
    http:
      paths:
      - pathType: ImplementationSpecific
        backend:
          service:
            name: my-mc-service
            port:
              number: 60002

Reemplaza FIRST_DOMAIN y SECOND_DOMAIN por nombres de dominio de tu propiedad, como example.com y examplepetstore.com.

Los cambios en los secretos se captan de manera periódica, así que, si modificas los datos dentro del secreto, esos cambios se aplicarán en el balanceador de cargas en un máximo de 10 minutos.

Para proteger el Ingress encriptado con HTTPS en tus clústeres de GKE, consulta el ejemplo Ingress seguro.

Inhabilita HTTP

Si deseas que todo el tráfico entre el cliente y el balanceador de cargas use HTTPS, puedes inhabilitar HTTP incluyendo la anotación kubernetes.io/ingress.allow-http en tu manifiesto de Ingress. Establece el valor de la anotación en "false".

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress-2
  annotations:
    kubernetes.io/ingress.allow-http: "false"
spec:
  tls:
  - secretName: SECRET_NAME
  ...

Este manifiesto incluye el SECRET_NAME que es el nombre del Secret que creaste.

HTTP/2 entre el cliente y el balanceador de cargas

Los clientes pueden usar HTTP/2 para enviar solicitudes al balanceador de cargas. No se requiere configuración.

Protege y optimiza el tráfico entre el balanceador de cargas y la aplicación

Puedes configurar el protocolo que se usa para la comunicación entre el balanceador de cargas y los Pods de tu aplicación para garantizar la seguridad de extremo a extremo o para optimizar el rendimiento del tráfico interno. Si bien el balanceador de cargas usa HTTP/1.1 sin encriptar de forma predeterminada para las conexiones de backend, puedes habilitar HTTPS o HTTP/2 para cumplir con los requisitos específicos de tu aplicación.

HTTPS entre el balanceador de cargas y la aplicación

Si tu aplicación que se ejecuta en un pod de GKE es capaz de recibir solicitudes HTTPS, puedes configurar el balanceador de cargas para que use HTTPS cuando reenvíe solicitudes a tu aplicación. Para obtener más información, consulta HTTPS (TLS) entre el balanceador de cargas y la aplicación.

Para configurar el protocolo que se usa entre el balanceador de cargas y tu aplicación, debes usar la anotación cloud.google.com/app-protocols en el manifiesto del Service. Este manifiesto de este Service debe incluir type: NodePort, a menos que uses el balanceo de cargas nativo del contenedor. Si usas el balanceo de cargas nativo del contenedor, usa type: ClusterIP.

El siguiente manifiesto del Service especifica dos puertos. La anotación indica que cuando un balanceador de cargas HTTP(S) se dirige al puerto 80 del servicio, se debe usar HTTP. Y cuando el balanceador de cargas se dirige al puerto 443 del Service, se debe usar HTTPS.

El manifiesto del Service debe incluir un valor name en la anotación del puerto. Solo puedes editar el puerto del Service si haces referencia a su name asignado, no a su valor targetPort.

apiVersion: v1
kind: Service
metadata:
  name: my-service-3
  annotations:
    cloud.google.com/app-protocols: '{"my-https-port":"HTTPS","my-http-port":"HTTP"}'
spec:
  type: NodePort
  selector:
    app: metrics
    department: sales
  ports:
  - name: my-https-port
    port: 443
    targetPort: 8443
  - name: my-http-port
    port: 80
    targetPort: 50001

Usa HTTP/2 entre el balanceador de cargas y la aplicación

Si tu aplicación, que se ejecuta en un Pod de GKE, puede recibir solicitudes HTTP/2, puedes configurar el balanceador de cargas para que use HTTP/2 cuando reenvíe solicitudes a tu aplicación.

Para habilitar HTTP/2, debes usar la anotación cloud.google.com/app-protocols en el manifiesto del Service de Kubernetes. Esta anotación especifica el protocolo que usa el balanceador de cargas para comunicarse con tu aplicación. Para garantizar que el balanceador de cargas realice una solicitud HTTP/2 correcta a tu backend, este debe estar configurado con SSL.

El siguiente es un ejemplo de un manifiesto de Service configurado para HTTP/2:

apiVersion: v1
kind: Service
metadata:
  name: my-http2-service
  annotations:
    cloud.google.com/app-protocols: '{"my-port":"HTTP2"}'
spec:
  type: NodePort
  selector:
    app: my-app
  ports:
  - name: my-port
    protocol: TCP
    port: 443
    targetPort: 8443

Ten en cuenta lo siguiente:

La anotación cloud.google.com/app-protocols se establece en '{"my-port":"HTTP2"}', lo que indica al balanceador de cargas que use HTTP/2 para el tráfico enviado al puerto llamado my-port.
El puerto se establece en 443 y dirige el tráfico a los Pods en targetPort 8443.