Longhorn クラウドネイティブコンテナ分散ストレージ - トラブルシューティングガイド

[[429654]]

Longhornボリュームファイルシステムが破損すると、Podは作成状態のままになります。
非標準の Kubelet ディレクトリ
Longhornのデフォルト設定は保持されない
ボリュームをデタッチしてアタッチした後、定期的なジョブは新しいジョブを作成しません。
Traefik 2.x をイングレスコントローラとして使用する
cURL を使用してサポートバンドルを作成する
Longhorn RWXの共有マウント所有権は消費者向けポッドでは誰も表示されません
ノード上のマルチパスが原因でボリュームの MountVolume.SetUp が失敗する
Longhorn-UI: WebSocket ハンドシェイク中にエラーが発生しました: 予期しない応答コード: 200 #2265
Longhornボリュームのマウントには長い時間がかかります
ボリューム読み取り専用またはI/Oエラー
ボリューム pvc-xxx はスケジュールされていません

1. Longhornボリュームファイルシステムが破損すると、Podは作成状態のままになる

適用可能なバージョン

すべての Longhorn バージョン。

症状

ポッドはコンテナの作成中に停止し、ログにエラーが記録されます。

警告 FailedMount 30 秒 (63 秒を超える x7)ボリューム"pvc-bb8582d5-eaa4-479a-b4bf-328d1ef1785d"のkubelet MountVolume.SetUp が失敗しました: rpc エラー: コード = 内部説明= 'fsck'はデバイス /dev/longhorn/pvc-bb8582d5-eaa4-479a-b4bf-328d1ef1785dでエラーを検出しましたが、修正できませんでした: fsck from util-linux 2.31.1
 ext2fs_check_if_mount: /dev/longhorn/pvc-bb8582d5-eaa4-479a-b4bf-328d1ef1785dがマウントされているかどうかを判断中に、mtab ファイルが見つからないため、ファイルシステムがマウントされているかどうかを確認できません。
 /dev/longhorn/pvc-bb8582d5-eaa4-479a-b4bf-328d1ef1785d にはエラーのあるファイル システムが含まれているため、強制的にチェックされます。
 /dev/longhorn/pvc-bb8582d5-eaa4-479a-b4bf-328d1ef1785d:破損した孤立したリンク リストの一部であった i ノードが見つかりました。 
 
 /dev/longhorn/pvc-bb8582d5-eaa4-479a-b4bf-328d1ef1785d: 予期しない不整合; fsck を手動で実行します。
  (つまり、-aまたは-p オプションなし)

理由

Longhorn ボリュームのファイルシステムが破損すると、Longhorn はボリュームを再マウントできなくなります。したがって、ワークロードを再起動することはできません。

Longhorn ではこの問題を自動的に修正することはできません。このような場合は、問題を手動で解決する必要があります。

解決

注意すべき兆候:

ボリュームがエラー状態でない場合は、Longhorn ボリューム内のファイルシステムが外部的な理由により破損している可能性があります。
- Longhorn UI からボリュームがエラー状態かどうかを確認します。
- Longhorn マネージャーポッドログでシステム破損エラーメッセージを確認します。
作業負荷を軽減します。
UI からボリュームを任意のノードに接続します。
ノードに SSH で接続します。
/dev/longhorn/ の下にある Longhorn ボリュームに対応するブロックデバイスを見つけます。
fsck を実行してファイルシステムを修復します。
ボリュームを UI から切り離します。
作業負荷を拡大します。

2. 非標準の Kubelet ディレクトリ

適用可能なバージョン

すべての Longhorn バージョン。

症状

Kubernetes クラスターが非標準の Kubelet ディレクトリを使用すると、longhorn-csi-plugin は起動に失敗します。

 ip-172-30-0-73:/home/ec2-ユーザー# kubectl -n longhorn-system ポッドを取得します
名前準備完了 ステータス 再起動 年齢
longhorn-ui-5b864949c4-4sgws 1/1 実行中 0 7分35秒
longhorn-manager-tx469 1/1 実行中 0 7分35秒
longhorn-driver-deployer-5444f75b8f-kgq5v 1/1 実行中 0 7分35秒
longhorn-csi-plugin-s4fg7 0/2 コンテナ作成 0 6分59秒
instance-manager-r-d185a1e9 1/1 実行中 0 7分10秒
instance-manager-e-b5e69e2d 1/1 実行中 0 7分10秒
csi-attacher-7d975797bc-qpfrv 1/1 実行中 0 7m
 csi-snapshotter-7dbfc7ddc6-nqqtg 1/1 実行中 0 6分59秒
csi-attacher-7d975797bc-td6tw 1/1 実行中 0 7m
 csi-resizer-868d779475-v6jvv 1/1 実行中 0 7 メートル
csi-resizer-868d779475-2bbs2 1/1 実行中 0 7m
 csi-provisioner-5c6845945f-46qnb 1/1 実行中 0 7 メートル
csi-resizer-868d779475-n5vjn 1/1 実行中 0 7分
csi-provisioner-5c6845945f-fjnrq 1/1 実行中 0 7 メートル
csi-snapshotter-7dbfc7ddc6-mhfpl 1/1 実行中 0 6分59秒
csi-provisioner-5c6845945f-4lx5c 1/1 実行中 0 7 メートル
csi-attacher-7d975797bc-flldq 1/1 実行中 0 7m
 csi-snapshotter-7dbfc7ddc6-cms2v 1/1 実行中 0 6分59秒
engine-image-ei-611d1496-dlqcs 1/1 実行中 0 7分10秒

理由

Longhorn は Kubelet のルートディレクトリが設定されている場所を検出できないためです。

解決

Longhorn は longhorn.yaml 経由でインストールされます:

コメントを外して編集:

 #-名前: KUBELET_ROOT_DIR
 # 値: /var/lib/rancher/k3s/agent/kubelet

Longhorn は Rancher - アプリ経由でインストールされます:

Kubeletのルートディレクトリを設定するには、デフォルト設定のカスタマイズをクリックします。
関連情報
Longhorn の問題:

https://github.com/longhorn/longhorn/issues/2537

詳細については、OS/ディストリビューション固有の構成のトラブルシューティングセクションを参照してください。

3. Longhornのデフォルト設定は保持されない

適用可能なバージョン

すべての Longhorn バージョン。

症状

Helm または Rancher アプリを介して Longhorn システムをアップグレードする場合、変更された Longhorn のデフォルトは保持されません。
kubectl -n longhorn-system edit configmap longhorn-default-setting を使用してデフォルト設定を変更しても、その変更は Longhorn システムに適用されません。

背景

このデフォルト設定は、まだ展開されていない Longhorn システムにのみ適用されます。既存の Longhorn システムには影響はありません。

解決

既存のクラスターの Longhorn 設定を変更するには、Longhorn UI を使用することをお勧めします。

kubectl を使用することもできますが、これにより Longhorn バックエンドの認証がバイパスされることに注意してください。

kubectl 設定の編集-n ロングホーンシステム

4. ボリュームをデタッチしてアタッチした後、定期的なジョブは新しいジョブを作成しません。

適用可能なバージョン

すべての Longhorn バージョン。

症状

ボリュームが長期間切断された後に接続されると、繰り返しジョブは新しいジョブを作成しません。

Kubernetes CronJob の制限によると:

https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/#cron-job-limitations

各 CronJob について、CronJob コントローラは、最後にスケジュールされた時刻から現在までの期間に、実行されなかったスケジュールの数を確認します。 100件を超えるスケジュールが未達の場合、ジョブは開始されず、エラーが記録されます。 
 
ジョブを開始する必要があるかどうかを判断できません。開始時間の遅れが多すぎます(> 100)。セット または.spec.startingDeadlineSecondsを減らすか クロックスキューをチェックします。

たとえば、定期的なバックアップジョブが 1 分ごとに実行されるように設定されている場合、許容範囲は 100 分になります。

解決

スタックした cronjob を削除し、Longhorn で再作成するだけです。

 ip-172-30-0-211:/home/ec2-ユーザー# kubectl -n longhorn-system は cronjobs を取得します
名前スケジュール 一時停止 アクティブ最終スケジュール 年齢
pvc-394e6006-9c34-47da-bf27-2286ae669be1-c-ptl8l1-c * * * * *誤り1 47秒 2分23秒
 
 ip-172-30-0-211:/home/ec2-ユーザー# kubectl -n longhorn-system削除cronjobs/pvc-394e6006-9c34-47da-bf27-2286ae669be1-c-ptl8l1-c
 cronjob.batch 「pvc-394e6006-9c34-47da-bf27-2286ae669be1-c-ptl8l1-c」が削除されました
 
 ip-172-30-0-211:/home/ec2-ユーザー# kubectl -n longhorn-system は cronjobs を取得します
longhorn-system 名前空間にリソースが見つかりません。 
 
 ip-172-30-0-211:/home/ec2-ユーザー# スリープ 60 
 
 ip-172-30-0-211:/home/ec2-ユーザー# kubectl -n longhorn-system は cronjobs を取得します
名前スケジュール 一時停止 アクティブ最終スケジュール 年齢
pvc-394e6006-9c34-47da-bf27-2286ae669be1-c-ptl8l1-c * * * * *誤り1 2秒 3分21秒

5. Traefik 2.xをイングレスコントローラとして使用する

適用可能なバージョン

すべての Longhorn バージョン。

症状

Longhorn GUI フロントエンド API リクエストが longhorn-manager バックエンドに到達できないことがあります。

理由

API リクエストにより HTTPS/WSS 間のプロトコルが変更され、この変更によって CORS の問題が発生する可能性があります。

解決

Traefik 2.x イングレスコントローラーは WebSocket ヘッダーを設定しません。

1. Longhorn フロントエンドサービスのルートに次のミドルウェアを追加します。

 apiバージョン: traefik.containo.us/v1alpha1
種類: ミドルウェア
メタデータ:
名前: svc-longhorn-headers
  名前空間: longhorn-system
仕様:
  ヘッダー:
    カスタムリクエストヘッダー:
      X-Forwarded-Proto: "https"

2. ミドルウェアルールを使用するように Ingress を更新します。

 APIバージョン: networking.k8s.io/v1beta1
種類: イングレス
メタデータ:
名前: longhorn-ingress
  名前空間: longhorn-system
  注釈:
    traefik.ingress.kubernetes.io/router.entrypoints: ウェブセキュア
    traefik.ingress.kubernetes.io/router.tls: "true"         
    traefik.ingress.kubernetes.io/router.middlewares: longhorn-system-svc-longhorn-headers@kubernetescrd
仕様:
  ルール:
  - http:
      パス:
      - パス： /
        バックエンド:
          サービス名: longhorn-frontend
          サービスポート: 80

6. cURLを使用してサポートバンドルを作成する

適用可能なバージョン

すべての Longhorn バージョン。

症状

Web ブラウザを使用してサポートバンドルを作成することはできません。

解決

Longhorn バックエンドサービスを公開します。以下は NodePort を使用した例です。ロードバランサーが設定されている場合は、ロードバランサーを介して公開することもできます。

 ip-172-30-0-21:~ # kubectl -n longhorn-system patch svc longhorn-backend -p '{"spec": {"type":"NodePort"}}'  
 service/longhorn-backend にパッチを適用
ip-172-30-0-21:~ # kubectl -n longhorn-system は svc/longhorn-backend を取得します
名前タイプ クラスター IP 外部 IP ポート 年齢
longhorn-backend NodePort 10.43.136.157 <なし> 9500:32595/TCP 156m

次のスクリプトを実行して、サポートバンドルを作成してダウンロードします。 BACKEND_URL、ISSUE_URL、ISSUE_DESCRIPTION を置き換える必要があります。

 #このブロックを置き換えます====>
 BACKEND_URL = "18.141.237.97:32595"   
 
 ISSUE_URL = "https://github.com/longhorn/longhorn/issues/dummy"  
 ISSUE_DESCRIPTION= "ダミーの説明"  
 # <====このブロックを置き換える
 
 #リクエスト サポートバンドルを作成する
REQUEST_SUPPORT_BUNDLE=$( curl -sSX POST -H 'Content-Type: application/json' -d '{ "issueURL": "' "${ISSUE_URL} "'" , "description" : "'" ${ISSUE_DESCRIPTION} "'" }' http://${BACKEND_URL}/v1/supportbundles ) 
 
 ID=$( jq -r '.id' <<< ${REQUEST_SUPPORT_BUNDLE} )
 SUPPORT_BUNDLE_NAME=$( jq -r '.name' <<< ${REQUEST_SUPPORT_BUNDLE} )
 echo "ノード ${ID} にサポート バンドル ${SUPPORT_BUNDLE_NAME} を作成しています"   
 
 [ $(curl -sSX GET http://${BACKEND_URL}/v1/supportbundles/${ID}/${SUPPORT_BUNDLE_NAME} | jq -r '.state' ) != "ReadyForDownload" ];する
  echo "進行状況: $(curl -sSX GET http://${BACKEND_URL}/v1/supportbundles/${ID}/${SUPPORT_BUNDLE_NAME} | jq -r '.progressPercentage' )%"  
  1秒寝る
終わり
 
 curl -i -X GET http://${BACKEND_URL}/v1/supportbundles/${ID}/${SUPPORT_BUNDLE_NAME}/download --output /tmp/${SUPPORT_BUNDLE_NAME}.zip  
 echo "サポートバンドルを /tmp/${SUPPORT_BUNDLE_NAME}.zip にダウンロードしました"

7. Longhorn RWXの共有マウント所有権は、消費者向けポッドでは誰も表示されません

適用可能なバージョン

Longhorn バージョン = v1.1.0

症状

RWX ボリュームを使用して Pod がマウントされると、Pod の共有マウントディレクトリとその繰り返しコンテンツのすべての所有権は nobody として表示されますが、共有マネージャーでは root として表示されます。

 root@ip-172-30-0-139:/home/ubuntu# kubectl exec -it rwx-test-2pml2 -- ls -l /data  
合計 16
 drwx ------ 2 誰もいない 42949672 16384 3月31日 04:16 lost+found   
 
 root@ip-172-30-0-139:~# kubectl -n longhorn-system exec -it share-manager-pvc-f3775852-1e27-423f-96ab-95ccd04e4777 -- ls -l /export/pvc-f3775852-1e27-423f-96ab-95ccd04e4777  
合計 16
 drwx ------ 2 ルート ルート 16384 3月 31 04:42 lost+found

背景

share-manager の nfs-ganesha は、NFSv4 ID マッピングに idmapd を使用し、エクスポートドメインとして localdomain を使用するように設定されています。

理由

所有権の変更は、クライアント (ホスト) とサーバー (共有マネージャー) 間の /etc/idmapd.conf の内容が一致しないために発生します。

例を見てみましょう:

クラスターホスト上の /etc/idmapd.conf を変更していないことを前提としています。一部のオペレーティングシステムでは、Domain = localdomain がコメントアウトされており、デフォルトではホスト名を除いた FQDN が使用されます。

ホスト名が ip-172-30-0-139 で、FQDN が ip-172-30-0-139.lan の場合、ホスト idmapd はドメインとして lan を使用します。

 root@ip-172-30-0-139:/home/ubuntu# ホスト名
ip-172-30-0-139 
 
 root@ip-172-30-0-139:/home/ubuntu# ホスト名 -f
 ip-172-30-0-139.lan

この結果、共有マネージャー (localdomain) とクラスターホスト (lan) の間でドメインの不一致が発生しました。これにより、ファイルの権限が nobody を使用するように変更されます。

 [マッピング]セクション変数
 
誰も-ユーザー 
地元 ユーザー 名前 マッピングを完了できない場合に使用します。
誰もいないグループ 
地元 グループ 名前 マッピングを完了できない場合に使用します。

解決

1. すべてのクラスターホストの /etc/idmapd.conf で、Domain = localdomain のコメントを解除するか追加します。

 root@ip-172-30-0-139:~# cat /etc/idmapd.conf
 [一般的な] 
 
冗長性 = 0
 Pipefs ディレクトリ = /run/rpc_pipefs
 # FQDNからホスト名を除いたドメインと異なる場合は、ここで独自のドメインを設定します
ドメイン = ローカルドメイン
 
 [マッピング] 
 
誰も-ユーザー= 誰も
誰もいないグループ= nogroup

2. RWX リソーススタック (pvc + pod) を削除して再作成します。

 root@ip-172-30-0-139:/home/ubuntu# kubectl exec -it ボリュームテスト-- ls -l /data  
合計 16
 drwx ------ 2 ルート ルート 16384 3月 31 04:42 lost+found

8. ノード上のマルチパスが原因でボリュームの MountVolume.SetUp が失敗する

適用可能なバージョン

すべての Longhorn バージョン。

症状

ボリュームを持つポッドが起動せず、longhorn-csi-plugin で次のエラーメッセージが表示されます。

時刻= "2020-04-16T08:49:27Z"  レベル=info msg= "GRPC リクエスト: {\"target_path\":\"/var/lib/kubelet/pods/cf0a0b5b-106e-4793-a74a-28bfae21be1a/volumes/kubernetes.io~csi/pvc-d061512e-870a-4ece-bd45 -2f04672d5256/mount\",\"volume_capability\":{\"AccessType\":{\"Mount\":{\"fs_type\":\"ext4\"}},\"access_mode\":{\"mode\":1}},\"volu me_context\":{\"baseImage\":\"\",\"fromBackup\":\"\",\"numberOfReplicas\":\"3\",\"staleReplicaTimeout\":\"30\",\"storage.kubernetes .io/csiProvisionerIdentity\":\"1586958032802-8081-driver.longhorn.io\"},\"volume_id\":\"pvc-d061512e-870a-4ece-bd45-2f04672d5256\"}"  
時刻= "2020-04-16T08:49:27Z"   level =info msg= "NodeServer NodePublishVolume が必要です: volume_id:\"pvc-d061512e-870a-4ece-bd45-2f04672d5256\" target_path:\"/var/lib/kubelet/pods/cf0a0b5b-106e-4793-a74a-28bfae21be1a/volumes/kubernetes.io~csi/pvc-d061512e-870a-4ece-bd45-2f04672d5256/mount\" volume_capability:<mount:<fs_type:\"ext4\" > access_mode:<mode:SINGLE_NODE_WRITER > > volume_context:<key:\"baseImage\" value:\"\" > volume_context:<key:\"fromBackup\" value:\"\" > volume_context:<key:\"numberOfReplicas\" value:\"3\" > volume_context:<key:\"staleReplicaTimeout\" value:\"30\" > volume_context:<key:\"storage.kubernetes.io/csiProvisionerIdentity\" value:\"1586958032802-8081-driver.longhorn.io\" > "  
 E0416 08:49:27.567704 1 mount_linux.go:143] マウントに失敗しました: 終了ステータス 32
マウントコマンド: mount
マウント引数: -t ext4 -o defaults /dev/longhorn/pvc-d061512e-870a-4ece-bd45-2f04672d5256 /var/lib/kubelet/pods/cf0a0b5b-106e-4793-a74a-28bfae21be1a/volumes/kubernetes.io~csi/pvc-d061512e-870a-4ece-bd45-2f04672d5256/mount
出力: mount: /var/lib/kubelet/pods/cf0a0b5b-106e-4793-a74a-28bfae21be1a/volumes/kubernetes.io~csi/pvc-d061512e-870a-4ece-bd45-2f04672d5256/mount: /dev/longhorn/pvc-d061512e-870a-4ece-bd45-2f04672d5256 は既にマウントされているか、マウント ポイントがビジーです。
 E0416 08:49:27.576477 1 mount_linux.go:487]ディスク「/dev/longhorn/pvc-d061512e-870a-4ece-bd45-2f04672d5256」のフォーマットに失敗しました: タイプ:( 「ext4」 ) ターゲット:( 「/var/lib/kubelet/pods/cf0a0b5b-106e-4793-a74a-28bfae21be1a/volumes/kubernetes.io~csi/pvc-d061512e-870a-4ece-bd45-2f04672d5256/mount」 ) オプション:([ 「defaults」 ])エラー:(終了ステータス 1)
時刻= "2020-04-16T08:49:27Z"  レベル=エラー メッセージ = "GRPC エラー: rpc エラー: コード = 内部説明 = 終了ステータス 1"

詳細

これは、明示的にブラックリストに登録されていないすべての Longhorn ボリュームデバイスを含む、適格なデバイスパスに対してマルチパスがマルチパスデバイスを作成するためです。

トラブルシューティング

1. Longhorn デバイスのメジャー:マイナー番号を見つけます。ノード上で、ls -l /dev/longhorn/ を試してください。メジャー:マイナー番号はデバイス名の前に表示されます (例: 8、32)。

 ls -l /dev/longhorn
 brw-rw ---- 1 ルート ルート 8、32 8月 10 21:50 pvc-39c0db31-628d-41d0-b05a-4568ec02e487

2. 同じメジャー番号とマイナー番号に対して Linux が生成するデバイスを見つけます。 ls -l /dev を使用して、同じメジャー:マイナー番号を持つデバイス (例: /dev/sde) を見つけます。

 brw-rw ---- 1 ルートディスク 8、32 8月 10 21:50 sdc

プロセスを見つけます。 lsof を使用して使用中のファイルハンドラーのリストを取得し、デバイス名 (例: sde または /dev/longhorn/xxx) を grep で検索します。そこにデバイス名が見つかるはずです。

 lsof | grep sdc
マルチパス 514292 ルート 8r BLK 8,32 0t0 534 /dev/sdc
マルチパス 514292 514297 マルチパス ルート 8r BLK 8,32 0t0 534 /dev/sdc
マルチパス 514292 514299 マルチパス ルート 8r BLK 8,32 0t0 534 /dev/sdc
マルチパス 514292 514300 マルチパス ルート 8r BLK 8,32 0t0 534 /dev/sdc
マルチパス 514292 514301 マルチパス ルート 8r BLK 8,32 0t0 534 /dev/sdc
マルチパス 514292 514302 マルチパス ルート 8r BLK 8,32 0t0 534 /dev/sdc
マルチパス 514292 514304 マルチパス ルート 8r BLK

解決

マルチパスデーモンが Longhorn によって作成された追加のブロックデバイスを追加しないようにするには、次の手順に従ってください。

まず、lsblk を使用して、Longhorn によって作成されたデバイスを確認します。

ルート@localhost:~# lsblk
名前MAJ:最小RMサイズRO タイプ マウントポイント
sda 8:0 0 79.5G 0 ディスク /
 sdb 8:16 0 512M 0 ディスク [SWAP]
 sdc 8:32 0 1G 0 ディスク /var/lib/kubelet/pods/c2c2b848-1f40-4727-8a52-03a74f9c76b9/volumes/kubernetes.io~csi/pvc-859bc3c9-faa8-4f54-85e4-b12935b5ae3c/マウント
sdd 8:48 0 1G 0 ディスク /var/lib/kubelet/pods/063a181a-66ac-4644-8268-9215305f9b73/volumes/kubernetes.io~csi/pvc-837eb6ac-45fe-4de7-9c97-8d371eb02190/マウント
sde 8:64 0 1G 0 ディスク /var/lib/kubelet/pods/4c80842d-7257-4b91-b668-bb5b111da003/volumes/kubernetes.io~csi/pvc-c01cee3e-f292-4979-b183-6546d6397fbd/マウント
sdf 8:80 0 1G 0 ディスク /var/lib/kubelet/pods/052dadd9-042a-451c-9bb1-2d9418f0381f/volumes/kubernetes.io~csi/pvc-ba7a5c9a-d84d-4cb0-959d-3db39f34d81b/マウント
sdg 8:96 0 1G 0 ディスク /var/lib/kubelet/pods/7399b073-c262-4963-8c7f-9e481272ea36/volumes/kubernetes.io~csi/pvc-2b122b42-141a-4181-b8fd-ce3cf91f6a64/マウント
sdh 8:112 0 1G 0 ディスク /var/lib/kubelet/pods/a63d919d-201b-4eb1-9d84-6440926211a9/volumes/kubernetes.io~csi/pvc-b7731785-8364-42a8-9e7d-7516801ab7e0/マウント
sdi 8:128 0 1G 0 ディスク /var/lib/kubelet/pods/3e056ee4-bab4-4230-9054-ab214bdf711f/volumes/kubernetes.io~csi/pvc-89d37a02-8480-4317-b0f1-f17b2a886d1d/マウント

Longhornのデバイス名は/dev/sd[x]で始まることに注意してください。

デフォルトの設定ファイル /etc/multipath.conf が存在しない場合は作成します。
ブラックリストセクション devnode "^sd[a-z0-9]+" に次の行を追加します。

ブラックリスト {
    devnode "^sd[a-z0-9]+"  
 }

マルチパスサービスを再起動する

systemctl で multipathd.service を再起動します。

設定が適用されていることを確認する

マルチパス -t

マルチパスブラックリストセクションのデフォルト設定では、次のデバイス名がデフォルトでブロックされます ^(ram|raw|loop|fd|md|dm-|sr|scd|st|dcssblk)[0-9] ^(td|hd|vd)[az]

9. Longhorn-UI: WebSocket ハンドシェイク中にエラーが発生しました: 予期しない応答コード: 200 #2265

適用可能なバージョン

既存の Longhorn バージョン < v1.1.0 は Longhorn >= v1.1.0 にアップグレードされます。

症状

Longhorn をバージョン >= v1.1.0 にアップグレードすると、次の状況が発生します。

エントリーメッセージ:

 { "level" : "error" 、 "msg" : "vulcand/oxy/forward/websocket: \"10.17.1.246\" へのダイヤル中にエラーが発生しました: websocket: 応答: 200 200 OK とのハンドシェイクが不正です" 、 "time" : "2021-03-09T08:29:03Z" }

Longhorn UI メッセージ:

 10.46.0.3 - - [2021年2月19日:11:33:24 +0000] "GET /node/v1/ws/1s/engineimages HTTP/1.1" 200 578 "-"   「Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML、Gecko など) Chrome/88.0.4324.150 Safari/537.36 Edg/88.0.705.68」  
 10.46.0.3 - - [2021年2月19日:11:33:29 +0000] 「GET /node/v1/ws/1s/volumes HTTP/1.1」 200 578 「-」   「Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML、Gecko など) Chrome/88.0.4324.150 Safari/537.36 Edg/88.0.705.68」  
 10.46.0.3 - - [2021年2月19日:11:33:32 +0000] 「GET /node/v1/ws/1s/nodes HTTP/1.1」 200 578 「-」   「Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML、Gecko など) Chrome/88.0.4324.150 Safari/537.36 Edg/88.0.705.68」  
 10.46.0.3 - - [2021年2月19日:11:33:37 +0000] 「GET /node/v1/ws/1s/events HTTP/1.1」 200 578 「-」   「Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML、Gecko など) Chrome/88.0.4324.150 Safari/537.36 Edg/88.0.705.68」  
 10.46.0.3 - - [2021年2月19日:11:33:38 +0000] "GET /node/v1/ws/1s/engineimages HTTP/1.1" 200 578 "-"   「Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML、Gecko など) Chrome/88.0.4324.150 Safari/537.36 Edg/88.0.705.68」  
 10.46.0.3 - - [2021年2月19日:11:33:41 +0000] "GET /node/v1/ws/1s/volumes HTTP/1.1" 200 578 "-"   「Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML、Gecko など) Chrome/88.0.4324.150 Safari/537.36 Edg/88.0.705.68」

理由

さまざまなルーター (Rancher-Proxy、NodePort、Ingress、Nginx) をサポートするために、Longhorn v1.1.0 では、次の 2 つの理由からハッシュ履歴を使用するように UI を再構築しました。

異なるパスへの Longhorn UI ルーティングをサポートします。たとえば、/longhorn/#/dashboard
フロントエンドとバックエンドを分離することで、シングルページアプリケーションをサポートします。

結果、 /変更する/#/ 。

その後、出力メッセージは次のようになります。

Ingress メッセージには Websocket エラーが含まれてはなりません。

時刻= "2021-03-16T04:54:23Z"  レベル=debug メッセージ = "websocket: open" id = 6809628160892941023 タイプ = events
時刻= "2021-03-16T04:54:23Z"  レベル=debug メッセージ = "websocket: オープン" id = 3234910863291903636 タイプ = engineimages
時刻= "2021-03-16T04:54:23Z"  レベル=debug メッセージ = "websocket: open" id=2117763315178050120 タイプ = backingimages
時刻= "2021-03-16T04:54:23Z"  レベル=debug メッセージ = "websocket: open" id = 621105775322000457 タイプ = ボリューム

Longhorn UI メッセージ:

Ingress の使用:

 10.42.0.8 - - [2021年3月16日:04:54:34 +0000] 「GET /v1/nodes HTTP/1.1」 200 6729 「http://10.17.0.169/」   「Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML、Gecko など) Chrome/89.0.4389.90 Safari/537.36」  
 10.42.0.8 - - [2021年3月16日:04:54:34 +0000] "GET /v1/backingimages HTTP/1.1" 200 117 "http://10.17.0.169/"   「Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML、Gecko など) Chrome/89.0.4389.90 Safari/537.36」  
 10.42.0.8 - - [16/Mar/2021:04:54:34 +0000] "GET /v1/volumes HTTP/1.1" 200 162 "http://10.17.0.169/"   「Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML、Gecko など) Chrome/89.0.4389.90 Safari/537.36」  
 10.42.0.8 - - [2021年3月16日:04:54:34 +0000] 「GET /v1/engineimages HTTP/1.1」 200 1065 「http://10.17.0.169/」   「Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML、Gecko など) Chrome/89.0.4389.90 Safari/537.36」  
 10.42.0.8 - - [2021年3月16日:04:54:34 +0000] 「GET /v1/settings HTTP/1.1」 200 30761 「http://10.17.0.169/」   「Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML、Gecko など) Chrome/89.0.4389.90 Safari/537.36」  
 10.42.0.8 - - [2021年3月16日:04:54:34 +0000] 「GET /v1/events HTTP/1.1」 200 62750 「http://10.17.0.169/」   「Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML、Gecko など) Chrome/89.0.4389.90 Safari/537.36」

プロキシの使用:

 10.42.0.0 - - [16/Mar/2021:05:03:51 +0000] "GET /v1/engineimages HTTP/1.1" 200 1070 "http://localhost:8001/api/v1/namespaces/longhorn-system/services/http:longhorn-frontend:80/proxy/"   「Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML、Gecko など) Chrome/89.0.4389.90 Safari/537.36」  
 10.42.0.0 - - [16/Mar/2021:05:03:51 +0000] "GET /v1/events HTTP/1.1" 200 62904 "http://localhost:8001/api/v1/namespaces/longhorn-system/services/http:longhorn-frontend:80/proxy/"   「Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML、Gecko など) Chrome/89.0.4389.90 Safari/537.36」  
 10.42.0.0 - - [16/Mar/2021:05:03:52 +0000] "GET /v1/engineimages HTTP/1.1" 200 1071 "http://localhost:8001/api/v1/namespaces/longhorn-system/services/http:longhorn-frontend:80/proxy/"   「Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML、Gecko など) Chrome/89.0.4389.90 Safari/537.36」  
 10.42.0.0 - - [16/Mar/2021:05:03:52 +0000] "GET /v1/nodes HTTP/1.1" 200 6756 "http://localhost:8001/api/v1/namespaces/longhorn-system/services/http:longhorn-frontend:80/proxy/"   「Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML、Gecko など) Chrome/89.0.4389.90 Safari/537.36」  
 10.42.0.0 - - [16/Mar/2021:05:03:52 +0000] "GET /v1/settings HTTP/1.1" 200 30882 "http://localhost:8001/api/v1/namespaces/longhorn-system/services/http:longhorn-frontend:80/proxy/"   「Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML、Gecko など) Chrome/89.0.4389.90 Safari/537.36」  
 10.42.0.0 - - [16/Mar/2021:05:03:52 +0000] "GET /v1/volumes HTTP/1.1" 200 168 "http://localhost:8001/api/v1/namespaces/longhorn-system/services/http:longhorn-frontend:80/proxy/"   「Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML、Gecko など) Chrome/89.0.4389.90 Safari/537.36」  
 10.42.0.0 - - [16/Mar/2021:05:03:52 +0000] "GET /v1/backingimages HTTP/1.1" 200 120 "http://localhost:8001/api/v1/namespaces/longhorn-system/services/http:longhorn-frontend:80/proxy/"   「Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML、Gecko など) Chrome/89.0.4389.90 Safari/537.36」  
 10.42.0.0 - - [16/Mar/2021:05:03:52 +0000] "GET /v1/events HTTP/1.1" 200 62900 "http://localhost:8001/api/v1/namespaces/longhorn-system/services/http:longhorn-frontend:80/proxy/"   「Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML、Gecko など) Chrome/89.0.4389.90 Safari/537.36」

解決

ブラウザのキャッシュをクリアしてください。
から/# Longhorn URL にアクセス/再度ブックマークします。

10. Longhornボリュームのマウントに時間がかかる

適用可能なバージョン

すべての Longhorn バージョン。

症状

Longhorn ボリュームを使用するワークロードポッドを起動すると、Longhorn UI には Longhorn ボリュームがすぐに接続されることが表示されますが、ボリュームがマウントされてワークロードが開始できるようになるまでに長い時間がかかります。

この問題は、Longhorn ボリュームに多数のファイル/ディレクトリがあり、ワークロードポッドで securityContext.fsGroup が次のように設定されている場合にのみ発生します。

仕様:
  セキュリティコンテキスト:
    実行ユーザー: 1000
    実行グループ: 3000
    fsグループ: 2000

理由

デフォルトでは、fsGroup フィールドが検出されると、Kubernetes はボリュームがマウントされるたびに、ボリューム内のすべてのファイルとディレクトリに対して chown() と chmod() を再帰的に呼び出します。これは、ボリュームのグループ所有権が要求された fsGroup とすでに一致している場合でも発生し、多数の小さなファイルを含む大規模なボリュームでは非常にコストが高くなり、ポッドの起動に長い時間がかかる原因になります。

解決

Kubernetes v1.19.x 以前ではこの問題を回避する方法はありません。

バージョン 1.20.x 以降、Kubernetes では新しいベータ機能である fsGroupChangePolicy フィールドが導入されました。今すぐ、

仕様:
  セキュリティコンテキスト:
    実行ユーザー: 1000
    実行グループ: 3000
    fsグループ: 2000
    fsGroupChangePolicy: "OnRootMismatch"

fsGroupChangePolicy が OnRootMismatch に設定されている場合、ボリュームのルートに既に正しいアクセス許可がある場合は、再帰的なアクセス許可と所有権の変更はスキップされます。つまり、ユーザーがポッドの起動間で pod.spec.securityContext.fsGroup を変更しない場合、K8s はルートディレクトリの権限と所有権を確認するだけで済み、ボリュームの所有権と権限を常に再帰的に変更するよりもマウントプロセスがはるかに高速になります。

関連情報

関連する Longhorn の問題:
- https://github.com/longhorn/longhorn/issues/2131
関連する Kubernetes ドキュメント:
- https://kubernetes.io/blog/2020/12/14/kubernetes-release-1.20-fsgroupchangepolicy-fsgrouppolicy/#allow-users-to-skip-recursive-permission-changes-on-mount

11. ボリューム読み取り専用またはI/Oエラー

適用可能なバージョン

すべての Longhorn バージョン。

症状

アプリケーションが既存のファイルにデータを書き込むか、Longhorn ボリュームのマウントポイントにファイルを作成すると、次のメッセージが表示されます。

 / # CDデータ
/data # エコーテスト > テスト
sh: テストを作成できません: I/O エラー

関連するポッドまたはノードホストで dmesg を実行すると、次のメッセージが表示されます。

 [1586907.286218] EXT4-fs (sdc):順序付きデータ モードでマウントされたファイル システム。オプション: ( null )
 [1587396.152106] EXT4-fs 警告 (デバイス sdc): ext4_end_bio:323: I/O エラー 10 、inode 12への書き込み (オフセット 0、サイズ4096、開始ブロック 33026)
 [1587403.789877] EXT4-fs エラー (デバイス sdc): ext4_find_entry:1455: inode #2: comm sh: ディレクトリ lblock 0 を読み取り中
[1587404.353594] EXT4-fs 警告 (デバイス sdc): htree_dirblock_to_tree:994: inode #2: lblock 0: comm ls: エラー -5 ディレクトリ ブロックの読み取り
[1587404.353598] EXT4-fs エラー (デバイス sdc): ext4_journal_check_start:61: 中止されたジャーナルが検出されました
[1587404.355087] EXT4-fs (sdc): ファイルシステムを読み取り専用で再マウントしています 
 ......

`kubectl -n longhorn-system get event | を使用してイベントを確認する場合grep を実行すると、次のイベントが表示されます。

kubectl -n longhorn-system get event を使用します |グレップイベントを確認すると、次のイベントが表示されます。

 2 分 26 秒 警告 デタッチド 予期せず volume/pvc-342edde0-d3f4-47c6-abf6-bf8eeda3c32cボリューム pvc-342edde0-d3f4-47c6-abf6-bf8eeda3c32cのエンジンが予期せず停止しました。ボリュームを再接続してください

kubectl -n longhorn-system logsを実行すると|グレップワークロードが実行されているノード上の Longhorn マネージャーポッドのログを確認すると、次のメッセージが表示されます。

時刻= "2021-01-05T11:20:46Z"  レベル=debug msg= "インスタンス ハンドラーがインスタンス pvc-342edde0-d3f4-47c6-abf6-bf8eeda3c32c-e-0fe2dac3 状態を更新しました。古い状態は実行中、新しい状態はエラーです"  
時刻= "2021-01-05T11:20:46Z"  レベル=警告メッセージ= 「インスタンス pvc-342edde0-d3f4-47c6-abf6-bf8eeda3c32c-e-0fe2dac3 がインスタンス マネージャー instance-manager-e-a1fd54e4 の shuo-cluster-0-worker-3 でクラッシュしました。ログを取得してください」  
 ......
時刻= "2021-01-05T11:20:46Z"  レベル=警告 メッセージ= 「ボリュームのエンジンが予期せず停止しました。ボリュームを再接続してください」 accessMode=rwo コントローラー=longhorn-volume フロントエンド=blockdev ノード=shuo-cluster-0-worker-3 所有者=shuo-cluster-0-worker-3 状態=接続済み ボリューム=pvc-342edde0-d3f4-47c6-abf6-bf8eeda3c32c
 ......
時刻= "2021-01-05T11:20:46Z"   level =info msg= "Event(v1.ObjectReference{Kind:\"Volume\", Namespace:\"longhorn-system\", Name:\"pvc-342edde0-d3f4-47c6-abf6-bf8eeda3c32c\", UID:\"69bb0f94-da48-4d15-b861-add435f25d00\", APIVersion:\"longhorn.io/v1beta1\", ResourceVersion:\"7466467\", FieldPath:\"\"}): type: 'Warning' reason: 'DetachedUnexpectly' ボリューム pvc-342edde0-d3f4-47c6-abf6-bf8eeda3c32c のエンジンが予期せず停止しました。ボリュームを再接続してください"

失敗の原因

Longhorn ボリュームが予期せずクラッシュすると、Longhorn ボリュームのマウントポイントが無効になります。そうすると、Longhorn ボリューム内のデータはマウントポイント経由で読み書きできなくなります。

根本的な原因

エンジンのクラッシュは通常、各レプリカへの接続が失われることによって発生します。これが起こる理由としては、次のようなことが考えられます。

1. ノード上の CPU 使用率が高すぎます。 Longhorn エンジンに要求を処理するのに十分な CPU リソースがない場合、要求がタイムアウトし、レプリカへの接続が失われる可能性があります。 Longhorn インスタンスマネージャー Pod に適切な量の CPU リソースを予約する方法については、次のドキュメントを参照してください。

https://longhorn.io/docs/1.1.0/best-practices/#guaranteed-engine-cpu

2. ネットワーク帯域幅が不十分です。通常、1Gbps ネットワークでは、すべてのボリュームで負荷の高いワークロードが実行されている場合、3 つのボリュームしか処理できません。

3. ネットワークの遅延が比較的大きい。ノード上で同時に複数のボリュームの読み取り/書き込みが行われる場合、レイテンシが 20 ミリ秒未満になるようにするのが最適です。

4. ネットワークの中断。すべてのレプリカが切断され、エンジンがクラッシュする可能性があります。

5. ディスクのパフォーマンスが低すぎるため、要求を時間内に完了できません。 Longhorn システムでは、IOPS の低いディスク (回転ディスクなど) の使用はお勧めしません。

自動回復

v1.1.0 より前の Longhorn バージョンでは、Longhorn はボリュームを自動的に再マウントしようとしますが、処理できるシナリオには制限があります。

Longhorn v1.1.0 以降では、新しい設定「ボリュームが予期せず切断された場合にワークロードポッドを自動的に削除する」が導入され、Longhorn はコントローラー (デプロイメント、ステートフルセット、デーモンセットなど) によって管理されるワークロードポッドを自動的に削除するようになりました。

手動回復

ワークロードが単純なポッドの場合は、ポッドを削除して再デプロイできます。再利用ポリシーが「保持」でない場合は、関連する PVC または PV が削除されていないことを確認してください。そうでない場合、関連付けられている PVC/PV が消えると Longhorn ボリュームは削除されます。

ワークロードポッドが Deployment/StatefulSet に属している場合は、ワークロードレプリカをスケールダウンしてからスケールアップすることで、ポッドを再起動できます。

Longhorn v1.1.0 以降では、ボリュームが予期せず切断された場合にワークロードポッドを自動的に削除する設定を有効にすることができます。

その他の原因

関連するワークロードがまだボリュームを使用しているときに、ユーザーが誤ってまたは手動で Longhorn ボリュームを切断しました。

12。ボリュームPVC-XXXスケジュールされていません

該当するバージョン

すべてのロングホーンバージョン。

症状

PVCとしてLonghornボリュームでポッドを作成する場合、ポッドを開始できません。

kubectlの使用を使用しますエラーメッセージをチェックするとき、次のメッセージが表示されます。

警告FALEEDATTACHVOLUME 4M29S（5M33を超えるx3）actitiondetach-controller attachvolume.attachはボリューム「pvc-xxx」 ：rpcエラー：code = internal desc = bad response statuscode [500]で失敗しました。ステータス[500内部サーバーエラー]。ボディ：[メッセージ=ボリュームPVC-XXXをnode-xxxに添付することができない：ボリュームPVC-xxxスケジュールされていない、code = serverエラー、詳細=]から[http：// longhorn-backend：9500/v1/volumes/pvc-xxx？アクション=添付]

上記のエラーでは、ロングホーンによって返されたメッセージに気付きました。

ボリュームPVC-XXXをnode-xxxに添付することができない：ボリュームPVC-xxxスケジュールされていない

詳細

これは、ロングホーンがボリュームのデータを保存するのに十分なスペースをさまざまなノードに見つけることができず、ボリュームスケジューリングの障害をもたらすためです。

最も一般的な理由

Longhorn V1.0.xの場合、デフォルトのLonghornのインストールには次の設定があります。

ノードレベルソフトアンチアフィニティ：false
StorageClass Longhornのデフォルトのコピー数は3に設定されています。

これは、ロングホーンが常に3つの異なるノードに3つのレプリカに十分なスペースを割り当てようとすることを意味します。

たとえば、この要件を満たすことができない場合、クラスターに3つのノードがあるため、ボリュームスケジューリングは失敗します。

解決

この場合は、次のことができます。

または、ノードレベルのソフトアンチアフィニティをtrueに設定します。
または、レプリカの数を1または2に設定して、新しいStorageClassを作成します。
または、クラスターにノードを追加します。

その他の原因

スケジューリングポリシーの詳細な説明については、Longhornドキュメントのスケジューリングセクションを参照してください。

https://longhorn.io/docs/1.0.2/volumes-nnodes/scheduling/

[[429654]]

目次

1. Longhornボリュームファイルシステムが破損すると、Podは作成状態のままになる

適用可能なバージョン

症状

理由

解決

2. 非標準の Kubelet ディレクトリ

適用可能なバージョン

症状

理由

解決

3. Longhornのデフォルト設定は保持されない

適用可能なバージョン

症状

背景

解決

4. ボリュームをデタッチしてアタッチした後、定期的なジョブは新しいジョブを作成しません。

解決

関連情報

5. Traefik 2.xをイングレスコントローラとして使用する

適用可能なバージョン

症状

理由

解決

6. cURLを使用してサポートバンドルを作成する

適用可能なバージョン

症状

解決

関連情報

7. Longhorn RWXの共有マウント所有権は、消費者向けポッドでは誰も表示されません

適用可能なバージョン

症状

背景

理由

解決

関連情報

8. ノード上のマルチパスが原因でボリュームの MountVolume.SetUp が失敗する

適用可能なバージョン

症状

詳細

トラブルシューティング

解決

関連情報

9. Longhorn-UI: WebSocket ハンドシェイク中にエラーが発生しました: 予期しない応答コード: 200 #2265

適用可能なバージョン

症状

理由

解決

関連情報

10. Longhornボリュームのマウントに時間がかかる

適用可能なバージョン

症状

理由

解決

11. ボリューム読み取り専用またはI/Oエラー

適用可能なバージョン

症状

失敗の原因

根本的な原因

自動回復

手動回復

その他の原因

12。ボリュームPVC-XXXスケジュールされていません

該当するバージョン

症状

詳細

最も一般的な理由

解決

その他の原因

関連情報

推薦する