IBM Developer Japan Webサイトは2021年3月15日をもって終了となり、日本語コンテンツの一部は、オープンソースとして、提供予定です。 URLはこちら

KubernetesとOpenShift: 違いは何ですか?

皆さんこんにちは。IBM CloudチームのSai Vennamです。今回はKubernetesとOpenShiftについてお話しします。

この2つを直接比較するのは正しくないかもしれません。Kubernetesはオープンソース・プロジェクトであり、OpenShiftはRed Hat社の製品だからです。実際のところOpenShiftはOKD、つまりOrigin Kubernetes Distributionを採用しています。

alt

Kubernetes以外にも複数のオープンソース・プロジェクトが含まれています。そのためKubernetesやDockerなど、好みのコンテナー・ランタイムを利用できます。

alt

サービスメッシュ機能を活用したい場合は、Istioなどのさまざまなオープンソース・プロジェクトとの統合も可能です。

alt

[アプリケーションのデプロイにおける相違点]

それではいくつかの相違点を見ていきましょう。Kubernetesで実行する場合とOpenShiftを使用する場合とでアプリケーションの操作がどのように違うかをご説明します。まずアプリケーションのデプロイについて考えてみましょう。

alt

Kubernetes

Kubernetesでアプリケーションをデプロイするには若干手間がかかります。例えばGithubなどにコードをアップロードしているとします。そのコードを自分のローカル・マシンに取得しコンテナーを起動します。

alt

コンテナーを用意したらそれをホストする場所を考える必要があります。レジストリーです。例えばDocker Hubなどを使用できます。専用レジストリーを使用したい場合はそれを構築する必要があります。

alt

マネージドKubernetes、ご使用のクラウド・プロバイダーのKubernetesを利用する場合は、一般的にレジストリーまたは専用レジストリーを使用できるオプションがサービスに用意されています。

alt

コンテナーをレジストリーに配置したら、実際にCI/CDパイプラインを構築する必要があります。ここで作業が複雑になります。アプリケーションのデプロイには多数のオプションがあるからです。

alt

OpenShift

一方でOpenShiftのアプローチは一貫しています。必要な作業はアプリケーションやプロジェクトの作成のみで、複雑な作業はOpenShiftがバックエンドで行います。パイプラインの作成はもちろん、アプリケーションの開発、テスト、実装といった一連の作業が自動化されます。

alt

これで作業はずっと楽になりJenkinsアプローチや、ソース・イメージの機能を使用してデプロイを開始できます。

alt

ただし柔軟性という観点ではKubernetesがはるかに優れています。固定化された所定の方法がないからです。

レガシー・アーキテクチャーに影響されるパワー・ユーザーや、チームにとっては、Kubernetesの方が効果的でしょう。すべての手順について指示を必要とし、DevOpsおよびパイプライン・アプローチが整備されているチームにとっては、OpenShiftを使用する方がはるかに簡単です。

alt

[アプリケーションの管理における相違点]

Kubernetes

まずKubernetesでのアプリケーションの管理から見ていきましょう。管理にはKubernetesのディストリビューションに付属している標準のダッシュボードを利用できます。ただし残念ながら大半の運用チームにとってそれだけでは不十分です。さらに一歩進めて追加のダッシュボードをインストールする必要があります。

alt

ELKスタックなどの使用も考えられます。あるいはGrafanaやIstioなど、さまざまな選択肢があります。それぞれのユースケースに最も適したソリューションを見つけるには 詳しい調査が必要になります。

alt

OpenShift

一方OpenShiftでは、管理においても適切な所定の方法があります。さらにKubernetes APIを基盤とする優れたWebコンソールがあり、SREおよび運用チーム向けにワークロードを管理するためのさまざまな機能が付属しています。

alt

先程のダッシュボードも所定の一貫した方法で操作します。OpenShiftではEFKスタックを推奨しており、ユーザーの希望に応じてさまざまな方法でIstioなどの機能を組み込むことができます。

alt

その場合も自動インストーラーやAnsibleプレイブックを、活用することでアプリケーションの管理が多少簡単になります。ただし所定のアプローチに従うため柔軟性はいくらか低下します。

alt

[ノードの構成と運用]

次にノードの構成や毎日の運用について見ていきましょう。クラスターは複数のVMで構成され、クラスター内には仮想マシンかベアメタルかを問わず、いくつかのVMが配置されています。

alt

Kubernetes

KubernetesでクラスターにVMを追加するには時間がかかります。自己登録や異なるクラウド・オートメーションを設定し、新規VMを作成してクラスターに追加する必要があります。そのために時間を要し、スクリプトも作成しなければなりません。

alt

OpenShift

OpenShiftでの作業はもう少し簡単です。クラスターへの新規VMの追加にはAnsibleプレイブックやインストーラーを使用します。プロセスが非常にわかりやすく、負荷に応じてVMの自動スケーリングや高速化も行えます。

alt

[セキュリティー]

最後にセキュリティーについてお話しします。OpenShiftとRed Hatはオープンソース・コミュニティーが解決できていないギャップの解消に努めています。そのために企業のお客様と連携して最適なセキュリティー・プラクティスを一から作成しています。またお客様がKubernetesを使用するにあたって直面している問題にも対処しています。違いをいくつか見ていきましょう。

alt

Kubernetes

Kubernetesではプロジェクトに1人で取り組むことはおそらくないでしょう。数人で構成されるチームがあり、各チームに異なる権限が必要です。

alt

元々KubernetesにはOpenShiftに実装されているRBACなどはありませんでしたが、今ではKubernetesでもRBACが当たり前になっています。KubernetesはIAMなどを実行できるその他の機能も実装しようとしていますが、それには時間と労力を要します。

alt

OpenShift

一方OpenShiftでは、すべてがすぐに使える状態になっています。プロジェクトを作成するとすべての機能を利用でき、必要な作業はユーザーの追加だけです。OpenShiftはKubernetesの名前空間や、ベスト・プラクティスを使用した、さまざまなセキュリティー・ポリシーの策定にも対応します。すべての機能を最初から利用できますが、多少の制約も伴います。

alt

[制約]

例えばKubernetesではDocker Hubからイメージを取得できそのイメージは期待どおりに動作します。しかしOpenShiftでは権限が制限されているため、コンテナーはルートとして実行されません。このためイメージが期待どおりに動作しない場合があります。

このように、最初から組み込まれているセキュリティー・ベスト・プラクティスを利用するうえで、小さな妥協点があります。これらのバランスを考慮する必要があります。

要するにOpenShiftは、汎用的ですべてに対応できるソリューションではないのです。OpenShiftで採用されているKubernetesの基本的機能を理解することが非常に重要です。個人ユーザーや小規模なITチームはOpenShiftを使用すると非常に複雑なタスクの多くを効率化できます。

最後までご覧いただきありがとうございました。