Rookを使用してKubernetes内にCephクラスターを設定する方法

著者は、 Write for DOnations プログラムの一環として、 MozillaFoundationを選択して寄付を受け取りました。

序章

Kubernetes コンテナは、コア原則としてステートレスですが、データを管理、保存し、他のサービスにアクセスできるようにする必要があります。 ステートレスとは、過去のトランザクションの知識がなくてもコンテナーが分離して実行されていることを意味します。これにより、コンテナーの交換、削除、または配布が簡単になります。 ただし、再起動や削除などの特定のライフサイクルイベントではデータが失われることも意味します。

Rook は、さまざまなストレージプロバイダーのセットにクラウドネイティブのオープンソースソリューションを提供するストレージオーケストレーションツールです。 Rookは、Kubernetesの機能を使用して、ストレージシステムを自己管理サービスに変え、Kubernetesアプリケーションまたはデプロイデータを保存するためのシームレスなエクスペリエンスを提供します。

Ceph は、オブジェクト、ブロック、およびファイルのストレージを提供する、高度にスケーラブルな分散ストレージソリューションです。 Cephクラスターは、いわゆる CRUSHアルゴリズム（スケーラブルハッシュでの制御されたレプリケーション）を使用して、任意のハードウェアで実行するように設計されています。

このデプロイメントの主な利点の1つは、Rookが自動的に処理するため、Cephコマンドラインを使用して手動で構成しなくても、Cephの拡張性の高いストレージソリューションを利用できることです。 その後、Kubernetesアプリケーションは、Rookからブロックデバイスとファイルシステムをマウントして、アプリケーションデータを保存および監視できます。

このチュートリアルでは、Rookを使用してCephクラスターをセットアップし、それを使用して、例としてMongoDBデータベースのデータを永続化します。

注：このガイドは、Rook Cephの概要として使用する必要があり、多数のマシンを使用した実稼働展開を目的としたものではありません。

前提条件

このガイドを開始する前に、次のものが必要です。

• DigitalOcean Kubernetesクラスターには、それぞれ2つのvCPUと4GBのメモリを備えた少なくとも3つのノードがあります。 DigitalOceanでクラスターを作成して接続するには、 KubernetesQuickstartを参照してください。
• 開発サーバーにインストールされ、クラスターに接続するように構成されたkubectlコマンドラインツール。 kubectlのインストールの詳細については、公式ドキュメントを参照してください。
• DigitalOceanブロックストレージボリューム。作成したクラスターのノードごとに少なくとも100GB。たとえば、ノードが3つある場合は、3つのボリュームが必要になります。 自動ではなく手動フォーマットを選択してから、ボリュームをノードプールのドロップレットに接続します。 VolumesQuickstartに従ってこれを達成できます。

ステップ1—ルークを設定する

前提条件を完了すると、3つのノードと3つのボリュームを備えた完全に機能するKubernetesクラスターが完成します。これで、Rookをセットアップする準備が整いました。

このセクションでは、Rookリポジトリのクローンを作成し、最初のRook operator をKubernetesクラスターにデプロイし、指定されたデプロイステータスを検証します。 Rookオペレーターは、ストレージクラスターを自動的にブートストラップし、ストレージデーモンを監視して、ストレージクラスターが正常であることを確認するコンテナーです。

必要なRookリソースのデプロイを開始する前に、まずCephの前提条件としてすべてのノードにLVMパッケージをインストールする必要があります。 そのために、aptを使用してノードにLVMパッケージをインストールするKubernetesDaemonSetを作成します。 DaemonSetは、各ノードで1つのポッドを実行するデプロイメントです。

まず、YAMLファイルを作成します。

nano lvm.yaml

DaemonSetは、各ノードで実行されるコンテナーを定義します。 ここでは、debianを実行しているコンテナでDaemonSetを定義します。このコンテナは、aptコマンドを使用してlvm2をインストールし、volumeMounts：

lvm.yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
 name: lvm
 namespace: kube-system
spec:
 revisionHistoryLimit: 10
 selector:
   matchLabels:
     name: lvm
 template:
   metadata:
     labels:
       name: lvm
   spec:
     containers:
     - args:
       - apt -y update; apt -y install lvm2
       command:
       - /bin/sh
       - -c
       image: debian:10
       imagePullPolicy: IfNotPresent
       name: lvm
       securityContext:
         privileged: true
       volumeMounts:
       - mountPath: /etc
         name: etc
       - mountPath: /sbin
         name: sbin
       - mountPath: /usr
         name: usr
       - mountPath: /lib
         name: lib
     dnsPolicy: ClusterFirst
     restartPolicy: Always
     schedulerName: default-scheduler
     securityContext:
     volumes:
     - hostPath:
         path: /etc
         type: Directory
       name: etc
     - hostPath:
         path: /sbin
         type: Directory
       name: sbin
     - hostPath:
         path: /usr
         type: Directory
       name: usr
     - hostPath:
         path: /lib
         type: Directory
       name: lib

DaemonSetが正しく構成されたので、次のコマンドを使用して適用します。

kubectl apply -f lvm.yaml

すべての前提条件が満たされたら、Rookリポジトリのクローンを作成します。これで、Rookクラスターのセットアップを開始するために必要なすべてのリソースが得られます。

git clone --single-branch --branch release-1.3 https://github.com/rook/rook.git

このコマンドは、GitHubからRookリポジトリのクローンを作成し、ディレクトリにrookという名前のフォルダーを作成します。 次に、次のコマンドを使用してディレクトリに入ります。

cd rook/cluster/examples/kubernetes/ceph

次に、Rookのデプロイに必要な共通リソースを作成します。これは、ディレクトリでデフォルトで利用可能なKubernetes構成ファイルをデプロイすることで実行できます。

kubectl create -f common.yaml

作成したリソースは主にCustomResourceDefinitions（CRD）であり、オペレーターが後で使用する新しいリソースを定義します。 これらには、ServiceAccount、Role、RoleBinding、ClusterRole、ClusterRoleBindingなどのリソースが含まれています。

注：この標準ファイルは、RookオペレーターとすべてのCephデーモンを同じ名前空間にデプロイすることを前提としています。 別の名前空間に演算子をデプロイする場合は、common.yamlファイル全体のコメントを参照してください。

共通リソースが作成されたら、次のステップはRookオペレーターを作成することです。

DigitalOcean Kubernetesクラスタはデフォルトですでに標準ポートを使用しているため、operator.yamlファイルをデプロイする前に、CSI_RBD_GRPC_METRICS_PORT変数を変更する必要があります。 次のコマンドでファイルを開きます。

nano operator.yaml

次に、CSI_RBD_GRPC_METRICS_PORT変数を検索し、#を削除してコメントを解除し、値をポート9090から9093に変更します。

operator.yaml

kind: ConfigMap
apiVersion: v1
metadata:
  name: rook-ceph-operator-config
  namespace: rook-ceph
data:
  ROOK_CSI_ENABLE_CEPHFS: "true"
  ROOK_CSI_ENABLE_RBD: "true"
  ROOK_CSI_ENABLE_GRPC_METRICS: "true"
  CSI_ENABLE_SNAPSHOTTER: "true"
  CSI_FORCE_CEPHFS_KERNEL_CLIENT: "true"
  ROOK_CSI_ALLOW_UNSUPPORTED_VERSION: "false"
  # Configure CSI CSI Ceph FS grpc and liveness metrics port
  # CSI_CEPHFS_GRPC_METRICS_PORT: "9091"
  # CSI_CEPHFS_LIVENESS_METRICS_PORT: "9081"
  # Configure CSI RBD grpc and liveness metrics port
  CSI_RBD_GRPC_METRICS_PORT: "9093"
  # CSI_RBD_LIVENESS_METRICS_PORT: "9080"

完了したら、ファイルを保存して終了します。

次に、次のコマンドを使用してオペレーターをデプロイできます。

kubectl create -f operator.yaml

コマンドは以下を出力します：

Outputconfigmap/rook-ceph-operator-config created
deployment.apps/rook-ceph-operator created

ここでも、kubectl createコマンドと-fフラグを使用して、適用するファイルを割り当てています。 オペレーターが実行されるまでに数秒かかります。 次のコマンドを使用して、ステータスを確認できます。

kubectl get pod -n rook-ceph

-nフラグを使用して、特定のKubernetes名前空間（この例ではrook-ceph）のポッドを取得します。

オペレーターのデプロイメントの準備が整うと、クラスターの各ワーカーノードでrook-discoveryエージェントの作成を担当するDeamonSetの作成がトリガーされます。 次のような出力が表示されます。

OutputNAME                                  READY   STATUS    RESTARTS   AGE
rook-ceph-operator-599765ff49-fhbz9   1/1     Running   0          92s
rook-discover-6fhlb                   1/1     Running   0          55s
rook-discover-97kmz                   1/1     Running   0          55s
rook-discover-z5k2z                   1/1     Running   0          55s

これで、Rookが正常にインストールされ、最初のオペレーターがデプロイされました。 次に、Cephクラスターを作成し、それが機能していることを確認します。

ステップ2—Cephクラスターを作成する

KubernetesクラスターでRookを正常にセットアップしたので、引き続きKubernetesクラスター内にCephクラスターを作成し、その機能を確認します。

まず、最も重要なCephコンポーネントとその機能を確認しましょう。

• Ceph Monitors は、MONとも呼ばれ、Cephデーモンが相互に調整するために必要なクラスターのマップを維持する役割を果たします。 ストレージサービスの信頼性と可用性を高めるために、常に複数のMONを実行する必要があります。
• Ceph Managers は、MGRとも呼ばれ、ランタイムメトリックとCephクラスターの現在の状態を追跡するためのランタイムデーモンです。 これらは、監視デーモン（MON）と一緒に実行され、追加の監視と、外部の監視および管理システムへのインターフェースを提供します。
• Ceph Object Store Devices は、OSDとも呼ばれ、ローカルファイルシステムにオブジェクトを保存し、ネットワーク経由でオブジェクトへのアクセスを提供します。 これらは通常、クラスターの1つの物理ディスクに関連付けられています。 CephクライアントはOSDと直接対話します。

Cephストレージのデータを操作するために、クライアントは最初にCeph Monitors（MON）に接続して、クラスターマップの現在のバージョンを取得します。 クラスタマップには、データの保存場所とクラスタトポロジが含まれています。 次に、Cephクライアントはクラスターマップを使用して、対話する必要のあるOSDを決定します。

Rookを使用すると、CephストレージをKubernetesクラスターで実行できます。 これらのコンポーネントはすべてRookクラスターで実行されており、Rookエージェントと直接対話します。 これにより、高度な構成のオプションを提供しながら、配置グループやストレージマップなどのCephコンポーネントを非表示にすることで、Cephクラスターを管理するためのより合理化されたエクスペリエンスが提供されます。

Cephとは何か、Rookでの使用方法について理解が深まったので、次にCephクラスターをセットアップします。

Rookプロジェクトのexamplesディレクトリにある設定例を実行するか、独自の設定を作成することで、セットアップを完了することができます。 構成例はほとんどのユースケースに適していて、オプションのパラメーターの優れたドキュメントを提供します。

次に、Cephクラスター KubernetesObjectの作成プロセスを開始します。

まず、YAMLファイルを作成する必要があります。

nano cephcluster.yaml

構成は、Cephクラスターのデプロイ方法を定義します。 この例では、3つのCephモニター（MON）をデプロイし、Cephダッシュボードを有効にします。 Cephダッシュボードはこのチュートリアルの範囲外ですが、後でCephクラスターの現在のステータスを視覚化するために独自のプロジェクトで使用できます。

次のコンテンツを追加して、apiVersionとKubernetesオブジェクトkind、およびオブジェクトをデプロイする必要があるnameとnamespaceを定義します。

cephcluster.yaml

apiVersion: ceph.rook.io/v1
kind: CephCluster
metadata:
  name: rook-ceph
  namespace: rook-ceph

その後、specキーを追加します。これは、KubernetesがCephクラスターの作成に使用するモデルを定義します。 最初に、使用するイメージバージョンと、サポートされていないCephバージョンを許可するかどうかを定義します。

cephcluster.yaml

spec:
  cephVersion:
    image: ceph/ceph:v14.2.8
    allowUnsupported: false

次に、dataDirHostPathキーを使用して、構成ファイルを永続化するデータディレクトリを設定します。

cephcluster.yaml

  dataDirHostPath: /var/lib/rook

次に、次のパラメーターを使用して、アップグレードチェックをスキップするかどうか、およびクラスターをアップグレードするタイミングを定義します。

cephcluster.yaml

  skipUpgradeChecks: false
  continueUpgradeAfterChecksEvenIfNotHealthy: false

monキーを使用して、Cephモニター（MON）の数を構成します。 また、ノードごとに複数のMONを展開することもできます。

cephcluster.yaml

  mon:
    count: 3
    allowMultiplePerNode: false

Cephダッシュボードのオプションは、dashboardキーで定義されています。 これにより、ダッシュボードを有効にし、ポートをカスタマイズし、リバースプロキシを使用するときにプレフィックスを付けるオプションが提供されます。

cephcluster.yaml

  dashboard:
    enabled: true
    # serve the dashboard under a subpath (useful when you are accessing the dashboard via a reverse proxy)
    # urlPrefix: /ceph-dashboard
    # serve the dashboard at the given port.
    # port: 8443
    # serve the dashboard using SSL
    ssl: false

monitoringキーを使用してクラスターの監視を有効にすることもできます（監視には Prometheusがプリインストールされている必要があります）。

cephcluster.yaml

  monitoring:
    enabled: false
    rulesNamespace: rook-ceph

RDBはRADOS（Reliable Autonomic Distributed Object Store）ブロックデバイスの略で、複数のノードにデータを格納するシンプロビジョニングされたサイズ変更可能なCephブロックデバイスです。

rbdMirroringを有効にすることで、RBDイメージを2つのCephクラスター間で非同期に共有できます。 このチュートリアルでは1つのクラスターを使用しているため、これは必要ありません。 したがって、ワーカーの数は0に設定されます。

cephcluster.yaml

  rbdMirroring:
    workers: 0

Cephデーモンのクラッシュコレクターを有効にできます。

cephcluster.yaml

  crashCollector:
    disable: false

クリーンアップポリシーは、クラスターを削除する場合にのみ重要です。 そのため、このオプションは空のままにする必要があります。

cephcluster.yaml

  cleanupPolicy:
    deleteDataDirOnHosts: ""
  removeOSDsIfOutAndSafeToRemove: false

storageキーを使用すると、クラスターレベルのストレージオプションを定義できます。 たとえば、使用するノードとデバイス、データベースサイズ、デバイスごとに作成するOSDの数などです。

cephcluster.yaml

  storage:
    useAllNodes: true
    useAllDevices: true
    config:
      # metadataDevice: "md0" # specify a non-rotational storage so ceph-volume will use it as block db device of bluestore.
      # databaseSizeMB: "1024" # uncomment if the disks are smaller than 100 GB
      # journalSizeMB: "1024"  # uncomment if the disks are 20 GB or smaller

disruptionManagementキーを使用して、アップグレードまたはフェンシング中のデーモンの中断を管理します。

cephcluster.yaml

  disruptionManagement:
    managePodBudgets: false
    osdMaintenanceTimeout: 30
    manageMachineDisruptionBudgets: false
    machineDisruptionBudgetNamespace: openshift-machine-api

これらの構成ブロックにより、最終的に次のファイルが作成されます。

cephcluster.yaml

apiVersion: ceph.rook.io/v1
kind: CephCluster
metadata:
  name: rook-ceph
  namespace: rook-ceph
spec:
  cephVersion:
    image: ceph/ceph:v14.2.8
    allowUnsupported: false
  dataDirHostPath: /var/lib/rook
  skipUpgradeChecks: false
  continueUpgradeAfterChecksEvenIfNotHealthy: false
  mon:
    count: 3
    allowMultiplePerNode: false
  dashboard:
    enabled: true
    # serve the dashboard under a subpath (useful when you are accessing the dashboard via a reverse proxy)
    # urlPrefix: /ceph-dashboard
    # serve the dashboard at the given port.
    # port: 8443
    # serve the dashboard using SSL
    ssl: false
  monitoring:
    enabled: false
    rulesNamespace: rook-ceph
  rbdMirroring:
    workers: 0
  crashCollector:
    disable: false
  cleanupPolicy:
    deleteDataDirOnHosts: ""
  removeOSDsIfOutAndSafeToRemove: false
  storage:
    useAllNodes: true
    useAllDevices: true
    config:
      # metadataDevice: "md0" # specify a non-rotational storage so ceph-volume will use it as block db device of bluestore.
      # databaseSizeMB: "1024" # uncomment if the disks are smaller than 100 GB
      # journalSizeMB: "1024"  # uncomment if the disks are 20 GB or smaller
  disruptionManagement:
    managePodBudgets: false
    osdMaintenanceTimeout: 30
    manageMachineDisruptionBudgets: false
    machineDisruptionBudgetNamespace: openshift-machine-api

完了したら、ファイルを保存して終了します。

データベースサイズを変更したり、ダッシュボードのカスタムポートを定義したりして、展開をカスタマイズすることもできます。 Rookリポジトリのクラスターの例で、クラスターデプロイメントのその他のオプションを見つけることができます。

次に、このマニフェストをKubernetesクラスターに適用します。

kubectl apply -f cephcluster.yaml

次に、ポッドが実行されていることを確認します。

kubectl get pod -n rook-ceph

これには通常数分かかるため、出力に次のようなものが反映されるまで更新してください。

OutputNAME                                                   READY   STATUS    RESTARTS   AGE
csi-cephfsplugin-lz6dn                                 3/3     Running   0          3m54s
csi-cephfsplugin-provisioner-674847b584-4j9jw          5/5     Running   0          3m54s
csi-cephfsplugin-provisioner-674847b584-h2cgl          5/5     Running   0          3m54s
csi-cephfsplugin-qbpnq                                 3/3     Running   0          3m54s
csi-cephfsplugin-qzsvr                                 3/3     Running   0          3m54s
csi-rbdplugin-kk9sw                                    3/3     Running   0          3m55s
csi-rbdplugin-l95f8                                    3/3     Running   0          3m55s
csi-rbdplugin-provisioner-64ccb796cf-8gjwv             6/6     Running   0          3m55s
csi-rbdplugin-provisioner-64ccb796cf-dhpwt             6/6     Running   0          3m55s
csi-rbdplugin-v4hk6                                    3/3     Running   0          3m55s
rook-ceph-crashcollector-pool-33zy7-68cdfb6bcf-9cfkn   1/1     Running   0          109s
rook-ceph-crashcollector-pool-33zyc-565559f7-7r6rt     1/1     Running   0          53s
rook-ceph-crashcollector-pool-33zym-749dcdc9df-w4xzl   1/1     Running   0          78s
rook-ceph-mgr-a-7fdf77cf8d-ppkwl                       1/1     Running   0          53s
rook-ceph-mon-a-97d9767c6-5ftfm                        1/1     Running   0          109s
rook-ceph-mon-b-9cb7bdb54-lhfkj                        1/1     Running   0          96s
rook-ceph-mon-c-786b9f7f4b-jdls4                       1/1     Running   0          78s
rook-ceph-operator-599765ff49-fhbz9                    1/1     Running   0          6m58s
rook-ceph-osd-prepare-pool-33zy7-c2hww                 1/1     Running   0          21s
rook-ceph-osd-prepare-pool-33zyc-szwsc                 1/1     Running   0          21s
rook-ceph-osd-prepare-pool-33zym-2p68b                 1/1     Running   0          21s
rook-discover-6fhlb                                    1/1     Running   0          6m21s
rook-discover-97kmz                                    1/1     Running   0          6m21s
rook-discover-z5k2z                                    1/1     Running   0          6m21s

これで、Cephクラスターが正常にセットアップされ、最初のストレージブロックを作成して続行できます。

ステップ3—ブロックストレージの追加

ブロックストレージを使用すると、1つのポッドでストレージをマウントできます。 このセクションでは、後でアプリケーションで使用できるストレージブロックを作成します。

Cephがクラスターにストレージを提供する前に、まずstorageclassとcephblockpoolを作成する必要があります。 これにより、永続ボリュームを作成するときにKubernetesがRookと相互運用できるようになります。

kubectl apply -f ./csi/rbd/storageclass.yaml

コマンドは以下を出力します：

Outputcephblockpool.ceph.rook.io/replicapool created
storageclass.storage.k8s.io/rook-ceph-block created

注： rook-ceph以外の名前空間にRook演算子をデプロイした場合は、使用する名前空間に一致するようにプロビジョナーのプレフィックスを変更する必要があります。

storageclassおよびcephblockpoolを正常に展開した後、アプリケーションの PersistentVolumeClaim（PVC）を定義して続行します。 PersistentVolumeClaimは、クラスターからストレージを要求するために使用されるリソースです。

そのためには、最初にYAMLファイルを作成する必要があります。

nano pvc-rook-ceph-block.yaml

PersistentVolumeClaimに以下を追加します。

pvc-rook-ceph-block.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mongo-pvc
spec:
  storageClassName: rook-ceph-block
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

まず、apiVersionを設定する必要があります（v1は現在の安定バージョンです）。 次に、kindキー（この場合はPersistentVolumeClaim）を使用して、定義するリソースのタイプをKubernetesに通知する必要があります。

specキーは、KubernetesがPersistentVolumeClaimを作成するために使用するモデルを定義します。 ここで、前に作成したストレージクラスrook-ceph-blockを選択する必要があります。 次に、アクセスモードを定義し、クレームのリソースを制限できます。 ReadWriteOnceは、ボリュームを単一のノードでのみマウントできることを意味します。

PersistentVolumeClaimを定義したので、次のコマンドを使用してデプロイします。

kubectl apply -f pvc-rook-ceph-block.yaml

次の出力が表示されます。

Outputpersistentvolumeclaim/mongo-pvc created

これで、PVCのステータスを確認できます。

kubectl get pvc

PVCがバインドされると、準備が整います。

OutputNAME        STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      AGE
mongo-pvc   Bound    pvc-ec1ca7d1-d069-4d2a-9281-3d22c10b6570   5Gi        RWO            rook-ceph-block   16s

これで、ストレージクラスが正常に作成され、それを使用してPersistenVolumeClaimが作成されました。このクラスをアプリケーションにマウントして、次のセクションでデータを永続化します。

ステップ4—rook-ceph-blockを使用してMongoDBデプロイメントを作成する

ストレージブロックと永続ボリュームが正常に作成されたので、MongoDBアプリケーションに実装して使用できるようにします。

構成にはいくつかのものが含まれます。

• mongoイメージの最新バージョンに基づく単一コンテナーの展開。
• MongoDBデータベースのデータを保持するための永続ボリューム。
• すべてのノードのポート31017でMongoDBポートを公開して、後で操作できるようにするサービス。

最初に構成ファイルを開きます。

nano mongo.yaml

Deploymentリソースでマニフェストを開始します。

mongo.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mongo
spec:
  selector:
    matchLabels:
      app: mongo
  template:
    metadata:
      labels:
        app: mongo
    spec:
      containers:
      - image: mongo:latest
        name: mongo
        ports:
        - containerPort: 27017
          name: mongo
        volumeMounts:
        - name: mongo-persistent-storage
          mountPath: /data/db
      volumes:
      - name: mongo-persistent-storage
        persistentVolumeClaim:
          claimName: mongo-pvc

...

マニフェストのリソースごとに、apiVersionを設定する必要があります。 デプロイメントとサービスには、安定バージョンであるapiVersion: apps/v1を使用してください。 次に、kindキーを使用して定義するリソースをKubernetesに通知します。 各定義には、metadata.nameで定義された名前も必要です。

specセクションは、デプロイの最終状態の望ましい状態をKubernetesに通知します。 この定義では、Kubernetesが1つのレプリカで1つのポッドを作成する必要があります。

ラベルは、Kubernetesリソースを整理して相互参照するのに役立つキーと値のペアです。 metadata.labelsを使用してそれらを定義し、後でselector.matchLabelsを使用してそれらを検索できます。

spec.templateキーは、Kubernetesが各ポッドを作成するために使用するモデルを定義します。 ここでは、イメージ名、コンテナポート、マウントする必要のあるボリュームなど、ポッドの展開の詳細を定義します。 その後、画像はKubernetesによって画像レジストリから自動的にプルされます。

ここでは、前に作成したPersistentVolumeClaimを使用して、ポッドの/data/dbディレクトリのデータを永続化します。 デプロイメントをさらにカスタマイズするのに役立つ環境変数などの追加情報を指定することもできます。

次に、次のコードをファイルに追加して、クラスター内のすべてのノードのポート31017でMongoDBポートを公開するKubernetesServiceを定義します。

mongo.yaml

...

---
apiVersion: v1
kind: Service
metadata:
  name: mongo
  labels:
    app: mongo
spec:
  selector:
    app: mongo
  type: NodePort
  ports:
    - port: 27017
      nodePort: 31017

ここでは、apiVersionも定義しますが、Deploymentタイプを使用する代わりに、Serviceを定義します。 サービスはポート31017で接続を受信し、ポッドのポート27017に転送します。ここで、アプリケーションにアクセスできます。

サービスはサービスタイプとしてNodePortを使用し、30000と32767（31017）。

デプロイメントを定義したので、次はそれをデプロイします。

kubectl apply -f mongo.yaml

次の出力が表示されます。

Outputdeployment.apps/mongo created
service/mongo created

デプロイメントとサービスのステータスを確認できます。

kubectl get svc,deployments

出力は次のようになります。

OutputNAME                 TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)           AGE
service/kubernetes   ClusterIP   10.245.0.1       <none>        443/TCP           33m
service/mongo        NodePort    10.245.124.118   <none>        27017:31017/TCP   4m50s

NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/mongo   1/1     1            1           4m50s

デプロイメントの準備ができたら、データベースへのデータの保存を開始できます。 これを行う最も簡単な方法は、開始したばかりのMongoDBポッドに含まれているMongoDBシェルを使用することです。 kubectlを使用して開くことができます。

そのためには、ポッドの名前が必要になります。これは、次のコマンドを使用して取得できます。

kubectl get pods

出力は次のようになります。

OutputNAME                     READY   STATUS    RESTARTS   AGE
mongo-7654889675-mjcks   1/1     Running   0          13m

名前をコピーして、execコマンドで使用します。

kubectl exec -it your_pod_name mongo

これでMongoDBシェルができたので、データベースを作成して続行しましょう。

use test

useコマンドは、データベースを切り替えるか、データベースが存在しない場合はデータベースを作成します。

Outputswitched to db test

次に、いくつかのデータを新しいtestデータベースに挿入します。 insertOne()メソッドを使用して、作成したデータベースに新しいドキュメントを挿入します。

db.test.insertOne( {name: "test", number: 10  })

Output{
    "acknowledged" : true,
    "insertedId" : ObjectId("5f22dd521ba9331d1a145a58")
}

次のステップは、データを取得して保存されていることを確認することです。これは、コレクションでfindコマンドを使用して実行できます。

db.getCollection("test").find()

出力は次のようになります。

OutputNAME                     READY   STATUS    RESTARTS   AGE
{ "_id" : ObjectId("5f1b18e34e69b9726c984c51"), "name" : "test", "number" : 10 }

いくつかのデータをデータベースに保存したので、そのデータは基盤となるCephボリューム構造に保持されます。 この種のデプロイメントの大きな利点の1つは、ボリュームの動的プロビジョニングです。 動的プロビジョニングとは、アプリケーションがストレージをリクエストするだけでよく、開発者がストレージプロバイダーにリクエストを送信してストレージを手動で作成する代わりに、Cephによって自動的に提供されることを意味します。

ポッドを再起動し、データがまだそこにあるかどうかを確認して、この機能を検証しましょう。 ポッドを削除することでこれを行うことができます。これは、展開で定義された状態を満たすためにポッドが再起動されるためです。

kubectl delete pod -l app=mongo

次に、MongoDBシェルに接続してデータを出力することにより、データがまだ存在することを検証しましょう。 そのためには、最初にポッドの名前を取得してから、execコマンドを使用してMongoDBシェルを開く必要があります。

kubectl get pods

出力は次のようになります。

OutputNAME                     READY   STATUS    RESTARTS   AGE
mongo-7654889675-mjcks   1/1     Running   0          13m

名前をコピーして、execコマンドで使用します。

kubectl exec -it your_pod_name mongo

その後、データベースに接続してコレクション全体を印刷することにより、データを取得できます。

use test
db.getCollection("test").find()

出力は次のようになります。

OutputNAME                     READY   STATUS    RESTARTS   AGE
{ "_id" : ObjectId("5f1b18e34e69b9726c984c51"), "name" : "test", "number" : 10 }

ご覧のとおり、ポッドを再起動しても、以前に保存したデータはデータベースに残っています。 RookとCephを正常にセットアップし、それらを使用してデプロイメントのデータを永続化したので、Rookツールボックスとそれを使用して何ができるかを確認しましょう。

ステップ5—RookToolboxを実行する

Rook Toolbox は、Cephデプロイメントの現在の状態を取得し、問題が発生したときにトラブルシューティングするのに役立つツールです。 また、特定のモジュールの有効化、ユーザーの作成、プールなど、Ceph構成を変更することもできます。

このセクションでは、Rook Toolboxをインストールし、それを使用して、現在のCephステータスの取得などの基本的なコマンドを実行します。

ツールボックスは、examples/kubernetes/cephディレクトリにあるtoolbox.yamlファイルを展開することで開始できます。

kubectl apply -f toolbox.yaml

次の出力が表示されます。

Outputdeployment.apps/rook-ceph-tools created

次に、ポッドが実行されていることを確認します。

kubectl -n rook-ceph get pod -l "app=rook-ceph-tools"

出力は次のようになります。

OutputNAME                               READY   STATUS    RESTARTS   AGE
rook-ceph-tools-7c5bf67444-bmpxc   1/1     Running   0          9s

ポッドが実行されたら、kubectl execコマンドを使用してポッドに接続できます。

kubectl -n rook-ceph exec -it $(kubectl -n rook-ceph get pod -l "app=rook-ceph-tools" -o jsonpath='{.items[0].metadata.name}') bash

理解を深めるために、このコマンドを分解してみましょう。

1. kubectl execコマンドを使用すると、ポッドでコマンドを実行できます。 環境変数の設定やサービスの開始などです。 ここでは、ポッドのBASHターミナルを開くために使用します。 実行するコマンドは、コマンドの最後に定義されています。
2. -nフラグを使用して、ポッドが実行されているKubernetes名前空間を指定します。
3. -i（インタラクティブ）フラグと-t（ tty ）フラグは、ttyを有効にしてインタラクティブモードでコマンドを実行することをKubernetesに通知します。 これにより、開いたターミナルを操作できます。
4. $()を使用すると、コマンドで式を定義できます。 つまり、式はメインコマンドの前に評価（実行）され、結果の値は引数としてメインコマンドに渡されます。 ここでは、ラベルapp=rook-ceph-toolのポッドを取得し、jsonpathを使用してポッドの名前を読み取る別のKubernetesコマンドを定義します。 次に、最初のコマンドの引数として名前を使用します。

注：すでに述べたように、このコマンドはポッド内のターミナルを開くため、プロンプトはこれを反映するように変更されます。

ポッドに接続したので、Cephコマンドを実行して、現在のステータスを確認したり、エラーメッセージのトラブルシューティングを行ったりできます。 たとえば、ceph statusコマンドは、Ceph構成の現在のヘルスステータスと、実行中のMON、現在実行中のデータプール、使用可能で使用済みのストレージ、現在のI/O操作などの詳細情報を提供します。

ceph status

コマンドの出力は次のとおりです。

Output  cluster:
    id:     71522dde-064d-4cf8-baec-2f19b6ae89bf
    health: HEALTH_OK

  services:
    mon: 3 daemons, quorum a,b,c (age 23h)
    mgr: a(active, since 23h)
    osd: 3 osds: 3 up (since 23h), 3 in (since 23h)

  data:
    pools:   1 pools, 32 pgs
    objects: 61 objects, 157 MiB
    usage:   3.4 GiB used, 297 GiB / 300 GiB avail
    pgs:     32 active+clean

  io:
    client:   5.3 KiB/s wr, 0 op/s rd, 0 op/s wr

次のコマンドを使用して、OSDなどの特定のアイテムのステータスを照会することもできます。

ceph osd status

これにより、使用済みおよび使用可能なストレージやOSDの現在の状態などのOSDに関する情報が出力されます。

Output+----+------------+-------+-------+--------+---------+--------+---------+-----------+
| id |    host    |  used | avail | wr ops | wr data | rd ops | rd data |   state   |
+----+------------+-------+-------+--------+---------+--------+---------+-----------+
| 0  | node-3jis6 | 1165M | 98.8G |    0   |     0   |    0   |     0   | exists,up |
| 1  | node-3jisa | 1165M | 98.8G |    0   |  5734   |    0   |     0   | exists,up |
| 2  | node-3jise | 1165M | 98.8G |    0   |     0   |    0   |     0   | exists,up |
+----+------------+-------+-------+--------+---------+--------+---------+-----------+

使用可能なコマンドと、それらを使用してCephデプロイメントをデバッグする方法の詳細については、公式ドキュメントを参照してください。

これで、Kubernetesに完全なRook Cephクラスターを正常にセットアップできました。これにより、何らかの外部ストレージを使用したり、ストレージを手動でプロビジョニングしたりすることなく、デプロイのデータを永続化し、異なるポッド間で状態を共有できます。 また、Rook Toolboxを起動し、それを使用してCephデプロイメントのデバッグとトラブルシューティングを行う方法も学びました。

結論

この記事では、Kubernetesで独自のRook Cephクラスターを構成し、それを使用してMongoDBアプリケーションのストレージを提供しました。 有用な用語を抽出し、Rookの基本的な概念に精通しているため、デプロイメントをカスタマイズできます。

詳細については、公式のRookドキュメントとリポジトリで提供されている構成例を確認してください。構成オプションとパラメーターの詳細を確認してください。

同じボリュームを複数のポッドに同時にマウントする場合は、共有ファイルシステムなどのCephが提供する他の種類のストレージを試すこともできます。