 |
This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
1. はじめに
Kubernetes は、かなり長い間、コンテナオーケストレーションに最も広く使用されているツールです。 Checkmk は、Kubernetes 環境の監視をサポートしています。
Checkmk2.1.0 以降、Checkmk を使用して以下の Kubernetes オブジェクトを監視することができます。
クラスタ
ノード
デプロイ
ポッド
デーモンセット
ステートフルセット
永続ボリュームクレーム
クーロンジョブ
Kubernetes の監視に使用できるすべてのチェックプラグインの完全なリストについては、チェックプラグインのカタログをご覧ください。
1.1. サポートされているディストリビューションとバージョン
2.2.0 以降、Checkmk は以下のディストリビューションおよび Kubernetes サービスに対応しています。
Vanilla Kubernetes
Amazon Elastic Kubernetes Service (Amazon EKS)
Azure Kubernetes Service (AKS)
Google Kubernetes Engine (GKE) (オートパイロットモードを含む)
Tanzu Kubernetes
当社の目標は、Kubernetes の最新 5 つのリリース (マイナー) バージョンをすべてサポートすることです。 したがって、(Vanilla) Kubernetes のライフサイクルからすでに外れている Kubernetes バージョンもサポートしています。 何よりも、Kubernetes サービスのサポート期間を長く設定しているクラウドプロバイダとの円滑な連携を確保しています。 Kubernetes の新バージョンがリリースされた直後は、新機能の範囲やタイミングによっては、Checkmk で完全にサポートされるまでにしばらく時間がかかる場合があります。 Checkmk がこの新バージョンでスムーズに動作するようになり次第、Werk (Werk #14584 など) で発表いたします。
1.2. Kubernetes 監視の開始
Kubernetes の新しい監視機能の概要については、2 本のビデオ「Checkmk による Kubernetes 監視」および「Kubernetes クラスタの問題の検出とアラートの設定」をご覧ください。
1.3. 監視環境の構造
Kubernetes クラスタは、個々のコンポーネントの数や配置が急速に変化する場合があるため、Kubernetes 環境の監視用に別のサイトを作成することをお勧めします。 このサイトは、分散監視により、通常どおりセントラルサイトに接続することができます。
1.4. Checkmk での Kubernetes の監視プロセス
Checkmk は、2 つの方法で Kubernetes クラスタを監視します。
Kubernetesスペシャルエージェントは、クラスタの API サーバーを介して基本情報を取得します。 これだけでも、ノードやコンテナの状態を取得することができます。ポッドやデプロイメントのメタデータのほとんども、この方法で取得されます。
しかし、包括的な監視を行うには、この時点ではまだ何かが欠けています。 特定のデプロイが CPU にどれだけの負荷をかけているか、デーモンセットが現在どれだけのメモリを使用しているかなどの質問には、この方法では答えられません。
そこで、Checkmk ノードコレクターと Checkmk クラスターコレクターが登場します。 これらは、Checkmk での Kubernetes 監視に欠かせない要素です。 したがって、この記事の残りの部分では、これらのインストールと設定についても詳しく説明します。 さらに、商業版でKubernetes ダッシュボードを使用するには、ノードコレクターとクラスターコレクターが負荷に関するデータを提供できる必要があります。
1.5. Checkmk の他の監視機能との違い
Kubernetes クラスタ内のポッドおよびレプリカを監視する場合、ステータスの変化や遅延が頻繁に発生することがあります。 このことを考慮して、これらのオブジェクトの特定の状態のチェックは、10 分後に Checkmk でステータスを変更するように設定されています。
1.6. 従来の Kubernetes 監視との違い
Checkmk の Kubernetes 監視は、一から書き直されました。 監視できるデータの範囲が大幅に拡大しました。 Checkmk2.1.0 の Kubernetes 監視の技術的基盤は根本的に異なるため、Kubernetes オブジェクトの以前の監視データを転送したり、書き換えたりすることはできません。
2. クラスタに必要な前提条件を作成します
Checkmk で Kubernetes クラスタを監視するには、まずクラスタに必要な前提条件を作成する必要があります。 まず、クラスタに、どのポッド/コンテナをデプロイし、どのように設定するかを指示します。
2.1. Helm リポジトリの設定
Kubernetes 監視のインストールは、helm ツールを使用して行います。
Helm は、経験の浅いユーザーにも適しており、設定の管理を標準化します。
Helm は、Kubernetes 用のパッケージマネージャの一種です。
Helm をまだ使用していない場合は、通常、Linux ディストリビューションのパッケージマネージャまたはHelm プロジェクトのweb サイトから入手できます。
Helm を使用すると、リポジトリをソースとして含め、そこに含まれるヘルムチャートをパッケージと同じようにクラスタに簡単に追加することができます。
まず、リポジトリを特定します。
以下の例では、後でリポジトリにアクセスしやすいように、checkmk-chart という名前を使用しています。
もちろん、お好きな名前を使用することもできます。
user@host:~$ helm repo add checkmk-chart https://checkmk.github.io/checkmk_kube_agentKubernetes の新しい開発で必要になった場合は、Helm チャートを更新します。
そのため、リポジトリに新しいバージョンが利用可能になっているかどうかを時々チェックすることをお勧めします。
前のコマンドのように、リポジトリのローカルコピーに「checkmk-chart 」という名前を付けた場合は、次のコマンドを使用して、リポジトリで利用可能なチャートのすべてのバージョンを表示できます。
user@host:~$ helm search repo checkmk-chart --versions
NAME CHART VERSION APP VERSION DESCRIPTION
checkmk-chart/checkmk 1.2.0 1.2.0 Helm chart for Checkmk - Your complete IT monit...
checkmk-chart/checkmk 1.1.0 1.1.0 Helm chart for Checkmk - Your complete IT monit...
checkmk-chart/checkmk 1.0.1 1.0.1 Helm chart for Checkmk - Your complete IT monit...
checkmk-chart/checkmk 1.0.0 1.0.0 Helm chart for Checkmk - Your complete IT monit...新しいバージョンが利用可能な場合は、helm repo update で更新できます。
2.2. お使いの環境に合わせて設定をカスタマイズする
お客様の Kubernetes クラスタの構造を事前に把握することはできないため、クラスターコレクターの起動方法については、最も安全な方法を選択しています。 デフォルトでは、リモートからアクセス可能なポートは指定されていません。 後でコレクターにアクセスできるようにするには、お客様のクラスタに合わせてこれらの設定を変更する必要があります。
デフォルトでは、IngressによるクエリとNodePort によるクエリの 2 つの通信パスをサポートしています。 これらの設定は、クラスタでサポートしているバリエーションによって異なります。
すべての構成で特定のパラメーターを自分で決定できるように、コントロールファイル（values.yaml ）を含めます。
このようなvalues.yaml を作成するには 2 つの方法があります。
Helm チャートで当社が提供するファイルを抽出して編集するか、最小限のバージョンを自分で作成します。
このファイルの変更をクラスタにデプロイする場合は、この記事の後半で説明するヘルムチャートのインストールコマンドを再度使用できます。
独自の basic.values.yaml を作成する
変更したい値のみを入力するvalues.yaml を作成することができます。
たとえば、当社のヘルムチャートでは、クラスターコレクターのサービスタイプはデフォルトでClusterIP に設定されています。
このサービスタイプをNodePort に変更し、ポートを30035に変更したい場合は、次のようにvalues.yaml を作成するだけで十分です。
user@host:~$ echo 'clusterCollector: {service: {type: NodePort, nodePort: 30035}}' > values.yamlIngressの有効化は次のように行えます:
user@host:~$ echo 'clusterCollector: {ingress: { enabled: true }}' > values.yamlHelm チャートから values.yaml を抽出する
当社が提供する完全なvalues.yaml は、次のコマンドで簡単に抽出できます。
user@host:~$ helm show values checkmk-chart/checkmk > values.yamlこの方法で作成したファイルは、必要に応じて変更し、インストール時またはその後のアップグレード時に、-f values.yaml パラメータを指定してhelm に渡してください。
Ingress 経由での通信の提供
Ingressを使用してサービスへのアクセスを制御する場合は、values.yaml で、あらかじめ用意されている部分を適宜編集してください。
概要をわかりやすくするため、以下の例では関連部分のみを示しています。enabled パラメータをtrue に設定します。
残りのパラメータは、お使いの環境に合わせて適宜変更してください。
ingress:
enabled: true
className: ""
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
hosts:
- host: checkmk-cluster-collector.local
paths:
- path: /
pathType: Prefix
tls: []
# - secretName: chart-example-tls
# hosts:
# - chart-example.localNodePort 経由での通信の提供
ポートを介してサービスに直接アクセスすることもできます。
これは、Ingress を使用していない場合に必要です。
以下の例では、関連するセクションのみを示しています。type の値をNodePort に設定し、nodePort のコメントを削除します。
service:
# if required specify "NodePort" here to expose the cluster-collector via the "nodePort" specified below
type: NodePort
port: 8080
nodePort: 30035HTTPS 用のクラスターコレクターの設定
クラスタコレクタとの通信、およびクラスタコレクタ間の通信を HTTPS に切り替える場合は、values.yaml ファイルも変更する必要があります。
HTTPS を有効にするには、付属のvalues.yaml ファイル内の以下のセクションを編集する必要があります。
tlsCommunication:
enabled: false
verifySsl: false
# clusterCollectorKey: |-
# -----BEGIN EC PRIVATE KEY-----
# XYZ
# -----END EC PRIVATE KEY-----
# clusterCollectorCert: |-
# -----BEGIN CERTIFICATE-----
# XYZ
# -----END CERTIFICATE-----
# checkmkCaCert: |-
# -----BEGIN CERTIFICATE-----
# XYZ
# -----END CERTIFICATE-----enabled またはverifySsl で始まる行で、false をtrue に置き換えてください。
次に、clusterCollectorKey 、clusterCollectorCert 、checkmkCaCert の 3 つのセクションの前にあるハッシュマークを削除し、その後に以下のデータを挿入してください。
自己署名証明書を使用するか、認証機関 (CA) から証明書を取得するかは、組織で決定してください。
証明書は、以下の要件を満たしている必要がありますのでご注意ください。
CA 証明書には、ホスト名または Ingress の名前を FQDN として含める必要があります。
サーバー証明書の場合、FQDN は次のパターンに対応している必要があります：
<service_name>.<namespace>.cluster.local。証明書署名要求を生成するための設定ファイルの「
[ v3_ext ]」セクションでは、subjectAltNameは次のパターンと一致する必要があります。subjectAltName: DNS:<service_name>.<namespace>.cluster.local, IP:<service ip>
独自のサービスアカウントを使用する場合
当社のヘルムチャートを使用すると、デフォルトでサービスアカウントがクラスタに作成されます。
適切なサービスアカウントをすでに持っている場合は、values.yaml に追加して、新しいアカウントの作成を抑制するだけで十分です。
serviceAccount:
create: false
name: "myserviceaccount"GKE Autopilot を監視するための前提条件
GKE (Google Kubernetes Engine) クラスタをオートパイロットモードで運用している場合、Checkmkはいわゆるオートパイロットパートナーであるため、Checkmk による監視も可能です。
var_run readOnly values.yaml を に設定するだけです。
volumeMountPermissions:
var_run:
readOnly: trueポッドセキュリティアドミッションコントローラの設定
クラスタでポッドセキュリティ基準を使用する場合は、対応する名前空間で無制限のアクセス権を持つように Checkmk クラスターコレクターを設定する必要があります。 理想的には、以下の仕様で名前空間を作成してください。
apiVersion: v1
kind: Namespace
metadata:
name: checkmk-monitoring
labels:
pod-security.kubernetes.io/enforce: privileged
pod-security.kubernetes.io/enforce-version: latestkubectl apply -f namespace.yaml を実行して、名前空間を作成できます。
後でhelm upgrade コマンドを実行する際に、--create-namespace オプションを使用する必要がないことにご注意ください。
クラスターコレクターがすでに実行されているか、名前空間がすでに存在する場合、次のコマンドを使用して上記のラベルを設定することもできます。
user@host:~$ kubectl label --overwrite ns checkmk-monitoring pod-security.kubernetes.io/enforce=privileged pod-security.kubernetes.io/enforce-version=latestポッドセキュリティポリシーおよびネットワークポリシー
PodSecurityPolicy(PSP) およびNetworkPolicyポリシーは、主に互換性の理由から、Helm チャートに含まれています。
PSP はv1.25 以降、Kubernetes から完全に削除されたため、Helm チャートのバージョン1.3.0 以降では、デフォルトで使用不能になっています。
対応するセクションは、次のように変更されています。
rbac:
pspEnabled: falseクラスタで PSP を引き続き使用する場合は、values.yaml でこのオプションをtrue に設定する必要があります。
rbac:
pspEnabled: true後日、このエントリが使用不能に設定されているにもかかわらず正しく処理されていないことが判明した場合は、このエントリを完全に削除いたします。
NetworkPolicy についても同様です。
クラスタでこれを使用している場合は、values.yaml の場所をenabled: false からenabled: true に変更する必要があります。
この状況では、values.yaml 内の以下のドキュメントを参照して、NetworkPolicy を正しく設定してください。
## ref: https://kubernetes.io/docs/concepts/services-networking/network-policies/
networkPolicy:
# keep in mind: your cluster network plugin has to support NetworkPolicies, otherwise they won't have any effect
enabled: false
# specify ipBlock cidrs here to allow ingress to the cluster-collector
# this is required for the checkmk servers to be able to scrape data from checkmk, so include the resprective ip range(s) here
allowIngressFromCIDRs: []
# - 127.0.0.1/32 # e.g. Checkmk Server
# - 127.0.0.1/24 # e.g. Metallb speakers
# the cluster-collector needs to be able to contact the kube-apiserver
# you have three options here to choose from, depending on your cluster setup:
# 1) if your apiserver resides outside the cluster, resp. you have a kubernetes endpoint available (check via "kubectl -n default get ep kubernetes")
# we can make use of helm lookup to automatically inject the endpoint (cidr + port) here.
# This is the most comfortable one, just note that helm lookup won't work on a "helm template" or "helm diff" command.
# (see also: https://helm.sh/docs/chart_template_guide/functions_and_pipelines/#using-the-lookup-function)
# 2) similar to 1) you can also specify the "ipBlockCidr" directly. Make sure to disable "enableCidrLookup", and also fill the "port".
# 3) if the apiserver resides inside the cluster, disable "enableCidrLookup", unset "ipBlockCidr", and fill the "labelSelectors" section
# with the name of the namespace where the kube-apiserver is availabe, and the label key and label value that defines your kube-apiserver pod.
egressKubeApiserver:
enableCidrLookup: true
# ipBlockCidr: 172.31.0.3/32
# port: 6443
# labelSelectors:
# namespace: kube-system
# key: app
# value: kube-apiserver2.3. ヘルムチャートのインストール
values.yaml をカスタマイズまたは独自に作成した後、以下のコマンドを使用して、Checkmk でクラスタを監視するために必要なすべてのコンポーネントをクラスタにインストールしてください。
user@host:~$ helm upgrade --install --create-namespace -n checkmk-monitoring myrelease checkmk-chart/checkmk -f values.yamlこのコマンドは、その意味が直感的に理解できないため、個々のオプションについて以下で説明します。
| コマンドエレメント | 説明 |
|---|---|
|
この部分は、Kubernetes クラスタに構成を送信するための基本コマンドです。 |
|
Kubernetes では、設定を追加する名前空間を常に指定する必要があります。名前空間がまだ存在しない場合は、このオプションが必要です。この場合、Helm が名前空間を作成します。 |
|
このオプションは、設定を追加する名前空間を指定します。 |
|
ここでは、 |
|
このオプションの最初の部分は、以前に作成したリポジトリを表します。2 番目の部分（スラッシュの後）は、Kubernetes 監視の設定を作成するために必要な情報を含むパッケージです。 |
|
最後に、先ほど作成または変更した設定ファイルを入力します。このファイルには、 |
コマンドを実行すると、Kubernetes クラスタは Checkmk による監視の準備が整います。 クラスタは、必要なポッドおよびポッドに含まれるコンテナが実行され、アクセス可能であることを自動的に監視します。
Helm チャートの出力
次に、Checkmk で設定を行います。
この設定をできるだけ簡単にするため、Helm チャートの出力には一連のコマンドを装備しています。
この出力は、values.yaml ファイルで指定した値にも自動的に適合します。
NodePort を使用する場合、NodePort の IP およびポートなどを表示するコマンドが表示されます。
代わりに Ingress を使用する場合、出力はそれに応じて変更されます。
以下は、NodePort を使用してインストールが正常に完了したときの、少し省略した出力です。
user@host:~$ helm upgrade --install --create-namespace -n checkmk-monitoring myrelease checkmk-chart/checkmk -f values.yaml Release "myrelease" has been upgraded. Happy Helming! NAME: myrelease LAST DEPLOYED: Sat Dec 16 19:00:11 2022 NAMESPACE: checkmk-monitoring STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: You can access the checkmk: myrelease-checkmk-cluster-collector.checkmk-monitoring 名前空間cluster-collectorvia: NodePort: export NODE_PORT=$(kubectl get --namespace checkmk-monitoring -o jsonpath="{.spec.ports[0].nodePort}" services myrelease-checkmk-cluster-collector); export NODE_IP=$(kubectl get nodes --namespace checkmk-monitoring -o jsonpath="{.items[0].status.addresses[0].address}"); echo http://$NODE_IP:$NODE_PORT # Cluster-internal DNS ofcluster-collectorcheckmk-monitoringにmyrelease-checkmk-checkmkという名前のサービスアカウントのトークンを使用して、cluster-collectorに対してクエリを発行できるようになりました。 次のコマンドを実行して、そのトークンとクラスタの ca 証明書を取得します。 export TOKEN=$(kubectl get secret myrelease-checkmk-checkmk -n checkmk-monitoring -o=jsonpath='{.data.token}' | base64 --decode); export CA_CRT="$(kubectl get secret myrelease-checkmk-checkmk -n checkmk-monitoring -o=jsonpath='{.data.ca\.crt}' | base64 --decode)"; # 注 ： を引用 変数 を echo'ing に保存 を適切に 行 を破る：echo "$CA_CRT"アクセスをテストするには、以下を実行してください。 curl -H "Authorization: Bearer $TOKEN" http://$NODE_IP:$NODE_PORT/metadata | jq
この出力から、色付きの行をコピーしてコマンドを実行してください。
最初のブロックには、NodePortに関する情報が表示されます:
user@host:~$ export NODE_PORT=$(kubectl get --namespace checkmk-monitoring -o jsonpath="{.spec.ports[0].nodePort}" services myrelease-checkmk-cluster-collector);
user@host:~$ export NODE_IP=$(kubectl get nodes --namespace checkmk-monitoring -o jsonpath="{.items[0].status.addresses[0].address}");
user@host:~$ echo http://$NODE_IP:$NODE_PORT
http://10.184.38.103:30035これは、後で Checkmk の Kubernetes ルールでCollector NodePort / Ingress endpoint フィールドに入力する必要があるアドレスとまったく同じです。
次のブロックのコマンドで、サービスアカウントのトークンと証明書の両方が取得されます。
これにより、データは環境変数TOKEN およびCA_CRT に保存されます。CA_CRT 変数を出力する場合は、必ず引用符で囲んでください。そうしないと、証明書内の重要な改行が失われてしまいます。
user@host:~$ export TOKEN=$(kubectl get secret myrelease-checkmk-checkmk -n checkmk-monitoring -o=jsonpath='{.data.token}' | base64 --decode);
user@host:~$ export CA_CRT="$(kubectl get secret myrelease-checkmk-checkmk -n checkmk-monitoring -o=jsonpath='{.data.ca\.crt}' | base64 --decode)";
user@host:~$ echo $TOKEN
eyJhbGciOiJSUzI1NiIsImtpZCI6InR6VXhGSU ...
user@host:~$ echo "$CA_CRT"
-----BEGIN CERTIFICATE-----
MIIBdjCCAR2gAwIBAgIBADAKBggqhkjOPQQDAjAjMSEwHwYDVQQDDBhrM3Mtc2Vy
dmVyLWNhQDE2NjIxNDc5NTMwHhcNMjIwOTAyMTk0NTUzWhcNMzIwODMwMTk0NTUz
...
-----END CERTIFICATE-----Checkmk で設定を行う場合は、トークンと証明書の両方を保存しておく必要があります。 この情報をシェルに表示したままにしておくか、トークンと証明書を、Checkmk での次のセットアップでアクセスできる場所にコピーしてください。
前の 2 つのエクスポートコマンドを実行した場合は、最後のコマンドを使用して、セットアップが正常に完了したことを確認できます。
curl -H "Authorization: Bearer $TOKEN" http://$NODE_IP:$NODE_PORT/metadata | jq
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1815 100 1815 0 0 126k 0 --:--:-- --:--:-- --:--:-- 126k
{
"cluster_collector_metadata": {
"node": "mynode",
"host_name": "myrelease-checkmk-cluster-collector-58f97df9c9-mdhsw",
"container_platform": {
"os_name": "alpine",
"os_version": "3.15.4",
"python_version": "3.10.4",
"python_compiler": "GCC 10.3.1 20211027"
},
"checkmk_kube_agent": {
"project_version": "1.0.1"
}
}
...たとえば、非常に省略された出力の先頭には、クラスターコレクターのバージョンが表示されます。 その下には、このクラスタ内のすべてのノードのメタデータが続きます。
3. Checkmk での監視の設定
次に、Checkmk の GUI で、スペシャルエージェントと、Kubernetes オブジェクトのホストを自動的に作成するルールの設定に進みます。 ただし、スペシャルエージェントを設定するには、いくつかの前提条件を満たす必要があります。
3.1. Checkmk にパスワード (トークン) を保存する
サービスアカウントのパスワード（トークン）は、Checkmk のパスワードストアに保存することをお勧めします。
これにより、パスワードの保存と使用を組織的に分離できるため、最も安全な方法です。
あるいは、ルールを作成する際にパスワードをプレーンテキストで直接入力することもできます（以下を参照）。
必要なパスワードの表示方法については、ヘルムチャートの出力を参照してください。Setup > General > Passwords > Add password を使用して、パスワードを Checkmk パスワードストアに追加します。たとえば、ID とタイトルMy Kubernetes Token に追加します。
3.2. サービスアカウントの CA 証明書を Checkmk にインポートします。
Checkmk がサービスアカウントの認証機関 (CA) を信頼するには、CA 証明書を Checkmk に保存する必要があります。
必要な証明書を表示する方法も、ヘルムチャートの出力に記載されています。BEGIN CERTIFICATE およびEND CERTIFICATE の行を含むすべてをここにコピーし、Setup > General > Global settings > Site management > Trusted certificate authorities for SSL のセットアップメニューに証明書を追加してください。
3.3. ピギーバックホストの作成
Checkmk で通常どおり新しいホストを作成し、たとえば「mykubernetesclusterhost 」という名前を付けます。
タイトルとホスト名からもわかるように、このホストはピギーバックデータの収集、およびクラスタレベルでのすべてのサービスとメトリックのマッピングに使用されます。
このホストは特別なエージェント経由でのみデータを受信するため、ホストのプロパティで「IP address family 」オプションを「No IP 」に設定してください。
3.4. ダイナミックホストマネージメントの設定
異なる Kubernetes クラスタのオブジェクトを確実に分離するために、Setup > Hosts > Add folder を使用してクラスタごとにフォルダを作成し、ダイナミックホストマネージメントがクラスタのすべてのホストを自動的に作成できるようにすると便利です。 ただし、このようなフォルダを作成または使用することは任意です。
次に、受信ピギーバックデータ用の接続を設定します 商業版の場合 ：Setup > Hosts > Dynamic host management > Add connection.まず、タイトルを入力し、[Connection Properties] の [show more ] をクリックします。
次に、[Add new element ] をクリックし、[Create hosts in] で先ほど作成したフォルダを選択します。
Host attributes to set のデフォルトの属性はそのままにしておきます。 これにより、Checkmk は、自動的に作成されたホストのピギーバックデータのみに従い、たとえば、それらのホストに ping を送信したり、SNMP 経由でアクセスしたりすることを試みません。
監視可能オブジェクトおよび監視対象オブジェクトが絶えず出入りする Kubernetes 環境では、Automatically delete hosts without piggyback data オプションも有効にすることをお勧めします。 このオプションの具体的な機能、およびホストが実際に削除される状況については、ダイナミックホストマネージメントに関する記事の「ホストの自動削除」の章で説明しています。
次に、Restrict source hosts に、先ほど作成したピギーバックホストを入力し、Discover services during creation オプションを有効にします。
この新しい接続の「Connection Properties 」セクションは、次のように表示されます。
3.5. Checkmk Raw でのピギーバックデータの処理
Checkmk Raw では、蓄積するピギーバックデータ用のホストを手動で作成する必要があります。
Kubernetes クラスタでは、ピギーバックホストが大量に発生する可能性が高いため、コマンド cmk-piggyback list orphansコマンド.
3.6. 定期的なサービスディスカバリーのカスタマイズ
デフォルトでは、Checkmk は 2 時間ごとにサービスディスカバリーを実行し、その結果をCheck_MK Discovery サービスに表示します。
この設定は、Periodic service discovery ルールセットにあります。
Kubernetes のコンテキストでは、ラベルcmk/kubernetes:yes を持つすべてのホストに対するルールを作成することをお勧めします。
このラベルは、Kubernetes オブジェクトを表すすべてのホストに Checkmk によって自動的に付与されます。
ここでは、サービスディスカバリーのインターバルを短く設定し、Automatically update service configuration オプションも有効にしてください。
次のスクリーンショットの設定はあくまで例です。
クラスタに最適な設定は、ケースバイケースで決定してください。
このルールをクラスタのすべてのホストに制限するには、Host labels のConditions に「cmk/kubernetes:yes 」を入力するだけで十分です。
ただし、複数のクラスタに対して個別のルールを作成する場合は、ここでそれぞれのクラスタ固有のラベルを使用してください。
これらのラベルは、常に「cmk/kubernetes/cluster:mycluster 」というフォームになります。
3.7. スペシャルエージェントの設定
クラスタと Checkmk で必要な準備がすべて完了しましたので、次はスペシャルエージェントの設定に移ります。 これは、Setup > Agents > VM, cloud, container > Kubernetes から確認できます。Add rule で新しいルールを作成します。
まず、監視するクラスタの名前を割り当てる必要があります。
この名前は自由に選択できます。
この名前は、この特定のクラスタから来るすべてのオブジェクトに一意の名前を付けるために使用されます。
たとえば、ここに「mycluster 」と入力すると、このクラスタのすべてのポッドのホスト名は、後で「pod_mycluster 」で始まります。
ホスト名の次の部分は、この Kubernetes オブジェクトが存在する名前空間になります。
たとえば、ポッドのホスト名は「pod_mycluster_kube-system_svclb-traefik-8bgw7 」になります。
Token で、Checkmk パスワードストアから先ほど作成したエントリを選択します。
API server connection > Endpoint で、Checkmk は、Kubernetes API サーバーにアクセスするための URL (または IP アドレス) の入力を求めます。
サービスが仮想ホスト経由で提供されていない場合にのみ、ポートを入力する必要があります。
このアドレスを調べる最も簡単な方法は、手元にアドレスがない場合、Kubernetes 環境によって異なります。
次のコマンドを実行すると、server 行に API サーバーのエンドポイントが表示されます。
user@host:~$ kubectl config view
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: DATA+OMITTED
server: https://DFE7A4191DCEC150F63F9DE2ECA1B407.mi6.eu-central-1.eks.amazonaws.com
name: xyz:aws:eks:eu-central-1:150143619628:cluster/my-kubernetesただし、kubectl config view の実際の出力は、大きく異なります。server 行にもポートが指定されている場合は、そのポートもルールに含めてください。
ここまで手順に従って、クラスタの CA証明書を上記の手順でCheckmkに保存した場合は、SSL certificate verification で「Verify the certificate 」エントリを選択してください。
次に、Checkmk クラスターコレクターによって収集された使用状況データで、Kubernetes クラスタの監視を充実させることができます。 その重要性を強調するため、ここでもう一度繰り返します。 クラスタの包括的な監視には、クラスターコレクターのセットアップが不可欠です。 これだけが、CPU やメモリの使用率などの重要なデータを取得し、個々のコンポーネントが使用するファイルシステムに関する情報を入手する唯一の方法です。
したがって、Enrich with usage data from Checkmk Cluster Collector オプションを有効にし、NodePort または Ingress のエンドポイントを指定してください。 このエンドポイントを再表示する方法は、Helm チャートの出力に記載されています。
Collect information about… オプションを使用して、クラスタ内で監視するオブジェクトを選択できるようになりました。 当社の事前選択は、最も関連性の高いオブジェクトを網羅しています。Pods of CronJobs も監視する場合は、この点に関するインラインヘルプを参照してください。
次の 2 つのオプションを使用すると、監視するオブジェクトをさらに制限することができます。 特定の名前空間のオブジェクトのみに関心がある場合は、Monitor namespaces でそれに応じて設定してください。 ここでは、監視する個々の名前空間を入力するか、監視から個々の名前空間を明示的に除外することができます。
Cluster resource aggregation オプションを使用すると、クラスタのワークロードにリソースを提供しないノードを指定できます。
これらのノードは、使用可能なリソースの計算から除外する必要があります。そうしないと、容量のボトルネックが検出されないおそれがあります。
したがって、デフォルトでは、control-plane およびinfra ノードは評価から除外されます。
最後のオプションとして、Kubernetes からいわゆるアノテーションをインポートすることができます。 Checkmk では、これらのアノテーション はホストラベルとなり、ルールで条件として使用することができます。 インポートするアノテーションは、正規表現を使用して指定することができます。 ここでも、詳細なインラインヘルプを参照してください。
注： Import all valid annotations オプションは、完全性を期すためにのみここに記載されています。 すべての注釈を無差別にインポートすることは、Checkmk に膨大な量の無用なラベルが蓄積される原因となるため、お勧めできません。
重要： Conditions > Explicit hosts で、先ほど作成したホスト を入力してください。
次に、ルールを保存し、このホストでサービスディスカバリーを実行します。 すぐに、最初のクラスタレベルのサービスがここに表示されます。
次に、行ったすべての変更をアクティブにして、ダイナミックホストマネージメントに作業を任せます。 これにより、Kubernetes オブジェクトのすべてのホストが短時間で作成されます。
4. Kubernetes オブジェクトのラベル
Checkmk は、サービスディスカバリー中に、クラスタ、デプロイ、名前空間などの Kubernetes オブジェクトのラベルを自動的に生成します。
Checkmk が自動的に生成する Kubernetes オブジェクトのラベルは、すべてcmk/kubernetes/ で始まります。
たとえば、ポッドには、ノードのラベル (cmk/kubernetes/node:mynode)、このオブジェクトがポッドであることを示すラベル (cmk/kubernetes/object:pod)、および名前空間のラベル (cmk/kubernetes/namespace:mynamespace) が常に付与されます。
これにより、同じタイプまたは同じ名前空間にあるすべてのオブジェクトに対するフィルタやルールを非常に簡単に作成できます。
5. ダッシュボードとビュー
5.1. Kubernetes ダッシュボード
Checkmk の商業版には Kubernetes 用の 6 つのビルトインダッシュボードが付属しています。 これらのダッシュボードを実用的に使用するには、クラスターコレクターをインストールして設定する必要があります。 具体的には、以下の 6 つのダッシュボードがあります。
Kubernetes
Kubernetesクラスタ
Kubernetes デーモンセット
Kubernetes デプロイメント
Kubernetes 名前空間
Kubernetes ステートフルセット
エントリポイントは常にKubernetes ダッシュボードです。このダッシュボードには、Monitor > Applications > Kubernetes からアクセスできます。
Kubernetes ダッシュボードでは、監視対象のすべてのKubernetesクラスタが左側にリスト表示されます。 このクラスタのリストは、Kubernetesダッシュボードをさらに詳しく調べるためのエントリポイントでもあります。 クラスタの名前をクリックすると、選択したクラスタのKubernetes Cluster ダッシュボードに移動します。Kubernetes Cluster ダッシュボードで、それぞれの名前をクリックすると、他のコンテキスト依存のダッシュボードに移動します。
5.2. HW/SW インベントリ
Checkmk Kubernetes 監視は、HW/SW インベントリもサポートしています。 たとえば、上記のクラスタダッシュボードでクラスタのプライマリ名（ここでは「mycluster 」）をクリックすると、そのクラスタのインベントリにジャンプします。
同様に、オブジェクトのプライマリ名が入ったボックスをクリックすると、他のダッシュボードのそれぞれのオブジェクトのインベントリに移動します。 次の例は、ポッドの HW/SW インベントリを示しています。
6. インストールチェック
ヘルムチャートの出力セクションでは、Kubernetes を包括的に監視するためのコンポーネントが正常にインストールされていることを確認する最初の方法をすでに学びました。 Checkmk GUI では、インストールと設定が正常に行われたかどうかを、いくつかの場所で確認することもできます。
ここで最も重要なサービスは、間違いなくKubernetes API およびCluster Collector です。 これらは、作成したクラスタホストに存在し、特定の情報を表示する必要があります。
Kubernetes API サービスは、通常、Summary でLive, Ready をレポートする必要があります。Cluster Collector サービスは、インストールされているクラスターコレクターのバージョン番号を表示する必要があります。 いずれかがこの条件を満たしていない場合は、ヘルムチャートのインストールとスペシャルエージェントの設定を確認する必要があります。
さらにチェックする方法については、商業版のクラスタダッシュボードでご説明しています。
Kubernetes ダッシュボードでは、クラスタコレクターがクラスタで実行され、データを収集しているかどうかを非常に早い段階で確認できます。CPU resources およびMemory resources の列にデータが含まれていない場合は、クラスタコレクターが正しく実行されていないことを強く示しています。 正しく設定されている場合、Kubernetes ダッシュボードは次のようになります。
このウィンドウでクラスタの名前をクリックすると、それぞれのクラスタのダッシュボードの「Kubernetes Cluster 」に移動します。 ここでは、3 つのボックス「Primary datasource 」、「Cluster collector 」、「API health 」が緑色になり、「OK 」と表示されているはずです。
7. クラスタから監視コンポーネントを削除する
Helm チャートを使用して Checkmk をクラスタにデプロイした場合、作成したアカウント、サービス、ポッド、およびノードポートは、設定と同じくらい簡単に削除できます。 これを行うには、チャートを使用してインストールしたリリースをアンインストールするだけです。
リリースの名前がわからない場合は、まず、すべての名前空間にあるすべての Helm リリースを表示してください。
user@host:~$ helm list --all-namespaces
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
myrelease checkmk-monitoring 1 2022-08-15 19:00:42.318666784 +0200 CEST deployed checkmk-1.0.1 1.0.1上記の出力例のように、CHART 列に Checkmk への参照を含むリリースが見つかるはずです。
正しい名前空間を指定して、次のコマンドでこのリリースを削除します。
user@host:~$ helm uninstall myrelease -n checkmk-monitoring
release "myrelease" uninstalled