Rapid recovery of data volume mount problems

Pod のデータボリュームのアタッチとアンマウントに問題が発生する原因はさまざまです。ストレージボリュームの設計上の欠陥、関連コンポーネントの実装バグ、および不適切な使用が考えられます。複雑なアプリケーションとストレージの連携システムにおいては、データボリュームの問題に 2 つの観点から取り組む必要があります。

問題を回避する：ストレージコンポーネントの安定性を高め、仕様に沿った使用を徹底する。

問題に直面したとき：まずビジネスを迅速に復旧させ、その後で問題を分析する。

この記事では、迅速なサービス復旧の方法について説明します。データボリュームのマウント障害により Pod が再起動できない場合、問題のあるノードのマウント問題は一時的に解決せず、Pod を別のノードで正常に起動させてサービスを迅速に復旧し、サービスの復旧後に問題のあるノードを分析します。

Pod を更新した際に ContainerCreating 状態で停止する：

たとえば、Deployment タイプのアプリケーションで NAS データボリュームをマウントしている場合、Pod の更新時に Pod がマウント失敗のエラーを報告することがあります。

Warning FailedMount 18s kubelet, cn-shenzhen.192.168.1.24 Unable to mount volumes for pod "nas-static-796b49b5f8-svbvh_default(2d483078-1400-11ea-a9b7-00163e084110)":
timeout expired waiting for volumes to attach or mount for pod "default"/"nas-static-796b49b5f8-svbvh".
list of unmounted volumes=[pvc-nas]. list of unattached volumes=[pvc-nas default-token-9v9hl]

更新前はデータボリュームを正常に使用できていましたが、更新後に Pod が起動できなくなります。前述のメッセージは、データボリュームがマウントできないことを示しています。現在の Pod が配置されているノードで、この PV/PVC のステータスに異常が発生している可能性があります。異常の具体的な原因はここでは調査しません。

Pod を別のノードにスケジュールして迅速に起動させるには、次の手順を参照してください。

1. Pod が配置されているノードを特定する：

前述のエラー情報から、ノード：cn-shenzhen.192.168.1.24 を取得できます。

次の手順で取得することもできます。

# podname="nas-static-796b49b5f8-svbvh"
# namespace="default"
# kubectl describe pod $podname -n $namespace | grep Node: | awk '{print $2}'

cn-shenzhen.192.168.1.24/192.168.1.24

2. ノードをスケジュール不可に設定する：

コンソールを使用してノードのスケジューリング状態を設定できます。次を参照してください。

次のコマンドラインを使用して、現在のマウント問題のあるノードにテインラベルを付け、Pod がこのノードに再度スケジュールされないようにすることもできます。

# kubectl taint nodes cn-shenzhen.192.168.1.24 key=value:NoSchedule

node/cn-shenzhen.192.168.1.24 tainted

3. 問題のある Pod を再起動する：

この時点で問題のある Pod を再起動すると、新しい Pod は問題のあるノードにスケジュールされなくなります。

問題のある Pod を削除する：

# kubectl delete pod nas-static-796b49b5f8-svbvh

pod "nas-static-796b49b5f8-svbvh" deleted

新しい Pod が正常に起動し、新しいノードにスケジュールされます。

# kubectl get pod

NAME READY STATUS RESTARTS AGE

nas-static-857b99fcc9-vvzkx 1/1 Running 0 14s

# kubectl describe pod nas-static-857b99fcc9-vvzkx | grep Node

Node: cn-shenzhen.192.168.1.25/192.168.1.25

4. 後続の処理：

前述の手順はビジネスの迅速な復旧を目的としていますが、問題のあるノード自体の課題は依然として残っています。[一般的なストレージの問題]() を参照して、調査と分析を行うことができます。

ノードの問題を解決できない場合は、Alibaba Cloud Container Service のテクニカル サポートに連絡できます。ノードの問題が解決した後、コンソールまたはコマンドラインから問題のあるノードをスケジュール可能な状態に設定できます。

# kubectl taint nodes cn-shenzhen.192.168.1.24 key:NoSchedule-

node/cn-shenzhen.192.168.1.24 untainted

Pod を更新した際に Terminating 状態で停止する：

たとえば、StatefulSet でアプリケーションを作成し、クラウド ディスクのデータボリュームをマウントしている場合、アプリケーションの更新時に Pod がずっと Terminating 状態のままになり、新しい Pod が正常に起動できなくなることがあります。

# kubectl delete pod web-0

# kubectl get pod

NAME READY STATUS RESTARTS AGE

web-0 0/1 Terminating 0 47m

Pod が配置されているノードに移動して、次のログファイルを確認します。

# tailf /var/log/alicloud/flexvolume_ disk.log

# tailf /var/log/messages | grep kubelet

エラーがデータボリュームのアンマウントや接続の失敗によるものであることが判明した場合、たとえば：

unmount command failed, status: Failure, reason:

Device is busy
or
Target is busy
or
Orphan Pod
wait

まだ問題の解決策が見つかっていない段階で緊急にビジネスを復旧させる必要がある場合は、問題のある Pod を強制削除して、まずビジネスを回復させることができます。

1. 強制削除コマンドを使用して現在の Pod を終了する：

# kubectl delete pod web-0 --force=true --grace-period=0

pod "web-0" force deleted

このコマンドにより、etcd データベースから Pod 情報が強制的に削除され、新しい Pod の作成が可能になります（StatefulSet では、古い Pod が削除されるまで新しい Pod は再構築されません）。


2. 新しい Pod が起動に失敗し、ContainerCreating 状態で停止している場合：

前述の「Pod を更新した際に ContainerCreating 状態で停止する」の手順を参照し、ノードをスケジュール不可に設定して、Pod を迅速に復旧させることができます。

3. 問題のあるノードにログインし、原因を分析する：

問題が発生しているノードにログインし、[ストレージのよくある質問]() を参照してトラブルシューティングと分析を行います。問題が解決しない場合は、Alibaba Cloud Container Service のテクニカル サポートに連絡してください。