ロードバランサーと 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>
次に、以下のコードのように、CoreSpecでドメインを設定する。 CoreSpecの詳細については、コアの作成を参照してください。
spec:
agentAcceptorConfig:
host: ingress.<base_domain>
port: 443
baseDomain: <base_domain>
Instana Kubernetes のバックエンド
Instana Enterprise Operator に LoadBalancer サービスの作成を代行させたい場合は、 「 LoadBalancer サービスの自動作成」 を参照してください。
Kubernetes 上の Instana バックエンド用にロードバランサーを設定するには、次のように「タイプ LoadBalancer 」が「Services」のオブジェクトを使用します:
アクセプター
次のような
service.yamlYAML ファイルを作成します。ファイル
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: serviceAmazon 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: serviceGoogle 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 アドレスに置き換えます。
ファイル
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: serviceAmazon 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について、ポート設定ブロックを追加する必要があります。次のコマンドを実行して、 YAML ファイルを適用します:
kubectl apply -f service.yaml -n <CORE_NAMESPACE>< CORE_NAMESPACE> を Core オブジェクトの名前空間に置き換えます。
Red Hat OpenShift 上の Instana バックエンドにおけるエンドポイントの設定
Red Hat OpenShift では、エンドポイントを公開するために、Routes LoadBalancer-type Services を定義するか、または作成することができます。
ルート型サービスを使用して、アクセプタとエンドポイントを公開します:
oc create route passthrough acceptor --hostname=<acceptor_subdomain> --service=acceptor --port=8443 -n instana-coreOpenTelemetry のアクセプタとエンドポイントを、ルート型サービスとして公開します:
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ルート型サービスを使用してゲートウェイのエンドポイントを公開します:
oc create route passthrough base-domain --hostname=<base_domain> --service=gateway --port=https -n instana-coreoc create route passthrough <unitName>-<tenantName>-ui --hostname=<unitName>-<tenantName>.<base_domain> --service=gateway --port=https -n instana-core(オプション) 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にアクセスするために使用されます。
以下のコードに示されている CoreSpecs 内のドメインを設定し、適用してください。 CoreSpecの詳細については、コアの作成を参照してください。
spec: agentAcceptorConfig: host: ingress.<base_domain> port: 443 baseDomain: <base_domain>インストールが完了したら、 LoadBalancer またはIngressサービスのパブリックIPを取得してください。
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 ゲートウェイに転送します。
この設定では、リクエストに正しい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アドレスを追加します。