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

Implementación de referencia del balanceo de cargas de la capa 7 de HAProxy

Google Distributed Cloud (GDC) air-gapped proporciona un balanceador de cargas de capa 4 (L4) administrado integrado, pero muchas aplicaciones empresariales requieren capacidades avanzadas de capa 7 (L7), como el enrutamiento basado en el host, la administración centralizada de TLS y la división compleja del tráfico. Históricamente, esto se logra con la API de Ingress, que ahora se considera una función inmovilizada en la comunidad de Kubernetes.

Esta arquitectura de referencia proporciona una solución de balanceo de cargas de capa 7 autoadministrada. Cuando implementan el popular controlador de código abierto HAProxy en un clúster estándar de GDC, los clientes pueden enrutar sin problemas el tráfico de L7 a entornos híbridos. Esta arquitectura usa la finalización de TLS (HTTPRoute) para enrutar el tráfico según la indicación del nombre del servidor (SNI) a los pods y las aplicaciones alojadas en contenedores integrados en máquinas virtuales externas.

Arquitectura

Diagrama de arquitectura para el balanceo de cargas de capa 7 de HAProxy en GDC aislado del aire.

Los componentes clave de la solución incluyen lo siguiente:

Cliente: Es una entidad que inicia solicitudes HTTPS para interactuar con las aplicaciones.
Clúster estándar de GDC: GDC proporciona una forma integrada de crear clústeres de Kubernetes Vanilla. En esta solución, el clúster alojará el LB de L7 y sus controladores, junto con las cargas de trabajo y el servicio sin interfaz gráfica para las VMs externas.
Balanceador de cargas de L4 de GDC: Es el balanceador de cargas de L4 integrado que actúa como punto de entrada y distribuye el tráfico TCP/443 directamente a los pods de Kubernetes que ejecutan los controladores.
Controladores de Ingress: Son operadores de HAProxy que se ejecutan en el clúster estándar. Supervisan los recursos Ingress y actualizan de forma dinámica los proxies subyacentes. El controlador de Ingress de HAProxy se usará en la siguiente implementación.
Ingress: Son recursos estandarizados de Kubernetes que definen el puerto de escucha físico (443) y las reglas de enrutamiento de host basadas en SNI con finalización de TLS.
Carga de trabajo alojada en contenedores (pods): Es una implementación estándar de Kubernetes expuesta de forma interna con un Service normal de Kubernetes.
Carga de trabajo basada en VM (externa): Es una carga de trabajo alojada en una VM externa en la red del proyecto, expuesta al proxy con un Service de Kubernetes sin interfaz gráfica y un extremo personalizado que contiene la IP directa de la VM.
Registro de Harbor: Es un registro de contenedores privado que se usa para almacenar y entregar las imágenes de proxy y de aplicación en el entorno aislado.

En el clúster estándar, crea tres espacios de nombres:

El espacio de nombres load-balancer aloja el controlador de Ingress de HAProxy y la carga de trabajo del balanceador de cargas de HAProxy:
El espacio de nombres hello-app aloja la Deployment, un Service y un Ingress para la carga de trabajo del contenedor de demostración:
El espacio de nombres vm-app aloja un servicio sin interfaz gráfica que expone la IP de la VM externa, un EndpointSlice que apunta a la IP externa y un Ingress:

Antes de comenzar

Antes de implementar esta solución, asegúrate de cumplir con los siguientes requisitos previos:

Software necesario: helm, docker, kubectl

Acceso a la CLI y configuración local: Descarga la CLI de gdcloud desde la consola de GDC y configura tu entorno de forma local:

export USER_NAME="USER_NAME"
export PROJECT_ID="PROJECT_ID"
export ZONE="ZONE"
export ORG_NAME="ORG_NAME"
export GDC_URL="GDC_URL"

gdcloud components install gdcloud-k8s-auth-plugin

gdcloud config set core/organization_console_url \
  https://console.$ORG_NAME.$ZONE.$GDC_URL
gdcloud config set core/zone $ZONE
gdcloud config set core/project ${PROJECT_ID}

gdcloud auth login # use --login-config-cert option in case of TLS error

Configuración del proyecto: Crea un proyecto en tu entorno GDC aislado para alojar los recursos:
```
gdcloud projects create $PROJECT_ID
```

Roles de IAM: Otorga a tu usuario los roles Administrador del clúster y Administrador del clúster estándar para administrar los recursos de Kubernetes, y el rol Administrador de instancias de Harbor para enviar imágenes:

# Grant standard cluster and cluster admin roles
gdcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member="user:${USER_NAME}" \
  --role=cluster-admin

gdcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member="user:${USER_NAME}" \
  --role=standard-cluster-admin

# Grant Harbor instance admin role
gdcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member="user:${USER_NAME}" \
  --role=harbor-instance-admin

Crea un clúster estándar

En esta sección, se te guiará por el proceso de configuración de un clúster estándar de Kubernetes en tu entorno de GDC aislado. Un clúster estándar proporciona una base flexible y sólida para implementar varias cargas de trabajo, incluido el controlador de Ingress de HAProxy y tus aplicaciones personalizadas. Los siguientes pasos garantizarán que tu clúster esté configurado correctamente y sea accesible para las implementaciones posteriores.

Para identificar los tipos de imágenes de máquina virtual disponibles, ejecuta lo siguiente:
```
gdcloud compute machine-types list
```
Selecciona un tipo de máquina adecuado para los nodos de trabajador del clúster. Para este instructivo, se recomienda un tipo de máquina con al menos 4 CPUs virtuales.
```
export MACHINE_TYPE="MACHINE_TYPE"
```

Obtén el kubeconfig del servidor de la API de administración y establece un alias:

export CLUSTER_NAME="CLUSTER_NAME"

KUBECONFIG=kubeconfig-admin.yaml gdcloud clusters \
  get-credentials ${ORG_NAME}-admin

alias km="kubectl --kubeconfig kubeconfig-admin.yaml"

Crea un clúster estándar con dos nodos de trabajador:

km create -f - <<EOF
apiVersion: cluster.gdc.goog/v1
kind: Cluster
metadata:
  name: ${CLUSTER_NAME}
  namespace: ${PROJECT_ID}
spec:
  nodePools:
  - machineTypeName: ${MACHINE_TYPE}
    nodeCount: 2
    name: ${CLUSTER_NAME}-node-pool
EOF

Para obtener más detalles sobre las opciones disponibles, consulta la documentación.

La creación de clústeres estándar puede tardar hasta 60 minutos en completarse. Para verificar el estado, usa el siguiente comando:

km get clusters/${CLUSTER_NAME} \
  -n ${PROJECT_ID} \
  --watch

Cuando el clúster esté listo, el resultado debe mostrar un estado de Running, como este:

NAME         STATE     K8S VERSION
my-cluster   Running   1.30.12-gke.300

Cuando el clúster esté listo, recupera sus credenciales:

KUBECONFIG=kubeconfig-${CLUSTER_NAME}.yaml gdcloud clusters \
  get-credentials ${CLUSTER_NAME} \
  --standard \
  --project ${PROJECT_ID} \
  --zone ${ZONE}

Crea un alias para que los comandos kubectl sean más concisos en el resto de esta guía. Este alias se usará para interactuar con el clúster estándar:
```
alias kk="kubectl --kubeconfig kubeconfig-${CLUSTER_NAME}.yaml"
```
Crea espacios de nombres para el controlador, la app alojada en contenedores de demostración "hello-app" y la app de demo basada en VM:
```
kk create namespace load-balancer
kk create namespace hello-app
kk create namespace vm-app
```

Crea e integra el registro de Harbor

Harbor es un registro de imágenes de contenedor con compatibilidad integrada en GDC air-gapped. En esta sección, se te guiará por los pasos para integrar un registro de Harbor con tu clúster estándar, incluida la configuración de credenciales y secretos para permitir la extracción y el envío seguros de imágenes.

Crea una instancia de Harbor en tu proyecto.
Crea un proyecto de Harbor en tu instancia de Harbor.

Establece las variables de entorno:

export HARBOR_INSTANCE_NAME="HARBOR_INSTANCE_NAME"
export HARBOR_INSTANCE_URL="HARBOR_INSTANCE_URL"
export HARBOR_PROJECT="HARBOR_PROJECT"
export IMAGE_PULL_SECRET_NAME="harbor-secret"

Accede a la instancia de Harbor con una cuenta de robot:

docker --config=./docker login ${HARBOR_INSTANCE_URL}

Crea los secretos en el clúster estándar:

kk create secret docker-registry ${IMAGE_PULL_SECRET_NAME} \
  --from-file=.dockerconfigjson=./docker/config.json \
  -n load-balancer

kk create secret docker-registry ${IMAGE_PULL_SECRET_NAME} \
  --from-file=.dockerconfigjson=./docker/config.json \
  -n hello-app

Implementa la app alojada en contenedores de demostración

En esta sección, se detalla la implementación de una aplicación alojada en contenedores de demostración (hello-app) en tu clúster de Kubernetes aislado de GDC. Crearás los recursos necesarios de implementación y servicio de Kubernetes para ejecutar hello-app y exponerla de forma interna en el clúster, lo que la preparará para el acceso con el balanceador de cargas de L7.

Sube una imagen de muestra para la app alojada en contenedores de demostración a Harbor:

docker pull gcr.io/google-samples/hello-app:1.0 \
  --platform linux/amd64
docker tag gcr.io/google-samples/hello-app:1.0 \
  ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/hello-app:1.0
docker --config=./docker push \
  ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/hello-app:1.0

Implementa el siguiente manifiesto en el clúster estándar:

cat << EOF > hello-app.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-app
  namespace: hello-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: hello-app
  template:
    metadata:
      labels:
        app: hello-app
    spec:
      containers:
      - name: hello-server
        image: ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/hello-app:1.0
        ports:
        - containerPort: 8080
      imagePullSecrets:
      - name: ${IMAGE_PULL_SECRET_NAME}
---
apiVersion: v1
kind: Service
metadata:
  name: hello-app
  namespace: hello-app
spec:
  type: ClusterIP
  selector:
    app: hello-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
EOF

kk apply -f hello-app.yaml

Luego, verifica que la implementación y el servicio estén allí.

kk get svc,deploy -n hello-app

Implementa la app de demo en una VM

En esta sección, se detalla la implementación de una aplicación de demostración en una máquina virtual (VM) fuera de tu clúster de Kubernetes. Si configuras un servidor HTTP en una VM, simularás una aplicación externa que el balanceador de cargas puede exponer, lo que demuestra su capacidad para administrar el tráfico a los recursos dentro y fuera del clúster.

Primero, crea una VM para la app de demo:

Abre la consola de GDC en tu navegador web.
Selecciona el mismo proyecto en el que creaste tu clúster estándar de Kubernetes.
Abre el menú y, luego, haz clic en Máquinas virtuales.
Haz clic en Crear instancia.
Asigna el nombre vm-workload a la VM. Una imagen de 2 CPUs virtuales es suficiente para el ejemplo.
Para la imagen del disco de arranque, selecciona una distribución de Ubuntu 22.04, que incluye Python preinstalado.
Haz clic en Crear.
Espera unos minutos hasta que la VM esté lista.
Establece una conexión SSH a la VM:
1. En la consola de GDC, haz clic en la VM.
2. Haz clic en Conectar con SSH.

Después de conectarte a la consola SSH, ejecuta lo siguiente:

mkdir ~/simple-server
cd ~/simple-server
echo 'Welcome to my VM!' > index.html
python3 -m http.server --bind 0.0.0.0 8080 &

Para enrutar el tráfico a una VM, crea un servicio sin interfaz gráfica (sin selectores). Esto se asignará de forma manual a la dirección IP interna de la VM con un recurso EndpointSlice.

kk apply -f - <<EOF
apiVersion: v1
kind: Service
metadata:
  name: vm-app-svc
  namespace: vm-app
spec:
  ports:
  - protocol: TCP
    port: 443
    targetPort: 443
EOF

Para obtener la dirección IP de la VM vm-workload, ejecuta lo siguiente:

gdcloud compute instances list --project ${PROJECT_ID} \
  | grep workload-vm | awk '{print $3}'

El resultado será la dirección IP de la VM que se necesitará para configurar el recurso EndpointSlice.

Crea el recurso EndpointSlice que se conectará al servicio sin selector de la app de VM y dirigirá la IP de la VM a la que se debe enrutar el tráfico.

apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
  name: vm-app-endpoints
  namespace: vm-app
  labels:
    kubernetes.io/service-name: vm-app-svc
addressType: IPv4
ports:
  - port: 8080
endpoints:
  - addresses:
    - "VM_IP"
    conditions:
      ready: true

Crea certificados autofirmados

En esta sección, se te guiará por el proceso de creación de certificados TLS y secretos de Kubernetes para proteger la comunicación de tus aplicaciones basadas en contenedores y en VM. En esta guía, se usan certificados autofirmados por conveniencia, pero en entornos de producción, debes usar certificados de nivel de producción, como se describe en Opcional: Usa certificados listos para producción. Elige nombres de dominio de muestra arbitrarios para estas apps. Si estableces conexiones seguras, garantizas la integridad y la confidencialidad de los datos para los clientes que acceden a tu aplicación a través del controlador de Ingress de HAProxy.

Para la app alojada en contenedores, creamos un certificado autofirmado y lo guardamos como un secreto en el espacio de nombres del balanceador de cargas. Esto se usará para TLS cuando se solicite k8s-app.example.com.

openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout tls-containerized.key \
  -out tls-containerized.crt \
  -subj "/CN=k8s-app.example.com" \
  -days 365

kk create secret tls tls-containerized \
  --namespace load-balancer \
  --key tls-containerized.key \
  --cert tls-containerized.crt

kk create secret tls tls-containerized \
  --namespace hello-app \
  --key tls-containerized.key \
  --cert tls-containerized.crt

Para la app de VM, se emite y se guarda un certificado autofirmado similar. Esto se usará para TLS cuando se solicite vm-app.example.com.

openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout tls-vm.key \
  -out tls-vm.crt \
  -subj "/CN=vm-app.example.com" \
  -days 365

kk create secret tls tls-vm \
  --namespace load-balancer \
  --key tls-vm.key \
  --cert tls-vm.crt

kk create secret tls tls-vm \
  --namespace vm-app \
  --key tls-vm.key \
  --cert tls-vm.crt

Implementa HAProxy

Instala el controlador de Ingress de HAProxy y el LB de L4

export HAPROXY_VERSION=3.1.14

# pull the HAProxy Ingress Controller image and push it to Harbor
docker pull haproxytech/kubernetes-ingress:${HAPROXY_VERSION} \
  --platform linux/amd64
docker tag haproxytech/kubernetes-ingress:${HAPROXY_VERSION} \
  ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/haproxy-ingress:${HAPROXY_VERSION}
docker --config=./docker push \
  ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/haproxy-ingress:${HAPROXY_VERSION}

# Get Helm repo
helm repo add haproxytech https://haproxytech.github.io/helm-charts
helm repo update

# Install the Ingress Controller with helm
helm upgrade --install haproxy-kubernetes-ingress \
  haproxytech/kubernetes-ingress \
  --kubeconfig kubeconfig-${CLUSTER_NAME}.yaml \
  --namespace load-balancer \
  --set controller.image.repository=${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/haproxy-ingress \
  --set controller.image.tag=${HAPROXY_VERSION} \
  --set controller.existingImagePullSecret=${IMAGE_PULL_SECRET_NAME} \
  --set controller.service.type=LoadBalancer \
  --set-json \
  controller.service.annotations='{"networking.gke.io/load-balancer-type": "internal"}'

El controlador de Ingress de HAProxy obtiene una dirección IP virtual única para el acceso del cliente con un servicio de tipo LoadBalancer. Este servicio configura un balanceador de cargas de capa 4 completamente administrado. Para simplificar esta guía, se crea un balanceador de cargas interno configurando la anotación load-balancer-type en internal. Si se omite esta anotación, se generará un balanceador de cargas externo. La implementación de Kubernetes extrae imágenes de forma segura de Harbor con el secreto proporcionado (${IMAGE_PULL_SECRET_NAME}), que contiene las credenciales de la cuenta de robot de Harbor.

Valida la instalación del controlador de Ingress de HAProxy

Verifica que los pods del controlador de Ingress de HAProxy estén en ejecución y listos:

kk get pods -n load-balancer

El resultado debe verse de la siguiente manera:

NAME                                          READY   STATUS      RESTARTS   AGE
haproxy-kubernetes-ingress-78dc9c8676-f8fcb   1/1     Running     0          35s
haproxy-kubernetes-ingress-78dc9c8676-lfnr2   1/1     Running     0          65s
haproxy-kubernetes-ingress-crdjob-3-tgj2h     0/1     Completed   0          65s

Verifica que se haya creado y configurado el servicio del controlador de Ingress de HAProxy:

kk get services -n load-balancer

El resultado es similar al siguiente:

NAME                         TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)                                                                  AGE
haproxy-kubernetes-ingress   LoadBalancer   10.252.27.46   10.252.4.17   80:32023/TCP,443:31103/TCP,443:31103/UDP,1024:30146/TCP,6060:30718/TCP   10m

Define los recursos de Ingress para las apps de demostración

Crea el recurso de Ingress que conectará HAProxy al servicio de la app alojada en contenedores.

cat << EOF > hello-app-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello-app-ingress
  namespace: hello-app
  annotations:
    haproxy.org/ssl-redirect: "true"
    haproxy.org/ssl-redirect-port: "443"
    haproxy.org/ssl-redirect-code: "308"
spec:
  ingressClassName: haproxy
  tls:
  - hosts:
    - "k8s-app.example.com"
    secretName: tls-containerized
  rules:
  - host: "k8s-app.example.com"
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: hello-app
            port:
              number: 80
EOF

kk apply -f hello-app-ingress.yaml

Crea el recurso de Ingress que se conectará al servicio sin selector de la app de VM y dirigirá la IP de la VM a la que se debe enrutar el tráfico.

cat << EOF > vm-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: vm-app-ingress
  namespace: vm-app
  annotations:
    haproxy.org/ssl-redirect: "true"
    haproxy.org/ssl-redirect-port: "443"
    haproxy.org/ssl-redirect-code: "308"
spec:
  ingressClassName: haproxy
  tls:
  - hosts:
    - "vm-app.example.com"
    secretName: tls-vm
  rules:
  - host: "vm-app.example.com"
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: vm-app-svc
            port:
              number: 443
EOF

kk apply -f vm-ingress.yaml

Recupera la dirección IP del balanceador de cargas

Ejecuta el comando para obtener la dirección IP del balanceador de cargas.

kk get services/haproxy-kubernetes-ingress \
  -n load-balancer \
  -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

Esto será necesario cuando se verifique el acceso a las apps. Se hará referencia a esto como LOAD_BALANCER_IP.

Crear una VM de cliente

Sigue los pasos para crear una VM de cliente:

Abre la consola de GDC en tu navegador web.
Abre el menú y, luego, haz clic en Máquinas virtuales.
Haz clic en Crear instancia.
Crea una VM llamada client, selecciona un tipo de máquina pequeño y selecciona Rocky Linux o Ubuntu, que incluyen curl preinstalado.
Haz clic en Crear.
Espera unos minutos hasta que la VM esté lista.
Cuando la VM esté lista, establece una conexión SSH con la VM:
1. En la consola de GDC, haz clic en la VM.
2. Haz clic en Conectar con SSH.

Verifica el acceso y el enrutamiento

Para probar el enrutamiento, ejecuta comandos curl desde tu VM de cliente. Puedes conectarte a ambas aplicaciones con sus nombres de host definidos con la dirección IP del balanceador de cargas.

Si pasas la marca --resolve en curl, puedes forzar que los nombres de dominio se resuelvan en la IP del balanceador de cargas de L4 de GDC air-gapped. Ten en cuenta que pasamos la marca -k para confiar en los certificados autofirmados.

Prueba la app alojada en contenedores de Kubernetes:

curl -k --resolve k8s-app.example.com:443:$LOAD_BALANCER_IP https://k8s-app.example.com -v

Prueba la app de VM externa:

curl -k --resolve vm-app.example.com:443:$LOAD_BALANCER_IP https://vm-app.example.com -v

Si se configura correctamente, el controlador de Ingress actuará sin problemas como terminador de TLS y pasará el tráfico al destino.

Opcional: Usa certificados listos para producción

En esta sección, se explica cómo aprovechar el servicio de CA de GDC aislado para crear una autoridad de certificación raíz privada, emitir certificados firmados para tus cargas de trabajo y actualizar de forma segura tu clúster estándar de GDC aislado y las VMs de cliente.

En esta sección, se describe cómo usar el servicio de CA aislado de GDC para crear una autoridad certificadora (CA) raíz privada y emitir certificados válidos para tus aplicaciones. Si instalas esta CA raíz en tu VM de cliente, puedes verificar que la finalización de TLS funcione sin problemas con certificados de confianza, sin necesidad de omitir las advertencias de SSL (por ejemplo, con curl -k).

Otorga los permisos necesarios y obtén las credenciales

Para administrar el servicio de CA y emitir certificados, tu usuario necesita los roles de IAM adecuados en el proyecto.

Otorga los roles certificate-authority-service-admin y certificate-requester:

gdcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member=user:${USER_NAME} \
  --role=certificate-authority-service-admin

gdcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member=user:${USER_NAME} \
  --role=certificate-requester

Obtén las credenciales del servidor de la API de administración:
```
gdcloud clusters get-credentials ${ORG_NAME}-admin
```

Crea la CA raíz:

Crearás una autoridad certificadora en el servidor de la API de administración dentro del espacio de nombres de tu proyecto.

Aplica el recurso CertificateAuthority:

km apply -f - <<EOF
apiVersion: pki.security.gdc.goog/v1
kind: CertificateAuthority
metadata:
  name: my-root-ca
  namespace: ${PROJECT_ID}
spec:
  caProfile:
    commonName: "My Root CA"
    duration: 87600h # 10 years
    keyAlgorithm: RSA_2048
    maxChainLength: 1
  caType: ROOT
  keyLocation: HSM
  rotationPolicy:
    cronTime: 0 0 1 1 *
EOF

km -n ${PROJECT_ID} get \
certificateauthority.pki.security.gdc.goog/my-root-ca -ojson \
| jq -r '
.status.conditions[] | select( .type as $id | "Ready" | index($id)) .status'

Emite e implementa certificados

Cuando la CA esté lista, solicitarás certificados para la app alojada en contenedores y la app basada en VM. Estas solicitudes se realizan en el servidor de la API de administración, y las claves resultantes deben moverse a tu clúster estándar.

Crea solicitudes para ambos dominios:

km apply -f - <<EOF
apiVersion: pki.security.gdc.goog/v1
kind: CertificateRequest
metadata:
  name: tls-containerized-req
  namespace: ${PROJECT_ID}
spec:
  certificateAuthorityRef:
    name: my-root-ca
    namespace: ${PROJECT_ID}
  certificateConfig:
    subjectConfig:
      commonName: "k8s-app.example.com"
      dnsNames:
      - "k8s-app.example.com"
  signedCertificateSecret: tls-containerized-signed
---
apiVersion: pki.security.gdc.goog/v1
kind: CertificateRequest
metadata:
  name: tls-vm-req
  namespace: ${PROJECT_ID}
spec:
  certificateAuthorityRef:
    name: my-root-ca
    namespace: ${PROJECT_ID}
  certificateConfig:
    subjectConfig:
      commonName: "vm-app.example.com"
      dnsNames:
      - "vm-app.example.com"
  signedCertificateSecret: tls-vm-signed
EOF

Espera unos instantes a que se emitan los certificados. Puedes verificar que estén listos cuando la condición Ready sea True:

km get certificaterequests -n ${PROJECT_ID}

Actualiza el clúster estándar

Si seguiste las secciones anteriores de esta guía, tienes secretos autofirmados en tu clúster estándar. Debes borrarlos antes de crear las versiones nuevas y firmadas:

kk delete secret tls-containerized -n load-balancer
kk delete secret tls-vm -n load-balancer

kk delete secret tls-containerized -n hello-app
kk delete secret tls-vm -n vm-app

Ahora, extrae los certificados firmados del servidor de la API de administración y crea los secretos nuevos en el clúster estándar.

km get secret -n ${PROJECT_ID} tls-containerized-signed \
  -o jsonpath='{.data.tls\.crt}' \
  | base64 -d > tls-containerized.crt

km get secret -n ${PROJECT_ID} tls-containerized-signed \
  -o jsonpath='{.data.tls\.key}' \
  | base64 -d > tls-containerized.key

kk create secret tls tls-containerized \
  --namespace load-balancer \
  --key tls-containerized.key \
  --cert tls-containerized.crt

kk create secret tls tls-containerized \
  --namespace hello-app \
  --key tls-containerized.key \
  --cert tls-containerized.crt

km get secret -n ${PROJECT_ID} tls-vm-signed \
  -o jsonpath='{.data.tls\.crt}' \
  | base64 -d > tls-vm.crt

km get secret -n ${PROJECT_ID} tls-vm-signed \
  -o jsonpath='{.data.tls\.key}' \
  | base64 -d > tls-vm.key

kk create secret tls tls-vm \
  --namespace load-balancer \
  --key tls-vm.key \
  --cert tls-vm.crt

kk create secret tls tls-vm \
  --namespace vm-app \
  --key tls-vm.key \
  --cert tls-vm.crt

Los balanceadores de cargas obtendrán y actualizarán automáticamente los secretos nuevos.

Configura la confianza del cliente

Para verificar la configuración, debes indicarle a tu VM de cliente que confíe en tu nueva CA raíz.

Extrae el certificado de la AC raíz a un archivo:

km get secret -n ${PROJECT_ID} my-root-ca-secret \
  -o jsonpath='{.data.tls\.crt}' \
  | base64 -d > my-root-ca.crt

Transfiere el certificado a tu VM de cliente. (Puedes copiar el contenido de my-root-ca.crt y pegarlo en un archivo en la VM de cliente).

En la VM de cliente, actualiza el almacén de confianza.

Si la VM client es Ubuntu:

sudo cp my-root-ca.crt /usr/local/share/ca-certificates/
sudo chmod 644 /usr/local/share/ca-certificates/my-root-ca.crt
sudo update-ca-certificates

Si la VM client es Rocky Linux:

sudo cp my-root-ca.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

Verifica el acceso

Ahora puedes acceder a tus aplicaciones con curl sin la marca -k. La conexión será completamente confiable.

Prueba la app alojada en contenedores de k8s:

curl -v --resolve k8s-app.example.com:443:LOAD_BALANDER_IP https://k8s-app.example.com

Prueba la app de VM:

curl -v --resolve vm.example.com:443:LOAD_BALANDER_IP https://vm-app.example.com

Si la operación se realiza correctamente, verás el resultado de la aplicación de inmediato sin ninguna advertencia de certificado SSL.