Portworx の障害のデバッグ
Portworx をデバッグするオプションを確認し、障害の根本原因を探します。
ストレージ・インスタンスをマウントするポッドが正常にデプロイされているかどうかの確認
手順に従って、ポッド・デプロイメントに関連するエラー・メッセージを確認します。
-
クラスター内のポッドをリストします。 ポッドで Running の状況が示される場合、ポッドは正常にデプロイされています。
oc get pods -
ポッドの詳細を取得し、CLI 出力の Events セクションに表示されているエラー・メッセージがないか確認します。
oc describe pod <pod_name> -
ポッドのログを取得し、エラー・メッセージがないか確認します。
oc logs <pod_name>
アプリ・ポッドの再始動
ポッドを再始動して再デプロイすると問題を解決できる場合があります。 手順に従って、特定のポッドを再デプロイします。
-
ポッドがデプロイメントの一部である場合は、ポッドを削除し、デプロイメントでポッドをビルドし直します。 ポッドがデプロイメントの一部ではない場合、ポッドを削除して、ポッドの構成ファイルを再適用します。
- ポッドを削除します。
oc delete pod <pod_name> ``` 出力例 ```sh {: screen} pod "nginx" deleted ``` 2. 構成ファイルを再適用して、ポッドを再デプロイします。 ```sh {: pre} oc apply -f <app.yaml> ``` 出力例 ```sh {: pre} pod/nginx created ``` -
ポッドを再始動しても問題が解決しない場合は、ワーカー・ノードを再ロードします。
-
IBM Cloud と IBM Cloud Kubernetes Service のプラグインの最新バージョンを使用していることを確認します。
ibmcloud updateibmcloud plugin repo-pluginsibmcloud plugin update
Portworx ストレージ・ドライバーおよびプラグインのポッドで、Running の状況が示されることの確認
手順に従って、ストレージ・ドライバーおよびプラグイン・ポッドの状況を確認し、エラー・メッセージを確認します。
kube-systemプロジェクトのポッドをリストします。
出力例:oc get pods -n kube-system | grep `portworx\|stork`portworx-594rw 1/1 Running 0 20h portworx-rn6wk 1/1 Running 0 20h portworx-rx9vf 1/1 Running 0 20h stork-6b99cf5579-5q6x4 1/1 Running 0 20h stork-6b99cf5579-slqlr 1/1 Running 0 20h stork-6b99cf5579-vz9j4 1/1 Running 0 20h stork-scheduler-7dd8799cc-bl75b 1/1 Running 0 20h stork-scheduler-7dd8799cc-j4rc9 1/1 Running 0 20h stork-scheduler-7dd8799cc-knjwt 1/1 Running 0 20h- ストレージ・ドライバーとプラグインのポッドに実行中 (Running) 状況が表示されない場合は、ポッドの詳細を取得して、根本原因を見つけます。 ポッドの状況によっては、以下のすべてのコマンドを実行できない場合があります。
- ドライバー・ポッドで実行されるコンテナーの名前を取得します。
kubectl describe pod <pod_name> -n kube-system ``` 2. ドライバー・ポッドからローカル・マシン上の `logs.txt` ファイルに、ログをエクスポートします。 ```sh {: pre} oc logs <pod_name> -n kube-system > logs.txt ``` 3. ログ・ファイルを確認します。 ```sh {: pre} cat logs.txt ``` - 最新のログにエラー・メッセージがないか調べます。 Portworx のトラブルシューティング資料で、一般的なエラーの解決手順を確認します。
oc CLI バージョンを確認して更新する
少なくともクラスターの major.minor バージョンと同じ oc CLI バージョンを使用しないと、予期しない結果になる可能性があります。 たとえば、 Kubernetes 対応していません oc のクライアントバージョンが、サーバーバージョンから2バージョン以上離れている場合(n
± 2)などです。
-
ローカル・マシンで実行する
ocCLI バージョンが、クラスターにインストールされている Kubernetes のバージョンと一致することを確認します。 クラスターおよびローカル・マシンにインストールされているocCLI バージョンを表示します。oc version出力例:
Client Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.35", GitCommit:"641856db18352033a0d96dbc99153fa3b27298e5", GitTreeState:"clean", BuildDate:"2019-03-25T15:53:57Z", GoVersion:"go1.12.1", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.35+IKS", GitCommit:"e15454c2216a73b59e9a059fd2def4e6712a7cf0", GitTreeState:"clean", BuildDate:"2019-04-01T10:08:07Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"}CLI バージョンが一致するのは、クライアントとサーバーの
GitVersionに同じバージョンが表示される場合です。 サーバーのバージョンの+IKS部分は無視できます。 -
ローカルマシンとクラスタの
ocCLIのバージョンが一致しない場合は、クラスタを更新するか、 ローカルマシンに別のバージョンのCLIをインストールしてください。
Helm チャートの更新
-
最新の Helm チャート・バージョンを見つけます。
-
クラスターにインストールされた Helm チャートをリストし、インストールしたバージョンと最新バージョンを比較します。
helm list --all-namespaces -
より新しいバージョンが使用可能な場合は、新しいバージョンをインストールします。 手順については、クラスター内の Portworx の更新を参照してください。