コンテナは、軽量さやポータビリティ性の高さといった特性により、アプリケーション開発で求められる変更の柔軟性と迅速性に対応ができることから、ここ数年多くの環境で活用が進んでいる。
コンテナ管理ツールであるKubernetesはオープンソース化され、CNCF（Cloud Native Computing Foundation）に移管されてから、コミュニティを拡大しつつ、多くの企業に注目されている。
近年は、Kubernetesがコンテナ管理ソフトウェアのデファクトスタンダードとなっており、また多くのクラウド事業者がKubernetesのマネージドサービスを提供しているため、Kubernetesを活用したプロジェクトが増加している。
OpenShiftは、Red Hat社がサポートするKubernetesディストリビューションの1つであり、企業のITの観点から、Red Hat社がKubernetesに機能追加している。企業が速やかにコンテナを採用できるように工夫され、Kubernetesが広く用いられるためには、とても重要なソフトウェアだと言えるだろう。
2020年5月に発表された Amazon Red Hat OpenShiftをはじめ、今後さまざまなマネージドサービス提供業者からのサポートが増えると予想される。IT基盤を担当するエンジニアも、OpenShiftの知識が求められていくだろう。
IT基盤から見たとき、OpenShiftをアプリケーション実行環境として使用する際には、企業内ネットワークやインターネットなど外部ネットワークからコンテナへ通信する要件が多く発生する。こうしたネットワークの接続性もコンテナの基盤の役割となり、どのようにデザインしていくかが重要な設計対象となる。
OpenShiftはクラウドかオンプレミスか、あるいはマネージドか自社運用かなど、さまざまな形態を取り得るが、設計するうえで基礎となる構造を理解することが必要となる。
そこで本稿ではOpenShiftの概要を説明したうえで、OpenShiftのアーキテクチャをネットワーク的な視点から解説しつつ、実行例を紹介していきたい。
.
OpenShiftの概要
OpenShiftとは、エンタープライズレベルでコンテナのデプロイメントや自動運用を管理するオーケストレーションツールである。OpenShiftは、企業の運用者・開発者に向けた機能が充実している。とくにアプリケーションのデプロイに関するサービス設定やアップデート、オートスケーリング、可用性確保、障害からの回復などを自動化する。
2019年にリリースされた最新のOpenShift 4では、CoreOS社買収による製品の統合やKubernetes Operatorsによる運用自動化の機能強化といった多くのアップデートが行われ、高い利便性を提供しつつ進化を重ねている（本稿ではOpenShift 4をベースにして紹介する）。
OpenShiftの主なコンポーネントを、図表1に示す。
.
OpenShiftで管理されるHost群をClusterと呼び、Cluster内の物理または仮想マシンLinux ServerをNodeと呼ぶ。
Cluster全体の管理を担うコントローラーNodeをMaster Nodeと定義する。OpenShiftではコンテナ管理の最小単位をPodと定義し、アプリケーションは単一または複数のPodとしてデプロイされる。
Worker Nodeは、コンテナアプリケーションのワークロードを実行するNodeとなる。Master NodeとWorker Nodeはいずれも複数のNodeから構成される。
Pod内には、1つ以上のコンテナが存在する。Podが通信に利用するIPアドレスは、Cluster内のプライベートなアドレス空間からPod単位に付与される。
なお、このIPアドレスはCluster内で恒久的に利用されるものではなく、Podが生成されるたびに新しいアドレスが付与される。また、それぞれのPodは特徴を示す任意のラベルを付けて識別する。ラベルにより、Podをグループ化したり、特定のPodを抽出したりできる。
なお、動的に再構成されるコンテナに対して安定したアクセスを提供するために、ネットワークを抽象化してコンテナへの接続を提供するServiceというコンポーネントがある（Serviceについては後述する）。
.
OpenShiftの提供形態
OpenShiftは大きく分けて、以下のような2つの提供形態があり、OpenShiftを導入する際には要件に応じて適切に選択するのが望ましい。
マネージドサービス
Red Hat OpenShift on IBM Cloud、Red Hat OpenShift on AWSなどがある。ポータル画面から簡単な操作で、すぐにOpenShift環境を構築・利用できる。
ただし、サービス事業者の管理下にあるため、一般的にMaster Nodeに対するアクセスや、Worker NodeのホストOSに対する操作は制限され、ユーザー操作の自由度が制限される。
日本では開発や運用がアウトソースである場合が多いので、マネージドサービスのほうがより適合する可能性が高い。
自前で構築
オンプレミスやパブリッククラウド上の環境に、管理者自身が必要なモジュールをダウンロードおよびインストールして、OpenShiftを構成できる。
自由度は高いが、構築時や運用時にOpenShiftやLinuxコンテナなどに対する十分な知識が必要である。米国では内製化が進んでおり、継続的なアプリケーション開発・運用を自らのエンジニアリソースで実施していることが多く、これに相当する。
.
OpenShiftのネットワーク
OpenShiftでは、PodはNode外のネットワークに直接接続せず、Node内部の仮想ブリッジに接続する。Podが使用するIPアドレスは、Cluster内のみで使用される。
さらにPodの実IPアドレスは、Podが他のホストへ移動し、再生成されることによって常に変化する。そのためアプリケーションとの通信では、Pod IPアドレスを使った直接通信でなく、Podの存在を抽象化し、Pod IPアドレスを意識せずに単一のエンドポイントで通信を提供する方法が必要となる。
そこで、OpenShiftではServiceという仕組みによりPodの存在を抽象化し、アプリケーションへのアクセスに対して仮想的なIPアドレスを払い出し、クライアントからのリクエストを傍受してPod群へ負荷分散する。いわゆるLoad Balancerのような仕組みを備える。なお、割り振り先となるPodの選出はラベルによって決定する。
Serviceには複数のタイプが存在するが、本稿では主要な以下の3つのServiceタイプを紹介する。
ClusterIP
ClusterIPは、最も基本となるServiceタイプである。Cluster内のプライベートなアドレス空間から仮想IPアドレスを払い出し、Podとの通信に対する単一のエンドポイントとして提供する。Cluster内部の異なるアプリケーション間の通信に利用される。
なお、ここで付与される仮想IPアドレスは、Podに付与されるIPアドレスがPodの再構成に応じて頻繁に変更されるのと異なり、Cluster内で恒久的、安定的に利用される（図表2）。
.
.
またOpenShiftでは、Service生成時にService名と仮想IPアドレスをClusterの内部DNSへ登録する。そのため、クライアントからServiceの名前を宛先としてアプリケーションへアクセスすることも可能である。
NodePort
アプリケーションをCluster外部へ公開する方法の1つである。全Nodeに特定のポートを開き、このポート宛てのトラフィックをCluster内のアプリケーションPodへフォワーディングする。
Nodeの実IPアドレスを使用してアクセスすることが前提となり、負荷分散の機能や可用性が提供されないため、テスト用途など一時利用向けの位置づけになる（図表3）。
.
.
LoadBalancer
Cluster外部のLoad Balancer機能を使用して、Serviceを外部ネットワークへ公開する。パブリッククラウドなどのマネージド環境では、クラウドのNLB （Network Load Balancer） 機能により、外部からアクセスが可能な単一のエンドポイント（IPアドレス）が自動でアサインされ、L4の負荷分散が提供される。
LoadBalancer Serviceを作成することで、当Serviceが利用するポート番号 （NodePort） とIPアドレス （ClusterIP）も自動的に確保される（図表4）。
.
.
クラウドのマネージドサービスではクラウドプロバイダーにより実装されているが、オンプレミス環境の場合、管理者自身で負荷分散の連携を実装する必要がある。
Route
RouteはURLのパスベースのL7負荷分散機能を提供する、アプリケーションのCluster外部への公開方法の1つである。RouteはServiceのように機能するが、正確にはServiceではない。
RouteはクライアントからのHTTP/HTTPSアクセスに対して、URLパスごとに異なるServiceへ転送可能なALB （Application Load Balancer）として機能する。1つのIPアドレスに対して、複数のURLパスで異なるアプリケーションへのアクセスを提供できる。
Routeを使用してアプリケーションを外部へ公開するには、アクセス先のURLパスや分散対象のPod群を指定したRouteリソースを作成する。Routeリソースが作成されると、Cluster上のIngress Operatorというコンポーネントが、その設定をRouter Pod（HA Proxyをベースにした負荷分散機能を提供するPod）へ反映する。
なお、クライアントからRouter Podまでのアクセス手段は別途用意する必要がある。環境ごとに実装は異なるが、Red Hat OpenShift on IBM Cloudの場合、LoadBalancer Serviceにより実現される（図表5）。
.
.
ここまで解説してきたアプリケーションのCluster外部への公開方法について、それぞれの特徴を図表6にまとめた。
.
OpenShiftの実行例
OpenShiftの基本的なネットワーク構造を説明してきたが、ここからOpenShiftのマネージドサービスであるRed Hat OpenShift on IBM Cloud （以下、ROKS）での実装を元に、構成事例をステップごとに分解して解説する。
ステップ1
Clusterの作成
IBM Cloudポータル画面を操作して、ROKSのClusterを作成する。ROKSでは可用性向上のため、複数のデータセンターにWorker NodeをデプロイするMultizone Clusterの構成を取ることが可能で、本事例も2つのデータセンターにそれぞれ1台のWorker Nodeをデプロイしている。
ポータル画面からデプロイ可能なデータセンター（今回はTokyo02、Tokyo04を使用）、Cluster名、Nodeのスペックや台数などを指定してデプロイを行う。
デプロイが完了したら、Cluster内のWorker Nodeのステータスやアドレス情報を確認する。ROKSの場合、各Worker Nodeには、デフォルトでPublic（Global）IPアドレスとPrivate IPアドレスが、それぞれ1つアサインされる（図表7）。
.
.
NodeのRoleが Master／Workerとなっているが、ROKSの場合、ユーザー管理対象はWorker Nodeのみに制限される。
ステップ2
PodのDeployment
OpenShiftではテナント環境の分離やリソース制御などの目的から、アプリケーションのデプロイや各種の作業に対してProjectという作業領域を定義し、そのなかで実行していく。
今回はproject1として新規に作成し、このproject1にPod をデプロイする。例として、レポジトリからWebサーバーとなるNginxというオープンソースが構成されたPodをデプロイする。
オートースケール数として2を設定すると、常に2つのコンテナが実行されるようになる。2つのPodが起動していることを確認し、Podの実IPアドレスとして、172.30で始まるCluster内部のみで使われるアドレスがアサインされていることを確認できる（図表8）。
.
.
ステップ3
LoadBalancer Serviceの作成
先ほど作成したPodを、LoadBalancer Serviceにより外部のネットワークへ公開する例を示す。
最初に、LoadBalancer Serviceの動作や構成を指定する構成ファイルとなるyaml形式のファイルを作成する。
可用性を高めるMultizone Cluster構成にて、LoadBalancer Serviceにより生成されるエンドポイントをそれぞれのデータセンターに配置させたいので、データセンターごとにyamlファイルを準備する。
ここではTokyo2用にnlbv-tok2.yaml、Tokyo4用にnlbv1-tok4.yamlを準備する（図表9）。
.
.
各yamlファイル内の「loadBalancerIP:」には、外部ネットワークからのアクセス先となるエンドポイントのIPアドレスを指定する。ROKSでは、ROKS Clusterの作成時にNLB用に利用可能なPublic IPアドレスが提供されるので、通常はこれを利用する。
LoadBalancer Serviceを作成することで、クライアントからアクセス可能なアドレスである。
http://162.XXX.XXX.172:80とhttp://128.xxx.xxx.92:80のいずれにアクセスしても、最初に作成した2つのNginx Podのいずれかにトラフィックが割り振られる。
なおLoadBalancerを設定すると、NodePortも合わせてアサインされるので（上記の例ではTokyo02:32468、Tokyo04:31792）、Worker Nodeのネットワーク・インターフェースのIPアドレスの対応ポートにアクセスしても、同じ結果が得られる。
ステップ4
Routeの作成
前述したように、アプリケーション公開オプションの1つであるRouteでは、HTTP/HTTPS通信限定にはなるが、URLパスに応じてクライアントからのリクエストがRouteリソースにマッピングしたServiceへ割り振られる。
新規にproject2を作成し、NginxをベースしたPodを1つデプロイする。oc new-app コマンドを利用する場合、ServiceとしてClusterIPが自動的に作成される（図表10）。
.
.
Routeによるアプリケーションの外部への公開は、oc exposeコマンドで実現できる。ROKSでは、Route （ALB） 用にデフォルトでGlobal IPアドレスが確保され、DNSレコードも自動で作成されている。
そのため、クライアントはRoute定義に指定したFQDNで HTTP/HTTPS アクセスが可能である。この例では、nginx-project2.ise-roks-cluster-xxxxxxxxxx-0000.jp-tok.containers.appdomain.cloud へのアクセスとなる。
ROKSを利用の場合、リバースプロクシーのように動作するWebアプリケーション・セキュリティのサービスである、IBM Cloud Internet Service （以下、CIS）と連動させる組み合わせを採用するケースが多い。
CISと連携する場合、CISにユーザー指定のFQDNのCNAMEレコードを登録する。たとえば、FQDNをmywebservice.isenw.comにして、CNAMEにRoute定義に指定したFQDN （上記例にはnginx-project2.ise-roks-cluster-xxxxxxxxxx-0000.jp-tok.containers.appdomain.cloud ）を登録する。
Route定義のHostnameをmywebservice.isenw.comと紐付けることにより、mywebservice.isenw.comでアプリケーションをインターネットへ公開することが可能となる。
以上本稿ではOpenShiftの概要を説明したうえで、OpenShift管理下のアプリケーションをネットワークに公開する仕組みおよび実行例を紹介した。
マネージドサービスの提供が増えつつ、OpenShiftが迅速に利用できる環境として、今後の適用も増えるだろう。今後OpenShiftを利用する際に、本稿での紹介内容を活用いただければ幸いである。
著者｜
陰 蘊霄（YUNXIAO YIN）氏
日本アイ・ビー・エム システムズ・エンジニアリング株式会社?
テクニカル・コンピテンシー ネットワーク
ITスペシャリスト
2016年、日本アイ・ビー・エム システムズ・エンジニアリングに入社。入社以来、ネットワークを中心とした技術支援に携わり、ネットワーク構築などの技術支援活動を行っている。
［i Magazine 2020 Summer掲載］
････････
特集｜OpenShift
Part1 基礎から始めよう、OpenShiftネットワークの概要と活用例
Part2 OpenShift on IBM Cloudを活用した本気の開発環境デザイン
＿前編 提案時の悩み：コンテナ環境向け開発ツールの選定
＿中編 設計時の悩み：開発テスト環境のプライベートネットワーク構成
＿後編 運用時の悩み：OpenShift機能を活用して開発テスト環境へのデプロイを効率的に
Part3 OpenShiftでの最適なバックアップ手法
