• ログイン無料アカウント

本書は、お客様のご参考のために原文の英語版を機械翻訳したものです。

英語版と齟齬がある場合、英語版の定めが優先するものとします。より詳しい情報については、本リンクをご参照ください。

問題を作成する

コントロールプレーンモニタリングの設定

New Relic は、Kubernetes 統合のために コントロールプレーン をサポートしており、クラスタのコントロールプレーンコンポーネントからメトリクスを監視・収集することができます。これらのデータは、New Relic で、 クエリやチャートの作成に使用することができます

ヒント

このページでは、特に指定のない限り、 Kubernetes integration v3 を参照しています。v2のコントロールプレーン監視の設定方法の詳細は、以下の特定のセクションに記載されています。

機能

以下のコントロールプレーンコンポーネントから、 メトリクス を監視・収集しています。

  • etcd: リーダー情報、常駐メモリサイズ、OSスレッド数、コンセンサスプロポーザルデータ、など。サポートされているメトリクスの一覧については、 etcd data を参照してください。
  • APIサーバーapiserverリクエストの割合、HTTPメソッドとレスポンスコードによるapiserverリクエストの内訳など。サポートされている指標の完全なリストについては、 APIサーバーデータをご覧ください。
  • スケジューラ: 要求されたCPU/メモリ対ノードで利用可能なCPU/メモリ、汚染に対する耐性、任意のセットのアフィニティまたはアンチアフィニティなど。サポートされているメトリクスの完全なリストについては、 Scheduler data を参照してください。
  • コントローラーマネージャー :常駐メモリサイズ、作成されたOSスレッド数、現在存在するゴルーチンなど。サポートされるメトリクスの完全なリストについては、 Controller Manager data を参照してください。

互換性と要件

  • コントロールプレーンモニタリングのサポートは、マネージドクラスターに限定されています。これは、ほとんどのクラウド・プロバイダーがコントロール・プレーンのコンポーネントのメトリクス・エンドポイントを公開していないため、New Relic がアクセスできないためです。
  • 非特権モード でソリューションを展開する場合、コントロールプレーンのセットアップには 追加の手順が必要となり、 いくつかの注意点が適用されます。
  • OpenShift 4.xでは、コントロールプレーンコンポーネントのメトリックエンドポイントがデフォルトとは異なるものを使用しています。

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

Kubernetesコントロールプレーンを監視するタスクは、デフォルトでDaemonSetとしてデプロイされるnrk8s-controlplaneコンポーネントの責任です。このコンポーネントは、 node-role.kubernetes.io/control-planenode-role.kubernetes.io/masterなどのマスターノードを識別するために一般的に使用されるラベルを含むnodeSelectorTermsのデフォルトリストを使用して、マスターノードに自動的にデプロイされます。とにかく、このセレクターはvalues.ymlファイルで公開されているため、他の環境に合わせて再構成できます。

これらのセレクターに一致するノードがないクラスターでは、ポッドがスケジュールされないため、リソースを浪費することはなく、ヘルムチャートでcontrolPlane.enabledfalseに設定することでコントロールプレーンの監視を完全に無効にすることと機能的に同等です。

コントロールプレーンの各コンポーネントには専用のセクションが設けられており、個別に対応することができます。

  • そのコンポーネントのモニタリングを有効または無効にする
  • そのコンポーネントを発見するための特定のセレクタと名前空間を定義します。
  • そのコンポーネントのメトリクスを取得するために使用されるエンドポイントとパスの定義
  • そのコンポーネントのメトリクスを取得するために使用する必要のある認証メカニズムの定義
  • オートディスカバリーを完全にスキップするエンドポイントを手動で指定します。

オートディスカバリーとデフォルト設定

デフォルトでは、 Helm Chartは、 Kubeadmminikubeなど、クラスター内でコントロールプレーンを実行するオンプレミスディストリビューションの一部のコントロールプレーンコンポーネントに対して、すぐに使用できる構成を提供します。

hostNetwork および privileged

v3より前のバージョンでは、統合がprivileged: falseを使用してデプロイされると、コントロールプレーンコンポーネントのhostNetwork設定もfalseに設定されます。

バージョン3以降では、 privilegedフラグはsecurityContextオブジェクトにのみ影響します。つまり、コンテナがホストメトリックにアクセスできるルートとして実行されているかどうかに影響します。ほとんどのディストリビューションでコントロールプレーンのエンドポイントに到達するために必要なhostNetwork: trueを持つコントロールプレーンからメトリックを取得するポッドを除いて、すべての統合コンポーネントはデフォルトでhostNetwork: falseになりました。すべてのコンポーネントのhostNetwork値はvalues.yamlhostNetworkトグルを使用して、個別にまたはグローバルに変更できます。

クラスタまたはその他のポリシーのために、 hostNetworkでポッドを実行することがまったく受け入れられない場合、コントロールプレーンの監視は不可能であり、 controlPlane.enabledfalseに設定して無効にする必要があります。

カスタム自動検出または静的エンドポイントを含む高度な構成がある場合は、 hostNetworkなしでコントロールプレーンを監視するために使用できます。 プロジェクトのREADMEを確認し、 values.yamlcontrolPlane.hostNetworkトゥーグルを探します。

カスタムオートディスカバリー

自動検出に使用されるセレクターは、 values.yamlファイルの構成エントリとして完全に公開されます。つまり、コントロールプレーンがクラスターの一部として実行されるほとんどすべての環境に合わせて、セレクターを微調整または置換できます。

オートディスカバリーのセクションは以下のようになります。

autodiscover:
- selector: "tier=control-plane,component=etcd"
namespace: kube-system
# Set to true to consider only pods sharing the node with the scraper pod.
# This should be set to `true` if Kind is Daemonset, `false` otherwise.
matchNode: true
# Try to reach etcd using the following endpoints.
endpoints:
- url: https://localhost:4001
insecureSkipVerify: true
auth:
type: bearer
- url: http://localhost:2381
- selector: "k8s-app=etcd-manager-main"
namespace: kube-system
matchNode: true
endpoints:
- url: https://localhost:4001
insecureSkipVerify: true
auth:
type: bearer

autodiscoverセクションには、自動検出エントリのリストが含まれています。各エントリには次のものがあります。

  • selector:ポッドを検索するために使用される文字列でエンコードされたラベルセレクター。
  • matchNode:trueに設定すると、検出を実行するDaemonSetの特定のインスタンスと同じノードで実行されているポッドに検出が追加で制限されます。
  • endpoints:指定されたセレクターのポッドが見つかった場合に試行するエンドポイントのリスト。

さらに、各endpointには次のものがあります。

  • url:スキームを含む、ターゲットへのURL。 httpまたはhttpsにすることができます。
  • insecureSkipVerify:trueに設定すると、証明書はhttps URLについてチェックされません。
  • auth.type:リクエストの認証に使用するメカニズム。現在、次のメソッドがサポートされています。
  • なし: authが指定されていない場合、リクエストには認証がまったく含まれません。
  • bearer:KubernetesAPIに対する認証に使用されたものと同じベアラトークンがこのリクエストに送信されます。
  • mtls:mTLSはリクエストの実行に使用されます。
mTLS

mtlsタイプの場合、以下を指定する必要があります。

endpoints:
- url: https://localhost:4001
auth:
type: mtls
mtls:
secretName: secret-name
secretNamespace: secret-namespace

ここで、 secret-nameは、 secret-namespaceに存在するKubernetes TLSシークレットの名前であり、その特定のエンドポイントに接続するために必要な証明書、キー、およびCAが含まれています。

統合では、このシークレットをマウントするのではなく、実行時にフェッチします。つまり、このシークレットへのアクセスを許可するRBACロールが必要です。ヘルムチャートは、レンダリング時にauth.mtlsエントリを自動的に検出し、 rbac.createがfalseに設定されていない限り、これらの特定のシークレットと名前空間のエントリを自動的に作成します。

私たちの統合は、以下のキーを持つ秘密を受け入れます。

  • cert:etcdに提示されるPEMでエンコードされた証明書
  • key:上記の証明書に対応するPEMでエンコードされた秘密鍵

これらの証明書は、etcdが動作に使用しているのと同じCAによって署名されている必要があります。

これらの証明書を生成する方法は、Kubernetesのディストリビューションによって大きく異なるため、このドキュメントの範囲外です。必要なetcdピア証明書を取得する方法については、ディストリビューションのドキュメントを参照してください。たとえば、Kubeadmでは、マスターノードの/etc/kubernetes/pki/etcd/peer.{crt,key}にあります。

etcdのピア証明書を見つけたり生成したりしたら、シークレットに含まれると思われるキーに合わせてファイル名を変更し、クラスタにシークレットを作成します。

bash
$
mv peer.crt cert
$
mv peer.key key
$
mv ca.crt cacert
$
$
kubectl -n newrelic create secret tls newrelic-etcd-tls-secret --cert=./cert --key=./key --certificate-authority=./cacert

最後に、このセクションの冒頭に示されている構成スニペットにシークレット名( newrelic-etcd-tls-secret )と名前空間( newrelic )を入力できます。 Helm Chartはこの構成を自動的に解析し、RBACロールを作成して、 nrk8s-controlplaneコンポーネントのこの特定のシークレットと名前空間へのアクセスを許可するため、その点で手動のアクションは必要ありません。

静的エンドポイント

オートディスカバリーは、コントロールプレーンがKubernetesクラスター内に存在する場合をカバーする必要がありますが、ディストリビューションや洗練されたKubernetes環境の中には、可用性やリソースの分離など様々な理由から、コントロールプレーンを別の場所で実行するものもあります。

このような場合、コントロールプレーンラベルの付いたポッドがノードで見つかったかどうかに関係なく、任意の固定URLをスクレイプするように統合を構成できます。これは、 staticEndpointエントリを指定することによって行われます。たとえば、外部etcdインスタンスの場合は次のようになります。

controlPlane:
etcd:
staticEndpoint:
url: https://url:port
insecureSkipVerify: true
auth: {}

staticEndpointautodiscoverエントリのendpointsと同じタイプのエントリであり、そのフィールドは上記で説明されています。ここでは、認証メカニズムとスキーマがサポートされています。

staticEndpointが設定されている場合、 autodiscoverセクションは完全に無視されることに注意してください。

制限

重要

ノード外(つまりlocalhostではない)エンドポイントを指すstaticEndpointを使用している場合は、 controlPlane.kindDaemonSetからDeploymentに変更する必要があります。

staticEndpointを使用すると、すべてのnrk8s-controlplaneポッドが上記のエンドポイントに到達してスクレイプしようとします。これは、 nrk8s-controlplaneがDaemonSet(デフォルト)の場合、DaemonSetのすべてのインスタンスがこのエンドポイントをスクレイプすることを意味します。 localhostをポイントしている場合はこれで問題ありませんが、エンドポイントがノードに対してローカルでない場合は、メトリックを複製して請求可能な使用量を増やす可能性があります。 staticEndpointを使用していて、それを非ローカルURLにポイントしている場合は、必ずcontrolPlane.kindをDeploymentに変更してください。

上記と同様の理由により、現在のところ、あるコントロールプレーンコンポーネントにオートディスカバリーを使用し、他のコンポーネントにスタティックエンドポイントを使用することはできません。これは既知の制限事項であり、将来のバージョンでの対応を検討しています。

最後に、 staticEndpointではコンポーネントごとに1つのエンドポイントのみを定義できます。これは、異なるホストに複数のコントロールプレーンシャードがある場合、現在、それらを個別にポイントすることはできないことを意味します。これは、将来のバージョンで対処するために取り組んでいる既知の制限でもあります。当面の回避策は、別の場所にあるさまざまなシャードのメトリックを集約し、集約された出力をstaticEndpoint URLにポイントすることです。

マネージド環境やクラウド環境のためのコントロールプレーン監視

EKSやGKEのような一部のクラウド環境では、Kubernetes API Serverからメトリクスを取得することができます。これは静的なエンドポイントとして簡単に設定できます。

controlPlane:
affinity:
nodeAffinity: false # https://github.com/helm/helm/issues/9136
kind: Deployment
config:
etcd:
enabled: false
scheduler:
enabled: false
controllerManager:
enabled: false
apiServer:
staticEndpoint:
url: "https://kubernetes.default:443"
insecureSkipVerify: true
auth:
type: bearer

なお、この機能はAPIサーバーにのみ適用され、クラウド環境ではetcd、スケジューラー、コントローラーマネージャーにはアクセスできませんのでご注意ください。

ランチャーRKE1のコントロールプレーンモニタリング

Rancher Kubernetes Engine(RKE1)を利用してデプロイされたクラスターは、コントロールプレーンコンポーネントを、Kubeletによって管理されるポッドとしてではなくDockerコンテナーとして実行します。そのため、統合ではこれらのコンテナーを自動検出できず、統合構成のstaticEndpointセクションですべてのエンドポイントを手動で指定する必要があります。

統合は、直接接続するか、使用可能な認証方法(サービスアカウントトークン、カスタムmTLS証明書、またはなし)を使用するか、プロキシを介して、さまざまなエンドポイントに到達できる必要があります。

たとえば、スケジューラとコントローラマネージャのメトリックを到達可能にするために、 --authorization-always-allow-pathsフラグを追加して、 /metricsまたは--authentication-kubeconfig--authorization-kubeconfigでトークン認証を有効にする必要がある場合があります。

すべてのコンポーネントが指定されたポートで到達可能であると仮定すると、次の構成はAPIサーバー、スケジューラー、およびコントローラーマネージャーを監視します。

scraper:
enabled: true
kind: DaemonSet
config:
scheduler:
enabled: true
staticEndpoint:
url: https://localhost:10259
insecureSkipVerify: true
auth:
type: bearer
controllerManager:
enabled: true
staticEndpoint:
url: https://localhost:10257
insecureSkipVerify: true
auth:
type: bearer
apiServer:
enabled: true
staticEndpoint:
url: https://localhost:6443
insecureSkipVerify: true
auth:
type: bearer

この例では、統合は各staticEndpointにローカルに接続しているため、 hostNetworkオプションがtrueに設定されている各コントロールプレーンコンポーネントの同じノードで実行する必要があります。したがって、 controlPlane.kindDaemonSetとして保持する必要があります。また、DaemonSetには、監視するすべてのコントロールプレーンノードですべてのインスタンスが実行されるように、アフィニティルール、nodeSelector、および許容値を構成する必要があります。

node-role.kubernetes.io/controlplaneラベルを確認すると、コントロールプレーンノードを認識できます。このラベルは、統合のデフォルトのアフィニティルールによってすでに考慮されています。

統合されたコントロールプレーンの監視 バージョン2

ここでは、バージョン2以前のインテグレーションでコントロールプレーンモニタリングを設定する方法について説明します。

これらのバージョンでは、オートディスカバリーオプションの柔軟性が低く、外部エンドポイントをサポートしていないことにご注意ください。お早めに バージョン3 にアップデートされることを強くお勧めします。 変更点をご覧ください Kubernetesとの統合の。

OpenShiftの設定

Kubernetes Integrationのバージョン3には、OpenShiftクラスタ内のコントロールプレーンコンポーネントを自動検出するデフォルト設定が含まれているため、etdを除くすべてのコンポーネントですぐに動作するはずです。

OpenShift 環境ではメトリクスのエンドポイントが mTLS 認証を必要とするように構成されているため、Etcd はすぐにはサポートされません。当社の統合は、この構成でetcdのメトリクスを取得するためのmTLS認証をサポートしていますが、必要なmTLS証明書を手動で作成する必要があります。これは、ユーザーからの明示的な承認なしに当社の統合に広範な権限を与えることを避けるために必要です。

mTLSシークレットを作成するには、 以下の本セクションの手順に従ってください。 その後、 mtlsセクション で説明されているように、新しく作成されたシークレットを使用するように統合を構成してください。

OpenShift での etcd 用 mTLS の設定

以下の手順で、 OpenShift 4.xでetcdの相互TLS認証を設定してください。

  1. etcdクライアント証明書をクラスターから不透明なシークレットにエクスポートします。デフォルトのマネージドOpenShiftクラスターでは、シークレットの名前はkube-etcd-client-certsで、 openshift-monitoring名前空間に保存されます。

    bash
    $
    kubectl get secret kube-etcd-client-certs -n openshift-monitoring -o yaml > etcd-secret.yaml
  2. オプションで、秘密の名前と名前空間を意味のあるものに変更します。

  3. メタデータ部のこれらの不要なキーを削除します。

    • creationTimestamp
    • resourceVersion
    • selfLink
    • uid
  4. マニフェストを新しい名前と名前空間でインストールします。

    bash
    $
    kubectl apply -n newrelic -f etcd-secret.yaml
  5. mtlsのセクション で説明しているように、新しく作成したシークレットを使用するように統合を構成します。

自分のデータを見る

統合が正しく設定されていれば、 Kubernetes cluster explorer には、以下のように、すべてのコントロールプレーンコンポーネントとそのステータスが専用のセクションに表示されます。

New Relic - Kubernetes Cluster Explorer - Control Plane section

one.newrelic.com > Kubernetes Cluster Explorer: Kubernetesのクラスタエクスプローラを使用して、クラスタのコントロールプレーンコンポーネントからメトリクスを監視・収集します。

また、この NRQL クエリでコントロールプレーンデータを確認することもできます。

SELECT latest(timestamp) FROM K8sApiServerSample, K8sEtcdSample, K8sSchedulerSample, K8sControllerManagerSample FACET entityName where clusterName = '_MY_CLUSTER_NAME_'
Copyright © 2022 New Relic Inc.