IBM Cloud Docs
Utilización de IBM Cloud Kubernetes Service en classic para alojar el dl-reverse-proxy

Utilización de IBM Cloud Kubernetes Service en classic para alojar el dl-reverse-proxy

Siga estos pasos para configurar dl-reverse-proxy para IBM Cloud® Direct Link utilizando IBM Cloud Kubernetes Service en classic.

Creación de un clúster de IBM Cloud Kubernetes Service

Cree un clúster de IBM Cloud Kubernetes Service en su cuenta de IBM Cloud, que sirve como conexión entre la ubicación de Satellite y IBM Cloud en la red privada.

  1. Revise los conceptos básicos de red de los clústeres. En concreto, asegúrese de preparar lo siguiente:

    • Gestión de VLAN(solo clústeres clásicos): Gestione y elija una VLAN pública y privada para la conectividad de red del clúster.
    • Direccionamiento de subred: habilite una función de direccionador virtual (VRF) o una distribución de VLAN para la cuenta de infraestructura de IBM Cloud para que los nodos trabajadores puedan comunicarse entre sí en la red privada y comunicarse con los puntos finales de servicio de nube privada internamente.
    • Esquema de dirección IP: Asegúrese de que no existan conflictos de subred entre el clúster y la red local.

  2. Revise los pasos que debe realizar para prepararse para crear un clúster.

  3. Cree un clúster clásico o un clúster de VPC estándar en la CLI. Cree el clúster con las características siguientes.

    • Clústeres clásicos:
      • Zona: cualquier zona con capacidad multizona
      • Tipo de nodo trabajador: cualquier tipo de infraestructura clásica
      • Conectividad de red: VLAN públicas y privadas
      • Agrupación de nodos trabajadores: al menos 2 nodos trabajadores
      • Versión: 1.20.7 o posterior
      • Puntos finales de servicio en la nube: puntos finales públicos y privados
      • Subredes: incluya subredes en las opciones --pod-subnet y --service-subnet si los rangos predeterminados entran en conflicto con la subred de la ubicación Satellite que ha configurado en el centro de datos local o en un proveedor de nube diferente
    • Clústeres VPC:
      • Zona: cualquier zona de VPC con capacidad multizona
      • Tipo de nodo trabajador: cualquier tipo de infraestructura de VPC
      • Versión: 1.20.7 o posterior
      • Agrupación de nodos trabajadores: al menos 2 nodos trabajadores
      • Subredes: incluya subredes en las opciones --pod-subnet y --service-subnet si los rangos predeterminados entran en conflicto con la subred de la ubicación Satellite que ha configurado en el centro de datos local o en un proveedor de nube diferente
      • Puntos finales de servicio en la nube: no especifique la opción --disable-public-service-endpoint para asegurarse de que se crean puntos finales públicos y privados

  4. Distribuya la agrupación de nodos trabajadores predeterminada entre zonas para aumentar la disponibilidad del clúster clásico o VPC. Asegúrese de que existan al menos 2 nodos trabajadores en cada zona, de modo que los ALB privados que configure en los pasos siguientes estén altamente disponibles y puedan recibir correctamente las actualizaciones de versión.

  5. Establezca el clúster IBM Cloud Kubernetes Service como contexto para esta sesión.

    ibmcloud ks cluster config --cluster <cluster_name_or_ID>

  6. Cree un espacio de nombres para el proxy inverso NGINX.

    kubectl create ns dl-reverse-proxy

Configuración de ALB de Ingress privados en el clúster

Configure los equilibradores de carga de aplicación (ALB) de Ingress privados para el clúster IBM Cloud Kubernetes Service, que exponen el servicio para un proxy inverso NGINX en la red privada. Para obtener más información, puede revisar las consideraciones para exponer una app en el clúster solo en la red privada y la orientación específica para exponer apps de forma privada con ALB de Ingress.

  1. Verifique que existe al menos un ALB con un Tipo de private en cada zona.
    ibmcloud ks alb ls -c <cluster_name_or_ID>
  2. Asegúrese de que los ALB privados tengan un Estado de enabled. Si están desactivados, ejecute el siguiente comando para activar cada ALB privado.
    ibmcloud ks ingress alb enable classic --alb <ALB_ID> -c <cluster_name_or_ID> --version 0.45.0_1228_iks
  3. Opcional: Inhabilite cada ALB público.
    ibmcloud ks ingress alb disable classic --alb <ALB_ID> -c <cluster_name_or_ID>
  4. Configure un dominio personalizado para los ALB privados a través de los cuales se puede acceder al proxy inverso de NGINX y, opcionalmente, configure TLS para el dominio.
    1. Cree un dominio personalizado a través del proveedor de servicios de DNS. El dominio personalizado debe tener 130 caracteres o menos para cumplir los requisitos de Ingress.
    2. Correlacione el dominio personalizado con los ALB privados añadiendo sus direcciones IP como registros A (clústeres clásicos) o su nombre de host de VPC como CNAME (clústeres de VPC). Para buscar el nombre de host (VPC) o las direcciones IP (clásica), ejecute ibmcloud ks ingress alb ls -c <cluster_name_or_ID>. Ten en cuenta que en los clusters VPC se asigna un nombre de host a los ALB porque las direcciones IP de 10.X.X.X no son estáticas y pueden cambiar con el tiempo.
    3. Para utilizar la terminación TLS, cree un secreto en el espacio de nombres dl-reverse-proxy que contenga un certificado TLS para su dominio personalizado. Por ejemplo, si hay un certificado TLS almacenado en IBM Cloud Certificate Manager que quiere utilizar, puede ejecutar el mandato siguiente para importar en el clúster su secreto asociado. Para obtener más información, consulte Dominios personalizados con Ingress. 
      ibmcloud ks ingress secret create --name <secret_name> --cluster <cluster_name_or_ID> --cert-crn <certificate_crn> --namespace dl-reverse-proxy
  5. Defina un archivo de recursos Ingress que utilice su dominio personalizado para enrutar el tráfico de red entrante a un nginxsvc que creará en pasos posteriores. Sustituya <custom_ingress_domain> por el dominio que ha registrado y <secret_name> por el secreto que ha creado para el certificado TLS del dominio.
    apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: dl-ingress-resource
  annotations:
    kubernetes.io/ingress.class: "private-iks-k8s-nginx"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"
spec:
  tls:
  - hosts:
    - <custom_ingress_domain>
    secretName: <secret_name>
  rules:
  - host: <custom_ingress_domain>
  http:
    paths:
    - path: /
      pathType: Prefix
      backend:
        service:
          name: nginxsvc
          port:
            number: 80
  6. Cree el recurso Ingress en su clúster.
    kubectl apply -f dl-ingress-resource.yaml -n dl-reverse-proxy

Los ALB de Ingress privados del clúster están ahora configurados para exponer un servicio de proxy inverso con el dominio personalizado en la red privada IBM Cloud.

Desplegar un proxy inverso NGINX

Despliegue un proxy inverso NGINX en el clúster expuesto en la red privada por los ALB de Ingress y configure el proxy inverso para que apunte al servidor de túnel de enlace Satellite para su ubicación.

Los siguientes pasos incluyen la edición y el uso de archivos YAML locales para crear un ConfigMap,, un despliegue NGINX y un servicio. Como alternativa, puede clonar un repositorio de muestras de NGINX HTTPS, como el directorio https-nginx del repositorio kubernetes/examples, y empujar la imagen Docker a un espacio de nombres en IBM Cloud Container Registry. Si utiliza un repositorio de ejemplo, asegúrese de que la configuración de NGINX, como en el archivo default.conf, incluye el bloque de servidor especificado en el paso 2 de esta sección.

  1. Obtenga el punto final de servicio privado para el servidor de túnel de enlace. En la salida, busque el Address que se lista para un punto final de tipo location.
    ibmcloud sat endpoint ls --location <location_ID>
    En esta salida de ejemplo, el punto final del servidor de túnel es c-04.private.us-east.link.satellite.cloud.ibm.com. No incluya un puerto.
    ID                           Name                                            Destination Type   Address
c1hnscnw0h7i5uf0t8eg_zE6Nx   openshift-api-c1muom3w0kfdne2kb37g              location           TCP   d-04-ws.private.us-east.link.satellite.cloud.ibm.com:33809
c1hnscnw0h7i5uf0t8eg_2F3Xo   openshift-api-c2e3ishw0sdo08f5902g              location           TCP   d-04-ws.private.us-east.link.satellite.cloud.ibm.com:34222
c1hnscnw0h7i5uf0t8eg_EczUw   satellite-cos-c1hnscnw0h7i5uf0t8eg              cloud              TLS   m65f0b26d6c5f695647f5-6b64a6ccc9c596bf59a86625d8fa2202-c000.us-east.satellite.appdomain.cloud:30235
c1hnscnw0h7i5uf0t8eg_56zpT   satellite-cosCrossRegion-c1hnscnw0h7i5uf0t8eg   cloud              TLS   m65f0b26d6c5f695647f5-6b64a6ccc9c596bf59a86625d8fa2202-c000.us-east.satellite.appdomain.cloud:31774
...
  2. Cree un ConfigMap para el proxy inverso NGINX y guarde el archivo como confnginx.yaml. En el bloque server, sustituya <custom_ingress_domain> por el dominio que ha registrado para los ALB de Ingress privados y <tunnel_server_ep> por el punto final de servidor de túnel que ha encontrado en el paso 1.
    apiVersion: v1
kind: ConfigMap
metadata:
  name: confnginx
data:
  nginx.conf: |
    user  nginx;
    worker_processes  1;
    error_log  /var/log/nginx/error.log warn;
    events {
        worker_connections  1024;
    }
    http {
      include       /etc/nginx/mime.types;
      default_type  application/octet-stream;
      log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                          '$status $body_bytes_sent "$http_referer" '
                          '"$http_user_agent" "$http_x_forwarded_for"';
      access_log  /var/log/nginx/access.log  main;
      sendfile        on;
      keepalive_timeout  65;
      server {
        listen 80;

        server_name <custom_ingress_domain>;

        proxy_connect_timeout 180;
        proxy_send_timeout 180;
        proxy_read_timeout 180;

        location / {
          proxy_pass https://<tunnel_server_ep>;
          proxy_ssl_server_name on;
          proxy_http_version 1.1;
          proxy_set_header Upgrade $http_upgrade;
          proxy_set_header Connection "upgrade";
        }
      }
    }
  3. Cree la página ConfigMap en su clúster IBM Cloud Kubernetes Service.
    kubectl apply -f confnginx.yaml -n dl-reverse-proxy
  4. Cree una configuración de despliegue para el proxy inverso NGINX y un servicio para que el despliegue se incluya en el equilibrio de carga de Ingress privado. Guarde el archivo como nginx-app.yaml.
    apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:alpine
          ports:
          - containerPort: 80
          volumeMounts:
            - name: nginx-config
              mountPath: /etc/nginx/nginx.conf
              subPath: nginx.conf
      volumes:
        - name: nginx-config
          configMap:
            name: confnginx
---
apiVersion: v1
kind: Service
metadata:
  name: nginxsvc
  labels:
    app: nginx
spec:
  type: NodePort
  ports:
  - port: 80
    protocol: TCP
    name: http
  - port: 443
    protocol: TCP
    name: https
  - port: 8080
    protocol: TCP
    name: tcp
  selector:
    app: nginx
  5. Cree el despliegue y el servicio en el clúster IBM Cloud Kubernetes Service.
    kubectl apply -f nginx-app.yaml -n dl-reverse-proxy

El proxy inverso está ahora configurado para terminar las conexiones entrantes al subdominio de Ingress personalizado, abrir una nueva conexión con el servidor de túnel de Satellite y reenviar las solicitudes al servidor de túnel.