すべてが実験的であり、いつでも大幅に変化する可能性があることに注意してください。
このリポジトリは、プロメテウスオペレーターを使用してプロメテウスを使用したエンドツーエンドのKubernetesクラスター監視を簡単に操作できるように、ドキュメントとスクリプトと組み合わせたKubernetesマニフェスト、Grafana Dashboards、およびPrometheusルールを収集します。
このプロジェクトのコンテンツは、jsonnetで書かれています。このプロジェクトは、ライブラリだけでなくパッケージとしても説明できます。
このパッケージに含まれるコンポーネント:
このスタックはクラスター監視専用であるため、すべてのKubernetesコンポーネントからメトリックを収集することが事前に構成されています。それに加えて、ダッシュボードのデフォルトセットとアラートルールを提供します。有用なダッシュボードとアラートの多くは、このプロジェクトと同様に、Kubernetes-Mixinプロジェクトから来ています。これは、ユーザーがニーズに合わせてカスタマイズするライブラリとしてComposable JSonnetを提供します。
Kubernetesクラスターが必要になります。デフォルトでは、Kubeletはトークン認証と承認を使用していると想定されています。そうしないと、Prometheusにはクライアント証明書が必要であり、メトリックではなくKubeletに完全にアクセスできます。トークン認証と承認により、より細かい粒度と簡単なアクセス制御が可能になります。
これは、kubelet構成にこれらのフラグを含める必要があることを意味します。
--authentication-token-webhook=trueこのフラグは、 ServiceAccountトークンを使用してkubeletに対して認証できることを可能にします。これは、Kubelet Configuration Value authentication.webhook.enabled trueに設定することで有効にすることもできます。--authorization-mode=Webhookこのフラグは、kubeletがAPIでRBAC要求を実行して、要求エンティティ(この場合はプロメテウス)がこのプロジェクトに固有/metricsリソースにアクセスできるかどうかを決定するかどうかを判断します。これは、Kubelet Configuration Value authorization.modeをWebhookに設定することで有効にすることもできます。このスタックは、Prometheusアダプターを展開することにより、リソースメトリックを提供します。このアダプターは拡張機能APIサーバーであり、Kubernetesをこの機能を有効にする必要があります。そうしないと、アダプターには効果がありませんが、引き続き展開されています。
次のKubernetesバージョンがサポートされており、それぞれのブランチのこれらのバージョンに対してテストする際に機能します。しかし、他のバージョンが機能する可能性があることに注意してください!
| Kube-Prometheusスタック | Kubernetes 1.23 | Kubernetes 1.24 | Kubernetes 1.25 | Kubernetes 1.26 | Kubernetes 1.27 | Kubernetes 1.28 | Kubernetes 1.29 | Kubernetes 1.30 | Kubernetes 1.31 |
|---|---|---|---|---|---|---|---|---|---|
release-0.11 | ✔ | ✔ | ✗ | x | x | x | x | x | x |
release-0.12 | ✗ | ✔ | ✔ | x | x | x | x | x | x |
release-0.13 | ✗ | ✗ | x | ✔ | ✔ | ✔ | x | x | x |
release-0.14 | ✗ | ✗ | x | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
main | ✗ | ✗ | x | x | ✔ | ✔ | ✔ | ✔ | ✔ |
このプロジェクトは、ライブラリとして使用することを目的としています(つまり、このリポジトリの独自の修正コピーを作成する意図はありません)。
クイックスタートの場合、このライブラリ(特にexample.jsonnetを使用して)で生成されたKubernetesマニフェストのコンパイルされたバージョンがこのリポジトリにチェックされ、迅速にコンテンツを試してみます。カスタマイズされていないスタックを試すには:
manifestsディレクトリの構成を使用して監視スタックを作成します。 # Create the namespace and CRDs, and then wait for them to be available before creating the remaining resources
# Note that due to some CRD size we are using kubectl server-side apply feature which is generally available since kubernetes 1.22.
# If you are using previous kubernetes versions this feature may not be available and you would need to use kubectl create instead.
kubectl apply --server-side -f manifests/setup
kubectl wait
--for condition=Established
--all CustomResourceDefinition
--namespace=monitoring
kubectl apply -f manifests/監視コンポーネントを展開する際のレース条件を回避するために、最初に名前空間とCustomResourcedefinitionsを作成します。あるいは、両方のフォルダーのリソースを単一のコマンドで適用することができますkubectl apply --server-side -f manifests/setup -f manifests 、すべてのコンポーネントが正常に作成されるためにコマンドを複数回実行する必要がある場合があります。
kubectl delete --ignore-not-found=true -f manifests/ -f manifests/setupこのスタックを試してみるには、次のコマンドでminikubeを開始します。
$ minikube delete && minikube start --kubernetes-version=v1.23.0 --memory=6g --bootstrapper=kubeadm --extra-config=kubelet.authentication-token-webhook=true --extra-config=kubelet.authorization-mode=Webhook --extra-config=scheduler.bind-address=0.0.0.0 --extra-config=controller-manager.bind-address=0.0.0.0Kube-PrometheusスタックにはリソースメトリックAPIサーバーが含まれているため、メトリックサーバーアドオンは必要ありません。 MinikubeでMetrics-Serverアドオンが無効になっていることを確認してください。
$ minikube addons disable metrics-server生産環境にKube-Prometheusを展開する前に、次のことを読んでください。
docs/ディレクトリを参照してください。 Kube-Prometheusに貢献するには、貢献を参照してください。
Kube-Prometheusに関する質問やフィードバックがある場合は、Kube-Prometheusのディスカッションに参加してください。または、Kubernetes Slack#Prometheus-Operator ChannelまたはProjectの隔週の寄稿者の営業時間に参加することを検討してください。
Apacheライセンス2.0、ライセンスを参照してください。