Blog

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 に対するデプロイメントを制御する仕組みについて紹介したいと思います。

先日開催された Qiita Hackathon 2024 に参加をし、無事に予選を通過してきたので、振り返りも兼ねてブログを書こうと思います。

GCP では各マネージドサービスを利用する際の権限管理としてサービスアカウント（GSA：Google Service Account）を用います。GSA には、予め Google 側で用意しているデフォルト GSA と、利用者が自由に作成できる GSA が存在します。一般に、前者のデフォルト GSA はプロジェクト作成時点や API を有効化した際に自動的に作成されます。デフォルト GSA は削除してしまうと、その GSA を利用するマネージドサービスにアクセスできなくなってしまいます。今回は、誤って削除してしまったデフォルト GSA の復元方法について紹介したいと思います。

8 月 1 - 2 日（2 Days）パシフィコ横浜にて開催された Google Cloud Next Tokyo'24 に現地参加してきました。基調講演では主に生成 AI の最新動向や将来性について、実際の活用事例や今後の展望、使用していく上での課題や解決策に関する話題がメインでした。今回のブログでは、基調講演をはじめ、いくつか気になったセッションに関してまとめようと思います。