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

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

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

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

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

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

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

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.5xlarge 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:20210609210349p:plain
ロードバランサー構成の書き起こし
OpenShift (Kubernetes)API Server のアクセスを受け付けるポートは6443ですが、それを受け付ける ELBRed Hat SRE用と、ユーザー用で分かれている事がわかります。入り口のトラフィックの経路を分割しておこう。という思想が見て取れます。

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

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

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

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

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

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

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

OpenShiftでは、Router と呼ばれる Infra Node上のPodが (配置はどこでも良いのですが、通常 Infra NodeLabelTaintを使って配置します)、一旦、クラスター外部から来た 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つだけデプロイされているのがわかります。(紙面の都合上、確認ログは省きますが、上記のInServiceInfra Node の上にこれら Podがデプロイされていました)

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

Router Pod を増やしてみる

せっかく Infra Nodeが 3本あるので、RouterPod も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としてフォワード先になりました。

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

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

まずは 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コマンドや、OpenShiftCLI である 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として名前を付けたROSAOpenShift クラスターが表示されています。これは、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構成の画面があります。

f:id:yuhki-hatenua:20210610133439p:plain
OCM 上の ROSA Cluster Networking 設定

この画面では、デフォルトではインターネットに公開する設定になっている、API Server や、ユーザーアプリケーションのRouterの設定を Private に切り替える事ができるようになっています。

他にも、こちらの記事rosa コマンドを使って行われている Machinepoolの作成とMacinepoolへの Worker Node の追加等もこの OCMからできるようになっています。

ROSA クラスターのアップグレードの設定 (自動、手動) や、Supportケースの起票など、ROSAクラスターの管理に必要な事が、ここからできるようになっています。

f:id:yuhki-hatenua:20210610135004p:plain
サポートケースの管理画面

今回は、ROSAによって作成されるデフォルトの AWS上のオブジェクトをざっと見て周ったのと、ROSAを含めたOpenShiftクラスターを統合管理するツールであるOCM (OpenShift Cluster Manager) をご紹介しました。

ROSAは今後もアップデートが予定されており、今後も使いやすさに磨きがかかっていく予定ですが、随時情報をアップデートしていきたいと思います。

* 各記事は著者の見解によるものでありその所属組織を代表する公式なものではありません。その内容については非公式見解を含みます。