序章

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パッケージをインストールする必要があります。 そのために、Kubernetesを作成します DaemonSet aptを使用してノードにLVMパッケージをインストールします。 A DaemonSet 各ノードで1つのポッドを実行するデプロイメントです。

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

  1. nano lvm.yaml

The DaemonSet 各ノードで実行されるコンテナを定義します。 ここで定義します DaemonSet コンテナを実行している debian、インストールします lvm2 を使用して apt コマンドを実行し、を使用してインストールファイルをノードにコピーします。 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 が正しく構成されている場合は、次のコマンドを使用して適用します。

  1. kubectl apply -f lvm.yaml

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

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

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

  1. cd rook/cluster/examples/kubernetes/ceph

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

  1. kubectl create -f common.yaml

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

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

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

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

  1. nano operator.yaml

次に、 CSI_RBD_GRPC_METRICS_PORT 変数、削除してコメントを外します #、およびポートからの値を変更します 90909093:

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"

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

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

  1. kubectl create -f operator.yaml

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

Output
configmap/rook-ceph-operator-config created deployment.apps/rook-ceph-operator created

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

  1. kubectl get pod -n rook-ceph

あなたは -n 特定のKubernetes名前空間のポッドを取得するためのフラグ(rook-ceph この例では)。

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

Output
NAME 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クラスターをセットアップします。

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

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

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

  1. 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

Cephモニター(MON)の数は、 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ブロックデバイスです。

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

cephcluster.yaml
  rbdMirroring:
    workers: 0

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

cephcluster.yaml
  crashCollector:
    disable: false

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

cephcluster.yaml
  cleanupPolicy:
    deleteDataDirOnHosts: ""
  removeOSDsIfOutAndSafeToRemove: false

The 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クラスターに適用します。

  1. kubectl apply -f cephcluster.yaml

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

  1. kubectl get pod -n rook-ceph

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

Output
NAME 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がクラスターにストレージを提供する前に、まず、 storageclasscephblockpool. これにより、永続ボリュームを作成するときにKubernetesがRookと相互運用できるようになります。

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

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

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

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

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

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

  1. 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 現在の安定バージョンです)。 次に、を使用して定義するリソースのタイプをKubernetesに通知する必要があります。 kind 鍵 (PersistentVolumeClaim この場合)。

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

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

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

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

Output
persistentvolumeclaim/mongo-pvc created

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

  1. kubectl get pvc

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

Output
NAME 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データベースのデータを保持するための永続ボリューム。
  • ポートでMongoDBポートを公開するサービス 31017 後で操作できるように、すべてのノードの

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

  1. 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、これは安定バージョンです。 次に、を使用して定義するリソースをKubernetesに通知します。 kind 鍵。 各定義には、で定義された名前も必要です。 metadata.name.

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

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

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

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

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

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 サービスタイプとして、 Service 間の静的ポートでの各ノードのIP 3000032767 (31017 この場合)。

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

  1. kubectl apply -f mongo.yaml

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

Output
deployment.apps/mongo created service/mongo created

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

  1. kubectl get svc,deployments

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

Output
NAME 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を使用して開くことができます。

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

  1. kubectl get pods

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

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

名前をコピーして、 exec 指図:

  1. kubectl exec -it your_pod_name mongo

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

  1. use test

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

Output
switched to db test

次に、新しいデータにデータを挿入します test データベース。 あなたは insertOne() 作成したデータベースに新しいドキュメントを挿入する方法:

  1. db.test.insertOne( {name: "test", number: 10 })
Output
{ "acknowledged" : true, "insertedId" : ObjectId("5f22dd521ba9331d1a145a58") }

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

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

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

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

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

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

  1. kubectl delete pod -l app=mongo

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

  1. kubectl get pods

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

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

名前をコピーして、 exec 指図:

  1. kubectl exec -it your_pod_name mongo

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

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

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

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

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

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

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

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

ツールボックスは、 toolbox.yaml にあるファイル examples/kubernetes/ceph ディレクトリ:

  1. kubectl apply -f toolbox.yaml

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

Output
deployment.apps/rook-ceph-tools created

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

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

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

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

ポッドが実行されたら、を使用してポッドに接続できます kubectl exec 指図:

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

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

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

  1. 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などの特定のアイテムのステータスを照会することもできます。

  1. 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が提供する他の種類のストレージを試すこともできます。