問題タブ [persistent-volumes]

ReadWriteOnceKubernetes は、永続ボリュームに対して、ReadOnlyMany、の 3 種類のアクセス モードをサポートしているようですReadWriteMany。ReadWriteOnceモード ボリュームを使用するポッドのスケジューラ戦略に非常に興味があります。たとえば、Pod num=2 を持つ RC を作成しました。2 つの Pod は、ReadWriteOnceモードを持つボリュームを使用するため、同じホストにスケジュールされると思いますか? この部分のソースコードがどうしても知りたいです。

次のものがありますpvc(永続ボリューム要求):

および Google Cloud でサポートされているpv（永続ボリューム）:

存在する Google クラウド内のディスク。

最初に を作成しpv、 の後に作成するとpvc、次のkubectl get pvc,pvように表示されます。

しかし、を削除して再作成するとpv、次のkubectl get pvc,pvように表示されます。

• なぜpvc静止画なのBoundですか？
• pvc(再) バインドは自動的に行われませんか? (また、 のpv後にを作成すると、ステータスで永遠pvcに待機することもわかりました。)pvcPending

次の Kubernetes バージョンを使用します。

3 つのノードで構成される GCE コンテナ クラスタがあります。すべてのノードで、次のような POD を実行します。

「アンチアフィニティ」ポートを定義するトリックにより、すべての POD が異なるノードで実行されることが保証されます。次のように定義された 3 つの PersistentVolume を作成しました。

そしてそれらはうまく展開されています

クレームの定義は次のとおりです。

私が気付いたのは、クレームが作成したボリュームの 1 つにのみバインドされているため、PODS の 1 つだけが正常にデプロイされるということです。私が予想していたのは、クレームが POD によって使用された場合、バインド先の利用可能なボリュームが 1 つ見つかり、セレクター ルールに一致することでした。言い換えれば、PersistentVolumeClaims について私が解釈したのは、POD は、PVC 仕様に一致する PersistentVolumes セット内の使用可能なボリュームを検索するためにクレームを使用するということです。それが私の質問です：

同じ POD の異なるインスタンスで同じ PersistentVolumeClaim を使用して、異なる PersistentVolume に接続できますか? または、クレームが作成されると、1 つのボリュームのみにバインドされ、他のボリュームにバインドできなくなりますか?

正しい答えが 2 番目の場合、POD ごとに要求を作成せずに展開するときに、POD を PersistentVolume (セットから選択) に動的にバインドする方法を作成して、接続する必要があるすべてのボリュームに対して特定の POD を作成することを回避するにはどうすればよいですか?に？

PVC (永続ボリューム要求) を持つ POD を持つレプリケーション コントローラーを作成したいと考えています。私の PVC は、PV (永続ボリューム) に NFS ストレージを使用します。

POD が動作可能になると、RC は POD を稼働状態に維持します。この状況では、POD 内のデータは、次の場合に利用可能/永続的になります。

1. POD が削除コマンドによって停止/削除され、RC が再起動しますか? つまり、Kubernetes はシャットダウンされていません。この場合、新しい POD は同じボリュームから同じデータを持つことができますか?
2. POD が停止され、Kubernetes プロセスとノードが再起動されました。ただし、NFS ストレージはまだ PV として接続されていました。
3. 新しい PV が Kubernetes にアタッチされ、古い PV がデタッチされます。

Coreos で k8s storageclass を使用したいのですが、失敗しました

.CoreOS のバージョンは安定しています (1122.2) .Hyperkube のバージョンは v1.4.3_coreos.0 です

k8s クラスターはcoreos-kubernetes スクリプトによってデプロイされ、kubelet-wrapper.md によって推奨される rbd のrkt_opts を変更します。

ceph バージョンは宝石です。coreos に rbd イメージをマウントしました。うまく動作します。

今、ポッドで pvc を使用しようとしています。 kubernetes の公式ドキュメントを参照してください https://github.com/kubernetes/kubernetes/tree/master/examples/experimental/persistent-volume-provisioning

構成ファイル:

シークレットの作成は問題ありません。ストレージクラスの作成は問題ないようですが、説明できません (「StorageClass」の説明は実装されていません)。PVC を作成するとき、ステータスは常に保留中です。説明します。

誰かが私を助けることができますか？

そこの、

ドキュメントによると：

ReadWriteOnce – the volume can be mounted as read-write by a single node

nfs に基づいて PV を作成しました。

この PV の PVC:

PV への PVC バインドを作成した後:

次に、同じ PVC を使用して 2 つの POD を作成しました。

POD1:

ポッド2:

2 つの POD を作成すると、それらは 2 つの異なるノードに割り当てられます。そして、コンテナに実行でき、nfs マウント フォルダで読み書きできます。

なぜこれが起こったのか知っている人はいますか？

azureFile を使用して永続ボリュームを作成しようとしていますが、次のエラーが引き続き発生します。

また、kubernetes が動作している VM の 1 つに共有をマウントしようとしました。

pv/pvc/pod を作成するために、次の構成を使用しました。

これは、Azure コンテナー サービスを使用してビルドされた、私が使用している kubernetes のバージョンです。

この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

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

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