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 対策を紹介したいと思います。

Web アプリケーションの運用において、デプロイやメンテナンスに伴うプロセスの再起動は避けて通れないイベントです。この際、実行中のリクエストを強制的に遮断することなく、安全に処理を完了させてから停止する仕組みを Graceful Shutdown と言います。特に Kubernetes 環境では、デプロイやオートスケーリングによって Pod の破棄と再作成が頻繁に行われます。そのため、単にアプリケーションコードで終了処理を書くだけでは不十分です。 Kubernetes がどのように Pod をネットワークから切り離し、コンテナを停止させるのかという Termination プロセスについて正しく理解した上で、アプリケーションを安全に停止させる設計が求められます。今回のブログでは Kubernetes がどのように Pod を停止・削除するのか、その内部プロセスと挙動について整理してみたいと思います。

近年、クラウドネイティブなアプリケーション開発において Kubernetes はデファクトスタンダードとしての地位を確立しつつあります。今後はインフラエンジニアだけでなく、アプリケーション開発者にとっても、コンテナ上で動作するアプリケーションのライフサイクルやリソース管理を理解することはほぼ必須のスキルになっていくと考えられます。今回のブログは前後編の 2 部構成になっています。本記事では、Kubernetes がなぜ必要とされているのかについて、背後にあるコンテナ仮想化技術や Linux カーネルの仕組みを交えつつ章立てて紹介したいと思います。また、実装編 では Pod の詳細なライフサイクル、ネットワークの仕組み、ワークロード管理といった、Kubernetes の実践的な運用について紹介します。