一元化されたLogstashサーバー

10.0.2604.2 年6月のリリース以降、 UtilityServiceGroup 内にあるサービスのすべてのLogstashサーバーは、単一のデプロイメントに統合されます。

以前は、各パイプラインを個別のデプロイメントとして作成・管理することができました。 現在、特定のサービスに関連するすべてのパイプラインは、1台の中央集約型Logstashサーバー内で実行されるため、デプロイが簡素化されています。

このアーキテクチャの改善により、管理が簡素化され、リソースのオーバーヘッドが削減され、Logstashの運用におけるスケーラビリティが向上します。

以下の例は、 UtilityServiceGroup 内の検索サービスのLogstashサーバーが、 v1beta1 および v1 でどのように設定されているかを示しています。

以前の設定 - v1beta1

以前のバージョンでは、各Logstashパイプラインは個別のサーバーデプロイメントとして設定されていました。

searchService
 logstashServers:
  - active: true
    groupName: logstash-supply
    names:
      - logstash-supply
  - active: true
    groupName: logstash-demand
    names:
      - logstash-demand
  - active: true
    groupName: logstash-reservation
    names:
      - logstash-reservation
  - active: true
    groupName: logstash-inventorytag
    names:
      - logstash-inventorytag

新しい構成 - v1

集中型のアプローチでは、すべてのパイプラインが単一のLogstashサーバーのデプロイメントに統合されます。

searchService
 logstashServers:
  - active: true
    groupName: logstash
    names:
      - logstash-supply
      - logstash-demand
      - logstash-reservation
      - logstash-inventorytag

詳細については、 「カスタムリソース定義のバージョン管理」 を参照してください。

プロパティの統合動作

複数の独立したLogstashサーバー構成から単一の統合されたデプロイメントへ移行する際は、以下のシナリオにおいてプロパティがどのように扱われるかを理解しておく必要があります。

シナリオ:リソース、アノテーション、ラベル、HPA設定などが異なる複数のLogstashサーバーがある場合、統合プロセスでは、リストの先頭にあるLogstashサーバーのプロパティが引き継がれます。

例:

移行前 - v1beta1

logstashServers:
  - active: true
    affinityAndTolerations: <affinity_tolerations>
    horizontalPodAutoscaler: ApiSuppliesHPA
    logLevel: INFO
    pod:
      podAnnotations:
        lssupplyannkey1: lssupplyannvalue
      podLabels:
        logsupplylabkey1: logsupplylabvalue
    property:
      envVars: nn
      jvmArgs: mm
    resources:
      limits:
        cpu: '1'
        memory: 1536Mi
      requests:
        cpu: 250m
        memory: 512Mi
    names:
      - logstash-supply
  - active: true
    names:
      - logstash-demand
  - active: true
    affinityAndTolerations: different-setting
    horizontalPodAutoscaler: ApiReservationHPA
    logLevel: DEBUG
    pod:
      podAnnotations:
        lsreservannkey1: lsreservannvalue
      podLabels:
        logreservlabkey1: logreservlabvalue
    property:
      envVars: nnn
      jvmArgs: mmm
    resources:
      limits:
        cpu: '2'
        memory: 2048Mi
      requests:
        cpu: 500m
        memory: 1024Mi
    names:
      - logstash-reservation
  - active: true
    names:
      - logstash-inventorytag

移行後 - v1

logstashServers:
  - active: true
    groupName: logstash
    affinityAndTolerations: <affinity_tolerations>  # From first server
    horizontalPodAutoscaler: ApiSuppliesHPA  # From first server
    logLevel: INFO  # From first server
    pod:
      podAnnotations:
        lssupplyannkey1: lssupplyannvalue  # From first server
      podLabels:
        logsupplylabkey1: logsupplylabvalue  # From first server
    property:
      envVars: nn  # From first server
      jvmArgs: mm  # From first server
    resources:
      limits:
        cpu: '1'  # From first server
        memory: 1536Mi  # From first server
      requests:
        cpu: 250m  # From first server
        memory: 512Mi  # From first server
    names:
      - logstash-supply
      - logstash-demand
      - logstash-reservation
      - logstash-inventorytag

重要な考慮事項

  • それ以降のサーバーのプロパティは破棄されます。2台目、3台目、または4台目のLogstashサーバーで定義された固有の設定は、統合されたデプロイメントには引き継がれません。 必要に応じて、他のサーバーから必要な設定を手動で最初のサーバーの設定に統合してください。
  • 統一された動作:統合後、「supply」、「demand」、「reservation」、「inventorytag」などのすべてのLogstashパイプラインは、同じリソース制限、スケーリングポリシー、および実行時設定を共有するようになります。 これらはすべて、現在1つのデプロイメントにまとめられているためです。
  • これまで、異なるLogstashパイプラインごとにリソース要件や設定が異なっていた場合は、統合された設定がすべてのパイプラインに適しているかどうかを評価してください。 統合されたワークロードに対応するために、リソース制限やHPAの設定を調整する必要がある場合があります。
ヒント: これまで、異なるLogstashパイプラインごとにリソース要件や設定が異なっていた場合は、統合された設定がすべてのパイプラインに適しているかどうかを確認してください。 統合されたワークロードに対応するために、リソース制限やHPAの設定を調整する必要がある場合があります。