Configuration des équilibreurs de charge et de l' DNS

Modifier en ligne

Pour permettre l'accès public aux points de terminaison de l'interface utilisateur de l'Acceptor, de la Gateway et de l' Instana, vous devez configurer à la fois les équilibreurs de charge et l' DNS.

La procédure d'installation varie selon que vous utilisiez Kubernetes ou Red Hat OpenShift comme backend pour Instana :

  • Pour l' Kubernetes e, vous devez soit définir des Ingresses, soit créer des services de type LoadBalancer, puis mettre à jour vos enregistrements A sur DNS.
  • Pour l' Red Hat OpenShift e, vous devez soit définir des routes, soit créer des services de type LoadBalancer, puis mettre à jour vos enregistrements A de DNS. Des configurations supplémentaires peuvent être nécessaires pour la surveillance des sites Web et des applications mobiles; consultez la page « Surveillance des sites Web et des applications mobiles » ( 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)

Configuration des points de terminaison sur le backend Instana sur Kubernetes

Modifier en ligne

Dans Kubernetes, vous pouvez soit définir des Ingresses, soit en créer LoadBalancer-type Services pour rendre vos points de terminaison accessibles.

Pour exposer vos points de terminaison Acceptor et Gateway via un LoadBalancer-type service, consultez les exemples d' YAML s spécifiques à chaque plateforme pour Azure Kubernetes Service ( AKS ), Amazon Elastic Kubernetes Service (EKS) ou Google Kubernetes Engine ( GKE ). Ces exemples fournissent les annotations et les configurations nécessaires pour des paramètres tels que les groupes de ressources, l'étiquette DNS, les sous-réseaux et les adresses IP, adaptés à chaque plateforme. Pour l' Kubernetes e, vous devez soit définir des Ingresses, soit créer des services de type LoadBalancer. Pour l' Red Hat OpenShift e, vous devez soit définir des routes, soit créer des services de type LoadBalancer.

Configuration de domaine

Modifier en ligne

Que ce soit pour le backend Instana sur Kubernetes ou pour le backend Instana sur Red Hat OpenShift, vous devez configurer des enregistrements A dans votre DNS pour le domaine du sous-domaine base_domainAcceptor (généralement ingress), pour les sous-domaines Acceptor OTLP (otlp-http et otlp-grpc), ainsi que pour tous les sous-domaines des unités de locataires :

  • <base_domain>
  • ingress.<base_domain>
  • opamp-acceptor.<base_domain>
  • otlp-http.<base_domain>
  • otlp-grpc.<base_domain>
  • <unit-name>-<tenant-name>.<base_domain>
Remarque : si vous souhaitez utiliser uniquement <base_domain> pour tout votre trafic entrant, consultez la section « Activation de la prise en charge d'un domaine d'entrée unique ».

Ensuite, configurez les domaines dans le CoreSpec comme indiqué dans le code suivant. Pour plus d'informations sur CoreSpec, voir Créer un Core.

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

Instana backend sur Kubernetes

Modifier en ligne

Si vous souhaitez que l'opérateur d'entreprise d' Instana crée pour vous les services LoadBalancer, consultez la section Création automatique des services LoadBalancer.

Pour configurer des équilibreurs de charge pour votre backend Instana sur Kubernetes, utilisez les services de type LoadBalancer comme suit :

Accepteur

Modifier en ligne

  1. Créez un fichier « YAML », par exemple service.yaml.

  2. Définissez l'acceptateur dans le service.yaml fichier, puis effectuez l'une des opérations suivantes en fonction de votre environnement :

    • Pour 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

    • Pour Amazon Elastic Kubernetes Service s (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

    • Pour 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

      Remplacez < votre_IP_équilibre_charge> par l'adresse IP de votre équilibreur de charge.

  3. Configurez la passerelle dans le service.yaml fichier, puis effectuez l'une des opérations suivantes en fonction de votre environnement :

    • Pour 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

    • Pour 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
    • Pour 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
    Remarque : Remplacez <your_loadbalancer_IP> par l'adresse IP de votre équilibreur de charge.

    Si le contrôleur de passerelle est activé, mettez à jour le sélecteur de la passerelle de répartition de charge comme indiqué dans l'exemple suivant afin que le trafic entrant soit correctement redirigé vers les nouveaux pods « gateway-v2 ».

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

    Si le contrôleur de passerelle est activé et que vous avez configuré des ports autres que 443 pour l'un des accepteurs, vous devez exposer ces ports afin de permettre à Kubernetes d'acheminer le trafic vers votre environnement Custom Edition, en ajoutant le bloc de configuration suivant dans l'équilibreur de charge de la passerelle :

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

    Il faut ajouter un bloc de configuration de port pour chaque port d'acceptation configuré sur un port autre que 443.

  4. Appliquez le fichier « YAML » en exécutant la commande suivante :

    kubectl apply -f service.yaml -n <CORE_NAMESPACE>

    Remplacez < CORE_NAMESPACE> par l'espace de nom de l'objet Core .

Configuration des points de terminaison sur le backend Instana sur Red Hat OpenShift

Modifier en ligne

Dans Red Hat OpenShift, vous pouvez soit définir des routes, soit créer des routes LoadBalancer-type Services pour rendre vos points de terminaison accessibles.

  1. Exposez l'acceptor et les points de terminaison à l'aide d'un service de type route :

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

  2. Exposez l'acceptateur et les points de terminaison de l' OpenTelemetry s à l'aide d'un service de type route :

    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

  3. Exposer les points de terminaison de la passerelle à l'aide d'un service de type route :

    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

  4. (Facultatif) Surveillez le fonctionnement de votre site web et de votre application mobile sur Red Hat OpenShift; consultez la section « Surveillance des sites web et des applications mobiles » ( Red Hat OpenShift.

Configuration DNS

Modifier en ligne

Pour les deux backends Instana sur Kubernetes et Red Hat OpenShift, vous devez créer des enregistrements A dans votre DNS qui pointent vers les adresses IP publiques de vos services pour les sous-domaines suivants :

  • <base_domain>: Le domaine parent ou racine de tous les sous-domaines associés.
  • ingress.<base_domain>: Généralement utilisé pour le service Agent Acceptor ou Ingress.
  • opamp-acceptor.<base_domain>: Gère les collecteurs d' OpenTelemetry s via OpAMP. Il sert à gérer les collecteurs d' OpenTelemetry s.
  • otlp-http.<base_domain>: Gère les données de télémétrie via OTLP HTTP. Il sert à envoyer des données de traces et de métriques via des requêtes HTTP.
  • otlp-grpc.<base_domain>: Gère les données de télémétrie via OTLP gRPC. Il sert à envoyer des données de traces et de métriques via gRPC. gRPC est plus efficace et performant qu' HTTP
  • <unit-name>-<tenant-name>.<base_domain>: Le sous-domaine de l'unité de locataire permet d'accéder à l'interface utilisateur d' Instana d'une unité spécifique au sein d'un locataire.

  1. Configurez les domaines dans le fichier « CoreSpecs » tel qu'indiqué dans le code ci-dessous, puis enregistrez-le. Pour plus d'informations sur CoreSpec, voir Créer un Core.

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

  2. Une fois l'installation terminée, récupérez l'adresse IP publique de l' LoadBalancer e ou du service Ingress.

  3. Créez des enregistrements A chez votre fournisseur d' DNS s pour rediriger vos sous-domaines vers les adresses IP publiques.

Surveillance des sites web et des applications mobiles ( Red Hat OpenShift )

Modifier en ligne

Si vous souhaitez collecter uniquement les balises des sites Web et des applications mobiles sans utiliser les adresses IP des clients ni les services de géolocalisation, cette gateway configuration suffit. L'adresse IP du client apparaîtra probablement comme une adresse interne au sein du cluster Red Hat OpenShift.

Pour récupérer l'adresse IP réelle du client ou activer les services de géolocalisation, vous devez suivre quelques étapes supplémentaires. Ces étapes garantissent que l'adresse IP du client est conservée tout au long du parcours de la balise à travers la topologie du réseau jusqu'au serveur backend d' Instana.

L'acceptor EUM du backend utilise x-forwarded-for l'en-tête des requêtes entrantes pour déterminer l'adresse IP du client. Bien que le composant de passerelle « Instana » puisse ajouter cet en-tête, l'adresse IP du client est souvent erronée au moment où la requête parvient à la passerelle dans une configuration classique d' Red Hat OpenShift. Ce problème survient parce que la requête transite par un composant qui gère la traduction d'adresses réseau (NAT), tel qu'un équilibreur de charge ou un proxy inverse. Les causes les plus courantes de ce problème sont les suivantes :

  • Équilibreur de charge ou proxy inverse qui convertit une adresse IP publique en adresse IP privée à la périphérie du réseau de l'entreprise (haproxy ou Nginx )
  • Équilibreur de charge ou proxy inverse qui envoie une requête aux nœuds maîtres d' Red Hat OpenShift ( HAProxy ou Nginx )
  • Le contrôleur d'entrée de l' Red Hat OpenShift

Dans une topologie réseau comportant des composants NAT, il est essentiel de configurer x-forwarded-for l'en-tête tant que l'adresse IP du client est encore valide. La solution consiste à configurer le proxy inverse ou l'équilibreur de charge pour qu'il définisse cet en-tête.

Un proxy inverse ou un équilibreur de charge ne peut modifier une requête que si celle-ci n'est pas chiffrée. Pour ajouter x-forwarded-for l'en-tête, la requête doit être déchiffrée, modifiée, puis rechiffrée. La plupart des proxys inversés et des équilibreurs de charge prennent en charge ce processus, mais cela nécessite un certificat « TLS » supplémentaire au niveau du proxy ou de l'équilibreur de charge. Le contrôleur d'entrée « Red Hat OpenShift » peut également gérer cela à l'aide d'une route de type reencrypt.

Exemple de configuration : un équilibreur de charge ou un proxy inverse entre le navigateur Web du client et le backend Instana

Modifier en ligne

Imaginons un scénario dans lequel un équilibreur de charge ou un proxy inverse est placé entre le navigateur Web du client et le serveur backend d' Instana, accessible à l'adresse Red Hat OpenShift. Dans ce scénario, le backend Instana utilise le contrôleur Ingress Red Hat OpenShift pour traiter les requêtes. Le répartiteur de charge ou le proxy inverse peut être configuré pour conserver l'adresse IP du client afin d'ajouter x-forwarded-for l'en-tête. Cette configuration consiste à interrompre la connexion TLS, à insérer l'en-tête, puis à rechiffrer la connexion. Une fois le chiffrement effectué, l'équilibreur de charge ou le proxy inverse transmet la requête à la passerelle Instana via le contrôleur d'entrée Red Hat OpenShift.

sample-1

Dans cette configuration, une passthrough route peut être utilisée pour acheminer le trafic vers la passerelle Instana, car x-forwarded-for l'en-tête est déjà ajouté à la requête avec l'adresse IP correcte. Par conséquent, le contrôleur d'entrée n'a pas besoin de déchiffrer la requête.

Exemple de configuration : aucun équilibreur de charge ni proxy inverse entre le navigateur du client et le backend de Instana

Modifier en ligne

Lorsqu'il n'y a ni équilibreur de charge ni proxy inverse entre le navigateur du client et le backend de l' Instana sur Red Hat OpenShift, le contrôleur Ingress de l' Red Hat OpenShift est le seul composant à effectuer la traduction d'adresses réseau (NAT). Dans ce scénario, une reencrypt route peut ajouter x-forwarded-for l'en-tête à la requête avant que celle-ci n'atteigne la passerelle Instana. Par défaut, le contrôleur Ingress d' Red Hat OpenShift ajoute x-forwarded-for l'en-tête s'il est absent ou ajoute l'adresse IP du client à l'en-tête s'il existe déjà.

sample-2