マネージド OpenShift サービス ROSA(ろさ) の構成を覗いてみる

こんにちは、Red Hat版のKubernetes である、OpenShift を担当しています。花田です。

前回は、OpenShift の AWS上のマネージドサービスであるROSAの cluster を作成する。

独自の概念であるMachinepoolという概念を使って、Worker Nodeを使いしてみて、その周りの制限を探ってみる。という事をやってみました。

今回は、ROSAで作成される構成がどういうものになのか、AWSコンソール上から見ていこうと思います。

EC2 インスタンスの構成を観察してみる

初期状態のROSAの EC2 の構成を観察してみます。今回は

rosa create cluster --cluster-name rosa-cluster --multi-az

で Multi AZの最小構成で ROSAクラスターを作成した時の AWS Console からの EC2の眺めてみます。

Single AZ構成の時の EC2インスタンスについては、マニュアルの「1.5. プロビジョニングされる AWS インフラストラクチャー」に書いているのですが、同じかどうかの確認です。

f:id:yuhki-hatenua:20210609205737p:plain — 作成されたEC2インスタンス

インスタンスの名前から役割が想像できるようになっています。

Master Node m5.xlarge x 3
Infra Node r5.xlarge x 3
Worker Node m5.xlarge x 3

で構成されている事が見て取れます。Single AZ構成と同じインスタンスタイプが使われていて、本数だけが増えています。

こちらのページによると

m5.xlarge = 4 vCPU 16GB ：コンピューティング最低化ノード
r5.xlarge = 4 vCPU 32GB ：メモリ最適化ノード

なので、Infra Nodeにメモリが多めのインスタンスを使用している事がわかります。

ロードバランサーの構成を観察してみる

さて、次は ELB (Elastic Loadbalancer)の構成を見て行きます。

f:id:yuhki-hatenua:20210609205849p:plain — 作成されたロードバランサー

なにやら5つ程、ELB ( NLBx 2, CLB x 3) が作成されています。このままだと良く分からないので、構成を確認しながら図に起こしてみた所、以下のようになりました。

f:id:yuhki-hatenua:20211220135913p:plain — ロードバランサー構成の書き起こし

OpenShift (Kubernetes)で API Server のアクセスを受け付けるポートは6443ですが、それを受け付ける ELB が Red Hat SRE用と、ユーザー用で分かれている事がわかります。入り口のトラフィックの経路を分割しておこう。という思想が見て取れます。

Red Hat SRE用とされる6443の Load Balancerは、CLBが使われており、対象も Master NodeだけではなくWoker Nodeにも分散されています。この部分は標準的なオンプレのOpenShiftと異なる部分で気になる所です。

が、ここはRed HatのSREチームが使用する部分なので、追求は一旦、脇に置いておきましょう。(気になる方は、フォワード先の Portをどんな Service が構成されているか確認してみると面白いかもしれません)

他にも Red Hat SRE用の CLBには、ソースセキュリティグループが設定されており、Red Hatが使用する特定の IPアドレスレンジのみのインバウンドが許可されているのが見て取れました。

ユーザーHTTP アプリ用の ELB(CLB)

ユーザーが作成した Web アプリケーションは、図の上部のCLBが受け取り、Infra Node上にある Router (OpenShift の Ingress実装) にフォワードされます。

NLBのフォワード先の構成は、以下のように全てのNodeが対象になっています。が、実際にInServiceとなっているのは2つのInfra Nodeだけです。

f:id:yuhki-hatenua:20210609232343p:plain — 80/443 用のCLB (Classic Load Balancer)の構成

OpenShiftでは、Router と呼ばれる Infra Node上のPodが (配置はどこでも良いのですが、通常 Infra Nodeに LabelやTaintを使って配置します）、一旦、クラスター外部から来た 80/443 の受け口となり、Worker Node上で稼働するユーザーのコンテナに対してリクエストをフォワードします。

OpenShiftで使用されるRouter Podの実体は、Load Balancer アプリとして良く使用されるHA Proxyです。クラスター内のHA Proxyが一旦トラフィックを受け止めて、そこからさらにクラスター内のどこかのWorker Nodde上に存在するPod にフォワードする。と考えれば、動きが理解しやすいかもしれません。

このRouter Podの配置を確認してみます。

# Router Pod は、openshift-ingress という namespace に所属しています。
 $ oc get pods -n openshift-ingress -o wide
NAME                             READY   STATUS    RESTARTS   AGE     IP            NODE                                              NOMINATED NODE   READINESS GATES
router-default-f998c67f9-mtkcx   1/1     Running   0          6h31m   10.130.2.21   ip-10-0-135-141.ap-northeast-1.compute.internal   <none>           <none>
router-default-f998c67f9-snxw4   1/1     Running   0          6h31m   10.131.2.21   ip-10-0-189-232.ap-northeast-1.compute.internal   <none>           <none>
 $

Router Pod (router-default-xxxxxx-xxxxxx) は、2つだけデプロイされているのがわかります。(紙面の都合上、確認ログは省きますが、上記のInService の Infra Node の上にこれら Podがデプロイされていました)

ですので、NLBは、Router Podのある所にだけ、リクエストをフォワードしている事がわかります。

Router Pod を増やしてみる

せっかく Infra Nodeが 3本あるので、Router の Pod も3つにしたい所です。2→3 に Router Podの数を増やしてみます。

# Router Pod をコントロールする、Ingress Controller (名前は default) の設定を編集します。
 $ oc edit ingresscontroller/default -n openshift-ingress-operator
<省略>
spec:
  defaultCertificate:
    name: rosa-cluster-primary-cert-bundle-secret
  domain: apps.rosa-cluster.btpl.p1.openshiftapps.com
  nodePlacement:
    nodeSelector:
      matchLabels:
        node-role.kubernetes.io/infra: ""
    tolerations:
    - effect: NoSchedule
      key: node-role.kubernetes.io/infra
      operator: Exists
  replicas: 3   # ここを 2→ 3に編集して保存
  routeSelector: {}
<省略>
 $ 
 $ oc get pods -n openshift-ingress
NAME                             READY   STATUS    RESTARTS   AGE
router-default-f998c67f9-b2pvl   1/1     Running   0          17s
router-default-f998c67f9-mtkcx   1/1     Running   0          6h39m
router-default-f998c67f9-snxw4   1/1     Running   0          6h39m
 $

無事 Routerが 3つに増えました。

ロードバランサー側のステータスを確認してみます。

f:id:yuhki-hatenua:20210609234450p:plain — Router Pod を 3つに増やした時のステータス

ロードバランサー側もInfora Node 全てがInServiceとしてフォワード先になりました。

ストレージボリュームを観察してみる

EC2 、ELBと来て、次はストレージの初期構成を観察してみます。

まずは EBSの状態です。

f:id:yuhki-hatenua:20210609205932p:plain — 作成されたボリューム

Name カラムから推測ができる通りに

Master Node 350GiB io1 1000 IOPS
Infra Node 300GiB gp2 900 IOPS
Worker Node 300GiB gp2 900 IOPS

がアタッチされています。 etcd のある Master Node にやや大きめの領域と、若干高めのIOPSをプロビジョニングしている事がわかります。

その他に、Nameカラムからは何のボリュームか良く分からない 100 GiB x 2 と10GiB x 3 のボリュームが見えます。これらは、確認した所 Infra Node にアタッチされていました。

恐らく、OpenShift Monitoring 用のボリュームではないか。と当たりを付けて、OpenShift Monitoring がデプロイされる namespaceである、openshift-monitoring に所属する PVC (Persistent Volume Claim)を確認してみます。

$ oc get pvc -n openshift-monitoring
NAME                                    STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
alertmanager-data-alertmanager-main-0   Bound    pvc-4d3f789e-69a2-4018-a1e2-203c4d11c02e   10Gi       RWO            gp2            7h55m
alertmanager-data-alertmanager-main-1   Bound    pvc-3575ba46-984e-434b-9137-165d9aebcd77   10Gi       RWO            gp2            7h55m
alertmanager-data-alertmanager-main-2   Bound    pvc-242a40fe-3610-4b7a-b309-b394a19a3e6c   10Gi       RWO            gp2            7h55m
prometheus-data-prometheus-k8s-0        Bound    pvc-b358791e-5665-4cf1-9dcd-17e8ca0d5ec4   100Gi      RWO            gp2            7h55m
prometheus-data-prometheus-k8s-1        Bound    pvc-b152847b-5b80-45fd-a19a-a08f1e0ca455   100Gi      RWO            gp2            7h55m
$

ビンゴ！です。10 GiB x 3 は、Alert Manager 用、100 GIB x 2 は、Prometheus のデータ保管用のボリュームのようです。これらの Alert Mangerと、Prometheus は、OpenShift Monitoringと呼ばれるOpenShiftの監視用のサブコンポーネントを構成するモジュールです。

次に S3 を見て行きます。バックアップの保管先と思われる S3のバケットが作成されています。

f:id:yuhki-hatenua:20210609210046p:plain — 作成された S3バケット

名前 のカラムから、上の2つは backup 用、下の1つは registry 用だと思われます。

一応、xxxxx-image-registry-xxxxx の方だけでも確認してみます。Image Registry の構成の中身を、バケット名の一部を使って grep してみると…

$ oc get configs.imageregistry.operator.openshift.io -o yaml | grep "rosa-cluster-"
        bucket: rosa-cluster-sl69n-image-registry-ap-northeast-1-ktnkgfriwbfla
        bucket: rosa-cluster-sl69n-image-registry-ap-northeast-1-ktnkgfriwbfla
$

S3のバケット名が指定されていました。

ちなみにこの OpenShiftに標準でバンドルされている Image Registryですが、一番長い呼ばれ方だと Integrated OpenShift Container Platform Registryと呼ばれます。

Red Hat SRE チームの AWSインフラへのアクセス

ここまで、見て回った Master Nodeや、Infra Nodeや周辺の AWSオブジェクトは、 Red Hat SREチームが管理する部分なので、基本的にユーザーが触らなくて良い(触ってはいけない）部分になります。

ROSAはマネージドのOpenShift環境なので、ユーザーの関心範囲はWorker Nodeとその上にデプロイするユーザーのアプリケーションであり、Manster Nodeや、Worker Node等は、Red Hat SREチームが管理します。

とは言え Worker Nodeを追加したり、新しい PVを追加したり。と AWS上のオブジェクトに変更をもたらすはずのユーザーの操作というものがあります。

それらの作業は rosaコマンドや、OpenShift の CLI である ocコマンド、後述するOCM (OpenShift Cluster Manager) を通して行う事になります。

また反対に、Red Hat SREチームも通常は、AWS アカウントにアクセスはしません。緊急時にのみ「明確に定義された監査可能な手段」でアクセスする場合があります。詳細については、マニュアルの「3.3. アイデンティティーおよびアクセス管理」を参照下さい。

また、Red Hat SRE チームとユーザーの責任範囲については、「第2章責任分担マトリクス」のようなドキュメントも用意されています。

ROSA クラスターの管理 (OCM : OpenShift Cluster Manager)

ROSAをインストールするためには、cloud.redhat.com でアカウントを作成する必要があります。

作成したアカウントで cloud.redhat.com にログインした後、インストールするモジュールをAWS上に引っ張ってくるための token を取得します。

この cloud.redhat.com には、インストール用のtokenを取得する以外にも Red Hat製品の統合管理ツールとしての機能を持っています。

cloud.redhat.com にログインし、左側のペインのOpenShift というメニューをクリックします。

rosa-clusterとして名前を付けたROSAのOpenShift クラスターが表示されています。これは、OCM (OpenShift Cluster Manager) と呼ばれるクラウド・サービスの画面で、OpenShiftクラスターを管理するためのツールです。

f:id:yuhki-hatenua:20210610121540p:plain — OCM (OpenShift Cluster Manager) 画面

ここに表示されるOpenShift クラスターは、ROSAで作成された OpenShift クラスターだけでなく、同じ cloud.redhat.com ユーザーアカウントを使用して、tokenを取得した全ての OpenShiftクラスターが表示されます。

つまり Azureの上に作成しても IBM Cloud の上に作成しても GCPの上に作成してもオンプレミスのVMwareの上に作成したものも、同じユーザーアカウントを使って tokenを取得して構築したOpenShiftクラスターであれば、全てこちらに表示され、現在のステータス等が確認できるようになっています。

さらにROSAでは、幾つかの Cluster 管理機能をここからも行えるようになっています。

例えば、ROSAで作成したOpenShiftクラスターを選択すると以下のようなNetwork構成の画面があります。