ロードバランサーと DNS の設定

Acceptor、Gateway、および Instana のUIエンドポイントへの一般公開を有効にするには、ロードバランサーと DNS の両方を設定する必要があります。

Instana のバックエンドとして Kubernetes を使用するか、 Red Hat OpenShift を使用するかによって、セットアップの手順は異なります:

  • Kubernetes を使用するには、Ingress を定義するか、または ` LoadBalancerService` タイプのサービスを作成し、 DNS の Aレコードを更新する必要があります。
  • Red Hat OpenShift を使用するには、Routes を定義するか、 LoadBalancerまたは 型の Service を作成し、 DNS の Aレコードを更新する必要があります。 Webサイトおよびモバイルアプリの監視には、追加の設定が必要になる場合があります。 詳しくは、「Webサイトおよびモバイルアプリの監視」( 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)
 

Kubernetes 上の Instana バックエンドにおけるエンドポイントの設定

Kubernetes では、エンドポイントを公開するために、Ingress LoadBalancer-type Services を定義するか、または作成することができます。

サービス LoadBalancer-type を通じてAcceptorおよびGatewayエンドポイントを公開するには、 Azure Kubernetes Service ( AKS )、Amazon Elastic Kubernetes Service (EKS)、または Google Kubernetes Engine ( GKE )向けのプラットフォーム固有の YAML サンプルを参照してください。これらのサンプルには、各プラットフォームに合わせて調整されたリソースグループ、 DNS ラベル、サブネット、IPアドレスなどのパラメータに必要なアノテーションや設定が記載されています。 Kubernetes を使用するには、Ingress を定義するか、 LoadBalancerまたは タイプの Service を作成する必要があります。 Red Hat OpenShift を使用するには、Routes を定義するか、または. LoadBalancer型の Service を作成する必要があります。

ドメイン構成

Kubernetes 上の Instana バックエンドと、 Red Hat OpenShift 上の Instana バックエンドの両方について、 base_domainDNS で、Acceptor サブドメイン(通常は ingress)、 OTLP の Acceptor サブドメイン(otlp-http および otlp-grpc)、およびすべてのテナントユニットサブドメインに対して A レコードを設定する必要があります:

  • <base_domain>
  • ingress.<base_domain>
  • opamp-acceptor.<base_domain>
  • otlp-http.<base_domain>
  • otlp-grpc.<base_domain>
  • <unit-name>-<tenant-name>.<base_domain>
注: すべてのIngress <base_domain> トラフィックで単一のドメインのみを使用したい場合は、「単一Ingressドメインのサポートを有効にする」を参照してください。

次に、以下のコードのように、CoreSpecでドメインを設定する。 CoreSpecの詳細については、コアの作成を参照してください。

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

Instana Kubernetes のバックエンド

Instana Enterprise Operator に LoadBalancer サービスの作成を代行させたい場合は、 「 LoadBalancer サービスの自動作成」 を参照してください。

Kubernetes 上の Instana バックエンド用にロードバランサーを設定するには、次のように「タイプ LoadBalancer 」が「Services」のオブジェクトを使用します:

アクセプター

  1. 次のような service.yamlYAML ファイルを作成します。

  2. ファイル service.yaml で「Acceptor」を設定し、お使いの環境に応じて以下のいずれかの手順を実行してください:

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

      < your_loadbalancer_IP> をロード・バランサーの IP アドレスに置き換えます。

  3. ファイル service.yaml でゲートウェイを設定し、お使いの環境に応じて以下のいずれかの手順を実行してください:

    • 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
       
    • 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
     
    • 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
     
    注: <your_loadbalancer_IP> を、お使いのロードバランサーの IP アドレスに置き換えてください。

    ゲートウェイコントローラーが有効になっている場合は、次の例に示すように、loadbalancer-gatewayのセレクターを更新し、着信トラフィックが新しい gateway-v2 ポッドに正しく転送されるようにしてください。

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

    ゲートウェイコントローラーが有効になっており、いずれかのアクセプター 443 に対してデフォルト以外のポートを設定している場合は、 Kubernetes がトラフィックをCustom Edition 環境に確実に取り込めるように、ゲートウェイロードバランサーに以下の設定ブロックを追加して、それらのポートを公開する必要があります:

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

    . 以外のポートに設定されている各アクセプタポート 443について、ポート設定ブロックを追加する必要があります。

  4. 次のコマンドを実行して、 YAML ファイルを適用します:

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

    < CORE_NAMESPACE>Core オブジェクトの名前空間に置き換えます。

Red Hat OpenShift 上の Instana バックエンドにおけるエンドポイントの設定

Red Hat OpenShift では、エンドポイントを公開するために、Routes LoadBalancer-type Services を定義するか、または作成することができます。

  1. ルート型サービスを使用して、アクセプタとエンドポイントを公開します:

    oc create route passthrough acceptor --hostname=<acceptor_subdomain> --service=acceptor  --port=8443 -n instana-core
     
  2. OpenTelemetry のアクセプタとエンドポイントを、ルート型サービスとして公開します:

    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. ルート型サービスを使用してゲートウェイのエンドポイントを公開します:

    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. (オプション) Red Hat OpenShift でのウェブサイトおよびモバイルアプリの監視については、 「ウェブサイトおよびモバイルアプリの監視」( Red Hat OpenShift ) を参照してください。

DNS 構成

Kubernetes および Red Hat OpenShift の両方の「 Instana 」バックエンドについては、 DNS に、以下のサブドメインに対応するサービスのパブリック IP アドレスを指す A レコードを作成する必要があります:

  • <base_domain>: 関連するすべてのサブドメインの親ドメインまたはルートドメイン。
  • ingress.<base_domain>: 通常、エージェント・アクセプターまたはインジェス・サービスに使用されます。
  • opamp-acceptor.<base_domain>: OpAMP 経由で OpenTelemetry のコレクターを管理します。 OpenTelemetry コレクターの管理に使用されます。
  • otlp-http.<base_domain>: OTLP および HTTP 経由でテレメトリデータを処理します。 これは、 HTTP リクエストを通じてトレースおよびメトリクスデータを送信するために使用されます。
  • otlp-grpc.<base_domain>: OTLP および gRPC 経由でテレメトリデータを処理します。 これは、 gRPC を通じてトレースおよびメトリクスデータを送信するために使用されます。 gRPC HTTP よりも効率的で高性能です。
  • <unit-name>-<tenant-name>.<base_domain>: テナント・ユニット・サブドメインは、テナント内の特定のユニットの Instana UIにアクセスするために使用されます。
  1. 以下のコードに示されている CoreSpecs 内のドメインを設定し、適用してください。 CoreSpecの詳細については、コアの作成を参照してください。

    spec:
      agentAcceptorConfig:
        host: ingress.<base_domain>
        port: 443
      baseDomain: <base_domain>
     
  2. インストールが完了したら、 LoadBalancer またはIngressサービスのパブリックIPを取得してください。

  3. DNS プロバイダーでAレコードを作成し、サブドメインをパブリックIPアドレスに設定してください。

ウェブサイトおよびモバイルアプリの監視( Red Hat OpenShift )

クライアントのIPアドレスや位置情報サービスを使用せずに、ウェブサイトやモバイルアプリケーションのビーコンのみを収集したい場合は、この gateway 設定で十分です。 クライアントのIPアドレスは、 Red Hat OpenShift クラスター内では内部アドレスとして表示される可能性があります。

クライアントの実際のIPアドレスを取得したり、位置情報サービスを有効にしたりするには、さらにいくつかの手順が必要です。 これらの手順により、ビーコンがネットワークトポロジーを経由して Instana のバックエンドに到達する際、クライアントのIPアドレスが保持されるようになります。

バックエンドのEUMアクセプターは、着信リクエストのヘッダーに基づいてクライアント x-forwarded-for のIPアドレスを特定します。 Instana ゲートウェイコンポーネントはこのヘッダーを追加できますが、一般的な Red Hat OpenShift 構成では、リクエストがゲートウェイに到達する時点で、クライアントのIPアドレスが正しくないことがよくあります。 この問題は、リクエストがロードバランサーやリバースプロキシなど、ネットワークアドレス変換(NAT)を処理するコンポーネントを経由するために発生します。 この問題の最も一般的な原因は以下の通りです:

  • 企業ネットワークの境界でパブリックIPアドレスをプライベートIPアドレスに変換するロードバランサーまたはリバースプロキシ(haproxyまたは Nginx )
  • Red Hat OpenShift のマスターノード( HAProxy または Nginx )にリクエストを送信するロードバランサーまたはリバースプロキシ
  • Red Hat OpenShift イングレッション・コントローラー

NATコンポーネントを含むネットワークトポロジーでは、クライアントのIPアドレスがまだ正確なうちに x-forwarded-for ヘッダーを設定することが不可欠です。 解決策は、リバースプロキシまたはロードバランサーを設定して、このヘッダーを設定するようにすることです。

リバースプロキシやロードバランサーは、リクエストが暗号化されていない場合にのみ、その内容を変更することができます。 この x-forwarded-for ヘッダーを追加するには、リクエストを復号化し、変更を加えた上で、再度暗号化する必要があります。 ほとんどのリバースプロキシやロードバランサーはこのプロセスをサポートしていますが、プロキシまたはロードバランサー側に TLS 証明書をもう1つ用意する必要があります。 Red Hat OpenShift のIngressコントローラーも、タイプが のルート reencryptを使用してこれを処理できます。

構成例:クライアントのWebブラウザと Instana のバックエンドの間にロードバランサーまたはリバースプロキシを配置する

クライアントのWebブラウザと、 Red Hat OpenShift 上の Instana バックエンドの間に、ロードバランサーまたはリバースプロキシが配置されているシナリオを考えてみましょう。 このシナリオでは、 Instana バックエンドは、 Red Hat OpenShift Ingress Controllerを使用してリクエストを処理します。 ロードバランサーまたはリバースプロキシを設定することで、クライアントのIPアドレスを保持し、 x-forwarded-for ヘッダーを追加することができます。 この設定では、 TLS 接続を一旦切断し、ヘッダーを挿入した後、接続を再暗号化します。 再暗号化後、ロードバランサーまたはリバースプロキシは、 Red Hat OpenShift Ingress Controllerを介して、リクエストを Instana ゲートウェイに転送します。

sample-1

この設定では、リクエストに正しいIPアドレスを含むヘッダーが x-forwarded-for すでに追加されているため、ルート passthrough を使用してトラフィックを Instana ゲートウェイに転送することができます。 その結果、Ingressコントローラーはリクエストを復号化する必要がありません。

構成例:クライアントのブラウザと Instana のバックエンドの間にロードバランサーやリバースプロキシが存在しない場合

クライアントのブラウザと Red Hat OpenShift 上の Instana バックエンドの間にロードバランサーやリバースプロキシが存在しない場合、 Red Hat OpenShift Ingress Controller が NAT を実行する唯一のコンポーネントとなります。 このシナリオでは、 ルート reencrypt、リクエストが Instana ゲートウェイに到達する前に、その x-forwarded-for ヘッダーを追加することができます。 デフォルトでは、 Red Hat OpenShift のIngressコントローラーは、ヘッダーが存在しない場合は x-forwarded-for それを追加し、存在する場合はヘッダーにクライアントのIPアドレスを追加します。

sample-2