Foire aux questions

Le coût des ressources de calcul de relais est-il inclus dans les coûts du service Satellite ?

Les ressources IBM Cloud utilisées pour le relais et Satellite sont facturées séparément.

Y a-t-il des frais supplémentaires pour accéder aux services IBM Cloud via Direct Link?

Non, aucun frais supplémentaire n'est facturé pour l'accès aux services via Direct Link.

Pourquoi ai-je besoin de Direct Link?

Par défaut, le trafic sortant de votre site vers les services d' IBM Cloud passe par l'Internet public. Lorsque vous utilisez Direct Link, le trafic sortant de votre site transite par l’ Direct Link plutôt que par l’Internet public.

Mon organisation désactive l'accès à Internet par conception. Puis-je créer et gérer des emplacements et des hôtes connectés à l'emplacement avec Direct Link?

Si vous disposez de Direct Link, vous pouvez l'utiliser pour les services Satellite. Avec Direct Link, vous pouvez créer des emplacements et connecter des hôtes sans accès à l'Internet public.

Puis-je utiliser des hôtes RHEL pour configurer mon Direct Link?

Non. Vous devez disposer d'un emplacement compatible RHCOS et utiliser des hôtes RHCOS dans votre emplacement pour utiliser Direct Link.

Puis-je rediriger tout le trafic vers IBM Cloud via Direct Link au lieu d'Internet?

Actuellement, tous les services ne prennent pas en charge Direct Link. La possibilité pour l'ensemble du trafic d'utiliser Direct Link dépend des services que vous utilisez. Consultez la documentation de chaque service pour vérifier ses exigences en matière de connectivité.

Quels services IBM Cloud puis-je accéder via Direct Link pour éviter d'y accéder via Internet?

Après avoir suivi ces instructions, Satellite et OpenShift sur Satellite fonctionneront sur Direct Link. Si des services supplémentaires sont déployés dans un emplacement Satellite, consultez la documentation de chaque service pour vérifier leurs exigences en matière de connectivité, car certains services nécessitent un accès public à Internet.

Si j'ai deux emplacements qui utilisent Direct Link, puis-je les utiliser pour que Direct Link puisse basculer d'un emplacement à l'autre?

Cette fonctionnalité n'est pas encore disponible.

Comment dimensionner la capacité de Direct Link pour mon site?

Il n'y a pas d'exigences de dimensionnement supplémentaires pour l'utilisation de Direct Link. Ainsi, vous pouvez dimensionner votre emplacement comme un emplacement normal, c'est-à-dire en fonction des services que vous utiliserez.

Puis-je avoir un déploiement en un clic de tout ce qui est nécessaire pour activer Direct Link afin d'éviter les erreurs manuelles?

Actuellement, un déploiement en un clic pour Direct Link n'est pas disponible.

Scénario d'utilisation cible

Les clients qui utilisent actuellement Direct Link entre IBM et des clouds publics sur site ou autres, peuvent continuer à l'utiliser pour le lien Satellite. Cela permet aux clients de:

• Accès aux services sur IBM Cloud à partir d'un emplacement Satellite sur Direct Link; exemples: sauvegardes dans IBM Cloud® Object Storage, envoi de métriques à IBM Cloud Monitoring, suivi des événements dans IBM Cloud Activity Tracker
• Accédez aux services s'exécutant dans un emplacement Satellite à partir de IBM Cloud.
• Accédez aux services de cloud public en dehors de IBM Cloud.

Vous pouvez y accéder à l'aide des adresses de noeuds finaux Satellite créées pour acheminer le trafic via Direct Link à la place d'Internet.

Cela empêche les données sensibles du client de passer par l'Internet public, telles que la journalisation, les sauvegardes ou les données entre les services intégrés dans le paysage du cloud hybride. Cela permet également d'optimiser les frais d'entrée et de sortie.

Présentation

Par défaut, deux composants d’ Satellite Link, à savoir le serveur de tunnel et le connecteur, acheminent le trafic réseau entre IBM Cloud et les ressources de votre emplacement Satellite via une connexion sécurisée TLS. Ce document traite du cas d'utilisation d'une connexion TLS via Direct Link.

Cette configuration utilise le noeud final de service de cloud privé du serveur de tunnel pour acheminer le trafic sur le réseau privé IBM Cloud (166.9.0.0/8, voir Réseau de services. Toutefois, la communication avec le noeud final de service de cloud privé du serveur de tunnel doit passer par 166.9.X.X/16 Plage d'adresses IP sur le réseau privé IBM Cloud, qui n'est pas routable à partir de IBM Cloud Direct Link.

Pour activer l'accès à la plage 166.9.X.X/16, créez un relais dans votre compte IBM Cloud, ce qui inversera le trafic entrant du proxy vers le noeud final de service de cloud privé du serveur de tunnel. Par défaut, le relais Ingress possède une adresse IP dans la plage d'adresses IP 10.X.X.X/8 interne, qui est accessible via une connexion Direct Link.

Le diagramme suivant illustre le flux du trafic.

1. Le trafic réseau provenant de votre emplacement, par exemple une demande provenant d'un cluster IBM Cloud Satellite vers un service IBM Cloud, est acheminé via le service de liaison via Direct Link vers le service Relay Private Ingress, qui possède une adresse routable Direct Link.
2. Le relais lance une nouvelle session pour transmettre la demande au noeud final de service de cloud privé du serveur de tunnel, qui se termine par une adresse IP comprise dans la plage 166.9.X.X/16 (adresse privée de liaison).

Objectifs

Vous pouvez créer des emplacements Red Hat CoreOS sans accéder à l'Internet public. Tout le trafic est géré par Direct Link et reste interne.

Les étapes de niveau supérieur sont les suivantes:

1. Créez un emplacement Red Hat CoreOS activé Satellite avec votre compte IBM Cloud qui termine votre Direct Link.
2. Créez un relais, qui est un proxy inverse prenant en charge http / https et websocket sécurisé.
3. Red Hat s sur la mise en place des hébergeurs CoreOS. Personnalisez les hôtes à l'aide du script ignition qui sont téléchargés en tant que script d'association pour l'emplacement créé à l'étape 1.

Prérequis

• Vous devez disposer d'un emplacement Red Hat CoreOS activé Satellite. Si vous n'en avez pas déjà, suivez les instructions de la rubrique Création d'un emplacement Red Hat CoreOS activé Satellite pour le créer.
• Direct Link est disponible entre l'emplacement cible Satellite et les clusters VPC ou classiques spécifiques à IBM Cloud.
• Vérifiez que votre connexion IBM Cloud Direct Link peut accéder à la plage d'adresses IP 10.X.X.X/8. Passez en revue la conception du réseau pour éviter les conflits d'adresses IP entre deux extrémités de Direct Link.
• Installez l'interface de ligne de commande IBM Cloud et les plug-in et installez l'interface de ligne de commande Kubernetes(kubectl).
• Vérifiez que votre compte IBM Cloud est activé pour la fonction VRF (Virtual Router Function) afin d'utiliser les noeuds finaux de service.
• Assurez-vous de disposer des politiques d'accès suivantes. Pour plus d'informations, voir Vérification des droits utilisateur.
  • Administrateur IBM Cloud Rôle d'accès à la plateforme IAM pour IBM Cloud Kubernetes Service
  • Administrateur IBM Cloud Rôle d'accès à la plateforme IAM pour IBM Cloud Container Registry
  • Auteur ou Gestionnaire IBM Cloud Rôle d'accès au service IAM pour IBM Cloud Kubernetes Service
  • Administrateur IBM Cloud Rôle d'accès à la plateforme IAM pour IBM Cloud Container Registry
  • Administrateur IBM Cloud Rôle d'accès à la plateforme IAM pour IBM Cloud Satellite
  • Gestionnaire IBM Cloud Rôle d'accès au service IAM pour IBM Cloud Satellite
  • Administrateur IBM Cloud Rôle d'accès à la plateforme IAM pour Object Storage
  • Auteur ou Gestionnaire IBM Cloud Rôle d'accès à la plateforme IAM pour IBM Cloud Object Storage
  • Administrateur IBM Cloud Rôle d'accès à la plateforme IAM pour IBM Cloud Certificate Manager
  • Auteur ou Gestionnaire IBM Cloud Rôle d'accès à la plateforme IAM pour IBM Cloud Certificate Manager
  • Afficheur IBM Cloud Rôle d'accès à la plateforme IAM pour le groupe de ressources que vous prévoyez d'utiliser avec Satellite
  • Gestionnaire IBM Cloud Rôle d'accès au service IAM pour IBM Cloud Schematics
• Provoisionnez spécifiquement un cluster Kubernetes et déployez-y un proxy inverse NGINX afin de rediriger vers les points de terminaison Direct Link.

Création d'un emplacement Red Hat CoreOS activé Satellite

Vous pouvez ignorer cette étape si vous disposez déjà d'un emplacement Satellite activé pour Red Hat CoreOS.

Connectez-vous à votre compte IBM Cloud disposant d' Direct Link, puis créez un emplacement Satellite activé pour Red Hat CoreOS. Pour plus d'informations, voir Création d'un emplacement Satellite.

Création d'un relais

Le relais est un proxy inverse http / https qui prend en charge les connexions Websocket sécurisées. Il peut fonctionner sur VSI, Red Hat OpenShift ou IBM Cloud Kubernetes Service en mode Classic ou VPC. Les étapes suivantes illustrent un exemple de déploiement d’un proxy inverse d’ NGINX sur un cluster Red Hat OpenShift hébergé exclusivement dans un VPC privé (sur des nœuds privés du VPC).

Une exigence essentielle consiste à avoir un nom valide pouvant être affecté à l'ingress privé du cluster (Relay Ingress) et un certificat valide sur IBM Cloud. Sur les clusters IBM Cloud, le VPC Red Hat OpenShift sur les noeuds privés est fourni avec le nom d'hôte et le certificat privés par défaut. Vous pouvez les utiliser ou apporter votre nom d'hôte personnalisé et votre certificat. Cet exemple utilise le nom d'hôte privé et les certificats par défaut.

Remarques sur les clusters de VPC pour ce scénario:

• Zone: toute zone VPC compatible avec plusieurs zones
• Version de noeud worker: toute version d'infrastructure VPC
• Version : 4.x.x
• Pool de noeuds worker: au moins 2 noeuds worker
• Subnets (sous-réseaux): Inclure les sous-réseaux IP de l'équilibreur de charge d'entrée si les plages par défaut sont en conflit avec les valeurs --pod-subnet et --service-subnet du cluster Red Hat OpenShift sur Satellite ou le réseau CIDR où les hôtes Satellite ou Red Hat OpenShift sont déployés sur site.
• Noeuds finaux de service de cloud: ne spécifiez pas l'option --disable-public-service-endpoint si vous souhaitez des noeuds finaux publics et privés.
• Répartissez le pool de noeuds worker par défaut entre les zones pour augmenter la disponibilité de votre cluster classique ou VPC.
• Assurez-vous qu'il existe au moins 2 noeuds worker dans chaque zone, de sorte que les équilibreurs de charge d'application privés que vous configurez dans les étapes suivantes soient hautement disponibles et puissent recevoir correctement les mises à jour de version.

Dans l'exemple suivant, un cluster VPC privé uniquement et un contrôleur Ingress privé sont créés par défaut. Vous pouvez toutefois également utiliser un cluster Red Hat OpenShift avec un point de terminaison de service cloud public activé, mais dans ce cas, votre cluster est créé par défaut avec uniquement un contrôleur Ingress public. Si vous souhaitez configurer votre relais en utilisant un cluster avec un noeud final de service public, vous devez d'abord activer le contrôleur Ingress privé et l'enregistrer avec un sous-domaine et un certificat en suivant les étapes de la rubrique Configuration d'Ingress.

1. Créez un cluster Red Hat OpenShift privé uniquement sur VPC. Pour plus d'informations, voir Création de clusters de VPC.

   Il existe de nombreuses façons de rendre des applications accessibles au sein d'un cluster d' Red Hat OpenShift s dans un VPC. Dans cet exemple, l'application sera exposée en mode privé avec uniquement des points de terminaison privés, ce qui correspond au cas d'utilisation le plus courant pour les clients d' Direct Link. Les clusters d' Red Hat OpenShift exposés en mode privé avec uniquement des points de terminaison privés sont fournis avec un nom privé et un certificat par défaut. Ils seront utilisés dans cet exemple pour exposer les pods de proxy inverse de l' NGINX. Vous pouvez utiliser les valeurs par défaut ou apporter votre nom d'hôte et votre certificat personnalisés. Pour plus de détails, voir Exposition privée d'applications dans des clusters de VPC avec un noeud final de service de cloud privé uniquement.

2. Créez une instance de Secret Manager et enregistrez-la dans le cluster Red Hat OpenShift créé à l'étape précédente. Pour plus d'informations, voir Création d'une instance de service Secrets Manager.

3. Obtenez les détails d'Ingress à partir de Direct Link.

   ibmcloud oc cluster get --cluster CLUSTER_NAME_OR_ID | grep Ingress
   

   Exemple de sortie :

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

   Dans ce scénario, si vous exécutez la commande nslookup sur le sous-domaine Ingress, celle-ci renvoie l'adresse IP privée du service IBM (10.0.0.0/8). L'ajout de routes permettant de rendre l'adresse IP Ingress (10.0.0.0/8) accessible depuis l'environnement sur site du client n'est pas abordé dans ce document. Vous êtes chargé de faciliter le routage entre l'environnement sur site et le relais Ingress sur IBM Cloud.

4. Obtenez le secret du CRN.

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

5. Créer un espace de noms pour le proxy inverse NGINX.

   kubectl create ns dl-reverse-proxy
   

6. Copiez la clé secrète par défaut TLS depuis vers openshift-ingress le projet dans lequel NGINX va être déployé.

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

7. Copiez le contenu du fichier de ressources Ingress suivant dans votre répertoire local. Remplacez VALUE_FROM_INGRESS_SUBDOMAIN et VALUE_FROM_INGRESS_SECRET par vos propres valeurs.

   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. Créez l'Ingress.

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

9. Obtenez le nom d'hôte Ingress interne du serveur de tunnel Direct Link en exécutant la commande suivante.

   ibmcloud sat endpoint ls --location LOCATION_ID
   

10. Dans la sortie, notez le noeud final Location. Remplacez c-01, c-02 ou c-03 par d-01-ws, d-02-ws ou d-03-ws et retirez le port. Par exemple, c-01.private.us-south.link.satellite.cloud.ibm.com:40934 devient d-01-ws.private.us-south.link.satellite.cloud.ibm.com. Cette valeur peut être utilisée comme valeur pour proxy_pass https dans le fichier ConfigMap.

11. Copiez le contenu du fichier NGINX ConfigMap dans votre répertoire local. Cette configuration applique soit un proxy inverse WS, soit un proxy inverse HTTPS au point de terminaison Direct Link du serveur de tunnel. Remplacez VALUE_FROM_INGRESS_SUBDOMAIN et VALUE_FOR_PROXY_PASS par vos propres valeurs.

    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. Copiez le fichier de déploiement 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. Créer l' ConfigMap de l' NGINX (dl-reverse-proxy).

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

14. Définissez le scc profil approprié et créez l' 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. Vérifiez que l' NGINX e est bien en cours d'exécution en répertoriant les 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. Consultez les journaux.

    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. Vérifiez 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. Se connecter à l' URL du proxy inverse.

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

    {"status":"UP"}
    

Rediriger le trafic vers l'utilisation du Direct Link Chemin d'accès

Maintenant que le relais est prêt à acheminer le trafic entrant vers le serveur tunnel Ingress interne, vous pouvez configurer votre hôte de localisation ou votre connecteur pour rediriger son trafic via le relais. Cela garantit que tout le trafic restera sur le chemin Direct Link dans votre réseau privé et qu'aucun trafic n'utilisera l'internet public.

Redirigez le trafic vers votre agent Connector ou votre hôte Location en suivant les instructions ci-dessous.