0

Minikube で MongoDB Community Kubernetes Operator を使用して、MongoDB レプリカ セットをデプロイしようとしています。
公式の GitHub の指示に従ったので、次のようにしました。

  • CRD のインストール
  • 必要なロールとロール バインディングをインストールする
  • Operator をインストールする Replicaset をデプロイする

デフォルトでは、オペレーターは 3 つの Pod を作成します。それぞれのポッドは、オペレーターによって作成された新しい永続ボリュームにバインドされた新しい永続ボリューム要求に自動的にリンクされます (これまでのところは問題ありません)。

ただし、データを特定のボリュームに保存し、特定のホスト パスにマウントしたいと考えています。そのため、それぞれが特定のホスト パスにマウントされた 3 つの永続ボリュームを作成する必要があるため、各ポッドがそれぞれの永続ボリュームに接続するように (おそらく matchLabels セレクターを使用して) 自動的にレプリカセットを構成する必要があります。そこで、次のファイルを適用して 3 つのボリュームを作成しました。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: mongodb-pv-00
  namespace: $NAMESPACE
  labels: 
    type: local
    service: mongo
spec:
  storageClassName: manual
  capacity:
    storage: 5Gi
  accessModes:
  - ReadWriteOnce
  hostPath: 
    path: "/mnt/mongodata/00"
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: mongodb-pv-01
  namespace: $NAMESPACE
  labels: 
    type: local
    service: mongo
spec:
  storageClassName: manual
  capacity:
    storage: 5Gi
  accessModes:
  - ReadWriteOnce
  hostPath: 
    path: "/mnt/mongodata/01"
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: mongodb-pv-02
  namespace: $NAMESPACE
  labels: 
    type: local
    service: mongo
spec:
  storageClassName: manual
  capacity:
    storage: 5Gi
  accessModes:
  - ReadWriteOnce
  hostPath: 
    path: "/mnt/mongodata/02"

次に、次の方法でレプリカ セットの構成ファイルをセットアップしましたが、ポッドをボリュームに接続できません。

apiVersion: mongodbcommunity.mongodb.com/v1
kind: MongoDBCommunity
metadata:
  name: mongo-rs
  namespace: $NAMESPACE
spec:
  members: 3
  type: ReplicaSet
  version: "4.4.0"
  persistent: true
  podSpec:
    persistence:
      single: 
        labelSelector: 
          matchLabels:
            type: local
            service: mongo
        storage: 5Gi
        storageClass: manual
  statefulSet:
    spec:
      volumeClaimTemplates:
        - metadata:
            name: data-volume
          spec:
            accessModes: [ "ReadWriteOnce", "ReadWriteMany" ]
            resources:
              requests:
                storage: 5Gi
            selector:
              matchLabels:
                type: local
                service: mongo
            storageClassName: manual
  security:
    authentication:
      modes: ["SCRAM"]
  users:
    - ...
  additionalMongodConfig:
    storage.wiredTiger.engineConfig.journalCompressor: zlib

mongodb.com_v1_custom_volume_cr.yamlを除いて、オンラインでドキュメントが見つかりません。以前にこの問題に直面した人はいますか? どうすればそれを機能させることができますか？

4

1 に答える 1

2

ローカル タイプのボリュームの使用に興味があると思います。それはこのように動作します：

最初に、ローカル ボリュームのストレージ クラスを作成します。次のようなもの：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer

を持っているのでno-provisioner、手動でローカルPVを作成する場合のみ使用可能になります。WaitForFirstConsumer代わりに、PV が使用可能なホストでスケジュールできない Pod の PVC に PV を接続することを防ぎます。

次に、ローカル PV を作成します。例でそれらを作成した方法と同様に、次のようになります。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: example-pv
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: local-storage
  local:
    path: /path/on/the/host
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - the-node-hostname-on-which-the-storage-is-located

定義に注意してください。ホスト上のパス、容量を示します。次に、クラスターのどのノードでそのような PV を使用できるかを説明します (nodeAffinity を使用)。また、以前に作成したストレージ クラスにもそれらをリンクします。そのため、誰か (クレーム テンプレート) がそのクラスでストレージを必要とする場合、この PV が見つかるようになります。

3 つの異なるノードに 3 つの PV を作成できます。または、同じノードの異なるパスに 3 つの PV を作成して、必要に応じて整理できます。

3 番目local-storageに、クレーム テンプレートでクラスを使用できるようになりました。クレーム テンプレートは次のようになります。

volumeClaimTemplates:
  - metadata:
      name: the-name-of-the-pvc
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "local-storage"
      resources:
        requests:
          storage: 5Gi

local-storageそして、StatefulSet の各 Pod は、 PV が利用可能なノードでスケジュールされようとします。

ローカル ストレージ、または一般に、ホスト パスを使用するボリュームを使用する場合、アプリのさまざまな Pod をさまざまなノードに分散して、アプリが単独で単一ノードの障害に耐えられるようにすることを忘れないでください。

どの Pod がどのボリュームにリンクするかを決定できるようにしたい場合、最も簡単な方法は、一度に 1 つの PV をクレートし、Pod がそれを使用するのを待っBoundて..次の PV を作成することです。最適ではありませんが、最も簡単な方法です。

于 2021-07-13T17:41:00.733 に答える