ITコラム

OpenShiftとKubernetesの違いと価値

2019年10月30日

カテゴリー ITコラム

記事をシェアする:

KubernetesをベースとするOpenShiftと、Kubernetesの違い、ご存知ですか？

執筆者：高良真穂 ID:maho.takara

日本IBM クラウド＆コグニティブ・ソフトウェア事業本部、「15Stepで習得 Dockerから入るKubernetes」の著者

Kubernetesとは
OpenShiftとは
OpenShiftとKubernetesの違い
まとめ

1.Kubernetesとは

Kubernetes(クーバネティス)は、Dockerコンテナを本番サービスで利用するためのプラットフォームであり、CNCF(Cloud Computing Foundation）が開発を支援するオープンソース・ソフトウェアである。

Dockerコンテナは、可搬性があり、起動が早く、小さなサイズであることから、手軽に開発環境が構築できるために、ソフトウェア開発者の間で注目されてきた。そして、Dockerコンテナをアプリケーションの本番運用にも、そのまま利用したいという自然なニーズに答えたのが、Kubernetesである。Kubernetesは、Dockerのイメージのリポジトリなど実行基盤を利用しながら、本番サービスを運用する上で必要な下記の７つの機能を提供する。

コンテナの組み合わせ利用: Webアプリケーションのコンテナとデータベースのコンテナを連携させてシステムを構築する機能
スケールアウト: クライアントのリクエストによる負荷に応じて、コンテナ数を増減して応答性能の維持と無駄の無いリソース使用とを両立する機能
ロールアウト＆ロールバック機能: 実行中のアプリケーションを停止することなく、最新バージョンへ切り替える機能、そして、問題が発覚した場合に無停止で元のバージョンへ戻す機能
永続ストレージ利用: コンテナはプロセスと同じ一時的な存在なので、停止時にデータが失われることが課題である。そこで、データを保持するためにストレージ装置の論理ボリュームをコンテナにマウントする機能
自己修復（可用性）: コンテナを実行するノード（仮想サーバーなど）が障害停止してコンテナを喪失した場合でも、必要なコンテナ数を維持して性能やシステム構成への影響を最小化する回復機能
クラスタの仮想化: Kubernetesクラスタを論理的に分割して、複数のアプリケーションのサービスを共存、また、開発テストと本番環境を同一クラスタに共存させる。共存環境同士が影響しない様に、リソース使用量の上限を設定して、アクセス制御を強制する機能
監視とログ分析: アプリケーションが稼働状態を見守る上で重要なCPU使用時間、メモリ使用量、通信量などの監視項目をリアルタイムで監視するための機能、アプリケーションやミドルウェアからのログを集中管理するための機能

優れたKubernetesの機能に気づいた企業から次第に参画が始まり、現在500社近くの世界の主要なIT企業がCNCFへ参画する潮流となっている。

2. OpenShiftとは

CNCFが開発を推進するKubernetesは、たくさんの企業が参画して開発を進め、急速に発展している。この活動は、3ヶ月ごとにマイナー・バージョンがリリースされ、リリース後の約9ヶ月間でサポートが終了することから伺い知ることができる。このCNCFが配布するKubernetesは、上流(アップストリーム）のKubernetesと呼ばれ、ソフトウェア・ベンダーが製品化する前の実証試験的なプロダクトと見なされている。

この様な上流のKubernetesの課題を解決に、企業情報システムに適する製品として仕上げられたのが、Red Hat社のOpenShiftである。

3. OpenShiftとKubernetesの違い

OpenShiftは初期の段階では、独自の設計でPaaS(Platform As Service)として開発された。しかし、バージョン3では大幅な改修と共に、Kubernetesをベースとするコンテナ・プラットフォームとして生まれ変わった。そのため、OpenShiftには上流のKubernetesには無い多くの特徴を備えている。そこで、以下にOpenShiftの主な特徴を挙げてみたい。

3.1. OpenShiftは、CI/CDツール環境が整っている

OpenShiftは当初PaaSとして開発された経緯から、Cloud Foundry（旧IBM Bluemix のPaaSエンジン）と同様な機能が備わっている。Ruby、PHP、PythonなどのアプリケーションのソースコードをOpenShiftへ与えることで、OpenShift内部でソースコードやメタ情報などから、適切な実行環境を含むコンテナをビルドして、サービスとして公開するまでの一連の作業を自動的に実行してくれる。これには、簡便なコマンドベースのビルド・パイプラインから、Jenkinsの本格的なビルド・パイプラインまで、開発者のニーズに応じて複数が準備されている。
これまでのレガシーなアプリケーションをコンテナ化するだけではなく、コンテナの利点を最大限活かすには、マイクロサービス化することが良いとされている。しかし、モノリシックなアプリケーションを細分化してマイクロサービス化することは容易では無い。しかし、コンテナ実行環境にCI/CD(Continuous Integration / Continuous Delivery 継続的開発と継続的デリバリー) 機能が備わっていれば、継続的な改善の推進を進めることができる。

3.2. OpenShiftには、長期のサポートがある

Kubernetesが幾ら優れていても、9ヶ月以内にバージョンアップが必須という安定しないプラットフォーム上に、企業の本格的なアプリケーションを構築して運用するにはリスクが大きい。例えば、頻繁にプラットフォームのバージョンアップに伴いKubernetesの仕様やAPIが進化するだけでなく、廃止や置き換わる機能もある。しかも、ドキュメントなども必要最小限となり、脆弱性やバグなどの情報も開発チームのIssueトラッキングのシステムから読み取らなければならない。この様なプラットフォームで運用を推進するには、高度なスキルが必要とされる。
一般的なユーザー企業でのKubernetesの運用を現実的なものとするために、OpenShiftのユーザーは長期間の保守サービスを受けることができる。例えば、OpenShift バージョン3.11のベースとなっているKubernetes バージョン 1.11は、既にCNCF Kubernetesプロジェクトのサポートが終了しているが、OpenShiftでは延長サポートの終了を 2024年6月としている。
この様な長期間のサポートが可能になるのは、Kubernetesのソフトウェア開発を推進するデベロッパーをRed Hat社から数多く輩出しているためだからこそ可能となると考えられる。

3.3. OpenShiftは、脆弱性対応など企業向けセキュリティが強化

オープンソース活用の課題として、脆弱性対応の課題は極めて重要である。脆弱性とは、プログラムの動作の不備を悪用される情報セキュリティ上の弱点である。つまり、ソフトウェア上の問題が原因となって生じた欠陥であり、セキュリティ・ホールとも呼ばれる。当然、ソフトウェア開発者は、脆弱性を産まないように細心の注意を払ってコード開発を進めるが、開発者が利用するオペレーティング・システムのライブラリやパッケージに含まれることもある。そのような事情から、開発者の責任範囲外に原因がある場合も多くある。

ソフトウェアの脆弱性は、絶えず調査と改善対応が進められ、新たな脆弱性が発見されると、米国政府が支援する国際的機関によってCVE番号が採番され、標準を定めるNIST(National Institute of Standards and Technology; アメリカ国立標準技術研究所）が運営するNVD(National Vulnerability Database)に重要度が評価されて登録される。つまり、一度モジュールの脆弱性を検査して問題がないと判断されても、時間の経過とともに、次々に脆弱性は発見されるため、いつ迄も安全という訳ではない。もし、脆弱性対応を放置すれば、不正アクセスや情報漏洩の原因となることが懸念されるため、出来るだけ早く対応することが望ましい。

この様な背景の中、Red Hatでは、政府機関や一般企業でのLinuxの活用推進のため、Red Hat CVE Database、Red Hat Security Advisoriesなどの活動を通じて、脆弱性の発見と対応に力を注いでおり、セキュリティの国際的機関と連携して対応を進めている。RHEL(Red Hat Enterprise Linux)では過去、重大な脆弱性が発見されてから、対応する修正プログラムを提供するまでの時間が、24時間以内となるものが殆どあるという実績がある。

当然、コンテナにおいても、Linux OSなどのパッケージが数多く含まれ、脆弱性検査と対応の対象となる。Red Hatから提供される「Red Hat認定コンテナ」は、Kubernetesでコンテナのアプリケーションを運用する上で、最高水準の脆弱性対応を受けることができる。