なにがあったのか
- serverおよびagentで構成されたクラスタのRKE2のバージョンを上げた
- 更新そのものは成功し、基本的なアプリケーションのPodとContainerは問題なく起動した
- PVに依存する一部のContainerだけ何故かタイムアウトで上がってこなくなってしまった
- PVのストレージにはlonghornを使用
更新後、クラスタの上に建てたMySQLのPodの様子がおかしくなる
発生していた事象としては↑の記事とほぼ同じで、ContainerCreatingから進まなくなってしまうという事象でした。
内部のコンテナが上がってこないのでMySQLのPodは死んでいる状態になっています。
$ kubectl describe mysql8-db-0 -n database
....
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedMount 7m18s (x151 over 7h40m) kubelet Unable to attach or mount volumes: unmounted volumes=[data], unattached volumes=[xxxxxxxxxxxx]: timed out waiting for the condition
Warning FailedMount 2m47s (x51 over 7h38m) kubelet Unable to attach or mount volumes: unmounted volumes=[data], unattached volumes=[xxxxxxxxxxxx]: timed out waiting for the condition
どうやらタイムアウトしているらしい....? PVのストレージに使っているlonghornが死んでいる....?
といろいろ疑います。
しかし同じlonghornのストレージに載っているRedisは問題なく起き上がってきます。なにかがおかしいですね。
$ kubectl get pvc -A
NAMESPACE NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
database data-mysql8-db-0 Bound pvc-xxxxxxxx 8Gi RWO longhorn 105d
database redis-data-redis-server-master-0 Bound pvc-xxxxxxxx 8Gi RWO longhorn 105d
Statusも異常なし、ログを見ても異常なし... どう考えても何かがおかしい....
試行錯誤の末、PVを残した状態でMySQLのPodを作り直すことに
MySQLの運用に必要なデータは全て永続化ボリュームの中に格納されているので、これを削除しなければ問題なくサービスを再開出来るのでは？ということで作業を進めます。
(通常であれば、更新前やこういった破壊的な作業の前にはデータのバックアップはきちんと取った方が良いですが、今回趣味で作ってる奴だしということで横着してやりませんでした。ちゃんとバックアップは取りましょう！)
というわけで、MySQLのPodはhelmとhelmfileで管理していたのでhelmから消してあげます。
必ずSCのreclaimPolicyとPVCのpersistentVolumeReclaimPolicyがRetainになっていることを確認した上で実行してください。
(ポリシーがdeleteになっていたりrecycleになっていると、helm deleteを実行した際にPVごと消えてしまうので注意しましょう)
$ helm delete mysql8-db --namespace=database
削除して... helmfileを管理しているレポジトリに入り、helmfileから作り直しをやります。
$ helmfile apply
しばらく待つとPodが上がってきます。
$ kubectl get pods -n database
NAME READY STATUS RESTARTS AGE
mysql8-db-0 1/1 Running 0 53m
redis-server-master-0 1/1 Running 0 53m
生き返りましたね。
しっかり元通りになっていることを確認して一安心して今回のトラブルシューティングは終了！