Preguntas frecuentes

¿Se incluye el coste de los recursos de cálculo de retransmisión en los costes de servicio de Satellite ?

Los recursos IBM Cloud utilizados para el retransmisor y Satellite se facturan por separado.

¿Hay cargos adicionales para acceder a los servicios de IBM Cloud a través de Direct Link?

No, no hay cargos adicionales para acceder a los servicios a través de Direct Link.

¿Por qué necesito Direct Link?

Por defecto, el tráfico saliente desde su ubicación hacia los servicios de IBM Cloud circula a través de la red pública de Internet. Cuando utilizas Direct Link, el tráfico saliente de tu ubicación pasa por la red Direct Link, en lugar de utilizar la Internet pública.

Mi organización inhabilita el acceso a Internet por diseño. ¿Puedo crear y mantener ubicaciones y hosts conectados a la ubicación con Direct Link?

Si tiene Direct Link, puede utilizarlo para los servicios de Satellite. Con Direct Link, puede crear ubicaciones y adjuntar hosts sin acceso a Internet público.

¿Puedo utilizar hosts RHEL para configurar mi Direct Link?

Núm. Debe tener una ubicación habilitada para RHCOS y debe utilizar hosts RHCOS en la ubicación para utilizar Direct Link.

¿Puedo redirigir todo el tráfico a IBM Cloud a través de Direct Link en lugar de Internet?

Actualmente, no todos los servicios dan soporte a Direct Link. Que todo el tráfico pueda utilizar Direct Link depende de los servicios que utilices. Consulte la documentación de cada servicio para comprobar sus requisitos de conectividad.

¿Qué servicios de IBM Cloud puedo acceder a través de Direct Link para evitar acceder a ellos a través de Internet?

Después de seguir estas instrucciones, Satellite y OpenShift en Satellite funcionarán a través de Direct Link. Si se implementan servicios adicionales en una ubicación de Satellite, consulte la documentación de cada servicio para comprobar sus requisitos de conectividad, ya que algunos servicios requieren acceso público a Internet.

Si tengo dos ubicaciones que utilizan Direct Link, ¿puedo utilizarlas para que Direct Link realice la migración tras error de una ubicación a la otra?

Esta funcionalidad aún no está disponible.

¿Cómo puedo dimensionar la capacidad de Direct Link para mi ubicación?

No hay requisitos de dimensionamiento adicionales para utilizar Direct Link. Por lo tanto, puede dimensionar su ubicación como una ubicación normal, lo que significa en función de los servicios que vaya a utilizar.

¿Puedo tener un solo clic en el despliegue de todo lo necesario para habilitar Direct Link para evitar errores manuales?

Actualmente, no está disponible un despliegue de una sola pulsación para Direct Link.

Caso de uso de destino

Los clientes que están utilizando actualmente Direct Link entre IBM y nubes locales u otras nubes públicas, pueden seguir utilizándolo para el enlace Satellite. Esto permite a los clientes:

• Acceda a servicios en IBM Cloud desde una ubicación de Satellite sobre Direct Link; los ejemplos son copias de seguridad en IBM Cloud® Object Storage, el envío de métricas a IBM Cloud Monitoring, el seguimiento de sucesos en IBM Cloud Activity Trackero el envío de registros a IBM Cloud Log Analysis.
• Acceda a los servicios que se ejecutan en una ubicación de Satellite desde IBM Cloud.
• Acceda a los servicios de nube pública fuera de IBM Cloud.

Se puede acceder a ellos utilizando Satellite direcciones de puntos finales creadas para direccionar el tráfico a través de Direct Link en lugar de Internet.

Esto impide que los datos confidenciales del cliente vayan a través de Internet público como, por ejemplo, el registro, las copias de seguridad o los datos entre servicios integrados en el entorno de cloud híbrido. Esto también ayuda a optimizar los cargos de entrada/salida.

Visión general

De forma predeterminada, dos componentes de Satellite Link —el servidor de túnel y el conector— actúan como proxy del tráfico de red entre IBM Cloud y los recursos de su ubicación de Satellite a través de una conexión segura TLS. Este documento describe el caso de uso de una conexión TLS a través de Direct Link.

Esta configuración utiliza el punto final de servicio de nube privada del servidor de túnel para direccionar el tráfico a través de la red privada IBM Cloud (166.9.0.0/8, consulte Red de servicio. Sin embargo, la comunicación con el punto final de servicio de nube privada del servidor de túnel debe pasar por 166.9.X.X/16 Rango de direcciones IP en la red privada IBM Cloud, que no se puede direccionar desde IBM Cloud Direct Link.

Para habilitar el acceso al rango 166.9.X.X/16, cree un retransmisor en su cuenta de IBM Cloud, lo que invertirá el tráfico de entrada de proxy al punto final de servicio de nube privada del servidor de túnel. De forma predeterminada, el Relay Ingress tiene una dirección IP en el rango de direcciones IP de 10.X.X.X/8 interno, al que se puede acceder a través de una conexión de Direct Link.

El diagrama siguiente muestra el flujo de tráfico.

1. El tráfico de red que se origina en la ubicación, como por ejemplo una solicitud de un clúster IBM Cloud Satellite a un servicio IBM Cloud, se direcciona a través del servicio de enlace a través de Direct Link a la entrada privada del retransmisor, que tiene una dirección direccionable de enlace directo.
2. El retransmisor inicia una nueva sesión para reenviar la solicitud al punto final de servicio de nube privada del servidor de túnel, que termina en una dirección IP en el rango de 166.9.X.X/16 (dirección privada de enlace).

Objetivos

Puedes crear ubicaciones habilitadas para Red Hat y CoreOS sin necesidad de acceder a Internet pública. Todo el tráfico se gestiona a través de Direct Link y permanece interno.

Los pasos de alto nivel incluyen:

1. Cree una ubicación de Red Hat CoreOS habilitada Satellite con su cuenta de IBM Cloud que termine su Direct Link.
2. Cree un retransmisor, que es un proxy inverso que soporta http/https y websocket seguro.
3. Aprovisionar hosts de Red Hat CoreOS. Personalice los hosts utilizando el script de encendido que se ha descargado como script de conexión para la ubicación creada en el paso 1.

Requisitos previos

• Debe tener una ubicación de Red Hat CoreOS habilitada Satellite. Si todavía no tiene uno, siga las instrucciones de Creación de un Red Hat CoreOS habilitado Satellite Ubicación para crearlo.
• Direct Link está disponible entre la ubicación Satellite de destino y los clústeres clásicos o de VPC específicos de IBM Cloud.
• Asegúrese de que la conexión de IBM Cloud Direct Link pueda acceder al rango de direcciones IP de 10.X.X.X/8. Revise el diseño de red para evitar conflictos de IP entre dos extremos de Direct Link.
• Instale la CLI y los plugins de IBM Cloud e instale la CLI de Kubernetes(kubectl).
• Asegúrese de que la cuenta de IBM Cloud esté habilitada para VRF (Virtual Router Function) para utilizar puntos finales de servicio.
• Asegúrese de que dispone de las siguientes políticas de acceso. Puede obtener información adicional consultando Comprobación de los permisos de usuario.
  • Administrador IBM Cloud IAM para IBM Cloud Kubernetes Service
  • Administrador IBM Cloud IAM para IBM Cloud Container Registry
  • Rol de acceso al servicio de escritor o Gestor IBM Cloud IAM para IBM Cloud Kubernetes Service
  • Administrador IBM Cloud IAM para IBM Cloud Container Registry
  • Administrador IBM Cloud Rol de acceso de plataforma de IAM para IBM Cloud Satellite
  • Gestor Rol de acceso al servicio de IBM Cloud IAM para IBM Cloud Satellite
  • Administrador IBM Cloud para Object Storage
  • Rol de acceso de plataforma de escritor o Gestor IBM Cloud IAM para IBM Cloud Object Storage
  • Administrador IBM Cloud Rol de acceso de plataforma de IAM para IBM Cloud Certificate Manager
  • Rol de acceso de plataforma de escritor o Gestor IBM Cloud IAM para IBM Cloud Certificate Manager
  • Visor IBM Cloud IAM para el grupo de recursos que tiene previsto utilizar con Satellite
  • Gestor IBM Cloud Rol de acceso al servicio IAM para IBM Cloud Schematics
• Configure específicamente un clúster de Kubernetes e implemente en él un proxy inverso de NGINX para redirigir a los puntos finales de Direct Link.

Creación de una ubicación de Red Hat CoreOS habilitada Satellite

Puedes saltarte este paso si ya tienes habilitado Red Hat CoreOS en Satellite Location.

Inicia sesión en tu cuenta de IBM Cloud que cuente con Direct Link y crea una ubicación Satellite habilitada para Red Hat CoreOS. Para obtener más información, consulte Creación de una ubicación de Satellite.

Creación de un retransmisor

El retransmisor es un proxy inverso http/https que da soporte a conexiones Websocket seguras. Puede ejecutarse en VSI, Red Hat OpenShift o IBM Cloud Kubernetes Service en modo Classic o VPC. Los siguientes pasos muestran un ejemplo de cómo implementar un proxy invers NGINX e en un clúster de Red Hat OpenShift en una VPC exclusivamente privada (en nodos privados de la VPC).

Un requisito esencial es tener un nombre válido que se pueda asignar a la entrada privada del clúster (Relay Ingress) y un certificado válido en IBM Cloud. En IBM Cloud, los clústeres de VPC Red Hat OpenShift en nodos privados vienen con el nombre de host privado predeterminado y el certificado. Puede utilizarlos o traer el nombre de host personalizado y el certificado. Este ejemplo utiliza el nombre de host privado predeterminado y los certificados.

Consideraciones sobre los clústeres de VPC para este escenario:

• Zona: cualquier zona de VPC con capacidad multizona
• Tipo de nodo trabajador: cualquier tipo de infraestructura de VPC
• Versión: 4.x.x
• Agrupación de nodos trabajadores: al menos 2 nodos trabajadores
• Subredes: Incluya subredes IP del equilibrador de carga de entrada si los rangos predeterminados entran en conflicto con los valores de --pod-subnet y --service-subnet del clúster Red Hat OpenShift en Satellite o el CIDR de red donde los hosts Satellite o Red Hat OpenShift están desplegados en las instalaciones.
• Puntos finales de servicio en la nube: no especifique la opción --disable-public-service-endpoint si desea puntos finales públicos y privados.
• Distribuya la agrupación de nodos trabajadores predeterminada entre zonas para aumentar la disponibilidad del clúster clásico o de 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.

En el ejemplo siguiente, se crean de forma predeterminada un clúster de VPC solo privado y un controlador de Ingress privado. No obstante, también puede utilizar un clúster de Red Hat OpenShift con un punto de conexión de servicio en la nube pública habilitado, pero en este caso su clúster se creará, por defecto, únicamente con un controlador Ingress público. Si desea configurar el retransmisor utilizando un clúster con un punto final de servicio público, primero debe habilitar el controlador de Ingress privado y registrarlo con un subdominio y un certificado siguiendo los pasos de Configuración de Ingress.

1. Cree un clúster solo privado Red Hat OpenShift en VPC. Para obtener más información, consulte Creación de clústeres de VPC.

   Hay muchas formas de exponer aplicaciones en un clúster de Red Hat OpenShift en una VPC. En este ejemplo, la aplicación se expondrá de forma privada únicamente con puntos de conexión privados, lo cual es el caso de uso más habitual para los clientes de Direct Link. Los clústeres de Red Hat OpenShift que se exponen de forma privada únicamente con puntos de conexión privados incluyen un nombre privado y un certificado predeterminados. En este ejemplo se utilizarán para exponer los pods de proxy inverso de NGINX. Puede utilizar los predeterminados o traer el nombre de host personalizado y el certificado. Para obtener más detalles, consulte Exposición privada de apps en clústeres de VPC solo con un punto final de servicio de nube privada.

2. Cree una instancia de Gestor de secretos y regístrela en el clúster Red Hat OpenShift que se creó en el paso anterior. Para obtener más información, consulte Creación de una instancia de servicio de Secrets Manager.

3. Obtenga los detalles de Ingress de Direct Link.

   ibmcloud oc cluster get --cluster CLUSTER_NAME_OR_ID | grep Ingress
   

   Salida de ejemplo:

   Ingress Subdomain:      mycluster-i000.us-south.containers.appdomain.cloud
   Ingress Secret:         mycluster-i000
   

   En este escenario, si ejecutas el comando nslookup en el subdominio de Ingress, este se resuelve en la dirección IP privada del servicio IBM (10.0.0.0/8). En este documento no se trata la adición de rutas para que la dirección IP de Ingress (10.0.0.0/8) sea accesible desde el entorno local del cliente. Eres responsable de facilitar el enrutamiento entre el entorno local y el relé de Ingress en IBM Cloud.

4. Consigue el CRN secreto.

   ibmcloud oc ingress secret get -c CLUSTER --name SECRET_NAME --namespace openshift-ingress
   

5. Crea un espacio de nombres para el proxy inverso de NGINX.

   kubectl create ns dl-reverse-proxy
   

6. Copia el secreto predeterminado de TLS openshift-ingress de al proyecto en el que se va a implementar NGINX.

   ibmcloud oc ingress secret create --cluster CLUSTER_NAME_OR_ID --cert-crn CRN --name SECRET_NAME --namespace dl-reverse-proxy
   

7. Copie el siguiente contenido del archivo de recursos de Ingress en el directorio local. Sustituya VALUE_FROM_INGRESS_SUBDOMAIN y VALUE_FROM_INGRESS_SECRET por sus propios valores.

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: dl-ingress-resource
     annotations:
       kubernetes.io/ingress.class: "public-iks-k8s-nginx"
       nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
       nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"
   spec:
     tls:
     - hosts:
       - satellite-dl.VALUE_FROM_INGRESS_SUBDOMAIN
       secretName: VALUE_FROM_INGRESS_SECRET
     rules:
     - host: satellite-dl.VALUE_FROM_INGRESS_SUBDOMAIN
       http:
         paths:
         - path: /
           pathType: Prefix
           backend:
             service:
               name: nginxsvc
               port:
                 number: 80
   

8. Cree el Ingress.

   oc apply -f myingressresource.yaml -n <dl-reverse-proxy>
   

9. Obtenga el nombre de host de Ingress interno del servidor de túnel Direct Link ejecutando el mandato siguiente.

   ibmcloud sat endpoint ls --location LOCATION_ID
   

10. En la salida, tome nota del punto final de ubicación. Sustituya c-01, c-02 o c-03 por d-01-ws, d-02-ws o d-03-ws y extraiga el puerto. Por ejemplo, c-01.private.us-south.link.satellite.cloud.ibm.com:40934 pasa a ser d-01-ws.private.us-south.link.satellite.cloud.ibm.com. Este valor se puede utilizar como valor para proxy_pass https en el archivo ConfigMap.

11. Copia el contenido del archivo NGINX ( ConfigMap ) en tu directorio local. Esta configuración aplica un proxy inverso WS o un proxy inverso HTTPS al punto final Direct Link del servidor de túnel. Sustituya VALUE_FROM_INGRESS_SUBDOMAIN y VALUE_FOR_PROXY_PASS por sus propios valores.

    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  4096;
        }
        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_names_hash_bucket_size  128;
          server {
            listen 80;
            server_name VALUE_FROM_INGRESS_SUBDOMAIN;
            proxy_connect_timeout 180;
            proxy_send_timeout 180;
            proxy_read_timeout 180;
            location /ws {
              proxy_pass https://VALUE_FOR_PROXY_PASS;
              proxy_ssl_server_name on;
              proxy_http_version 1.1;
              proxy_set_header Upgrade $http_upgrade;
              proxy_set_header Connection "upgrade";
            }
            location / {
              proxy_pass https://VALUE_FOR_PROXY_PASS;
            }
          }
        }
    

12. Copia el archivo de implementación NGINX.

    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
    

13. Crea la versión ConfigMap de NGINX (dl-reverse-proxy).

    oc apply -f confnginx.yaml -n dl-reverse-proxy
    

14. Configura el perfil scc correcto y crea el NGINX (dl-reverse-proxy).

    oc adm policy add-scc-to-user anyuid system:serviceaccount:dl-reverse-proxy:default
    oc apply -f nginx-app.yaml -n dl-reverse-proxy
    

15. Comprueba que el servicio NGINX esté en funcionamiento mostrando la lista de pods.

    oc get pods
    

    NAME                     READY   STATUS    RESTARTS   AGE
    nginx-757fbc9f85-gv2p6   1/1     Running   0          53s
    nginx-757fbc9f85-xvmrj   1/1     Running   0          53s
    

16. Compruebe los registros.

    oc logs -f nginx-757fbc9f85-gv2p6
    

    /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
    /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
    /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
    10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
    10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
    /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
    /docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
    /docker-entrypoint.sh: Configuration complete; ready for start up
    

17. Compruebe Ingress.

    oc get ingress
    

    NAME                  CLASS    HOSTS                                                                                                       ADDRESS                                                                                                     PORTS     AGE
    dl-ingress-resource   <none>   mysatellite-dl.myname-cluster10-22bfd3cd491bdeb5a0f661fb1e2b0c44-0000.us-south.containers.appdomain.cloud   router-default.myname-cluster10-22bfd3cd491bdeb5a0f661fb1e2b0c44-0000.us-south.containers.appdomain.cloud   80, 443   19m
    

18. Conéctese a la URL del proxy inverso.

    curl -k https://mysatellite-dl.myname-cluster10-22bfd3cd491bdeb5a0f661fb1e2b0c44-0000.us-south.containers.appdomain.cloud
    

    {"status":"UP"}
    

Redirigir el tráfico para utilizar el Direct Link Ruta

Ahora que la retransmisión está lista para dirigir el tráfico entrante al servidor de túnel de entrada interno, puedes configurar tu host de localización o conector para redirigir su tráfico a través de la retransmisión. Esto garantiza que todo el tráfico permanecerá en la ruta de Direct Link de su red privada y que ningún tráfico utilizará la Internet pública.

Redirige el tráfico de tu agente conector o host de localización siguiendo las instrucciones que se indican a continuación.