IK.AM

@making's tech note


Tanzu Application PlatformでClusterBuilderのReadyがFalseから直らないときの対処メモ

🗃 {Dev/CaaS/Kubernetes/TAP}
🏷 Kubernetes 🏷 Tanzu Build Service 🏷 Tanzu 🏷 TAP 🏷 kpack 
🗓 Updated at 2023-02-17T08:10:37Z  🗓 Created at 2022-12-13T11:08:55Z   🌎 English Page

⚠️ 本記事の内容はVMwareによってサポートされていません。 記事の内容で生じた問題については自己責任で対応し、 VMwareサポート窓口には問い合わせないでください

気付いたらClusterBuilderのReadyがFalseになってimageのbuildが進まないことがある。特にk8sを再起動したときなど。次のような状態になり、

$ kubectl get clusterbuilder                                              
NAME         LATESTIMAGE                                                                                                                     READY
base         ghcr.io/making/buildservice:clusterbuilder-base@sha256:6f6f2178be677884e78353eb39bf37cc55b0f7483cc59740e50dbf958dec7f65         False
base-jammy   ghcr.io/making/buildservice:clusterbuilder-base-jammy@sha256:064c5d5314dd9357a7978e41f62f8d44b6ffc2cf18fba78a73d85ebc25d8d51e   False
default      ghcr.io/making/buildservice:clusterbuilder-default@sha256:6f6f2178be677884e78353eb39bf37cc55b0f7483cc59740e50dbf958dec7f65      False

"dial tcp: lookup xxxx: i/o timeout" の場合

次のようなエラーメッセージが出力される場合、

$ kubectl get clusterbuilder base -ojsonpath='{.status.conditions}' | jq .
[
  {
    "lastTransitionTime": "2022-12-08T12:13:35Z",
    "message": "failed to fetch lifecycle image: Get \"https://registry.tanzu.vmware.com/v2/\": dial tcp: lookup registry.tanzu.vmware.com: i/o timeout",
    "status": "False",
    "type": "Ready"
  }
]

放っておいても直らないが、kpack-controllerを再起動すると直る

kubectl rollout restart -n kpack deployment kpack-controller 

再起動すればReadyはTrueに戻る。

$ kubectl get clusterbuilder                                  
NAME         LATESTIMAGE                                                                                                                     READY
base         ghcr.io/making/buildservice:clusterbuilder-base@sha256:6f6f2178be677884e78353eb39bf37cc55b0f7483cc59740e50dbf958dec7f65         True
base-jammy   ghcr.io/making/buildservice:clusterbuilder-base-jammy@sha256:064c5d5314dd9357a7978e41f62f8d44b6ffc2cf18fba78a73d85ebc25d8d51e   True
default      ghcr.io/making/buildservice:clusterbuilder-default@sha256:6f6f2178be677884e78353eb39bf37cc55b0f7483cc59740e50dbf958dec7f65      True

"lifecycle image has not been loaded" の場合

次のようなエラーメッセージが出力される場合、

$ kubectl get clusterbuilder base -ojsonpath='{.status.conditions}' | jq .
[
  {
    "lastTransitionTime": "2023-02-15T03:48:10Z",
    "message": "lifecycle image has not been loaded",
    "status": "False",
    "type": "Ready"
  }
]

Package Repositoryを変更した場合に発生する。

 kubectl get configmap lifecycle-image -n kpack -ojsonpath='{.data.image}'

の結果がおそらく古いRepositoryを指している。削除してbuild serviceをreconcileすれば新しいimageでConfigMapが再作成される。

kubectl delete configmap lifecycle-image -n kpack
kctrl app kick -n tap-install -a buildservice -y

その後、kpack-controllerを再起動すると直る

kubectl rollout restart -n kpack deployment kpack-controller 
$ kubectl get clusterbuilder                                  
NAME         LATESTIMAGE                                                                                                                     READY
base         ghcr.io/making/buildservice:clusterbuilder-base@sha256:6f6f2178be677884e78353eb39bf37cc55b0f7483cc59740e50dbf958dec7f65         True
base-jammy   ghcr.io/making/buildservice:clusterbuilder-base-jammy@sha256:064c5d5314dd9357a7978e41f62f8d44b6ffc2cf18fba78a73d85ebc25d8d51e   True
default      ghcr.io/making/buildservice:clusterbuilder-default@sha256:6f6f2178be677884e78353eb39bf37cc55b0f7483cc59740e50dbf958dec7f65      True

✒️️ Edit  ⏰ History  🗑 Delete