K8sの画像キャッシュ管理の詳しい説明 kube-stead

モバイル 2024-04-16 13:19:18 訪問数: null

この記事は、Shanhe 氏による Huawei クラウド コミュニティ「K8s Image Cache Management Kube-stead Affairs」から共有されたものです。

インターネット上のコンテナーのスケジューリングでは、一部の特殊なシナリオでは、スケジュールされたノード行の現在のコンテナーのイメージをプルする必要があることがわかっています。 k8s 

  • 快速启动和/或扩展 申請が 必要です 。たとえば、リアルタイム データ処理を実行するアプリケーションは、データ量が爆発的に増加するため、迅速に拡張する必要があります。
  • イメージは比較的大きく、複数のバージョンが含まれているため、ノードのストレージには制限があるため、不要なイメージを動的にクリーンアップする必要があります。
  • 无服务器函数 多くの場合、受信イベントに即座に反応し、数秒以内にコンテナを起動する必要があります。
  • エッジ デバイスで実行するには、 ミラー リポジトリへの断続的なネットワーク接続を 許容する必要があります 。   IoT 应用程序 边缘设备
  • 专用仓库 から イメージをプルする必要があり 、 镜像仓库 そこからイメージをプルするためのアクセス権を全員に与えることができない場合は、クラスターのノードでイメージを使用できるようにすることができます。
  • クラスター管理者またはオペレーターがアプリケーションをアップグレードする必要があり、新しいイメージが正常にプルできるかどうかを事前に確認したい場合。

kube-fledged これは、Kubernetes クラスターのノード上でコンテナー イメージ キャッシュを直接作成および管理するために使用されます。これにより、ユーザーは画像のリストと、これらの画像をキャッシュする (つまり、プルする) ワーカー ノードを定義できます。その結果、レジストリからイメージを取得する必要がないため、アプリケーション ポッドをほぼ即座に開始できます。 kubernetes operator worker 

kube-fledged 画像キャッシュのライフサイクルを管理するために CRUD API が提供され、複数の構成可能なパラメーターをサポートしているため、独自のニーズに応じて機能をカスタマイズできます。

Kubernetes にはそれが組み込まれています镜像垃圾回收机制。ノード内の kubelet は、ディスク使用量が特定のしきい値 (フラグで構成可能) に達しているかどうかを定期的にチェックします。これに達すると阈值、kubelet はすべての未使用のイメージをノードから自動的に削除します。

提案されたソリューションには、自動および定期的なリフレッシュ メカニズムを実装する必要があります。イメージ キャッシュ内のイメージが kubelet の gc によって削除された場合、次の更新サイクルで削除されたイメージがイメージ キャッシュにプルされます。これにより、画像キャッシュが確実に最新の状態になります。

設計フロー

https://github.com/senthilrch/kube-ある程度/blob/master/docs/kubeある程度-architecture.png

kube 本格的なデプロイ

ヘルムモードの展開

──[[email protected]]-[~/ansible]
└─$mkdir kube 本格的
┌──[[email protected]]-[~/ansible]
━─$cd キューブ本格
┌──[[email protected]]-[~/ansible/kube-owned]
└─$export KUBEFLEDGED_NAMESPACE=kube 本格的
┌──[[email protected]]-[~/ansible/kube-owned]
━─$kubectl 名前空間 ${KUBEFLEDGED_NAMESPACE} を作成します
名前空間/kube-owned が作成されました
┌──[[email protected]]-[~/ansible/kube-owned]
└─$helm リポジトリに kubestead-charts を追加 https://senthilrch.github.io/kubeある程度-charts/
「kubestead-charts」がリポジトリに追加されました
┌──[[email protected]]-[~/ansible/kube-owned]
└─$helm リポジトリの更新
チャート リポジトリから最新情報を取得しますので、しばらくお待ちください...
...「kubestead-charts」チャート リポジトリから更新を正常に取得しました
...「kubescape」チャート リポジトリから更新を正常に取得しました
...「rancher-stable」チャート リポジトリから更新を正常に取得しました
...「skm」チャート リポジトリから更新を正常に取得しました
...「openkruise」チャート リポジトリから更新を正常に取得しました
...「awx-operator」チャート リポジトリから更新を正常に取得しました
...「botkube」チャート リポジトリから更新を正常に取得しました
アップデートが完了しました。 ⎈ヘルミングおめでとう！⎈
┌──[[email protected]]-[~/ansible/kube-owned]
└─$helm install --verify kube-ある程度の kubeある程度の-charts/kube-ある程度の -n ${KUBEFLEDGED_NAMESPACE} --wait

実際にデプロイする際、ネットワークの問題によりchart ダウンロードができないことが判明したため、yamlを使用してデプロイしました。 make deploy-using-yaml 

Yaml ファイルのデプロイメント

┌──[[email protected]]-[~/ansible/kube-owned]
━─$git クローン https://github.com/senthilrch/kube-ある程度.git
「kube-stead」へのクローンを作成しています...
リモート: オブジェクトの列挙: 10613、完了。
リモート: オブジェクトのカウント: 100% (1501/1501)、完了。
リモート: オブジェクトの圧縮: 100% (629/629)、完了。
リモート: 合計 10613 (デルタ 845)、再利用 1357 (デルタ 766)、パック再利用 9112
受信オブジェクト間: 100% (10613/10613)、34.58 MiB | 7.33 MiB/s、完了。
デルタ媒体の処理: 100% (4431/4431)、完了。
┌──[[email protected]]-[~/ansible/kube-owned]
└─$ls
キューブ型
┌──[[email protected]]-[~/ansible/kube-owned]
└─$cd キューブ本格/
┌──[[email protected]]-[~/ansible/kube-ある程度/kube-ある程度]
└─$makedeploy-using-yaml
kubectl apply -fdeploy/kubeある程度の名前空間.yaml

初めてデプロイしたとき、イメージをプルダウンできないことがわかりました。

┌──[[email protected]]-[~]
└─$kubectl すべてを取得 -n kube-stead
名前の準備完了ステータスが年齢を再開します
pod/kube-owned-controller-df69f6565-drrqg 0/1 CrashLoopBackOff 35 (5 時間 59 分前) 21 時間
pod/kube-owned-webhook-server-7bcd589bc4-b7kg2 0/1 Init:CrashLoopBackOff 35 (5 時間 58 分前) 21 時間
pod/kubesteady-controller-55f848cc67-7f4rl 1/1 実行中 0 21 時間
pod/kubeある程度-webhook-server-597dbf4ff5-l8fbh 0/1 Init:CrashLoopBackOff 34 (6時間前) 21h

名前 タイプ クラスター IP 外部 IP ポート 経過時間
service/kube-owned-webhook-server ClusterIP 10.100.194.199 <なし> 3443/TCP 21h
service/kubeある程度-webhook-server ClusterIP 10.101.191.206 <なし> 3443/TCP 21h

名前 準備完了 最新の利用可能年齢
デプロイメント.apps/kube-ある程度のコントローラー 0/1 1 0 21h
デプロイメント.apps/kube-ある程度のウェブフックサーバー 0/1 1 0 21h
デプロイメント.apps/kubestead-controller 0/1 1 0 21h
デプロイメント.apps/kubestead-webhook-server 0/1 1 0 21h

名前 希望する現在の準備年齢
レプリカセット.apps/kube-owned-controller-df69f6565 1 1 0 21h
レプリカセット.apps/kube-owned-webhook-server-7bcd589bc4 1 1 0 21h
レプリカセット.apps/kubestead-controller-55f848cc67 1 1 0 21h
レプリカセット.apps/kubeある程度-webhook-server-597dbf4ff5 1 1 0 21h
┌──[[email protected]]-[~]
━─$

ここでプルしたい画像を見つけます

┌──[[email protected]]-[~/ansible/kube-ある程度/kube-ある程度/deploy]
└─$cat *.yaml | grep イメージ:
      - イメージ: Senthilrch/kubestead-controller:v0.10.0
      - 画像：senthilrch/kubeある程度-webhook-server:v0.10.0
      - 画像：senthilrch/kubeある程度-webhook-server:v0.10.0

いくつかを個別にプルし、現在、すべての動作ノードでバッチ操作を使用します。 ansible 

┌──[[email protected]]-[~/ansible]
━─$ansible k8s_node -m shell -a "docker pull docker.io/senthilrch/kubeある程度-cri-client:v0.10.0" -i host.yaml

他の関連画像をプルします

操作が完了すると、コンテナのステータスはすべて正常になります。

┌──[[email protected]]-[~/ansible]
└─$kubectl -n kube-ある程度のすべてを取得
名前の準備完了ステータスが年齢を再開します
pod/kube-owned-controller-df69f6565-wdb4g 1/1 実行中 0 13 時間
pod/kube-owned-webhook-server-7bcd589bc4-j8xxp 1/1 実行中 0 13h
pod/kubesteady-controller-55f848cc67-klxlm 1/1 実行中 0 13 時間
pod/kubeある程度-webhook-server-597dbf4ff5-ktsh 1/1 実行中 0 13h

名前 タイプ クラスター IP 外部 IP ポート 経過時間
service/kube-owned-webhook-server ClusterIP 10.100.194.199 <なし> 3443/TCP 36h
service/kubeある程度-webhook-server ClusterIP 10.101.191.206 <なし> 3443/TCP 36h

名前 準備完了 最新の利用可能年齢
deployment.apps/kube-owned-controller 1/1 1 1 36h
deployment.apps/kube-owned-webhook-server 1/1 1 1 36h
deployment.apps/kubestead-controller 1/1 1 1 36h
デプロイメント.apps/kubestead-webhook-server 1/1 1 1 36h

名前 希望する現在の準備年齢
レプリカセット.apps/kube-owned-controller-df69f6565 1 1 1 36h
レプリカセット.apps/kube-owned-webhook-server-7bcd589bc4 1 1 1 36h
レプリカセット.apps/kubestead-controller-55f848cc67 1 1 1 36h
レプリカセット.apps/kubeある程度-webhook-server-597dbf4ff5 1 1 1 36h

インストールが成功したことを確認する

┌──[[email protected]]-[~/ansible/kube-ある程度/kube-ある程度]
└─$kubectl ポッドを取得 -n kube-ある程度の -l app=kubeある程度
名前の準備完了ステータスが年齢を再開します
kubestead-controller-55f848cc67-klxlm 1/1 実行中 0 16 時間
kubestead-webhook-server-597dbf4ff5-ktsh 1/1 実行中 0 16h
┌──[[email protected]]-[~/ansible/kube-ある程度/kube-ある程度]
└─$kubectl get imagecaches -n kube-ある程度
kube-ある程度の名前空間にリソースが見つかりません。

kubescalの使用

画像キャッシュオブジェクトの作成

ファイルに基づいて画像キャッシュ オブジェクトを作成します Demo 

┌──[[email protected]]-[~/ansible/kube-ある程度/kube-ある程度]
└─$cd デプロイ/
┌──[[email protected]]-[~/ansible/kube-ある程度/kube-ある程度/deploy]
└─$cat kubeある程度-imagecache.yaml
---
apiバージョン: kubestead.io/v1alpha2
種類: ImageCache
metadata:
  # 画像キャッシュの名前。クラスターには複数のイメージ キャッシュ オブジェクトを含めることができます
  名前: imagecache1
  名前空間: kube の本格的な
  # このイメージ キャッシュに使用される kubernetes 名前空間。好みに応じて別の名前空間を選択できます
  ラベル:
    アプリ: kubestrom
    kubestead: イメージキャッシュ
仕様:
  # "cacheSpec" フィールドを使用すると、ユーザーは画像のリストと、それらの画像をどのワーカー ノードにキャッシュするか (つまり、事前にプルするか) を定義できます。
  キャッシュ仕様:
  # ノード セレクターを使用せずにイメージのリスト (nginx:1.23.1) を指定します。したがって、これらのイメージはクラスター内のすべてのノードにキャッシュされます
  - 画像:
    - ghcr.io/jitesoft/nginx:1.23.1
  # ノードセレクターを使用してイメージのリスト (cassandra:v7 および etcd:3.5.4-0) を指定します。したがって、これらのイメージはノードセレクターによって選択されたノードにのみキャッシュされます。
  - 画像:
    - us.gcr.io/k8s-artifacts-prod/cassandra:v7
    - us.gcr.io/k8s-artifacts-prod/etcd:3.5.4-0
    ノードセレクター:
      層: バックエンド
  # プライベート リポジトリからキャッシュにイメージをプルするためのイメージ プル シークレットのリストを指定します
  imagePullの秘密:
  - 名前: 私のレジストリキー

公式Demoの該当画像はプルダウンできないので変更します。

┌──[[email protected]]-[~/ansible/kube-ある程度/kube-ある程度/deploy]
└─$docker pull us.gcr.io/k8s-artifacts-prod/cassandra:v7
デーモンからのエラー応答: Get "https://us.gcr.io/v2/": net/http: 接続待機中にリクエストがキャンセルされました (ヘッダー待機中に Client.Timeout を超過しました)
┌──[[email protected]]-[~/ansible/kube-ある程度/kube-ある程度/deploy]
━─$

セレクター タグの使用をテストするために、ノードのタグを見つけて、画像キャッシュを個別に実行します。

┌──[[email protected]]-[~/ansible/kube-ある程度/kube-ある程度/deploy]
└─$kubectl ノードの取得 --show-labels

同時に、イメージをパブリック ウェアハウスから直接取得するため、オブジェクトは必要ありません imagePullSecrets 

┌──[[email protected]]-[~/ansible/kube-ある程度/kube-ある程度/deploy]
└─$vim kubeある程度-imagecache.yaml

変更されたファイル yaml 

  • すべてのノードに liruilong/my-busybox:latest イメージ キャッシュを追加しました
  • タグセレクターに対応した ミラーキャッシュ を追加   kubernetes.io/hostname: vms105.liruilongs.github.io     liruilong/hikvision-sdk-config-ftp:latest   
┌──[[email protected]]-[~/ansible/kube-ある程度/kube-ある程度/deploy]
└─$cat kubeある程度-imagecache.yaml
---
apiバージョン: kubestead.io/v1alpha2
種類: ImageCache
metadata:
  # 画像キャッシュの名前。クラスターには複数のイメージ キャッシュ オブジェクトを含めることができます
  名前: imagecache1
  名前空間: kube の本格的な
  # このイメージ キャッシュに使用される kubernetes 名前空間。好みに応じて別の名前空間を選択できます
  ラベル:
    アプリ: kubestrom
    kubestead: イメージキャッシュ
仕様:
  # "cacheSpec" フィールドを使用すると、ユーザーは画像のリストと、それらの画像をどのワーカー ノードにキャッシュするか (つまり、事前にプルするか) を定義できます。
  キャッシュ仕様:
  # ノード セレクターを使用せずにイメージのリスト (nginx:1.23.1) を指定します。したがって、これらのイメージはクラスター内のすべてのノードにキャッシュされます
  - 画像:
    - liruilong/my-busybox:最新
  # ノードセレクターを使用してイメージのリスト (cassandra:v7 および etcd:3.5.4-0) を指定します。したがって、これらのイメージはノードセレクターによって選択されたノードにのみキャッシュされます。
  - 画像:
    - liruilong/hikvision-sdk-config-ftp:latest
    ノードセレクター:
      kubernetes.io/ホスト名: vms105.liruilongs.github.io
  # プライベート リポジトリからキャッシュにイメージをプルするためのイメージ プル シークレットのリストを指定します
  #imagePullSecrets:
  #- 名前: myregistrykey
┌──[[email protected]]-[~/ansible/kube-ある程度/kube-ある程度/deploy]
━─$

直接作成してエラーを報告しました

┌──[[email protected]]-[~/ansible/kube-ある程度/kube-ある程度/deploy]
━─$kubectl create -f kubeある程度-imagecache.yaml
サーバーからのエラー (InternalError): "kubestead-imagecache.yaml" の作成中にエラーが発生しました: 内部エラーが発生しました: Webhook の呼び出しに失敗しました "validate-image-cache.kubestead.io": Webhook の呼び出しに失敗しました: Post "https://kubeある程度- webhook-server.kube-ある程度の.svc:3443/validate-image-cache?timeout=1s": x509: 不明な機関によって署名された証明書 (候補機関の証明書を検証する際の「crypto/rsa: 検証エラー」が原因である可能性があります) kubestroc.io")
┌──[[email protected]]-[~/ansible/kube-ある程度/kube-ある程度/deploy]
└─$kubectl get imagecaches -n kube-ある程度
kube-ある程度の名前空間にリソースが見つかりません。
┌──[[email protected]]-[~/ansible/kube-ある程度/kube-ある程度/deploy]
━─$

解決策は、対応するオブジェクトを削除して再作成することです。

現在のプロジェクトの 1 つで解決策を見つけましたhttps://github.com/senthilrch/kube-ある程度/issues/76 issues  

これはハードコードされているように見えますが、サーバーが起動すると、新しい CA バンドルが生成され、Webhook 構成が更新されます。別のデプロイメントが発生すると、元の CA バンドルが再適用され、バンドルの init-server にパッチを適用するために Webhook コンポーネントが再起動されるまで、Webhook リクエストは失敗し始めます。 Webhook CA  webhook 

┌──[[email protected]]-[~/ansible/kube-ある程度/kube-ある程度]
└─$make 削除-kubeshelf-and-operator
# kubestrom を削除する
kubectl delete -fdeploy/kubeある程度-operator/deploy/crds/charts.helm.kubeある程度の.io_v1alpha2_kubeある程度の_cr.yaml
エラー: 名前のリソース マッピングが見つかりません: "kube-ある程度" 名前空間: "deploy/kubestead-operator/deploy/crds/charts.helm.kubeある程度.io_v1alpha2_kubeある程度_cr.yaml" の "kube-ある程度": 種類 "KubeFledged" に一致しません" バージョン "charts.helm.kubestead.io/v1alpha2"
CRD が最初にインストールされていることを確認してください
┌──[[email protected]]-[~/ansible/kube-ある程度/kube-ある程度]
└─$makedeploy-using-yaml
kubectl apply -fdeploy/kubeある程度の名前空間.yaml
名前空間/kube-owned が作成されました
kubectl apply -fdeploy/kubeある程度-crd.yaml
カスタムリソース定義.apiextensions.k8s.io/imagecaches.kubeある程度の.ioは変更されていません
…………
kubectl ロールアウト ステータス デプロイメント kubeある程度-webhook-server -n kube-ある程度 --watch
デプロイ「kubestead-webhook-server」ロールアウトが完了するのを待っています: 1 個中 0 個の更新されたレプリカが利用可能です...
デプロイメント「kubestead-webhook-server」が正常にロールアウトされました
kubectl get ポッド -n kube-ある程度の
名前の準備完了ステータスが年齢を再開します
kubestead-controller-55f848cc67-76c4v 1/1 実行中 0 112 秒
kubestead-webhook-server-597dbf4ff5-56h6z 1/1 実行中 0 66 秒

キャッシュ オブジェクトを再作成し、正常に作成します。

┌──[[email protected]]-[~/ansible/kube-ある程度/kube-ある程度/deploy]
━─$kubectl create -f kubeある程度-imagecache.yaml
imagecache.kubeある程度.io/imagecache1が作成されました
┌──[[email protected]]-[~/ansible/kube-ある程度/kube-ある程度/deploy]
└─$kubectl get imagecaches -n kube-ある程度
名前と年齢
画像キャッシュ1 10秒
┌──[[email protected]]-[~/ansible/kube-ある程度/kube-ある程度/deploy]
━─$

現在管理されている画像キャッシュを表示する

┌──[[email protected]]-[~/ansible/kube-owned]
━─$kubectl get imagecaches imagecache1 -n kube-ある程度 -o json
{
    "apiVersion": "kubestead.io/v1alpha2",
    "種類": "イメージキャッシュ",
    「メタデータ」: {
        "creationTimestamp": "2024-03-01T15:08:42Z",
        「世代」：83、
        「ラベル」: {
            "アプリ": "kubestead",
            "kubestroc": "イメージキャッシュ"
        }、
        "名前": "イメージキャッシュ1",
        "名前空間": "kube 本格的",
        "リソースバージョン": "20169836",
        "uid": "3a680a57-d8ab-444f-b9c9-4382459c5c72"
    }、
    「仕様」: {
        "キャッシュスペック": [
            {
                「画像」: [
                    "liruilong/my-busybox:最新"
                】
            }、
            {
                「画像」: [
                    "liruilong/hikvision-sdk-config-ftp:latest"
                ]、
                "ノードセレクター": {
                    "kubernetes.io/ホスト名": "vms105.liruilongs.github.io"
                }
            }
        】
    }、
    "状態"： {
        "completionTime": "2024-03-02T01:06:47Z",
        "message": "要求されたすべてのイメージがそれぞれのノードに正常にプルされました",
        "理由": "イメージキャッシュの更新",
        "startTime": "2024-03-02T01:05:33Z",
        "ステータス": "成功"
    }
}
┌──[[email protected]]-[~/ansible/kube-owned]
━─$

ansible 経由で検証する

┌──[[email protected]]-[~/ansible]
└─$ansible all -m shell -a "docker image | grep liruilong/my-busybox" -i host.yaml
192.168.26.102 |変更されました | rc=0 >>
liruilong/my-busybox 最新 497b83a63aad 11 か月前 1.24MB
192.168.26.101 |変更されました | rc=0 >>
liruilong/my-busybox 最新 497b83a63aad 11 か月前 1.24MB
192.168.26.103 |変更されました | rc=0 >>
liruilong/my-busybox 最新 497b83a63aad 11 か月前 1.24MB
192.168.26.105 |変更されました | rc=0 >>
liruilong/my-busybox 最新 497b83a63aad 11 か月前 1.24MB
192.168.26.100 |変更されました | rc=0 >>
liruilong/my-busybox 最新 497b83a63aad 11 か月前 1.24MB
192.168.26.106 |変更されました | rc=0 >>
liruilong/my-busybox 最新 497b83a63aad 11 か月前 1.24MB
┌──[[email protected]]-[~/ansible]
━─$
┌──[[email protected]]-[~/ansible]
└─$ansible all -m shell -a "docker イメージ | grep liruilong/hikvision-sdk-config-ftp" -i host.yaml
192.168.26.102 |失敗しました | rc=1 >>
ゼロ以外の戻りコード
192.168.26.100 |失敗しました | rc=1 >>
ゼロ以外の戻りコード
192.168.26.103 |失敗しました | rc=1 >>
ゼロ以外の戻りコード
192.168.26.105 |変更されました | rc=0 >>
liruilong/hikvision-sdk-config-ftp 最新 a02cd03b4342 4 ヶ月前 830MB
192.168.26.101 |失敗しました | rc=1 >>
ゼロ以外の戻りコード
192.168.26.106 |失敗しました | rc=1 >>
ゼロ以外の戻りコード
┌──[[email protected]]-[~/ansible]
━─$

自動更新をオンにする

┌──[[email protected]]-[~/ansible]
└─$kubectl annotate imagecaches imagecache1 -n kube-ある程度の kubeある程度の.io/refresh-imagecache=
imagecache.kubestead.io/imagecache1 アノテーション付き
┌──[[email protected]]-[~/ansible]
━─$

画像キャッシュを追加する

新しい画像キャッシュを追加する

┌──[[email protected]]-[~/ansible]
━─$kubectl get imagecaches.kubeある程度の.io -n kubeの本格的なimagecache1 -o json
{
    "apiVersion": "kubestead.io/v1alpha2",
    "種類": "イメージキャッシュ",
    「メタデータ」: {
        "creationTimestamp": "2024-03-01T15:08:42Z",
        「世代」: 92、
        「ラベル」: {
            "アプリ": "kubestead",
            "kubestroc": "イメージキャッシュ"
        }、
        "名前": "イメージキャッシュ1",
        "名前空間": "kube 本格的",
        "リソースバージョン": "20175233",
        "uid": "3a680a57-d8ab-444f-b9c9-4382459c5c72"
    }、
    「仕様」: {
        "キャッシュスペック": [
            {
                「画像」: [
                    "liruilong/my-busybox:最新",
                    "liruilong/jdk1.8_191:最新"
                】
            }、
            {
                「画像」: [
                    "liruilong/hikvision-sdk-config-ftp:latest"
                ]、
                "ノードセレクター": {
                    "kubernetes.io/ホスト名": "vms105.liruilongs.github.io"
                }
            }
        】
    }、
    "状態"： {
        "completionTime": "2024-03-02T01:43:32Z",
        "message": "要求されたすべてのイメージがそれぞれのノードに正常にプルされました",
        "理由": "ImageCacheUpdate",
        "startTime": "2024-03-02T01:40:34Z",
        "ステータス": "成功"
    }
}
┌──[[email protected]]-[~/ansible]
━─$

ansible 経由で確認する

┌──[[email protected]]-[~/ansible]
└─$ansible all -m shell -a "docker イメージ | grep liruilong/jdk1.8_191" -i host.yaml
192.168.26.101 |失敗しました | rc=1 >>
ゼロ以外の戻りコード
192.168.26.100 |失敗しました | rc=1 >>
ゼロ以外の戻りコード
192.168.26.102 |失敗しました | rc=1 >>
ゼロ以外の戻りコード
192.168.26.103 |失敗しました | rc=1 >>
ゼロ以外の戻りコード
192.168.26.105 |失敗しました | rc=1 >>
ゼロ以外の戻りコード
192.168.26.106 |失敗しました | rc=1 >>
ゼロ以外の戻りコード
┌──[[email protected]]-[~/ansible]
└─$ansible all -m shell -a "docker イメージ | grep liruilong/jdk1.8_191" -i host.yaml
192.168.26.101 |変更されました | rc=0 >>
liruilong/jdk1.8_191 最新 17dbd4002a8c 5 年前 170MB
192.168.26.102 |変更されました | rc=0 >>
liruilong/jdk1.8_191 最新 17dbd4002a8c 5 年前 170MB
192.168.26.100 |変更されました | rc=0 >>
liruilong/jdk1.8_191 最新 17dbd4002a8c 5 年前 170MB
192.168.26.103 |変更されました | rc=0 >>
liruilong/jdk1.8_191 最新 17dbd4002a8c 5 年前 170MB
192.168.26.105 |変更されました | rc=0 >>
liruilong/jdk1.8_191 最新 17dbd4002a8c 5 年前 170MB
192.168.26.106 |変更されました | rc=0 >>
liruilong/jdk1.8_191 最新 17dbd4002a8c 5 年前 170MB
┌──[[email protected]]-[~/ansible]
━─$

画像キャッシュを削除する

┌──[[email protected]]-[~/ansible]
━─$kubectl edit imagecaches imagecache1 -n kube-ある程度
imagecache.kubeある程度.io/imagecache1を編集しました
┌──[[email protected]]-[~/ansible]
━─$kubectl get imagecaches.kubeある程度の.io -n kubeの本格的なimagecache1 -o json
{
    "apiVersion": "kubestead.io/v1alpha2",
    "種類": "イメージキャッシュ",
    「メタデータ」: {
        "creationTimestamp": "2024-03-01T15:08:42Z",
        「世代」：94、
        「ラベル」: {
            "アプリ": "kubestead",
            "kubestroc": "イメージキャッシュ"
        }、
        "名前": "イメージキャッシュ1",
        "名前空間": "kube 本格的",
        "リソースバージョン": "20175766",
        "uid": "3a680a57-d8ab-444f-b9c9-4382459c5c72"
    }、
    「仕様」: {
        "キャッシュスペック": [
            {
                「画像」: [
                    "liruilong/jdk1.8_191:最新"
                】
            }、
            {
                「画像」: [
                    "liruilong/hikvision-sdk-config-ftp:latest"
                ]、
                "ノードセレクター": {
                    "kubernetes.io/ホスト名": "vms105.liruilongs.github.io"
                }
            }
        】
    }、
    "状態"： {
        "message": "画像キャッシュを更新中です。しばらくしてからステータスを確認してください",
        "理由": "ImageCacheUpdate",
        "startTime": "2024-03-02T01:48:03Z",
        "ステータス": "処理中"
    }
}

Ansible で確認すると、マスター上のノードでもワークノードでも、対応する画像キャッシュがクリアされていることがわかります。

┌──[[email protected]]-[~/ansible]
└─$ansible all -m shell -a "docker image | grep liruilong/my-busybox" -i host.yaml
192.168.26.102 |変更されました | rc=0 >>
liruilong/my-busybox 最新 497b83a63aad 11 か月前 1.24MB
192.168.26.101 |変更されました | rc=0 >>
liruilong/my-busybox 最新 497b83a63aad 11 か月前 1.24MB
192.168.26.105 |失敗しました | rc=1 >>
ゼロ以外の戻りコード
192.168.26.100 |変更されました | rc=0 >>
liruilong/my-busybox 最新 497b83a63aad 11 か月前 1.24MB
192.168.26.103 |失敗しました | rc=1 >>
ゼロ以外の戻りコード
192.168.26.106 |失敗しました | rc=1 >>
ゼロ以外の戻りコード
┌──[[email protected]]-[~/ansible]
└─$ansible all -m shell -a "docker image | grep liruilong/my-busybox" -i host.yaml
192.168.26.105 |失敗しました | rc=1 >>
ゼロ以外の戻りコード
192.168.26.102 |失敗しました | rc=1 >>
ゼロ以外の戻りコード
192.168.26.103 |失敗しました | rc=1 >>
ゼロ以外の戻りコード
192.168.26.101 |失敗しました | rc=1 >>
ゼロ以外の戻りコード
192.168.26.100 |失敗しました | rc=1 >>
ゼロ以外の戻りコード
192.168.26.106 |失敗しました | rc=1 >>
ゼロ以外の戻りコード
┌──[[email protected]]-[~/ansible]
━─$

ここで注意すべき点は、画像キャッシュをすべてクリアする場合は、以下の配列を「」と記述する必要があることです。 images 

┌──[[email protected]]-[~/ansible]
━─$kubectl edit imagecaches imagecache1 -n kube-ある程度
imagecache.kubeある程度.io/imagecache1を編集しました
┌──[[email protected]]-[~/ansible]
└─$ansible all -m shell -a "docker イメージ | grep liruilong/jdk1.8_191" -i host.yaml
192.168.26.102 |失敗しました | rc=1 >>
ゼロ以外の戻りコード
192.168.26.101 |失敗しました | rc=1 >>
ゼロ以外の戻りコード
192.168.26.100 |失敗しました | rc=1 >>
ゼロ以外の戻りコード
192.168.26.105 |失敗しました | rc=1 >>
ゼロ以外の戻りコード
192.168.26.103 |失敗しました | rc=1 >>
ゼロ以外の戻りコード
192.168.26.106 |失敗しました | rc=1 >>
ゼロ以外の戻りコード
┌──[[email protected]]-[~/ansible]
━─$kubectl get imagecaches.kubeある程度の.io -n kubeの本格的なimagecache1 -o json
{
    "apiVersion": "kubestead.io/v1alpha2",
    "種類": "イメージキャッシュ",
    「メタデータ」: {
        "creationTimestamp": "2024-03-01T15:08:42Z",
        「世代」: 98、
        「ラベル」: {
            "アプリ": "kubestead",
            "kubestroc": "イメージキャッシュ"
        }、
        "名前": "イメージキャッシュ1",
        "名前空間": "kube 本格的",
        "リソースバージョン": "20176849",
        "uid": "3a680a57-d8ab-444f-b9c9-4382459c5c72"
    }、
    「仕様」: {
        "キャッシュスペック": [
            {
                「画像」: [
                    「」
                】
            }、
            {
                「画像」: [
                    "liruilong/hikvision-sdk-config-ftp:latest"
                ]、
                "ノードセレクター": {
                    "kubernetes.io/ホスト名": "vms105.liruilongs.github.io"
                }
            }
        】
    }、
    "状態"： {
        "completionTime": "2024-03-02T01:52:16Z",
        "message": "キャッシュされたすべてのイメージがそれぞれのノードから正常に削除されました",
        "理由": "ImageCacheUpdate",
        "startTime": "2024-03-02T01:51:47Z",
        "ステータス": "成功"
    }
}
┌──[[email protected]]-[~/ansible]
━─$

以下の方法で削除した場合は、該当タグを直接コメント化してください

┌──[[email protected]]-[~/ansible/kube-ある程度/kube-ある程度/deploy]
└─$cat kubeある程度-imagecache.yaml
---
apiバージョン: kubestead.io/v1alpha2
種類: ImageCache
metadata:
  # 画像キャッシュの名前。クラスターには複数のイメージ キャッシュ オブジェクトを含めることができます
  名前: imagecache1
  名前空間: kube の本格的な
  # このイメージ キャッシュに使用される kubernetes 名前空間。好みに応じて別の名前空間を選択できます
  ラベル:
    アプリ: kubestrom
    kubestead: イメージキャッシュ
仕様:
  # "cacheSpec" フィールドを使用すると、ユーザーは画像のリストと、それらの画像をどのワーカー ノードにキャッシュするか (つまり、事前にプルするか) を定義できます。
  キャッシュ仕様:
  # ノード セレクターを使用せずにイメージのリスト (nginx:1.23.1) を指定します。したがって、これらのイメージはクラスター内のすべてのノードにキャッシュされます
  #- 画像:
    #- liruilong/my-busybox:最新
  # ノードセレクターを使用してイメージのリスト (cassandra:v7 および etcd:3.5.4-0) を指定します。したがって、これらのイメージはノードセレクターによって選択されたノードにのみキャッシュされます。
  - 画像:
    - liruilong/hikvision-sdk-config-ftp:latest
    ノードセレクター:
      kubernetes.io/ホスト名: vms105.liruilongs.github.io
  # プライベート リポジトリからキャッシュにイメージをプルするためのイメージ プル シークレットのリストを指定します
  #imagePullSecrets:
  #- 名前: myregistrykey
┌──[[email protected]]-[~/ansible/kube-ある程度/kube-ある程度/deploy]
━─$

その後、次のエラーが報告されます

┌──[[email protected]]-[~/ansible/kube-ある程度/kube-ある程度/deploy]
━─$kubectl edit imagecaches imagecache1 -n kube-ある程度
エラー: imagecaches.kubestead.io "imagecache1" にパッチを適用できませんでした: 受付 Webhook "validate-image-cache.kubeある程度の.io" がリクエストを拒否しました: no が一致しません。画像リストの
「kubectl replace -f /tmp/kubectl-edit-4113815075.yaml」を実行して、この更新をもう一度試すことができます。

ブログ投稿の一部を参照

© この記事内の参考リンクの著作権は元の著者に帰属します。侵害がある場合は、スターを付けないでください。

https://github.com/senthilrch/kube-ある程度

 

クリックしてフォローし、できるだけ早くHuawei Cloudの新しいテクノロジーについて学びましょう~

 

仲間のニワトリがDeepin-IDE を 「オープンソース」化し、ついにブートストラップを達成しました。 いい奴だ、Tencent は本当に Switch を「考える学習機械」に変えた Tencent Cloud の 4 月 8 日の障害レビューと状況説明 RustDesk リモート デスクトップ起動の再構築 Web クライアント WeChat の SQLite ベースのオープンソース ターミナル データベース WCDB がメジャー アップグレードを開始 TIOBE 4 月リスト: PHPは史上最低値に落ち、 FFmpeg の父であるファブリス ベラールはオーディオ圧縮ツール TSAC をリリースし 、Google は大規模なコード モデル CodeGemma をリリースしました 。それはあなたを殺すつもりですか?オープンソースなのでとても優れています - オープンソースの画像およびポスター編集ツール
{{名前}}
{{名前}}

おすすめ

転載: my.oschina.net/u/4526289/blog/11052468
おすすめ
openKylinコミュニティ生態委員会の第6回会議が無事に開催されました
Alibaba Cloud、Tongyi Qianwen 2.5を正式リリース
Python 3.13 が最初のベータ版をリリース: 実験的なフリー スレッド モードと JIT、改善された対話型インタープリター
Stack Overflow は私のコードを使用して大規模な AI モデルをトレーニングし、私のアカウントを禁止しました。
Pop!_OS の COSMIC デスクトップが App Store のリストに掲載される
レポート: Django は依然として 74% の開発者にとって第一の選択肢です
「2024年第1四半期のインターネット投融資業務」調査レポート
15 年前、彼は「FFmpeg 恥の柱」に立っていたのに、今でも私たちに感謝しなければなりません - Tencent QQPlayer はその恥を晴らしますか?
ランキング
ブルーブリッジカップクロップハイブリッド（再帰的）
java线程、线程池
关于毕业前后的道路
JVMの基本
OpenCV ヒストグラムの原理と表示、マスキング、イコライゼーション、適応イコライゼーション
PHPのAES暗号化と復号化、MCRYPT_ENCRYPTとopenssl_encrypt
スコアボードを回転poj3335
Vueで要求されたデータ：タイムスタンプ変換時間
Javaの合併のpng画像
HttpServletResponseアプリケーションリクエストのリダイレクト
アーカイブ
もっと
2024-05-10(33)
2024-05-09(30)
2024-05-08(18)
2024-05-07(34)
2024-05-06(6)
2024-05-05(0)
2024-05-04(18)
2024-05-03(8)
2024-05-02(0)
2024-05-01(4)

コードワールド

© 2018 codetd.com