0

このkubernetes の例に従って、永続データを使用して wordpress と mysql を作成しました

ディスクの作成から展開まで、チュートリアルからすべてに従い、最初の削除も試してみました

1回目

https://s3-ap-southeast-2.amazonaws.com/dorward/2017/04/git-cmd_2017-04-03_08-25-33.png

問題: 永続ボリュームが永続ボリューム要求にバインドされません。ポッドの作成とボリューム要求の両方で、保留中の状態のままです。ボリュームのステータスも Released 状態のままです。

例で説明されているようにすべてを削除して、再試行する必要がありました。今回は、作成したボリュームをクラスター内のインスタンスにマウントし、ext4 fs を使用してディスクをフォーマットし、ディスクをアンマウントしました。

2回目の試行

https://s3-ap-southeast-2.amazonaws.com/dorward/2017/04/git-cmd_2017-04-03_08-26-21.png

問題: ボリュームをフォーマットした後、ボリュームがクレームにバインドされました。残念ながら、mysql pod はステータス crashLoopback off では実行されません。最終的にワードプレスのポッドもクラッシュしました。

https://s3-ap-southeast-2.amazonaws.com/dorward/2017/04/git-cmd_2017-04-03_08-27-22.png

他の誰かがこれを経験しましたか？私が何か間違ったことをしたのか、それとも試験の記述から現在までに何かが変更されて例が壊れたのか疑問に思っています。どうすれば修正できますか？

どんな助けでも大歓迎です。

4

1 に答える 1

1

Pod のログを取得します。

kubectl logs pod-name

Pod が起動していないこと (crashloopback) がログに示されている場合は、k8s でイベントを調査します。

kubectl get events

イベント ログは、ノードのメモリ不足 (OOM) を示します。

    LASTSEEN   FIRSTSEEN   COUNT     NAME                                              KIND      SUBOBJECT                    TYPE      REASON       SOURCE                                                      MESSAGE
1m         7d          1555      gke-hostgeniuscom-au-default-pool-xxxh   Node                                   Warning   SystemOOM    {kubelet gke-hostgeniuscom-au-default-pool-xxxxxf-qmjh}   System OOM encountered

より大きなインスタンス サイズを試すと、問題が解決するはずです。

于 2017-04-03T01:01:12.997 に答える