Rookの基礎・バージョンアップ

Rook 基礎・バージョンアップ
@rev4t
Takashi Sogabe
2020年03月27日

今回お話しすること
•Rookの基本的な使い方
•Ceph の利用を想定
•バージョンアップ方法
•Rook Operator
•Ceph

発表者紹介
•Takashi Sogabe
• @rev4t
•OpenStack や Ceph の運用をやっています
•発表内容の元ネタ
• https://bit.ly/2QPeNPf

k8s で Storage を使うときの課題
•外部ストレージが必要
•EBS等の、クラウドサービスを使う
• k8s node 障害時、 failover に時間を要する
•自前でアプライアンスを用意する
• ストレージシステムを別途運用するコストが大きい
•ベンダ・ロックイン
• ブラックボックスが相手だと、何かあっても自分たちで解決
することはできない

Rook で解決できること
•k8s 上で Storage Operation を実現
•Day1, Day2 Operation の自動化
• Bootstrap
• Deploy
• Configure
• Upgrade
•Storage Provisioning
• PVC

Rook とは?
•Open Source (Apache 2.0)
•CNCF のプロジェクト
•Operator + Custom Resource にて k8s の機能を拡張
•沢山の Storage システムに対応したフレームワーク

Storage Providers
Project Status
Ceph Stable
EdgeFS Stable
CockroachDB Alpha
Cassandra Alpha
NFS Alpha
YugabyteDB Alpha
Minio Alpha
2020年3月現在 (Rook v1.3)

Rook Architecture
•Rook Operator
•人間のオペレータに代わって、Ceph 等のデータを
持った分散システムのデプロイ・管理を実施する
•Rook Discover
•ストレージノード (k8s worker node)で動作し、ス
トレージを自動検出する

Rook Version Up
•Version Up の対象は、2つあります
•Rook
•Ex) rook v1.1 -> v1.2
•Storage Backend
• Ex) Ceph 14.0.4 -> 14.0.5

Version Up Strategy (1)
• Rook Control Plane
• Release Note 等を確認した上で、修正するべき不具合等があれば、
Version Up を実施します
• Major Version Up
• ドキュメントに従い Version Up すれば、大きな問題はおこらないはずですが、
必ず事前検証をしておきましょう
• Version Up 中、一時的にストレージが利用できない状態になるのでご注意
ください
• ceph-mon, ceph-osd の container restart が発生します
• Minor Version Up
• Minor version up (v1.2.x -> v1.2.y) であれば、ceph-mon /ceph-osd の
container restart が発生しないパターンもあるため、影響は軽微になります

Version Up Strategy (2)
•Ceph
•事前テスト等を実施した上で本番環境に Roll Out
しましょう
•過去に、最新版 Ceph に Version Up することでサー
ビス影響が出そうな不具合がしばしば発生しています
•ceph-mon, ceph-osd の再起動が one-by-one で実
施されるため、I/O の一時的な性能低下・遅延が発
生します
• 一時的なパフォーマンス低下に耐えられる時間帯等で実
施しましょう

Version Up: Rook Control Plane
•Rook の公式ドキュメントに従って作業を実施
します
• https://rook.io/docs/rook/v1.2/ceph-upgrade.html
• 公式リリースバージョンの使用が前提です
• master ブランチからの Version Up については unsupported になります

Rook Version Up (v1.1 -> v1.2)

Step 0-1: Ceph Health Verification
export ROOK_NAMESPACE=rook-ceph
kubectl -n $ROOK_NAMESPACE get pods
TOOLS_POD=$(kubectl -n $ROOK_NAMESPACE get pod -l "app=rook-ceph-tools" -o
jsonpath='{.items[0].metadata.name}')
kubectl -n $ROOK_NAMESPACE exec -it $TOOLS_POD -- ceph status
• Version Up 前に、Ceph がクラスタとして正常に稼働していることを確
認しておきます

Step 0-2: Ceph Health Verification
kubectl -n $ROOK_NAMESPACE exec -it $TOOLS_POD -- ceph status
cluster:
id: 3cce2f74-a60c-4420-b88e-61b2b3f143ae
health: HEALTH_OK
services:
mon: 3 daemons, quorum a,b,c (age 43m)
mgr: a(active, since 42m)
osd: 9 osds: 9 up (since 39m), 9 in (since 39m)
data:
pools: 1 pools, 128 pgs
objects: 14 objects, 7.0 MiB
usage: 9.0 GiB used, 162 GiB / 171 GiB avail
pgs: 19.531% pgs unknown
3.906% pgs not active
98 active+clean
25 unknown
5 peering

Step 0-3: k8s Health Verification
POD_NAME=$(kubectl -n $ROOK_NAMESPACE get pod -o custom-columns=name:.metadata.name --no-
headers | grep rook-ceph-mon-b)
# Container の version を確認
kubectl -n $ROOK_NAMESPACE get pod ${POD_NAME} -o jsonpath='{.spec.containers[0].image}‘
ceph/ceph:v14.2.4-20190917
kubectl -n $ROOK_NAMESPACE get deployments -o jsonpath='{range .items[*]}{.metadata.name}{"
¥treq/upd/avl: "}{.spec.replicas}{"/"}{.status.updatedReplicas}{"/"}{.status.readyReplicas}{"
¥trook-version="}{.metadata.labels.rook-version}{"¥n"}{end}‘
kubectl -n $ROOK_NAMESPACE get jobs -o jsonpath='{range .items[*]}{.metadata.name}{"
¥tsucceeded: "}{.status.succeeded}{" ¥trook-version="}{.metadata.labels.rook-
version}{"¥n"}{end}'
• Version Up 前に、Rook の Control plane が正常に稼働していることを
確認します

kubectl -n $ROOK_NAMESPACE get deployments -o jsonpath='{range .items[*]}{.metadata.name}{" ¥treq/upd/avl:
"}{.spec.replicas}{"/"}{.status.updatedReplicas}{"/"}{.status.readyReplicas}{" ¥trook-
version="}{.metadata.labels.rook-version}{"¥n"}{end}'
csi-cephfsplugin-provisioner req/upd/avl: 2/2/2 rook-version=
csi-rbdplugin-provisioner req/upd/avl: 2/2/2 rook-version=
rook-ceph-mgr-a req/upd/avl: 1/1/1 rook-version=v1.1.9
rook-ceph-mon-a req/upd/avl: 1/1/1 rook-version=v1.1.9
rook-ceph-mon-b req/upd/avl: 1/1/1 rook-version=v1.1.9
rook-ceph-mon-c req/upd/avl: 1/1/1 rook-version=v1.1.9
rook-ceph-operator req/upd/avl: 1/1/1 rook-version=
rook-ceph-osd-0 req/upd/avl: 1/1/1 rook-version=v1.1.9
rook-ceph-tools req/upd/avl: 1/1/1 rook-version=

kubectl -n $ROOK_NAMESPACE get jobs -o jsonpath='{range .items[*]}{.metadata.name}{" ¥tsucceeded:
"}{.status.succeeded}{" ¥trook-version="}{.metadata.labels.rook-version}{"¥n"}{end}'
rook-ceph-osd-prepare-k8s-node1 succeeded: 1 rook-version=v1.1.9

Step 1: Update the RBAC and CRDs
kubectl apply -f upgrade-from-v1.1-apply.yaml
• Operator の Upgrade に必要な、Custom Resource Definition 及び
RBAC の更新を実施します

Step 2: CSI upgrade pre-requisites
kubectl -n $ROOK_SYSTEM_NAMESPACE edit deploy rook-ceph-operator
• fuse または rbd-nbd を使っている場合は、CSI driver 再起動時に
Pod の mount が外れてしまいます
• Cephfs plugin 及び rbd plugin の update strategy を OnDelete に変
更することで、問題を回避します

Step 3: Update the Rook Operator
kubectl -n $ROOK_SYSTEM_NAMESPACE set image deploy/rook-ceph-operator rook-ceph-
operator=rook/ceph:v1.2.5
• Rook ceph operator の container image version を v1.1.9 -> v1.2.5
に変更します

Step 4-1: Wait for the upgrade to complete
watch --exec kubectl -n $ROOK_NAMESPACE get deployments -l
rook_cluster=$ROOK_NAMESPACE -o jsonpath='{range .items[*]}{.metadata.name}{"
¥treq/upd/avl:
"}{.spec.replicas}{"/"}{.status.updatedReplicas}{"/"}{.status.readyReplicas}{"
¥trook-version="}{.metadata.labels.rook-version}{"¥n"}{end}'
• Rook ceph operator の container image version を v1.1.9 -> v1.2.5
に変更します

Step 4-2: Wait for the upgrade to complete
rook-ceph-mgr-a req/upd/avl: 1/1/1 rook-version=v1.2.5
rook-ceph-mon-a req/upd/avl: 1/1/1 rook-version=v1.2.5
rook-ceph-mon-b req/upd/avl: 1/1/1 rook-version=v1.2.5
rook-ceph-mon-c req/upd/avl: 1/1/1 rook-version=v1.2.5

Step 5: Verify the updated cluster
kubectl -n $ROOK_SYSTEM_NAMESPACE get pod -o
jsonpath='{range .items[*]}{.metadata.name}{"¥n¥t"}{.status.phase}{"¥t¥t"}{.spec.containers[0].image}{"¥t"}{.spec.initContaine
rs[0]}{"¥n"}{end}' && ¥kubectl -n $ROOK_NAMESPACE get pod -o
jsonpath='{range .items[*]}{.metadata.name}{"¥n¥t"}{.status.phase}{"¥t¥t"}{.spec.containers[0].image}{"¥t"}{.spec.initContaine
rs[0].image}{"¥n"}{end}‘
…
rook-ceph-operator-6b8474c69c-qt9tl
Running rook/ceph:v1.2.5
rook-ceph-osd-prepare-k8s-node1-x6tpr
Succeeded ceph/ceph:v14.2.4-20190917 rook/ceph:v1.2.5
rook-ceph-osd-prepare-k8s-node2-72h27
rook-ceph-osd-prepare-k8s-node3-rql6v
rook-discover-j4pn7
rook-discover-j4xgj
rook-discover-k8cc7
• Rook の control plane が v1.2.5 になっていることを確認します

Step 6: CSI Manual Update (optional)
•CSI driver 再起動時に mount が外れる問題
に該当する場合は、CSI driver の手動 version
up を実施します
• Application Pods の drain を各 worker node にて実施
• CSI driver pod の delete を実施
• Delete 後に作成される新しい Pod は、version up されています

Step 7: Update Rook-Ceph custom resource
definitions
kubectl apply -f upgrade-from-v1.1-crds.yaml
• Version up 全ての Step 完了後に、Custom Resource Definition を
更新します

Rook Version Up (v1.2.x -> v1.2.y)

Step 1: Patch Release Upgrades
kubectl -n rook-ceph set image deploy/rook-ceph-operator rook-ceph-
operator=rook/ceph:v1.2.5
• Ceph operator の Custom Resource について、image のバージョンを
変更します
• 移行先の Version 番号によって、影響を受ける Pod が異なります
• 事前に、実際に使用する from, to の version を用いたテストを実
施しておくことをお勧めします

Affected components (v1.2.x -> v1.2.y)
From -> To CSI Driver ceph-mon ceph-osd ceph-mgr
V1.2.x -> v1.2.0 Affected - Affected -
v1.2.0 -> v1.2.1 - - Affected -
v1.2.1 -> v1.2.2 Affected - Affected -
v1.2.2 -> v1.2.3 Affected - - -
v1.2.3 -> v1.2.4 - - - -
v1.2.4 -> v1.2.5 Affected - - -
• 対象Deployment / DaemonSet の PodTemplate が変更されると、当
該Pod の delete / create が発生します

Ceph Version Up (v14.2.4 -> v14.2.7)

Step 1: Update the main Ceph daemons
ROOK_NAMESPACE=rook-ceph
NEW_CEPH_IMAGE=ceph/ceph:v14.2.7
CLUSTER_NAME=$ROOK_NAMESPACE
kubectl -n $ROOK_NAMESPACE patch CephCluster $CLUSTER_NAME --type=merge -p
"{¥"spec¥": {¥"cephVersion¥": {¥"image¥": ¥"$NEW_CEPH_IMAGE¥"}}}"
• Ceph cluster の Custom Resource について、image のバージョンを変
更します
• Update に必要な実際の処理については、Rook operator が自動的
に実施します

Step 2-1: Wait for the daemon pod updates to complete
# 各Podの update 状況を確認します
watch --exec kubectl -n $ROOK_NAMESPACE get deployments -l rook_cluster=$ROOK_NAMESPACE -o
jsonpath='{range .items[*]}{.metadata.name}{" ¥treq/upd/avl:
"}{.spec.replicas}{"/"}{.status.updatedReplicas}{"/"}{.status.readyReplicas}{" ¥tceph-
version="}{.metadata.labels.ceph-version}{"¥n"}{end}‘
# 全ての Pod について、update が完了したことを確認します
kubectl -n $ROOK_NAMESPACE get deployment -l rook_cluster=$ROOK_NAMESPACE -o
jsonpath='{range .items[*]}{"ceph-version="}{.metadata.labels.ceph-
version}{"¥n"}{end}' | sort | uniq
• Update 処理が完了するのを待ちます
• 上記コマンドを実行することで、現在の status を確認できます

Step 2-2: Wait for the daemon pod updates to
complete
# Rook operator 側の稼働状況をリアルタイムに確認します
ROOK_OPERATOR_POD=$(kubectl -n rook-ceph get pod -l "app=rook-ceph-operator" -o
jsonpath='{.items[0].metadata.name}')
kubectl -n rook-ceph logs -f $ROOK_OPERATOR_POD
• Rook operator の稼働状況をリアルタイムに確認することで、進捗状
況を詳細に把握することができます

Step 3: Verify the updated cluster
TOOLS_POD=$(kubectl -n $ROOK_NAMESPACE get pod -l "app=rook-ceph-tools" -o
jsonpath='{.items[0].metadata.name}')kubectl -n $ROOK_NAMESPACE exec -it $TOOLS_POD
-- ceph status
cluster:
id: 3cce2f74-a60c-4420-b88e-61b2b3f143ae
health: HEALTH_OK
…
• Ceph cluster が正常に稼働していることを確認します

Rook Ceph with External Cluster (1)
• 既存の Ceph Cluster に対して、Rook を用いた k8s との連携ができます
• メリット
• CSI Driver の運用管理のみを k8s で実施する形になるため、k8s 側の運用コス
トを下げつつ責任分界点をキッチリと分けられます
• Rook Version Up の際に Ceph Cluster に与えるサービス影響を完全に排除で
きます
• k8s networking による性能低下の影響を受けません
• デメリット
• Rook のほかに Ceph のデプロイツールを導入する必要があります
• ただし、Ceph 自体が強力な自律システムであるため、オペレータが障害時に介入する
必要はありません
• ceph-mon のノード数が障害等の影響で減少した際は、別途デプロイツールを走らせ
る必要があります

Rook Ceph with External Cluster (2)
•Rook + ceph-ansible (container deployment)
• Ceph のデプロイについては、ceph-ansible を用います
• ceph-mon, ceph-osd の配置を自由に決められます
• k8s worker node 上に配置
• k8s クラスタとは独立したノードに配置
• crush mapping や block device mapping に k8s を介在させる必要がないため、運用がシンプ
ルになります
• ceph-ansible 自体が agent 不要でシンプルなため、agent 起因で Ceph クラスタに
影響を与える可能性がありません

Summary: Rook Version Up (1)
•長期的な運用の観点では、対象の Storage
Backend だけでなく、Rook Operator 自体の
Version Up が必要になる
•Minor Version Up は作業コスト・リスクは低いものの、
Major Version Up についてはサービスへの影響を伴う
作業が発生する

•Ceph の Version Up については、煩雑な作業
を Rook Operator が引き受けてくれるため、と
ても便利
• ただし、リリース直後の Ceph には致命的な Known Issues が
含まれている可能性もあるため、十分な事前検証が必要

•K8s 側の運用をシンプルにしたい場合は..
•ceph-ansible + Rook external cluster
• Ceph クラスタの管理については ceph-ansible を用いる
• Rook は external cluster の形でCeph を使用する
• メリット
• Rook Operator の Version Up に伴う Ceph クラスタへのサービス影響を排除で
きる
• デメリット
• 2つのデプロイシステムを管理する必要がある
• ceph-mon が worker ノード障害等で減少した際は、手動で ceph-ansible コ
マンドを実行してノード数を維持させる必要がある

Rookの基礎・バージョンアップ

More Related Content

What's hot (20)

Similar to Rookの基礎・バージョンアップ (20)

More from Takashi Sogabe (12)

Rookの基礎・バージョンアップ