Kubernetesの統合：v3での変更点

概要

バージョン3以降のNew RelicのKubernetesソリューションは、よりモジュール化された構成を目指した新しいアーキテクチャを採用しており、ソリューションの導入方法をより自由に選択できるようになり、より多くの環境に対応できるようになっています。

Kubernetes Integrationバージョン3によって報告されたデータは、バージョン2以降変更されていません。バージョン3では、構成可能性、安定性、ユーザーエクスペリエンスに重点を置いています。

重要

Kubernetes統合バージョン3（ appVersion ）は、 nri-bundleチャートversion 4に含まれています。

アーキテクチャの変更

この新しいバージョンでは、統合の主要コンポーネントであるnewrelic-infrastructure DaemonSetは、 nrk8s-ksm 、 nrk8s-kubelet 、およびnrk8s-controlplaneの3つの異なるコンポーネントに分割され、最初のコンポーネントはデプロイメントで、次の2つはDaemonSetです。。これにより、実行時ではなく、スケジューリングおよび展開時に決定を下すことが容易になります。

さらに、スクレイピングプロセスのライフサイクルも変更しました。これにより、Kubernetes informersのような高レベルのKubernetes APIを活用できるようになりました。Kubernetes informersは、クラスター・オブジェクトのビルトイン・キャッシュと監視を提供します。このため、各コンポーネントには2つのコンテナが用意されています。

インテグレーションのコンテナで、メトリクスの収集を担当します。
New Relic Infrastructure Agent を搭載したコンテナで、メトリクスを New Relic Platform に送信するために使用します。

Kub-State-Metricsコンポーネント

クラスター状態の指標は、Kubernetes組織自体の下にあるOSSプロジェクトkube-state-metricsの上に構築されます。以前は、ソリューションが1つのDaemonSetのみで構成されていたため、メトリックのスクレイピングを担当するポッドを決定するための選択プロセスが行われました。このプロセスは、単に地域性に基づいていました。担当するポッドは、KSMデプロイメントとノードを共有するポッドになります。

KSM出力にはクラスタ全体のデータが含まれているため、この出力を解析するにはかなりの量のリソースが必要になります。これは大規模なクラスター運営者が想定できることですが、この大量のリソースを必要とするのはDaemonSetの任意の1つのインスタンスであるという事実から、クラスター運営者は、実際には1つしか必要としないDaemonSet全体にそのような消費を許可しなければなりません。

KSMスクレイピングのもう一つの問題は、KSMポッドがどのノードに住んでいるのかを把握することでした。これを行うためには、APIサーバーに連絡して、いくつかのラベルでポッドをフィルタリングする必要がありますが、統合が短命であることから、キャッシュとウォッチャーはAPIサーバーによって効果的に使用されていませんでした。このため、大規模なクラスタでは、DaemonSetのすべてのインスタンスが、KSMポッドが隣に住んでいるかどうかを把握しようとして、名前のないポッドリスト要求でコントロールプレーンに殺到するという問題が発生していました。

この問題に対処するため、KSMのスクレイピング方法に2つの大きな変更を加えることにしました。

DaemonSet ポッドから KSM をスクレイピングする責任を、別の単一インスタンスの Deployment に分割しました。
コードをリファクタリングして長時間稼働させることで、キャッシュと監視の仕組みが組み込まれたKubernetesのインフォーマーを活用できるようにしました。

したがって、特定のデプロイメントnrk8s-ksmがKSMの検索とスクレイピングを処理するようになりました。このポッドは長寿命で単一であるため、エンドポイントインフォーマーを使用して、KSMポッドのIPを安全に特定し、スクレイプできます。インフォーマーは、クラスター内のインフォーマーのリストをローカルに自動的にキャッシュし、新しいインフォーマーを監視します。これにより、ポッドがどこにあるかを把握するためのリクエストでAPIサーバーが急増するのを防ぎます。

シャード化されたKSMのセットアップはまだサポートされていませんが、この新しいコードはこの将来の改善を念頭に置いて作られています。

Kubeletコンポーネント

Kubeletは "Kubernetesエージェント "と呼ばれ、すべてのKubernetesノード上で動作するサービスで、コントロールプレーンからの指示に従ってコンテナを作成する役割を担っています。Kubeletはコンテナランタイムと密接に連携しているため、CPU、メモリ、ディスク、ネットワークの使用状況など、我々の統合のためのインフラメトリクスの主な情報源となっています。徹底的にドキュメント化されているわけではありませんが、Kubelet APIはほとんどのKubernetesメトリクスのデファクトスタンダードなソースです。

Kubeletのスクレイピングは、通常、リソースの少ない操作です。これと、可能な限りノード間のトラフィックを最小限に抑えるという意図を踏まえて、 nrk8s-kubeletはDaemonSetとして実行され、各インスタンスは、同じノードで実行されているKubeletからメトリックを収集します。

nrk8s-kubelet hostNetworkを正しく実行する必要がなくなり、代わりにノードIPを使用してKubeletに接続します。このプロセスが失敗した場合、 nrk8s-kubeletはフォールバックしてAPIサーバープロキシを介してノードに到達します。このフォールバックメカニズムは新しいものではありませんが、クラスターが非常に大きい場合は、多くのkubeletをプロキシすると、APIサーバーの負荷が増える可能性があるため、このことを覚えておくことをお勧めします。ログで次のようなメッセージを探すことで、APIサーバーがプロキシとして使用されているかどうかを確認できます。

Trying to connect to kubelet through API proxy

コントロールプレーンコンポーネント

CPコンポーネントを検索して接続できるようにすることは、今回の作業の中でも最も困難な作業の一つでした。その主な理由は、CPコンポーネントの構成方法が多岐にわたっているからである。さらに、異なるCPコンポーネントを直接構成することも可能である。

以下のようなシナリオを想定して、現在のアプローチを構築しました。

CPモニタリングは、KubeadmやMinikubeなどのように、CPが箱から出しても到達可能な環境では、すぐに機能するはずです。
CPを自動検出できない設定の場合。例えば、クラスターの外に住んでいる場合は、ユーザーが自分でエンドポイントを指定する方法を提供する必要があります。
自動検出に失敗してもデプロイメントが失敗することはありませんが、手動で定義されたエンドポイントにヒットしない場合は失敗します。

Kubeadmなどの主要なKubernetesディストリビューションは、ホストのネットワーク名前空間上のローカルホストでのみリッスンするように構成されたCPコンポーネントをデプロイするため、 nrk8s-controlplaneをhostNetwork: trueのDaemonSetとしてデプロイすることを選択しました。

オートディスカバーと静的エンドポイントをサポートするように構成しました。様々なディストリビューションにすぐに対応できるように、設定項目として幅広い既知のデフォルトを提供しています。これをコードではなく設定で行うことで、オートディスカバリーを必要に応じて微調整することができます。

また、セレクターごとに複数のエンドポイントを設定できるようにし、正しいエンドポイントを自動的に検出するプローブ機構を追加しました。これにより、同じセレクターを使って、ポートやプロトコルなど、さまざまな設定を試すことができます。

etcd CPコンポーネントのスクレイピング構成は以下のようになっており、すべてのコンポーネントに同じ構造と機能が適用されています。

config:
  etcd:
    enabled: true
    autodiscover:
      - selector: "tier=control-plane,component=etcd"
        namespace: kube-system
        matchNode: true
        endpoints:
          - url: https://localhost:4001
            insecureSkipVerify: true
            auth:
              type: bearer
          - url: http://localhost:2381
    staticEndpoint:
      url: https://url:port
      insecureSkipVerify: true
      auth: {}

staticEndpointが設定されている場合、コンポーネントはそれをスクレイプしようとします。エンドポイントに到達できない場合、統合は失敗するため、手動エンドポイントが構成されているときにサイレントエラーは発生しません。

staticEndpointが設定されていない場合、コンポーネントは自動検出エントリを反復処理して、指定されたnamespaceのselectorに一致する最初のポッドを探し、オプションでDaemonSetの同じノードで実行されます（ matchNodeの場合） trueに設定されます）。ポッドが検出された後、コンポーネントはプローブし、http HEADリクエストを発行し、リストされたエンドポイントを順番に、選択した認証タイプを使用して最初に成功したプローブされたエンドポイントをスクレイプします。

上記では、 etcdコンポーネントの構成の抜粋を示していますが、スクレイピングロジックは他のコンポーネントでも同じです。

コントロールプレーンモニタリングの設定方法の詳細については、コントロールプレーンモニタリングのページをご確認ください。

ヘルムチャート

Helmは、ソリューションをクラスターにデプロイするために提供する主要な手段です。チャートの複雑さも、1つのDaemonSetを管理するだけでよい以前のバージョンから大幅に増加しました。ここで、1つのデプロイメントと2つのDaemonSetを管理する必要があり、それぞれの構成はわずかに異なります。これにより、チャートや生成されたマニフェストの上に手動パッチを適用する必要なしに、ソリューションをニーズに適応させるための柔軟性が高まります。

新しいHelmチャートが公開する新機能の一部をご紹介します。

すべてのポッドのsecurityContextを完全に制御
すべてのポッドのポッドlabelsおよびannotationsのフルコントロール
追加の環境変数、 volumes 、およびを追加する機能 volumeMounts
どのエンドポイントに到達するか、オートディスカバリーの動作、スクレイピングの間隔など、統合の設定を完全にコントロールすることが可能
Helmのイディオムやスタンダードとの連携強化

チャートのREADME.mdで切り替えることができるすべてのスイッチの詳細を確認できます。

マイグレーションガイド

以前のバージョンからの移行をできるだけ簡単にするために、古いnewrelic-infrastructureチャートで指定可能だったオプションのほとんどを、新しいものに変換する互換性レイヤーを開発しました。この互換性レイヤーは一時的なもので、将来的には削除される予定ですので、このガイドをよく読んで、人の目を気にしながら設定を移行することをお勧めします。

KSMの構成

ヒント

KSMのモニタリングは、ほとんどの構成ですぐに機能するので、ほとんどのユーザーはこの設定を変更する必要はありません。

disableKubeStateMetrics ksm.enabledに置き換えられました。デフォルトは同じです（KSMスクレイピングが有効）。
kubeStateMetricsScheme、 kubeStateMetricsPort 、 kubeStateMetricsUrl 、 kubeStateMetricsPodLabel 、およびkubeStateMetricsNamespaceは、より包括的で柔軟なksm.configに置き換えられました。

ksm.configオブジェクトの構造は次のとおりです。

ksm:
  config:
   # When autodiscovering KSM, force the following scheme. By default, `http` is used.
   scheme: "http"
   # Label selector to find kube-state-metrics endpoints. Defaults to `app.kubernetes.io/name=kube-state-metrics`.
   selector: "app.kubernetes.io/name=kube-state-metrics"
   # Restrict KSM discovery to this particular namespace. Defaults to all namespaces.
   namespace: ""
   # When autodiscovering, only consider endpoints that use this port. By default, all ports from the discovered `endpoint` are probed.
   #port: 8080
   # Override autodiscovery mechanism completely and specify the KSM url directly instead
   #staticUrl: "http://test.io:8080/metrics"

コントロールプレーンの構成

コントロールプレーンの設定が大幅に変更されました。これまでコントロールプレーン監視を有効にしていた方は、 Configure control plane monitoring の専用ページをご覧になることをお勧めします。

以下のオプションは、上記のリンク先のセクションで説明されている、より包括的な設定に置き換えられています。

apiServerSecurePort
etcdTlsSecretName
etcdTlsSecretNamespace
controllerManagerEndpointUrl、 etcdEndpointUrl 、 apiServerEndpointUrl 、および schedulerEndpointUrl

エージェントの構成

以前にconfigで指定されていたエージェント構成ファイルがcommon.agentConfigに移動されました。ファイルの形式は変更されていません。構成可能なオプションの全範囲は、ここにあります。

次のエージェントオプションは、以前はvalues.ymlファイルのルートで「エイリアス化」されていたため、使用できなくなりました。

logFile common.agentConfig.log_fileに置き換えられました。
eventQueueDepth common.agentConfig.event_queue_depthに置き換えられました。
customAttributes フォーマットがyamlオブジェクトに変更されました。以前の形式である、手動でjsonでエンコードされた文字列（例： {"team": "devops"} ）は廃止されました。
以前は、 customAttributesにはデフォルトのclusterNameエントリがあり、削除すると望ましくない結果が生じる可能性がありました。これはもはや当てはまりません。ユーザーはcustomAttributes全体を安全にオーバーライドできるようになりました。
discoveryCacheTTL キャッシュが組み込まれているkubernetesインフォーマーを使用して検出が実行されるようになったため、は完全に削除されました。

インテグレーションの設定

統合は、以前は配列形式を使用してintegrations_configで構成されていました。

integrations_config:
  - name: nri-redis.yaml
    data:
      discovery:  # ...
      integrations:  # ...

仕組みは変わりませんが、より使いやすいようにフォーマットを変更しました。

integrations:
  nri-redis-sampleapp:
    discovery:  # ...
    integrations:  # ...

さらに、検出コマンドでは--port }フラグと--tlsフラグが必須になりました。以前は、次のように機能していました。

integrations:
  nri-redis-sampleapp:
    discovery:
      command:
        exec: /var/db/newrelic-infra/nri-discovery-kubernetes

v3以降では、 --portと--tlsを指定する必要があります。

integrations:
  nri-redis-sampleapp:
    discovery:
      command:
        exec: /var/db/newrelic-infra/nri-discovery-kubernetes --tls --port 10250

v2以前では、 nrk8s-kubeletコンポーネント（または同等のもの）がhostNetwork: trueで実行されていたため、この変更が必要です。したがって、 nri-discovery-kubernetesはlocalhostとプレーンhttpを使用してkubeletに接続できます。セキュリティ上の理由から、これはもはや当てはまらないため、今後は両方のフラグを指定する必要があります。

Kubernetesにおけるオンホスト統合の設定方法の詳細については、 Monitor services in Kubernetes ページをご確認ください。

その他のチャート値

統合設定とは関係ありませんが、ヘルムチャートの以下の雑多なオプションも変更されています。

runAsUser securityContextに置き換えられました。これは、ポッドに直接テンプレート化され、より構成可能です。
resources 現在、3つの異なるワークロードを展開しているため、削除されました。それぞれのリソースは、以下で個別に構成できます。
ksm.resources
kubelet.resources
controlPlane.resources
同様に、 tolerationsは3つに分割され、前の1つは無効になります。
ksm.tolerations
kubelet.tolerations
controlPlane.tolerations

3つすべてのデフォルトで、 NoScheduleおよび NoExecute

image そして、そのすべてのサブキーは、現在デプロイされている3つのイメージのそれぞれについて個別のセクションに置き換えられています。
images.forwarder.* インフラストラクチャエージェントフォワーダを設定します。
images.agent.* インフラストラクチャエージェントとオンホストの統合をバンドルするイメージを構成します。
images.integration.* k8sデータのスクレイピングを担当するイメージを構成します。

v2からのアップグレード

Kubernetes統合バージョン2（ nriバンドルチャートバージョン3.xに含まれています）からアップグレードするには、目的のライセンスキーと設定でvalues-newrelic.yamlファイルを作成することを強くお勧めします。以前にCLIからチャートを直接インストールしたことがある場合、たとえば次のようなコマンドを使用します。

bash

$helm install newrelic/nri-bundle \
>--set global.licenseKey=<New Relic License key> \
>--set global.cluster=<Cluster name> \
>--set infrastructure.enabled=true \
>--set prometheus.enabled=true \
>--set webhook.enabled=true \
>--set ksm.enabled=true \
>--set kubeEvents.enabled=true \
>--set logging.enabled=true

提供された--set引数を取得して、次のようにyamlファイルに入れることができます。

# values-newrelic.yaml
global:
  licenseKey: <New Relic License key>
  cluster: <Cluster name>
infrastructure:
  enabled: true
prometheus:
  enabled: true
webhook:
  enabled: true
ksm:
  enabled: true
kubeEvents:
  enabled: true
logging:
  enabled: true

このようにして、上記ののセクションに従って変更したその他の設定を適応させた後、、以下のコマンドを実行することでアップグレードできます。