DatadogのコンテナマップはKubernetesアプリケーションの内部〜各コンテナの可視性を提供

コンテナへ移行する企業が増えている中で、個々のコンテナと、それがアプリケーションに与えているインパクトをモニタすることが、課題になっている。それがとくに難しいのは、コンテナがきわめて短時間だけ存在する短命な実体だからだ。モニタリングとアナリティクスの専門企業Datadogは今日(米国時間5/3)、この問題を解決するための視覚化ツール、コンテナマップを発表した。

Datadogのプロマネ担当VP Ilan Rabinovitchはこう語る: “コンテナマップはユーザーのシステムにあるすべてのコンテナを見せる。顧客はすべてのコンテナを、どんなときでも見られて、それらをタグに基づいてグループ化し、その中で起きていることを詳しく知ることができる”。

同社はタグとメタデータを利用してコンテナの各部とそれらのお互いの関係、そしてそれらを支えるインフラストラクチャを識別する。そのツールはコンテナを、Datadogのそのほかのエンティティとまったく同じようにモニタする。

同社のブログ記事は、こう書いている:

“ホストマップが個々のインスタンスに対してするように、コンテナマップはメタデータを使ってコンテナを容易にグループ化し、フィルタし、点検できる。メタデータは、サービス、可利用性ゾーン、ロール、パーティション、そのほかのユーザーが望む特質など、何でもよい”。

問題が見つかったとき、Datadog自身が顧客企業のシステムにライト(write)アクセスして問題を修復することはしないが、その企業はWebhookや、あるいはAmazon Lambdaのファンクションのようなサーバーレスのトリガを使って、何らかのアクションを呼び出すことができる。

  1. container-inspect

  2. container-list

  3. dashboard

同社は、すべてのコンテナが正常に動作していることを監視するサードパーティにすぎない。“コンテナに対してやるべきことは、もっぱらKubernetesを信用している。でも異状が起きたら、何が起きたのかを知らなければならないが、それはKubernetesにできることではない”、とRabinovitchは語る。この新しいマップの機能は、コンテナシステムの内部に対する、その欠けていた可視性を提供し、ユーザーは個々のコンテナの内部を詳細に調べて、問題の原因を特定できる。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

クラウドホスティングのDigitalOceanもついにコンテナプラットホームを提供

誰もが気軽に使えるクラウドホスティングサービスDigitalOceanが、そのメニューにコンテナサービスを載せた。同社は今でも、安価な仮想プライベートサーバーのホスティングサービスとしていちばんよく知られているが、同社自身はそのうち、クラウドコンピューティングの世界でメジャーになるつもりだ。ホスティングは、そのプランの最初の部分にすぎない。たとえば同社のストレージサービスSpacesは、同社の夢が本気であることを示す一例だ。

しかし今や、コンテナを避けて通れない世の中になっているので、同社が今日(米国時間5/2)、Kubernetesベースのコンテナサービスを立ち上げたのも、もはや意外ではないだろう。

このサービスはまだ初期のプレビュー段階で、ここからサインアップできるが、一般公開は今年の終わりごろだ。

DigitalOceanのプロダクト担当VP Shiven Ramjiはこう述べている: “私たちはいつも、デベロッパーのためのシンプルなソリューションに専心してきた。その最初のプロダクトが、クラウドサーバーDropletsだった。今度のプロダクトも、その例外ではない。デベロッパーは自分のアプリケーションを完成させることに専念でき、複数のアプリケーションにまたがるスケーラビリティの高い安全なクラスターを作って動かすことに伴う、複雑な作業は免除されるのだ”。

そのサービスはDigitalOcean Kubernetesと名付けられ、それによりデベロッパーは、自分のコンテナワークロードをDigitalOceanのプラットホームでデプロイし管理できる。大手のクラウドコンピューティングプロバイダーのほとんどすべてが提供している競合製品と同様に、DigitalOceanのプロダクトも、Kubernetesを動かすことに伴う複雑性の大部分を、抽象化してデベロッパーからは見えなくする。しかし必要ならユーザーは、KubernetesのAPIにフルアクセスして、独自の隔離されたKubernetesクラスターを作れる。

このサービスは同社の既存のサービス、ストレージやファイヤーウォールツールなどを統合している。デベロッパーは自分のコンテナを、DigitalOceanの標準のノードで動かすか、あるいはより強力で計算能力の高いノードで動かすかを、選択できる。また“teams”という機能で、アクセスコントロールができる。さらに、こういうサービスの通例として、通常のパフォーマンスアナリティクスやロギングの機能もある。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

コンテナを安全に隔離するサンドボックス化コンテナランタイムgVisorをGoogleがオープンソースで提供

コペンハーゲンで行われているKubeConのおかげで、今週はコンテナの週、とくにKubernetesの週だ。Kubernetesは、Googleにおけるコンテナの使用から生まれたので、このショウもやはりGoogleからの発表が多い。その中でいちばんおもしろいのが、gVisorのローンチだろう。それはサンドボックス化されたコンテナランタイムで、コンテナ間の安全な隔離を確保する。

‘..Visor’という名前を見て、ぴんと来た方もおられると思うが、gVisorは仮想マシンを隔離して制御するハイパーバイザー(hypervisor)にちょっと似ていて、仮想マシンではなくコンテナを隔離する。コンテナを使うワークロードのセキュリティを確保したい企業には、とくに関心があるだろう。それは、Kubernetesの世界でも未だに問題なのだ。

今日の発表は、こう言っている: “互いにヘテロで信頼性の乏しい複数のワークロードを同時に動かしたいという欲求が、ますます強くなっている。そのために、サンドボックス化され隔離されたコンテナへの関心が生まれている。それは、ホストOSとコンテナの中で動くアプリケーションとの間に安全な隔離境界のあるコンテナだ。gVisorは、アプリケーションのシステムコールを横取りしてゲストカーネルとして動作し、しかも終始、ユーザー空間で動く”。

gVisorに加えてGoogleは、Stackdriver MonitoringにおけるKubernetesのサポートをローンチした。この、まだベータの新サービスは、複数のクラウドやオンプレミス環境にまたがるKubernetesアプリケーションのステートを、すべて一箇所にまとめたビューを与える。ただしGoogle Cloudの外では、すべてがスムーズに動くためにちょっとした統合作業が必要だ。

〔参考: サンドボックス解説

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

RedHatのCoreOSがKubernetesアプリケーションを管理するツールキットを発表

Red Hatが今年初めに2億5000万ドルで買収したLinuxディストリビューションとコンテナ管理のスタートアップCoreOSが今日(米国時間4/30)、Kubernetesのクラスターを管理するオープンソースのツールキットOperator Frameworkを発表した

CoreOSがソフトウェア概念としてのOperatorについて最初に言及したのは、2016年だった。その考え方は、コンテナベースのアプリケーションをデプロイし管理するためのベストプラクティスをコードとして実装することだった。“まあOperatorとは、最良のオペレーター社員を絵に描いたようなものだ”、とRedHatのOpenShiftのプロダクトマネージャーRob Szumskiは語る。理想としては、Operator Frameworkはオペレーションのチームをあらゆる雑用や単純労働から解放して、高いレベルのタスクに集中させる。そして同時に、Operatorがつねに会社のルールブックに従うことによって、その過程からエラーしがちな人間を取り除く。

CoreOSのCTO Brandon Philipsは、今日の発表声明でこう説明している: “Kubernetesを最大限に有効利用するためには、Kubernetesの上で動くアプリケーションをサービスし管理するための一連の統一的なAPIを広げる必要がある。われわれはOperatorを、Kubernetes上のそういうアプリケーションを管理するランタイムだ、と見なしている”。

Szumskiによれば、CoreOSのチームは、同社独自のTechtonicコンテナプラットホームを作って管理するときに(そのユーザーコミュニティからのものも含めて)、これらのベストプラクティスを開発した。それらがコードとしてのOperatorとして動くようになると、Kubernetesのクラスターを監視し、アップデートを処理し、たとえば何かがおかしくなったら、数ミリ秒以内にその不具合に反応する。

全体としてのOperator Frameworkは、三つの部分から成る。1)実際のOperatorを作ってテストしてパッケージするためのSDK、2)OperatorをKubernetesのクラスターにデプロイしてそれらを管理するためのOperator Lifecycle Manager、そして、3)チャージバックや顧客への課金を必要とする企業のためにKubernetesのユーザーを(リソース使用量などを)計量することだ。

軽量ツールは全体の絵の中ではつけたり的だが、Szumskiによると多くの企業がそれを求めるのであり、CoreOSもKubernetesでそれをやるのはうちが初めて、と主張している。

今日のCoreOS/Red Hatによる発表は、今後各方面から、さまざまなKubernetes関連の発表が行われそうな週の、始まりにすぎない。数日後にはCloud Native Computing FoundationのデベロッパーカンファレンスKubeConが始まるし、そこではコンテナのエコシステムに帰属する企業のほとんどが、何かを発表すると思われるからだ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

HeptioがKubernetesとOpenStack用のロードバランサーをオープンソースでローンチ

Heptioは、コンテナのエコシステムの中でおもしろい企業のひとつだ。まず同社は、Kubernetesを作った三人の技術者のうちの二人、Craig McLuckieとJoe Bedaが作った企業だ。しかしそれだけでなく、同社が開発している技術と、これまで調達した巨額の資金も、注目に値する。

同社の今日(米国時間4/23)の発表によれば、2018年第一四半期の売上は前四半期比で140%増加した。さらにまた、社員数は2017年の初めに比べて4倍に増加した。元の数の発表がないから、これらが実際にどれだけすごいことかよく分からないが、なにしろ同社が好調で、今急成長中のKubernetesのエコシステムに自分の足場をしっかり築きつつあることは分かる。

これらの数字の発表と並んで同社は今日、新しいオープンソースプロジェクトのローンチを発表した。それは、クラスターリカバリツールArkや、KubernetesのクラスターモニタリングツールSonobuoyなど、同社の既存のツール集合に、新たに加わるものだ。

そのHeptio Gimbalと呼ばれる新しいツールは、そのユースケースが非常に特殊で、少数のユーザーにしか関心がないと思われるが、でも彼らにとってはライフラインだ。GimbalはYahoo Japaの子会社Actapioとの共同開発で、エンタープライズがトラフィックをKubernetesのクラスターやOpenStackのデプロイへルートするタスクを助ける。多くのエンタープライズが今ではこれらの技術を並列で動かしていて、一部はOpenStackを超えてもっとKubernetes中心のアーキテクチャへ移行しつつあるが、でもOpenStackへのこれまでの投資の成果を今すぐ完全に捨て去る気はない。

ActapioのCEO Norifumi Matsuyaはこう述べている: “われわれがHeptioにアプローチしたのは、OpenStackなどのバックエンドシステムへのこれまでの投資を無駄にすることなく、自分たちのインフラストラクチャをKubernetesで現代化したかったからだ。アプリケーションを大きなスケールでデリバリすることが、うちのビジネスにとってもっとも重要だ。そのためには、より高速なサービスディスカバリーと、即時のロールバックとパフォーマンスの測定を可能とするカナリア分析を伴う、デプロイメント能力が必要だった。Gimbalはわが社のデベロッパーたちに、これらのチャレンジへの対応能力を与え、彼らの生産性を上げるとともに、システムのパフォーマンスを最適化する”。

GimbalはHeptioの既存のオープンソースツールの多くを利用し、またCloud Native Computing Foundationのクラウドネイティブプロジェクト群の一つであるEnvoyプロキシも使っている。今のところGimbalは、OpenStackの2016年のMitakaリリースのみサポートしているが、今後はVMwareやEC2もサポートしていく予定だ。

〔・Heptio関連記事:
Kubernetesによるコンテナクラスターのプロダクションレベルのデプロイを「安全化」するHeptioのオープンソースプロジェクト
Kubernetes展開お助けサービスで起業したHeptioが創立1年足らずでシリーズB $25Mを調達
オープンソースのライセンスをレビューするOpen Source InitiativeにMicrosoftが参加
HeptioとMicrosoftが共同でKubernetesのバックアップ/災害復旧ソリューションに取り組む

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

KubernetesをCloud Foundryが本格採用して両社の仲がより密接に

コンテナがソフトウェアの世界を食べている。そしてKubernetesがコンテナの王様だ。そこで、大きなソフトウェアプロジェクトに、とくに企業で関わる人は、いずれこの王様とお近づきになる。今ボストンで、半年に一度のデベロッパーカンファレンスをやっているCloud Foundryも、その興味深い例のひとつだ。

エンタープライズデベロッパーの世界の外にいる人にとっては、Cloud Foundryは馴染みのない名前だが、今ではFortune 500社の約半数がユーザーだ(スタートアップのユーザーはあまりいない)。Cloud Foundryをよく知らない人は、Herokuに似ている、と思ってもよい。ただしそれは商用ユーザーの大きなエコシステムのあるオープンソースのプロジェクトで、そのどんなクラウドやオンプレミス上のインストールでも、そしてどんなに大きなスケールでも、動かすことができる。デベロッパーは自分のコードを(Twelve-Factorの方法論–日本語–に従って)書き、実行に必要なものを定義すると、それが動くためのインフラや、必要なスケーリングについては、すべてCloud Foundryが面倒見てくれる。デベロッパーは自分のアプリケーションをどこで動かすか、どうやってもっと効率的に動かすかなどを、考えなくてよい。

それだけのことを可能にするためにCloud Foundryは、Dockerなどがまだ存在しない、きわめて初期のころからコンテナを導入した。そのころKubernetesはまだなかったので、Cloud Foundryに関わっているさまざまな企業が一緒になって、独自のコンテナオーケストレーションシステムを作った。それは今日のサービスでも利用されている。しかし、コンテナベースの開発が普及するに伴い、Cloud Foundryのエコシステムでも、Kubernetesをサポートせよ、という声が高くなった。昨年Foundationはその方向への第一歩を踏み出し、コンテナを管理するための、KubernetesベースのContainer Runtimeをローンチした。それが、これまでのApplication Runtimeの隣に座る。これによってデベロッパーは、Cloud Foundryを使って、彼らが開発する新しいサービスと並列に、彼らの新旧の一枚岩的なアプリケーションを動かし管理することもできる。

でも、Cloud FoundryではApplication Runtimeのための同団体独自のコンテナサービスをなぜ使い続けるのだろうか? 今ではKubernetesやそのほかの各種プロジェクトが出揃ってきて、それらがコンテナを扱うためのデフォルトになっているから、そんなことをする理由はないはずだ。そこで、当然とはいえ、今では、古いコンテナ管理システムをなくして、それらをKubernetesで置き換えていくCloud Foundryのプロジェクトがある。今やコンテナ管理の部分は、Cloud Foundryの差別化要因ではない。むしろ、Cloud Foundryの最大の差別化要因はデベロッパー体験であり、Cloud Foundryのそもそも中心的メリットは、デベロッパーがインフラストラクチャの内部構造をまったく気にする必要がない、という点にある。

Cloud FoundryのエコシステムがKubernetesに傾くことには、もうひとつの側面がある。Cloud Foundryも同じくソフトウェアだから、それをKubernetesの上で動かして悪い理由はない。だから、SUSEやIBMなど、Cloud Foundryの最大のベンダーたちの一部も、まさにそうしている。

Cloud Foundryの公認ディストリビューションであるSUSE Cloud Application Platformは、どのパブリッククラウドのKubernetesインフラストラクチャの上でも動く。それにはMicrosoftのAzure Container Serviceも含まれる。SUSEのチームによると、その方がデプロイが容易であるだけでなく、リソースの節約にもなる(アプリケーションがより少ないリソースで動く)。

同じくIBMも、今では顧客にKubernetesの上でCloud Foundryを提供している。ただしそれはまだ、実験段階だそうだ。IBMのCloud Developer ServicesのゼネラルマネージャーDon Bouliaが強調するのは、IBMの顧客の多くは自分たちのワークロードを、IBMのそのほかの顧客に共有されない隔離された環境で動かしたがることだ。

Bouliaによれば、多くの顧客に、KubernetesかCloud Foundryか、という視点はない。彼の顧客の多くにとっては、Kubernetesを使うことが即、自分たちの既存のアプリケーションをクラウドへ移すことだ。そして新しいアプリケーションに関しては、Cloud Foundryを動かすことを選ぶ。

SUSEのチームも、同じことを強調している。SUSEの顧客のひとつのパターンとして、彼らはコンテナ環境をセットアップしたくてSUSEにやってくるが、しかしその商談の過程で、Cloud Foundryを実装することを決心するのだ。

というわけで、今週のイベントのメッセージはまさに、KubernetesとCloud Foundryが互いに補完的な技術だ、ということだ。そのイベントのパネルディスカッションで、GoogleのContainer EngineとKubernetes担当技術部長Chen Goldbergも、その点を強調した。

Cloud Foundry Foundationと、KubernetesのホームCloud Native Computing Foundation(CNCF)は共に、Linux Foundationの傘下にある。しかしCloud FoundryはCNCFに比べて圧倒的にエンタープライズユーザーの比重が大きい。そこには何らかの政治が絡んでいるのかもしれないが、でも両団体は互いに十分に友好的で、メンバーも相当重複している。PivotalのCEO Rob Meeは、本誌のRon Millerの取材に対してこう述べた: “うちは半分CNCFで半分Cloud Foundryだ。二つのコミュニティはますますいろんな技術を共有し合っているし、共に進化している。完全に独立でもないし、競争関係もない。関係はもっといろいろ複雑で微妙だ。CNCFとCloud Foundryはどちらも、大きなエコシステムの部分であり、互いに補完し、収束している”。

つまりCNCFとCloud Foundryの技術共有と、もしかしてコラボレーションは、今後も増えるということだろう。CNCFはクラウドネイティブなアプリケーションを作るための、とてもおもしろいいろんなプロジェクトのホームであり、そしてそれらのユースケースの多くはCloud Foundryにもある。

関連記事: Cloud Foundry財団、Alibabaがゴールド会員に――中国のクラウドのオープンソース化加速へ

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

FargateによってAWSはコンテナをもっとクラウドネイティブにしたい(Kubernetesなどのインフラを完全抽象化)

AWSのデベロッパーカンファレンスre:Inventは、たくさんの発表があるので、同社自身の重要な新製品の、影が薄くなってしまうこともある。同社の待望のElastic Container Service for Kubernetesはかなり大きく報道されたが、より斬新なコンテナサービスであるFargateローンチは今もまだ、あまり知られていない。

今週たまたま会う機会があったAmazonのCTOでAWS担当VP(そしてEDMの熱心なファン) Werner Vogelsも、それを認める。彼曰く、“Fargateはそのほかの発表の下に埋もれてしまったようだ。しかしそれは、コンテナをもっとクラウドネイティブにするための重要なステップだと思うし、すでにかなりの数の顧客がFargateを採用している。”

Fargateは、AWSのコンテナサービス、Elastic Container Service(ECS)やElastic Kubernetes Service(EKS)のために、コンテナを動かすためのインフラストラクチャを抽象化する技術だ。ユーザーはコンテナオーケストレーションエンジンを指定するだけで、あとのことはこのサービスがやってくれる。個々のサーバーやクラスターをユーザーが管理する必要はない。むしろユーザーは単純に、ECSやEKSに、Fargateでコンテナをローンチすると告げ、そのアプリケーションのCPUとメモリの要求を定義し、あとはサービスにまかせる。

Fargateに関する長いブログ記事を今日(米国時間4/11)発表したVogelsにとってこのサービスは、デベロッパーが、インフラを気にせずに自分のアプリケーションだけに集中できるようにするというAWSのミッションの一環だ。彼曰く“クラウドの初期のころを、よく思い出す。AWSが登場するまでは、クラウドから仮想マシンを提供するサービスしかなかったんだ。多くの企業がそれを利用してビジネスを築き成功させてきたが、でも仮想マシンを動かすときには、依然としてハードウェアを管理しなければならない。[…] われわれがAWSのクラウドコンピューティングサービスの中核であるECSをかつて導入したときに起きたことの一つは、いろんなものをハードウェアから切り離してしまったことだ。[…]それによってデベロッパーの生産性は、ものすごく上がったと思うね”。

しかしAWSやECSの上でコンテナを動かそうとすると、初期のコンテナツールでは、コンテナを実際に動かすこととは無関係な多くのことを、やらなければならなかった。“それは、クラウドの初期と同じだ”、とVogelsは語る。“仮想マシンがコンテナにとってのハードウェアになってしまっている。デベロッパーはコンテナのオーケストレーションのために、VMを相手に大量の作業をしなければならない”。

しかしAmazonの顧客が求めるのは単純に自分のコンテナを動かすことだけだ。Vogelsの言う“ハードウェアに直接触(さわ)るような管理作業”なんか、やりたくない。“それはまるで、クラウド以前の時代に戻ったみたいだ”、とVogelsは述べ、そして今日のブログ記事では、“コンテナのオーケストレーションは、あまりクラウドネイティブではない、といつも感じていた”、と言っている。

Vogelsは、インフラストラクチャを気にしなければならないならそれはクラウドネイティブではない、と考えているようだ。彼によると、AWSの最初の約束は、インフラストラクチャに関してはAWSが面倒見るからデベロッパーはビジネスにとって重要なことだけに専念すればよい、というものだった。その哲学をさらに徹底したサービスがFargateであり、Lambdaだろう。

ECSやEKSのようなクラウドサービスがあっても、クラスターはまだ完全に自動的に動くわけではなくて、つねに必要とはしない能力や容量でも、ユーザー自身が確保(プロビジョニング)しなければならない。Fargateの約束は、そのようなスケーリングを自動化し、ユーザーは実際に必要とする能力と容量だけに支払えばよい、という状態にすることだ。

Vogelsはこう言う: “顧客は、ソフトウェアを作りたいだけだし、自分のアプリケーションを作りたいだけだ。このコンテナをどの仮想マシンに置くか、なんてことで悩みたくはない。でも今は、デベロッパーがそれをやっている。Fargateがあれば、ユーザーはタスクに対するCPUのタイプを指定するだけで、スケーリングは自動的に行われる。実際に使う能力容量に対してだけ、支払えばよいのだ”。

インフラの抽象化という点では、Fargateはコンテナのためにそれをやるのだが、AWS Lambdaのようなプロダクトはもっと徹底している。それは Vogelsにとってはひとつの連続体であり、顧客の要望が生んだものだ。今のAWSはコンテナをきわめて重視しているが、彼の現実的な見方によれば、近未来がコンテナ一色に塗りつぶされてしまうわけではなくて、VMを必要とする開発ニーズも残る、VMはなくならない、という。

Lambdaのようなサーバーレスのプロダクトでは、インフラストラクチャのことをまったく考える必要がない。コンテナのことすらも。ユーザーはただ単に、やりたい処理を指定するだけだ。そしてそのコードの実行に対して支払う。しかもVogelsの視界の中では、VMとコンテナとサーバーレスは一つの連続体の各部だ。顧客は、そのどれからどれへ移行してもよい。彼によると、今ではコンテナを完全に飛び越えて、何もかもサーバーレスで行くエンタープライズも見かけるようになった、という。

〔関連記事: 昨年のre:InventにおけるFargateの発表

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

GitLabがGoogleのKubernetes Engineを統合、コンテナアプリケーションのデプロイが超簡単に

今や多くの人が使っているVCSのGitを、独自にホストしているサービスとして人気の高いGitLabが、最近とくに好調だ。わずか2週間前にはGitHubとの統合を発表したが、今日はGoogleのKubernetes Engine(GKE)を統合してクラスターの展開を自動化し、ユーザーであるデベロッパーが自分のアプリケーションをほんの数クリックでデプロイできるようにした。

この機能を作るために同社はGoogleと協働したが、しかしこの統合はGitLabに前からあるAuto DevOpsツールを大々的に使っている。それは、コンテナを扱うためのよく似た機能をすでに提供していた。Auto DevOpsは、CI/CDパイプラインのセットアップやコンテナへのデプロイなど、面倒な仕事をすべて引き受けることをねらっている。

しかし、“GKEを統合する前は、GitLabのユーザーは自分のクラスターを管理するためにKubernetesの深い理解を必要とした”、とGitLabのCEO Sid Sijbrandijは今日の発表で述べている。“Googleとの協働により、われわれのユーザーはGoogle Cloud Platform上に、管理サービスを伴うデプロイ環境をセットアップし、GitLabの堅牢なAuto DevOpsの能力を利用することが簡単になった”。

このGKEの統合を利用するためには、デベロッパーはGitLabから自分のGoogleアカウントに入るだけだ。GKEがクラスターを自動的に管理するので、デベロッパーは自分のアプリケーションを書くことに集中でき、デプロイと管理はGitLabとGoogleにまかせられる。

この新しい機能はGitLab 10.6 releaseの一部として、GitLabの全ユーザーが今すでに利用できる。

〔この記事の日本語訳。〕

 

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

NvidiaのGPUによる高速化技術がついにKubernetesをサポート

やっと、という感じだが、NvidiaのCEO Jensen Huangが今日(米国時間3/27)、彼のGTC(GPU Technology Conference)キーノートで、Googleで生まれ育ったコンテナオーケストレーションシステムKubernetesをNvidiaのGPUでサポートする、と発表した。

その意味は、何百何千ものGPUが機械学習処理の高速化などのために使われているような、いわゆるハイパースケールなデータセンターでGPUの使用を最適化し、デベロッパーがコンテナをなんの変更も加えずに複数のクラウドへデプロイできるようにする、ということだ。

Jensenはこう言った: “今やフレームワークは高速化し、コードも高速化した。では、それをデータセンターの世界へデプロイするにはどうするのか? そうだ、そこにはうまい具合に、Kubernetesというものがある。良かった!すごく良かった!”。

NvidiaはKubernetesのGPUによる高速化技術とそのコードを、オープンソースのコミュニティに寄贈する。機械学習のワークロードは、計算とデータの両方で巨大なものになりがちだ。Kubernetesはそんなワークロードのオーケストレーションを助け、そして今や、その仕事にGPUを使える。

Huangは次のように述べて、会場からの笑いを誘った: “Kubernetesは今やGPU対応だ。DockerのコンテナはGPUが加速する。そして私がこれまで名を挙げたようなフレームワークはすべて、GPUで加速される。そしてまた、みなさんが抱え込んでいる推論のワークロードもGPUが加速する。そしてこれらのクラウドのすべてでNvidiaのGPUが動く。そしてさらに、すばらしいオーケストレーションのレイヤとしてKubernetesがある。完全に満たされた人生だね”。

KubernetesのGPUによる高速化は、今日の発表以前にもある程度サポートされていた。たとえばGoogleは、そのKubernetes EngineですでにGPUをサポートしている。

 

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

IBMがセキュリティやDDoS防御でCloudflareとパートナー、サービスの内製を選ばず

最近の数年間でCloudflareは、データセンターの立地とパートナーシップでグローバルなネットワークを築き、同社のDDoS防御やセキュリティツール、Webサイトの加速、などのサービスを拡大してきた。これだけの専門的能力は簡単に得られるものではないので、IBMのような巨大グローバル企業でさえ今日(米国時間3/13)、内製よりもむしろCloudflareとのパートナーシップにより、これらのサービスを顧客に提供していく、と発表したのも、不思議ではないかもしれない。

IBMが新たに始めたCloud Internet Servicesは今日発表され、サイトの保護と高速化のためのCloudflareのサービスをすべて提供する。IBMはこの発表を、来週行われるTHINKカンファレンスの前、というタイミングで行っているのだ。

IBMのWatsonとクラウドを担当するCTO Bryson Koehlerによると、IBM Cloudのユーザーは、一回のクリックでこれらの機能をonにできる。“Cloudflareは、ワールドクラスのツールセットを作るすごい仕事をしている。それらは使いやすいだけでなく、うちのチームが使っているのと同じスタンダードに従っている”、と彼は語る。“今日のように、変化が早くてサービスがつねに進化しているときには、いつも内製かパートナーかという決定を迫られる。そしてキャッシングやロードバランシングでは、彼らがうちとのパートナーシップにふさわしい仕事を成し遂げている”。

このパートナーシップに加えてIBMは今日、二つの新しいセキュリティ機能を発表した: それはIBM Cloud Security Advisorと、IBM Cloud App IDの新しい機能だ。Cloud Security Advisorは、デベロッパーとオペレーションの両チームに、彼らのセキュリティ態勢への、これまでよりも多くて深いインサイトを提供する。その中には、Webサーバーのセキュリティ証明がそろそろ期限切れだというベーシックなアラートがあったり、あるいはアプリケーションとデータに影響を与えるIBMのグローバルネットワーク上に兆候のある脅威に関する警報だったりする。このツールは十分高度に作りこまれているので、たとえば特定の規制に従ってデータを管理しなければならないデベロッパーが、うかつにPCIやHIPAA準拠のサービスからデータをロードし、それを非準拠のサービスに書き出す、といった事故を未然に防ぐことができる。

Cloud Security Advisorはまだ実験段階のプロダクトだが、必要なすべてのデータを単一のダッシュボード上に表示する。

App IDの方は、正しい認証を経たユーザーだけが、アプリケーションやデータにアクセスできるようにする。とくに新しい機能ではないが、IBMはこのサービスを今後、コンテナやIBM Cloud Container Serviceにも適用する。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

IBMがベアメタルKubernetesを発表

コンテナは急速に、新しいアプリケーションをクラウドに導入するための標準的な方法になりつつある。これは歴史の古い企業でも同様である。このため主要なクラウドプロバイダーのすべてが、コンテナに力を入れていても不思議はないが、その中でも特にオープンソースのKubernetesコンテナオーケストレーションサービスに力が注がれている。IBMも長い間自身のCloud Container Serviceを通してそのサービスを提供してきた。そして本日(米国時間3月13日)業界初となる、ベアメタルKubernetesをマネージドサービスとして提供し始めた。

なぜそれが重要なのだろう?ベアメタルサーバー上でコンテナを実行するとパフォーマンスが向上し、開発チームはコンテナを実行したいマシンを選択することができる。同時に、他の顧客と共有していないマシンでコンテナを実行することで、通常のコンテナサービスを実行するときには得られない、一段上のセキュリティと分離のレイヤーを実現することができる。

IBMのWatsonならびにCloudのCTOであるBryson Koehlerによれば、このことによってGPUをマシンに装着することが可能になり、多くの企業が実験を始めている、機械学習やハイパフォーマンス計算ワークロードの実行が可能となる。「企業がクラウドに移行させようとしているワークロードの種類を見ると、ベアメタルは分離性と柔軟性の面で大きな恩恵をもたらします」とKoehlerは私に語った。

他のIBM Cloud Container Serviceと同様に、これはフルマネージドサービスであり、自動アップデートとセキュリティパッチが適用される。

[ 原文へ ]
(翻訳:sako)

Image Credits: Kittikorn / Getty Images

GoogleがUbisoftと協働でオープンソースのゲームサーバーホスティングシステムAgonesをローンチ

クラウドコンピューティングといえば、ドキュメントをクラウドで編集したり、CRMシステムをアップデートしたりするための大規模なサーバーファームを連想する人が多いだろう。でも嬉しいことにクラウドには、遊びの側面もある。マルチプレーヤーゲームも、すべてどこかのクラウドで動いている。ゲーム企業は、これらのサーバーを動かすためのシステムを自分で作ることが多いが、しかしGoogleとUbisoftは今日(米国時間3/13)、マルチプレーヤーゲームのサーバーを管理しホスティングするためのオープンソースのシステムを提供する新しいプロジェクトを発表した。

そのプロジェクトの名前Agonesは、ギリシア語で“コンテスト”という意味だ。それはGoogleが育てたコンテナプロジェクトKubernetesを、マルチプレーヤーゲームサーバーの艦隊をオーケストレーションしスケーリングするための中核的なツールとして使用する。ユーザーが自分が好きなマルチプレーヤーゲームをプレイするときには、そんな大軍のゲームサーバーがあるおかげで、島にいる自分以外の99名のマニア的プレーヤーと互いに相手を見つけたり対戦したりできる。サーバーはゲームだけでなく、いかさまを見抜くためのソフトウェアを動かすこともある。コンテナがこの種のシナリオにとって理想的なのは、ゲームの個々のセッションは短時間で終わるものが多く、ひとつのコンテナでひとつのセッションを表せば、デプロイもシャットダウンも迅速にできるからだ。

Ubisoftの開発部長Carl Dionneは、こう書いている: “プレーヤーがゲームに集中できるためには、クォリティの高い、最高にシームレスなサービスを提供しなければならないし、そのための方法をたえず改良していく必要がある。Agonesが備えている柔軟性により、専用のゲームサーバー群を最適なデータセンターで動かすことができ、われわれのチームに、彼らが必要とするリソースのより強力かつ詳細なコントロールを与える。両社のコラボレーションによって、Kubernetesの大規模デプロイに関するGoogleの専門的能力と、われわれのゲーム開発パイプラインと技術に関する深い知識を、結びつけることができる”。

Agonesは要するに、ゲームサーバーを動かすために必要なツールでKubernetesを拡張したものだ。そのツールには、ゲームサーバーのためにカスタム化されたKubernetes Controllerと、同じくカスタムのリソース定義が含まれる。Agonesのチームによると、デベロッパーは、ペアのゲーマーを互いに引き合わせるデベロッパー独自のマッチメイキングサービスと標準のKubernetes APIsを容易に統合して、ゲームサーバーを始動できる。

Googleとしてはデベロッパーが自分のゲームをGoogle Kubernetes Engineでホストしてくれると嬉しいところだが、しかしAgones自身はクラウドを特定せず、どんなクラウドでも、あるいはオンプレミスでも、使用できる。

今日のリリースは、あくまでも初期的な形だ。しかしv2に向けてのロードマップはすでに作成中であり、チームによると、そこではゲームサーバーの集合体(Fleets)のような新しい機能や、ゲームサーバーのパフォーマンス分析、ノードの自動スケーリングなどが導入される予定だ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

Google Kubernetes Engineのコンテナ用GPUが公開ベータへ

GoogleのKubernetes Engine旧: ‘Google Container Engine and GKE’)では、これからすべてのデベロッパーが自分のコンテナにNvidiaのGPUをアタッチできる。

そのGPUs on GKE(←これはGoogleがよく使っていた頭字語だが、今はあまり使われていない)は、これまで半年あまり、非公開アルファで提供されていた。しかし今度からそのサービスは公開ベータになり、機械学習アプリケーションなどのワークロードを動かしたいデベロッパーが誰でも、GPUの力を利用できる。Googleによるとこのサービスは、Tesla P100とK80 GPUs の両方へのアクセスを提供する。それらはどちらも現在、Google Cloud Platformで利用できるGPUだ。

コンテナとGPUという組み合わせのアドバンテージは、必要に応じてワークロードの増減に、容易に対応できることだ。GPUのワークロードのすべてにスパイクがあるわけではなくても、万一のときには便利なオプションとして評価できるだろう。

Googleでは、GPUジョブのモニタリングを、そのAPIStackdriver、ロギングサービスなどから容易に行える。

全体としてKubernetes Engine(←GoogleがGKEの正式名として使うことにしたらしい名前)は、そのコアアワー(core数×時間)が2017年に9倍になった。コンテナのブームと、(当時の)GKEが2016年にローンチしたばかりであることを考えると、9倍も意外ではないが、しかしそれは、Googleがコンテナの世界で勝馬を獲得したことを、意味しているのかもしれない。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

ハイパフォーマンスコンピューティングのためのコンテナプラットホームSingularity ProをSylabsがローンチ

オープンソースのコンテナエンジンSingularityを抱える商用企業Sylabsが、最初の商用製品Singularity Proを今日(米国時間2/8)発表した。

Sylabsがローンチしたのは2015年で、同社は科学計算やハイパフォーマンスなコンピューティングに特化したコンテナプラットホーム作ることを志向した。この二つの分野は同社のファウンダーでCEOのGregory Kurtzerによると、これまでコンテナ化の動きから置き去りにされてきた(本誌TechCrunchのコンテナ入門記事がここにある)。

Dockerが、多くのデベロッパーが選ぶコンテナエンジンとして台頭してきたが、しかしKurtzerによると、コンテナを使用するソリューションの初期のものは、マイクロサービスにフォーカスしていた。それは必ずしも間違いではないが、それにより、サービスではなくジョブに依存するタイプのコンピューティング、とりわけハイパフォーマンスコンピューティングが取り残された。

Kurtzerは、オープンソースの落ちこぼれでは決してないが、これまで20年あまり、アメリカのエネルギー省の研究所で、ハイパフォーマンスコンピューティング(HPC)のアーキテクトとして仕事をしてきた。そしてそこで彼は、オープンソースのエンタープライズLinuxプロジェクトCentOSと、Warewulfに出会った。後者は、彼によると、もっとも多く利用されるステートレスなHPCクラスターのプロヴィジョナーになっている。

彼が視点をコンテナに向ける決心をしたのは、Sylabsを創業して2016年の4月にSingularityの最初のバージョンをローンチしたときだ。そのときすでに、それの商用バージョンを作る気でいた。彼はSingularityをHPC環境のためのDockerと見なし、自分の会社もDockerみたいに経営して、オープンソースのプロジェクトをリードし、さらにその上に商用ビジネスを築きたい、と考えた。Dockerがまさにそうしているように。

今ではKurtzerは、SingularityをHPCの商用市場だけでなく、エンタープライズにも持ち込み、人工知能や機械学習、ディープラーニング、高度なアナリティクスなど、そのほかのハイパフォーマンスコンピューティング的ワークロードにもフォーカスしていきたい、と考えている。

“これらのアプリケーションはデータ集約的なワークロードを背負っているから、HPC的なリソースを要求し、今後ますます多くの企業がデータ指向の経営をするようになると、そういうワークフローを適正にコンテナ化してサポートするニーズが大きく成長する”、と同社のエンタープライズプロダクトを発表するブログ記事でKurtzerは述べている。

Singularityは、得意とするワークロードのタイプは違っても、KubernetesMesosのようなコンテナオーケストレーションツールを有効に利用でき、また、MicrosoftのAzure Batchツールなどのクラウドツールとの互換性もある。

Kurtzerによると、現在のSylabsの社員は12名で、金額は非公開だがすでにシード資金を得ている。その投資家のRStorも、まだステルス状態のスタートアップだ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

Red HatがCoreOSを$250Mで買収してKubernetes路線を強化

エンタープライズLinuxの代表的企業であるRed Hatは近年、同社のOpenShiftプロダクトで、Kubernetesを軸とするコンテナ技術に積極的に注力してきた。そして今日(米国時間1/30)同社は、その路線のさらなる拡張のために、コンテナ管理のスタートアップ*CoreOSを2億5000万ドルで買収すると決定した。〔*: 元々はCoreOSはDockerコンテナの使用を前提とするエンタープライズLinuxディストリビューションである。〕

CoreOSのメインのプロダクトは、LinuxディストリビューションCoreOSと、Googleが開発したオープンソースのコンテナオーケストレーションプラットホームKubernetesをベースとするコンテナ管理ソリューションTectonicだ。本誌TechCrunchのコンテナ入門記事が、ここにある。

CoreOsとRed Hatは、Google, FathomDB, ZTE Corporation, Huawei, IBM, Microsoft, Fujitsu, Mirantisなどと並んでKubernetesの最大のコントリビューターの一員だ。

おそらくKubernetesをめぐる密接な協働関係が契機となって、CoreOSとRed Hatの仲が深まり、この際一つになった方が顧客の共有や人材の有効活用の点で有利、という結論に達したのだろう。両者はコンテナを前提とするLinuxディストリビューションでも、CoreOS vs. Red Hat Atomicで競合してきたが、これについてもやはり、デベロッパー環境を統一すべき、という結論になったのだろう。

次世代の中心的なソフトウェア環境が、自社データセンター上のオンプレミスとパブリッククラウドを併用するハイブリッドクラウドになるのなら、クラウドネイティブな枠組みにより、統一的な方法でアプリケーションをデリバリしていくことがとても重要になる。Red Hatでプロダクトとテクノロジーを担当するPaul Cormierによると、両社の合体はそのようなハイブリッド環境や複数のクラウド環境を 統一的に扱える力を与える。

Cormierは声明文の中でこう述べている: “次世代のテクノロジーは、複数の、そしてハイブリッドなクラウド環境にまたがるコンテナベースのアプリケーションが駆動する。それらは、物理環境、仮想環境、プライベートクラウド、パブリッククラウドなど多様な要素から成る環境だ。KubernetesとコンテナとLinuxが、この変化の核であり、Red Hat同様CoreOSも、これらのイノベーションを推進する上流のオープンソースコミュニティと、エンタープライズ級のKubernetesを顧客に提供していく能力の両方において、リーダー的存在だった”。

昨年CoreOSのCEO Alex Polviもインタビューでこう語った:“うちはGoogleやDocker、Red Hatなどと共に、コンテナという新しい技術カテゴリーを作ってきた、という自負を持っている。うちはこれまで、まったく新しいカテゴリーのインフラストラクチャを作ってきた”。

彼の企業は、エンタープライスKubernetesプロダクトを作って早くからゲームに参戦し、そのことを有利に生かしてきた。“Kubernetesについては、その初期から、すごい大物になる、と感じていた。そして当時からすでに、TicketmasterやStarbucksなどのシステムにKubernetesを導入してきた”、と彼は語る。

彼によると、同社のコンテナ管理システムTectonicには4つのメイン成分がある: ガバナンス、モニタリング・ツール、課金、そしてワンクリック・アップグレードだ。

Red HatのCEO Jim Whitehurstも昨年のインタビューで、うちもコンテナとKubernetesに関しては早かった、と述べた。彼によると、同社はオペレーティングシステムのカーネル(すなわちLinux)もコンテナに入れられることを理解していた。同社は本来Linux企業なのでKubernetesと(Linux上の技術である)コンテナ化技術に早期から専念して、OpenShiftを作った。

CoreOSは2013年の創業以来5000万ドルを調達している。主な投資家であるGV(元Google Ventures)とKleiner Perkinsは、おいしいリターンを得たようだ。いちばん最近のラウンドは、GVがリードするシリーズBの2800万ドルだった。Kubernetesの作者で最大のコントリビューターでもあり、CoreOSの主要投資家であるGVを同系とするGoogleが、Red HatというトンビにCoreOSという油揚げをさらわれた形になったのはおもしろい。

買収は今月中に完了するものと思われる。ただし1月はあと1日だけなので、すでに完了しているのかもしれない。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

今年Kubernetesは急速に立ち上がり、活き活きとしたエコシステムを生み出した

普通の人はおそらく聞いたこともない技術だろうが、Kubernetesは今年2017年に、コンテナテクノロジーを使うITプロたちの間で、急速に人気を獲得した。Kubernetesは、運用スタッフがコンテナ群を大規模に展開および管理するための基盤を提供するオーケストレーションエンジンである。(コンテナの基礎については、 この記事を参照のこと )。

もっと分かりやすい言い方をするなら、コンテナの数が増加するにつれて、それらの起動や状態を管理するツールが必要になるということだ。コンテナというアイデア自身や、それが可能にするいわゆる「マイクロサービス」モデルが、複雑なモノリシックなアプリケーションを、はるかに小さく管理しやすいものに分解するので、必然的にコンテナの数は時間とともに増加する傾向がある。Kubernetesはこうした際の運用/管理用途に使われる事実上の標準ツールとなっている。

Kubernetesは、元々はGoogleで開発されたオープンソースプロジェクトで、現在はCloud Native Computing Foundation(CNCF)によって管理されている。昨年、AWS、オラクル、マイクロソフトなどを含むテクノロジー界の大企業たちがCNCFに名前を連ねた。もちろんKubernetesの開発に何らかの影響を与えたいという思いが、その動機の大半を占めている。

急速な成長

Kubernetesが勢いを増すにつれ、それはイノベーションとビジネスアイデアのプラットフォームになってきた(人気のあるオープンソースプロジェクトではよく見られることだ)。早期に採用を行った企業たちは、いまや新技術に移行したいものの内部に専門家がいない顧客たちを支援できるチャンスを得ている。支援企業は、このようなツールを使用することに伴う基本的な複雑さを隠すことによって、商業的な機会を創出することができる。

私たちは、Kubernetesでもこの大きな流れを見ることができている。支援企業たちはオープンソースに基づいたブロダクトの開発を始めており、それによってツールの細かな癖に精通せずとも、利用と実装が容易になるパッケージアプローチが可能になる。

利用実績がどれほど急速に伸びているかを知ってもらうために、451 Researchが行ったサーベイを紹介しよう。2015年に行われた調査では、回答企業の10%が何らかのコンテナオーケストレーションツールを使用していた(Kubernetesもしくは他の競合を含む)。ちょうど2年後に行われたフォローアップ調査では、451は、回答企業の71%がコンテナ管理のためにKubernetesを使用していることを報告している。

Googleのプロダクトマネジメント担当副社長であるSam Ramji(以前はCloud Foundry FoundationのCEOだった)は、こうしたことが一夜にして起きたような感じを受けているかもしれないが、他の多くのことと同様に、作成には長い時間を要したのだと語っている。Kubernetesの直接の前身はBorgと呼ばれるGoogleのプロジェクトである。Ramjiは、2014年にオープンソースプロジェクトとしてKubernetesをリリースする10年前から、Googleはコンテナを実運用していたのだと指摘する。

「10年近いコンテナの大規模運用の歴史をGoogleは持っていました。実験ではありません。Borgの上でGoogleのビジネスが大規模に運用されていたのです。Kubernetesはそれらのレッスンに基づいて、ゼロから構築されたものです」とRamjiは語った。

クラウドネイティブコンピューティング

Kubernetesやクラウドネイティブツールを使用する背景にある大きな要因の1つは、企業がリソースの一部をクラウドに置き、一部をオンプレミスのデータセンターに置くハイブリッド環境での運用が増えていることだ。Kubernetesのようなツールは、どこにデプロイされても一貫した方法でアプリケーションを管理できるフレームワークを提供する。

その一貫性が、人気の大きな理由の1つなのだ。IT部門が2つの異なるツール(またはツールセット)を使用して、2つの異なる場所でアプリケーションを管理することを余儀なくされた場合、やがてどのリソースが利用され、データがある瞬間にどこにあるかを把握することが難しくなるような混乱に陥る可能性がある(実際にそのようなことは起こっている)。

クラウドネイティブコンピューティングファウンデーション(CNCF)が、KubernetesファウンデーションではなくCNCFと呼ばれる理由は、Googleやその他の運営メンバーたちが、Kubernetedはクラウドネイティブストーリーの一部に過ぎないと考えているからだ。もちろんそれは「大きな一部」かもしれないが、彼らはより豊かなツールシステムを目指したいと考えている。より広範な名前を付けることで、オープンソースコミュニティ対して、クラウドネイティブのやりかたで、インフラストラクチャ管理機能を拡張するためのツールを構築するように奨励しているのだ。

採用に向かう大企業たち

このプロジェクトへの貢献者のトップ10を見ると、OpenStack、Linux、その他のオープンソースプロジェクトにまたがった、主要なテクノロジープレイヤーたちの名前を見ることができる。それらはGoogle、Red Hat、CoreOS、FathomDB、ZTE Corporation、Huawei、IBM、Microsoft、Fujitsu、そしてMirantisなどだ。

CNCFのエグゼクティブディレクター、Dan Kohnは、これらの企業は、基盤技術では協力を行いながら、高レベルのツールで競争することが、より効果的であると認識しているのだと言う。「Linuxに関するアナロジーを使うことができます。人びとはKubernetesを『クラウドのLinux』と表現しています。企業のすべてが手を携えたり、同じ顧客に対して競合しないことにしたというわけではありません。ただ、コンテナオーケストレーションそのもので競争することには、あまり価値がないと認識しているのです」。

そして、これらの企業の多くは、過去12-18ヶ月間の間に、Kubernetesや、コンテナ、そしてクラウドネイティブ関連企業を買収している。

会社名 買収企業 目的 買収日付 金額
Red Hat Codenvy コンテナ開発チームワークスペース

5/25/2017

非公開
Oracle Wercker 大規模クラウドネイティブアプリの運用と展開

4/17/2017

非公開
Microsoft Deis Kubernetes用ワークフローツール

4/10/2017

非公開
Mirantis TCP Cloud 連続更新

9/15/2016

3000万ドル
Centurylink ElasticBox マルチクラウドのアプリケーション管理

6/14/2016

2000万ドル
Apprenda Kismatic Kubernetesのサポートとツール

5/19/2016

非公開

これらのすべてが、2015年7月までにはバージョン1.0に達していなかったツールを中心に構築されたビジネスとなった(その前にもいくつかの 0.x リリースが行われている)。それ以降、採用は順調に増加している。

今年の初め、CNCFは、36社がKubernetes認定基準に合意したことを発表した。以前36社ものハイテク企業が何かに合意したのは一体何時だったろうか?彼らがこれを行った理由は、個々のメンバーは互換性がなかったり一貫していないバージョンを作成することを防ぐためだ。もしこれが満たされないならば、期待に反した振舞が起きたり、あるバージョンから他のバージョンへの移植ができなくなったりするだろう。これは一般的にはフォーク(枝分かれ)という名で知られている現象だ。組織はKubernetesの人気の高まりを認識し、可能な限り不都合が起きないようにしたいと考えている。

エコシステムの構築

Kubernetesを商用化している企業には、Google Kubernetes Engine(以前のGoogle Container Engine)を提供しているGoogle自身、Red Hat OpenShift、Pivotal Container System(正しくない略称のPKSとして知られている)、そしてCoreOS Tectonicが含まれている。AWSは、そのコンテナサービスにKubernetesサポートを追加して流れに飛び乗ったばかりだ。今年の初めには、コンテナのブームを生み出したDockerも同じ動きをみせた

写真:Googleより(クリックして拡大)

Kubernetesのコアなオープンソース版を商用化する方法を探る以外にも、ホスト管理から、セキュアなログ管理と監視に至るまで、少なくないツールが開発されている。

これらがすべて、生まれてわずか2歳のオープンソースプロジェクトの周りに、豊富なツール群を構成している。これがオープンシステムを作成したときに起きることだ。皆がそれを運用するツールアプリケーションを必要とするので、イノベーションが起こる傾向があるのだ。私たちはそれをLinuxで目撃した。同じようにHadoopとOpenStackでも目撃した。そして今やそれがKubernetesでも起きている。今年それは大きな飛躍を果たしたのだ。

[原文へ]
(翻訳:sako)

HeptioとMicrosoftが共同でKubernetesのバックアップ/災害復旧ソリューションに取り組む

オープンソースのツールKubernetesがコンテナオーケストレーションのデファクトスタンダードになるにつれて、当然ながらそのまわりには、さまざまな新進企業からなるエコシステムが形成されてきた。Heptioもそういう企業のひとつだが、創業者がKubernetesの協同ファウンダー(Joe BedaとCraig McLuckie)であることがとくに関心を招(よ)んでいる。そのHeptioが今日(米国時間12/7)、この夏ローンチした同社のHeptio ArkプロジェクトでMicrosoftと協働する、と発表した。

Heptio Arkはバックアップと災害復旧を管理するユーティリティで、データセンターで大きな問題が起きたときに、Kubernetesのクラスターとボリュームをバックアップする。

計画では、Arkの能力の強化で両社は協働するが、並行してKubernetesを使っているアプリケーションをオンプレミスや、当然ながらMicrosoft AzureとAzure Container Serviceへ移すためのツールも作る(Microsoftはまだ後者を、‘Azure Kubernetes Service’に改名していない)。

HeptioのCEO Craig McLuckieはこう言う: “パブリッククラウドだけで生きてるような企業は、実はほどんどいない。だからワークロードをパブリッククラウドとオンプレミスに正しく振り分けるためのツールと方法がきわめて重要だ。Microsoftが今回のようにオープンソースのコミュニティと本気で協働することは、Azureの顧客の利益になるだけでなく、Kubernetesのコミュニティも強くする”。

さらにおもしろいのは、この共同事業が、Kubernetesの協同ファウンダーたちの同窓会になることだ。HeptioのBedaとMcLuckie、そしてMicrosoftのBrendan Burnsは、共にGoogleでKubernetesプロジェクトをオープンソースで立ち上げ、その後もしばらくGoogleで、その開発とメンテを担当した。

そのBurnsは曰く、“HeptioとMicrosoftが一緒になって、Kubernetesのエコシステムが抱える未対応のニーズを満たす強力なソリューションを作っていくことは、すごくワクワクする。Heptioと共同でArkとAzureを統合すればそれは、オンプレミスのKubernetesクラスターをクラウドへバックアップするための由緒正しいソリューションに、確実になるだろう”。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

IntelとHyperがOpenStack Foundationとパートナーしてコンテナのセキュリティで独自技術

【抄訳】
すでに周知のように、OpenStack Foundationは今後、その名前が示すような単一のビッグプロジェクトだけでなく、もっと多様なオープンソースプロジェクトのホームになる、と宣言している。そこで今日、同Foundationが発表したのが、Kata Containersプロジェクトのローンチだ。

Kata Containersは、実行環境の仮想化/隔離化に関してコンテナと仮想マシンの良いとこ取りをするようなオープンソースプロジェクト(GitHub上)だ。コンテナからはそのスピードと柔軟性と管理性を、そして仮想マシンからはとくにそのセキュリティをいただく。この技術のベースは、IntelのClear Containersと、Hyperのハイパーバイザーランタイム(仮想マシン環境)runVだ。

OpenStack Foundationの事務局長Jonathan Bryceによると、彼のこの組織は、クラウド上の本格的なワークロードの実行を容易にするような、別のプロジェクトを求めていた。“OpenStack Foundationではユーザーコミュニティにフォーカスし、そのニーズに応えるものを作っている。それが、OpenStackの本来のサービスより大きいことも、ありえる”、と彼は語る。

では一体、Kata Containersプロジェクトとは何なのか? その基本的な着眼は、確かに優れた技術であるコンテナにも、長年手付かずのセキュリティの問題がいくつかあることだ。とくに複数のコンテナが仮想マシンを共有して動いていくときには、それぞれを完全に隔離孤立することが難しい。Kata Containersはこの問題を、それぞれのコンテナにきわめて軽量な仮想マシンとカーネルを与え、各コンテナないしコンテナポッドが自分だけの隔離された環境で動き、ネットワーキングもI/Oもメモリそれぞれ独自に割り当てられるようにすることで、解決しようとする。またIntelがプロセッサーに組み込んでいる仮想化技術により、ハードウェアレベルでの隔離孤立も利用する。

Kata Containersは現在、Kubernetes, Docker, およびOpenStackを統合し、x86アーキテクチャのプロセッサーでのみ動く。サポートしているハイパーバイザーは、KVMのみである。今後、他のアーキテクチャやハイパーバイザーにも拡張していくプランはある。

HyperとIntelとの技術融合には約1年を要しているが、この技術は多方面から期待されていて、すでにCanonical, China Mobile, CoreOS, Dell/EMC, Google, Huawei, JD.com, Mirantis, Suse, Tencent, ZTEなどがこれをサポートしている。

【後略】

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

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

AWS Fargateはインフラストラクチャー管理不要のコンテナ運用サービス

Amazonは、ラスベガスで開催中のAWS re:Invent会議で、新しいサービスAWS Fargateを発表した。このサービスを使うことで、実行インフラストラクチャについて考えることなくコンテナを運用できるようになる。

これは注目すべきアイデアだ。コンテナを起動して、Kubernetesや他のオーケストレーションエンジンをマネージャとして動作させ、AWSが必要となるハードウェアをすべて賄う。

新しいサービスを発表したRandall Huntのブログ記事では「簡単に説明するなら、FargateはEC2と似たようなものですが、仮想マシンを提供する代わりにコンテナを使うことができるものです。これは、基盤となるインスタンスを管理することなく、コンテナを基本的な計算プリミティブとして使用できるようにするテクノロジーです」と説明されている。

AWSのCEOであるAndy Jassyは、re:Inventのステージでこの新しいサービスを紹介し、とても簡単に利用できることを強調した。タスクを定義し、アカウントとアクセス管理要件と必要なメモリとCPUを指定すれば、Fargateが残りの作業を行う。サーバーやクラスタの調達について心配する必要はなく、自動スケール機能も備えている。

このサービスは、インフラストラクチャを管理する複雑な仕事を、簡素化してくれるものだ。もちろんインフラストラクチャーの管理を自分たちで行いたい企業もいるし、そうした企業のためにはEC2が用意されているが、インフラストラクチャー管理をやめてしまいたい企業はFargateを利用し、AWSに全てを任せることが可能だ。

さらに、特定のアプリケーションの要件に合わせてFargateを設定すれば、各コンテナに必要なリソースに対してのみ支払いが発生する。

本日発表されたこの出発点から、さらなる拡張計画もある。AmazonはAmazon EKSも発表した。これはAmazon版Kubernetesである。ブログの記事によれば、EKSと組み合わせてFargateを使ってコンテナを起動することができるということだが、理にかなったアイデアだ。

本日(11月29日)、Fargateは米国東部(バージニア州北部)リージョンでの提供が始まった。

[原文へ]
(翻訳:Sako)