🙄

Red Hat OpenShiftをざっくり理解する。

2023/05/04に公開

AWS

K8s

OpenShift

tech

まえがき

現在私が開発を行っているWEBシステムはROSA(Red Hat OpenShift on AWS/Kubernetesコンテナプラットフォーム)を利用しています。

↓の図にあるように、開発者が該当ブランチにマージしたら自動でイメージ作成＆デプロイまでやってくれるCICD環境(Jenkins)と連携している形です。

これをまとめるまでは、
・OpenShift内の中身がブラックボックス状態。どうなってるん？
・どういう流れでイメージが作られてデプロイされてるん？
という状態だったので、忘れないよう記事に残しておきます。

※本記事は勉強用OUTPUTとして残しておくので、Red Hat Openshiftの全てを網羅しているわけではないです。もっと勉強しないとな...(´_ゝ｀)

単語

大前提である単語の定義を改めて確認。

コンテナ

OS上のアプリケーションの動作環境を仮想的に区切る技術。
1台の物理サーバー上で動作する複数のコンテナを、それぞれ独立したサーバー環境のように利用できる。
機能単位の小さなアプリケーション（サービス）を組み合わせてシステムを実現する設計手法であるマイクロサービスとの相性も良い。

イメージ

コンテナを構築するための設計書(テンプレート)
イメージ = リポジトリ＋タグで決まる。
例: xxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/repo1:latest

レジストリとリポジトリとイメージ(Tag付)

リポジトリとイメージは、GitHubのリポジトリとTagの関係性と同じ。
１つのリポジトリに対してバージョン(イメージ/Tag)が存在しているイメージ。
レジストリはGitHubに該当する。
レジストリ(Amazon ECR)で、アプリA(リポジトリ)のイメージ(V_1.X.X) を管理。
アプリAがリリースされるたびに、アプリA(リポジトリ)にはイメージがどんどん増えていく。

コンテナオーケストレーション/Container orchestration

Container orchestration automates the deployment, management, scaling, and networking of containers.
Reference: Red Hat｜What is container orchestration?

✅コンテナのデプロイ/管理/スケーリング/ネットワーキングを自動化すること。

１つ１つのPod(サーバ)を人間が監視して、アクセス数が増えたらスケーリングしたりPodが死んだらデプロイし直すとか手間だよね...
このコンテナの管理を自動でやってくれるツール(コンテナオーケストレーションツール)ないかな -> これがKubernetesである。

Kubernetes

Container orchestration toolの１つ。
米グーグル（Google）が社内で利用していたコンテナ管理ツールを汎用化してOSSにしたもの。

Kubernetesマネージドサービス

自動でコンテナ管理してくれるコンテナオーケストレーションツール(Kubernetes)をそのまま使うだけでいいの？...そういうわけではないようだ。Kubernetesを利用する主な選択肢としては

サーバにKuberneteをインストール＆1から構築
クラウドベンダーが提供するKubernetesマネージドサービスを利用

1と2の主な違いは

Control planeがmanagedかどうか。
・2の場合、DeveloperはControl planeのことは気にする必要なし。
・マネージドサービスが常にControl planeが正常稼働するよう管理してくれる。
Data planeに対するOS update等の管理
・2の場合、Data plane内の各NodeのOS updateやセキュリティパッチ対応などはマネージドサービスがやってくれる。Developerは気にしなくていい。

裏を返せば、そのままKubernetesを使う場合、自分でControl planeを管理しないといけないし、Data plane内の各NodeのOS updateなどをする必要があるということだ。

参考：Compare EKS vs. self-managed Kubernetes on AWS

ROSA全体像

私が開発しているWEBシステムはWEBサーバ(NodeJS/React)と複数のAPIサーバ(Java/SpringBoot)で構成されており、いずれもOpenShift内で各サーバ(Pod)を立ち上げてCloudFrontからアクセスできる形になっています。

ROSAの"Red Hat OpenShift"ってそもそも何？

✅Red Hat社が提供するKubernetesマネージドサービス。
✅Red Hat社が直接提供しているものを利用する手段があるが、他サービスで既にAWSを利用している＆それらとOpenShiftを連動させたい(例えばCloudFrontと紐づけたい)場合は、AWS上で利用できるRed Hat OpenShiftを採用することになる（私の開発現場ではそう）。

Kubernetesになくて、OpenShiftにあるもの

「素のKubernetesに便利機能を付け加えたのがOpenShift」みたいなイメージなので、以下の要素はOpenShift固有の特徴になる。
✅Imageレジストリ作成/運用可能(ImageStream) ※別でレジストリ作成不要だから嬉しい
✅CI/CDパイプラインの作成/運用可能 ※JenkinsでCICD構成してる場合は使わないかな
✅OpenShift特有のリソース
　→ Project/DeploymentConfig/BuildConfig/Route/ImageStream

クラウドベンダーが提供するKubernetesマネージドサービス

素のKubernetesを運用するには複雑すぎるという問題を解決してくれるのが、各クラウドベンダーが提供するKubernetesマネージドサービス。Red Hat OpenShiftと含め比較対象となるものがこちら。

ベンダー	サービス名
AWS	EKS(Elastic Kubernetes Service)
GCP	GKE(Google Kubernetes Engine)
Azure	AKS(Azure Kubernetes Service)
Red Hat	Red Hat OpenShift★本記事のメイン★

※AWS ECSはAWSオリジナルのソフトウェアをベースに構築されている一方で、EKSはKubernetesをベースに構築されている。

どれを選ぶのかについては下記の記事を参照。

Red Hat OpenShiftの各リソース

OpenShift特有のものは🔴

リソース名	内容
Route🔴	Host名/SSLサーバ証明書を設定。 ScalingするPodにSSLサーバ証明書設定不要👍
Service	Podが内部公開してるPortと外部公開するPortの紐づけ。
Pod	サーバ本体。
DeploymentConfig🔴	後述のReplicationController, Replicat Setを管理。
Replication Controller	Pod のレプリカ(複製)数を維持する。
Replica Set	安定したPodのセットを維持する。
BuildConfig🔴	イメージを作成する。
ImageStream🔴	作成したイメージの保管場所/レジストリ。

負荷分散

OpenShiftにおける負荷分散

Serviceでロードバランシングする。
https://docs.openshift.com/container-platform/4.8/networking/configuring_ingress_cluster_traffic/configuring-ingress-cluster-traffic-load-balancer.html#:~:text=OpenShift Container Platform provides methods,method uses a load balancer.

AWS EKSにおける負荷分散

AWS Load Balancer ControllerによってEKS外にAWS ELBを作成する。
・L4で負荷分散したければNLB(Network Load Balancer)
・L7で負荷分散したければALB(Application Load Balaner)
を作成する。

無料でハンズオンできる「Red Hat OpenShift Online」

実際に使ってみないとよくわかんないよね、ということで後で使う予定のRed Hat OpenShift Online。60日間まで無料ぽいので、あとで学習用に使ってみる。