Blog

システムの監視は安定した運用を維持するために欠かせない要素です。 モニタリングの一環として「アラーティング（警告通知）」を整備することで、システムの異常を早期に検出して適切な対応を取ることでダウンタイムの回避やパフォーマンスの最適化を図ることができます。今日、Grafana は OSS として公開されているダッシュボードツールのデファクトスタンダードとなっています。 Grafana はメトリクスの可視化やデータ分析の機能だけでなく、アラート機能を活用することでシステムの異常をリアルタイムに検出し、担当者に迅速に通知することが可能です。 最新の Grafana バージョンでは、アラート機能が大幅に強化され複雑な条件設定や通知チャネルの多様化に対応しています。Grafana Alert は単純なクエリや閾値に加え、ポリシを設定することで通知のタイミングを柔軟に制御することができます。今回のブログでは、Grafana Alert の機能について基本的な仕組みやアラートの制御方法について整理したいと思います。

Kubernetes には Pod の配置を制御する機能があります。 Pod の配置制御とは、任意の Pod を特定のノードにスケジュールしたり、逆に特定のノードに対して Pod をスケジュールさせないようにコントロールすることです。最も簡易的な方法として、Node Selector を使用することで任意の Pod を所定のノードにスケジュールすることができます。 また、Node Selector に加え、より細やかな制御が可能な Node Affinity を使用することもできます。Node Selector および Node Affinity が、ある Pod を特定のノードにスケジュールさせるために使用されるのに対し、Pod をあるノードから遠ざけたい、または特定のノードをワークロードから隔離したいという要件に対しては Taints/Tolerations という機能が用意されています。 Taints と Tolerations は互いに作用しあい、Pod が不適当なノードにスケジュールされるのを防ぎます。Node Affinity の場合は、未指定の場合、どのノードにでも Pod をスケジュール可能ですが、Taints/Tolerations の場合は、指定しない限りそのノードに Pod がスケジュールされることはありません。Taints/Tolerations は、例えば Production 用のノードには他の Pod をスケジュールさせたくない場合や、GPU（Graphics Processing Unit） や FPGA（Field Programmable Gate Array） 等の特殊なデバイスを持つノードには特定の Pod 以外をスケジュールさせたくないといった場合に有効です。今回のブログでは、Taints/Tolerations による Pod の配置制御とノードの隔離策についてまとめたいと思います。

昨年 12 月 2 日 - 6 日までの 5 日間に渡り、米 Las Vegas にて AWS re:Invent が開催されました。 今回は、次世代 SageMaker の発表や Bedrock・Knowledge Bases の機能強化、Nova のマルチモーダル画像・動画生成モデルの提供開始等、生成 AI に関する話題が盛りだくさんでした。中でも個人的に興味深かったのが EKS Auto Mode の発表です。 これまでの EKS は、Control-Plane に関してある程度の機能がマネージドに提供されているものの、Google Kubernetes Engine（GKE） と比較してネイティブな Kubernetes を運用しなければならない印象でした。また、手動でのクラスタアップグレードが必要な上、Data-Plane（ワーカーノード）の運用自動化も提供されておらず、ある程度インフラの知識を持ったエンジニアによる戦略的なメンテナンス作業が必要でした。EKS Auto Mode では Kubernetes に必要なコンピュートリソース、ストレージシステム、ネットワーキング機能のプロビジョニング自動化等、従来の EKS と比較してクラスタの管理コストを大幅に下げることが期待できます。今回は、そんな EKS Auto Mode の特徴や仕組みについて、個人的な所感を交えつつ紹介したいと思います。

Kubernetes API はクラスタリソースを操作するための基本的なインターフェースを提供します。 クライアントは Kubernetes API を通じて、Namespace, Deployment, Pod 等の Kubernetes の様々なオブジェクトを検索・操作することができます。Kubernetes API はクラスタのアップグレードに伴い、既存の API が非推奨（Deprecated）または廃止（Removal）となる場合があります。 もし、非推奨 API でサービスを運用し続けると、いずれ API が使用できなくなりサービスのダウンタイムや障害を引き起こすリスクが高まります。 実際に米国ソーシャルニュースサイト Reddit の例 にあるように、非推奨 API を使用し続けたことで大規模な障害が発生した事例も報告されています。Kubernetes の API サーバは API のバージョン情報を管理しており、Deprecated API を適用すると、以下のようなメッセージで警告を出してくれます。これは v1.21 のクラスタに対して、batch/v1beta1 の CronJob を利用したリソースを定義したマニフェストを Apply した際に返される結果です。 kubectl が Warning を返しているのが分かると思います。今回のブログでは、Kubernetes が非推奨 API を検出する仕組みについて紹介したいと思います。

Kubernetes はコンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するための強力なプラットフォームエンジンです。 マニフェストを用いてリソースの種類や制御パラメータを組み合わせることで、アプリケーションを柔軟にデプロイ・管理できますが、運用面での統制やセキュリティの確保が課題となっています。 組織全体で一貫したポリシを確立し、セキュリティ要件を設けることは、運用の安全性を確保する上で非常に重要になります。また、インフラ・プラットフォームサイドのエンジニアが継続的に介入せずとも、開発者が自立して安全にアプリケーションを開発できるように舗装することは Platform Engineering の文脈でも必要になってきます。今回のブログでは、ポリシ整備ツールのデファクトスタンダートとなっている OPA（Open Policy Agent） および Gatekeeper を取り上げ、Kubernetes に対するデプロイメントを制御する仕組みについて紹介したいと思います。