こんにちは。レッドハットでストレージを中心にクラウドインフラを生業にしている宇都宮(うつぼ)です。
なんだか久しぶりな感じがしますが、今回はOpenShift Data Foundation(ODF)のMultiCloud Gateway(MCG)について話します。
以前(だいぶ前)にもMCG自体については紹介したのですが、今回はそんなMCGにまつわる実践的な使い方を紹介します。 MCGってなんだという方は、こちらのちょっとアレなノリの記事をご参照ください。
参考:
https://rheb.hatenablog.com/entry/ocs/01
https://rheb.hatenablog.com/entry/ocs/02
OpenShiftはオブジェクトストレージを使う
OpenShiftを使うと地味にオブジェクトストレージを求められることがあります。代表的なものはコンテナレジストリのバックエンドです。
例えば、Red Hatのコンテナレジストリのソフトウェアに、Red Hat Quayというものがありますが、このQuayはバックエンドにオブジェクトストレージを必要とします。
参考: https://rheb.hatenablog.com/entry/202002-quay
また、OpenShiftの内部レジストリ(OpenShift Image Registry)のバックエンドも、Persistent Volumeでも構成可能ではありますがオブジェクトストレージがRecommendedです。
パブリッククラウドでOpenShiftを使っているならクラウドストレージサービスを使えば話は早いのですが、オンプレだとそう簡単ではありません。
そういう場合にMCGは便利だったりします。
MCGはPVをバックエンドにバケットを提供できる
以前紹介した内容を見ると、MCGは他のオブジェクトストレージのバケットを仮想的に統合するゲートウェイ、のような説明をしています。
そうすると、「結局バックエンドにあらかじめオブジェクトストレージが要るんじゃないかよ、何がやりたいんだコラ」と思いますよね。ナニコラタココラと。
実はMCGは進化して、PVをバックエンドにしてバケットを提供できるようになっています。
まずはPVの源泉となるStorage Classを指定して BackingStore
というカスタムリソースを作ります。そしてこれを使う BucketClass
を作って、後は OBC(ObjectBucketClaim)
を投げるだけでサクッとバケットが作れます。まあカンタン!
ODFはMCGだけインストールするオプションがある
MCGはODFの中に含まれている機能の1つなので、ODFをインストールすることでMCGが使えるようになります。
しかし、「ぶっちゃけPVには困ってないからRook-Cephは必要ないんだよなぁCPUもメモリも食うし。MCGだけ使いたいんだよなぁ」みたいな場合もあるでしょう。
ええ、実はODFはMCGだけデプロイすることができます。
ODF Operatorをインストールして、StorageSystem
を作る時に、デプロイメントタイプに"MultiCloud Object Gateway"を選択して StorageSystem
を作りましょう。
そうするとこんな具合にMCGだけデプロイされます。
$ oc get pod -n openshift-storage NAME READY STATUS RESTARTS AGE csi-addons-controller-manager-cd76d866d-slfp7 2/2 Running 0 6m28s noobaa-core-0 1/1 Running 0 2m9s noobaa-db-pg-0 1/1 Running 0 2m10s noobaa-endpoint-768dfc9bd6-57jk8 1/1 Running 0 47s noobaa-operator-5bb8ccb9b-gp5h5 1/1 Running 1 (2m9s ago) 6m44s ocs-metrics-exporter-7fffdc5cf5-c6wsf 1/1 Running 0 6m21s ocs-operator-68ccfbd9dd-7gbln 1/1 Running 0 6m42s odf-console-d5fc456fd-xbtm4 1/1 Running 0 6m41s odf-operator-controller-manager-546574b575-j2crh 2/2 Running 0 6m41s rook-ceph-operator-6685c78555-6hjvq 1/1 Running 0 6m42s $ oc get pvc -n openshift-storage NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE db-noobaa-db-pg-0 Bound pvc-61f14200-5bf2-4670-b295-3421ec5d2733 50Gi RWO gp3-csi 6m48s
なんにも使われてないrook-ceph-operatorが哀愁を漂わせますね。
ちなみに noobaa-db
のPVは、Rook-Cephがある場合はそこから作られますが、ない場合は StorageSystem
を作るときに指定したStorage Classから作られます。
ちゃんとGUIも使えます。
レジストリとMCGを連携させることができる
さてここからが本題でレジストリの話に戻るのですが、Red Hat Quayも内部レジストリも、MCGと連携してオブジェクトバケットをデータストアとして置くことができます。
QuayとMCGの連携
特にRed Hat Quayは、MCGが居るOpenShiftクラスタでQuay Operatorを使って構成すると、バックエンドストレージの設定を何もしなくても自動的にMCGのバケットを作って設定してくれます。
やってみましょう。
Quay Operatorをインストールして、
レジストリを動かす適当なプロジェクトを作って、QuayRegistry
カスタムリソースを作ります。
この段階で、"config bundle"というQuayの設定パラメータをSecretの形で作成して適用することで、色々とカスタマイズすることができます。
今はオブジェクトバケットが自動的にできているかどうかだけを見たいので、リソースの名前以外は全部デフォルトで進めます。
10-15分くらい待っていると、レジストリが自動的にでき上がります。
$ oc get all -n my-quay NAME READY STATUS RESTARTS AGE pod/my-registry-clair-app-59d65b9c8d-5hvjf 1/1 Running 0 8m21s pod/my-registry-clair-app-59d65b9c8d-c6zcq 1/1 Running 0 7m6s pod/my-registry-clair-app-59d65b9c8d-chpb6 1/1 Running 0 8m21s pod/my-registry-clair-app-59d65b9c8d-dw8w4 1/1 Running 3 (14m ago) 15m pod/my-registry-clair-app-59d65b9c8d-knfvt 1/1 Running 0 7m51s pod/my-registry-clair-app-59d65b9c8d-m9sw7 1/1 Running 0 7m51s pod/my-registry-clair-app-59d65b9c8d-tg2gf 1/1 Running 3 (14m ago) 14m pod/my-registry-clair-postgres-5476fbcbcf-7snc4 1/1 Running 1 (14m ago) 15m pod/my-registry-quay-app-84cd84c546-9cr4g 1/1 Running 0 13m pod/my-registry-quay-app-84cd84c546-vsktj 1/1 Running 0 13m pod/my-registry-quay-app-upgrade--1-fwvpz 0/1 Completed 0 14m pod/my-registry-quay-config-editor-5b8985df88-kmkrg 1/1 Running 0 14m pod/my-registry-quay-database-7bd56b69d7-6vgrh 1/1 Running 0 15m pod/my-registry-quay-mirror-584f5d6fbc-c5hq4 1/1 Running 0 14m pod/my-registry-quay-mirror-584f5d6fbc-z7jg4 1/1 Running 0 14m pod/my-registry-quay-redis-67854cb5fd-nwdp6 1/1 Running 0 15m NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/my-registry-clair-app ClusterIP 172.30.111.209 <none> 80/TCP,8089/TCP 15m service/my-registry-clair-postgres ClusterIP 172.30.138.193 <none> 5432/TCP 15m service/my-registry-quay-app ClusterIP 172.30.22.33 <none> 443/TCP,80/TCP,8081/TCP,55443/TCP 15m service/my-registry-quay-config-editor ClusterIP 172.30.24.78 <none> 80/TCP 15m service/my-registry-quay-database ClusterIP 172.30.130.162 <none> 5432/TCP 15m service/my-registry-quay-metrics ClusterIP 172.30.11.12 <none> 9091/TCP 15m service/my-registry-quay-redis ClusterIP 172.30.143.50 <none> 6379/TCP 15m NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/my-registry-clair-app 7/7 7 7 15m deployment.apps/my-registry-clair-postgres 1/1 1 1 15m deployment.apps/my-registry-quay-app 2/2 2 2 15m deployment.apps/my-registry-quay-config-editor 1/1 1 1 15m deployment.apps/my-registry-quay-database 1/1 1 1 15m deployment.apps/my-registry-quay-mirror 2/2 2 2 15m deployment.apps/my-registry-quay-redis 1/1 1 1 15m NAME DESIRED CURRENT READY AGE replicaset.apps/my-registry-clair-app-59d65b9c8d 7 7 7 15m replicaset.apps/my-registry-clair-postgres-5476fbcbcf 1 1 1 15m replicaset.apps/my-registry-quay-app-6d7b68678d 0 0 0 15m replicaset.apps/my-registry-quay-app-84cd84c546 2 2 2 14m replicaset.apps/my-registry-quay-config-editor-5b8985df88 1 1 1 14m replicaset.apps/my-registry-quay-config-editor-5d9c485579 0 0 0 15m replicaset.apps/my-registry-quay-database-7bd56b69d7 1 1 1 15m replicaset.apps/my-registry-quay-mirror-584f5d6fbc 2 2 2 14m replicaset.apps/my-registry-quay-mirror-68cd8d4b87 0 0 0 15m replicaset.apps/my-registry-quay-redis-67854cb5fd 1 1 1 15m NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE horizontalpodautoscaler.autoscaling/my-registry-clair-app Deployment/my-registry-clair-app 75%/90%, 1%/90% 2 10 7 15m horizontalpodautoscaler.autoscaling/my-registry-quay-app Deployment/my-registry-quay-app 30%/90%, 1%/90% 2 20 2 15m horizontalpodautoscaler.autoscaling/my-registry-quay-mirror Deployment/my-registry-quay-mirror 25%/90%, 0%/90% 2 20 2 15m NAME COMPLETIONS DURATION AGE job.batch/my-registry-quay-app-upgrade 1/1 12s 14m NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD route.route.openshift.io/my-registry-quay my-registry-quay-my-quay.apps.cluster-px6nv.px6nv.sandbox906.opentlc.com my-regis try-quay-app http edge/Redirect None route.route.openshift.io/my-registry-quay-builder my-registry-quay-builder-my-quay.apps.cluster-px6nv.px6nv.sandbox906.opentlc.com my-regis try-quay-app grpc edge/Redirect None route.route.openshift.io/my-registry-quay-config-editor my-registry-quay-config-editor-my-quay.apps.cluster-px6nv.px6nv.sandbox906.opentlc.com my-regis try-quay-config-editor http edge/Redirect None
さあここで何も設定しなかったデータストアですが、OBC
を確認してみると、
作られています。Storage Classに "openshift-storage.noobaa.io" が指定されていることから、MCGで間違いなさそうです。
またオーナーとして QuayRegistry
が指定されているので、Quayが作った OBC
であることはがわかります。
もちろん自分で作った OBC
をデータストアに指定することは可能です。ここではQuayとMCGが連携して動きますーという一例で、データストアの自動構成をお見せしました。
内部レジストリとMCGの連携
内部レジストリとMCGは、Quayのように自動では連携することはしません。
こちらのドキュメントの手順のように OpenShift Image Registry Operator を使って手動で構成できます。
まとめ
ODFは現在 "OpenShift Platform Plus(OPP)" の一員として含まれており、OpenShiftのストレージやデータ系のインフラサービスを提供する基盤として存在感を日々高めています(うつぼにとっては)。
レジストリだけではなく、バックアップ/リストアのOADPや、マイグレーションのMTC、マルチクラスタのACMなど、インフラ側のツールとバリバリ連携が進んでいます。今後はApplication側とも積極的に連携していくでしょう(うつぼの期待では)。
そんな具合で、今後もOpenShift好きな方はODF/MCGから目が離せないですね!ハハハッ!
というわけで今回はここまで。