kubernetes - OpenStack ボリュームを Kubernetes 静的ポッドに接続する方法は?

Question

kubeletOpenStack クラウドで v1.10.3 を使用して単一のマスター ノードをブートストラップし、ポッドとして k8s の必需品用に「自己ホスト型」の単一の etcd ノードを使用したいとします。

コンポーネントを開始する前にkube-apiserver、稼働中の etcd インスタンスが必要ですが、もちろん、クラスターの準備がまったく整っていないため、単に実行しkubectl apply -fたり、マニフェストをフォルダーに配置したりすることはできません。addon-managerAPI サーバーの準備ができていなくても、kubelet でポッドを開始する方法があります。これは静的ポッドと呼ばれます (yaml Pod 定義は通常 にあります/etc/kubernetes/manifests/)。そして、それは、apiserver、スケジューラー、コントローラーマネージャー、etcd 自体などの「システム」ポッドを開始する方法です。以前はノードからディレクトリをマウントして etcd データを保持していましたが、今は OpenStack ブロックストレージ リソースを使用したいと考えています。ここで質問があります: OpenStack cinder ボリュームをアタッチ、マウント、使用して、静的ポッドから etcd データを永続化するにはどうすればよいですか?

今日学んだように、OpenStack ボリュームをアタッチするには少なくとも 3 つの方法があります。

• ボリュームを管理するかなり新しい方法であるCSI OpenStack cinder ドライバー。また、静的ポッド マニフェストではポッドのみを宣言でき、PVC/PV などの他のリソースは宣言できないため、CSI ドキュメントには次のように記載されているため、要件に適合しません。

  csi ボリューム タイプは Pod からの直接参照をサポートしておらず、PersistentVolumeClaim オブジェクトを介してのみ Pod で参照できます。

• ボリュームをアタッチする前の csi の方法は次のとおりです: FlexVolume。

  FlexVolume ドライバー バイナリは、各ノード (場合によってはマスター) の事前定義されたボリューム プラグイン パスにインストールする必要があります。

OK、これらのバイナリをノードに追加し (この DS を参照として使用)、次のようにポッド マニフェストにボリュームを追加しました。

volumes:
- name: test
  flexVolume:
    driver: "cinder.io/cinder-flex-volume-driver"
    fsType: "ext4"
    options:
      volumeID: "$VOLUME_ID"
      cinderConfig: "/etc/kubernetes/cloud-config"

kubelet ログから次のエラーを受け取りました。

driver-call.go:258] マウント コマンドが失敗しました、ステータス: 失敗、理由: ボリューム 2c21311b-7329-4cf4-8230-f3ce2f23cf1a が利用できません

この Cinder ボリュームは既に CoreOS コンピューティング インスタンスに接続されていると確信しているため、これは奇妙です。

• そして、私が知っているボリュームをマウントする最後の方法は、cinder in-tree サポートです。これは、少なくとも k8s 1.5--cloud-provider=openstack以降で機能し、--cloud-configkubelet オプション以外に特別な要件はありません。

静的ポッドのボリュームを宣言するための yaml マニフェスト パーツは次のようになります。

volumes:
  - name: html-volume
    cinder:
      # Enter the volume ID below
      volumeID: "$VOLUME_ID"
      fsType: ext4

残念ながら、この方法を試すと、kubelet から次のエラーが表示されます。

ボリュームは、ボリュームのノードのボリューム ステータスの VolumesInUse のリストに追加されていません。

意味がわかりませんが、ノードのステータスを更新できなかったようです (もちろん、まだ etcd と apiserver はありません)。悲しいことに、それは私にとって最も有望な選択肢でした。

OpenStack cinder ボリュームを kubelet のみに依存する静的ポッドにアタッチする他の方法はありますか (クラスターが実際には準備ができていない場合)? 私が見逃しているクラウドがエラーを上回ったというアイデアはありますか?