Blog

2025 年 4 月 1 日から Docker Hub の Rate Limit が引き締められ、未認証ユーザによるイメージ Pull は 1 時間あたり 10 回まで に制限されました。Rate Limit に引っかかると、Docker Hub からのイメージ Pull が一定の期間規制されるため、コンテナが起動できなくなる危険があります。 特に、マネージド Kubernetes の場合、イメージ Pull はクラスタの IP（NAT IP 等）アドレスを送信元としてリクエストされるため、同一の IP アドレスから大量の Pull リクエストを送信すると、その IP に対して Docker Hub の Rate Limit が適用されます。このため、単一の Pod が Rate Limit に引っかかると、他の Pod もイメージの取得ができなくなり、ImagePullBackOff や ErrImagePull に陥る可能性があります。今回は Google Cloud Artifact Registry の Remote Repository と Amazon ECR の Pull Through Cache を活用した Docker Hub の Rate Limit 対策を紹介したいと思います。

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

Google Kubernetes Engine（GKE）は Google Cloud が提供するマネージド Kubernetes サービスで、クラウドネイティブなアプリケーションの実行基盤として広く利用されています。 Kubernetes クラスタの運用において、アップグレード作業はセキュリティの確保や新機能の利用のために不可欠なプロセスです。一方、Kubernetes のマイナーリリースは 通常 3 - 4 ヶ月に 1 回のペースで実施される上、アップグレード作業にはいくつもの考慮事項があるため、メンテナンスコストが高くなりがちです。また、マネージド Kubernetes の場合、サポートを受けられる期間も限られているため、継続的なクラスタバージョン追従が必要になります。このような GKE のメンテナンスに関する課題に対して、Google Cloud は作業負荷を下げるための仕組みを用意してくれています。このブログでは、GKE の効果的なアップグレード戦略について Google Cloud の内間さんが出している こちらのスライド を参考にまとめてみます。

マルチクラウド環境において、AWS から GCP のマネージドサービスに対し、OIDC によるキーレス連携を実現する GCP Workload Identity Federation の仕組みについて紹介します。多くのクラウドサービスでは、API キーや Credential（AWS アクセスキーや GSA アカウントキー）を発行することで、各種マネージドサービスにアクセスすることが可能です。しかし、永続的に使用できてしまう認証情報は、キーローテーションによる管理の煩雑化や、流出によるセキュリティリスクが存在します。GCP Workload Identity Federation では、Credential として有効期限の短い STS トークンで認証・認可を行うため、前述のセキュリティリスクを軽減できます。これらの処理はクライアントライブラリによって隠蔽されるため、サービスの開発者やワークロードは OAuth 2.0 Token Exchange の複雑な仕組みを意識することなく、通常の Credential と同じように利用することができます。GCP Workload Identity Federation は非常にセキュアで利便性が良いですが、内部でどのような手続きが行われているのか気になったので DeepDive してみました。

Kubernetes でリクエストを Pod に負荷分散する際にクライアントの送信元 IP アドレスを保持したいケースがあります。LoadBalancer や NodePort を使用する Service の場合、負荷分散の過程で送信元 IP アドレスが NAT（SNAT：Source NAT）されるため、Pod に到達するパケットからはクライアントの IP アドレスを知ることができません。Service の External Traffic Policy を Local に設定すると、外部からのトラフィックは受信したノード上の Pod にのみ転送されるため SNAT は回避できますが、単一ノードにトラフィックが集中するためクラスタワイドな負荷分散ができません。また、Ingress Controller を利用すると HTTP X-Forwarded-For ヘッダに送信元情報を付加することができますが、L7 LB が前提となるため、L4 LB のような低レベルロードバランサでは有効に機能しません。ベアメタル Kubernetes でネットワークロードバランサをプロビジョニングするための代表的な OSS に MetalLB があります。MetalLB には L2 モードと BGP モードの 2 種類の負荷分散方式が用意されています。多くの場合は前者が利用されますが、後者の BGP モードでは、より柔軟なネットワーク構成や負荷分散の制御が可能になり、送信元 IP アドレスを保持したままリクエストを分散することができます。今回のブログでは、MetalLB の BGP モードを利用して SNAT を回避しつつ、クラスタワイドな負荷分散を実現する構成について紹介したいと思います。

現在、研究室で利用するための KaaS 基盤（プライベートクラウド）を整備するべく、ベアメタル Kubernetes の構築に取り組んでいます。今回は、CNCF cloud native landscape にもある Rook/Ceph を使用して分散ストレージシステムを導入し、Amazon S3 や Google Cloud Storage に相当するオブジェクトストレージを自前で構築してみたので、その紹介です。

Kubernetes やクラウドネイティブな環境下での負荷試験において、Grafana Labs の k6 が注目されています。 k6 はコンテナフレンドリーな設計となっており、シナリオの定義も非常に容易です。 また、Kubernetes への導入には、オペレータ（k6-operator）を用いることで、大規模な負荷シナリオや分散実行、自動化されたパイプラインとの統合も可能です。今回のブログでは、モダンな負荷試験ツールである k6 を取り上げ、導入方法や負荷試験環境の構築についてまとめてみたいと思います。

従来、Kubernetes では秘匿情報を管理するコンポーネントとして KES（Kubernetes External Secrets） が広く利用されており、Secret リソースを管理するツールとしてデファクトスタンダートとなっていました。 しかし、2021 年 11 月 KES の非推奨化が発表され、2022 年 7 月時点でアーカイブされました。KES が非推奨になった背景としては、アクティブなメンテナがいなかったことや、プロジェクト内で抱えていた技術負債を解消しきれず、メンテナンスのモチベーションを維持できなかったことが言及されています。KES の非推奨化に伴う後継ツールの一つとして ESO（External Secrets Operator） が注目を集めています。 ESO は KES を開発していたコミュニティによってホスティングされており、Go でリファクタリングされています。 ESO は KES との互換性を維持しつつ、メンテナンス性を重視した機能豊富なサービスとなっており、移行ツールも用意されています。今回のブログでは、KES の非推奨化に伴う ESO への移行について、ツールの特徴を交えながら紹介したいと思います。

このブログは『RaspberryPi で構築する Bare-Metal Kubernetes』のエコシステム編です。 準備編では、機器類の準備、セットアップ、各種 OSS の選定と全体設計について紹介しました。 また、構築編では Kubernetes クラスタを構築し、アプリケーションをデプロイして MetalLB で公開しました。エコシステム編では、より本番環境に近い Kubernetes の運用を目指すべく、モニタリング基盤と ArgoCD による GitOps を整備したいと思います。

このブログは『RaspberryPi で構築する Bare-Metal Kubernetes』の構築編です。 準備編では、機器類の準備、セットアップ、各種 OSS の選定と全体設計について紹介しました。構築編では、セットアップした RaspberryPi に Kubernetes をインストールして Control-Plane 1 台、Data-Plane 3 台のクラスタを構築し、アプリケーションをデプロイして公開してみます。 本記事では MetalLB の仕組みについても簡単に紹介します。

クラウドネイティブ に注目が集まる昨今、コンテナオーケストレーションツールとして Kubernetes がデファクトスタンダードな基盤技術となっています。Kubernetes を用いることで 宣言的な設定（Declarative Configuration）に基づいたアプリケーションのデプロイ、管理、運用の自動化、スケーラビリティの確保等を実現することができます。Kubernetes によりサービス運用の効率化や高度な自動化を実現できますが、内部のアーキテクチャは非常に複雑なものになっており、コンピュータサイエンスの基本的な知識も必要になります。運用に際して、インフラエンジニアやクラスタの管理者は Kubernetes の内部コンポーネントの詳細や、その挙動を熟知しておくことが重要です。Kubernetes の有名な学習リソースの一つに Kubernetes The Hard Way というものがあります。これは、手作業で一からクラスタを構築して Kubernetes の内部構造への理解を深めるというコンテンツです。Kubernetes The Hard Way では、主に GCP の Compute Engine を用いますが、今回は RaspberryPi をベースにベアメタルでクラスタを構築してみました。いわゆる『おうち Kubernetes』というやつです。今回は、RaspberryPi で Kubernetes をセルフホスティングする方法について『準備編』『構築編』『エコシステム編』の 3 編にわたり紹介したいと思います。準備編では、機器類の準備、RaspberryPi の初期設定をします。また、Kubernetes の構築に必要となる各種 OSS の選定や、ネットワーク構成およびインフラ全体の設計について固めます。