Rookを使用してKubernetes内にCephクラスターを設定する方法
序章
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ファイルを作成します。
- nano lvm.yaml
The DaemonSet
各ノードで実行されるコンテナを定義します。 ここで定義します DaemonSet
コンテナを実行している debian
、インストールします lvm2
を使用して apt
コマンドを実行し、を使用してインストールファイルをノードにコピーします。 volumeMounts
:
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オペレーターを作成することです。
展開する前に operator.yaml
ファイル、あなたは変更する必要があります CSI_RBD_GRPC_METRICS_PORT
DigitalOcean Kubernetesクラスターは既にデフォルトで標準ポートを使用しているため、変数です。 次のコマンドでファイルを開きます。
- nano operator.yaml
次に、 CSI_RBD_GRPC_METRICS_PORT
変数、削除してコメントを外します #
、およびポートからの値を変更します 9090
に 9093
:
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
この例では)。
オペレーターのデプロイメントの準備ができると、作成を担当するDeamonSetの作成がトリガーされます。 rook-discovery
クラスターの各ワーカーノード上のエージェント。 次のような出力が表示されます。
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クラスターをセットアップします。
にある設定例を実行して、セットアップを完了することができます。 examples
Rookプロジェクトのディレクトリ、または独自の構成を作成します。 構成例はほとんどのユースケースに適していて、オプションのパラメーターの優れたドキュメントを提供します。
次に、Cephクラスター KubernetesObjectの作成プロセスを開始します。
まず、YAMLファイルを作成する必要があります。
- nano cephcluster.yaml
構成は、Cephクラスターのデプロイ方法を定義します。 この例では、3つのCephモニター(MON)をデプロイし、Cephダッシュボードを有効にします。 Cephダッシュボードはこのチュートリアルの範囲外ですが、後でCephクラスターの現在のステータスを視覚化するために独自のプロジェクトで使用できます。
次のコンテンツを追加して、 apiVersion
およびKubernetesオブジェクト kind
だけでなく、 name
そしてその namespace
オブジェクトは次の場所にデプロイする必要があります。
apiVersion: ceph.rook.io/v1
kind: CephCluster
metadata:
name: rook-ceph
namespace: rook-ceph
その後、を追加します spec
キー。KubernetesがCephクラスターの作成に使用するモデルを定義します。 最初に、使用するイメージバージョンと、サポートされていないCephバージョンを許可するかどうかを定義します。
spec:
cephVersion:
image: ceph/ceph:v14.2.8
allowUnsupported: false
次に、を使用して構成ファイルを永続化するデータディレクトリを設定します。 dataDirHostPath
鍵:
dataDirHostPath: /var/lib/rook
次に、次のパラメーターを使用して、アップグレードチェックをスキップするかどうか、およびクラスターをアップグレードするタイミングを定義します。
skipUpgradeChecks: false
continueUpgradeAfterChecksEvenIfNotHealthy: false
Cephモニター(MON)の数は、 mon
鍵。 また、ノードごとに複数のMONを展開することもできます。
mon:
count: 3
allowMultiplePerNode: false
Cephダッシュボードのオプションは、 dashboard
鍵。 これにより、ダッシュボードを有効にし、ポートをカスタマイズし、リバースプロキシを使用するときにプレフィックスを付けるオプションが提供されます。
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がプリインストールされている必要があります):
monitoring:
enabled: false
rulesNamespace: rook-ceph
RDBはRADOS(Reliable Autonomic Distributed Object Store)ブロックデバイスの略で、複数のノードにデータを格納するシンプロビジョニングされたサイズ変更可能なCephブロックデバイスです。
RBDイメージは、有効にすることで2つのCephクラスター間で非同期に共有できます rbdMirroring
. このチュートリアルでは1つのクラスターを使用しているため、これは必要ありません。 したがって、労働者の数は次のように設定されます。 0
:
rbdMirroring:
workers: 0
Cephデーモンのクラッシュコレクターを有効にできます。
crashCollector:
disable: false
クリーンアップポリシーは、クラスターを削除する場合にのみ重要です。 そのため、このオプションは空のままにする必要があります。
cleanupPolicy:
deleteDataDirOnHosts: ""
removeOSDsIfOutAndSafeToRemove: false
The storage
キーを使用すると、クラスターレベルのストレージオプションを定義できます。 たとえば、使用するノードとデバイス、データベースサイズ、デバイスごとに作成するOSDの数などです。
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
アップグレードまたはフェンシング中のデーモンの中断を管理するためのキー:
disruptionManagement:
managePodBudgets: false
osdMaintenanceTimeout: 30
manageMachineDisruptionBudgets: false
machineDisruptionBudgetNamespace: openshift-machine-api
これらの構成ブロックにより、最終的に次のファイルが作成されます。
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演算子を以外の名前空間にデプロイした場合 rook-ceph
使用する名前空間に一致するように、プロビジョナーのプレフィックスを変更する必要があります。
正常に展開した後 storageclass
と cephblockpool
、アプリケーションの PersistentVolumeClaim(PVC)を定義して続行します。 PersistentVolumeClaimは、クラスターからストレージを要求するために使用されるリソースです。
そのためには、最初にYAMLファイルを作成する必要があります。
- nano pvc-rook-ceph-block.yaml
PersistentVolumeClaimに以下を追加します。
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を定義したので、次のコマンドを使用してデプロイします。
- 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データベースのデータを保持するための永続ボリューム。
- ポートでMongoDBポートを公開するサービス
31017
後で操作できるように、すべてのノードの
最初に構成ファイルを開きます。
- nano mongo.yaml
マニフェストを Deployment
資源:
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
クラスタ内のすべてのノードの:
...
---
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 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
The 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ステータスの取得などの基本的なコマンドを実行します。
ツールボックスは、 toolbox.yaml
にあるファイル examples/kubernetes/ceph
ディレクトリ:
- 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
理解を深めるために、このコマンドを分解してみましょう。
- The
kubectl exec
commandを使用すると、ポッドでコマンドを実行できます。 環境変数の設定やサービスの開始などです。 ここでは、ポッドのBASHターミナルを開くために使用します。 実行するコマンドは、コマンドの最後に定義されています。 - あなたは
-n
ポッドが実行されているKubernetes名前空間を指定するフラグ。 - The
-i
(インタラクティブ)および-t
( tty )フラグは、コマンドをインタラクティブモードで実行することをKubernetesに通知します。tty
有効。 これにより、開いたターミナルを操作できます。 $()
コマンドで式を定義できます。 つまり、式はメインコマンドの前に評価(実行)され、結果の値は引数としてメインコマンドに渡されます。 ここでは、ラベルが配置されているポッドを取得するための別のKubernetesコマンドを定義しますapp=rook-ceph-tool
を使用してポッドの名前を読み取りますjsonpath
. 次に、最初のコマンドの引数として名前を使用します。
注:すでに述べたように、このコマンドはポッド内のターミナルを開くため、プロンプトはこれを反映するように変更されます。
ポッドに接続したので、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が提供する他の種類のストレージを試すこともできます。