Perguntas frequentes

O custo dos recursos de cálculo de relé incluído nos custos de serviço Satellite ?

Os recursos IBM Cloud usados para o relay e Satellite são faturados separadamente.

Existem encargos adicionais para acessar os serviços IBM Cloud sobre o Direct Link?

Não, não há encargos adicionais para acessar serviços sobre o Direct Link.

Por que eu preciso do Direct Link?

Por padrão, o tráfego de saída do seu Local para os serviços d IBM Cloud passa pela internet pública. Ao utilizar o serviço “ Direct Link ”, o tráfego de saída do seu local passa pela rede “ Direct Link ”, em vez de utilizar a internet pública.

Minha organização desabilita o acesso à Internet pelo design. Posso criar e manter Locais e hosts anexados ao Local com Direct Link?

Se você tiver o Direct Link, você pode usá-lo para os serviços Satellite. Com o Direct Link, é possível criar Locais e anexar hosts sem acesso à Internet pública.

É possível usar hosts RHEL para configurar meu Direct Link?

Nº. Deve-se ter um local ativado por RHCOS e usar hosts RHCOS em seu local para usar o Direct Link.

Posso redirecionar todo o tráfego para IBM Cloud sobre o Direct Link em vez da Internet?

Atualmente, nem todos os serviços suportam o Direct Link. A possibilidade de todo o tráfego utilizar o Direct Link depende dos serviços que você utiliza. Consulte a documentação de cada serviço para verificar seus requisitos de conectividade.

O que os serviços IBM Cloud podem eu acessar sobre o Direct Link para evitar acessá-los através da Internet?

Depois de seguir essas instruções, Satellite e OpenShift em Satellite funcionarão em Direct Link. Se forem implantados serviços adicionais em um local do Satellite, consulte a documentação de cada serviço para verificar seus requisitos de conectividade, pois alguns serviços exigem acesso à internet pública.

Se eu tiver duas Locações que usam o Direct Link, posso usá-las para Direct Link para falir de um Local para o outro?

Essa funcionalidade ainda não está disponível.

Como dimensionar a capacidade do Direct Link para o meu Local?

Não há requisitos adicionais de dimensionamento para o uso do Direct Link. Assim, você pode dimensionar o seu Local como um Local normal, significando com base nos serviços que irá utilizar.

Posso ter uma implementação de um clique de tudo necessário para ativar o Direct Link para evitar erros manuais?

Atualmente, uma implantação de um clique para Direct Link não está disponível.

Caso de uso da meta

Os clientes que estão atualmente usando Direct Link entre IBM e on-prem ou outras nuvens públicas, podem continuar a usá-lo para Satellite Link. Isso permite que os clientes:

• Serviços de acesso em IBM Cloud a partir de um Satellite local sobre Direct Link; exemplos são backups em IBM Cloud® Object Storage, acompanhando eventos em IBM Cloud Activity Tracker, ou envio de logs para IBM Cloud Log Analysis.
• Serviços de acesso em execução em um local Satellite a partir de IBM Cloud.
• Acesse os serviços de cloud pública fora do IBM Cloud.

Estes podem ser acessados usando Satellite endereços de endpoints criados para rotear o tráfego sobre Direct Link em vez da internet.

Isso evita que os dados sensíveis do cliente refiram a internet pública, como registro de registro, backups ou dados entre serviços integrados em todo o cenário de nuvem híbrida. Isso também ajuda a otimizar as taxas de ingresso / egresso.

Visão geral

Por padrão, dois componentes do Satellite Link — o servidor de túnel e o conector — atuam como proxy para o tráfego de rede entre IBM Cloud e os recursos em seu endereço Satellite por meio de uma conexão segura TLS. Este documento aborda o caso de uso da conexão TLS por meio de Direct Link.

Esta configuração usa o terminal de serviço de nuvem privada do servidor de túnel para rotear o tráfego sobre a rede privada IBM Cloud (166.9.0.0/8, ver Rede de serviços. No entanto, a comunicação para o terminal de serviço de nuvem privada do servidor de túnel deve passar pelo 166.9.X.X/16 Faixa de endereço IP na rede privada IBM Cloud, que não é roteável a partir de IBM Cloud Direct Link.

Para ativar o acesso à faixa 166.9.X.X/16, crie um Relay em sua conta IBM Cloud, que reverterá o tráfego de entrada de proxy para o terminal de serviço de nuvem privada do servidor de túnel. Por padrão, o Ingresso Relay possui um endereço IP na faixa de endereço IP interno 10.X.X.X/8, que é acessível através de uma conexão Direct Link.

O diagrama a seguir demonstra o fluxo do tráfego.

1. O tráfego de rede originado em sua Localização, como um pedido de um cluster IBM Cloud Satellite para um serviço IBM Cloud, é roteado via Link Service over Direct Link para o Relay Private Ingress, que possui um endereço de roteável de link direto.
2. O Relay inicia uma nova sessão para encaminhe a solicitação para o terminal de serviço de nuvem privada do servidor do túnel, que finaliza para um endereço IP na faixa 166.9.X.X/16 (Link privado Link).

Objetivos

É possível criar locais habilitados para o Red Hat CoreOS sem precisar acessar a Internet pública. Todo o tráfego é gerenciado por Direct Link e permanece interno.

As etapas de alto nível incluem:

1. Crie um Red Hat CoreOS ativado Satellite Local com sua conta IBM Cloud que finaliza o seu Direct Link.
2. Crie um relay, que é um proxy reverso que suporta http / https e websocket seguro.
3. Provisão Red Hat CoreOS hosts. Personalize os hosts usando script de ignição que são baixados como script de anexação para o Local criado na Etapa 1.

Pré-requisitos

• Deve-se ter um local do Red Hat CoreOS ativado Satellite. Se você ainda não tiver um, siga as instruções em Criando um Red Hat CoreOS ativado Satellite Local para criá-lo.
• O Direct Link está disponível entre o local do Satellite de destino e os clusters VPC ou clássicos específicos do IBM Cloud.
• Certificar-se de que sua conexão IBM Cloud Direct Link pode acessar a faixa de endereço IP 10.X.X.X/8. Revisar design de rede para evitar conflitos IP entre duas extremidades de Direct Link.
• Instalar o IBM Cloud CLI e plug-ins e instalar o CLI Kubernetes(kubectl).
• Certidão-se de que sua conta IBM Cloud é a Função Virtual Router Function (VRF) ativada para usar terminais de serviço.
• Certifique-se de que as seguintes políticas de acesso estejam em vigor. Para obter mais informações, consulte Verificando permissões de usuário.
  • Administrador IBM Cloud Função de acesso à plataforma IAM para IBM Cloud Kubernetes Service
  • Administrador IBM Cloud Função de acesso à plataforma IAM para IBM Cloud Container Registry
  • Writer ou Manager IBM Cloud Função de acesso de serviços do IAM para IBM Cloud Kubernetes Service
  • Administrador IBM Cloud Função de acesso à plataforma IAM para IBM Cloud Container Registry
  • Administrador IBM Cloud Função de acesso à plataforma IAM para IBM Cloud Satellite
  • Manager IBM Cloud Função de acesso de serviços do IAM para IBM Cloud Satellite
  • Administrador IBM Cloud Função de acesso à plataforma IAM para Object Storage
  • Writer ou Manager IBM Cloud Função de acesso da plataforma IAM para IBM Cloud Object Storage
  • Administrador IBM Cloud Função de acesso à plataforma IAM para IBM Cloud Certificate Manager
  • Writer ou Manager IBM Cloud Função de acesso da plataforma IAM para IBM Cloud Certificate Manager
  • Viewer IBM Cloud Função de acesso da plataforma IAM para o grupo de recursos que você planeja usar com Satellite
  • Manager IBM Cloud Função de acesso de serviços do IAM para IBM Cloud Schematics
• Configure especificamente um cluster do Kubernetes e implante nele um proxy reverso NGINX para redirecionar para os endpoints Direct Link.

Criando um Red Hat CoreOS ativado Satellite Local

Você pode pular esta etapa se já tiver uma localização Satellite habilitada em Red Hat CoreOS.

Faça login na sua conta do IBM Cloud que contém o Direct Link e crie um Red Hat CoreOS habilitado Satellite Location. Para obter mais informações, consulte Criando um local do Satellite.

Criando um relay

O relay é um proxy reverso http / https que suporta conexões Websocket seguras. Ele pode ser executado no VSI, em Red Hat OpenShift ou em IBM Cloud Kubernetes Service, na versão Classic ou VPC. As etapas a seguir mostram um exemplo de implantação de um proxy revers NGINX em um cluster do Red Hat OpenShift em uma VPC exclusivamente privada (em nós privados da VPC).

Um requisito essencial é ter um nome válido que possa ser atribuído ao cluster private ingress (Relay Ingress) e um certificado válido em IBM Cloud. Em IBM Cloud, VPC Red Hat OpenShift clusters em nós privados vêm com nome de host e certificado privado padrão. Você pode usá-los ou trazer seu nome de host e certificado personalizado. Este exemplo usa o nome de host privado padrão e certificados.

Considerações de clusters do VPC para este cenário:

• Zona: Qualquer zona de VPC multizone capaz
• Sabor do nó do trabalhador: Qualquer sabor de infraestrutura VPC
• Versão: 4.x.x
• Conjunto de trabalhadores: Pelo menos 2 nós do trabalhador
• Sub-redes: Inclua sub-redes de IP do balanceador de carga de entrada se os intervalos padrão entrarem em conflito com os valores --pod-subnet e --service-subnet do cluster Red Hat OpenShift em Satellite ou com o CIDR da rede em que os hosts Satellite ou Red Hat OpenShift estão implantados no local.
• Terminais de serviço em nuvem: Não especifique a opção --disable-public-service-endpoint se você deseja terminais públicos e privados.
• Espalhar o conjunto de trabalhadores padrão através de zonas para aumentar a disponibilidade do seu cluster clássico ou VPC.
• Certifica-se de que pelo menos 2 nós do trabalhador existem em cada zona, de modo que os ALBs privados que você configurar em etapas subsequentes estão altamente disponíveis e podem receber corretamente atualizações de versão.

No exemplo a seguir, um cluster de VPC somente privado e um controlador de Ingresso privado são criados por padrão No entanto, você também pode usar um cluster do Red Hat OpenShift com um endpoint de serviço em nuvem pública habilitado; mas, nesse caso, seu cluster é criado, por padrão, apenas com um controlador Ingress público. Se você deseja configurar o seu relay usando um cluster com um terminal de serviço público, você deve primeiro ativar o controlador Ingresso privado e registrá-lo com um subdomínio e certificado seguindo os passos em Configurando Ingress.

1. Crie um cluster private-only Red Hat OpenShift no VPC. Para obter mais informações, consulte Criando clusters de VPC.

   Existem várias maneiras de disponibilizar aplicativos em um cluster d Red Hat OpenShift s em uma VPC. Neste exemplo, o aplicativo será exposto de forma privada, utilizando apenas pontos de extremidade privados, o que é o caso de uso mais comum para clientes do Direct Link. Os clusters do Red Hat OpenShift que são expostos de forma privada, utilizando apenas pontos de extremidade privados, vêm com um nome privado e um certificado predefinidos. Nesse exemplo, eles serão utilizados para expor os pods do proxy reverso NGINX. Você pode usar os inadimplentes ou trazer seu nome de host e certificado personalizado. Para obter mais detalhes, consulte Expondo de forma privada os apps em clusters VPC com um terminal de serviço de nuvem privado apenas.

2. Crie uma instância do Secret Manager e registre-a no cluster Red Hat OpenShift que foi criado na etapa anterior. Para obter mais informações, consulte Criando uma instância de serviço Secrets Manager.

3. Obter os detalhes Ingresso a partir de Direct Link.

   ibmcloud oc cluster get --cluster CLUSTER_NAME_OR_ID | grep Ingress
   

   Saída de exemplo:

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

   Nesse cenário, se você executar o nslookup comando para o subdomínio do Ingress, ele será resolvido para o endereço IP privado do serviço IBM (10.0.0.0/8). A adição de rotas para tornar o endereço IP do Ingress (10.0.0.0/8) acessível a partir do ambiente local do cliente não é abordada neste documento. Você é responsável por facilitar o roteamento entre o ambiente local e o relé do Ingress em IBM Cloud.

4. Obtenha o CRN secreto.

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

5. Crie um namespace para o proxy reverso NGINX.

   kubectl create ns dl-reverse-proxy
   

6. Copie o segredo padrão “ TLS ” de openshift-ingress para o projeto no qual NGINX será implantado.

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

7. Copie o conteúdo do arquivo de recursos do Ingresso em seu diretório local. Substitua VALUE_FROM_INGRESS_SUBDOMAIN e VALUE_FROM_INGRESS_SECRET pelos seus próprios 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. Criar o Ingresso.

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

9. Get the tunnel server Direct Link Nome do host interno do Ingresso executando o seguinte comando.

   ibmcloud sat endpoint ls --location LOCATION_ID
   

10. A partir da saída, tire uma nota do terminal de Localização. Substitua c-01, c-02 ou c-03 com d-01-ws, d-02-ws ou d-03-ws e remova a porta. Por exemplo, c-01.private.us-south.link.satellite.cloud.ibm.com:40934 se torna d-01-ws.private.us-south.link.satellite.cloud.ibm.com. Este valor pode ser usado como o valor para proxy_pass https no arquivo ConfigMap.

11. Copie o conteúdo do arquivo NGINX ConfigMap para o seu diretório local. Essa configuração aplica um proxy reverso WS ou um proxy reverso HTTPS ao endpoint Direct Link do servidor de túnel. Substitua VALUE_FROM_INGRESS_SUBDOMAIN e VALUE_FOR_PROXY_PASS pelos seus próprios 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. Copie o arquivo de implantação “ 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. Crie o “ ConfigMap ” do “ NGINX ” (dl-reverse-proxy).

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

14. Defina o perfil correto do scc e crie o 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. Verifique novamente se o NGINX está em execução, listando os 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. Verificar logs.

    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. Confira Ingresso.

    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. Conecte-se ao URL do proxy reverso.

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

    {"status":"UP"}
    

Redirecionar o tráfego para usar o Direct Link Caminho

Agora que o relé está pronto para fazer o proxy do tráfego de entrada para o Ingress interno do servidor de túnel, você pode configurar o host ou o conector do local para redirecionar o tráfego por meio do relé. Isso garante que todo o tráfego permanecerá no caminho Direct Link em sua rede privada e nenhum tráfego usará a Internet pública.

Redirecione o tráfego para seu agente Connector ou host de local seguindo as instruções aplicáveis abaixo.