Configuração de balanceadores de carga e do serviço de armazenamento em nuvem ( DNS )

Editar online

Para habilitar o acesso público aos pontos de extremidade da interface do usuário do Acceptor, do Gateway e do Instana, é necessário configurar tanto os balanceadores de carga quanto o DNS.

O processo de configuração varia dependendo se você está usando Kubernetes ou Red Hat OpenShift como backend do Instana :

Para o ` Kubernetes `, você deve definir entradas (Ingresses) ou criar serviços do tipo LoadBalancer` DNS ` e atualizar seus registros A.
Para o Red Hat OpenShift, você deve definir rotas ou criar serviços do tipo LoadBalancer, e atualizar seus registros A do DNS. Podem ser necessárias configurações adicionais para o monitoramento de sites e aplicativos móveis; consulte Monitoramento de sites e aplicativos móveis ( Red Hat OpenShift ).

- [Configuring endpoints on the Instana backend on Kubernetes](#configuring-endpoints-on-the-instana-backend-on-kubernetes)
- [Domain configuration](#domain-configuration)
- [Instana backend on Kubernetes](#instana-backend-on-kubernetes)
- [Acceptor](#acceptor)
- [Configuring endpoints on the Instana backend on Red Hat OpenShift](#configuring-endpoints-on-the-instana-backend-on-red-hat-openshift)
- [DNS configuration](#dns-configuration)
- [Website and mobile app monitoring (Red Hat OpenShift)](#website-and-mobile-app-monitoring-red-hat-openshift)
- [Sample configuration: Load balancer or reverse proxy between the client web browser and the Instana backend](#sample-configuration-load-balancer-or-reverse-proxy-between-the-client-web-browser-and-the-instana-backend)
- [Sample configuration: No load balancer or reverse proxy between the client browser and the Instana backend](#sample-configuration-no-load-balancer-or-reverse-proxy-between-the-client-browser-and-the-instana-backend)

Configurando pontos de extremidade no backend do Instana em Kubernetes

Editar online

No ` Kubernetes `, você pode definir Ingresses ou criar ` LoadBalancer-type Services Ingresses` para expor seus endpoints.

Para expor seus pontos de extremidade do Acceptor e do Gateway por meio de um LoadBalancer-type serviço, consulte os exemplos do ` YAML ` específicos para cada plataforma: ` Azure Kubernetes Service ` ( AKS ), `Amazon Elastic Kubernetes Service ` (EKS) ou ` Google Kubernetes Engine ` ( GKE ). Esses exemplos fornecem as anotações e configurações necessárias para parâmetros como grupos de recursos, rótulo do DNS, sub-redes e endereços IP, adaptados a cada plataforma. Para o ` Kubernetes `, você deve definir Ingresses ou criar Serviços do tipo LoadBalancer. Para o ` Red Hat OpenShift `, você deve definir rotas ou criar serviços do tipo LoadBalancer.

Configuração de domínio

Editar online

Tanto para o backend Instana em Kubernetes quanto para o backend Instana em Red Hat OpenShift, é necessário configurar registros A no seu DNS para o domínio do subdomínio base_domainAcceptor (geralmente ingress), para os subdomínios Acceptor OTLP (otlp-http e otlp-grpc), e para todos os subdomínios de unidades de locatários:

<base_domain>
ingress.<base_domain>
opamp-acceptor.<base_domain>
otlp-http.<base_domain>
otlp-grpc.<base_domain>
<unit-name>-<tenant-name>.<base_domain>

Observação: Se você deseja usar apenas <base_domain> para todo o seu tráfego de entrada, consulte Ativando o suporte para domínio único de entrada.

Em seguida, configure os domínios no CoreSpec conforme mostrado no código a seguir. Para obter mais informações sobre o CoreSpec, consulte Criando um Core.

spec:
  agentAcceptorConfig:
    host: ingress.<base_domain>
    port: 443
  baseDomain: <base_domain>

Instana backend em Kubernetes

Editar online

Se você deseja que o Operador Empresarial do Instana crie os serviços do LoadBalancer para você, consulte “Criação automática de serviços do LoadBalancer ”.

Para configurar balanceadores de carga para o seu backend do Instana no Kubernetes, use os Serviços do tipo LoadBalancer da seguinte maneira:

Aceitador

Editar online

Crie um arquivo ` YAML `, como, por exemplo, service.yaml.

Defina o Acceptor no service.yaml arquivo e execute uma das etapas a seguir, dependendo do seu ambiente:

Para a revista “ Azure Kubernetes Service ” ( AKS ):

apiVersion: v1
kind: Service
metadata:
  namespace: instana-core
  annotations:
    # For additional Loadbalancer annotations, kindly refer: https://cloud-provider-azure.sigs.k8s.io/topics/loadbalancer/#loadbalancer-annotations
    service.beta.kubernetes.io/azure-load-balancer-resource-group: <your-resource-group>
    service.beta.kubernetes.io/azure-load-balancer-internal: "false" #if internet facing
    service.beta.kubernetes.io/azure-dns-label-name: <dns-label-name>
  name: loadbalancer-acceptor
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local
  ports:
    - name: http-service
      port: 443
      protocol: TCP
      targetPort: http-service
  selector:
    app.kubernetes.io/name: instana
    app.kubernetes.io/component: acceptor
    instana.io/group: service

Para o Amazon Elastic Kubernetes Service (EKS):

apiVersion: v1
kind: Service
metadata:
  namespace: instana-core
  annotations:
    # To explore on more service annotations, kindly refer the documentation - https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.8/guide/service/annotations/
    service.beta.kubernetes.io/aws-load-balancer-name: <your-load-balancer-name>
    service.beta.kubernetes.io/aws-load-balancer-subnets: <subnet1-name>,<subnet2-name>,<subnet3-name>
    service.beta.kubernetes.io/aws-load-balancer-ip-address-type: ipv4
    service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"
  name: loadbalancer-acceptor
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local
  ports:
    - name: http-service
      port: 443
      protocol: TCP
      targetPort: http-service
  selector:
    app.kubernetes.io/name: instana
    app.kubernetes.io/component: acceptor
    instana.io/group: service

Para a revista “ Google Kubernetes Engine ” ( GKE ):

apiVersion: v1
kind: Service
metadata:
  namespace: instana-core
  annotations:
    # To explore on more service annotations, kindly refer the documentation https://cloud.google.com/kubernetes-engine/docs/concepts/service-load-balancer
    cloud.google.com/l4-rbs: "enabled"
  name: loadbalancer-acceptor
spec:
  type: LoadBalancer
  loadBalancerIP: <your_loadbalancer_IP>
  externalTrafficPolicy: Local
  ports:
    - name: http-service
      port: 443
      protocol: TCP
      targetPort: http-service
  selector:
    app.kubernetes.io/name: instana
    app.kubernetes.io/component: acceptor
    instana.io/group: service

Substitua < your_loadbalancer_IP> pelo endereço IP de seu balanceador de carga

Defina o gateway no service.yaml arquivo e execute uma das etapas a seguir, dependendo do seu ambiente:

Para a revista “ Azure Kubernetes Service ” ( AKS ):

apiVersion: v1
kind: Service
metadata:
  namespace: instana-core
  name: loadbalancer-gateway
  annotations:
    # For additional Loadbalancer annotations, kindly refer: https://cloud-provider-azure.sigs.k8s.io/topics/loadbalancer/#loadbalancer-annotations
    service.beta.kubernetes.io/azure-load-balancer-resource-group: <your-resource-group>
    service.beta.kubernetes.io/azure-load-balancer-internal: "false" #internet facing
    service.beta.kubernetes.io/azure-dns-label-name: <dns-label-name>
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local
  ports:
    - name: https
      port: 443
      protocol: TCP
      targetPort: https
    - name: http
      port: 80
      protocol: TCP
      targetPort: http
  selector:
    app.kubernetes.io/name: instana
    app.kubernetes.io/component: gateway
    instana.io/group: service

Para o Amazon Elastic Kubernetes Service (Amazon EKS):

apiVersion: v1
kind: Service
metadata:
  namespace: instana-core
  name: loadbalancer-gateway
  annotations:
    # To explore on more service annotations, kindly refer the documentation - https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.8/guide/service/annotations/
    service.beta.kubernetes.io/aws-load-balancer-name: <your-gateway-name>
    service.beta.kubernetes.io/aws-load-balancer-ip-address-type: ipv4
    service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"
    service.beta.kubernetes.io/aws-load-balancer-subnets: <subnet1-name>,<subnet2-name>,<subnet3-name>
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local
  ports:
    - name: https
      port: 443
      protocol: TCP
      targetPort: https
    - name: http
      port: 80
      protocol: TCP
      targetPort: http
  selector:
    app.kubernetes.io/name: instana
    app.kubernetes.io/component: gateway
    instana.io/group: service

Para a revista “ Google Kubernetes Engine ” ( GKE ):

apiVersion: v1
kind: Service
metadata:
  namespace: instana-core
  name: loadbalancer-gateway
  annotations:
    # To explore on more service annotations, kindly refer the documentation https://cloud.google.com/kubernetes-engine/docs/concepts/service-load-balancer
    cloud.google.com/l4-rbs: "enabled"
spec:
  type: LoadBalancer
  loadBalancerIP: <your_loadbalancer_IP>
  externalTrafficPolicy: Local
  ports:
    - name: https
      port: 443
      protocol: TCP
      targetPort: https
    - name: http
      port: 80
      protocol: TCP
      targetPort: http
  selector:
    app.kubernetes.io/name: instana
    app.kubernetes.io/component: gateway
    instana.io/group: service

Observação: Substitua <your_loadbalancer_IP> pelo endereço IP do seu balanceador de carga.

Se o Gateway Controller estiver ativado, atualize o seletor do loadbalancer-gateway conforme mostrado no exemplo a seguir, para que o tráfego de entrada seja encaminhado corretamente para os novos pods do gateway-v2.

apiVersion: v1
kind: Service
metadata:
  namespace: instana-core
  name: loadbalancer-gateway
spec:
  selector:
    ...
    app.kubernetes.io/component: gateway-v2 # changed from gateway
    ...

Se o Gateway Controller estiver ativado e você tiver configurado portas diferentes de 443 para qualquer um dos aceitadores, será necessário expor essas portas para garantir que o Kubernetes e possa direcionar o tráfego para o seu ambiente da Custom Edition, adicionando o seguinte bloco de configuração no balanceador de carga do Gateway:

apiVersion: v1
kind: Service
metadata:
  namespace: instana-core
  name: loadbalancer-gateway
spec:
  type: LoadBalancer
  ports:
    ...
    - name: <ACCEPTOR_NAME>
      port: <ACCEPTOR_PORT>
      protocol: TCP
      targetPort: <ACCEPTOR_PORT>
    ...

É necessário adicionar um bloco de configuração de porta para cada porta de aceitação configurada em uma porta diferente de 443.

Aplique o arquivo ` YAML ` executando o seguinte comando:
```
kubectl apply -f service.yaml -n <CORE_NAMESPACE>
 
```
Substitua < CORE_NAMESPACE> pelo namespace do objeto Core .

Configurando pontos de extremidade no backend do Instana em Red Hat OpenShift

Editar online

No ` Red Hat OpenShift `, você pode definir rotas ou criar endpoints LoadBalancer-type Services para disponibilizá-los.

Exponha o Acceptor e os pontos finais por meio de um serviço do tipo rota:

oc create route passthrough acceptor --hostname=<acceptor_subdomain> --service=acceptor  --port=8443 -n instana-core

Exponha o Acceptor e os endpoints do ` OpenTelemetry ` por meio de um serviço do tipo rota:

oc create route passthrough opamp-acceptor --hostname=opamp-acceptor.<base_domain> --service=gateway --port=https -n instana-core
oc create route passthrough otlp-http-acceptor --hostname=otlp-http.<base_domain> --service=gateway  --port=https -n instana-core
oc create route passthrough otlp-grpc-acceptor --hostname=otlp-grpc.<base_domain> --service=gateway  --port=https -n instana-core

Exponha os pontos de extremidade do Gateway por meio de um serviço do tipo rota:

oc create route passthrough base-domain --hostname=<base_domain> --service=gateway --port=https -n instana-core

oc create route passthrough <unitName>-<tenantName>-ui --hostname=<unitName>-<tenantName>.<base_domain> --service=gateway --port=https -n instana-core

(Opcional) Monitore sites e aplicativos móveis em Red Hat OpenShift; consulte Monitoramento de sites e aplicativos móveis ( Red Hat OpenShift.

Configuração de DNS

Editar online

Tanto para o backend do Instana em Kubernetes quanto para Red Hat OpenShift, você precisa criar registros A no seu DNS que apontem para os IPs públicos dos seus serviços para os seguintes subdomínios:

<base_domain>: O domínio pai ou raiz de todos os subdomínios relacionados.
ingress.<base_domain>: Normalmente utilizado para o serviço Agent Acceptor ou Ingress.
opamp-acceptor.<base_domain>: Gerencia coletores do OpenTelemetry através do OpAMP. É utilizado para gerenciar coletores d OpenTelemetry.
otlp-http.<base_domain>: Processa dados de telemetria por meio de OTLP HTTP. É utilizado para enviar dados de rastreamentos e métricas por meio de solicitações do tipo ` HTTP `.
otlp-grpc.<base_domain>: Processa dados de telemetria por meio de OTLP gRPC. É utilizado para enviar dados de rastreamentos e métricas por meio do gRPC. gRPC é mais eficiente e tem melhor desempenho do que o ` HTTP `.
<unit-name>-<tenant-name>.<base_domain>: O subdomínio da unidade do locatário é usado para acessar a interface do usuário do Instana de uma unidade específica dentro de um locatário.

Configure os domínios no arquivo ` CoreSpecs `, conforme mostrado no código a seguir, e aplique as alterações. Para obter mais informações sobre o CoreSpec, consulte Criando um Core.
```
spec:
  agentAcceptorConfig:
    host: ingress.<base_domain>
    port: 443
  baseDomain: <base_domain>
 
```
Após a conclusão da instalação, obtenha o IP público do serviço LoadBalancer ou do serviço Ingress.
Crie registros A no seu provedor de DNS para direcionar seus subdomínios aos endereços IP públicos.

Monitoramento de sites e aplicativos móveis ( Red Hat OpenShift )

Editar online

Se você deseja coletar apenas beacons de sites e aplicativos móveis sem usar endereços IP de clientes ou serviços de geolocalização, essa gateway configuração é suficiente. É provável que o endereço IP do cliente apareça como um endereço interno dentro do cluster Red Hat OpenShift.

Para coletar o endereço IP real do cliente ou ativar os serviços de geolocalização, é necessário seguir mais algumas etapas. Essas etapas garantem que o endereço IP do cliente seja mantido enquanto o beacon percorre a topologia da rede até o backend do Instana.

O aceitador EUM no backend utiliza o x-forwarded-for cabeçalho das solicitações recebidas para determinar o endereço IP do cliente. Embora o componente de gateway do serviço de gerenciamento de endereços de rede ( Instana ) possa adicionar esse cabeçalho, o endereço IP do cliente costuma estar incorreto quando a solicitação chega ao gateway em uma configuração típica do serviço de gerenciamento de endereços de rede ( Red Hat OpenShift ). O problema ocorre porque a solicitação passa por um componente que lida com a tradução de endereços de rede (NAT), como um balanceador de carga ou um proxy reverso. As causas mais comuns desse problema são:

Equipamento de balanceamento de carga ou proxy reverso que converte um endereço IP público em um endereço IP privado na borda da rede da empresa (haproxy ou Nginx )
Balanceador de carga ou proxy reverso que envia uma solicitação aos nós principais do Red Hat OpenShift ( HAProxy ou Nginx )
O controlador de entrada do Red Hat OpenShift

Em uma topologia de rede com componentes NAT, é essencial definir o x-forwarded-for cabeçalho enquanto o endereço IP do cliente ainda estiver correto. A solução é configurar o proxy reverso ou o balanceador de carga para definir esse cabeçalho.

Um proxy reverso ou balanceador de carga só pode modificar uma solicitação se ela não estiver criptografada. Para adicionar o x-forwarded-for cabeçalho, a solicitação deve ser descriptografada, modificada e, em seguida, criptografada novamente. A maioria dos proxies reversos e balanceadores de carga suporta esse processo, mas ele requer mais um certificado de " TLS " no proxy ou no balanceador de carga. O controlador de entrada do Red Hat OpenShift também pode lidar com isso usando uma rota do tipo reencrypt.

Exemplo de configuração: balanceador de carga ou proxy reverso entre o navegador do cliente e o backend do Instana

Editar online

Considere um cenário em que um balanceador de carga ou um proxy reverso esteja posicionado entre o navegador do cliente e o backend do Instana em Red Hat OpenShift. Nesse cenário, o backend do Instana utiliza o controlador de ingress Red Hat OpenShift para processar as solicitações. O balanceador de carga ou o proxy reverso pode ser configurado para preservar o endereço IP do cliente ao adicionar o x-forwarded-for cabeçalho. Essa configuração envolve encerrar a conexão TLS, inserir o cabeçalho e, em seguida, criptografar novamente a conexão. Após a recriptografia, o balanceador de carga ou o proxy reverso encaminha a solicitação para o gateway Instana por meio do controlador de entrada Red Hat OpenShift.

sample-1

Nessa configuração, uma passthrough rota pode ser usada para direcionar o tráfego para o gateway Instana, já que o x-forwarded-for cabeçalho já está adicionado à solicitação com o endereço IP correto. Consequentemente, o Ingress Controller não precisa descriptografar a solicitação.

Exemplo de configuração: sem balanceador de carga ou proxy reverso entre o navegador do cliente e o backend do Instana

Editar online

Quando não há nenhum balanceador de carga ou proxy reverso entre o navegador do cliente e o backend do Instana em Red Hat OpenShift, o controlador de ingress Red Hat OpenShift é o único componente que realiza NAT. Nesse cenário, uma reencrypt rota pode adicionar o x-forwarded-for cabeçalho à solicitação antes que ela chegue ao gateway do Instana. Por padrão, o controlador de entrada do Red Hat OpenShift adiciona o x-forwarded-for cabeçalho caso ele esteja ausente ou acrescenta o endereço IP do cliente ao cabeçalho, caso ele já exista.

sample-2