1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

kindでDocker Hubのレートリミットを回避する設定

Posted at

Kubernetesの学習やローカル開発で使われる「kind」を利用しているとき、Docker Hubのレートリミットによってコンテナイメージがうまくpullできない経験はありませんか?特に繰り返しクラスターを作成・削除するような場合、すぐにレート制限に引っかかってしまいます。本稿では、kindでレートリミットを回避するための設定方法をご紹介します。

はじめに

Docker Hubレートリミットの現状と変更予定

Docker Hubでは、イメージのpull回数に制限があります。2025年4月1日から、この制限が以下のように変更される予定です。

  • 未認証ユーザー: 1時間あたり10回まで(IPアドレス単位で計算)
  • 認証済み無料ユーザー: 1時間あたり100回まで(これまでの40回から増加)
  • 有料プランユーザー(Pro, Team, Business): 無制限(フェアユースポリシー適用)

認証すれば100回までpullできますが、Helm Chartを複数インストールしたり、環境を何度も作り直したりする開発フローでは、あっという間にこの制限に達してしまいそうです。

kindにおける問題

kind(Kubernetes IN Docker)は、Dockerコンテナを使ってKubernetesクラスターをローカルで簡単に構築できるツールです。しかし、クラスターを作成するたびに必要なイメージをDocker Hubからpullするため、レートリミットに悩まされることがあります。

特に以下のようなエラーに見覚えはありませんか?

ImagePullBackOff: Back-off pulling image "docker.io/library/nginx:latest"

「なぜイメージがpullできないのか」と悩んだとき、Docker Hubのレートリミットが原因であることが少なくありません。

解決策:ミラーの設定

結論:レジストリミラーを使ってレートリミットを回避する

結論から言うと、Google Container Registry (GCR) のミラーを設定することで、Docker Hubのレートリミットを簡単に回避できます。kindクラスター作成時にcontainerdの設定をパッチすることで実現できます。

以下が設定の核心部分です:

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
containerdConfigPatches:
  - |-
    [plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
      endpoint = ["https://mirror.gcr.io", "https://registry-1.docker.io"]

この設定により、Docker Hubからのイメージpull要求が自動的にGCRのミラーにリダイレクトされ、レートリミットを気にせずコンテナを起動できるようになります。

詳細な設定方法

ステップ1:設定ファイルの作成

まず、上記の設定を含むkind-config.yamlファイルを作成します:

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4

# ... 他の設定は中略 ...

containerdConfigPatches:
  - |-
    [plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
      endpoint = ["https://mirror.gcr.io", "https://registry-1.docker.io"]

ステップ2:設定ファイルを使ってクラスターを作成

作成した設定ファイルを使って、kindクラスターを作成します:

kind create cluster --name mirror-cluster --config kind-config.yaml

これだけで、Docker Hubへのイメージpullリクエストは自動的にGCRのミラーに転送されるようになります。

ステップ3:動作確認

設定が正しく機能しているか確認するために、いくつかのPodをデプロイしてみましょう:

kubectl create deployment nginx --image=nginx
kubectl create deployment redis --image=redis

以前レートリミットで失敗していた場合でも、これらのデプロイメントが正常に動作するはずです。

仕組みの解説

containerdのレジストリミラー機能

この設定が機能する仕組みを理解しておくと、他の環境でも応用できるでしょう。

containerdは、コンテナランタイムの一つで、kindクラスター内でコンテナを管理しています。containerdには「レジストリミラー」という機能があり、特定のレジストリへのリクエストを別のエンドポイントにリダイレクトできます。

今回の設定では:

  1. docker.io(Docker Hub)へのリクエストに対して
  2. 最初にhttps://mirror.gcr.ioにアクセスを試み
  3. 失敗した場合はhttps://registry-1.docker.io(オリジナルのDocker Hub)にフォールバック

という動作をします。Google Container Registry (GCR) のミラーは、Docker Hubの公開イメージをキャッシュしており、レートリミットなしで利用できるため、非常に便利です。

まとめ

本稿では、kindクラスターでDocker Hubのレートリミットを回避するためのレジストリミラー設定方法をご紹介しました。シンプルなYAML設定を追加するだけで、開発中のImagePullBackOffエラーから解放され、よりスムーズにKubernetes開発に集中できるようになります。

レジストリミラーは、ローカル開発環境だけでなく、CIパイプラインや本番環境でもレートリミット対策やパフォーマンス向上のために活用できるテクニックです。ぜひ自分の環境に合わせてカスタマイズしてみてください。

最後までお読みくださりありがとうございました。

1
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?