プロホスト > ブログ > 行政 > Ceph ベースのストレージを Kubernetes クラスターに接続する実際の例

Ceph ベースのストレージを Kubernetes クラスターに接続する実際の例

Container Storage Interface (CSI) は、Kubernetes とストレージ システム間の統合インターフェイスです。 それについてはすでに簡単に説明しました 言ったそして今日は、CSI と Ceph の組み合わせを詳しく見ていきます。 Cephストレージに接続する Kubernetes クラスターに接続します。
この記事では、理解しやすいように少し簡略化して実際の例を示します。 Ceph クラスターと Kubernetes クラスターのインストールと構成は考慮していません。

どのように機能するのか気になりますか?

Ceph ベースのストレージを Kubernetes クラスターに接続する実際の例

したがって、Kubernetes クラスターをすぐにデプロイできます。たとえば、 キューブスプレー。 近くで動作している Ceph クラスターがあります。たとえば、これを使用してインストールすることもできます。 プレイブックのセット。 言うまでもなく、それらの間の本番環境には少なくとも 10 Gbit/s の帯域幅を持つネットワークが必要です。

これをすべて持っているなら、行きましょう！

まず、Ceph クラスター ノードの XNUMX つに移動し、すべてが正常であることを確認しましょう。

ceph health
ceph -s

次に、すぐに RBD ディスクのプールを作成します。

ceph osd pool create kube 32
ceph osd pool application enable kube rbd

Kubernetes クラスターに移りましょう。 そこで、まず、RBD 用の Ceph CSI ドライバーをインストールします。 予想どおり、Helm を通じてインストールします。
チャートを含むリポジトリを追加し、ceph-csi-rbd チャートの変数セットを取得します。

helm repo add ceph-csi https://ceph.github.io/csi-charts
helm inspect values ceph-csi/ceph-csi-rbd > cephrbd.yml

ここで、cephrbd.yml ファイルに記入する必要があります。 これを行うには、Ceph でモニターのクラスター ID と IP アドレスを調べます。

ceph fsid  # так мы узнаем clusterID
ceph mon dump  # а так увидим IP-адреса мониторов

取得した値を cephrbd.yml ファイルに入力します。 同時に、PSP ポリシー (ポッド セキュリティ ポリシー) の作成を有効にします。 セクション内のオプション ノードプラグイン и プロビジョナー すでにファイル内にある場合は、以下のように修正できます。

csiConfig:
  - clusterID: "bcd0d202-fba8-4352-b25d-75c89258d5ab"
    monitors:
      - "v2:172.18.8.5:3300/0,v1:172.18.8.5:6789/0"
      - "v2:172.18.8.6:3300/0,v1:172.18.8.6:6789/0"
      - "v2:172.18.8.7:3300/0,v1:172.18.8.7:6789/0"

nodeplugin:
  podSecurityPolicy:
    enabled: true

provisioner:
  podSecurityPolicy:
    enabled: true

次に、残っているのは、Kubernetes クラスターにチャートをインストールすることだけです。

helm upgrade -i ceph-csi-rbd ceph-csi/ceph-csi-rbd -f cephrbd.yml -n ceph-csi-rbd --create-namespace

すばらしい、RBD ドライバーは機能しました。
Kubernetes で新しい StorageClass を作成しましょう。 これにも Ceph を少しいじる必要があります。

Ceph で新しいユーザーを作成し、そのユーザーにプールに書き込む権限を与えます。 久部:

ceph auth get-or-create client.rbdkube mon 'profile rbd' osd 'profile rbd pool=kube'

ここで、アクセス キーがまだ存在していることを確認してみましょう。

ceph auth get-key client.rbdkube

コマンドは次のような出力を出力します。

AQCO9NJbhYipKRAAMqZsnqqS/T8OYQX20xIa9A==

この値を Kubernetes クラスターの必要な場所の Secret に追加しましょう ユーザー・キー:

---
apiVersion: v1
kind: Secret
metadata:
  name: csi-rbd-secret
  namespace: ceph-csi-rbd
stringData:
  # Значения ключей соответствуют имени пользователя и его ключу, как указано в
  # кластере Ceph. ID юзера должен иметь доступ к пулу,
  # указанному в storage class
  userID: rbdkube
  userKey: <user-key>

そしてシークレットを作成します。

kubectl apply -f secret.yaml

次に、次のような StorageClass マニフェストが必要です。

---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
   name: csi-rbd-sc
provisioner: rbd.csi.ceph.com
parameters:
   clusterID: <cluster-id>
   pool: kube

   imageFeatures: layering

   # Эти секреты должны содержать данные для авторизации
   # в ваш пул.
   csi.storage.k8s.io/provisioner-secret-name: csi-rbd-secret
   csi.storage.k8s.io/provisioner-secret-namespace: ceph-csi-rbd
   csi.storage.k8s.io/controller-expand-secret-name: csi-rbd-secret
   csi.storage.k8s.io/controller-expand-secret-namespace: ceph-csi-rbd
   csi.storage.k8s.io/node-stage-secret-name: csi-rbd-secret
   csi.storage.k8s.io/node-stage-secret-namespace: ceph-csi-rbd

   csi.storage.k8s.io/fstype: ext4

reclaimPolicy: Delete
allowVolumeExpansion: true
mountOptions:
  - discard

記入する必要があります クラスタID、チームはすでに学習しています セフシドを作成し、このマニフェストを Kubernetes クラスターに適用します。

kubectl apply -f storageclass.yaml

クラスターがどのように連携するかを確認するために、次の PVC (Persistent Volume Claim) を作成してみましょう。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: rbd-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: csi-rbd-sc

Kubernetes が Ceph で要求されたボリュームをどのように作成したかをすぐに見てみましょう。

kubectl get pvc
kubectl get pv

すべてが素晴らしいようです！ これは Ceph 側ではどのように見えるでしょうか?
プール内のボリュームのリストを取得し、ボリュームに関する情報を表示します。

rbd ls -p kube
rbd -p kube info csi-vol-eb3d257d-8c6c-11ea-bff5-6235e7640653  # тут, конечно же, будет другой ID тома, который выдала предыдущая команда

次に、RBD ボリュームのサイズ変更がどのように機能するかを見てみましょう。
pvc.yaml マニフェストのボリューム サイズを 2Gi に変更し、適用します。

kubectl apply -f pvc.yaml

変更が有効になるのを待って、ボリューム サイズをもう一度見てみましょう。

rbd -p kube info csi-vol-eb3d257d-8c6c-11ea-bff5-6235e7640653

kubectl get pv
kubectl get pvc

PVC のサイズが変わっていないことがわかります。 その理由を調べるには、Kubernetes にクエリして PVC の YAML 記述を取得します。

kubectl get pvc rbd-pvc -o yaml

問題は次のとおりです。

メッセージ: ユーザーがポッドを (再) 起動して、ノード上のボリュームのファイル システムのサイズ変更を完了するのを待っています。 タイプ: FileSystemResizePending

つまり、ディスクは拡張されましたが、その上のファイル システムは拡張されていません。
ファイル システムを拡張するには、ボリュームをマウントする必要があります。 我が国では、作成されたPVC/PVは現在いかなる形でも使用されていません。

たとえば次のようにテスト ポッドを作成できます。

---
apiVersion: v1
kind: Pod
metadata:
  name: csi-rbd-demo-pod
spec:
  containers:
    - name: web-server
      image: nginx:1.17.6
      volumeMounts:
        - name: mypvc
          mountPath: /data
  volumes:
    - name: mypvc
      persistentVolumeClaim:
        claimName: rbd-pvc
        readOnly: false

次に、PVC を見てみましょう。

kubectl get pvc

サイズは変更されましたが、すべて問題ありません。

最初の部分では、RBD ブロック デバイス (Rados Block Device の略) を操作しましたが、異なるマイクロサービスがこのディスクを同時に操作する必要がある場合、これは実行できません。 CephFS は、ディスク イメージよりもファイルを操作するのにはるかに適しています。
Ceph および Kubernetes クラスターの例を使用して、CephFS と連携するために CSI およびその他の必要なエンティティを構成します。

必要な新しい Helm チャートから値を取得しましょう。

helm inspect values ceph-csi/ceph-csi-cephfs > cephfs.yml

もう一度、cephfs.yml ファイルに記入する必要があります。 以前と同様に、Ceph コマンドが役立ちます。

ceph fsid
ceph mon dump

ファイルに次のような値を入力します。

csiConfig:
  - clusterID: "bcd0d202-fba8-4352-b25d-75c89258d5ab"
    monitors:
      - "172.18.8.5:6789"
      - "172.18.8.6:6789"
      - "172.18.8.7:6789"

nodeplugin:
  httpMetrics:
    enabled: true
    containerPort: 8091
  podSecurityPolicy:
    enabled: true

provisioner:
  replicaCount: 1
  podSecurityPolicy:
    enabled: true

モニターのアドレスは、アドレス:ポートという単純な形式で指定されることに注意してください。 ノードに cephfs をマウントするには、これらのアドレスがカーネル モジュールに渡されますが、カーネル モジュールは v2 監視プロトコルの操作方法をまだ認識していません。
Kubespray によってインストールされる nginx-proxy と競合しないように、httpMetrics のポートを変更します (Prometheus はメトリクスを監視するためにそこに移動します)。 これは必要ないかもしれません。

Kubernetes クラスターに Helm チャートをインストールします。

helm upgrade -i ceph-csi-cephfs ceph-csi/ceph-csi-cephfs -f cephfs.yml -n ceph-csi-cephfs --create-namespace

Ceph データストアに移動して、そこに別のユーザーを作成しましょう。 ドキュメントには、CephFS プロビジョナーにはクラスター管理者のアクセス権が必要であると記載されています。 ただし、別のユーザーを作成します fs 制限付きの権利:

ceph auth get-or-create client.fs mon 'allow r' mgr 'allow rw' mds 'allow rws' osd 'allow rw pool=cephfs_data, allow rw pool=cephfs_metadata'

そして、すぐに彼のアクセス キーを見てみましょう。後で必要になります。

ceph auth get-key client.fs

Secret と StorageClass を別々に作成しましょう。
新しいものは何もありません。これは RBD の例ですでに確認済みです。

---
apiVersion: v1
kind: Secret
metadata:
  name: csi-cephfs-secret
  namespace: ceph-csi-cephfs
stringData:
  # Необходимо для динамически создаваемых томов
  adminID: fs
  adminKey: <вывод предыдущей команды>

マニフェストを適用する:

kubectl apply -f secret.yaml

そして今 - 別の StorageClass:

---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: csi-cephfs-sc
provisioner: cephfs.csi.ceph.com
parameters:
  clusterID: <cluster-id>

  # Имя файловой системы CephFS, в которой будет создан том
  fsName: cephfs

  # (необязательно) Пул Ceph, в котором будут храниться данные тома
  # pool: cephfs_data

  # (необязательно) Разделенные запятыми опции монтирования для Ceph-fuse
  # например:
  # fuseMountOptions: debug

  # (необязательно) Разделенные запятыми опции монтирования CephFS для ядра
  # См. man mount.ceph чтобы узнать список этих опций. Например:
  # kernelMountOptions: readdir_max_bytes=1048576,norbytes

  # Секреты должны содержать доступы для админа и/или юзера Ceph.
  csi.storage.k8s.io/provisioner-secret-name: csi-cephfs-secret
  csi.storage.k8s.io/provisioner-secret-namespace: ceph-csi-cephfs
  csi.storage.k8s.io/controller-expand-secret-name: csi-cephfs-secret
  csi.storage.k8s.io/controller-expand-secret-namespace: ceph-csi-cephfs
  csi.storage.k8s.io/node-stage-secret-name: csi-cephfs-secret
  csi.storage.k8s.io/node-stage-secret-namespace: ceph-csi-cephfs

  # (необязательно) Драйвер может использовать либо ceph-fuse (fuse), 
  # либо ceph kernelclient (kernel).
  # Если не указано, будет использоваться монтирование томов по умолчанию,
  # это определяется поиском ceph-fuse и mount.ceph
  # mounter: kernel
reclaimPolicy: Delete
allowVolumeExpansion: true
mountOptions:
  - debug

ここに記入しましょう クラスタID Kubernetes にも適用可能:

kubectl apply -f storageclass.yaml

Проверка

確認するには、前の例と同様に、PVC を作成しましょう。

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: csi-cephfs-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi
  storageClassName: csi-cephfs-sc

そして、PVC/PV の存在を確認します。

kubectl get pvc
kubectl get pv

CephFS 内のファイルとディレクトリを確認したい場合は、このファイル システムをどこかにマウントできます。 例えば下図のように。

Ceph クラスター ノードの XNUMX つに移動して、次のアクションを実行してみましょう。

# Точка монтирования
mkdir -p /mnt/cephfs

# Создаём файл с ключом администратора
ceph auth get-key client.admin >/etc/ceph/secret.key

# Добавляем запись в /etc/fstab
# !! Изменяем ip адрес на адрес нашего узла
echo "172.18.8.6:6789:/ /mnt/cephfs ceph name=admin,secretfile=/etc/ceph/secret.key,noatime,_netdev    0       2" >> /etc/fstab

mount /mnt/cephfs

もちろん、このように Ceph ノードに FS をマウントすることは、トレーニング目的にのみ適しています。 スラムコース。 本番環境でこれを行う人はいないと思いますが、重要なファイルを誤って消去してしまう危険性が高くなります。

最後に、CephFS の場合にボリュームのサイズ変更がどのように機能するかを確認してみましょう。 Kubernetes に戻り、PVC 用のマニフェストを編集しましょう。サイズをたとえば 7Gi に増やします。

編集したファイルを適用しましょう。

kubectl apply -f pvc.yaml

マウントされたディレクトリを見て、クォータがどのように変化したかを確認してみましょう。

getfattr -n ceph.quota.max_bytes <каталог-с-данными>

このコマンドが機能するには、システムにパッケージをインストールする必要がある場合があります。 ATTR.

目が怖くて、手がしている

これらすべての呪文と長い YAML マニフェストは、表面的には複雑に見えますが、実際には、Slurm の学生はすぐにコツを掴みます。
この記事では、ジャングルの奥深くには入りませんでした。それについては公式ドキュメントがあります。 Kubernetes クラスターを使用した Ceph ストレージのセットアップの詳細に興味がある場合は、次のリンクが役立ちます。

ボリュームを操作する Kubernetes の一般原則
RBD ドキュメント
Ceph の観点から見た RBD と Kubernetes の統合
CSI の観点から RBD と Kubernetes を統合する
CephFS の一般的なドキュメント
CSI の観点から CephFS と Kubernetes を統合する

スラームコースでは Kubernetes ベース さらに進んで、ファイルストレージとして CephFS を使用する実際のアプリケーションを Kubernetes にデプロイすることもできます。 GET/POST リクエストを通じて、Ceph との間でファイルを送受信できるようになります。

データ ストレージに興味がある場合は、サインアップしてください。 Ceph の新しいコース。 ベータテスト中は、コースを割引価格で入手でき、その内容に影響を与えることができます。

記事の著者: Alexander Shvalov、現役エンジニア サウスブリッジ, 認定 Kubernetes 管理者、Slurm コースの著者および開発者。

出所： habr.com