Rookをすぐに使い始め、クラウドネイティブのストレージオーケストレーションを始めましょう

[[415352]]

この記事はWeChatの公開アカウント「Hacker Afternoon Tea」から転載したもので、著者はShaoです。この記事を転載する場合は、Hacker Afternoon Tea公式アカウントまでご連絡ください。

Rook は、クラウドネイティブ環境とネイティブに統合するためのさまざまなストレージソリューションのプラットフォーム、フレームワーク、サポートを提供するオープンソースのクラウドネイティブストレージオーケストレーターです。

Rook は、ストレージソフトウェアを自己管理、自己スケーリング、自己修復機能を備えたストレージサービスに変換します。これは、展開、ブートストラップ、構成、プロビジョニング、スケーリング、アップグレード、移行、災害復旧、監視、およびリソース管理を自動化することによって実現されます。 Rook は、基盤となるクラウドネイティブのコンテナ管理、スケジューリング、オーケストレーションプラットフォームによって提供される機能を使用して、その機能を実行します。

Rook は拡張ポイントを活用してクラウドネイティブ環境に深く統合し、スケジュール、ライフサイクル管理、リソース管理、セキュリティ、監視、ユーザーエクスペリエンスのシームレスなエクスペリエンスを提供します。

Cassandra クイックスタート

Cassandra は、超高速のパフォーマンスと調整可能な一貫性を備えた、可用性が高く、フォールトトレラントなピアツーピアの NoSQL データベースです。単一障害点のない大規模なスケーラビリティを提供します。

Scylla は、C++ で Cassandra をハードウェアに近い形で書き直したものです。シェアードナッシングアーキテクチャを採用しており、真の線形スケーラビリティと主要なハードウェア最適化を実現し、超低レイテンシと非常に高いスループットを実現します。これは Cassandra の代替品であり、同じインターフェースを使用するため、Rook でもサポートされています。

前提条件

Rook Cassandra オペレーターを実行するには、Kubernetes クラスターが必要です。 Rook 用の Kubernetes クラスターが準備されていることを確認する (Cassandra では flexvolume プラグインは必要ありません)

Cassandraオペレーターをデプロイする

まず、次のコマンドを使用して Rook Cassandra Operator をデプロイします。

 $ git clone --single-branch --branch v1.6.8 https://github.com/rook/rook.git  
 cd rook/cluster/examples/kubernetes/cassandra
 kubectl を適用 -f 演算子.yaml

これにより、名前空間 rook-cassandra-system にオペレーターがインストールされます。オペレーターが起動して実行中であることを確認できます。

 kubectl -n rook-cassandra-system ポッドを取得します

Cassandra/Scylla クラスターの作成と初期化

オペレーターが実行されているので、clusters.cassandra.rook.io リソースのインスタンスを作成して、Cassandra/Scylla クラスターのインスタンスを作成できます。このリソースの一部の値は構成可能なので、cluster.yaml を参照して、好みに合わせて設定を調整してください。

Cassandra クラスターを作成する準備ができたら、次のコマンドを実行します。

 kubectl作成-f クラスター.yaml

次のコマンドを使用して、新しい Cassandra クラスターを表す Kubernetes オブジェクトが作成されたかどうかを確認できます。これは、Rook が Kubernetes を正常に拡張して、Cassandra クラスターを Kubernetes クラウドネイティブ環境の第一級オブジェクトにしたことを示しているため重要です。

 kubectl -n rook-cassandra で clusters.cassandra.rook.io を取得します。

必要なメンバーがすべて実行されているかどうかを確認するには、次のコマンドで、cluster.yaml に指定されたメンバー数と同じ数のエントリが表示されるはずです。

 kubectl -n rook-cassandra ポッドを取得します -l app=rook-cassandra

Cassandra クラスターのステータスをそのステータスから追跡することもできます。クラスターの現在のステータスを確認するには、次のコマンドを実行します。

 kubectl -n rook-cassandra で clusters.cassandra.rook.io rook-cassandra を記述します。

データベースへのアクセス

kubectl から:

新しいクラスターで cqlsh シェルを取得するには:

 kubectl exec -n rook-cassandra -it rook-cassandra-east-1-east-1a-0 --cqlsh  
 > キースペースの説明;

ポッド内部から:

新しいクラスターを作成すると、Rook はクライアントがクラスターにアクセスするためのサービスを自動的に作成します。サービス名は慣例に従っています-クライアント。次のコマンドを実行すると、クラスター内でこのサービスを表示できます。

 kubectl -n rook-cassandra でサービス rook-cassandra-client を記述します。

Kubernetes クラスターで実行されているポッドは、このサービスを使用して Cassandra に接続できます。以下は Python ドライバーを使用した例です。

 cassandra.clusterからClusterをインポートする
 
クラスター = Cluster([ 'rook-cassandra-client.rook-cassandra.svc.cluster.local' ])
セッション = cluster.connect ()

スケールアップ

オペレーターはラックの拡張と新しいラックの追加をサポートします。変更するには、以下を使用できます。

 kubectl で clusters.cassandra.rook.io rook-cassandra を編集します。

ラックを拡張するには、ラックの Spec.Members フィールドを目的の値に変更します。
新しいラックを追加するには、ラックリストに新しいラックを追加します。新しいラックには必ず別のラック名を選択してください。
yaml を編集して保存した後、クラスターのステータスとイベントをチェックして、何が起こっているかに関する情報を取得します。

 kubectl -n rook-cassandra で clusters.cassandra.rook.io rook-cassandra を記述します。

スケールダウン

オペレーターはラックのスケールダウンをサポートします。変更するには、以下を使用できます。

 kubectl で clusters.cassandra.rook.io rook-cassandra を編集します。

ラックを縮小するには、ラックの Spec.Members フィールドを目的の値に変更します。
yaml を編集して保存した後、クラスターのステータスとイベントをチェックして、何が起こっているかに関する情報を取得します。

 kubectl -n rook-cassandra で clusters.cassandra.rook.io rook-cassandra を記述します。

掃除

このチュートリアルに関連するすべてのリソースをクリーンアップするには、次のコマンドを実行します。

注意: これにより、データベースが破壊され、関連するすべてのデータが削除されます。

 kubectl削除-f クラスター.yaml 
 
 kubectl削除-f 演算子.yaml

トラブルシューティング

クラスターが起動しない場合は、まずオペレーターのログを確認します。

 kubectl -n rook-cassandra-system ログ -l app=rook-cassandra-operator

オペレーターログですべてが正常に見える場合は、Cassandra インスタンスの 1 つのログを確認することもできます。

 kubectl -n rook-cassandra ログ rook-cassandra-0

Cassandra モニタリング

Cassandra ラックに対して jmx_exporter を有効にするには、CassandraCluster CRD でラックに対して jmxExporterConfigMapName オプションを指定する必要があります。

例えば：

 APIバージョン: cassandra.rook.io/v1alpha1
種類: クラスター
メタデータ:
名前: my-cassandra
  名前空間: rook-cassandra
仕様:
  ...
  データセンター:
名前: my-datacenter
    ラック:
    -名前: my-rack
      メンバー: 3
      jmxExporterConfigMapName: jmx-exporter-settings
      ストレージ：
        ボリュームクレームテンプレート:
        - メタデータ:
名前: rook-cassandra-data
          仕様:
            ストレージクラス名: 私のストレージクラス
            リソース：
              リクエスト:
                ストレージ: 200Gi

すべてのメトリックを取得するための簡単な構成マップの例:

 APIバージョン: v1
種類: ConfigMap
メタデータ:
名前: jmx-exporter-settings
  名前空間: rook-cassandra
データ：
  jmx_exporter_config.yaml: |
    小文字出力ラベル名: true  
    小文字出力名: true  
    ホワイトリストオブジェクト名: [ "org.apache.cassandra.metrics:*" ]

ConfigMap のデータフィールドには、jmx エクスポーター設定を含む jmx_exporter_config.yaml キーが含まれている必要があります。

構成マップが更新されても、Pod の自動リロードメカニズムは存在しません。 configmap を変更した後は、すべてのラックポッドを手動で再起動する必要があります。

 NAMESPACE=<名前空間>
 CLUSTER=<クラスター名>
ラック = $(kubectl get sts -n ${NAMESPACE} -l "cassandra.rook.io/cluster=${CLUSTER}" )
 ${RAKS} をエコーします | xargs -n1 kubectl ロールアウト 再起動 -n ${NAMESPACE}

Ceph ストレージクイックスタート

このガイドでは、Ceph クラスターの基本的なセットアップについて説明し、クラスター内で実行されている他のポッドからブロック、オブジェクト、およびファイルストレージを使用できるようにします。

最小バージョン

Rook は Kubernetes v1.11 以降をサポートしています。

重要: K8s 1.15 以前を使用している場合は、Rook CRD の別のバージョンを作成する必要があります。サンプルマニフェストの pre-k8s-1.16 サブフォルダーにある crds.yaml を作成します。

前提条件

Rook で使用できる Kubernetes クラスターがあることを確認します。

Ceph ストレージクラスターを構成するには、次のローカルストレージオプションの少なくとも 1 つが必要です。

RAWデバイス（パーティションやフォーマットされたファイルシステムがない）
- これには、ホストに lvm2 がインストールされている必要があります。この依存関係を回避するには、ディスク上に完全なディスクパーティションを作成します（以下を参照）。
未フォーマットのパーティション（フォーマットされたファイルシステムなし）
ブロックモードストレージクラスで利用可能な永続ボリューム

次のコマンドを使用して、パーティションまたはデバイスがファイルシステムでフォーマットされているかどうかを確認できます。

 lsblk -f

名前FSTYPE ラベル UUID マウントポイント
ビデオ
└─vda1 LVM2_メンバー >eSO50t-GkUV-YKTH-WsGq-hNJY-eKNf-3i07IB
 ├─ubuntu --vg-root ext4 c2366f76-6e21-4f10-a8f3-6776212e2fe4 /  
 └─ubuntu --vg-swap_1 スワップ 9492a3dc-ad75-47cd-9596-678e8cf17ff9 [スワップ]  
仮想データベース

FSTYPE フィールドが空でない場合、対応するデバイスの上にファイルシステムが存在します。この場合、Ceph で vdb を使用できますが、vda とそのパーティションは使用できません。

要約

運が良ければ、次の kubectl コマンドとサンプル yaml ファイルを使用して、シンプルな Rook クラスターを作成できます。

 $ git clone --single-branch --branch v1.6.8 https://github.com/rook/rook.git  
 cd rook/cluster/examples/kubernetes/ceph
 kubectl create -f crds.yaml -f common.yaml -f operator.yaml
 kubectl作成-f クラスター.yaml

クラスター環境

Rook のドキュメントは、実稼働環境で Rook を起動することに重点を置いています。テスト環境の一部の設定を緩和するための例もいくつか提供されています。このガイドの後半でクラスターを作成するときは、次のクラスターマニフェストの例を検討してください。

cluster.yaml: ベアメタル上で実行されている本番クラスターのクラスター設定。少なくとも 3 つのワーカーノードが必要です。
cluster-on-pvc.yaml: 動的クラウド環境で実行される本番クラスターのクラスター設定。
cluster-test.yaml: minikube などのテスト環境のクラスター設定。

Rookオペレーターを展開する

最初のステップは、Rook オペレーターを展開することです。使用している Rook のバージョンに対応するサンプル yaml ファイルを使用していることを確認します。

クラスター/examples/kubernetes/ceph を CD します。
 kubectl create -f crds.yaml -f common.yaml -f operator.yaml 
 
 # rook-ceph-operatorが 続行する前に「実行中」状態にする
kubectl -n rook-ceph ポッドを取得する

Operator を本番環境で起動する前に、いくつかの設定を検討することをお勧めします。

kubernetes v1.15 以前を使用している場合は、/cluster/examples/kubernetes/ceph/pre-k8s-1.16/crd.yaml に CRD を作成する必要があります。 CustomResourceDefinition の apiextension v1beta1 バージョンは、Kubernetes v1.16 では非推奨になりました。
デフォルトで無効になっている特定の Rook 機能を有効にするかどうかを検討します。これらおよびその他の高度な設定については、operator.yaml を参照してください。

デバイスの検出: ROOK_ENABLE_DISCOVERY_DAEMON 設定が有効になっている場合、Rook は、ベアメタルクラスターで一般的に使用される、構成される新しいデバイスを監視します。
Flex ドライバー: Flex ドライバーは CSI ドライバーに置き換えられて非推奨になりましたが、ROOK_ENABLE_FLEX_DRIVER 設定によって引き続き有効にすることができます。
ノードのアフィニティと許容範囲: デフォルトでは、CSI ドライバーはクラスター内の任意のノードで実行されます。 CSI ドライバーのアフィニティを構成するには、さまざまな設定を使用できます。

Rook Ceph クラスターを作成する

Rook オペレーターが実行されているので、Ceph クラスターを作成できます。クラスターが再起動後も存続できるようにするには、dataDirHostPath プロパティがホストに対して有効になるように設定してください。

クラスターを作成します。

 kubectl作成-f クラスター.yaml

kubectl を使用して、rook-ceph 名前空間内のポッドを一覧表示します。すべて実行されると、次のポッドが表示されるはずです。 osd ポッドの数は、クラスター内のノードの数と構成されているデバイスの数によって異なります。上記の cluster.yaml を変更しない場合は、ノードごとに 1 つの OSD が作成されると考えられます。 CSI、rook-ceph-agent (flex ドライバー)、rook-discover ポッドも、設定に応じてオプションになります。

 kubectl -n rook-ceph ポッドを取得する

名前準備完了 ステータス 再起動 年齢
csi-cephfsplugin-provisioner-d77bb49c6-n5tgs 5/5 実行中 0 140 秒
csi-cephfsplugin-provisioner-d77bb49c6-v9rvn 5/5 実行中 0 140 秒
csi-cephfsplugin-rthrp 3/3 実行中 0 140秒
csi-rbdplugin-hbsm7 3/3 実行中 0 140秒
csi-rbdplugin-provisioner-5b5cd64fd-nvk6c 6/6 実行中 0 140 秒
csi-rbdplugin-provisioner-5b5cd64fd-q7bxl 6/6 実行中 0 140 秒
rook-ceph-crashcollector-minikube-5b57b7c5d4-hfldl 1/1 実行中 0 105 秒
rook-ceph-mgr-a-64cd7cdf54-j8b5p 1/1 実行中 0 77秒
rook-ceph-mon-a-694bb7987d-fp9w7 1/1 実行中 0 105秒
rook-ceph-mon-b-856fdd5cb9-5h2qk 1/1 実行中 0 94秒
rook-ceph-mon-c-57545897fc-j576h 1/1 実行中 0 85秒
rook-ceph-operator-85f5b946bd-s8grz 1/1 実行中 0 92分
rook-ceph-osd-0-6bb747b6c5-lnvb6 1/1 実行中 0 23秒
rook-ceph-osd-1-7f67f9646d-44p7v 1/1 実行中 0 24秒
rook-ceph-osd-2-6cd4b776ff-v4d68 1/1 実行中 0 25秒
rook-ceph-osd- prepare -node1-vx2rz 0/2 完了 0 60秒
rook-ceph-osd- prepare -node2-ab3fd 0/2 完了 0 60秒
rook-ceph-osd- prepare -node3-w4xyz 0/2 完了 0 60秒

クラスターが正常であることを確認するには、Rook ツールボックスに接続し、ceph status コマンドを実行します。

すべてのモンスが定足数に出席する必要がある
mgr はアクティブである必要があります
少なくとも1つのOSDがアクティブです
ヘルスがHEALTH_OKでない場合は、警告またはエラーを調査する必要があります。

セファロステータス

クラスタ：
  識別子: a0452c76-30d9-4c1a-a948-5d8405f19a7c
  健康状態: HEALTH_OK 
 
サービス:
  mon: 3 つのデーモン、定足数 a、b、c (年齢 3 メートル)
  mgr: a (アクティブ、2分前から)
  osds: 3 osds: 3 アップ (1 分以降)、3イン(1 分以降)
 ..

ストレージ

Rook によって公開される 3 つのストレージタイプの詳細については、次のガイドを参照してください。

ブロック: ポッドが使用するブロックストレージを作成します
オブジェクト: Kubernetes クラスターの内外からアクセスできるオブジェクトストレージを作成します。
共有ファイルシステム: 複数のポッド間で共有するファイルシステムを作成する

Cephダッシュボード

Ceph には、クラスターのステータスを表示できるダッシュボードがあります。

道具

Rook クラスターのデバッグとトラブルシューティング用の Ceph クライアントのフルセットを含むツールボックスコンテナーを作成しました。

モニター

各 Rook クラスターには、Prometheus で監視するためのメトリックコレクター/エクスポーターがいくつか組み込まれています。

破壊する

クラスターのテストが完了したら、次の手順に従ってクラスターをクリーンアップしてください。

ネットワークファイルシステム (NFS)

NFS を使用すると、リモートホストはネットワーク経由でファイルシステムをマウントし、ローカルにマウントされているかのようにそれらのファイルシステムと対話できます。これにより、システム管理者はネットワーク上の中央サーバーにリソースを統合できるようになります。

前提条件
Rook NFS オペレーターを実行するには、Kubernetes クラスターが必要です。

ボリュームを公開するには、PVC 経由で NFS サーバーポッドに接続する必要があります。

ホストパス、AWS Elastic Block Store、GCP Persistent Disk、CephFS、Ceph RBD など、あらゆるタイプの PVC に接続およびエクスポートできます。これらのボリュームの制限は、NFS 経由で共有される場合にも適用されます。これらのボリュームの詳細と制限については、Kubernetes のドキュメントで詳しく知ることができます。 3. NFS をマウントするポッドを実行する可能性のあるすべての Kubernetes ノードに NFS クライアントパッケージをインストールする必要があります。 CentOS ノードに nfs-utils をインストールするか、Ubuntu ノードに nfs-common をインストールします。

NFSオペレーターの導入

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

 $ git clone --single-branch --branch v1.6.8 https://github.com/rook/rook.git  
 cd rook/cluster/examples/kubernetes/nfs
 kubectl作成-f common.yaml
 kubectl作成-f 演算子.yaml

オペレーターが起動して実行中であることを確認できます。

 kubectl -n rook-nfs-system ポッドを取得する

名前準備完了ステータス再起動年齢

名前準備完了 ステータス 再起動 年齢
rook-nfs-operator-879f5bf8b-gnwht 1/1 実行中 0 29m

NFS Admission Webhook をデプロイする (オプション)

アドミッション Webhook は、API サーバーへのアドミッション要求を受信する HTTP コールバックです。アドミッション Webhook には、検証アドミッション Webhook と変更アドミッション Webhook の 2 種類があります。 NFS Operator は、API サーバーに送信された NFSServer オブジェクトを etcd (永続性) に保存する前に検証する検証アドミッション Webhook をサポートしています。

NFS でアドミッション Webhook を有効にするには (たとえば、アドミッション Webhook を検証する)、次の手順を実行する必要があります。

まず、cert-manager がインストールされていることを確認します。まだインストールされていない場合は、cert-manager インストールドキュメントの手順に従ってインストールできます。あるいは、次の単一のコマンドを実行することもできます。

 kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v0.15.1/cert-manager.yaml

これにより、cert-manager の最新バージョン (v0.15.1) が簡単にインストールされます。完了したら、cert-manager コンポーネントが正しくデプロイされ、実行状態になっていることを確認します。

 kubectl get -n cert-manager ポッド

名前準備完了 ステータス 再起動 年齢
cert-manager-7747db9d88-jmw2f 1/1 実行中 0 2分1秒
cert-manager-cainjector-87c85c6ff-dhtl8 1/1 実行中 0 2分1秒
cert-manager-webhook-64dc9fff44-5g565 1/1 実行中 0 2分1秒

cert-manager が実行されると、NFS Webhook をデプロイできるようになります。

 kubectl作成-f webhook.yaml

Webhook が稼働していることを確認します。

 kubectl -n rook-nfs-system ポッドを取得する

名前準備完了 ステータス 再起動 年齢
rook-nfs-operator-78d86bf969-k7lqp 1/1 実行中 0 102秒
rook-nfs-webhook-74749cbd46-6jw2w 1/1 実行中 0 102秒

OpenShift セキュリティコンテキスト制約を作成する (オプション)

OpenShift クラスターでは、追加のセキュリティコンテキスト制約をいくつか作成する必要があります。 OpenShift で実行していない場合は、このセクションをスキップして次のセクションに進むことができます。

nfs-server ポッドのセキュリティコンテキスト制約を作成するには、次の yaml を使用できます。これは、/cluster/examples/kubernetes/nfs の下の scc.yaml にもあります。

注意: OpenShift の古いバージョンでは apiVersion: v1 が必要になる場合があります

種類: SecurityContextConstraints
 APIバージョン: security.openshift.io/v1
メタデータ:
名前: rook-nfs
ホストディレクトリボリュームプラグインを許可: true  
ホストIPCを許可:無効 
 allowHostNetwork:偽 
許可ホストPID: false  
 allowHostPorts:偽 
特権コンテナを許可: false  
許可される機能:
 -SYS_ADMIN
 - DAC_READ_SEARCH
デフォルトの追加機能: null  
グループ:
  タイプ: MustRunAs
優先度: null  
 readOnlyRootFilesystem: false  
必要なドロップ機能:
 -殺す
-MKNOD
 -SYS_CHROOT
実行ユーザー:
  タイプ: RunAsAny
 seLinuxコンテキスト:
  タイプ: MustRunAs
補足グループ:
  タイプ: RunAsAny
ボリューム:
 -configマップ
- 下向きAPI
 -空のディレクトリ
-永続ボリュームクレーム
- 秘密
ユーザー:
  - システム:サービスアカウント:rook-nfs:rook-nfs-server

次のコマンドで scc を作成できます。

 oc作成-f scc.yaml

ポッドセキュリティポリシーを作成する (推奨)

ポッドセキュリティポリシーも作成することをお勧めします

APIバージョン: ポリシー/v1beta1
種類: PodSecurityPolicy
メタデータ:
名前: rook-nfs-policy
仕様:
  特権: true  
  グループ:
ルール: RunAsAny
  許可される機能:
  - DAC_READ_SEARCH
  -SYS_リソース
  実行ユーザー:
ルール: RunAsAny
  カーネル:
ルール: RunAsAny
  補足グループ:
ルール: RunAsAny
  ボリューム:
  -configマップ
  - 下向きAPI
  -空のディレクトリ
  -永続ボリュームクレーム
  - 秘密
  -ホストパス

このファイルを psp.yaml という名前で保存し、次のコマンドで作成します。

 kubectl作成-f psp.yaml

NFS サーバーの作成と初期化

オペレーターが実行されているので、nfsservers.nfs.rook.io リソースのインスタンスを作成して、NFS サーバーのインスタンスを作成できます。 NFS サーバーリソースのさまざまなフィールドとオプションを使用して、サーバーとそのボリュームをエクスポート用に構成できます。

NFSサーバーを作成する前に、ServiceAccountとRBACルールを作成する必要があります。

 ---  
 APIバージョン: v1
種類: 名前空間
メタデータ:
名前: rook-nfs
 ---  
 APIバージョン: v1
種類: サービスアカウント
メタデータ:
名前: rook-nfs-server
  名前空間: rook-nfs
 ---  
種類: ClusterRole
 apiバージョン: rbac。認証.k8s.io/v1
メタデータ:
名前: rook-nfs-provisioner-runner
ルール:
  -apiグループ: [ "" ]
    リソース: [ "persistentvolumes" ]
    動詞: [ 「取得」 、 「一覧表示」 、 「監視」 、 「作成」 、 「削除」 ]
  -apiグループ: [ "" ]
    リソース: [ "persistentvolumeclaims" ]
    動詞: [ "get" 、 "list" 、 "watch" 、 "update" ]
  - apiグループ: [ "storage.k8s.io" ]
    リソース: [ "ストレージクラス" ]
    動詞: [ 「取得する」 、 「一覧表示する」 、 「見る」 ]
  -apiグループ: [ "" ]
    リソース: [ "イベント" ]
    動詞: [ 「作成」 、 「更新」 、 「パッチ」 ]
  -apiグループ: [ "" ]
    リソース: [ "サービス" 、 "エンドポイント" ]
    動詞: [ "得る" ]
  -apiGroups: [ "ポリシー" ]
    リソース: [ "podsecuritypolicies" ]
    リソース名: [ "rook-nfs-policy" ]
    動詞: [ "使用する" ]
  -apiグループ: [ "" ]
    リソース: [ "エンドポイント" ]
    動詞: [ "get" 、 "list" 、 "watch" 、 "create" 、 "update" 、 "patch" ]
  -apiグループ:
    翻訳元
    リソース：
    - 「*」  
    動詞:
    - 「*」  
 ---  
種類: ClusterRoleBinding
 apiバージョン: rbac。認証.k8s.io/v1
メタデータ:
名前: rook-nfs-provisioner-runner
科目:
  - 種類: サービスアカウント
名前: rook-nfs-server
     ＃交換する プロビジョナーがデプロイされている名前空間
    名前空間: rook-nfs
ロールリファレンス:
  種類: ClusterRole
名前: rook-nfs-provisioner-runner
  apiGroup : rbac.authorization.k8s.io

このファイルを rbac.yaml という名前で保存し、次のコマンドを使用して作成します。

 kubectl作成-f rbac.yaml

このガイドには、NFS サーバーを使用してボリュームをエクスポートする主な例が 3 つあります。

デフォルトのストレージクラスの例
XFS ストレージクラスの例
Rook Ceph ボリュームの例

デフォルトのストレージクラスの例

最初の例では、実行している環境のデフォルトの StorageClass によってサポートされるストレージをエクスポートする NFS サーバーインスタンスを作成する手順を説明します。環境によっては、これがホストパスになる場合もあれば、クラウドプロバイダーの仮想ディスクになる場合もあります。いずれにしても、この例ではデフォルトの StorageClass が存在している必要があります。

まず、次の NFS CRD インスタンス定義を nfs.yaml という名前のファイルに保存します。

 ---  
 #デフォルトのストレージクラスが存在する必要があります
APIバージョン: v1
種類: PersistentVolumeClaim
メタデータ:
名前: nfs-デフォルト-クレーム
  名前空間: rook-nfs
仕様:
  アクセスモード:
  -読み書き多数
  リソース：
    リクエスト:
      ストレージ: 1Gi
 ---  
 APIバージョン: nfs.rook.io/v1alpha1
種類: NFSサーバー
メタデータ:
名前: rook-nfs
  名前空間: rook-nfs
仕様:
  レプリカ: 1
  輸出:
  -名前: シェア1
    サーバ：
      アクセスモード: 読み取り書き込み
      スカッシュ： 「なし」  
    # NFS CRD インスタンスを作成する前に、永続ボリューム要求を作成する必要があります。
    永続ボリュームクレーム:
      クレーム名: nfs-デフォルト-クレーム
  #注釈のキー/値リスト
  注釈:
    ルーク: nfs

nfs.yaml ファイルを保存したら、次のように NFS サーバーを作成します。

 kubectl作成-f nfs.yaml

XFS ストレージクラスの例

Rook NFS は xfs_quota を介してディスククォータをサポートします。したがって、ボリュームのディスククォータを指定する必要がある場合は、次の例に従ってください。

この例では、prjquota オプションを使用して xfs としてマウントされた基礎ボリュームを使用します。基礎となるボリュームを作成する前に、xfs ファイルシステムと prjquota mountOptions を使用して StorageClass を作成する必要があります。 Kubernetes の多くの分散ストレージプロバイダーは xfs ファイルシステムをサポートしています。通常、storageClass パラメータの fsType: xfs または fs: xfs によって定義されます。ただし、ストレージクラスのファイルシステムタイプを実際に指定する方法は、そのストレージプロバイダーによって異なります。詳細については、https://kubernetes.io/docs/concepts/storage/storage-classes/ を参照してください。

GCE PDとAWS EBSのStorageClassの例を以下に示します。

GCE PD

 APIバージョン: storage.k8s.io/v1
種類: ストレージクラス
メタデータ:
名前: 標準-xfs
パラメータ:
  タイプ: pd-標準
  ファイルタイプ: xfs
マウントオプション:
  -prjquota
プロビジョナー: kubernetes.io/gce-pd
回収ポリシー:削除 
ボリュームバインディングモード: 即時
ボリューム拡張を許可する: true

AWS の EBS

 APIバージョン: storage.k8s.io/v1
種類: ストレージクラス
メタデータ:
名前: 標準-xfs
プロビジョナー: kubernetes.io/aws-ebs
パラメータ:
  タイプ: io1
  iops/GB: "10"  
  ファイルタイプ: xfs
マウントオプション:
  -prjquota
回収ポリシー:削除 
ボリュームバインディングモード: 即時

xfs ファイルシステムと prjquota mountOptions を持つ StorageClass を作成したら、次の例を使用して NFS サーバーインスタンスを作成できます。

 ---  
 # ストレージクラス 名前standard-xfs が存在する必要があります。
 # ストレージ クラスには、xfs ファイルシステム タイプとprjquota マウント オプションが必要です。
 APIバージョン: v1
種類: PersistentVolumeClaim
メタデータ:
名前: nfs-xfs-claim
  名前空間: rook-nfs
仕様:
  ストレージクラス名: "standard-xfs"  
  アクセスモード:
  -一度だけ読み書き可能
  リソース：
    リクエスト:
      ストレージ: 1Gi
 ---  
 APIバージョン: nfs.rook.io/v1alpha1
種類: NFSサーバー
メタデータ:
名前: rook-nfs
  名前空間: rook-nfs
仕様:
  レプリカ: 1
  輸出:
  -名前: シェア1
    サーバ：
      アクセスモード: 読み取り書き込み
      スカッシュ： 「なし」  
    # NFS CRD インスタンスを作成する前に、永続ボリューム要求を作成する必要があります。
    永続ボリュームクレーム:
      クレーム名: nfs-xfs-claim
  #注釈のキー/値リスト
  注釈:
    ルーク: nfs

この PVC および NFS サーバーインスタンスを nfs-xfs.yaml として保存し、次のコマンドを使用して作成します。

 kubectl作成-f nfs-xfs.yaml

Rook Ceph ボリュームの例

この代替例では、NFS サーバーのエクスポートとして別の基礎ボリュームを使用します。これらの手順では、クライアントがネットワーク経由でアクセスできるように Ceph RBD ブロックボリュームをエクスポートする方法について説明します。

Rook Ceph クラスターが起動したら、NFS サーバーの作成に進むことができます。

この PVC および NFS サーバーインスタンスを nfs-ceph.yaml として保存します。

 ---  
 # rook ceph クラスターが実行中である必要があります
# rook/cluster/examples/kubernetes/cephの例を使用して rook ceph クラスターを作成します
#簡単なrookクラスターのセットアップについては、 https://rook.io/docs/rook/master/ceph-quickstart.htmlを参照してください。
 APIバージョン: v1
種類: PersistentVolumeClaim
メタデータ:
名前: nfs-ceph-claim
  名前空間: rook-nfs
仕様:
  ストレージクラス名: rook-ceph-block
  アクセスモード:
  -読み書き多数
  リソース：
    リクエスト:
      ストレージ: 2Gi
 ---  
 APIバージョン: nfs.rook.io/v1alpha1
種類: NFSサーバー
メタデータ:
名前: rook-nfs
  名前空間: rook-nfs
仕様:
  レプリカ: 1
  輸出:
  -名前: シェア1
    サーバ：
      アクセスモード: 読み取り書き込み
      スカッシュ： 「なし」  
    # NFS CRD インスタンスを作成する前に、永続ボリューム要求を作成する必要があります。
    #この例を使用するためにCeph クラスターを作成します
    # ceph-pvc.yaml を使用して rook ceph クラスターを作成した後、 ceph PVCを作成します。
    永続ボリュームクレーム:
      クレーム名: nfs-ceph-claim
  #注釈のキー/値リスト
  注釈:
    ルーク: nfs

nfs-ceph.yaml に保存した NFS サーバーインスタンスを作成します。

 kubectl作成-f nfs-ceph.yaml

NFSサーバーの検証

次のコマンドを使用して、新しい NFS サーバーとそのエクスポートを表す Kubernetes オブジェクトが作成されたかどうかを確認できます。

 kubectl -n rook-nfs で nfsservers.nfs.rook.io を取得します。

名前年齢 州
rook-nfs 32s 実行中

NFS サーバーポッドが起動して実行されていることを確認します。

 kubectl -n rook-nfs ポッドを取得します -l app=rook-nfs

名前準備完了 ステータス 再起動 年齢
rook-nfs-0 1/1 ランニング 0 2m

NFS サーバーポッドが実行状態の場合、公開された NFS 共有が正常に作成され、クライアントはネットワーク経由でアクセスを開始できます。

エクスポートを訪問

Rook バージョン v1.0 以降、Rook は NFS の動的プロビジョニングをサポートします。この例では、nfs で動的構成機能を使用する方法を示します。

NFS Operator および NFSServer インスタンスをデプロイした後。ボリュームを動的にプロビジョニングするには、次の例のようなストレージクラスを作成する必要があります。

 APIバージョン: storage.k8s.io/v1
種類: ストレージクラス
メタデータ:
  ラベル:
    アプリ: rook-nfs
名前: rook-nfs-share1
パラメータ:
  エクスポート名: share1
  nfsサーバー名: rook-nfs
  nfsServer名前空間: rook-nfs
プロビジョナー: nfs.rook.io/rook-nfs-provisioner
回収ポリシー:削除 
ボリュームバインディングモード: 即時

これを sc.yaml などのファイルとして保存し、次のコマンドを使用してストレージクラスを作成できます。

 kubectl作成-f sc.yaml

注: StorageClass は次の 3 つのパラメータを渡す必要があります。

exportName: ボリュームのプロビジョニングに使用するエクスポートをプロビジョナーに指示します。
nfsServerName: NFSServer インスタンスの名前です。
nfsServerNamespace: NFSServer インスタンスが実行される名前空間。

上記のストレージクラスを作成した後、次の例に示すように、ストレージクラスを参照する PV クレームを作成できます。

 APIバージョン: v1
種類: PersistentVolumeClaim
メタデータ:
名前: rook-nfs-pv-claim
仕様:
  ストレージクラス名: "rook-nfs-share1"  
  アクセスモード:
    -読み書き多数
  リソース：
    リクエスト:
      ストレージ: 1Mi

また、たとえば pvc.yaml という名前のファイルとして保存し、次のコマンドを使用して PV クレームを作成することもできます。

 kubectl作成-f pvc.yaml

消費輸出

これで、上記の PersistentVolumeClaim クレームを使用してエクスポートされたボリュームを使用するサンプル Web サーバーアプリを作成することで、作成した PV を使用できるようになります。この例を構成するポッドは 2 つあります。

NFS共有の内容を読み取り、表示するWebサーバーポッド

ウェブサイトが常に更新されるように、NFS共有にランダムデータを書き込むライターポッド

cluster/examples/kubernetes/nfs フォルダから busybox ポッド (ライター) と Web サーバーを起動します。

 kubectl create -f busybox-rc.yaml
 kubectl作成-f web-rc.yaml

期待される busybox ライターポッドと Web サーバーポッドの両方が起動して実行されていることを確認しましょう。

 kubectl get pod -l app=nfs-demo

Web サーバーをネットワーク経由でアクセスできるようにするには、そのためのサービスを作成しましょう。

 kubectl作成-f web-service.yaml

次に、先ほど起動した busybox ライターポッドを使用して、nginx がデータを正しく提供していることを確認できます。次の 1 行コードでは、kubectl exec を使用して、busybox ライターポッドで wget を使用して Web サーバーポッドによってホストされている Web ページを取得するコマンドを実行します。 busybox ライターポッドが新しいタイムスタンプを書き込み続けると、返される出力も約 10 秒ごとに更新されることがわかります。

 $ エコー; kubectl exec $(kubectl get pod -l app=nfs-demo,role=busybox -o jsonpath= '{.items[0].metadata.name}' ) -- wget -qO- http://$(kubectl get services nfs-web -o jsonpath='{.spec.clusterIP}');エコー

 2015年10月22日木曜日 19:28:55 UTC
 nfs-ビジーボックス-w3s4t

掃除して破壊する

このチュートリアルに関連するすべてのリソースをクリーンアップするには、次のコマンドを実行します。

 kubectl削除-f web-service.yaml
 kubectl削除-f web-rc.yaml
 kubectl削除-f busybox-rc.yaml
 kubectl削除-f pvc.yaml
 kubectl削除-f pv.yaml
 kubectl削除-f nfs.yaml
 kubectl削除-f nfs-xfs.yaml
 kubectl削除-f nfs-ceph.yaml
 kubectl削除-f rbac.yaml
 kubectl削除-f psp.yaml
 kubectl delete -f scc.yaml # デプロイされている場合
kubectl削除-f 演算子.yaml
 kubectl delete -f webhook.yaml # デプロイされている場合
kubectl削除-f common.yaml

トラブルシューティング

NFS サーバーポッドが表示されない場合、最初の手順は NFS オペレーターログを確認することです。

 kubectl -n rook-nfs-system ログ -l app=rook-nfs-operator

<<: ノーコードプラットフォームがSaaSを介してスタートアップの成長を促進する方法

>>: レポート: 2021 年第 2 四半期のクラウド市場の総支出は 400 億ドルを超える

Cassandra クイックスタート

前提条件

Cassandra/Scylla クラスターの作成と初期化

スケールアップ

スケールダウン

掃除

トラブルシューティング

Cassandra モニタリング

Ceph ストレージ クイックスタート

最小バージョン

前提条件

要約

クラスター環境

Rookオペレーターを展開する

Rook Ceph クラスターを作成する

ストレージ

Cephダッシュボード

道具

モニター

破壊する

ネットワーク ファイル システム (NFS)

NFSオペレーターの導入

NFS Admission Webhook をデプロイする (オプション)

NFS サーバーの作成と初期化

デフォルトのストレージクラスの例

XFS ストレージクラスの例

Rook Ceph ボリュームの例

NFSサーバーの検証

エクスポートを訪問

消費 輸出

掃除して破壊する

トラブルシューティング

推薦する

Ceph ストレージクイックスタート

ネットワークファイルシステム (NFS)

消費輸出