Kubercon 2017より - KubernetesとOpenShiftについてBrian Gracely氏に聞く

テキサス州オースチンで先日閉幕したKubeconには、4,000人を越えるエンジニアが参加し、Kubernetesで埋め尽くされた。

InfoQはRed Hat Openshiftで製品戦略担当ディレクタを務めるBrian Gracely氏に会い、製品の方向性を決める上でのKubernetesの役割、開発者やアーキテクトとの関係などについて聞いた。

InfoQ: Kubeconの参加者数は前例のないものでしたが、Red HatがOpenShiftの基盤としてKubernetesを選択したのは、最近のことではありません。OpenShiftの簡単な歴史と、Kubernetesをどのように活用しているのか、説明して頂けますか？

Brian Gracely: 2015年までのOpenShiftは、他の大部分のPaaSプラットフォーム(Appenda、dotCloud、Cloud Foundry、Herokuなど)と同じように、標準化されていない、独自開発のコンテナオーケストレーション上に構築されていました。Red Hatは経験から、広範なコミュニティのサポートがなければ、この種のテクノロジを革新し維持することは非常に難しいことを理解しています。ですから、2014年にGoogleがKubernetesプロジェクトに関してRed Hatにアプローチした時、そのプロジェクトとコミュニティの構築を支援する機会を得られたことについて、大変うれしく思いました。当時私たちは、2013年からすでにDockerプロジェクトに深く関わっていましたから、これはOpenShift v1とv2の独自開発のコンテナテクノロジから、OpenShift v3.0でのDockerとKubernetesのフルサポートに移行するための、次の論理的ステップだったのです。Red Hat OpenShiftは、これらの標準をサポートした最初のエンタープライズプラットフォームであり、Red Hatはプロジェクトにとって２番目に大きなコントリビュータです。それ以来、当社はKubernetesのリーダシップ/運営グループに深く関与するとともに、Kubernetsの12のSIGで議長ないし共同議長を務めています。さらに当社は、コンテナのフォーマットとランタイムを標準化するOCIプロジェクトでも最大のコントリビュータとなっています。

InfoQ: 実装面においては、OpenShiftとKubernetesとの総合的なシナジはどのようになっているのでしょう？

Gracely: Red HatがOpenShift(プラットフォーム)に関して行うことは、すべてKubernetsプロジェクトを起点としています。ですからシナジは100パーセント、ということになります。OpenShiftはKubernetesの認定を受けています。当社はKubernetesの上流作業から関与しており、他のテクノロジ(SDNネットワーキング、ストレージ、監視、コンテナレジストリ、コンテナへの要件(セキュリティやHWサポートなど)、CI/CDとの統合など)と幅広く統合しています。そこから生まれたのがOpenShift Originプロジェクトです。OpenShift OriginはLinuxでのFedoraプロジェクトのような位置付けで、その商用バージョンがソフトウェア(OpenShift Container Platform, OCP)およびマネージドサービス(OpenShift DedicatedとOpenShift Online)として提供されています。

InfoQ: Kubernetesはしばしば、プラットフォームを構築するためのプラットフォームとして特徴付けられます。Helm chartやIstio、KubeFlowなどの実例もたくさんあります。OpenShiftも同じようなアプローチで他のオープンソースプロジェクトを活用するのでしょうか、あるいは違う考え方なのでしょうか？

Gracely: OpenShiftはモジュール化された、構成可能なプラットフォームです。デフォルト機能は添付されていますが、ユーザや技術パートナが(SDNネットワーキング、ストレージ、監視などを)別の選択肢に置き換えることも可能です。300社以上のOpenShiftプロバイダが、100以上のテスト済みインテグレーションを提供しています。プラットフォームとしてのOpenShiftの歴史を考えると、Kubernetesやその他のオープンソースプロジェクトを通じて利用可能になるよりも前に、機能を実装していることが少なくありません。例えばRBACは、まずOpenShiftで利用可能になってから、Kubernetesに移植されたものです。アプリケーションテンプレートも、Helmプロジェクトよりも前からありました。OpenShiftの実装がKubernetesに移植された例(RBACなど)もありますし、OpenShiftのオプションとして新たな機能が追加される場合(HelmあるいはPrometheus)もあります。さらにRed Hatは、Istioやサーバレスプロジェクトといった新しいプロジェクトの発展と統合、さらにはパフォーマンス重視アプリケーションのように新たな重点領域にも、積極的に関与しています。

InfoQ: 企業で主にレガシアプリケーションの開発に従事している開発者やアーキテクトにとって、そもそもOpenShiftは関係のあるものなのでしょうか？

Gracely: おそらくOpenShiftユーザの半数以上は、既存のアプリケーションの現代化やアプリケーションのOpenShiftへのリフト・アンド・シフトを行っている人たちです。Barclays Bank、Deutsche Bank、Disney/Pixar、Inmarsat、Keybank、Optum/United Health Group、SKY TV、Volvo、Verizon、Telusなどがそうですし、他にもたくさんあります。アナリスト企業のIDCによる検証では、これらのマイグレーションによるROIは、ビジネスに大きな価値をもたらしています。

コンテナとKubernetesは、あらゆる用途に数多くの、価値ある概念を提供します。コンテナは、開発、テスト、Q/A、ステージング、運用で動作するアプリケーションをパッケージングするための、一貫した手段を提供します。コンテナによって得られる不変性により、オペレーションチームによるセキュリティアップデート方法の簡略化や、クラウド環境間における一定水準のポータビリティが実現されます。KubernetesとOpenShiftのようなプラットフォームによって、(マルチクラウドのように)あらゆるクラウド環境にわたって一貫性のある、自動化された、スケーラブルな環境が実現するのです。

InfoQ: PaaS分野でのパイオニアはHerokuでした。大部分のPaaSはステートレスアプリケーションを指向しています。現実世界の本質ともいえるステートレスアプリケーションを取り込む上で、OpenShiftはどのような取り組みをしているのか、技術的に詳しく説明して頂けますか？

Gracely: サポートするアプリケーションがステートレスに限定されていたことは、初期のPaaSシステムのユーザ、特に大企業にとって、最大の不満のひとつでした。12 Factor Appは、そのアプリがHerokuないしCloud Foundryプラットフォーム上で動作しないとする理由の、12の意見の集合体に過ぎなかったのです。OpenShiftが標準コンテナとKubernetesに移行したとき、その12の意見は組み込まれませんでした。それによって、プラットフォームはもっと柔軟なものになったのです。Red Hatのエンジニアたちは、Kubernetesのストレージ開発に多くの貢献をしています。v3.0以降、さまざまなタイプの永続ストレージをサポートしてきました。その後のリリースでは、ストレージボリュームの動的プロビジョニングや、複数のストレージクラスによる強化が図られています。Kubernetesのストレージ開発に加えて、Red HatはSatefulSetsにも深く関わってきました。

短命なアプリケーションやステートレスなアプリケーションにしか利用できないというのは、コンテナに対する大きな誤解です。

InfoQ: OpenShiftのエコシステムやさまざまな提供物、ロードマップなどについて教えてください。

Gracely: まず最初に確認したいのは、OpenShiftのエコシステムはKubernetesのエコシステムそのものである、ということです。そのコアテクノロジが極めて柔軟なエコシステムを実現しています。コミュニティはAPIとインターフェースで標準化され、新たなアイデアの一貫性のある統合を可能にするとともに、OpenShfitの任意のクラウドプラットフォーム(AWS、Azure、GCP、OpenStack、VMware、RHV、およびベアメタル)への展開を実現しています。統合に関する要件を抱えて私たちの元に来るテクノロジパートナやISV、ユーザの両方に対しては、OpenShift CommonsコミュニティとOpenShift Primedプログラムが用意されています。Red HatはAWSおよびAzureと、両社のテクノロジをOpenShiftに拡張する(Service Broker、Windows Containers、MS SQLなど)主要パートナシップを発表しています。また、AWSとGCP(近日中にAzureも)を対象に、OpenShift Dedicatedをホストしています。さらにGoogleのエンジニアリングチームとは、Kubernetesの初期段階から密接な関係を持って開発を続けています。OpenShiftは、世界中のクラウドサービスプロバイダを支えるバックエンドプラットフォーム技術としても採用され、数多くの利用モデルが有償で提供されています。

• OpenShift Container Platform – 任意のクラウド(AWS, Azure, GCP, OpenStack, VMware, RHV, およびベアメタル)の展開可能なソフトウェアプラットフォームとして利用されています。
• OpenShift Dedicated – マネージドサービス(Red Hatが運営)として供用され、“プライベート”クラウド環境を実現します。AWSあるいはGCP(2018年からはAzureにも)の任意のリージョンに展開可能です。
• OpenShift Online – 開発者が利用可能なオンデマンド環境として、Red Hatが管理します。Starter Tier(無償)とPro Tier(有償)が提供されています。

ロードマップと“What’s next”については、私たちがRed Hat Summitで行った公開セッションと、KubeConの前のオースチンでのOpenShift Commonsでのフォローアップを参照頂けます。ロードマップ上の優先順位は次のような領域に分類されます。

• KubernetesコミュニティとCNCFプロジェクトからのアップデート統合を継続する。
• OpenShiftプラットフォームで実行可能なアプリケーション(12 Factor、ステートフル、マシンラーニング/AI、データベース、サーバレス、ハイパフォーマンスコンピューティングなど)の範囲をさらに拡大する。先日ローンチされたRHOAR(Red Hat OpenShift Application Runtimes)がこの拡大に寄与している。
• マルチクラウド環境の実現とパブリッククラウドサービス統合の簡素化(Service Brokerなど)を継続する。
• プラットフォームへの堅牢なマルチレイヤのセキュリティ提供を継続すると同時に、急速に変化するソフトウェアコンテキストに対するセキュアな環境提供を引き続き簡素化する。
• UI(CLI、GUI、API)およびCI/CD統合の両面で、堅牢な開発環境の提供を継続する。OpenShift.ioは開発者に対して、よりシンプルかつ統合されたエクスペリエンスを提供するオプションのひとつになる。

   

基調講演その他の記録は、Kubeconのスケジュールで公開されている。