新しい Kubernetes クラスター インフラストラクチャを計画しているのですが、いくつか質問があります。現在、環境 (開発、ステージング、本番) と複数のチームが作業している 1 つの大きなクラスターがあります。最初は、単なる「POC」、つまりデモでしたが、皆さんご存知のとおり、一時的な解決策ほど長く続くものはありません。このセットアップでは、一般的な問題がいくつかあり、目的のアーキテクチャでは、それらのトピックのいくつかを修正する予定です。
皆さんが知識や経験を共有していただければ幸いです。
まず第一に、アプリケーションごとに 1 つのクラスターは解決策ではありません。アプリケーションは非常に小さく、各チームには約 3 ～ 5 個のアプリケーションがあり、環境ごとにすべてのノードで約 6 ～ 20 GB の RAM が必要です。したがって、単一のクラスターは実際には選択肢ではありません。
環境ごとに 1 つのクラスターを計画しています。開発、ステージング (qa)、本番、そしておそらく運用用のデモ クラスターです。すべてが自動化され、Terraform + Ansible (kubespray) による IaC になります。当然のことながら、すべてのチーム/アプリケーション スコープには単一の名前空間が割り当てられます。
質問/問題:
監視 通常、Pod/クラスターのリソース使用状況を監視するために Prometheus と Grafana を使用します。New には中央ログも含まれる必要があります (現在ソリューションを試しています)。これはインフラ チームにとっては問題ありませんが、インフラはアプリケーション レベルで監視する必要はありません。
アプリ チームに監視機能を提供する実用的な方法はありますか? たとえば、アプリ チームは、ログ、CPU、RAM の使用状況など、必要なものに関するアラートを設定できます。「この Helm チャートを展開するだけです」。理想的な世界では、すべてのチーム (つまり、すべての名前空間) に独自の監視スタックを提供して、ストレージと RAM+CPU の使用量を制限し、すべてのチームが「順序付けられた」リソースを使用できるようにします (つまり、チームに多くのログ/監視ニーズがある場合は、より多くのリソースを「順序付け」する必要があります)。また、そのアプローチに基づいて、最適なソフトウェアを選択できます。
別の解決策としては、インフラ チームが中央監視/ログ ソリューションを設定し、アクセスを制限することが考えられます。App-Team A は、App-Team B のログ、CPU 使用量、RAM 使用量、ディスク使用量にアクセスできないようにする必要があります。しかし、これを本当にうまく行う方法は思いつきません。
インフラ チームがそのスタックをインストールするオプションもありますが、私が確認したところ、特定の名前空間に監視スタックをインストールする場合、スタックにはクラスターへの管理者アクセスが必要です。これは、私の意見では好ましくありません。
私が間違っている？
ストレージ Gluster ストレージがあり、それを維持したいと考えています。チームにディスクが必要な場合は、「team1-disk5」のような特定のサイズと storageClassName を持つ「glusterfs 永続ボリューム」を追加します。それに基づいて、チームは PVC を作成し、ストレージを使用できます。これまでは問題なく動作していました。
これは良い解決策でしょうか？ 他に何かアイデアはありますか？
今のところはこれですべてだと思います。質問はたった 2 つだけです。正しい方向に導くためのアイデアはありますか?
ありがとう！