Prometheus Operator高度な構成Prometheus Operator自動検出およびデータ永続化
12041 ワード
前回のレッスンでは、Prometheus Operatorの下でモニタリングオプションをカスタマイズし、アラームルールの使用をカスタマイズする方法について説明しました.では、前のレッスンの自動発見機能を直接使用することもできますか?我々のKubernetesクラスタに多くのServices/PODが存在する場合、監視のために対応するServiceMonitorオブジェクトを1つずつ確立する必要がありますか?これでまた面倒になったのではないでしょうか.
自動検出構成
上記の問題を解決するために、Prometheus Operatorはこの問題を解決するために追加のスナップ構成を提供し、追加の構成を追加することでサービス発見を自動監視することができます.前述のカスタマイズと同様に、Prometheus Operatorで
上記の構成に慣れていない場合は、Kubernetesの一般的なリソースオブジェクトモニタリングに関する前述の章の紹介を参照することをお勧めします.クラスタ内のサービスを自動的に発見するには、サービスの
すべての操作はPrometheus Operatorソース
作成が完了すると、上記の構成情報をbase 64符号化してprometheus-additionalとする.yamlというkeyに対応する値は存在します.
次に、prometheusを宣言するリソースオブジェクトファイルにこの追加の構成を追加するだけです:(prometheus-prometheus.yaml)
追加が完了したら、prometheusというCRDリソースオブジェクトを直接更新します.
しばらくして、PrometheusのDashboardで構成が有効かどうかを確認できます.
Prometheus Dashboardの構成ページの下には、すでに対応する構成情報が表示されていますが、targetsページの下に切り替えても、対応する監視タスクは見つかりません.PrometheusのPodログを表示します.
多くのエラー・ログが表示されます.
上記の権限ルールでは、サービスまたはPodに対するlist権限が明らかにないことがわかります.そのため、エラーが発生しました.この問題を解決するには、必要な権限を追加するだけです.
上のClusterRoleというリソースオブジェクトを更新し、PrometheusのすべてのPodを再構築すると、targetsページの下にkubernetes-service-endpointsという監視タスクが表示されます.
ここでは2つのサービスを自動的に監視しています.1つ目は、以前に作成したRedisのサービスです.Redisサービスには2つの特殊なannotationsがあります.
したがって、自動的に発見され、もちろんPod、Ingressなどのリソースオブジェクトの自動発見を同様に構成することもできます.
データ持続性
上記の権限を変更したとき、PrometheusのPodを再起動しました.よく観察すると、prometheusというCRDで作成したPrometheusはデータの持続化をしていないので、生成したPrometheus Podのマウント状況を直接見ることができます.
Prometheusのデータディレクトリ/prometheusは実際にemptyDirによってマウントされていることがわかります.emptyDirにマウントされているデータのライフサイクルはPodのライフサイクルと一致していることを知っています.だから、Podがマウントされたら、データも失われます.これは、私たちがPodを再構築する前のデータがなくなった理由です.対応ライン上のモニタリングデータは必ずデータの持続化を行う必要があります.同じprometheusというCRDリソースもデータの持続化の構成方法を提供しています.私たちのPrometheusは最終的にStatefulsetコントローラを通じて配置されるので、storageclassを通じてデータの持続化を行う必要があります.まずStorageClassオブジェクトを作成します.
ここでは、provisioner=fuseimのStorageClassオブジェクトを宣言します.pri/ifsは、ストレージバックエンドとしてnfsを使用しているため、前のレッスンで作成したnfs-client-provisionerで指定したPROVISIONER_NAMEはfuseimです.pri/ifs、この名前は勝手に変更することはできません.このファイルをprometheus-storageclassとして保存します.yaml:
次に、prometheusのCRDリソースオブジェクトに次の構成を追加します.
ここのstorageClassNameの名前は、上に作成したStorageClassオブジェクトの名前であり、prometheusというCRDリソースを更新します.更新が完了すると、2つのPVCとPVリソースオブジェクトが自動的に生成されます.
Prometheus Podのデータディレクトリを見ると、PVCオブジェクトに関連付けられていることがわかります.
今、私たちのPodが切れても、データは失われません.最後に、以下は私たちのPrometheus Operatorシリーズの授業で最終的にリソースリストファイルを作成し、より多くの情報をhttps://github.com/cnych/kubernetes-learning以下を参照してください.
ここまでPrometheus Operatorシリーズのチュートリアルは一段落しましたが、微信群の中で何か問題があったら、Kubernetesログの収集に便利な知識点を紹介します.
自動検出構成
上記の問題を解決するために、Prometheus Operatorはこの問題を解決するために追加のスナップ構成を提供し、追加の構成を追加することでサービス発見を自動監視することができます.前述のカスタマイズと同様に、Prometheus Operatorで
prometheus.io/scrape=trueというannotationsを持つサービスを自動的に発見し、監視したいと考えています.これまで定義したPrometheusの構成は次のとおりです.- job_name: 'kubernetes-service-endpoints'
kubernetes_sd_configs:
- role: endpoints
relabel_configs:
- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape]
action: keep
regex: true
- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scheme]
action: replace
target_label: __scheme__
regex: (https?)
- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_path]
action: replace
target_label: __metrics_path__
regex: (.+)
- source_labels: [__address__, __meta_kubernetes_service_annotation_prometheus_io_port]
action: replace
target_label: __address__
regex: ([^:]+)(?::\d+)?;(\d+)
replacement: $1:$2
- action: labelmap
regex: __meta_kubernetes_service_label_(.+)
- source_labels: [__meta_kubernetes_namespace]
action: replace
target_label: kubernetes_namespace
- source_labels: [__meta_kubernetes_service_name]
action: replace
target_label: kubernetes_name
上記の構成に慣れていない場合は、Kubernetesの一般的なリソースオブジェクトモニタリングに関する前述の章の紹介を参照することをお勧めします.クラスタ内のサービスを自動的に発見するには、サービスの
annotation領域にprometheus.io/scrape=trueの声明を追加し、上記のファイルをprometheus-additionalに直接保存する必要があります.yamlを使用して、このファイルから対応するSecretオブジェクトを作成します.$ kubectl create secret generic additional-configs --from-file=prometheus-additional.yaml -n monitoring
secret "additional-configs" created
すべての操作はPrometheus Operatorソース
contrib/kube-prometheus/manifests/ディレクトリの下にあることに注意してください.作成が完了すると、上記の構成情報をbase 64符号化してprometheus-additionalとする.yamlというkeyに対応する値は存在します.
$ kubectl get secret additional-configs -n monitoring -o yaml
apiVersion: v1
data:
prometheus-additional.yaml: LSBqb2JfbmFtZTogJ2t1YmVybmV0ZXMtc2VydmljZS1lbmRwb2ludHMnCiAga3ViZXJuZXRlc19zZF9jb25maWdzOgogIC0gcm9sZTogZW5kcG9pbnRzCiAgcmVsYWJlbF9jb25maWdzOgogIC0gc291cmNlX2xhYmVsczogW19fbWV0YV9rdWJlcm5ldGVzX3NlcnZpY2VfYW5ub3RhdGlvbl9wcm9tZXRoZXVzX2lvX3NjcmFwZV0KICAgIGFjdGlvbjoga2VlcAogICAgcmVnZXg6IHRydWUKICAtIHNvdXJjZV9sYWJlbHM6IFtfX21ldGFfa3ViZXJuZXRlc19zZXJ2aWNlX2Fubm90YXRpb25fcHJvbWV0aGV1c19pb19zY2hlbWVdCiAgICBhY3Rpb246IHJlcGxhY2UKICAgIHRhcmdldF9sYWJlbDogX19zY2hlbWVfXwogICAgcmVnZXg6IChodHRwcz8pCiAgLSBzb3VyY2VfbGFiZWxzOiBbX19tZXRhX2t1YmVybmV0ZXNfc2VydmljZV9hbm5vdGF0aW9uX3Byb21ldGhldXNfaW9fcGF0aF0KICAgIGFjdGlvbjogcmVwbGFjZQogICAgdGFyZ2V0X2xhYmVsOiBfX21ldHJpY3NfcGF0aF9fCiAgICByZWdleDogKC4rKQogIC0gc291cmNlX2xhYmVsczogW19fYWRkcmVzc19fLCBfX21ldGFfa3ViZXJuZXRlc19zZXJ2aWNlX2Fubm90YXRpb25fcHJvbWV0aGV1c19pb19wb3J0XQogICAgYWN0aW9uOiByZXBsYWNlCiAgICB0YXJnZXRfbGFiZWw6IF9fYWRkcmVzc19fCiAgICByZWdleDogKFteOl0rKSg/OjpcZCspPzsoXGQrKQogICAgcmVwbGFjZW1lbnQ6ICQxOiQyCiAgLSBhY3Rpb246IGxhYmVsbWFwCiAgICByZWdleDogX19tZXRhX2t1YmVybmV0ZXNfc2VydmljZV9sYWJlbF8oLispCiAgLSBzb3VyY2VfbGFiZWxzOiBbX19tZXRhX2t1YmVybmV0ZXNfbmFtZXNwYWNlXQogICAgYWN0aW9uOiByZXBsYWNlCiAgICB0YXJnZXRfbGFiZWw6IGt1YmVybmV0ZXNfbmFtZXNwYWNlCiAgLSBzb3VyY2VfbGFiZWxzOiBbX19tZXRhX2t1YmVybmV0ZXNfc2VydmljZV9uYW1lXQogICAgYWN0aW9uOiByZXBsYWNlCiAgICB0YXJnZXRfbGFiZWw6IGt1YmVybmV0ZXNfbmFtZQo=
kind: Secret
metadata:
creationTimestamp: 2018-12-20T14:50:35Z
name: additional-configs
namespace: monitoring
resourceVersion: "41814998"
selfLink: /api/v1/namespaces/monitoring/secrets/additional-configs
uid: 9bbe22c5-0466-11e9-a777-525400db4df7
type: Opaque
次に、prometheusを宣言するリソースオブジェクトファイルにこの追加の構成を追加するだけです:(prometheus-prometheus.yaml)
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
labels:
prometheus: k8s
name: k8s
namespace: monitoring
spec:
alerting:
alertmanagers:
- name: alertmanager-main
namespace: monitoring
port: web
baseImage: quay.io/prometheus/prometheus
nodeSelector:
beta.kubernetes.io/os: linux
replicas: 2
secrets:
- etcd-certs
resources:
requests:
memory: 400Mi
ruleSelector:
matchLabels:
prometheus: k8s
role: alert-rules
securityContext:
fsGroup: 2000
runAsNonRoot: true
runAsUser: 1000
additionalScrapeConfigs:
name: additional-configs
key: prometheus-additional.yaml
serviceAccountName: prometheus-k8s
serviceMonitorNamespaceSelector: {}
serviceMonitorSelector: {}
version: v2.5.0
追加が完了したら、prometheusというCRDリソースオブジェクトを直接更新します.
$ kubectl apply -f prometheus-prometheus.yaml
prometheus.monitoring.coreos.com "k8s" configured
しばらくして、PrometheusのDashboardで構成が有効かどうかを確認できます.
Prometheus Dashboardの構成ページの下には、すでに対応する構成情報が表示されていますが、targetsページの下に切り替えても、対応する監視タスクは見つかりません.PrometheusのPodログを表示します.
$ kubectl logs -f prometheus-k8s-0 prometheus -n monitoring
level=error ts=2018-12-20T15:14:06.772903214Z caller=main.go:240 component=k8s_client_runtime err="github.com/prometheus/prometheus/discovery/kubernetes/kubernetes.go:302: Failed to list *v1.Pod: pods is forbidden: User \"system:serviceaccount:monitoring:prometheus-k8s\" cannot list pods at the cluster scope"
level=error ts=2018-12-20T15:14:06.773096875Z caller=main.go:240 component=k8s_client_runtime err="github.com/prometheus/prometheus/discovery/kubernetes/kubernetes.go:301: Failed to list *v1.Service: services is forbidden: User \"system:serviceaccount:monitoring:prometheus-k8s\" cannot list services at the cluster scope"
level=error ts=2018-12-20T15:14:06.773212629Z caller=main.go:240 component=k8s_client_runtime err="github.com/prometheus/prometheus/discovery/kubernetes/kubernetes.go:300: Failed to list *v1.Endpoints: endpoints is forbidden: User \"system:serviceaccount:monitoring:prometheus-k8s\" cannot list endpoints at the cluster scope"
......
多くのエラー・ログが表示されます.
xxx is forbiddenです.これはRBAC権限の問題です.prometheusリソース・オブジェクトの構成により、prometheusがprometheus-k 8 sというServiceAccountオブジェクトをバインドしていることがわかります.このオブジェクトはprometheus-k 8 sというClusterRole:(prometheus-clusterRole.yaml)をバインドしています.apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: prometheus-k8s
rules:
- apiGroups:
- ""
resources:
- nodes/metrics
verbs:
- get
- nonResourceURLs:
- /metrics
verbs:
- get
上記の権限ルールでは、サービスまたはPodに対するlist権限が明らかにないことがわかります.そのため、エラーが発生しました.この問題を解決するには、必要な権限を追加するだけです.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: prometheus-k8s
rules:
- apiGroups:
- ""
resources:
- nodes
- services
- endpoints
- pods
- nodes/proxy
verbs:
- get
- list
- watch
- apiGroups:
- ""
resources:
- configmaps
- nodes/metrics
verbs:
- get
- nonResourceURLs:
- /metrics
verbs:
- get
上のClusterRoleというリソースオブジェクトを更新し、PrometheusのすべてのPodを再構築すると、targetsページの下にkubernetes-service-endpointsという監視タスクが表示されます.
ここでは2つのサービスを自動的に監視しています.1つ目は、以前に作成したRedisのサービスです.Redisサービスには2つの特殊なannotationsがあります.
annotations:
prometheus.io/scrape: "true"
prometheus.io/port: "9121"
したがって、自動的に発見され、もちろんPod、Ingressなどのリソースオブジェクトの自動発見を同様に構成することもできます.
データ持続性
上記の権限を変更したとき、PrometheusのPodを再起動しました.よく観察すると、prometheusというCRDで作成したPrometheusはデータの持続化をしていないので、生成したPrometheus Podのマウント状況を直接見ることができます.
$ kubectl get pod prometheus-k8s-0 -n monitoring -o yaml
......
volumeMounts:
- mountPath: /etc/prometheus/config_out
name: config-out
readOnly: true
- mountPath: /prometheus
name: prometheus-k8s-db
......
volumes:
......
- emptyDir: {}
name: prometheus-k8s-db
......
Prometheusのデータディレクトリ/prometheusは実際にemptyDirによってマウントされていることがわかります.emptyDirにマウントされているデータのライフサイクルはPodのライフサイクルと一致していることを知っています.だから、Podがマウントされたら、データも失われます.これは、私たちがPodを再構築する前のデータがなくなった理由です.対応ライン上のモニタリングデータは必ずデータの持続化を行う必要があります.同じprometheusというCRDリソースもデータの持続化の構成方法を提供しています.私たちのPrometheusは最終的にStatefulsetコントローラを通じて配置されるので、storageclassを通じてデータの持続化を行う必要があります.まずStorageClassオブジェクトを作成します.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: prometheus-data-db
provisioner: fuseim.pri/ifs
ここでは、provisioner=fuseimのStorageClassオブジェクトを宣言します.pri/ifsは、ストレージバックエンドとしてnfsを使用しているため、前のレッスンで作成したnfs-client-provisionerで指定したPROVISIONER_NAMEはfuseimです.pri/ifs、この名前は勝手に変更することはできません.このファイルをprometheus-storageclassとして保存します.yaml:
$ kubectl create -f prometheus-storageclass.yaml
storageclass.storage.k8s.io "prometheus-data-db" created
次に、prometheusのCRDリソースオブジェクトに次の構成を追加します.
storage:
volumeClaimTemplate:
spec:
storageClassName: prometheus-data-db
resources:
requests:
storage: 10Gi
ここのstorageClassNameの名前は、上に作成したStorageClassオブジェクトの名前であり、prometheusというCRDリソースを更新します.更新が完了すると、2つのPVCとPVリソースオブジェクトが自動的に生成されます.
$ kubectl get pvc -n monitoring
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
prometheus-k8s-db-prometheus-k8s-0 Bound pvc-0cc03d41-047a-11e9-a777-525400db4df7 10Gi RWO prometheus-data-db 8m
prometheus-k8s-db-prometheus-k8s-1 Bound pvc-1938de6b-047b-11e9-a777-525400db4df7 10Gi RWO prometheus-data-db 1m
$ kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-0cc03d41-047a-11e9-a777-525400db4df7 10Gi RWO Delete Bound monitoring/prometheus-k8s-db-prometheus-k8s-0 prometheus-data-db 2m
pvc-1938de6b-047b-11e9-a777-525400db4df7 10Gi RWO Delete Bound monitoring/prometheus-k8s-db-prometheus-k8s-1 prometheus-data-db 1m
Prometheus Podのデータディレクトリを見ると、PVCオブジェクトに関連付けられていることがわかります.
$ kubectl get pod prometheus-k8s-0 -n monitoring -o yaml
......
volumeMounts:
- mountPath: /etc/prometheus/config_out
name: config-out
readOnly: true
- mountPath: /prometheus
name: prometheus-k8s-db
......
volumes:
......
- name: prometheus-k8s-db
persistentVolumeClaim:
claimName: prometheus-k8s-db-prometheus-k8s-0
......
今、私たちのPodが切れても、データは失われません.最後に、以下は私たちのPrometheus Operatorシリーズの授業で最終的にリソースリストファイルを作成し、より多くの情報をhttps://github.com/cnych/kubernetes-learning以下を参照してください.
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
labels:
prometheus: k8s
name: k8s
namespace: monitoring
spec:
alerting:
alertmanagers:
- name: alertmanager-main
namespace: monitoring
port: web
storage:
volumeClaimTemplate:
spec:
storageClassName: prometheus-data-db
resources:
requests:
storage: 10Gi
baseImage: quay.io/prometheus/prometheus
nodeSelector:
beta.kubernetes.io/os: linux
replicas: 2
secrets:
- etcd-certs
additionalScrapeConfigs:
name: additional-configs
key: prometheus-additional.yaml
resources:
requests:
memory: 400Mi
ruleSelector:
matchLabels:
prometheus: k8s
role: alert-rules
securityContext:
fsGroup: 2000
runAsNonRoot: true
runAsUser: 1000
serviceAccountName: prometheus-k8s
serviceMonitorNamespaceSelector: {}
serviceMonitorSelector: {}
version: v2.5.0
ここまでPrometheus Operatorシリーズのチュートリアルは一段落しましたが、微信群の中で何か問題があったら、Kubernetesログの収集に便利な知識点を紹介します.