検索

28.5. Network Observability Operator の設定

download PDF

Flow Collector API リソースを更新して、Network Observability Operator とそのマネージドコンポーネントを設定できます。Flow Collector は、インストール中に明示的に作成されます。このリソースはクラスター全体で動作するため、単一の FlowCollector のみが許可され、cluster という名前を付ける必要があります。

28.5.1. FlowCollector リソースを表示する

OpenShift Container Platform Web コンソールで YAML を直接表示および編集できます。

手順

  1. Web コンソールで、Operators Installed Operators に移動します。
  2. NetObserv OperatorProvided APIs 見出しの下で、Flow Collector を選択します。
  3. cluster を選択し、YAML タブを選択します。そこで、FlowCollector リソースを変更して Network Observability Operator を設定できます。

以下の例は、OpenShift Container Platform Network Observability Operator のサンプル FlowCollector リソースを示しています。

FlowCollector リソースのサンプル

apiVersion: flows.netobserv.io/v1beta1
kind: FlowCollector
metadata:
  name: cluster
spec:
  namespace: netobserv
  deploymentModel: DIRECT
  agent:
    type: EBPF                                1
    ebpf:
      sampling: 50                            2
      logLevel: info
      privileged: false
      resources:
        requests:
          memory: 50Mi
          cpu: 100m
        limits:
          memory: 800Mi
  processor:
    logLevel: info
    resources:
      requests:
        memory: 100Mi
        cpu: 100m
      limits:
        memory: 800Mi
    conversationEndTimeout: 10s
    logTypes: FLOWS                            3
    conversationHeartbeatInterval: 30s
  loki:                                       4
    url: 'https://loki-gateway-http.netobserv.svc:8080/api/logs/v1/network'
    statusUrl: 'https://loki-query-frontend-http.netobserv.svc:3100/'
    authToken: FORWARD
    tls:
      enable: true
      caCert:
        type: configmap
        name: loki-gateway-ca-bundle
        certFile: service-ca.crt
  consolePlugin:
    register: true
    logLevel: info
    portNaming:
      enable: true
      portNames:
        "3100": loki
    quickFilters:                             5
    - name: Applications
      filter:
        src_namespace!: 'openshift-,netobserv'
        dst_namespace!: 'openshift-,netobserv'
      default: true
    - name: Infrastructure
      filter:
        src_namespace: 'openshift-,netobserv'
        dst_namespace: 'openshift-,netobserv'
    - name: Pods network
      filter:
        src_kind: 'Pod'
        dst_kind: 'Pod'
      default: true
    - name: Services network
      filter:
        dst_kind: 'Service'

1
エージェント仕様 spec.agent.typeEBPF でなければなりません。eBPF は、OpenShift Container Platform でサポートされる唯一のオプションです。
2
サンプリング仕様 spec.agent.ebpf.sampling を設定して、リソースを管理できます。サンプリング値が低いと、大量の計算、メモリー、およびストレージリソースが消費される可能性があります。これは、サンプリング比の値を指定することで軽減できます。値 100 は、100 ごとに 1 つのフローがサンプリングされることを意味します。0 または 1 の値は、すべてのフローがキャプチャーされることを意味します。値が低いほど、返されるフローが増加し、派生メトリクスの精度が向上します。デフォルトでは、eBPF サンプリングは値 50 に設定されているため、50 ごとに 1 つのフローがサンプリングされます。より多くのサンプルフローは、より多くのストレージが必要になることにも注意してください。デフォルト値から始めて経験的に調整し、クラスターが管理できる設定を決定することを推奨します。
3
オプションの仕様 spec.processor.logTypesspec.processor.conversationHeartbeatInterval、および spec.processor.conversationEndTimeout を設定して、会話追跡を有効にすることができます。有効にすると、Web コンソールで会話イベントをクエリーできるようになります。spec.processor.logTypes の値は次のとおりです: FLOWS CONVERSATIONSENDED_CONVERSATIONS、または ALL。ストレージ要件は ALL で最も高く、ENDED_CONVERSATIONS で最も低くなります。
4
Loki 仕様である spec.loki は、Loki クライアントを指定します。デフォルト値は、Loki Operator のインストールセクションに記載されている Loki インストールパスと一致します。Loki の別のインストール方法を使用した場合は、インストールに適切なクライアント情報を指定します。
5
spec.quickFilters 仕様は、Web コンソールに表示されるフィルターを定義します。Application フィルターキー、src_namespace および dst_namespace は否定 (!) されているため、Application フィルターは、openshift- または netobserv namespace から発信されて いない、または宛先がないすべてのトラフィックを表示します。詳細は、以下のクイックフィルターの設定を参照してください。

関連情報

会話追跡の詳細は、Working with conversations を参照してください。

28.5.2. Kafka を使用した Flow Collector リソースの設定

Kafka を使用するように FlowCollector リソースを設定できます。Kafka インスタンスを実行する必要があり、そのインスタンスで OpenShift Container Platform Network Observability 専用の Kafka トピックを作成する必要があります。詳細は、AMQ Streams を使用する Kafka など、Kafka ドキュメントを参照してください。

以下の例は、OpenShift Container Platform Network Observability Operator の FlowCollector リソースを変更して Kafka を使用する方法を示しています。

FlowCollector リソースの Kafka 設定のサンプル

  deploymentModel: KAFKA                                    1
  kafka:
    address: "kafka-cluster-kafka-bootstrap.netobserv"      2
    topic: network-flows                                    3
    tls:
      enable: false                                         4

1
Kafka デプロイメントモデルを有効にするには、spec.deploymentModelDIRECT ではなく KAFKA に設定します。
2
spec.kafka.address は、Kafka ブートストラップサーバーのアドレスを参照します。ポート 9093 で TLS を使用するため、kafka-cluster-kafka-bootstrap.netobserv:9093 など、必要に応じてポートを指定できます。
3
spec.kafka.topic は、Kafka で作成されたトピックの名前と一致する必要があります。
4
spec.kafka.tls を使用して、Kafka との間のすべての通信を TLS または mTLS で暗号化できます。有効にした場合、Kafka CA 証明書は、flowlogs-pipeline プロセッサーコンポーネントがデプロイされている namespace (デフォルト: netobserv) と eBPF エージェントがデプロイされている namespace (デフォルト: netobserv-privileged) の両方で ConfigMap または Secret として使用できる必要があります。spec.kafka.tls.caCert で参照する必要があります。mTLS を使用する場合、クライアントシークレットはこれらの namespace でも利用でき (たとえば、AMQ Streams User Operator を使用して生成できます)、spec.kafka.tls.userCert で参照される必要があります。

28.5.3. 強化されたネットワークフローデータをエクスポートする

オプションでネットワークフローを Kafka に送信して、Splunk、Elasticsearch、Fluentd などの Kafka 入力をサポートするプロセッサーまたはストレージでネットワークフローを利用できるようにすることができます。

前提条件

  • インストールされた Kafka

手順

  1. Web コンソールで、Operators Installed Operators に移動します。
  2. NetObserv OperatorProvided APIs 見出しの下で、Flow Collector を選択します。
  3. cluster を選択し、YAML タブを選択します。
  4. FlowCollector を編集して、spec.exporters を次のように設定します。

    apiVersion: flows.netobserv.io/v1alpha1
    kind: FlowCollector
    metadata:
      name: cluster
    spec:
      exporters:
      - type: KAFKA
          kafka:
            address: "kafka-cluster-kafka-bootstrap.netobserv"
            topic: netobserv-flows-export   1
            tls:
              enable: false                 2
    1
    Network Observability Operator は、すべてのフローを設定された Kafka トピックにエクスポートします。
    2
    Kafka との間のすべての通信を SSL/TLS または mTLS で暗号化できます。有効にした場合、Kafka CA 証明書は、flowlogs-pipeline プロセッサーコンポーネントがデプロイされている namespace (デフォルト: netobserv) で、ConfigMap または Secret として使用できる必要があります。これは spec.exporters.tls.caCert で参照する必要があります。mTLS を使用する場合、クライアントシークレットはこれらの namespace でも利用可能であり (たとえば、AMQ Streams ユーザーオペレーターを使用して生成できます)、spec.exporters.tls.userCert で参照される必要があります。
  5. 設定後、ネットワークフローデータを JSON 形式で利用可能な出力に送信できます。詳細は、ネットワークフロー形式のリファレンス を参照してください。

関連情報

フロー形式の指定の詳細は、ネットワークフロー形式リファレンス を参照してください。

28.5.4. Flow Collector リソースの更新

OpenShift Container Platform Web コンソールで YAML を編集する代わりに、flowcollector カスタムリソース (CR) にパッチを適用することで、eBPF サンプリングなどの仕様を設定できます。

手順

  1. 次のコマンドを実行して、flowcollector CR にパッチを適用し、spec.agent.ebpf.sampling 値を更新します。

    $ oc patch flowcollector cluster --type=json -p "[{"op": "replace", "path": "/spec/agent/ebpf/sampling", "value": <new value>}] -n netobserv"

28.5.5. クイックフィルターの設定

FlowCollector リソースでフィルターを変更できます。値を二重引用符で囲むと、完全一致が可能になります。それ以外の場合、テキスト値には部分一致が使用されます。キーの最後にあるバング (!) 文字は、否定を意味します。YAML の変更に関する詳細なコンテキストは、サンプルの FlowCollector リソースを参照してください。

注記

フィルターマッチングタイプ "all of" または "any of" は、ユーザーがクエリーオプションから変更できる UI 設定です。これは、このリソース設定の一部ではありません。

使用可能なすべてのフィルターキーのリストを次に示します。

表28.2 フィルターキー
Universal*ソース送信先説明

namespace

src_namespace

dst_namespace

特定の namespace に関連するトラフィックをフィルタリングします。

name

src_name

dst_name

特定の Pod、サービス、またはノード (ホストネットワークトラフィックの場合) など、特定のリーフリソース名に関連するトラフィックをフィルター処理します。

kind

src_kind

dst_kind

特定のリソースの種類に関連するトラフィックをフィルタリングします。リソースの種類には、リーフリソース (Pod、Service、または Node)、または所有者リソース (Deployment および StatefulSet) が含まれます。

owner_name

src_owner_name

dst_owner_name

特定のリソース所有者に関連するトラフィックをフィルタリングします。つまり、ワークロードまたは Pod のセットです。たとえば、Deployment 名、StatefulSet 名などです。

resource

src_resource

dst_resource

一意に識別する正規名で示される特定のリソースに関連するトラフィックをフィルタリングします。正規の表記法は、namespace の種類の場合は kind.namespace.name、ノードの場合は node.name です。たとえば、Deployment.my-namespace.my-web-server です。

address

src_address

dst_address

IP アドレスに関連するトラフィックをフィルタリングします。IPv4 と IPv6 がサポートされています。CIDR 範囲もサポートされています。

mac

src_mac

dst_mac

MAC アドレスに関連するトラフィックをフィルタリングします。

port

src_port

dst_port

特定のポートに関連するトラフィックをフィルタリングします。

host_address

src_host_address

dst_host_address

Pod が実行しているホスト IP アドレスに関連するトラフィックをフィルタリングします。

protocol

該当なし

該当なし

TCP や UDP などのプロトコルに関連するトラフィックをフィルタリングします。

  • ソースまたは宛先のいずれかのユニバーサルキーフィルター。たとえば、フィルタリング name: 'my-pod' は、使用される一致タイプ (Match all または Match any) に関係なく、my-pod からのすべてのトラフィックと my-pod へのすべてのトラフィックを意味します。

28.5.6. リソース管理およびパフォーマンスに関する考慮事項

ネットワーク監視に必要なリソースの量は、クラスターのサイズと、クラスターが可観測データを取り込んで保存するための要件によって異なります。リソースを管理し、クラスターのパフォーマンス基準を設定するには、次の設定を設定することを検討してください。これらの設定を設定すると、最適なセットアップと可観測性のニーズを満たす可能性があります。

次の設定は、最初からリソースとパフォーマンスを管理するのに役立ちます。

eBPF サンプリング
サンプリング仕様 spec.agent.ebpf.sampling を設定して、リソースを管理できます。サンプリング値が低いと、大量の計算、メモリー、およびストレージリソースが消費される可能性があります。これは、サンプリング比の値を指定することで軽減できます。値 100 は、100 ごとに 1 つのフローがサンプリングされることを意味します。0 または 1 の値は、すべてのフローがキャプチャーされることを意味します。値が小さいほど、返されるフローが増加し、派生メトリクスの精度が向上します。デフォルトでは、eBPF サンプリングは値 50 に設定されているため、50 ごとに 1 つのフローがサンプリングされます。より多くのサンプルフローは、より多くのストレージが必要になることにも注意してください。クラスターがどの設定を管理できるかを判断するには、デフォルト値から始めて実験的に調整することを検討してください。
インターフェイスの制限または除外
spec.agent.ebpf.interfaces および spec.agent.ebpf.excludeInterfaces の値を設定して、観測されるトラフィック全体を削減します。デフォルトでは、エージェントは、excludeInterfaces および lo (ローカルインターフェイス) にリストされているインターフェイスを除く、システム内のすべてのインターフェイスを取得します。インターフェイス名は、使用される Container Network Interface (CNI) によって異なる場合があることに注意してください。

Network Observability をしばらく実行した後、次の設定を使用してパフォーマンスを微調整できます。

リソース要件および制限
spec.agent.ebpf.resources および spec.processor.resources 仕様を使用して、リソース要件と制限をクラスターで予想される負荷とメモリー使用量に適応させます。多くの中規模のクラスターには、デフォルトの制限の 800MB で十分な場合があります。
キャッシュの最大フロータイムアウト
eBPF エージェントの spec.agent.ebpf.cacheMaxFlows および spec.agent.ebpf.cacheActiveTimeout 仕様を使用して、エージェントによってフローが報告される頻度を制御します。値が大きいほど、エージェントで生成されるトラフィックが少なくなり、これは CPU 負荷の低下と相関します。ただし、値を大きくするとメモリー消費量がわずかに増加し、フロー収集でより多くの遅延が発生する可能性があります。

28.5.6.1. リソースの留意事項

次の表は、特定のワークロードサイズのクラスターのリソースに関する考慮事項の例を示しています。

重要

表に概要を示した例は、特定のワークロードに合わせて調整されたシナリオを示しています。各例は、ワークロードのニーズに合わせて調整を行うためのベースラインとしてのみ考慮してください。

表28.3 リソースの推奨事項
 極小規模 (10 ノード)小規模 (25 ノード)中規模 (65 ノード) [2]大規模 (120 ノード) [2]

ワーカーノードの vCPU とメモリー

4 vCPU| 16GiB mem [1]

16 vCPU| 64GiB mem [1]

16 vCPU| 64GiB mem [1]

16 vCPU| 64GiB Mem [1]

LokiStack サイズ

1x.extra-small

1x.small

1x.small

1x.medium

ネットワーク可観測性コントローラーのメモリー制限

400Mi (デフォルト)

400Mi (デフォルト)

400Mi (デフォルト)

800 Mi

eBPF サンプリングレート

50 (デフォルト)

50 (デフォルト)

50 (デフォルト)

50 (デフォルト)

eBPF メモリー制限

800Mi (デフォルト)

800Mi (デフォルト)

2000Mi

800Mi (デフォルト)

FLP メモリー制限

800Mi (デフォルト)

800Mi (デフォルト)

800Mi (デフォルト)

800Mi (デフォルト)

FLP Kafka パーティション

該当なし

48

48

48

Kafka コンシューマーレプリカ

該当なし

24

24

24

Kafka ブローカー

該当なし

3 (デフォルト)

3 (デフォルト)

3 (デフォルト)

  1. AWS M6i インスタンスでテスト済み。
  2. このワーカーとそのコントローラーに加えて、3 つのインフラノード (サイズ M6i.12xlarge) と 1 つのワークロードノード (サイズ M6i.8xlarge) がテストされました。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.