第5回 『Red Hat OpenShift と Kubernetes の違い』

記事をシェアする:

こんにちは、Red Hat のSolution Architect の花田です。普段は OpenShift の提案サポートやエバンジェリスト的な活動として講演を行ったり、記事を執筆したりしています。

今日は、ご質問の多い「Kubernetes と OpenShiftは何が違うの？」という質問について解説したいと思います。

OpenShift にご興味が無い方でも、Kubernetes をエンタープライズ環境で使用するには、どのような考慮が必要なのか、ポイントの整理になれば幸いです。

 

OpenShift とは

Kubernetes 自体は、誰でも使用できる Open Source である一方で、企業ユースで Kubernetes を使用するには、いろいろと選択が必要になります。この「選択」は、製品のコンポーネントの選定と、Open Source 製品のサポートをどうするのか。という、機能要件、非機能要件の両方に及びます。

図1. Kubernetes と OpenShift Container Platform のパッケージの違い

OpenShift は、Kubernetes の本体に、Kubernetes の本体だけでは不足している機能や、コンテナの開発・運用に必要になるツールとサポートを追加したもの。と言う説明がよくなされます。が、ここではもう少し、具体的に解説していきたいと思います。

尚、OpenShift と一口に言った時に、OCP (OpenShift Container Platform) と、OKE (OpenShift Kubernetes Engine) の2種類のパッケージがあります。OKEは、OCPのサブセットですが、本文中では OCP (OpenShift Container Platform) を前提に記述しています。

 

Kubernetes を使用する際に求められる選択肢

Kubernetes をインストールしただけでは、多くの場合Kubernetes を使いはじめる事はできません。Kubernetes では、ユーザーの選択肢を広げるために、Kubernetes とのインターフェイスだけを定義して、幾つかの基本機能を外出しにしている部分があります。

例えば、Kubernetes クラスター内で使用される Pod (Kubernetes上でのコンテナの実行単位) の間の仮想ネットワークを作る仕組みは、Kubernetes には含まれていません。Kubernetesでは、CNI (Container Network Interface) という仕様が公開されているので、その仕様にあったソフトウェアをユーザーが選択する必要があります。CNIというインターフェイスに対応していれば、Kubernetes に差し込んで使えるので「CNI プラグイン」という言い方もされます。

図2. Kubernetes の CNI Plugin の選択

Kubernetes の公式ドキュメントには、CNIに対応したプラグインがリストされています。

ここで CNIプラグインとして公開されているソフトウェアも Open Source でサポートが基本的にコミュニティによるサポートであるものから、プロプライアタリでしっかりした企業サポートが付いているものまで、複数の選択肢があります。

また、CNIに対応している。という最低ラインさえ守れば、追加で独自の機能を搭載する事も可能です。そのため同じ CNIプラグインでも細かな機能差がある場合があります。

他にも Kubernetes を使用する上で、ユーザーが選択しなければいけないものとして、コンテナを実行するためのランタイムがあります。

コンテナのランタイムは、コンテナを作成、管理するための基本的なソフトウェアです。Docker が有名ですが、現在では特定のベンダーに依存しないように仕様が標準化され、複数の選択肢が存在します。

図3. コンテナ・ランタイムの選択

コンテナ・ランタイムは正確には、CRI (Container Runtime Interface) と OCI (Open Container Initiative) Runtime の2種類があり、これらのコンテナのランタイムも、前述のCNI 同様に、設計時にユーザーが選択する必要があります。

さらに機能だけでなく運用のサポートまで考慮しなければいけないとなると、こういった選択を自力で行う事は難しいものです。自分の要件にあったコンポーネントを組み合わせていき、それぞれのベンダーサポートも得ようとすると、幾つもの異なるベンダーからサポートを得る必要が出てきます。

もし、Public Cloud ベンダーが提供するKubernetes のManagedサービスを使用すれば、その部分はサービス提供者が管理してくれる事になります。もしくは、Red Hat OpenShift 等のあらかじめ選択されたものがパッケージされ、サポートも付いているエンタープライズ向けの Kubernetes ディストリビューションを使用する事で、こうしたやっかいな選択をベンダーにまかせる事が可能です。

 

コンテナのための開発・運用ツール

Kubernetes は仮想化インフラのツールに分類されると思いますが、Kubernetes の上では仮想マシンではなく、コンテナが稼働する所が、大きく異なります。

コンテナの大きなメリットは、小さなサイズを生かした開発速度です。コンテナではユーザーが作成したプログラムと、ベースとなるコンテナのイメージを合わせて新しいイメージを作成する「ビルド」という作業が必ず必要で、さらに「ビルド」したイメージはKubernetes 上に「デプロイ」する必要があります。実際には他にもビルドしたコンテナをテストしたり、ビルドが完了したコンテナ・イメージを、レポジトリに「PUSH」したり、他にもこれに付随する典型的な作業が存在します。

このように、コンテナが作成されてKubernetes 上にデプロイされるまでの作業は、開発者が単純に手元でコンテナを実行するのに比べて、意外に複雑です。

コンテナ化のメリットを存分に生かすには、これらの作業を自動化するCI/CDツールが不可欠とされています。が、Open Source の世界には、無数のCI/CDのためのツールが存在しています。そのため、ここでも「選択」の問題が発生します。

OpenShift では、CI/CDツールとして Tekton と Argo CDをベースにしたアプリケーションがバンドルされ、サポートと伴に提供されています。

図4. OpenShift Container Platform に付属する、Open Source の運用ツール

他にも運用に必要な、監視ツールや、ログ収集ツールが付属しており、コンテナ環境を構築するためのソフトウェアがあらかじめバンドルされています。例えば、アプリケーションを開発していて、「Service Mesh を使いたい」となった場合は、「OpenShift Service Mesh」が使用できます。

 

コンテナとコンテナを動かすためのＯＳのサポート

Kubernetes は、ソフトウェアです。ソフトウェアを動かすには、もちろんOSが必要です。

最近は、Windows 用コンテナの開発が進み、Windows OSも(Windows)コンテナのホストOSとして選択する方法も選択肢として出てきつつあります。

OpenShift では、Windows OSを Worker Node として使用する事もサポートされていますが、現時点では一般的にLinux が コンテナの ホストOS となるでしょう。

このLinux ホストOS上で Kubernetes や前述したコンテナを稼働させるためのソフトウェアであるコンテナ・ランタイム等が稼働するわけですが、Linux OS そのものはKubernetes のパッケージに含まれていないので、どのディストリビューションのLinux OSを選択するかも、Kubernetes の設計時に考える必要があります。

また、前述したように、自分のコンテナを作成するには「ベース・イメージ」を使用して、必要なアプリケーション用のライブラリと、自分で書いたアプリケーションのコードを合わせて新しいイメージを「ビルド」します。

インターネット上には「ベース・イメージ」となる、様々な Linux OSのイメージが出回っています。が、企業ユースで使用するにはインターネット上にある出所不明の”野良イメージ”ではなく、きちんとメンテナンスがされており、マルウェアも含んでない事が保証された「ベース・イメージ」を選択する必要があります。

Red Hat では、UBI (Universal Base Image) と呼ばれる、コンテナの「ベース・イメージ」をDocker Hubや、Red Hat Ecosystem Catalog上で配布しています。この記事を執筆している時点で、 RHEL7とRHEL8 UBIイメージが提供されており、それぞれにUBI (Standard)と UBI Minimal, UBI Init, UBI Micro の4種類が存在しています。

通常使用では、この UBI 「ベース・イメージ」は無償で配布されているだけで、サポートはありませんが、エンタイトルメントを持ったRHEL もしくはOpenShift 上で使用した場合は、サポートが提供されます。

また、実際のコンテナの開発では、「ベース・イメージ」だけでなく、アプリケーションの開発のためのミドルウェアも必要です。

こちらも、企業ユースとなると「ベース・イメージ」と同様に、きちんとメンテナンスされており、マルウェアを含んでない事が保証されているものを使用する必要があります。

OpenShift では、Perl, PHP, Python, Ruby等の言語ライブラリや、MariaDB、MongoDB, MySQL, PostgreSQL等の Database、Nginx, Apache 等 Web Server 等の基本的な ミドルウェアが使用でき、UBIにこれらのエンタイトルメントを持ったコンポーネントを追加したイメージも、もちろん(ユーザーが作成したコード部分を除いて) サポート対象です。

図5. OpenShift とUBIベース・イメージとミドルウェア(ライブラリ)

コンテナ環境は、コンテナ単位で仮想化され、個々に独立した Linux 環境と言う事ができます。そのため、コンテナの開発・運用では、きちんとメンテナンスされたOSとミドルウェアが必要で、基本的な条件はLinux 環境でのアプリケーション開発と同じです。

OpenShift では、Red Hat がRed Hat Linux Enterprise Linux で提供してきた技術スタックをOpenShift でも同様に提供しているため、安心して Linux コンテナの開発に集中する事が可能です。

 

実運用で使用するために拡張された機能

Kubernetes のコア部分は、シンプルな作りになっており、実運用ではいろいろな機能を運用担当者が追加しているケースがあります。

Red Hat では Community を通じて Kubernetesにエンタープライズの運用で得た知見を元にしたフィードバックを行うのと並行として、OpenShift 独自の機能ももっています。

Kubernetes は基本的に 「Resource」という概念の集合体で構成されており、機能を追加したい場合は、「Custom Resource」の定義を追加する事で機能を拡張できるように、設計されています。OpenShift もこの「Custom Resource」の定義 (CRD: Custom Resource Definition)を追加する事で、Kubernetes の機能を拡張しています。

これらの機能拡張は、あまりに多岐に渡るため、ここではごく一部だけご紹介します。

 

Project / Template

OpenShiftでは、Kubernetes のnamespace の拡張機能である、project という概念を導入しています。

この project は、一見するとKubernetes 標準の namespace と変わらず、namespace オブジェクトとしても参照できる (kubectl get namespace で、project の一覧がリストされます)ため、一見すると違いがわかりません。そのため、project = namespace と考えても、通常は問題ありません。

一方で、project では、template という概念が使えるようになっています。

図6. OpenShift の Project と Template

この template に、project 内で許可するLimitRange (その project内で Pod が使用できるCPU/Memoryリソースの制限) や、NetworkPolicy (他のproject へのネットワーク・アクセス制御) と言った Kubernetes の設定を記述する事で、project が作成された時に、基本的な設定が適用された状態にしておく事ができます。

また、OpenShift では、このtemplate を使って、project を作成したユーザーが、このproject の管理者になるように、必要な権限が自動的に構成されます。そのため、一般のユーザーは、他の人が作成した project にアクセスできなくなっています。

 

SCC (Security Context Constraint)

コンテナは、ひとつのLinux OSカーネルを複数コンテナ間で共有するアーキテクチャーです。そのため特権を持つコンテナが存在すると、その気になれば他のコンテナに対して干渉を行う事が可能です。

OpenShift では、SCC (Security Context Constrain) という機能がデフォルトで有効化されており、例えば root 権限を持ったユーザーのコンテナは、デフォルトのOpenShift 環境では実行できなくなっているなど、権限が厳密に管理されています。

SCC では、OpenShift管理者の利便性を考え、デフォルトで 権限の異なる8つの雛形が用意されています。

図7. OpenShift のデフォルトで用意されているSCC (Security Context Constraints)の種類

OpenShift のデフォルトでは、”restricted” と名前が付けられた SCC が、ユーザーが作成した Pod に適用されるようになっています。そのためユーザーのPod は、root 権限が必要な操作は実行できませんし、 Host OSへのアクセスももちろんできません。SELinux も有効になっています。とは言え、通常のアプリケーションであれば、問題の無い十分な権限が与えられています。

コンテナのアーキテクチャー上、Linux カーネルをシェアする事が前提である事を考えると、エンタープライズの環境では、不必要に強い権限を持ったコンテナが稼働している事は、大きなセキュリティ・リスクです。脆弱性を突かれてコンテナが乗っ取られた場合は、仮想マシンと違い、Kubernetes クラスター全体がリスクにさらされます。デフォルトで妥当な制限をかけておき、必要なものだけ強い権限を与える対策が妥当でしょう。

また、Kubernetes クラスターの作成後、暫くしてからセキュリティを厳しくするアプローチは、既存のコンテナが動かなくなる可能性があり、大変な作業になってしまいます。OpenShift では、このような事がないように、OpenShiftクラスター・インストール完了時に、既にSCCが有効になっており、OpenShift を構成する Pod (OpenShift 自体が Pod の集合体です)も、このSCCに従って稼働しています。

尚、Kubernetes では、SCCとよく似た PSP(Pod Security Policy)という機能が存在します。Cloud Provider の Kubernetes の Managed サービスや、エンタープライズ環境で既に広く使われていますが、デフォルトでは有効にされていないため手動で有効にする必要がありました。

PSPは長い間、ベータ機能だったのですが、2020年8月に導入された「ベータ機能は3リリース後には、ベータを卒業してGAにするか次のベータバージョンに移行する事」というKubernetes の新しいポリシーの導入もあり、 最終的にKubernetes 1.21 (2021年4月リリース)で非推奨(deprecated)になる事が発表されました。

現在は、PSPの後継となる新しい機能の開発が、アルファ機能という形で進んでいる状態になっています。

 

Egress Router Pod / EgressIP

「Egress Router Pod」と、「EgressIP」は、Pod(ユーザーのアプリケーションが、OpenShift クラスター外部に通信する際に、Source IPを固定する機能です。

Podは任意のIPアドレスを使って起動し、どのNode上に生成させるかは基本的に決まっていないため、通常 IPアドレスは固定されませんが、この機能を使う事で、Source IPを固定する事ができます。

図8. OpenShift の Egress Router Pod と Egress IP

現在、OpenShift では、2種類の CNIプラグインを選択して使用する事ができます。つまり2種類の仮想ネットワークをサポートしています。

一つは独自実装の OpenShift SDN で、もう一つが Open vSwitch コミュニティによって開発されているOVN (Open Virtual Networking)です。後者は、OpenShift のマニュアル上はCNIプラグイン用のレポジトリ名を取ってOVN-Kubernetesと呼ばれています。”EgressIP” は、OVN-Kubernetes が提供するCustom Resourceと呼ばれる機能拡張で、OVN-Kubernetes を使用した時だけ使用可能です。

もう一つの “Egress Router Pod” は、どちらのCNIプラグイン環境でもサポートされている OpenShift 独自の機能で、独自のコンテナ・イメージが クラスター外部への出口として機能します。よりできる事が豊富ですが、環境によってサポートされる機能が違うなど、できる事に細かな違いがあります。

どちらの機能も AWSや、Azure 等のPublic Cloud の環境ではサポートされておらず、他にも細かな動作条件があります。ここでは、説明のために簡略化して書いていますので、詳細は OpenShiftのマニュアルを参照下さい。

(尚、OpenShiftSDN を使用した場合は、上記で紹介した機能以外にも、さらに”NetNamespace” リソースを使用して Egress IP を指定する方法があります。この方法は、Public Cloud 環境でも使用する事も可能です。)

 

Over The Air Update

OpenShiftのバージョンは、コアとなる Kubernetes のバージョンがアップデートされると、それを追う形で、最新バージョンを含んだ OpenShift の新バージョンをリリースするようになっています。

基本的な方針として Kubernetes は、1年に3回のリリースが行われています。

比較的更新の速いKubernetes のリリース・サイクルに対応するためには、簡単にクラスターをアップデートできる事が望ましいです。 Kubernetes では、コンポーネント毎にバージョンの依存関係があるので、その依存関係を把握した上で手順を守って、各OSノードにログインし、コンポーネントのアップデートしていく必要があります。

OpenShift が提供する Over The Air Updateでは、アップデートが可能なバージョンのパスをユーザーに提示してくれ、選択してクリックするだけで簡単に OpenShift クラスター全体のアップデートを行う事ができます。

図9. OpenShift の OTA (Over The Air Update)

管理者の作業端末にインストールされるクライアント用のコマンド (kubectl等のコマンド) 以外のサーバー側のコンポーネントのアップデートは全て OpenShift 側で管理してくれます。ユーザーがアップデートを行うためにする事は、OpenShift Console 上のボタンを押すか、コマンドを管理端末から実行して待つだけです。個々の OS Node にログインしてコマンドを実行する必要はありません。

また、OpenShift は、デフォルトで CoreOS というコンテナ専用のOSを採用しており、OpenShift (Kubernetes) のアップデートとリンクして、Host OSであるCoreOSのアップデートも行われるようになっています。

図10. Over The Air Update で更新される部分

一応、ホストOS として、RHELもサポートされています(原稿執筆時点で RHEL7のみ)が、Over The Air Update では管理できないため、別途、運用管理を設計する必要があります。また、通常のLinux OSには、コンテナ実行には必要ないコンポーネントがたくさん含まれており(カーネル以外の必要なライブラリはコンテナ側に含まれるので)、セキュリティ・リスクも高くなります。

RHEL のホスト OSとしてのサポートは、あくまで、特殊な理由でコンテナ化できないアプリケーションをどうしても、OpenShift と一緒に使いたい。と言う要件のために残されています。

CoreOS を使用して、Kubernetes 層と一緒にNode のOS層も管理する事で、大幅に運用の負荷を下げる事が可能です。また、Node の追加時も、OpenShiftが他の Node と同じ構成に自動で構成してくれます。

 

コミュニティと並行した独自機能開発

Kubernetes で開発中のある機能をエンタープライズ環境で使用したいが、まだ機能不足・不安定であると言ったケースや、必要な機能が存在していない。という事がありえます。

Red Hat社も Kubernetes コミュニティの最も大きなコントリビューターの一つですので、Red Hat 社からコミュニティにフィードバックする事で、それらの機能が Kubernetes 本体に取り込まれる /改善される事があります。

OpenShift 等で開発された独自機能が Kubernetes のアップ・ストリームに反映され、OpenShift も、アップ・ストリームの仕様にアラインしていくというのが理想的な流れだと思います。RBAC (Role Base Access Control) はRed Hat の提案がそのまま、コミュニティに受け入れられた例の一つです。

一方で、コミュニティの運営は特定のベンダーがコントロールするものではないため、多種多様のステーク・ホルダーの要求が上手くまとまらないケースや、開発スピードが必ずしもエンタープライズ側の要望に合わないケースもありえます。

例えば Kubernetes では、L7 （HTTP/HTTPS）のトラフィックを処理するリソースとして、 Ingress リソースと呼ばれるものが定義されています。現在では殆どのアプリケーションが HTTP/HTTPS での通信を前提としており、Ingress リソースは、Kubernetes の中でも重要なコンポーネントの一つと言えるでしょう。

OpenShift がコンテナのアプリケーションを外部に公開する仕組みが必要だと感じた時には、まだIngressが存在していませんでした。

そのため Routeというリソースが開発され、現在でもOpenShift では、Ingress の代わりに Route がデフォルトで使用されています。Routeは、Kubernetesの Ingress のデザインに大きな影響を与えたとされています。

図11. OpenShift Route リソース

Ingress リソースは2020年8月に Kubernetes 1.19でGAされるまで、長い期間ベータのままでした。Kubernetes では、Ingress リソースを処理するためのアプリケーション・コンポーネントを Ingress Controller と呼んでいます。

Ingress リソースを処理するためのIngress Controllerは、Kubernetes本体には含まれておらず、ユーザーが3rd Party が提供する Ingress Controllerから選択し、Kubernetes に組み合わせる必要があります

現在では、独自に仕様拡張された Ingress リソースを処理するための様々な Ingress Controllerが開発されており、Ingress リソースと一口に言っても、開発元毎に様々な拡張機能を持つようになっています。

これらの Ingress の機能拡張は、Kubernetes で共通仕様として決められているフィールドではなく、 annotations と呼ばれるコメント等を記載するフィールドに、ベンダー独自の文字列を記述し、それを各ベンダーの Ingress Controller が解釈する事で実現されています。Ingress によっては、annotations に指定できる値が大量にあり、これらの annotations に大きく依存する使い方をし始めると、他の Ingress Controller への移行は事実上困難になりえます。

こうした背景が、Ingress Controller の選択を悩ましいものにしてます。そのため、現在、Ingress をさらに進化させたリソースとして Gateway API の開発がはじまっています。

OpenShift では、デフォルトで Route リソースが使われるようにできているので、おすすめは Route ですが、標準のIngress リソースも使用する事ができます。

理想的には、Kubernetes の統一仕様に沿っていく事が、継続的、安定的な運用の観点で望ましいですが、歴史的に多様化した技術仕様を一つにまとめるのが難しく、時間を要する事もあります。現実的な選択肢として、アップ・ストリームが安定するまでは、一部のコンポーネントに関してはベンダー依存の規格に戦略的に依存する事も必要になってくると思います。

このように、OpenShiftは、コミュニティによって開発されている、変化が激しく予測がしにくいソフトウェアを、エンタープライズ・ユーザーが安心して使えるように、独自の代換え機能を提供している場合があります。

 

エンタープライズ環境でも安心してコンテナ運用を

今回は、OpenShift と Kubernetes の違いについて簡単にご紹介しました。OpenShift は、エンタープライズ環境で、できるだけ簡単に Kubernetes を使ったコンテナ運用をはじめられるためのプラットフォームです。

OpenShift は、オンプレ環境だけでなく、IBM、AWS、Azure、GCPをはじめとするクラウド環境上にもインストールする事ができますし、マネージド・サービス版も提供されています。

Kubernetesとコンテナは、習得するのにかなりの労力を要するのが現状ですが、OpenShift であれば、どのような環境で使用しても、基本的に同じ OpenShift で、その知識は環境に依存せず持ち越して行く事ができます。

エンタープライズ向けにKubernetesを使ったコンテナ運用環境を作成したい。という最初の一歩としては、非常に良い製品だと思いますので、是非、ご検討してみて頂けると幸いです。