手動でプログラムをインストール - アリのクラウドソリューションを(デプロイメントが失敗しました):
https://www.jianshu.com/p/1c7ddf18e8b2
手動でプログラムのインストール - (成功した展開が、唯一のCPUメモリおよびその他の監視情報を、何の監視情報GPUのはありません):
https://github.com/camilb/prometheus-kubernetes/tree/master
ヘルムインストールプログラム--GPU - モニタリング・ツール・ソリューション(導入成功):
参考ます。http://fly-luck.github.io/2018/12/10/gpu-monitoring-tools%20Prometheus/
对应githubのします。https://github.com/NVIDIA/gpu-monitoring-tools/tree/helm-charts
- GPU-監視ツール(以下、GMTと呼ばれる)プログラムのメトリック取得いくつかのセットを含みます。
- NVMLゴーバインディング(CのAPI)。
- DCGM輸出国(DCGM上プロメテウスメトリクス)。
- GMTの監視フレームワークプログラムのいくつかのセットを提供します。
- プロメテウスDaemonSet DCGM輸出、のみ収集と監視を直接使用します。
- 完全取得、モニタリング、アラーム、および他のグラフィカル要素を含むプロメテウスオペレータ(のNvidiaによって修飾)+ KUBE-プロメテウス、。
私たちは、監視フレームワークプログラムの第2のセットを使用して、このプログラムの機能はまだGPUマシンのCPUのために有効です。
証明、このプログラムは(等CPU、GPU、メモリ、ディスク、)ハードウェアをホスト同時に監視することができ、KubernetesにKubernetesコアコンポーネント(apiserver、コントローラマネージャ、スケジューラ、等)だけでなく、ビジネスサービスは、動作を実行します。
オペレータは何ですか
- ステートレスアプリケーションでは、リソース(例えば展開)ネイティブKubernetesはよくサポート自動スケーリング、自動再起動やアップグレードを受けます。
- そのようなデータベース、キャッシュ、モニタリング・システム、特定の用途に応じて異なる操作及びメンテナンス作業の必要性などのステートフル・アプリケーションのため。
- ユーザーが作成、構成、アプリケーションを管理することができ、サードパーティのリソースによって拡張オペレータ特定のアプリケーションのためのソフトウェア・パッケージへの運用・保守業務、およびKubernetes APIは、一般的にCRD一連のKubernetesコレクションが含まれています。
- 同様のリソースコントローラとKubernetesの対応関係は、オペレータコントローラは、ユーザに提示する要求に応じて、インスタンスの実際の数とインスタンスの状態は、ユーザが所望するが、パッケージの操作の詳細の多くと同様の効果に維持されます。
事前準備
ミラーリング
クラスタのすべてのノードにインポートし、次の画像:
1 |
#あなたは、元のkubernetesは、リソースを作成するために2つのミラーを使用して、プロメテウスを構築するが、唯一の指標を得ることができ、何のドッキングアラーム監視を使用する場合 |
ヘルムテンプレート
舵次のテンプレートをダウンロードし、解凍します。
1 |
wgetのhttps://nvidia.github.io/gpu-monitoring-tools/helm-charts/kube-prometheus-0.0.43.tgz |
インストール手順
1.設定
ノードラベル
ラベルの付いたGPUノードの監視の必要性。
1 |
kubectlラベルなし<ノード名>ハードウェア型= NVIDIAGPU |
外因性etcd
etcd開始前etcd外因性、すなわち、方法ではないetcd Kubernetesクラスタの初期化を開始すると、容器が、クラスタ外、etcdのクラスタのアドレスを指定する必要があります。
外因性は、HTTPを使用してIP etcd0、etcd1、etcd2、外部アクセスポート2379、直接アクセスとしetcd。
1 |
VimのKUBE-プロメテウス/チャート/輸出-KUBE-etcd / values.yaml |
1 |
#etcdPort:4001 |
一方、グラフのデータgrafanaを挿入する必要が、注意してください:
- 465で行を追加します「」
- ライン465の前
"title": "Crashlooping Control Plane Pods"
パネル。 - インデントを維持するために465に次の行を追加します。
1
VimのKUBE-プロメテウス/チャート/ grafana /ダッシュボード/ kubernetes-クラスタのステータス-dashboard.json
1 |
{ |
暴露端口
暴露prometheus、alertmanager、grafana的访问端口,以备排障。这些端口需要能从开发VPC直接访问。
1 |
vim kube-prometheus/values.yaml |
1 |
alertmanager: |
1 |
vim kube-prometheus/charts/grafana/values.yaml |
1 |
service: |
告警接收器
配置告警接收器,通常我们选择在同一个集群内的ControlCenter Service来接收,并将告警信息转换格式后转发给IMS。
1 |
vim kube-prometheus/values.yaml |
1 |
alertmanager: |
告警规则
平台监控包括Node硬件(CPU、内存、磁盘、网络、GPU)、K8s组件(Kube-Controller-Manager、Kube-Scheduler、Kubelet、API Server)、K8s应用(Deployment、StatefulSet、Pod)等。
由于篇幅较长,因此将监控告警规则放在附录。
2. 启动
1 |
cd prometheus-operator |
1 |
cd kube-prometheus |
3. 清理
1 |
helm delete --purge kube-prometheus |
1 |
helm delete --purge prometheus-operator |
常见问题
无法暴露Kubelet metrics
在1.13.0版本的kubernetes未出现此问题。
- 对于1.13.0之前的版本,需将获取kubelet metrics的方式由https改为http,否则Prometheus的kubelet targets将down掉。[github issue 926]
1
vim kube-prometheus/charts/exporter-kubelets/templates/servicemonitor.yaml
1 |
spec: |
- 验证
在Prometheus页面可以看到kubelet target。
无法暴露controller-manager及scheduler的metrics
方法一
针对Kubernetes v1.13.0。
-
将下述内容添加到kubeadm.conf,并在kubeadm初始化时kubeadm init –config kubeadm.conf。
1
2
3
4
5
6
7
8
9
10apiVersion: kubeadm.k8s.io/v1alpha3
kind: ClusterConfiguration
kubernetesVersion: 1.13.0
networking:
podSubnet: 10.244.0.0/16
controllerManagerExtraArgs:
address: 0.0.0.0
schedulerExtraArgs:
address: 0.0.0.0
... -
为pod打上label。
1
2
3
4kubectl get po -n kube-system
kubectl -n kube-system label po kube-controller-manager-<nodename> k8s-app=kube-controller-manager
kubectl -n kube-system label po kube-scheduler-<nodename> k8s-app=kube-scheduler
kubectl get po -n kube-system --show-labels -
验证
在Prometheus页面可以看到kube-controller-manager及kube-scheduler两个target。
在grafana页面可以看到controller-manager及scheduler的状态监控。
方法二
guide
针对1.13.0之前的Kubernetes。
- 修改kubeadm的核心配置。
1
kubeadm config view
将上述输出保存为newConfig.yaml,并添加以下两行:
1 |
controllerManagerExtraArgs: |
应用新配置:
1 |
kubeadm config upload from-file --config newConfig.yaml |
-
为pod打上label。
1
2
3
4kubectl get po -n kube-system
kubectl label po kube-controller-manager-<nodename> k8s-app=kube-controller-manager
kubectl label po kube-scheduler-<nodename> k8s-app=kube-scheduler
kubectl get po -n kube-system --show-labels -
重建exporters。
1
kubectl -n kube-system get svc
可以看到以下两个没有CLUSTER-IP的Service:
1 |
kube-prometheus-exporter-kube-controller-manager |
1 |
kubectl -n kube-system get svc kube-prometheus-exporter-kube-controller-manager -o yaml |
将上述输出分别保存为newKubeControllerManagerSvc.yaml和newKubeSchedulerSvc.yaml,删除一些非必要信息(如uid、selfLink、resourceVersion、creationTimestamp等)后重建。
1 |
kubectl delete -n kube-system svc kube-prometheus-exporter-kube-controller-manager kube-prometheus-exporter-kube-scheduler |
-
确保Prometheus pod到kube-controller-manager和kube-scheduler的NodePort 10251/10252的访问是通畅的。
-
验证与方法一相同。
无法暴露coredns
在Kubernetes v1.13.0中,集群DNS组件默认为coredns,因此需修改kube-prometheus的配置,才能监控到DNS服务的状态。
方法一
- 修改配置中的selectorLabel值与coredns的pod标签对应。
1
2
3kubectl -n kube-system get po --show-labels | grep coredns
# 输出
coredns k8s-app=kube-dns
1 |
vim kube-prometheus/charts/exporter-coredns/values.yaml |
1 |
#selectorLabel: coredns |
-
重启kube-prometheus。
1
2helm delete --purge kube-prometheus
helm install --name kube-prometheus --namespace monitoring kube-prometheus -
验证
在Prometheus可以看到kube-dns target。
方法二
-
修改pod的标签与配置中的一致。
1
kubectl -n kube-system label po
-
验证与方法一相同。
部署成功后需要使用port-forward才能访问到grafana面板,可视化看到监控效果:
https://blog.csdn.net/aixiaoyang168/article/details/81661459