Google Cloudとコンテナの継続的なセキュリティ
本文の内容は、2020年7月9日にCarlos Arillaが投稿したブログ(https://sysdig.com/blog/monitoring-kubernetes/)を元に日本語に翻訳・再構成した内容となっております。
Kubernetesのモニタリングは、インフラストラクチャープラットフォームとワークロードを実行させる両方です。ゼロデイを超えて本番環境に移行するときに、全員のチェックリストに含まれています。従来の監視ツールとプロセスは、動的なコンテナ環境の可視性が提供されないため、適切ではありません。このため、Kubernetesとアプリケーションを監視するためにどのツールを使用できるのでしょうか？
Kubernetesは、コンテナエコシステムに嵐を巻き起こしました。Kubernetesは、分散コンテナデプロイメントの頭脳として機能します。ホストのクラスター全体に分散されたコンテナを使用してサービス指向アプリケーションを管理するように設計されています。Kubernetesは、アプリケーションのデプロイ、スケジューリング、アップデート、サービス検出、スケーリングのためのメカニズムを提供します。しかし、Kubernetesの監視についてはどうでしょうか？
Kubernetesは、アプリケーションをコンテナ内およびクラウド全体にデプロイする作業を劇的に簡素化する可能性がありますが、日々のタスク、アプリケーションパフォーマンスの管理、サービスの可視化、および一般的な作業である、監視->警告->トラブルシューティングワークフローに新しい一連の複雑さが増加します。
静的ターゲットからメトリクスを収集するレガシー監視ツールは、名前を付けることができるサーバーと一晩で変更されないサービスを監視するために構築されており、過去にはうまく機能しましたが、今日はうまく機能しません。これが、これらのツールがKubernetesの監視に失敗する理由です。
アプリケーションのデプロイメントを簡素化することを期待して、インフラストラクチャーの複雑さの新しい層が現れています。：IaaSによる動的プロビジョニング、構成管理ツールによる自動構成、最近では、ベアメタルまたは仮想インフラストラクチャーとアプリケーションを強化するサービスの間に位置するKubernetesなどのオーケストレーションプラットフォーム。これが、コントロールプレーンでのKubernetesの正常性の監視が仕事の一部である理由です。
インフラストラクチャーの複雑さが増すことに加えて、相互に通信するコンポーネントの数が桁違いに増加するマイクロサービス用に新しいアプリケーションが設計されています。各サービスは複数のインスタンスに分散でき、コンテナは必要に応じてインフラストラクチャー全体を移動します。これが、Kubernetesがその役割を果たしているかどうかを理解するために、Kubernetesオーケストレーションの状態を監視することが重要な理由です。信頼しますが、サービスのすべてのインスタンスが稼働中であることを確認します。
私たちはクラウドネイティブアーキテクチャを採用していますが、それらがもたらす変更により、より小さなコンポーネントの量が増えています。これはKubernetesモニタリングの方法論とツールにどのように影響するのでしょうか？サイト信頼性エンジニアリング- Googleによる本稼働システムの実行方法で説明されているように、「高レベルのサービス目標をアラートできるようにする一方で、必要に応じて個々のコンポーネントを検査するための細分性を維持できる監視システムが必要です。」
メトリクスの数は爆発的に増加し、従来の監視システムでは対応できません。以前は各サービスコンポーネントのインスタンスの数とそれらの場所がわかっていましたが、現在はそうではありません。現在、メトリクスのカーディナリティは高くなっています。 Kubernetesは、クラスター、ノード、ネームスペース、サービスなどのいくつかの多次元レベルを追加するため、コントロールが必要なさまざまな集約またはパースペクティブが爆発する可能性があります。：マイクロサービスの論理グループから、アプリケーションのバージョン、APIエンドポイント、特定のリソースまたはアクションなどの属性を表す多くのラベル。
そして、コンテナは永遠に持続しません。最新のコンテナ使用状況レポートでは、コンテナの22％が10秒以下の寿命であり、54％が5分未満の寿命であることがわかりました。これにより、チャーンのレベルが高くなります。コンテナIDやポッド名などのラベルは常に変更されるため、新しいラベルを処理する必要がある間、ラベルが表示されなくなります。
次に、メトリクス名とラベルのすべての組み合わせを、実際の値とタイムスタンプとともに取得します。短期間には数千のデータポイントがあり、小さなサイズのKubernetesクラスターでも数十万の時系列が生成されます。これは、中規模のインフラストラクチャーでは数百万になる可能性があります。これが、Kubernetesモニタリングツールが数十万のメトリクスにスケーリングする準備ができている必要がある理由です。
コンテナは短命です。つまり、コンテナが死ぬと、中身はすべてなくなります。SSHを使用したり、ログを確認したりすることはできません。トラブルシューティングに使用するツールのほとんどはインストールされていません。アプリケーションをパッケージ化して分離し、どこにでも一貫した方法でデプロイできるので、運用に最適ですが、同時に、トラブルシューティングが困難なブラックボックスになります。このため、システムコールトレースを通じて詳細な可視性を提供する監視ツールを使用すると、コンテナ内で発生したすべてのプロセス、ファイル、またはネットワーク接続を確認して、問題をより迅速にトラブルシューティングできます。
これらの考慮事項を念頭に置いて、Kubernetesのモニタリングがサーバー、VM、またはクラウドインスタンスのモニタリングとは大きく異なる理由をよりよく理解出来ましたでしょうか？
疑問に思われるかもしれませんが、なぜこれをやるのですか？Kubernetesクラスターには複数のコンポーネントとレイヤーがあり、それぞれに監視する必要のあるさまざまな障害ポイントがあります。これらは、Kubernetesモニタリングの一般的な使用例です。
クラスターを監視することで、プラットフォーム全体の状態とキャパシティの全体像を把握できます。特定のユースケースは次のいずれかです。
ネームスペース、デプロイメント、ReplicaSets、DaemonSetsなどのKubernetesコンストラクトを見ると、アプリケーションが適切にデプロイされているかどうかがわかります。例えば：
しかし結局のところ、アプリケーションは最も重要なものです。ここで何を見たいですか？これは、次のように使用できる部分に似ています。
ゴールデンシグナルを使用したモニタリングは、これに関するベストプラクティスアプローチと見なされています。
ほとんどのプラットフォームと同様に、Kubernetesには、物理インフラストラクチャーの上に乗るKubernetesコンストラクトなど、プラットフォームを監視できる基本的なツールのセットがあります。「組み込み」という用語は、少し大げさな表現かもしれません。Kubernetesの拡張可能な性質を考えると、内部の改造者が追加のコンポーネントを追加してKubernetesの可視性を獲得することが可能であると言う方がより公正です。Kubernetesモニタリングセットアップの典型的な部分を実行してみましょう。
cadvisorは、オープンソースのコンテナリソース使用状況コレクターです。コンテナ用に意図的に構築されており、Dockerコンテナをネイティブでサポートしています。cadisorは、指定されたノードのすべてのコンテナを自動検出し、CPU、メモリ、ファイルシステム、およびネットワークの使用統計を収集しますが、いくつかの方法で制限されています。
Kubernetesでは、ノードのkubelet（マシン上のKubernetesエージェント）がcadvisorをインストールして、ポッドコンテナーのリソースを監視します。
しかし、このデータをさらに活用するには、クラスター全体のデータを集約するものが必要です。最も人気のあるオプションは、以前はHeapsterでした。Heapsterは、他のアプリケーションと同様に、クラスター内のポッドとして実行されます。Heapsterポッドは、kubeletから使用状況データをクエリします。kubeletは、cadvisorをクエリします。Heapsterは、関連するラベルを含めるとともに、情報をポッドごとにグループ化します。
HebersterおよびcAdvisorによるKubernetesでのモニタリング。ソース：blog.kubernetes.io
はい、これで準備が整いましたね。よくほとんど。Heapsterでは、データの保存、傾向分析、または警告を行うことはできません。クラスター全体でcadvisorデータを収集するのが簡単になるだけです。次に、このデータを構成可能なバックエンドにプッシュして、保存および視覚化する必要があります。サポートされるバックエンドには、InfluxDB、Google Cloud Monitoring、その他いくつかが含まれます。データを表示するには、Grafanaなどの視覚化レイヤーを追加する必要があります。
cadvisorはkubeletを介したデフォルトのポッドモニタリングコンポーネントのままですが、Heapsterは非推奨になり、Kubernetesはmetric-serverを介してメトリクスを消費します。
Kubernetes 1.8以降、kubeletおよびcadvisorからのリソース使用状況メトリクスは、Kubernetes APIが公開されているのと同じ方法でKubernetes メトリクスサーバー APIを介して利用できます。
このサービスでは、時間の経過とともに値を保存することもできず、視覚化や分析も行われません。Kubernetesメトリクスサーバーは、自動スケーリング用のHorizontal Pod AutoscalerのようなKubernetesの高度なオーケストレーションに使用されます。
Kubernetesダッシュボードには、あなたのKubernetesネームスペースとワークロードを通して、あなたの環境のブラウジングを参照するための簡単な方法を提供します。Kubernetesダッシュボードでは、基本的なCPU/メモリデータのみを使用して、この基本的なデータの一部を視覚化する一貫した方法を提供します。適切なRBAC権限を設定する必要があるため、このダッシュボードから管理してアクションを実行することもできます。
検討したいもう1つのコンポーネントは、kube-state-metricsです。これは、Kubernetes APIをポーリングし、Kubernetesコンストラクトに関する特性をメトリクスに変換するKubernetesメトリクスサーバーと一緒に実行されるアドオンサービスです。kube-state-metricsが回答するいくつかの質問は次のとおりです。
一般に、モデルはKubernetesイベントを取得し、それらをメトリクスに変換することです。Kubernetes 1.2以降が必要ですが、メトリクス名とタグが不安定であり、変更される可能性があることを残念ながら警告しています。
これにより、Kubernetes環境の合理的なモニタリングを構築するために実行するステップの感覚がわかります。詳細なアプリケーション監視はまだありませんが（「データベースサービスの応答時間は？」）、少なくとも基盤となるホスト、Kubernetesノード、およびKubernetes抽象化の状態の監視を確認できました。
Kubernetesプローブは、ポッドの状態または可用性を定期的に監視するという重要な機能を実行します。Kubernetesモニタリングプローブを使用すると、エンドポイントに対するリクエストまたはコマンドの実行を通じて、「Liveness」を任意に定義できます。以下は、catコマンドの実行に基づくLivenessプローブの簡単な例です。
#Example Liveness probe for the Sysdig Blog on "Monitoring Kubernetes"
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-exec
spec:
containers:
- name: liveness
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
image: gcr.io/google_containers/busybox
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
#source https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/
Prometheusは時系列データベースであり、オープンソースであり、Kubernetesと同様に、CNCFプロジェクトです。ただし、Prometheusモニタリングは、メトリクスを収集して保存するPrometheusサーバーの周りのモニタリングスタック全体です。これには、ダッシュボード用のGrafana、および多くのエクスポーターが含まれます。サービスメトリクスをPrometheusメトリクス形式に変換する小さなサイドカーコンテナです。
Prometheusを使い始めるのは本当に簡単です。簡単な設定には、Prometheus、Grafana、およびその他の要素がほとんど含まれていません。
Prometheusは、Kubernetesを監視するためのデファクトアプローチです。Kubernetesの独自のDIY Prometheus監視の実装を検討している場合は、その方法についてのガイドを作成しました。PrometheusでKubernetesの監視を開始するのは本当に簡単ですが、DevOpsチームは、Prometheusにスケール、RBAC、チームによるコンプライアンスサポートなどのいくつかの課題があることをすぐに理解します。詳しくは、Prometheusを使用した課題で詳しく説明しています。
Sysdig MonitorとSysdigバックエンドは、Prometheusのネイティブメトリクスとラベルを保存およびクエリできます。さらに、ユーザーは、Prometheusを使用するのと同じ方法でSysdigを使用できます。DevOpsワークフローの一部として、ダッシュボードとアラートにはPrometheus Query Languageクエリ、スクリプト化されたクエリにはPrometheus APIを利用できます。このようにして、Prometheusエコシステムへの投資を保護し、拡張しながら、規模とセキュリティを向上させることができます。ユーザーは、Sysdig Monitorの一部として提供するトラブルシューティング、関連付け、サポートを利用して、完全なPrometheus監視ソリューションを利用できます。
結論として、重要なデプロイメントがある場合は、オーケストレーション環境に自然に適合する方法でKubernetesを監視することを検討する必要があります。
Kubernetesモニタリングのデファクトスタンダードは、cadvisor、Kubernetesメトリクスサーバー、kube-state-metrics、Prometheusなどの多数のオープンソースツールから構築されています。本番環境をモニタリングする場合、Sysdigは、Prometheusモニタリングとの互換性を維持しながら、Kubernetesをモニタリングするための合理的なワークフローとサポートされたエクスペリエンスを提供します。また、大規模な環境を実行している場合は、Prometheusのスケール機能のおかげで対応できます。
本番環境で Kubernetesを実行している場合、Sysdig MonitorのPrometheusモニタリング機能を使用すると、Prometheusメトリクスを収集し、PromQLを使用してクエリを実行できるため、DevOpsチームは、広範なオープンソースのPrometheusエコシステムを活用して、Sysdigで実現する自信、Prometheusスケール、およびサポートを確保しながら、モニタリングへの投資のリスクを軽減できます。
しかし、まだ終わっていません。フォローアップの推奨事項は多数あり、Kubernetes Monitoring Fundamentalsガイドで詳細を確認することをお勧めします。