엉뚱한 녀석의 블로그 [quirky guy's Blog]

Zabbixによる Kubernetes モニタリング構築ガイド

—

제공

black K
|

⚠️ バージョン注意（重要）
Zabbixはバージョン（7.4 / 7.2 / 7.0 LTSなど）によって Helm Repo URL およびチャートブランチが異なる。
以下の例は 7.4 を前提としており、運用中の Zabbix サーバまたはテンプレートのバージョンに合わせて <ZBX_VER> の値を変更すること。

Repo パターン:

https://cdn.zabbix.com/zabbix/integrations/kubernetes-helm/<ZBX_VER>/

0) 前提条件

  • Kubernetes 1.23 以上（推奨: 1.24+）
  • kubectl, helm が使用可能であること
  • Zabbix Server または Proxy から TCP 10050 / 10051 が通ること
  • 対応する Zabbix バージョンの Zabbix agent2 が事前インストール済み
  • デプロイ先 Namespace 例：monitoring

1) Helm Repo 登録（バージョン選択）

使用する Zabbix バージョンを指定

# export ZBX_VER=7.4

Namespace 作成

# kubectl create namespace monitoring 2>/dev/null || true

バージョン別 Helm Repo 追加・更新

# helm repo add zabbix-chart-${ZBX_VER} https://cdn.zabbix.com/zabbix/integrations/kubernetes-helm/${ZBX_VER}/
# helm repo update

2) values.yaml の作成と編集（1ファイルのみ）

チャートのデフォルト値をローカルに出力し、環境に合わせて編集する。

helm show values zabbix-chart-${ZBX_VER}/zabbix-helm-chrt > zabbix_values.yaml

※以下の設定例はすべて Zabbix 7.4 基準。

① kube-state-metrics を特定ノードに配置

kubeStateMetrics ブロックがある場合、kube-state-metrics に修正して以下を設定：

kube-state-metrics:
  enabled: true
  nodeSelector:
    kubernetes.io/hostname: example-node1  # デプロイ先ノード

Taint ノードに配置する場合は tolerations を追記。

② Zabbix Proxy を特定ノードに配置

zabbixProxy:
  enabled: true
  nodeSelector:
    kubernetes.io/hostname: example-node1
  tolerations: []   # 必要に応じて taint に合わせる
  affinity: {}      # 高度な制御を行う場合に使用

Zabbix Proxy の環境変数：

- name: ZBX_HOSTNAME
  value: example-proxy   # Zabbix UI上で使用するプロキシ名

- name: ZBX_SERVER_HOST
  value: "zabbix サーバ IP"

③ Zabbix Agent のデプロイノード指定（DaemonSet）

Agentをノード単位に制限する場合：

zabbixAgent:
  enabled: true
  nodeSelector:
    kubernetes.io/hostname: example-node1

nodeSelector の Linux指定（kubernetes.io/os: linux）はコメントアウトすること。

Agentを enabled: false にすると、既存ホストの agent2 を停止する必要はない。
ここでは true として Pod ベースに切り替える。

④ Zabbix Java Gateway（必要に応じて）

zabbixJavaGateway:
  enabled: false   # 使用しない場合

使用する場合は：

zabbixJavaGateway:
  enabled: true
  nodeSelector:
    kubernetes.io/hostname: example-node1

⑤ Zabbix Server IP の指定

- name: ZBX_SERVER_HOST
  value: 実際のサーバ IP

以上の設定だけでも問題なく動作するが、必要に応じて
resources, tolerations, hostNetwork なども同ファイルで調整可能。
ポイントは1つのvalues.yamlだけを編集してデプロイすること。

Zabbix UI 設定

  1. 管理 → プロキシ → 新規作成
    • プロキシ名: 例 example-proxy
  2. テンプレート適用時
    • 対象: Prod K8S Cluster
    • プロキシ: 上記で登録したものを指定

テンプレートのうち「Kubernetes cluster state by HTTP」は、
ZabbixサーバがK8sクラスタ外部にある場合、データ収集ができないため、
Zabbix Proxy の使用が必須。

zabbix_values.yaml の設定では、プロキシのバージョンを Zabbix サーバーと同じバージョンに合わせることが推奨される。
例：Zabbix サーバーのバージョンが 7.4.3 の場合、以下のように同じ 7.4.3 に設定する。

3) 既存ホストの zabbix-agent2 停止

PodでAgentを動かす場合、ホスト側Agent2を停止して競合を防ぐ。

# sudo systemctl stop zabbix-agent2
# sudo systemctl disable zabbix-agent2
  • Pod未展開ノード → ホストagent2継続利用（競合なし）
  • Pod展開ノード → Podのみ使用（重複・ポート競合回避）

4) Helm デプロイ

#helm install zabbix zabbix-chart-${ZBX_VER}/zabbix-helm-chrt \
  -n monitoring \
  --dependency-update \
  -f zabbix_values.yaml

確認：

# kubectl -n monitoring get pods -o wide

values.yamlを更新した場合は：

# helm upgrade --install zabbix zabbix-chart-${ZBX_VER}/zabbix-helm-chrt \
  -n monitoring \
  -f zabbix_values.yaml

5) ServiceAccount トークン発行

# kubectl -n monitoring get secret zabbix-service-account -o jsonpath='{.data.token}' | base64 -d; echo

6) Zabbix テンプレート適用（重複回避）

ホスト名適用テンプレート
K8S ClusterKubernetes cluster state by HTTP / API server / controller manager / scheduler
K8S NodeKubernetes nodes by HTTP / Kubelet by HTTP

共通マクロ設定：

{$KUBE.API.TOKEN} = 上記で発行したSAトークン
{$KUBE.API.URL} = https://<apiserver_ip>:6443
{$KUBE.KUBELET.URL} = https://<node_ip>:10250

状況により：

{$KUBE.API.SERVER.URL} = https://<apiserver_ip>:6443/metrics

{$KUBE.KUBELET.URL} はマスターノードIPでも問題なし。

7) Zabbix UI 設定例

項目例
クラスタホスト名Prod K8S Cluster
ノードホスト名Prod K8S Node
APIサーバIP192.168.190.24 (マスター)
Kubelet IP192.168.190.25 (Zabbix Pod配置ノード)
  1. Prod K8S Cluster Template -> cluster state / api server / controller manager / scheduler

2. Prod K8S Cluster -> set macros

3. Prod K8S node Templates -> node/kubelet templates

4. Prod K8S Node -> set macros

8) チェックリスト

  • 対象ノードの zabbix-agent2 が完全停止済み
  • Server ↔ Agent2 (10050/10051) 通信可能
  • {$KUBE.API.TOKEN} が有効（get/list/watch 権限）
  • {$KUBE.KUBELET.URL} (10250) にアクセス可能
  • Cluster / Node テンプレートを別ホストとして登録
  • Repo・チャート・テンプレートのバージョンがサーバと一致
  • Zabbix Proxyの性能上の限界
    – Zabbix Proxyは内部データベースのI/O処理能力に応じて、1秒あたりに処理で
    きる値（VPS: Values Per Second）に上限があります。
    – つまり、1台のプロキシに全てのメトリクスを集約する構成では、おおよそ
    250 VPS 前後 が限界となります。
    これを超える場合は、プロキシのリソース増強、または プロキシの水平分割 （Proxy A/B構成） による負荷分散が有効です。
    – VPSが250以下であっても、Podに割り当てられたリソース、特にCPUのlimit
    が低い場合は、
    Proxyの処理がボトルネックとなり、データ収集の遅延が発生する可能性があ
    ります。

日本語（表現を自然に調整）

VPS値状態意味
≤ 250正常運用追加の対応は不要
250 ~ 350境界領域収集遅延が発生する可能性あり → リソース増強 / チューニングを検討
≥ 350危険領域収集遅延が発生する可能性が高い → Proxyの分割を推奨

この内容について、もし要望があれば、今後さらに詳しい解説記事を作成します。

9) FAQ

Q. なぜ Zabbix サーバをクラスタ外に置くのか？
A. オンプレミス環境では必須ではないが、Kubernetes クラスタ自体の状態も監視するため、
Zabbix を外部に配置しておく構成が推奨される。

🔗 関連記事

Zabbix で Kubernetes Pod の主要指標を可視化する（深掘りガイド）

🛠 마지막 수정일: 2025.11.18

💡 お困りですか？
Zabbix、Kubernetes、各種オープンソースインフラの構築・運用・最適化・障害解析が必要であれば、いつでもご連絡ください。

📧 メール: jikimy75@gmail.com
💼 サービス: 導入支援 | 性能チューニング | 障害解析コンサルティング

코멘트

답글 남기기