Kubernetes | SEO-LPO.net

CoreOSの商用化KubernetesツールTectonicがv.1.8にアップデート、外部サービスの利用が容易に

CoreOSが、ポピュラーなコンテナオーケストレーションツールKubernetesを企業向けに使いやすく商用化して提供するTectonicのマイナーアップデート、v.1.8をリリースする。その新しい機能Open Cloud Services Catalogにより、ユーザー企業のDevOpsは、外部サービスを容易にKuberneesにプラグインできる。

CoreOSでTectonicのプロダクトマネージャーをやっているRob Szumskiが、ニューバージョンを発表する同社のブログ記事で言ってるように、パブリッククラウドは使いやすくて便利ではあるけれども、そこにロックインされてしまって、プロプライエタリなツールしか使えないこともある。

CoreOSのOpen Cloud Services Catalogは、その問題を解決する。‘カタログ’の名のとおりここには、特定のプロプライエタリなツールに代わる多様な選択肢があり、クラウドやハイブリッド環境など、複数の実行環境間の移動や行き来が容易にできる。

“Tectonic 1.8では、CoreOSのOpen Cloud Servicesで、マネージドクラウド（管理サービスを伴うクラウド）が提供すると期待されている苦労のないオペレーションに、さらに一味加えたものを体験できる。通常のプロプライエタリなクラウドサービスと違ってOpen Cloud Servicesは、CoreOSのTectonicプラットホームの上で走る第一級の、完全に自動化された、Kubernetesリソースの集合だ”、とSzumskiはそのブログ記事で述べている。

CoreOSは、提供物のすべてをできるかぎりオープンでポータブルにして、顧客のあらゆる特殊条件や要求にも柔軟に対応したい、と考えている。それだけでなく今度のOpen Cloud Services CatalogはTectonicsのコンソール本体上にあるので、外部サービスの導入も、またその無効化も、きわめて簡単容易である。

Open Cloud Servicesの初期のリソースとしては、etcd, Prometheus, Vaultなどが挙げられる。

Open Cloud Service CatalogはあくまでもTectonic 1.8のリリースの一部であり、基本的には9月の終わりにリリースしたオープンソースバージョンの路線は維持されている。とくにCoreOSが強調するのは、それがあくまでもKubernetesのオリジナルバージョンであり、フォークではないことだ。Kubernetesの管理団体であるCloud Native Computing Foundationも、それがピュアなオープンソースバージョンとして維持されることを期待し奨励している。

なお、このバージョンにより、コンテナエンジンDockerも自動的にアップデートされる。デベロッパー(Dev)は、このエンジンを使って、コンテナに収めたアプリケーションを作る。そしてオペレーション(Ops)はKubernetesを使ってコンテナの管理とデプロイを行う。というわけでこのツールは、コンテナのDevOpsの両サイドの面倒を見てくれる。

この最新バージョンは年内にダウンロード可能になるが、既存のTectonic 1.7からのアップデートは自動的に行われる。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

複数クラウドにまたがるアプリケーションの管理をコンテナとKubernetesで自動化するOverclock Labs

Overclock Labsは、アプリケーションの複数のクラウドにまたがるデプロイと管理を自動化により容易にするためのサービスを提供している。そのために同社が作った、分散クラウドインフラストラクチャを自動化するツールは、今どき当然ながらコンテナを使用する。そしてそれらのツールの主役は、コンテナオーケストレーションツールKubernetesだ。

今日（米国時間11/21）、2年前に創業されたOverclock Labsはステルス状態を脱し、130万ドルの資金調達を発表した。投資家はシリコンバレーの複数のエンジェルとCrunchFund、こちらは本誌TechCrunchと名前や経歴を多少共有しているが、本誌と特別の関係はない。

同社は、今回初めて一般に公表される資金を使って、DISCOというものを開発していた。DISCOは Decentralized Infrastructure for Serverless Computing Operations（サーバーレスコンピューティングオペレーションのための分散インフラストラクチャ）の頭字語だ。サーバーレスとあるからにはそれは、AWSのLambdaやAzure Functionsのようなイベントドリブンのサービスか？　そう考えたくなるのも無理もないが、しかしOverclock Labsの協同ファウンダーGreg Osuri(CEO)とGreg Gopman(COO)によると、彼らの言う“サーバーレス”とは、完全な自動化のことだ。Lambdaは、イベントドリブンなアプリケーションのためにリアルタイムの自動化をやってくれるが、オープンソースにする予定のDISCOの場合は、もっといろんなアプリケーションのサポートを目指している。なお、同社の三人目の協同ファウンダーは、Adam Bozanichである。

Osuriが説明するその基本的な考え方は、ユーザーがどんなクラウドサービスのプロバイダーでも使えて、それら複数のクラウド間を容易に行き来できるようにすることだ。そのようなデベロッパー体験は、クラウドアプリケーションプラットホームのHerokuにやや似ており、ユーザーインタフェイスはGUIとコマンドラインの両方を提供している。

目下このツールがサポートしているのはAWSとGoogle Cloud Platform、そしてベアメタルのスペシャリストPacketだが、今後徐々にそのほかのクラウドもサポートしていく。DISCOはオープンソースだから、ほかの人たちが自分のものを統合するのも容易だ。

DISCOを使ってアプリケーションをデプロイするやり方は、二（ふた）とおりある。12-factor appのありがたい教えに従ってアプリケーションを作っている場合は、DISCOは単純にソースコードを取り込んでアプリケーションをデプロイする。あるいは独自のコンテナでアプリケーションを作ってる場合は、それらのコンテナをDISCOに渡してデプロイさせる。するとDISCOがコンテナレジストリを扱い、コンテナをデベロッパーに代わって管理する。

DISCOの約束は、アプリケーションのデプロイをHerokuを使う場合のように容易にすること、ただしその1/3のコストで。前にAngelHackを一緒に作ったOsuriとGopmanには、オープンソースのツールを作った経験が豊富にあり、今でもオープンソースのエコシステムの一員だ。だからDISCOをオープンソースにするのも自然な流れで、その上に有料サービスを乗っけていく気だ。

その有料サービスは現段階ではまだ具体化していないが、とにかく同社が真っ先にやることは数か月後にDISCOをリリースし、そのまわりにエコシステムを築いていくことだ。

今では高度なオープンソースのプロジェクトが毎日のようにローンチしているから、DISCOのエコシステムづくりも容易ではないだろう。でも同社のファウンダーたちは、その過程について現実的な見方をしている。それに、コンテナとKubernetesによるアプリケーションのマルチクラウドデプロイと管理の自動化は、誰にでもできることだから、そのうち競合他社があふれてくるだろう。近くAWSのre:Inventカンファレンスがあるから、そのへんの情況を確認してみたい。でもOverclock Labsの連中は、早くスタートした者にはそれなりの優位性があり、ビッグプレイヤーになれる、と信じている。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

Kubernetesの認証基準に36の企業が合意

Cloud Native Computing Foundation（CNCF）は本日（米国時間11月13日）、そのメンバーの中の36組織が、広く普及しているオープンソースコンテナオーケストレーションツールKubernetesの、認証基準に対して合意したことを発表した。これにより、ユーザーたちは、Kubernetes管理下のコンテナを想定範囲内で動作させながら、不安なくあるバージョンから別のバージョンへと移動させることが簡単になる。

今回36組織のグループは、メンバーたちが作成するKubernetesの各バージョンの全バージョンが、移植性を担保するために保証しなければならない、APIの基本セットに関して合意したのだ。CNCFのエグゼクティブディレクターDan Kohnは、参加しているメンバーたちが互換性テストとして扱い、サポートを保証している、既存のKubernetesプロジェクトAPIのサブセットを取り出したと語っている。実際上これが意味することは、新しいコンテナを立ち上げたときに、誰が作成したバージョンのKubernetesかに関わらず、一貫した動作を期待することができるということだ、と彼は続ける。

Kohnは、この組織が業界で最も有名な多くの企業たちを、結集することができたと言う。「私たちは素晴らしいメンバーたちを得ました。こうすることで、製品がフォークすることなく、単一のものとして発展していくと確信しています」と彼は語る。

フォークとは、オープンソースプロジェクトの中で、独自のバージョンを作る企業が現れ、互換性のない可能性のある新しいバージョンのソフトウェアを作り出すことを意味する。CNCFはこれを防ぎたいと願っており、そのためにMicrosoft、Red Hat、Alibaba、Oracle、Google、そしてIBMを含む多くの強力なメンバーを結集た。

パブリック・クラウド・コンピューティング世界での最大勢力であるAWSは、今回署名したメンバーには加わっていないが、CNSFによれば、これは単に同社がまだ、独自バージョンのKubernetesを作成していないからということだ（とはいえ、AWS上ではKubernetesクラスターは動作している）。AWSが8月にCNCFに加わったことで、CNCFとKubernetesが本格的に立ち上がったことが示された。

これだけ多様な多くのテクノロジー企業たちが、何かについて合意するのは、間違いなく素晴らしく奇跡的な出来事だ。しかしKohnによれば、大部分の企業はフォークへの懸念から極めて迅速に集まったのだという。

「Kubernetesは急激に普及していて、誰もがそれを採用しています。もし取り組みと適用のレベルが高い場合には、プロジェクトがフォークするかどうかには懸念を抱くことになります。あるバージョンで動作するアプリを持っているときに、はたして別のバージョンで動作するだろうかと心配することになりますから」とKohnはTechCrunchに語った。

Kubernetesは実際、CNCFに参加したテクノロジー企業のほぼすべての中で、昨年の段階で既にデファクトスタンダードになっていた。今日の発表は成長するプロジェクトに対してあるレベルでの規律を持ち込むものだ、そしてオープンソースプロジェクトプロジェクトとしてのKubernetesが、成熟に向かう重要な一歩なのだ。

[原文へ]
（翻訳：Sako）

FEATURED IMAGE: STAN OLSZEWSKI/SOSKIPHOTO/FLICKR UNDER A COPYRIGHT LICENSE

MicrosoftのAzure Container Serviceの頭字語がACSからAKSに変わった、そのココロは？

コンテナのオーケストレーションに関してはKubernetesが急速にデファクトスタンダードになりつつあり、Docker SwarmやデータセンターOS(DC/OS)を自称するMesos/Mesosphereなどは今や、なんとか自分なりのニッチを見つけようと努力している。そんな中でMicrosoftは長きにわたって、同社のマネージドAzure Container Service(ACS)のアドバンテージのひとつは複数のオーケストレーションツールをサポートすることだ、と主張してきた。しかし今日（米国時間10/24）からは、それがすこし変わるようだ。Azure Container Serviceの頭字語が、なんと、“AKS”になるのだ。

お察しのとおり、この唐突な“K”はKubernetesであり、Microsoftは明らかにそのサービスをこのオーケストレーションツールに向かわせようとしている。サービスの正式名は変わらないのに。

Azureに、マネージドなKubernetesが加わるこのAKSは、目下プレビューだ。

AKSでMicrosoftは、そのフォーカスの中心にKubernetesを置く。Azureのコンテナ対応主席PM Gabe Monroyによると、コンテナサービスは至近の6か月で300%成長し、そしてその顧客は、同社の現在のKubernetesサポートを“とても気に入っている”、という。他の類似サービスと同様にAzureも、Kubernetes環境の管理と運用をできるかぎり容易にしているのだ。

なお、AKSそのものは無料だが、コンテナを動かすためには当然、AzureのVMを有料で使わなければならない。これに対しGoogle Container Engineは、そのサービスの使用時間とクラスター数に応じて課金される。

Microsoftが強調するのは、今でもDocker EnterpriseやMesosphereのDC/OSへの関心が存続していることと、既存のACSデプロイメントエンジンのサポートは今後も続けることだ。Monroyは今日の発表声明でこう述べている: “Azureの顧客でもあるこれらの顧客のニーズに対応するために、DockerとMesosphereのエンタープライズ製品の統合は弊社のAzure Marketplaceにおいて、さらに強化していく。Azure MarketplaceはACSと同様の容易なデプロイメントを提供し、またエンタープライズエディションへの容易なインプレースアップグレード（稼働時アップグレード）を提供していく。それはまた、付加価値としての商用機能と24×7のサポートを提供する”。

この春Microsoftは、KubernetesにフォーカスするコンテナプラットホームDeisを買収した。また同社は最近、オープンソースソフトウェアとしてのKubernetesの‘実家’Cloud Native Computing Foundationに加盟した。Kubernetesの共同制作者の一人Brendan Burnsは、今ではAzureのコンテナ関連サービスのトップだ。こういった最近の動きはすべて、同社がますます強力に、このオープンソースのプロジェクトを支持するようになったことの現れ、と見なさざるをえない。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

DockerもついにKubernetesをネイティブでサポート、Swarmの併用も可能

コンテナのオーケストレーションといえば、Googleが開発したオープンソースのツールKubernetesが今や事実上のデフォルトスタンダードになってしまったようだ。だから今日Dockerが、コペンハーゲンで行われたDockerCon EuropeでKubernetesのネイティブサポートを発表したことには、誰も驚かないだろう。

同社独自のオーケストレーションツールDocker Swarmを完全に放棄したわけではないが、今回初めてKubernetesのネイティブサポートを提供したということは、今やそのユーザー数がとても多いから、コンテナ企業である以上、サポートせざるをえないのだ。ただしDockerの場合は、ユーザーがランタイムにオーケストレーションエンジンを選択できる。DockerのプロダクトマネージャーBanjot Chananaによると、毎回SwarmかKubernetesかどちらかを選べるが、コードを替える必要はない。

これまでも、DockerでKubernetesを使うことはできたが、それは必ずしも容易ではなかった。今回発表されたKubernetesのサポートにより、Docker Enterprise EditionとDocker Developer Editionのどちらのユーザーにとっても、それがずっと単純になったはずだ。

Chananaによると、Dockerのアーキテクチャのおかげで、KubernetesとDocker Swarmの併用はそれほど難しくなく、違和感もない。Dockerは顧客に、プログラムのコンテナを作るための標準的な方法を提供している。それはDevOpsモデルでは通常、デベロッパーの担当になる。

一方オペレーションの方は、コンテナのライフサイクルの間にそのデプロイとセキュリティと管理を担当し、そのためにコンテナオーケストレーションツールを使用する。最近の2年間でAWS, Oracle, Microsoft, VMwareとPivotalなどのビッグネームがこぞってKubernetesを採用し、彼らはオープンソースのKubernetesプロジェクトの拠点であるCloud Native Computing Foundationにも参加した。それによりデフォルトスタンダードとしてのKubernetesの地位が、いよいよ確定した。

これだけの企業がKubernetesバスに乗り込んでしまったからには、Dockerも顧客の要望に従わざるをえない。Dockerはこれまで、自社のオーケストレーションツールを使いながらKubernetesをサポートすることもできていたが、でも今後は、大多数のコンテナワークロードでKubernetesが選ばれることが、確実になってきた。

なお、今週のThe Informationの記事によると、GoogleはKubernetesを開発していた2014年に、Dockerをコラボレーションに誘（さそ）っている。でも当時DockerはSwarmを選び、そしてGoogleはCloud Native Computing Foundationへと向かった。今日の発表は、まさに円が閉じたようであり、これからはDockerも、（コードはホストしないけれど）Kubernetesをサポートしていくことになる。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

Kubernetesがコンテナ時代のソフトウェア産業を全面的に支配、大企業もCloud Native Computing Foundationに参集する

駅を出て徐々にスピードを増す列車のように、Cloud Native Computing Foundationは急速に強くなり、テクノロジー業界の大物たちを吸引してきた。過去1か月半だけでも、AWS, Oracle, Microsoft, VMwareとPivotalなどがこぞって参加した。

これらの企業は必ずしも毎日仲が良いわけではないが、しかしそんな中でKubernetesは業界の必須のツールへと育ち、どの企業もCNCFに参加してそのミッションをサポートすることが必要だ、と考えている。これは部分的には顧客の要望によるものであり、そして残りの部分は、Kubernetesやそのほかのクラウドネイティブ技術に自分も口出しをしたいという欲求の表れだ。

この団体はLinux Foundationの傘下にあり、最初はGoogleが開発したオープンソースのプロジェクトKubernetesもこの親団体の管理下にある。Kubernetesはコンテナ化されたプログラムのオーケストレーション部分を担う。そしてコンテナは、ソフトウェアを、以前のように大きな一枚岩的なプログラムとしてではなく、マイクロサービスと呼ばれる離散的な小片の集まりとして配布するための形式ないし方法である。

過去2年ほどはDockerがコンテナの普及に大きく貢献し、コンテナ化されたプログラムを作るための共通的な方法をデベロッパーに提供してきた。そして今では、企業はこれらのコンテナ化されたアプリケーションを“クラウドネイティブ*に”動かすことを欲している…CNCFの事務局長Dan Kohnはそう語る。〔*: cloud-native, ‘クラウド生まれ’、アプリケーションの作成も実稼働もクラウド上で行われること。〕

彼の説明によると、企業がAWS, Azure, GCPのようなパブリッククラウドへ行くにせよ、あるいはオンプレミスのプライベートクラウドでアプリケーションを動かすにせよ、どちらの場合も同じ技術がベースになる。アプリケーションがどっちにあっても、Kubernetesはそれらを整合性のある形で動かし管理するためのツールを提供する。

コンテナ化されたクラウドネイティブなアプリケーションをローンチする企業にとって、Kubernetesはオーケストレーションとオペレーションのレイヤを提供し、それを軸として驚異的なほど高い生産性が実現する。だから冒頭に挙げた巨大企業ですら、そのことを認識して、今やCNCFというバスに乗り込んでくるのだ。

というわけで、すべての中心にあるものはKubernetesだが、Kohnによるとそれは、見た目ほどシンプルではない。コンテナオーケストレーションツールを採用しCNCFに参加することには、企業目的が伴っている。“全員が輪になって手を握り合い、Kumbayaを歌う、という状況ではない。同じ顧客を奪い合う競合関係もある。しかし彼らは、コンテナオーケストレーションツールをめぐって争っても一文の得にもならないことを、十分に理解している”、とKohnは語る。

Kohnによると、Kubernetesは今やコンテナオーケストレーションのデファクトスタンダードだから、企業はもはやその部分では競合せず、コンテナの管理体験を向上させるそのほかの部分のサービスで優位に立とうとしている。業界の大物たちも、コンテナのオーケストレーションは今や解決済みの問題であり、今さら車輪の再発明に取り組むのは愚かである、という認識を共有している。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

Kubernetes展開お助けサービスで起業したHeptioが創立1年足らずでシリーズB $25Mを調達

オープンソースのコンテナオーケストレーションツールKubernetesの協同ファウンダーCraig McLuckieとJoe Beda〔共に元Google〕が創業したHeptioが今日（米国時間9/13）、Madrona Venture Partnersが率いるシリーズBのラウンドで、2500万ドルを調達したことを発表した。Lightspeed Venture PartnersとAccel Partnersもこのラウンドに参加したが、同社はシリーズAで850万ドルを調達してからまだ1年経っていない。ただしこのシアトルのスタートアップは、シード資金を獲得していない。なお、Kubernetesのもう一人の協同ファウンダーBrendan Burnsは、今Microsoftにいる…MicrosoftからGoogleに来たBedaとは逆だ。

HeptioのCEO McLuckieは、“短い8か月だったが、すばらしい体験をした”、と語る。“シリーズAのときは、次の資金調達がこれほどすぐだとは、想像もしなかった”。Kubernetesやそのほかのクラウドネイティブ技術のエンタープライズへの導入を支援する彼らのビジネス機会が、これほど急速に大きくなるとは、彼らも予想しなかった。そして今彼が強調するのは、その機会が単にKubernetesの機会ではないことだ。

McLuckieは語る: “Kubernetesは核であり、それを取り巻くようにしてこの会社を作った”。そしてさらにそのまわりには、クラウドネイティブコンピューティングをエンタープライズが容易に採用できるようにするためにやるべき仕事が、山のようにある。また、さらにそれに伴って、デベロッパーの新しいワークフローも生まれる。Kubernetesはコンテナオーケストレーションツールだが、McLuckieによると、ほかに大量の関連ツールも作らなければならない。

“Kubernetesの人気が盛り上がるのを見て、われわれにはこれをビジネス機会として捉える資格がある、と感じた”、そうMcLuckieは述べる。

では、Heptioは実際に何をやっているのか？　企業向けの、Kubernetesお助けサービスがビジネスになる、と確信していたが、最初はプロダクトの具体的なイメージはなかった。でもその後の数か月で、徐々にビジネスモデルがはっきりしてきた。要するにHeptioは、Kubernetesを採用したがっている企業にプロフェッショナルなサービスを提供し、教育訓練やサポートも提供する。McLuckieが強調するのは、それが企業のKubernetes利用を助けるだけでなく、彼らをオープンソースのコミュニティに接近させる意味合いもあること。そのためにチームは、Kubernetesのいくつかの具体的な特性と、それがオーケストレーションするコンテナクラスターを管理するための、独自のオープンソースプロジェクトも作っている。

新たな資金はヨーロッパとアジアへの進出に充てる予定だが、さらにチームを拡大するとともに、新市場開拓に役に立ちそうな買収を検討するかもしれない、という。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

MesosphereがデータセンターオペレーティングシステムDC/OSにKubernetesのサポートを導入

今Kubernetesは確実に、コンテナオーケストレーションサービスのデファクトスタンダードになっている。Mesosphereはわりと初期からコンテナを採用し、企業顧客の、分散システムによるクラウド上のビッグデータ分析を支えているが、今日（米国時間9/6）は、大規模な分散アプリケーションを動かすためのOSのような同社のプラットホームDC/OSがKubernetesをサポートする、と発表した。Mesospereはいわば、Apache Mesosの実装系であるが、MesosとDC/OSのためのコンテナオーケストレーションツールとしては長年、同社独自のMarathonを提供してきただけに、今回の動きは意外である。〔*: DC/OS == Data Center Operating System〕

KubernetesのサポートはDC/OS 1.10のベータから提供され、それは9月11日にローンチされる。

今朝この情報をもたらしたThe Informationの記事は、MesosphereがKubernetesに“屈した”、という見方をしている。同じく今朝、ぼくがMesosphereの協同ファウンダーでCEO Florian LeibertやMesosphereのCMO Peter Guagentiに取材したら、両人は屈服説を断固否定した。両人が強調するのは、大企業が多い同社の顧客に選択肢を提供する、という考え方だ。“うちの顧客は大企業のインフラやオペレーションを担当しているプロであり、一つの組織内で何十万ものデベロッパーに奉仕している”、とGuagentiは語る。“そんな彼らにとっていちばん重要なのは、選択の自由だ”。

Leibertの見解では、Kubernetesをオーケストレーションエンジンの一つとして提供することは、これまで同社が、複数のデータサービスや継続的インテグレーションのプラットホーム、あるいは複数のネットワーキングツールをサポートしてきたことの延長にすぎない。さらにGuagentiが強調して曰く、顧客にとってMesosphereは、コンテナを利用するためのプラットホームではなく、あくまでも、データ集約的なアプリケーションをデプロイし管理していくためのインフラなのである。

Leibertによると、MarathonとKubernetesではユースケースが異なる。Marathonは、コンテナ技術を使っていないレガシーのアプリケーションを動かすためにも使えるが、Kubernetesは当然ながらコンテナのためのツールだ。“だから両方をサポートするのが自然であり当然だ”、と彼は言う。“これらの技術の多くはレヤーケーキにとてもよく似ていて、たとえばKubernetesとMesosはとても相性が良い。コンテナのワークフローをKubernetesが担当するが、Hadoopのようにコンテナを使わないアプリケーションもある”。

Guagentiに言わせると、コンテナの分野でもMesosphereはリーダーだ。ユーザーがプロダクションで動かしているコンテナの数でもたぶんトップだし、コンテナサービス企業の中で売上でもトップだろう、という。売上の金額は、教えてくれなかったけど。

LeibertとGuagentiは、これまでと変わらずMarathonへの投資は続ける、と断言した。

今後ユーザー企業のデベロッパーたちは、Kubernetesを使うコンテナのデプロイを、DC/OSを使ってセットアップおよび管理できるようになる。もちろん同じインフラストラクチャの上でDC/OSはそのほかのコンテナデプロイメントも動かすし、Kubernetesも各デプロイによってバージョンがさまざまに異なったりするだろう。このプロジェクトでMesosphereはGoogleと協働し、Mesosphereがユーザーに、ベンダー固有の変更がなく、互換性の問題も起きない、源流的（最上流的）なバージョンのKubernetesを提供できるようにしている。

GoogleでKubernetesとGoogle Cloud Platformを担当しているプロダクトマネージャーAllan Naimはこう語る: “KubernetesをDC/OSに導入することによってMesosphereは顧客に、データリッチなコンテナ化アプリケーションを、彼らのデータセンターやクラウド上で構築、デプロイ、そしてオペレートできる堅牢なプラットホームを提供することになる。コンテナにはKubernetes、そしてマシンインテリジェンスにはTensorFlowを使うプロジェクトを、MesosphereのDC/OSとGoogle Cloud Platformの両プラットホームで動かせば、企業は強力な、そしてオープンなハイブリッドクラウドプラットホームを確保することになる。その意味でMesosphereとの協働、およびコミュニティの前進に継続的に貢献できることが、これからも楽しみである”。

Mesosphere側の結論としては、単純に顧客の選択肢を増やすことに帰結するが、Kubernetesのエコシステムがまた一勝を挙げたことも確実だ。そのエコシステムは、これまで独自のニッチを築いてきたMesosphereにとっては脅威ではないが、これまでコンテナの普及推進の主役だったDockerにとっては、主役を奪われる危険性があるかもしれない。たしかに今回のMesosphereの動きによって、Dockerの独自性の確立と維持が、やや難しくなったようだ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

PivotalとVMwareとGoogleがコンテナでパートナー、すでに提供プロダクトも具体化

PivotalとVMwareとGoogleがチームを作って、コンテナプロジェクトの開発とデプロイと管理を、十分なスケーラビリティを維持しつつ単純化する総合的サービスを提供していくことになった。

三社はオープンソースのプロダクトをベースとする商用サービスにより、このパートナーシップを構成するさまざまなパーティーと共にそのプロダクトを市場化していく。GoogleはそれをGoogle Cloud Platformの一環として売ることになり、PivotalとVMwareでは彼らの標準の営業品目として売り、両社の親会社であるDell-EMCはハードウェアを含めたパッケージとして売っていく。

彼らの役割分担を整理するとこうなる: GoogleはオープンソースのコンテナオーケストレーションツールKubernetesを提供する。PivotalはCloud FoundryによりPaaSの要素を提供、そしてVMwareは全体をまとめる管理層を加える。

プロダクトの名前にはPivotalが使われ、Pivotal Container Serviceとなる。省略形はPCSではなくPKSだが、たぶん彼らは頭字語という言葉の意味をよくわかっていないのだろう。いずれにしても、三社が肩を組んでやることは、VMwareのvSphereとGoogleのCloud Platform(GCP)をベースとする“プロダクションに即対応する(production-readyな)Kubernetes”を提供していくことだ。そしてそれは継続的に、Google Container Engineとの互換性が確約される。後者はご想像どおり、GCEではなくてGKEなのだ。¯_(ツ)_/¯

以上は説明だが、このプロダクトが実際にベースとするものはGoogleとPivotalが作ったコンテナ管理プロダクトKuboだ。そしてPKSは、PivotalのCloud Foundryによる、デベロッパーにとっておなじみのコンテナ開発環境を提供する。デベロッパーはKubernetesの経験者であることが前提だ。

VMwareは縁の下の力持ちのように管理層を提供し、その上でDevOpsのOpsの連中がコンテナをデプロイし、コンテナのライフサイクルの全体を管理する。以上を総合すると、エンタープライズ級のコンテナ開発〜デプロイ〜管理のシステムの、一丁あがり、となる。

Google Cloudのプロダクトマーケティング担当VP Sam Ramjiによると、昨年Googleに来る前、Cloud Foundry Foundationにいたときすでに、コンテナをプロダクションに持ち込むためのいちばん容易な方法がCloud Foundryだ、と直観していた。そして当時の彼らは、Kubernetesを統合するやり方を研究していた。

一方、PivotalのJames Watersはこれまで、PivotalのツールとともにGoogle Cloudのツールを使っている大企業顧客が多いことに気づいていて、そのツールキットに、人気急上昇中のKubernetesを含める必要性を痛感していた。

VMwareはどうか、というと、Sanjay PoonenらVMwareの連中はこれまで、コンテナの開発環境としてCloud Foundryを使う大企業顧客が多いことと、Kubernetesがコンテナオーケストレーションエンジンとしての勢いを増していること、この二つの支配的な状況を日々、目にしていた。

そして今回、そのような三者が交わったところに出現したコンテナ統合環境（開発/デプロイ/管理サービス）が、今回の三社パートナーシップの成果だ。その供用開始は、今年の第四四半期を予定している。

〔関連記事:
●三社パートナーシップに導いた7つの動向（未訳）
●VMware CloudがAWSからも提供（未訳）
〕

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

CoreOSのTectonicコンテナプラットフォームがMicrosoft Azureをフルサポート

本日（米国時間8月17日）CoreOSは、KubernetesベースのTectonicコンテナ管理プラットフォームの、Microsoft Azure対応を発表した。これまでは、ベアメタルサーバとAWS上へのコンテナデプロイメントだけが完全にサポートされていた。3月に登場したAzureへのベータサポートに続く今回の新規リリースで、Tectonicはサポート対象の3つのプラットフォームにまたがるマルチクラウドデプロイメントへの統合サポートを提供することになった。

「Microsoft Azureに向けてのTectonicsの安定版メジャーリリースは、マルチクラウドに対応し、インフラと運用をより効率的かつスケラーブルなものにするというお約束に向けた、非常に重要なステップです」と語るのはCoreOSのTectonicプロダクトマネージャーRob Szumskiだ。「Azure向けTectonicは、Kubernetesインフラストラクチャを初めから正しく構築し、展開サイクルをスピードアップすることで、時間とコストを節約します。ハイブリッドクラウドのデプロイメントが可能なことで、インフラストラクチャ責任者たちは、ユーザーをクラウドコンピューティングやクラウドサービスにロックインしないプラットフォームの自由度と柔軟性を手に入れることができます」。

Tectonicのその他のアップデートとしては、Google謹製コンテナオーケストレーションサービスの最新リリースであるKubernetes 1.7への完全サポートも含まれる。最新リリースへのアップグレードはワンクリックで完了し、アップデート中にダウンタイムが発生しないことが約束されている。これはKubernetesの初期版と比べると大きな利点だ。当時はどのようなプラットフォームを選んでもアップグレードは一苦労だった。

また新機能としてインバウンドトラフィックをより詳細に制御できるようにするネットワークポリシーのサポート（アルファ版）が入り、コンテナの展開中に問題が発生した場合のアラートを、あらかじめ設定しておくこともできるようになった。

[ 原文へ ]
（翻訳：Sako）

Red HatのコンテナプラットホームOpenShiftのアップデートに外部サービスへの接続インタフェイスを導入

Red Hatが今日（米国時間8/9）、OpenShiftプラットホームの今四半期のアップデートをリリースし、社内や社外のさまざまなサービスへの接続を作る機能、Service Catalogを新たに加えた。

OpenShiftは、KubernetesとDockerをベースとするPaaSで、コンテナのスタンダードとしてOpen Container Initiativeを採用している。KubernetesはGoogleで開発されたコンテナ管理プラットホーム、Dockeは広く使われているコンテナ作成プラットホームだ。

企業が仮想マシンからコンテナへ移行していくに伴い、OpenShiftのようなコンテナデプロイプラットホームのニーズがますます高まっている。そして今やRed Hatの顧客の中には、Deutsche Bank, Volvo, United Healthのような有名大企業もいる。

Red HatでOpenShiftを担当するプロダクトマネージャーJoe Fernandesによると、コンテナへ移行しようとする企業は最近ますます多くなり、すべての企業が何らかの形でコンテナの採用を目指していると言っても過言ではない。今では“いちいち表に書ききれないほど多い”、と彼は言う。

同社の、コンテナを利用する顧客ベースの増大とともに、大企業のIT部門の現実的なニーズを満たす、コンテナ化アプリケーションの展開プラットホームが重要になっている。とくに最近よく聞くニーズは、コンテナ化したアプリケーションが社内や外部のサービスに容易に接続できるようにしてほしい、という要望だ。

Service Catalogは、アプリケーションストアみたいな機能で、デベロッパーがそこへ行って構成済みのコネクターを見つけ、それらをサービスへのインタフェイスとして利用する。それは会社のOracleデータベースへのコネクターのこともあれば、AWSやAzureのようなパブリッククラウド、すなわち社外的サービスへのコネクターのこともある。Fernandesによると、アプリケーションストアの比喩は適切だが、今のところ正規の調達の手順は組み込まれていない。それが今後の課題だ、という。

これまでも、顧客がサービスへの接続を自作できたが、それには大量の作業を要した。ユーザーの面倒な作業を要しない、パッケージ化されたやり方でないと、時間と労力を取られすぎる。

そのために登場したService Catalogは、今回のリリースではテクニカルプレビューだ。次のリリースは、今年の終わりになる。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

Kubernetesによるコンテナクラスターのプロダクションレベルのデプロイを「安全化」するHeptioのオープンソースプロジェクト

シアトルのHeptioは、Kubernetesの協同ファウンダーCraig McLuckieとJoe Bedaが最近立ち上げた会社で、企業におけるKubernetesの本格的な利用（プロダクションレベルでの利用）を、より容易にすることをねらっている。2016年に創業したこの資金豊富な会社はこれまで、鳴り物入りの新製品発表などはまったくなかったが、でも今日（米国時間8/3）同社は、二つのオープンソースプロジェクトArkとSonobuoyをリリースした。

Kubernetesの人気は急成長し、それは今やもっとも人気のあるコンテナオーケストレーションシステムだと思うが、でもその周りにできるエコシステムは、誰もが認めるように、今でも未発達だ。Kubernetesをサポートするサービスやオープンソースのプロジェクトは山ほどあるが、現状はまだまだ、成熟期というより成長期だ。Heptioがその二つのプロジェクトで解決しようとする問題は、Kubernetesのクラスターのステートをバックアップすること（Ark）と、これらのクラスターのテストと診断（エラー検出）だ。

Arkのようなツールの標準的なユースケースといえば、インフラストラクチャやデータが落ちたときの災害復旧だ。同社の今日の発表では、こう言われている: “われわれの顧客がKubernetesのプロダクションユースに向かうに伴い、彼らの多くが、クラスターのバックアップとリストアの管理、という難題に直面する。そんなときデベロッパーは、（etcdで）クラスターのステートの直接的なレプリカからクラスターをリカバリしようとするが、うまく行かないこともある”。そこでArkはすべてのクラスターオブジェクトのバックアップを作り、ボリュームのスナップショットを作らせ、クラスター全体を前のステートへリストアする能力を与える。

一方Sonobuoyは、災害の防止だ。それはデベロッパーとオペレーションのチームが彼らのKubernetesのデプロイをテストし、それらが想定通り動いていることと、正しく構成されていることを確認する作業を支援する。

二つのプロジェクトはどちらもGitHubから入手でき、オープンソースなので多方面からのフィードバックやコードの寄与貢献を歓迎している。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

CoreOSがコンテナプラットホームTectonicをアップデート、Kubernetesの最新バージョンとetcdデータストアをサポート

CoreOSが今日（米国時間5/31）、サンフランシスコで同社のユーザーカンファレンスを開催している。当然ながらそのイベントでは、同社のあれやこれやがたくさん発表された。そしてその多くは、Kubernetesベースのコンテナインフラストラクチャを管理するTectonicプラットホームに関連している。

アップデートの多くは、単純明快だ。たとえばTectonicは今やKubernetesの最新バージョン1.6.4を使っているが、同社によると、エンタープライズ対応のKubernetesプラットホームでその最新バージョンを使っているのはTectonicだけだ、という。ただしそのバージョンは主にバグフィクスが目的で、メジャーバージョンではない。

しかしさらに重要なのは、デベロッパーが今や簡単に、CoreOSで人気のキー-ヴァリューデータストアetcdを導入し利用できることだ…そのためには新たなツールetcd Operatorを使う。etcdを使いたいデベロッパーは、Operatorを使ってetcdを必要に応じてスケールするが、エラーはサービス側がおだやかに処理し、アップデートも自動的に行う。

CoreOSのファウンダーでCEOのAlex Polviによると、同社が今注力しているのはエンタープライズ顧客の獲得だ。彼の主張では、今エンタープライズと呼べるほどの企業は、コンテナによるアプリケーション開発に注目している（そして既存のアプリケーションはクラウドへ）。しかしAmazon, Microsoft, Googleなど特定のベンダーにロックインされたくはない。“でも1年ぐらいそこにいただけで、請求書は屋根を突き抜け、彼らのAPIをすべて使い、そして完全にロックインされる。われわれは、そんなサイクルを終わらせたい”。

Kubernetesは多くの企業にとってコンテナオーケストレーションプラットホームの第一の選択肢だから、CoreOSも、主なクラウドプラットホームすべての上で（そしてオンプレミスでも）その利用を手伝いたいが、主なプラットホームすべてをサポートすることで、そのようなロックインを避けたい。

Polviによると、同社がエンタープライズへの直接的な営業を開始したのはやっと2016年の最後の四半期からだ。最近ではそれがほぼ軌道に乗り、そしてPolvi説ではKubernetesも離陸したから、CoreOSの営業活動のエンジン全開もこれからだ、という。

〔関連記事：Microsoftのコンテナアプリケーション開発ツールDraft（未訳）〕

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

OpenStackの古参Mirantisが顧客の要望に逆らえずKubernetesをクラウドサービスの核に加える

OpenStackのエコシステムにその初期からいるMirantisが今日、これまでのメインプロダクトMirantis OpenStackのサポートを2019年5月に終了し、OpenStackとコンテナプラットホームKubernetesを組み合わせたクラウドサービスMirantis Cloud Platformをその後継プロダクトにする、と発表した。この新しいサービスでは、Kubernetesだけ、というサービス形態もありえる。

もちろんMirantisがOpenStackから一抜けるわけではないが、コンテナプラットホームとしてのKubernetesの人気と関心がMirantisの顧客のあいだでも最近はますます高まっているので、同社もそれに合わせざるをえない。今日発表された新しいプラットホームでは、OpenStackと共存してKubernetesの複数のクラスターをデプロイできるし、両者別々や、Kubernetesのみ、というデプロイも可能だ。顧客の中にはこのように、OpenStack抜きでソフトウェアのデプロイ方式を現代化したい、という要望もある。

新しいプラットホームは、その配布方法も変わっている。同社は顧客のMirantis Cloud Platformのデプロイを少なくとも6か月、彼らに代わって運用するが、その後は運用を顧客のOpsチームに委（ゆだ）ねる。同社は今日の発表声明で、こう言っている: “このデリバリモデルによって、ソフトウェアだけでなく、顧客のチームと工程もDevOpsのベストプラクティスに確実に従うようになる”。アップデートもこれからは、一定期間間隔で、迅速かつ楽に行われるようになる。従来の同社のOpenStackソリューションでは、アップデートもそれほど楽ではなかった。

Mirantisの協同ファウンダーでCMOのBoris Renskiは、自分の意見を言うとき、いわゆる歯に衣着せぬタイプだが、OpenStack vs. Kubernetesという議論に関しては、“人気と価値は違う”、と言う。“ハイスクールで人気者だった子が、大人になってフェラーリに乗ってるとはかぎらない。今のOpenStackは人気者ではないし、人気者はKubernetesだ。そして顧客は、人気者になびく場合が多いのだ”。

彼によると、Mirantisの顧客にもOpenStackを避けてKubernetesだけで行く、という企業が増えている。CanonicalのDustin Kirklandも、今月の初めに同じことを言っていた。Renskiは曰く、“OpenStackが人気トップだったころは、顧客は自分のデータセンターでOpenStack以外の何もかも脇に置くようになった。そして失敗した。重要なのは、その仕事に合った正しいツールを使うことだ。今、コンテナならKubernetesが良い。VMなら、OpenStackだ。たぶん明日になればAWSがLambdaをオープンソースにして、今度はKubernetesとコンテナが脇へ追いやられるだろう”。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

MicrosoftがKubernetesデプロイ技術とツールのベテランDeisを買収、Azureのコンテナプラットホームを強化

Microsoftが今日（米国時間4/10）、Googleが産み育てたコンテナオーケストレーションサービスKubernetesの上でアプリケーションを構築し管理するための、さまざまなツールを作っているDeisを買収したことを発表した。買収の価額は公表されていない。

なおDeisは2015年にEngine Yardに買収されており、したがってMicrosoftは実際には、Engine YardからDeisを買収したのである。

Microsoft Azureのコンテナサービスは、Mesos、Docker Swarmなどさまざまなコンテナオーケストレーションフレームワークをサポートしていたが、Kubernetesが急速にデファクトスタンダードになり、Microsoftも最近はKubernetesへの投資を増やしていた。コンテナがアプリケーションの構築とデプロイの方法を根本的に変えつつある現状では、Microsoftとしてもそのトレンドの最先端に付き添って行かざるをえない。

“最近では、コンテナ化したワークロードをAzure上でデプロイする顧客や、またそのことへの関心が爆発的に増えている。われわれとしても、Azureをコンテナのためのベストの場所にしていきたい”、とMicrosoftのクラウド/エンタープライズ担当SVP Scott Guthrieが今日の発表声明で書いている。“そのための活動の一環として、今回Deisの買収合意を発表できることは、とても喜ばしい。同社は、コンテナ革命の主役的な企業の一つなのだ”。

この買収の目的は明らかに技術の獲得だが、Kubernetesのベテラン技術者という希少財を路上で素手で見つけることはきわめて困難だから、今回MicrosoftはKubernetesに詳しい人材を一挙に大量に取得したことになる。

Deisの中核製品は、Kubernetesのデプロイを管理するための三つのオープンソースツールだ：まず、デベロッパーとオペレーションチームがコンテナ化アプリケーションを容易にデプロイし管理できるためのプラットホームWorkflow、そしてKubernetesのパッケージマネージャーHelm、そしてアプリケーション間通信をサポートするKubernetesネイティブのサービスブローカーStewardだ。そのほかの類似企業と同様に、同社のビジネスモデルも、これらのアプリケーションの有料サポートと教育だ。

Microsoft傘下になってからもチームはこれらのツールの開発とサポートを継続するが、現在のユーザーの中にはMozillaやCloudMine、SocialRadarなどもいる。MicrosoftのGuthrieによると、“Deisのチームは、オープンソース技術の深い経験をもたらし、Microsoftのの顧客の選択肢をさらに充実し、デベロッパーの生産性の向上に寄与していくことだろう”、という。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

CoreOSのコンテナ管理サービスTectonicがバージョンアップ、Kubernetesとコンテナの自動アップデートが容易に

CoreOSが今日（米国時間12/12）、Kubernetesを使用する同社のコンテナ管理サービスTectonicをアップデートし、Kubernetesとそれが管理するコンテナの両方を容易に自動アップデートできるようにした。

これまでは、Kubernetesのクラスタをダウンタイムなしでつねに最新状態に維持することは、意外に困難だった。CoreOSが“自動運転インフラストラクチャ(self-driving infrastructure)”と呼ぶ今回の新たなサービスでは、ユーザーの指定により、アプリケーションをダウンさせずに、Tectonicにこれらのアップデートを管理させられるようになった。CoreOSのオペレーティングシステム本体にはかねてから同様の機能があり、今回は同じ機能をTectonicとその上で動くアプリケーションに持ち込んだ形だ。最近のユーザーの使用状況にちなんで同社は、CoreOSをContainer Linuxとも呼んでいる。

アップデートの発表声明は、こう言っている: “企業は、オープンソースコミュニティの活発なイノベーションのペースに遅れずに追随し、自分たちのソフトウェアがつねに最新の機能と高度なセキュリティを提供していくことを、必要としている。自動運転インフラストラクチャは、前進アップデートと、ときには後退アップデートを、ボタンひとつでできることにより、これらの問題を解決している”。

今回のアップデートと並行して同社は、ノード数が10未満のユーザーはTectonicの使用を無料にする、と発表した。それ以上は、ノード数に応じての課金になる。これにより、これまでよりも多くのデベロッパーがこのサービスを試用できるようになり、その後彼らの企業に本格的に導入することを、同社は期待している。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

MicrosoftがAzure Container Service Engineをオープンソース化、Kubernetesのネイティブインテグレーションも発表

オープンソースのKubernetesコンテナ管理プロジェクトは、おそらく、今日利用可能なさまざまな競合するコンテナ管理サービスの中で最も人気があるものだ。Kubernetesのオープンソース側のホスト役を果たしているCloud Native Compute Foundationは、初めてのKubernetesカンファレンスを今週主催する。当然ながら、数日の内に私たちは相当な数のコンテナ関連ニュースを目にすることになるだろう。

その筆頭はMicrosoftである。同社はそのAzure Container Service（ACS）のコアエンジンのソースコードをオープンにするだけではなく、ACSに対するKubernetesのネイティブインテグレーションに関しても、そのプレビューを公開する。加えて、MicrosoftはMesosphere’s DC/OSへの対応も続けていて、DC/OSの最新版に対するサービスもアップデートする。

「コンテナが仮想化の次の進化です、組織をこれまでよりも更にアジャイルにしてくれるのです」と、MicrosoftのCompute for Azureの責任者のCorey Sandersは、本日のアナウンスの中に書いている。「私はこれを毎日のように顧客から教えられています！一度アプリを書けば、どこへでもデプロイすることができます。開発でも、テストでも、そして本番環境でも。コンテナはどのようなハードウェアでも、どのようなクラウドでも、そしてどのような環境でも変更せずに実行することができるのです。要するに、それらはアジャイルなDevOpsに対する真にオープンでポータブルなソリューションを提供してくれるのです」。

マイクロソフトは、ユーザーに対してコンテナのオーケストレーションプラットフォーム（Docker Swarm、DC/OS、Kubernetes）の選択肢を提供する戦略を続けている。Kubernetesに関しては、Microsoftはすでに最近の2年の間、そのインフラ上で、このGoogleがインキュベートしたコンテナ管理プラットフォームをサポートしていた。「今日は、私たちはこのサポートをさらに進め、Azure Container Service上のKubernetesのプレビューリリースをアナウンスします」とSandersは書いている。「この深くネイティブなKubernetesへのサポートは、Azure上におけるコンテナオーケストレーションエンジンに対する、また別の完全なオープンソースの選択肢を提供します」。

Microsoftはまた、コンテナイメージのためのプライベートリポジトリであるAzure Container Registryのプレビュー版を、11月14日にローンチすることも発表した。既にAzureの上に各自がプライベートなDocker Registryをセットアップすることはできていたが、それは手動プロセスで、開発者にリポジトリインフラストラクチャの管理を委ねるものだった。AmazonとGoogleの両者が、既にこの機能を提供していることを考えると、Microsoftが今この競争に参加してくることは驚きではない。

これに加えて、Microsoftはまた、Visual Studio、Visual Studio Team Service、およびフリーでオープンなVisual Studio Code Editorのような開発ツールから、マルチコンテナLinuxアプリケーションをデプロイするための、より沢山のツールを11月14日に提供することもアナウンスした。

[ 原文へ ]
（翻訳：Sako）

Kubernetesによるコンテナ管理をステートフルなアプリケーションにまで広げるCoreOSのOperatorデザインパターン…最初の2つの実装をオープンソース化

CoreOSが今日（米国時間11/3）、コンテナ管理の新しいコンセプトOperatorsを発表した。同社によるとそれは、コンテナの管理をより一層自動化することによって、Kubernetesを使用するプロジェクトの進捗を早める。しかも同社は、この技術をオープンソースにする。

CoreOSのCTO Brandon Philipsはこう説明する: “Operators（オペレーター）はその名のとおり、システムのオペレーション（運用）の部分を担当し、自動化する。具体的にはそれは、エンジニアやデベロッパーがスクリプトやランブック(run book, 操作指示書)の中に書く大量の知識、とくにドメイン固有の知識を、自動化するソフトウェアだ”。

Googleのオープンソースのコンテナ管理プロジェクトKubernetesは、広く使われている。小さなマイクロサービスをコンテナに収めることによって、デベロッパーは複雑なアプリケーションを独立した部品に分割し、これまでのプログラミングデリバリ技術に比べてはるかに効率的に動かすことができる。

CoreOSがOperatorsでやろうとしているのは、生半可なことではない。従来の作業では、一連の複雑なタスクを取り上げて、それらをユーザーのプロジェクトのホワイトボードビュー（構造図・流れ図）にまとめる。そのプロジェクトが、3つのサーバーから成るクラスターを必要とするとしよう。すると各サーバーのIPアドレスを知り、構成ファイルを作り、それを3つのマシンにコピーする。以上は多くのデベロッパーがかなりの時間を投ずる作業であり、プランが変わったときには手作業で調整しなければならない。Operatorsを使うと、デベロッパーはこれらの手作業のすべてを、一つの宣言文： “Launch three clusters”（3つのクラスターをローンチせよ）に要約できる。あとはいっさい、 Operatorがやってくれる。

データベースやモニタリングツールなどの複雑なアプリケーションでは，このことがとくに重要だ。Philipsの説明によると、Kubernetesは、単純でステートレスなアプリケーションのスケーリングは得意だが、もっと複雑なステートフルなアプリケーションでは、大量のスクリプトを人間が書かなければならない。Operatorsは、そのたいへんな作業をなくすことが目的だ。

たしかに、昨年本誌TechCrunchのCrunchNetworkでゲスト記事I want to run stateful containers too（ステートフルなコンテナも動かしたいね）を書いたDean Peterson（abecornの協同ファウンダーでミネソタ州雇用経済開発部のソリューションアーキテクト）も、こんな嘆きを述べている:

今のぼくの考えでは、MongoDBのようなステートフルなアプリケーションも、ステートレスなクライアントやサービスと一緒にコンテナで動くべきだ。そう言うぼくは、馬鹿かもしれないが、でもコンテナの価値はアプリケーション全体を容易にスケールできることにある、と思う。

今日の発表で、Petersonの素朴な夢が実現への一歩を踏み出した。それには、二つのOperatorsのオープンソース化が含まれる。最初のetcd Operatorは、etcdのクラスターを管理し分散化する。etcdはKubernetesのためのキー-ヴァリューストアで、CoreOSが作った。もうひとつのPrometheus Operatorは、オープンソースのモニタリングツールPrometheusで使って、Kubernetesのリソースをモニタする。

Philipsによると、この二つのローンチがきっかけとなって、コミュニティによるそのほかのOperatorsの開発が盛んになることを期待したい。この二つを実際に使ってみたら、誰もがその気になるだろう、と彼は言う。

“Operatorの基礎部分の多くは、Kubernetesのコミュニティが作った。彼らとうちとの、初めての協働で、ドメイン固有の知識をKubernetesの上で管理するやり方が、だんだん分かってきたんだ。これをいわばパターン（‘デザインパターン’）として、この便利な仕組みをもっと広げてほしい”、と彼は語る。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

CoreOSのOpenStackクラウドを15分でデプロイできるツールStackanetes（OpenStack+コンテナ+Kubernetes）がテクニカルプレビューに達す

6か月前に、小型のLinuxディストリビューションとコンテナ管理サービスを提供するCoreOSは、その複雑さで敬遠されがちなOpenStackによるプライベートクラウドを、コンテナと、Googleのコンテナ管理ツールKubernetesを利用して容易にデプロイできるやり方をデモした。そして今日（米国時間10/26）同社は、そのツールのテクニカルプレビューのローンチにまでこぎつけ、誰もがたった一つのコマンドで、Kubernetes上のOpenStackをわずか15分でデプロイできるようになった、と発表した。

この、OpenStackとKubernetesをセットにしたプロダクトは“Stackanetes”と呼ばれ、CoreOSのチームは残念ながらこの奇妙な名前を気に入っているのだが、OpenStackの最新リリースであるNewtonを使用し、そのプラットホームのすべてのインフラストラクチャサービスを揃えた完全な高可用性OpenStackデプロイメントをセットアップする。

しかしOpenStackのクラウドをセットアップしている企業の多くは、Mirantis, Canonical, HPEなどのサードパーティベンダを利用してミッションクリティカルなワークロードをセットアップしている場合がほとんどだから、15分自力セットアップを訴求するCoreOSの今回のプロダクトは、一種のスタントでもある。しかしこれにより、OpenStack/コンテナ/Kubernetesという組み合わせが、少なくともOpenStackのベーシックなデプロイを、これまでになく、大幅に簡易化することを、多くの人びとに見せつけることはできる。これまで、OpenStackを使うことなど考えたこともなかった企業すら、前向きの関心を示すかもしれない。

StackanetesはコンテナエンジンとしてDocke Engineではなく、それと競合するCoreOSのrktを使用し、クラスタオーケストレーションツールとしてKubernetesを用いる。またCoreOSのチームによれば、Kubernetes自身もそのキー-ヴァリューストアとしてCoreOSで育ったetcdを使用している。

CoreOSのこのプロダクトでは、OpenStackのクラウドをセットアップするために必要なKubernetesの全オブジェクトが、約300行のYAMLのマークアップで定義されている。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

CoreOSがRedspreadをチームに加えてTectonicによるコンテナ管理を一層容易に

CoreOSが今日（米国時間10/17）、Redspreadのファウンダー（複数）を雇用したことを発表した。Y Combinatorで育ったRedspreadは、Kubernetesのコンテナクラスタによるソフトウェアのデプロイを手伝う、サービスやツールを提供している。今回のトップ引き抜きにより、RedspreadのオープンソースツールもCoreOSの傘下になる。

今日の発表では、RedspreadがCoreOSに“参加する(joining)”となっていて、CoreOSのスポークスパーソンは“参加する”の意味をはっきり言わない。はっきりしているのは、Redspreadの協同ファウンダーでCEOのMackenzie Burnettと、CTOのDan GillespieがCoreOSのチームに加わり、同社のオープンソース製品をCoreOSが管理する、ということだけだ。

Crunchbaseによると、Redspreadはこれまで24万ドルの資金を調達しており、また今回の“参加”に際して、ある程度のお金が動いたものと思われる。

Redspreadの主力製品であるSpreadは、Kubernetesによるクラスタを容易にデプロイし、Dockerコンテナ群を実稼働状態（プロダクション状態）までもっていく、コマンドラインツールだ。Spreadはユーザーのインフラストラクチャのバージョン管理を行い、必要なら旧バージョンへのロールバックもやってくれるが、そのために内部でgitを使用している。

CoreOSにはKubernetesによるコンテナのデプロイと管理を助けるツールTectonicがすでにあるが、Redspreadのコラボレーション的デプロイツールは、Tectonicに統合される予定だ。

CoreOSのCEO Alex Polviは、発表声明でこう述べている: “RedspreadがCoreOSに参加してくれたことに、ワクワクしている。その優れたチームが来てくれたことによって、ユーザー企業のためのKubernetes開発で弊社は、ますます優位に立てる。またKubernetesの利用は、Tectonicの利用によっても、なお一層容易になる。”

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））