ArgoCDを利用したkube-prometheus-stack(prometheus+grafana)監視


前提事項

kindを利用したセットアップは記載を省略する。
下記参照

サンプル:kube-prometheus-stackのデプロイ

kubernetes-dashboardのデプロイ手順※と同様に、下記マニフェストと同じになるように各項目をGUIで設定するか、
kubectl applyでデプロイを行う。

※:https://qiita.com/KO_YAmajun/items/dc24e03275eab7e3f9af#%E3%82%B5%E3%83%B3%E3%83%97%E3%83%ABkubernetes-dashboard%E3%81%AE%E3%83%87%E3%83%97%E3%83%AD%E3%82%A4

kube-prometheus-stack.yaml
project: default
source:
  repoURL: 'https://prometheus-community.github.io/helm-charts'
  targetRevision: 16.11.0
  helm:
    valueFiles:
      - values.yaml
    parameters:
      - name: prometheusOperator.admissionWebhooks.failurePolicy
        value: Ignore
  chart: kube-prometheus-stack
destination:
  server: 'https://kubernetes.default.svc'
  namespace: prometheus-community
syncPolicy:
  syncOptions:
    - CreateNamespace=true

ポートフォワーディング

argoCDの記事で実行したのと同様に、ポートフォワーディングすればよい。
grafanaのデフォルトポートは3000であるが、下記の通りサービスポートは80なので、
argoCDのポートフォワーディング手順を置き換えて18080:80の転送を行う。
https://qiita.com/KO_YAmajun/items/dc24e03275eab7e3f9af#argocd-ui%E6%8E%A5%E7%B6%9A

接続

PS C:\Users\aruki\Desktop\dev\kind\dashboard> kubectl get svc -A
NAMESPACE              NAME                                                TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                        AGE
argocd                 argocd-server                                       LoadBalancer   10.96.98.229    <pending>     80:31078/TCP,443:30231/TCP     3h23m
prometheus-stack       prometheus-community-grafana                        ClusterIP      10.96.247.200   <none>        80/TCP                         102m

結果、想定通り3000ポートに転送される

kubectl port-forward svc/kube-prometheus-stack-grafana -n prometheus-community 18080:80
#>Forwarding from 127.0.0.1:18080 -> 3000
#>Forwarding from [::1]:18080 -> 3000

grafanaログイン

ID:admin
Password:prom-operator

結果、想定通りPrometheusを通じて各リソースのメトリクスが取得できている。



なお、インスタンスIPは、INTERNAL-IPと一致する。

kubectl get nodes -o wide
#>NAME                 STATUS   ROLES                  AGE     VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE       #>KERNEL-VERSION                   CONTAINER-RUNTIME
#>kind-control-plane   Ready    control-plane,master   3h35m   v1.21.1   172.18.0.7    <none>        Ubuntu 21.04  5.4.72-microsoft-standard-WSL2   containerd://1.5.2
#>kind-worker          Ready    <none>                 3h35m   v1.21.1   172.18.0.4    <none>        Ubuntu 21.04  5.4.72-microsoft-standard-WSL2   containerd://1.5.2
#>kind-worker2         Ready    <none>                 3h35m   v1.21.1   172.18.0.3    <none>        Ubuntu 21.04  5.4.72-microsoft-standard-WSL2   containerd://1.5.2
#>kind-worker3         Ready    <none>                 3h35m   v1.21.1   172.18.0.6    <none>        Ubuntu 21.04  5.4.72-microsoft-standard-WSL2   containerd://1.5.2
#>kind-worker4         Ready    <none>                 3h35m   v1.21.1   172.18.0.5    <none>        Ubuntu 21.04  5.4.72-microsoft-standard-WSL2   containerd://1.5.2
#>kind-worker5         Ready    <none>                 3h35m   v1.21.1   172.18.0.2    <none>        Ubuntu 21.04  5.4.72-microsoft-standard-WSL2   containerd://1.5.2

余談:kind環境下で、kubernetesに関係しないリソースを使用した場合でも、
nodesのmemory usageは、上昇する。インスタンスが属するハードウェアの実態を取得している模様。