Gcr、Quay、DockerHub イメージのダウンロードの問題を完全に解決します。

[[382055]]

 この記事は、Michelangelo Yang 氏が執筆した WeChat 公開アカウント「Cloud Native Lab」から転載したものです。この記事を転載する場合は、Cloud Native Lab 公式アカウントまでご連絡ください。

序文

Docker と Kubernetes を使用する場合、gcr.io および quay.io イメージ リポジトリにアクセスする必要があることがよくあります。よく知られている理由により、これらの画像リポジトリは中国ではアクセスできません。唯一アクセスできるのはDocker Hubですが、速度も非常に遅いです。 gcr.azk8s.cn は、gcr.io イメージ リポジトリのプロキシ サイトです。元々は、gcr.azk8s.cn を介して gcr.io リポジトリ内のイメージにアクセスできましたが、現在 *.azk8s.cn は Azure China IP でのみ使用され、外部サービスは提供されなくなりました。他のほとんどの国内画像高速化ソリューションでは、キャッシュに時間同期を使用します。この方法には一定の遅延があり、タイムリーな更新を保証することはできません。 ustc や Qiniu Cloud などの画像アクセラレータを試してみましたが、信頼性が低く、多くの画像では機能しません。

gcr.io などのイメージ リポジトリに正常にアクセスするには、ファイアウォールの外側に gcr.azk8s.cn に似たイメージ リポジトリ プロキシ サイトを構築する必要があります。この要件は、Dockerのオープンソースプロジェクトレジストリ[1]を使用することで満たすことができます。レジストリは、ローカルのプライベート イメージ リポジトリとしてだけでなく、アップストリーム イメージ リポジトリのキャッシュ、つまりプル スルー キャッシュとしても使用できます。

まずはスピードを体感してみましょう:

1. 前提条件

魔法のようなことができるサーバー（つまり、gcr.io に直接アクセスする）

ドメイン名と、ドメイン名に関連付けられた SSL 証明書 (Docker がイメージをプルするときに検証するためにドメイン名証明書が必要です)。一般的にはLet's Encrypt[2]で十分です。

2. 核となる考え方

パラメータ remoteurl を設定することにより、レジストリをリモート リポジトリのキャッシュ リポジトリとして使用できます。このように、このプライベート リポジトリのアドレスを通じてイメージをプルすると、レジストリは最初にイメージをローカル ストレージにキャッシュし、次にそれをプル クライアントに提供します (これら 2 つの手順が同時に実行される可能性もありますが、確信はありません)。まずプライベート レジストリをデプロイし、次に remoteurl を高速化する必要があるイメージ リポジトリのアドレスに設定します。基本的にはこれで完了です。

3. レジストリをカスタマイズする

docker.io、gcr.io、k8s.gcr.io、quay.io、ghcr.io などの一般的なパブリック イメージ リポジトリのキャッシュをサポートするには、レジストリ構成ファイルをカスタマイズする必要があります。 Dockerfile は次のとおりです。

レジストリから:2.6
ラベル メンテナー = "registry-proxy Docker メンテナー https://fuckcloudnative.io"  
 ENV PROXY_REMOTE_URL = "" \
    DELETE_ENABLED = ""  
コピー entrypoint.sh /entrypoint.sh

entrypoint.sh は、環境変数を構成ファイルに渡すために使用されます。

エントリポイント

#!/bin/sh 
 
セット-e 
 
 config_yml = /etc/docker/registry/config.yml です。 
 
 if [ -n "$PROXY_REMOTE_URL" -a `grep -c "$PROXY_REMOTE_URL" $CONFIG_YML` -eq 0 ];それから 
    echo "プロキシ:" >> $CONFIG_YML
    echo "リモートURL: $PROXY_REMOTE_URL" >> $CONFIG_YML
    echo "ユーザー名: $PROXY_USERNAME" >> $CONFIG_YML
    echo "パスワード: $PROXY_PASSWORD" >> $CONFIG_YML
    echo "------ リモートへのプロキシが有効になりました: $PROXY_REMOTE_URL ------"  
 elif [ $DELETE_ENABLED = true -a `grep -c "delete:" $CONFIG_YML` -eq 0 ];それから 
    sed -i '/rootdirectory/a\ 削除:' $CONFIG_YML
    sed -i '/delete/a\ 有効: true' $CONFIG_YML
    echo "------ ローカルストレージの削除を有効にしました -----"  
フィ
 
 sed -i "/headers/a\ アクセス制御許可元: ['*']" $CONFIG_YML
 sed -i "/headers/a\ アクセス制御許可メソッド: ['HEAD', 'GET', 'OPTIONS', 'DELETE']" $CONFIG_YML
 sed -i "/headers/a\ アクセス制御公開ヘッダー: ['Docker-Content-Digest']" $CONFIG_YML 
 
場合  「$1」  で 
    *.yaml|*.yml)を設定  --registry サーブ "$@" ;;  
    サーブ|ガベージコレクト|ヘルプ|-*)セット  --registry "$@" ;;  
エサック
 
実行者  「$@」  

4. キャッシュサービスを開始する

Docker イメージをビルドしたら、サービスを開始できます。自分でビルドしたくない場合は、私のイメージ yangchuansheng/registry-proxy を直接使用できます。

一般的に言えば、docker.io、gcr.io、k8s.gcr.io、quay.io、ghcr.io を同時にキャッシュする場合でも、1C 2G のクラウド ホストで十分です (他のサービスを実行していない場合)。私のブログ、コメント サービス、その他さまざまなサービスはすべてクラウド ホスト上で実行されるため、1 つのサーバーではニーズを満たすのに不十分です。 Tencent Cloud Hong Kong の軽量サーバーを 2 台直接購入しました。

マシンを 2 台購入したので、k3s クラスターをセットアップする必要があります。ホスト名を見れば、何に使用するかがわかります。このうち、2C 4G はマスターノードとして使用され、1C 2G はノードノードとして使用されます。

docker.io を例にしてリソース リストを作成します。

dockerhub.yaml

 APIバージョン: アプリ/v1
種類: デプロイメント
メタデータ:
名前: dockerhub
  ラベル:
    アプリ: dockerhub
仕様:
  レプリカ: 1
  セレクタ：
    一致ラベル:
      アプリ: dockerhub
  テンプレート：
    メタデータ:
      ラベル:
        アプリ: dockerhub
    仕様:
      親和性:
        ポッドアンチアフィニティ:
          優先スケジュール中は無視実行中:
          -podアフィニティ用語:
              ラベルセレクター:
                一致表現:
                -キー: アプリ
                  演算子:  
値：
                  - ドッカーハブ
              トポロジキー: kubernetes.io/ホスト名
            重量: 1
      dnsポリシー: なし
      dnsConfig:
        ネームサーバー:
          - 8.8.8.8
          - 8.8.4.4
      コンテナ:
      -名前: dockerhub
        イメージ: yangchuansheng/registry-proxy:latest
        環境:
        -名前: PROXY_REMOTE_URL
          値: https://registry-1.docker.io
        -名前: PROXY_USERNAME
          値: 揚川勝
        -名前: PROXY_PASSWORD
          価値： ********
        ポート:
        - コンテナポート: 5000
          プロトコル: TCP
        ボリュームマウント:
        - マウントパス: /etc/localtime
名前: 現地時間
        - マウントパス: /var/lib/registry
名前: レジストリ
      ボリューム:
      -名前: 現地時間
        ホストパス:
          パス: /etc/localtime
      -名前: レジストリ
        ホストパス:
          パス: /var/lib/registry
 ---  
 APIバージョン: v1
種類: サービス
メタデータ:
名前: dockerhub
  ラベル:
    アプリ: dockerhub
仕様:
  セレクタ：
    アプリ: dockerhub
  ポート:
    - プロトコル: TCP
名前: http
      ポート: 5000
      ターゲットポート: 5000

リソース リストを使用して、対応するサービスを作成します。

 🐳 → kubectl apply -f dockerhub.yaml

ホストが 1 つしかない場合は、docker-compose を使用してコンテナーをオーケストレーションできます。 k8s 設定を参照して、設定ファイルを自分で変更することもできます。この記事では詳細には触れません。

5. エージェントの選択

docker.io のみをキャッシュする場合は、registry-proxy のポートを 443 に直接変更し、SSL 証明書の設定を追加できます。複数のパブリック イメージ リポジトリをキャッシュする場合は、443 ポートが 1 つしかなく、複数のレジストリ プロキシ サービスが同じポートを共有できないため、キャッシュすることはお勧めしません。合理的なアプローチは、エッジ プロキシ サービスを使用して、ドメイン名に基づいて異なるレジストリ プロキシ サービスにリクエストを転送することです。

Kubernetes クラスターの場合、Ingress Controller はエッジ プロキシです。一般的な Ingress コントローラーは、基本的に Nginx または Envoy によって実装されます。 Envoy はプロキシの世界では新参者ですが、適切なタイミングで誕生しました。その機能の多くはクラウド向けにネイティブに準備されており、真にクラウド ネイティブな L7 プロキシおよび通信バスとなっています。たとえば、サービス検出機能や動的構成機能は、Nginx などのプロキシのホットロードとは異なります。 Envoy は API を通じてコン​​トロール プレーンを実装できます。コントロール プレーンはサービス検出を集中管理し、データ プレーン プロキシを再起動せずに API インターフェイスを介してデータ プレーンの構成を動的に更新できます。それだけでなく、コントロール プレーンは API を介して構成を階層化し、レイヤーごとに更新することもできます。

現在、Envoyを使用して実装されているIngressコントローラには、ContourとGloo[3]が含まれます。 Envoy に興味があり、Ingress Controller をエッジ プロキシとして使用したい場合は、Contour を試してみてください。 Ingress Controller は、基盤となるレイヤーを抽象化し、多くの詳細を隠蔽します。すべての詳細な構成を考慮することはできず、基盤となるプロキシのすべての構成項目をサポートするわけではありません。したがって、私はネイティブ Envoy をエッジ プロキシとして使用することを選択しました。スタンドアロンのレジストリ プロキシ サービスを実行している場合は、Envoy を試すこともできます。

6. プロキシ設定

まず、Envoy リソース リストを作成します。

エンボイ.yaml

 APIバージョン: アプリ/v1
種類: デプロイメント
メタデータ:
名前: 特使
  名前空間: kube-system
  ラベル:
    アプリ: エンボイ
仕様:
  レプリカ: 2
  セレクタ：
    一致ラベル:
      アプリ: エンボイ
  戦略：
    ローリングアップデート:
      最大サージ: 0
      最大利用不可: 1
    タイプ: ローリングアップデート
  テンプレート：
    メタデータ:
      ラベル:
        アプリ: エンボイ
    仕様:
      ホストネットワーク: true  
      dnsポリシー: ClusterFirstWithHostNet
      コンテナ:
      -名前: 特使
        イメージ: envoyproxy/envoy:v1.17-latest
        イメージプルポリシー: IfNotPresent
        指示：
        -特使
        :envoy.yaml のファイル
        ポート:
        - コンテナポート: 443
名前: https
        - コンテナポート: 80
名前: http
        - コンテナポート: 15001
名前: http-metrics
        ボリュームマウント:
        - マウントパス: /etc/localtime
名前: 現地時間
        - マウントパス: /etc/envoy
名前: 特使
        - マウントパス: /root/.acme.sh/fuckcloudnative.io
名前: ssl
      ボリューム:
      -名前: 現地時間
        ホストパス:
          パス: /etc/localtime
      -名前: ssl
        ホストパス:
          パス: /root/.acme.sh/fuckcloudnative.io
      -名前: 特使
        ホストパス:
          パス: /etc/envoy

リソース リストを使用して、対応するサービスを作成します。

 🐳 → kubectl apply -f envoy.yaml

ここでは、hostPath を使用して envoy 構成をコンテナーにマウントし、ファイルを通じて構成を動的に更新することを選択します。 Envoy の構成を見てみましょう。まず、/etc/envoy ディレクトリに入ります。

ブートストラップ構成:

ノード：
  id: ノード0
  クラスター: cluster0
動的リソース:
  lds_config:
    パス: /etc/envoy/lds.yaml
  cds_config:
    パス: /etc/envoy/cds.yaml
管理者:
  アクセスログパス: "/dev/stdout"  
  住所：
    ソケットアドレス:
      アドレス: "0.0.0.0"  
      ポート値: 15001

LDS 構成:

lds.yaml

バージョン情報: "0"  
リソース：
 - "@type" : type.googleapis.com/envoy.config.listener.v3.Listener
名前: listener_http
  住所：
    ソケットアドレス:
      アドレス: 0.0.0.0
      ポート値: 80
  フィルターチェーン:
  - フィルター:
    -名前: envoy.filters.network.http_connection_manager
      入力された構成:
 "@type" : type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
        統計プレフィックス: ingress_http
        コーデックタイプ: AUTO
        アクセスログ:
名前: envoy.access_loggers.file
          入力された構成:
 "@type" : type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog
            パス: /dev/stdout
        ルート設定:
名前: http_route
          仮想ホスト:
          -名前:デフォルト 
            ドメイン:
            - 「*」  
            ルート:
            - マッチ：
                プレフィックス: "/"  
              リダイレクト：
                https_redirect:有効 
                ポートリダイレクト: 443
                応答コード: 「見つかりました」  
        http_フィルター:
        -名前: envoy.filters.http.router
 - "@type" : type.googleapis.com/envoy.config.listener.v3.Listener
名前: listener_https
  住所：
    ソケットアドレス:
      アドレス: 0.0.0.0
      ポート値: 443
  リスナーフィルター:
  -名前: "envoy.filters.listener.tls_inspector"  
    入力された構成: {}
  フィルターチェーン:
  - トランスポートソケット:
名前: envoy.transport_sockets.tls
      入力された構成:
 "@type" : type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext
        共通TLSコンテキスト:
          alpn_プロトコル: h2、http/1.1
          tls_証明書:
          - 証明書チェーン:
              ファイル名: "/root/.acme.sh/fuckcloudnative.io/fullchain.cer"  
            秘密鍵:
              ファイル名: "/root/.acme.sh/fuckcloudnative.io/fuckcloudnative.io.key"  
    フィルター:
    -名前: envoy.filters.network.http_connection_manager
      入力された構成:
 "@type" : type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
        統計プレフィックス: ingress_https
        コーデックタイプ: AUTO
        リモートアドレスの使用: true  
        アクセスログ:
名前: envoy.access_loggers.file
          入力された構成:
 "@type" : type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog
            パス: /dev/stdout
        ルート設定:
名前: https_route
          追加するレスポンスヘッダー:
          - ヘッダー:
キー: 厳格なトランスポートセキュリティ
              値: "max-age=15552000; includeSubdomains; preload"  
          仮想ホスト:
          -名前: docker
            ドメイン:
            ネイティブ
            ルート:
            - マッチ：
                プレフィックス: "/"  
              ルート：
                クラスター: dockerhub
                タイムアウト: 600秒
        http_フィルター:
        -名前: envoy.filters.http.router
          入力された構成:
 "@type" : type.googleapis.com/envoy.extensions.filters.http.router.v3.Router

CDS 構成:

cds.yaml

バージョン情報: "0"  
リソース：
 - "@type" : type.googleapis.com/envoy.config.cluster.v3.Cluster
名前: dockerhub
  接続タイムアウト: 15秒
  タイプ: strict_dns
  dns_lookup_family: V4_ONLY
  lb_policy: ラウンドロビン
  負荷割り当て:
    クラスター名: dockerhub
    エンドポイント:
    - lb_エンドポイント:
      - 終点：
          住所：
            ソケットアドレス:
              アドレス: dockerhub.default  
              ポート値: 5000

ここでのアドレスは、Kubernetes クラスターの内部ドメイン名を使用します。他の展開方法については、ご自身の判断でご検討ください。

Envoy を設定したら、プロキシ サーバー経由で docker.io イメージをプルできます。

7.加速効果を確認する

これで、プロキシ サーバー経由でパブリック イメージを取得できるようになりました。たとえば、nginx:alpine イメージをプルする場合は、次のコマンドを使用できます。

 🐳 → docker pull docker.fuckcloudnative.io/library/nginx:alpine 
 
 alpine: library/nginxから取得
801bfaa63ef2: プル完了
b1242e25d284: プルが完了しました
7453d3e6b909: プル完了
07ce7418c4f8: プル完了
e295e0624aa3: プル完了
ダイジェスト: sha256:c2ce58e024275728b00a554ac25628af25c54782865b3487b11c21cafb7fabda
ステータス: docker.fuckcloudnative.io/library/nginx:alpineの新しいイメージをダウンロードしました
docker.fuckcloudnative.io/library/nginx:alpine

8. すべての画像リポジトリをキャッシュする

前の例では、docker.io のみをキャッシュします。すべてのパブリックイメージリポジトリをキャッシュする場合は、セクション 4-6 を参照してください。 k8s.gcr.io を例にとると、まずリソース リストを準備します。

gcr-k8s.yaml

 APIバージョン: アプリ/v1
種類: デプロイメント
メタデータ:
名前: gcr-k8s
  ラベル:
    アプリ: gcr-k8s
仕様:
  レプリカ: 1
  セレクタ：
    一致ラベル:
      アプリ: gcr-k8s
  テンプレート：
    メタデータ:
      ラベル:
        アプリ: gcr-k8s
    仕様:
      親和性:
        ポッドアンチアフィニティ:
          優先スケジュール中は無視実行中:
          -podアフィニティ用語:
              ラベルセレクター:
                一致表現:
                -キー: アプリ
                  演算子:  
値：
                  - gcr-k8s
              トポロジキー: kubernetes.io/ホスト名
            重量: 1
      dnsポリシー: なし
      dnsConfig:
        ネームサーバー:
          - 8.8.8.8
          - 8.8.4.4
      コンテナ:
      -名前: gcr-k8s
        イメージ: yangchuansheng/registry-proxy:latest
        環境:
        -名前: PROXY_REMOTE_URL
          値: https://k8s.gcr.io
        ポート:
        - コンテナポート: 5000
          プロトコル: TCP
        ボリュームマウント:
        - マウントパス: /etc/localtime
名前: 現地時間
        - マウントパス: /var/lib/registry
名前: レジストリ
      ボリューム:
      -名前: 現地時間
        ホストパス:
          パス: /etc/localtime
      -名前: レジストリ
        ホストパス:
          パス: /var/lib/registry
 ---  
 APIバージョン: v1
種類: サービス
メタデータ:
名前: gcr-k8s
  ラベル:
    アプリ: gcr-k8s
仕様:
  セレクタ：
    アプリ: gcr-k8s
  ポート:
    - プロトコル: TCP
名前: http
      ポート: 5000
      ターゲットポート: 5000

Kubernetes クラスターにデプロイします。

 🐳 → kubectl apply -f gcr-k8s.yaml

lds.yaml に関連する設定を追加します。

仮想ホスト:
         -名前: docker
           ...
           ...
         -名前: k8s
           ドメイン:
           - k8s.fuckcloudnative.io
           ルート:
           - マッチ：
               プレフィックス: "/"  
             ルート：
               クラスター: gcr-k8s
               タイムアウト: 600秒

cds.yaml に関連する構成を追加します。

 - "@type" : type.googleapis.com/envoy.config.cluster.v3.Cluster
名前: gcr-k8s
  接続タイムアウト: 1秒
  タイプ: strict_dns
  dns_lookup_family: V4_ONLY
  lb_policy: ラウンドロビン
  負荷割り当て:
    クラスター名: gcr-k8s
    エンドポイント:
    - lb_エンドポイント:
      - 終点：
          住所：
            ソケットアドレス:
              アドレス: gcr -k8s.default  
              ポート値: 5000

他のイメージリポジトリでも上記の手順に従うことができます。私が自分で実行しているキャッシュ サービス コンテナーは次のとおりです。

 🐳 → kubectl get pod -o ワイド
 
 gcr-8647ffb586-67c6g 1/1 実行中 0 21h 10.42.1.52 blog-k3s02
 ghcr-7765f6788b-hxxvc 1/1 実行中 0 21h 10.42.1.55 blog-k3s01
 dockerhub-94bbb7497-x4zwg 1/1 実行中 0 21h 10.42.1.54 blog-k3s02
 gcr-k8s-644db84879-7xssb 1/1 実行中 0 21h 10.42.1.53 blog-k3s01
 quay-559b65848b-ljclb 1/1 実行中 0 21h 10.42.0.154 blog-k3s01

9. コンテナのランタイム構成

すべてのキャッシュ サービスを構成したら、プロキシ経由でパブリック イメージをプルできます。以下のリストに従って、画像アドレスのフィールドを置き換えるだけです。

もちろん、最善の方法はレジストリミラーを直接構成することです。 Docker は docker.io のレジストリ ミラーの構成のみをサポートしていますが、Containerd と Podman はすべてのイメージ リポジトリのレジストリ ミラーの構成をサポートしています。

ドッカー

Docker は設定ファイル /etc/docker/daemon.json を変更し、次のコンテンツを追加できます。

 {
 「レジストリミラー」 : [
 「https://docker.fuckcloudnative.io」  
    ]
 }

その後、Docker サービスを再起動すると、プロキシ サーバーのアドレスを指定せずに docker.io からイメージを直接プルできるようになります。 Docker サービス自体は、プロキシ サーバーを介してイメージを自動的にプルします。例えば：

 🐳 → docker pull nginx:alpine
 🐳 → docker pull docker.io/library/nginx:alpine

コンテナ

Containerd は比較的シンプルです。あらゆるレジストリのミラーリングをサポートします。設定ファイル /etc/containerd/config.toml を変更し、次の設定を追加するだけです。

 [プラグイン。 ["io.containerd.grpc.v1.cri" .レジストリ]
     [プラグイン。 ["io.containerd.grpc.v1.cri" .registry.mirrors]
       [プラグイン。 "io.containerd.grpc.v1.cri" .registry.mirrors. [[docker.io] ]
         エンドポイント = [ "https://docker.fuckcloudnative.io" ]
       [プラグイン。 "io.containerd.grpc.v1.cri" .registry.mirrors. [[ ... [ （
         エンドポイント = [ "https://k8s.fuckcloudnative.io" ]
       [プラグイン。 "io.containerd.grpc.v1.cri" .registry.mirrors. [[[gcr.io] ]
         エンドポイント = [ "https://gcr.fuckcloudnative.io" ]
       [プラグイン。 "io.containerd.grpc.v1.cri" .registry.mirrors. ["ghcr.io" ]
         エンドポイント = [ "https://ghcr.fuckcloudnative.io" ]
       [プラグイン。 "io.containerd.grpc.v1.cri" .registry.mirrors. [[[quay.io] ]
         エンドポイント = [ "https://quay.fuckcloudnative.io" ]

Containerd サービスを再起動すると、プレフィックスを変更せずにすべてのイメージを直接プルできるようになります。 Containerd は、設定に基づいてイメージをプルするための対応するプロキシ URL を自動的に選択します。

ポッドマン

Podman は、任意のレジストリのミラーリングもサポートします。設定ファイル /etc/containers/registries.conf を変更し、次の設定を追加するだけです。

非修飾検索レジストリ = [ 'docker.io' 、 'k8s.gcr.io' 、 'gcr.io' 、 'ghcr.io' 、 'quay.io' ] 
 
 [[レジストリ]]
プレフィックス = "docker.io"  
安全でない =本当 
場所 = "registry-1.docker.io"   
 
 [[レジストリミラー]]
場所 = "docker.fuckcloudnative.io"   
 
 [[レジストリ]]
プレフィックス = "k8s.gcr.io"  
安全でない =本当 
場所 = "k8s.gcr.io"   
 
 [[レジストリミラー]]
場所 = "k8s.fuckcloudnative.io"   
 
 [[レジストリ]]
プレフィックス = "gcr.io"  
安全でない =本当 
場所 = "gcr.io"   
 
 [[レジストリミラー]]
場所 = "gcr.fuckcloudnative.io"   
 
 [[レジストリ]]
プレフィックス = "ghcr.io"  
安全でない =本当 
場所 = "ghcr.io"   
 
 [[レジストリミラー]]
場所 = "ghcr.fuckcloudnative.io"   
 
 [[レジストリ]]
プレフィックス = "quay.io"  
安全でない =本当 
場所 = "quay.io"   
 
 [[レジストリミラー]]
場所 = "quay.fuckcloudnative.io"  

その後、プレフィックスを変更せずにすべてのイメージを直接プルできます。 Podman は、設定に基づいてイメージをプルするための対応するプロキシ URL を自動的に選択します。 Podman にはフォールバック メカニズムもあります。上記の構成は、最初に registry.mirror の location フィールドの URL を通じてイメージをプルしようとすることを意味します。失敗した場合は、レジストリの場所フィールドの URL を通じて取得を試みます。

10. キャッシュをクリアする

キャッシュ サービスはプルされたイメージをローカルにキャッシュするため、ディスク容量を消費します。一般的に、クラウド ホストのディスク容量はそれほど大きくなく、OSS や S3 ストレージは比較的高価で、コスト効率があまり良くありません。

この問題を解決するには、ローカル ディスクにキャッシュされた一部のイメージを定期的に削除するか、すべてのイメージを削除することをお勧めします。方法は比較的簡単です。他のレジストリのストレージを共有するために別のレジストリをデプロイし、削除機能を有効にして、API またはダッシュボードから削除します。

まずリソース リストを準備します。

 APIバージョン: アプリ/v1
種類: デプロイメント
メタデータ:
名前: reg-ローカル 
  ラベル:
    アプリ: reg-ローカル 
仕様:
  レプリカ: 1
  セレクタ：
    一致ラベル:
      アプリ: reg-ローカル 
  テンプレート：
    メタデータ:
      ラベル:
        アプリ: reg-ローカル 
    仕様:
      親和性:
        ポッドアンチアフィニティ:
          優先スケジュール中は無視実行中:
          -podアフィニティ用語:
              ラベルセレクター:
                一致表現:
                -キー: アプリ
                  演算子:  
値：
                  - reg-ローカル 
              トポロジキー: kubernetes.io/ホスト名
            重量: 1
      コンテナ:
      -名前: reg-ローカル 
        イメージ: yangchuansheng/registry-proxy:latest
        環境:
        -名前: DELETE_ENABLED
          値: "true"  
        ポート:
        - コンテナポート: 5000
          プロトコル: TCP
        ボリュームマウント:
        - マウントパス: /etc/localtime
名前: 現地時間
        - マウントパス: /var/lib/registry
名前: レジストリ
      ボリューム:
      -名前: 現地時間
        ホストパス:
          パス: /etc/localtime
      -名前: レジストリ
        ホストパス:
          パス: /var/lib/registry
 ---  
 APIバージョン: v1
種類: サービス
メタデータ:
名前: reg-ローカル 
  ラベル:
    アプリ: reg-ローカル 
仕様:
  セレクタ：
    アプリ: reg-ローカル 
  ポート:
    - プロトコル: TCP
名前: http
      ポート: 5000
      ターゲットポート: 5000

Kubernetes クラスターにデプロイします。

 🐳 → kubectl apply -f reg-ローカル.yaml

Docker レジストリ UI のリソース リストを準備します。

 APIバージョン: アプリ/v1
種類: デプロイメント
メタデータ:
名前: レジストリUI
  ラベル:
    アプリ: レジストリUI
仕様:
  レプリカ: 1
  セレクタ：
    一致ラベル:
      アプリ: レジストリUI
  テンプレート：
    メタデータ:
      ラベル:
        アプリ: レジストリUI
    仕様:
      親和性:
        ポッドアンチアフィニティ:
          優先スケジュール中は無視実行中:
          -podアフィニティ用語:
              ラベルセレクター:
                一致表現:
                -キー: アプリ
                  演算子:  
値：
                  - レジストリUI
              トポロジキー: kubernetes.io/ホスト名
            重量: 1
      許容範囲:
      -キー: node-role.kubernetes.io/ingress
        演算子: 存在する
        効果: NoSchedule
      コンテナ:
      -名前: レジストリUI
        イメージ: joxit/docker-registry-ui:静的 
        環境:
        -名前: REGISTRY_TITLE
          値: 私のプライベートDockerレジストリ
        -名前: REGISTRY_URL
          値: "http://reg-local:5000"  
        -名前: DELETE_IMAGES
          値: "true"  
        ポート:
        - コンテナポート: 80
          プロトコル: TCP
        ボリュームマウント:
        - マウントパス: /etc/localtime
名前: 現地時間
      ボリューム:
      -名前: 現地時間
        ホストパス:
          パス: /etc/localtime
 ---  
 APIバージョン: v1
種類: サービス
メタデータ:
名前: レジストリUI
  ラベル:
    アプリ: レジストリUI
仕様:
  セレクタ：
    アプリ: レジストリUI
  ポート:
    - プロトコル: TCP
名前: http
      ポート: 80
      ターゲットポート: 80

Kubernetes クラスターにデプロイします。

 🐳 → kubectl apply -f レジストリ ui.yaml

この方法では、ダッシュボードを通じてイメージをクリーンアップし、スペースを解放することができます。

または、ストレージ ディレクトリ全体の内容を一定の時間に削除するだけです。たとえば、crontab -e コマンドを実行し、次の内容を追加します。

 * * */2 * * /usr/bin/rm -rf /var/lib/registry/* &>/dev/ null  

/var/lib/registry/ ディレクトリが 2 日ごとにクリーンアップされることを示します。

11. 反無料品認定

最後に、もう1つ問題があります。キャッシュサービスのドメイン名をすべて公開しました。みんなが無料で使うようになれば、私のクラウドサーバーは絶対に耐えられなくなります。フリーロードを防ぐために、registry-proxy に認証を追加する必要があります。最も簡単な方法は、基本認証を使用し、htpasswd を使用してパスワードを保存することです。

パスワード admin を使用して、ユーザー admin のパスワード ファイルを作成します。

 🐳 → docker run \
 --entrypoint htpasswd \  
  レジストリ:2.6 -Bbn 管理者 管理者 > htpasswd

シークレットを作成する:

 🐳 → kubectlシークレットジェネリックレジストリ認証--from-file=htpasswdを作成します 

docker.io を例にして、リソース リストの構成を変更します。

 APIバージョン: アプリ/v1
種類: デプロイメント
メタデータ:
名前: dockerhub
  ラベル:
    アプリ: dockerhub
仕様:
  レプリカ: 1
  セレクタ：
    一致ラベル:
      アプリ: dockerhub
  テンプレート：
    メタデータ:
      ラベル:
        アプリ: dockerhub
    仕様:
      親和性:
        ポッドアンチアフィニティ:
          優先スケジュール中は無視実行中:
          -podアフィニティ用語:
              ラベルセレクター:
                一致表現:
                -キー: アプリ
                  演算子:  
値：
                  - ドッカーハブ
              トポロジキー: kubernetes.io/ホスト名
            重量: 1
      dnsポリシー: なし
      dnsConfig:
        ネームサーバー:
          - 8.8.8.8
          - 8.8.4.4
      コンテナ:
      -名前: dockerhub
        イメージ: yangchuansheng/registry-proxy:latest
        環境:
        -名前: PROXY_REMOTE_URL
          値: https://registry-1.docker.io
        -名前: PROXY_USERNAME
          値: 揚川勝
        -名前: PROXY_PASSWORD
          価値： ********
 + -名前: REGISTRY_AUTH_HTPASSWD_REALM
 + 値: レジストリ領域
+ -名前: REGISTRY_AUTH_HTPASSWD_PATH
 + 値: /auth/htpasswd
        ポート:
        - コンテナポート: 5000
          プロトコル: TCP
        ボリュームマウント:
        - マウントパス: /etc/localtime
名前: 現地時間
        - マウントパス: /var/lib/registry
名前: レジストリ
+ - マウントパス: /auth
 +名前: 認証
      ボリューム:
      -名前: 現地時間
        ホストパス:
          パス: /etc/localtime
      -名前: レジストリ
        ホストパス:
          パス: /var/lib/registry
 + -名前: 認証
+ 秘密:
 + シークレット名: レジストリ認証

効果を上げるには、次のように適用します。

 🐳 → kubectl apply -f dockerhub.yaml

イメージをプルしてみます:

 🐳 → docker pull docker.fuckcloudnative.io/library/nginx:latest 
    
デーモンからのエラー応答: https://docker.fuckcloudnative.io/v2/library/nginx/manifests/latest を取得:基本認証資格情報がありません

イメージリポジトリにログインします。

 🐳 → docker ログイン docker.fuckcloudnative.io
ユーザー名: admin
パスワード:
警告！パスワードは暗号化されずに/root/.docker/config.jsonに保存されます。
この警告を削除するには、資格情報ヘルパーを構成します。見る
https://docs.docker.com/engine/reference/commandline/login/#credentials-store 
 
ログインに成功しました

これで、イメージを正常にプルできるようになります。

より細かく権限を制御したい場合は、認証にトークンを使用できます。詳細についてはdocker_auth[4]プロジェクトを参照してください。

参考文献

[1]レジストリ: https://docs.docker.com/registry/

[2]レッツ・エンクリプト：https://letsencrypt.org/

[3]Gloo: https://github.com/solo-io/gloo

[4]docker_auth: https://github.com/cesanta/docker_auth