Kubernetesの統合開発環境のLensをMirantisが買収

Docker(ドッカー)のエンタープライズビジネスを最近買収したMirantis(ミランティス)は米国時間8月13日、Kubernetes(クーバネティス)のためのIDE(統合開発環境)の1つと言われているデスクトップ環境Lens(レンズ)を買収すると発表した。Mirantisはすでに、Lensをもともと開発していたフィンランドのスタートアップであるKontena(コンテナ)を買収(Mirantisプレスリリース)していた。

とはいえLens自体は、ここしばらくLakend Labs(ラケンド・ラボ)によって所有・管理されていた。なおLakend Labsは自身を「コンテナ(Kontena)の生み出したオープンソースソフトウェアとしての製品の保存と維持に力を注いでいる、クラウドネイティブコンピューティングの熱烈な支持者と技術者の集まり」だと説明している。LakendはLensを数カ月前にオープンソースにしていた。

画像クレジット:Mirantis

「Mirantisのミッションは非常にシンプルです。最新のアプリを大規模に構築できる最速の手段を、企業に提供するということです」こう私に語ったのは、MirantisのCEOであるAdrian Ionel (エイドリアン・アイオネル)氏だ。「わたしたちは企業が常にアプリケーションの構築方法を、次々に最新のものにしようとしていることを知っています。私たちはそうした企業に対して、その実現をお手伝いするようなプロダクトをお届けしたいのです」。

現在、それが意味しているのは、企業が大規模なクラウドネイティブなアプリケーションを構築することを支援するということであり、それはほぼ間違いなく、そうした企業に対して、あらゆる種類のコンテナ基盤サービスを提供するという意味になる。

「しかし、私たちの頭の中では常に別のストーリーが流れています。それは、どのようにすれば、開発者をより中心に据えて焦点を当てることができるのかということです。なぜなら、過去10年間に私たちが目にしてきたように、開発者たちは自分たちが実際に使っていたサービスやインフラとは違うものへの責任を負わされるようになってきたからです」とアイオネル氏は説明した。そこにマッチしたのがKontenaとLensの買収だ。結局のところKubernetesの管理は簡単なものではない。今でも開発者はしばしば、開発したアプリケーションが企業のインフラとどのように相互作用しているのかを、管理し監視する必要に迫られる。

「Lensを使うことで、開発者はKubernetesで作業することや、Kubernetesでアプリケーションを構築ならびにデプロイすることが非常に簡単になります。LensはKubernetesの複雑さによって立ち止まった人びとのために、障害を取り除きより多くの価値を引き出す存在なのです」と彼は付け加えた。

「私たちはこのクラウドネイティブテクノロジーの世界の中に、どのようにLensを組み込むのか、そしてどのように開発者たちの仕事をより楽しくしていくのかに対して、エイドリアンとの共通のビジョンを見いだせたことに、とても興奮しています」と私に語るのは、Kontenaの元CEOで、現在はMirantisのエンジニアリングディレクターのMiska Kaipiainen(ミスカ・カイピアイネン)氏だ。

彼はLensをKubernetesためのIDEとして説明する。カイピアイネン氏は、Lensの機能を既存のツールの組み合わせで実現することは可能だが、それを行うには20もの異なるツールが必要だと主張する。「たとえば監視機能、そしてまた別にログ機能なども必要です。そしてさらにコマンドラインの設定も必要になりますし、その先もキリがありません」と彼はいう。「私たちがLensで試みてきたことは、これらすべてのテクノロジーをまとめて、単一の統一された使いやすいインターフェースで開発者に提供することです。こうすることで開発者は、集中力と彼らが取り組んでいるもののコンテキストを失うことなく、ワークロードとクラスターで作業を続けることができるようになります」。

特にLensには、コンテキストを理解して振る舞う端末機能、クラウドの種類を問わず機能するマルチクラスター管理機能、オープンソースであるPrometheusのモニタリングサービス(Prometheusサイト)などのサポートが含まれている。

MirantisにとってLensは非常に戦略的な投資であり、同社は引き続きこのサービスを開発していく予定だ。実際、アイオネル氏によれば、Lensチームの使えるリソースには基本的に制限はないという。

計画としては、カピアイネン氏は、今後数か月以内にAPIを介してLensに拡張機能を追加することを検討していると語った。「この拡張APIを使用することで、私たちはクラウドテクノロジー業界内の他のテクノロジーベンダーと実際に緊密に連携して作業できるようになります。彼らはLensのUIに直接プラグインしてそのコンポーネントかたのデータをビジュアライズすることができるようになるのです。このことでシステムはとても強力なものになるでしょう」。

アイオネル氏はまた、現在シングルユーザー製品であるLensに、より大規模なソフトウェアチーム向けの機能を追加することに、同社が取り組んでいると付け加えた。結局のところ、すでに多くのユーザーが、非常に大規模な開発チームのコンテキストですでにレンズを使用している。

コアのLensツールは引き続き無料で、オープンソースのままだが、Mirantisは、それらを管理するために必要な集中型サービスを提供する新機能に、課金することになるだろう。しかし、それがどのようなものかはまだはっきりしない。

Lensを試してみたい場合には、Windows、macOS、Linuxのバイナリをダウンロードできる。

画像クレジット: bugto / Getty Images
原文へ

(翻訳:sako)

DataStaxがCassandraデータベースのためのKubernetesオペレーターをローンチ

米国時間3月31日、オープンソースのApache Cassandraプロジェクトを支える商用企業DataStaxが、データベースのクラウドネイティブバージョンを動かすために同社が開発したKubernetesオペレーターをオープンソースで発表した。

DataStaxの最高戦略責任者である Sam Ramji(サム・ラムジ)氏が2019年にGoogleから来て最初に取り組んだのが、KubernetesとCassandraに関して顧客、パートナー、コミュニティメンバーの動向をつかむことだったが、そこでわかったのはサポートが驚くほど限定的だったことだった。

一部の企業はKubernetesのサポートを自分たちで構築していたが、DataStaxには自社サポートと呼べるものがなかった。KubernetesはGoogleで生まれ、そして現在、DataStaxはコンテナ化を熱心に推進している。そこでラムジ氏は、顧客がKubernetesの利用を始めやすくするためのオペレーターがDataStaxにあるべきだと考えた。

「オプションとしてコミュニティに提供しているKubeオペレーターの特別な点は、オペレーターをCassandra向けに一般化して、どこでそれを実装しても使えるようにしたことだ」とラムジ氏はいう。

ラムジ氏によると、多くの企業が独自にKubernetesを運用している企業の多くは、それらは各社の固有の要求に向けて独自化されている。それはそれで結構だが、同社がCassandra上に構築しているため、幅広いユースケースにアピールできる一般的なバージョンを開発したいと考えていたという。

Kubernetesでは、オペレーターはDevOpsチームによるパッケージングの仕方、アプリケーションの管理とデプロイの仕方、それを正しく動かすために必要なインストラクションなどの指示を与える。DataStaxが今回作ったオペレーターは、Cassandraを幅広い前提条件で実行するために特別に作成ししたものだ。

Cassandraは強力なデータベースで、他のデータベースがダウンしても動き続ける。そこでAppleやeBay、Netflixなども主要なサービスを実行するために使っている。この新しいKubernetesの実装により、コンテナ化したアプリケーションとしてCassandraを動かしたいという人は誰でも利用できるようになり、Cassandraをモダンな開発領域へと押し上げられるようになる。

同社はまた、新型コロナウイルス(COVID-19)のためデータベースの利用が増えて苦労している技術者を助ける無料のヘルプサービスを発表した。彼らはそのプログラムを「Keep calm and Cassandra on(落ち着いて、Cassandraを動かそう)」と呼んでいる。Cassandraのようなシステムの稼働の維持を任されている技術者をサイトリライアビリティエンジニア(SREs、サイトの信頼性を維持するエンジニア)と呼ぶ。

ラムジ氏の説明によると「この新しいサービスは完全無料のSRE間のサポート通話だ。我々のSREたちは世界中どこからのApache Cassandraユーザーからの電話に対応する。需要増に対応しようとしているCassandraのバージョンは何でもよい」という。

DataStaxは2010に創業され、PitchBookのデータによるとこれまで1億9000万ドル(約206億円)を調達している。

関連記事:DataStax Lands $106M In Series E Funding(未訳)

[原文へ]

(翻訳:iwatani、a.k.a. hiwa

ScalewayがマネージドKubernetesクラスターをローンチ

クラウドホスティング企業のScalewayが立ち上げたKubernetes Kapsuleは、ユーザーがScalewayのインフラ上でKubernetesのクラスターを管理するためのサービスだ。このサービスはScalewayの複数のインスタンスで利用でき、需要に応じてスケールする大きなクラスターを作ることもできる。

Kubernetesは、コンテナとそれらを支えるインフラストラクチャを管理するオープンソースのプラットホームだ。コンテナを利用するアプリケーションを作るときは、アプリケーションを複数のアプリケーションやサービスに分割し、それらを個々にデプロイしアップグレードできる。その際、メインのオペレーティングシステムと対話することはない。

そしてKubernetesを使うと、サーバーのノードやコンテナを増やしてインフラストラクチャをスケールできる。そうするとピークに対応した十分な量のリソースを常時確保できる。スケールダウンしてお金を節約することもできる。

ScalewayのマネージドKubernetesサービスは無料なので、使用するノード(サーバー)に対してのみ料金を払えばよい。Scalewayはユーザーのノードの稼働状態を15分ごとにチェックし、必要に応じてクラスターをスケールする。ユーザーには自分のクラスターをモニターするWeb上のダッシュボードが提供される。

同社によると、コントロールプレーンには多少冗長性があるので、ユーザーのコントロールプレーンがエラーになっても利用できる(99.95%のSLAだ)。一度に500のノードをサポートする。

KapsuleはScalewayのクラウドインスタンスとGPUインスタンス、ブロックストレージ、およびロードバランサーをサポートする。同社はまた、ユーザーのコンテナを保存するためのコンテナレジストリを提供している。クラスターの作り方を図解すると、下図のようになる:

KapsuleはCloud Native Computing Foundation(CNCF)のスタンダードに準拠しているので、既存のCNCFクラスターをScalewayに移行できるし、マルチクラウドのインフラストラクチャを作ることもできる。

マネージドKubernetesサービスによってScalewayは、エンタープライズや大企業の顧客を増やせるだろう。冗長性のために余分のクラウドホスティングプロバイダーを確保しておきたい、というニーズにはぴったりだ。

[原文へ]

(翻訳:iwatani、a.k.a. hiwa

Kubernetesクラスターの構築に柔軟性と自由度を持たせるSpectro Cloud

Kubernetes(クバネティス)が非常に人気のあるコンテナ管理プラットフォームであることは広く知られているが、それを実際に使おうとしたら、管理を誰かにやらせるかそれとも自分でやるかを選ばなければならない。米国時間3月17日に750万ドル(約8億円)を調達してステルスを脱したSpectro Cloudは、両者の中間のような第三の選択肢を与えてくれる。

この投資はSierra Venturesがリードし、Boldstart Venturesが参加した。

Boldstartの創業者Ed Sim(エド・シム)氏によると、彼はSpectro Cloudのチームと技術が好きだそうだ。「Spectro Cloudは、大企業の多くが抱える重い苦痛を解決する。それは、Kubernetesのサポートをマネージドプラットフォーム上に展開したいが、大型ベンダーのなすがままにはなりたくないという難問だ」とシム氏は語る。

Spectroの共同創業者でCEOのTenry Fu(テンリー・フー)氏によると、エンタープライズはコントロールと使いやすさの間で妥協を求めるべきではない。「我々は、使いやすいマネージドKubernetes体験を提供する最初の企業でありたいが、しかしまた同時に彼らには、大規模なKubernetesインフラストラクチャスタックを自分たちで定義できる柔軟性、自由度を与えたい」とフー氏は説明する。

またフー氏によると、この場合のスタックはKubernetesのバージョン、ストレージ、ネットワーキング、さらにセキュリティやロギング、モニタリング、ロードバランシングなど、Kubernetes周辺のインフラ要素をすべてカバーする一種のオペレーティングシステムだ。それらに、ユーザーの自由度を与えたいという。

「エンタープライズの組織内ではさまざまなグループのニーズに奉仕するが、それはインフラストラクチャスタックの要素によっては、とても細かいレベルになることもある。しかしそれでも、ライフサイクルの管理は気にしなくてもよい」と彼は説明する。つまりSpectro Cloudがそれらをユーザーに代わって扱い、しかもコントロールはユーザーが手中にするからだ。

これによりエンタープライズのデベロッパーに展開に関する大きな柔軟性が与えられ、複数のクラウドインフラストラクチャプロバイダー間の移動も容易になる。今の企業は単一のベンダーに縛られるのを避けたいため、これは最上位の優先事項となる。

「インフラストラクチャのコントロールは連続的に行われるため、企業はいろいろなニーズに対してトレードオフを迫られることになる。極端な場合には、マネージドサービスは天国のような使いやすさを提供するが、しかしそれはクラウドユーザー側からのコントロールを犠牲にする。Kubernetesのバージョンの更新すら、ユーザーが自由にできないサービスもある」

フー氏と彼の共同創業者たちはこういった問題の経験者で、創業前までCliQrに在籍していた。この企業はハイブリッドクラウド環境におけるアプリケーションの管理を助ける、彼らが創業した企業だ。CliQrを2016年にCiscoに売却し、2019年の春にSpectro Cloudの開発を始めた。

まだ生まれたばかりの企業だが、すでにベータの顧客が16社抱えている。

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

Google Cloudが機械学習の工程パイプラインを作るツールを提供

Google Cloudは米国時間3月11日、Cloud AI Platform Pipelinesのベータローンチを発表した。このエンタープライズ向けのサービスによりデベロッパーは、単一のツールで機械学習のパイプラインをデプロイできるようになり、そこにはモニタリングや監査のツールも備わっている。

Googleは 「機械学習のモデルをノートブックでプロトタイピングするとき、それはかなり単純明快に思える。しかし機械学習のワークフローを持続可能でスケーラブルにするための、そのほかの部分にも配慮するようになると、急に難解になってくる」と説明する。そうやってワークフローが複雑になると、反復できて監査も可能なプロセスの構築が一層困難になる。

そこで、このPipelinesが登場する。Pipelinesはデベロッパーに反復可能なプロセスを構築する能力を与える。Googleによると、このサービスには、ワークフローをデプロイして動かすためのインフラストラクチャ、パイプラインを構築してデバッグするためのツールの2つの部分がある。

このサービスは、Kubernetes Engineのクラスターとストレージのセットアップや、マニュアルによるKubeflow Pipelineの構成などのプロセスを自動化する。それはまたTensorFlow Extendedを使ってTensorFlowベースのワークフローを構築し、Argoワークフローエンジンを使ってパイプラインを動かす。これはインフラストラクチャサービスであると同時に、パイプラインの構築やバージョニング、アーチファクト(人工物混入)トラッキングなどができるビジュアルツールでもある。

「これだけの機能をわずか数クリックで始動できる」とGoogleは約束しているが、パイプラインの実際の構成はもちろん簡単ではない。Google Cloud自身にも複雑性(見方によっては柔軟性)があるし、しかもKubeflow Pipelines SDKとTensorFlow Extended SDKの両方を使いこなしてパイプラインのオーサリングをしなければならない。

[原文へ]

(翻訳:iwatani、a.k.a. hiwa

昨年廃業したKubernetesインフラ管理のContainershipの資産を日立の米子会社が買収

日立製作所の米国子会社であるHitachi Vantara(ヒタチ・ヴァンタラ)は、企業のデータ管理を助けるハードウェアやソフトウェアを開発している。同社は米国時間3月10日、Containership(コンテナシップ)の資産を買収したことを発表した。Containershipはコンテナエコシステムの初期のメンバーのひとつだが、昨年10月に業務を停止した。

2015 Disrupt New YorkのStartup BattlefieldでデビューしたContainershipは、コンテナ化されたワークロードを複数のクラウド間で移動するサービスとしてスタートした。しかしその後、コンテナサービススタートアップの多くがそうであったように、もっぱらKubernetes(クバネティス)にフォーカスするようになり、企業のKubernetesインフラストラクチャの管理を助けるサービスを提供した。業務を停止する直前には、主にKubernetesのマルチクラウド展開を管理するサービスを提供していた。しかし同社のKubernetes関連プロダクトは収益化が遅れ、今ではそのウェブサイトも存在しない

Hitachi Vantaraのデジタルインフラストラクチャ部門のCOOを務めるBobby Soni(ボビー・ソニ)氏は「ContainershipはKubernetesクラスターとコンテナ化アプリケーションの、パブリッククラウドとプライベートクラウドおよびオンプレミス環境における容易なデプロイと管理を可能にする。そのソフトウェアは、Kubernetesを使っている企業が直面するクラウドネイティブの重要な問題、例えばパーシステントなストレージのサポートや認証の一元化、監査のロギング、継続的デプロイメント、ワークロードの可搬性、費用分析、オートスケール、アップグレードなどなどを解決する」と語る。

Hitachi Vantaraによると、同社の買収対象としてContainershipの顧客契約や社員は含まれず、Containershipのブランドを保全する計画もない。「ContainershipのIPをベースとして新しいプロダクトを開発することが目的である。それらのプロダクトが実際に供用される時点で以前の顧客が再び関わってこられることを期待したい」と同社のスポークスパーソンは説明する。

買収の価額は公表されていない。ピッツバーグに本社を置くContainershipは、2014年の創業以来約260万ドル(2億7121万円)しか資金を調達していない。その早逝の1〜2年前からは、まったく音沙汰がなくなっていた。買収価額もそんなに高くはなかっただろう。これまでの投資家は、Birchmere VenturesとDraper Triangle、およびInnovation Worksだった。

Hitachi Vantaraによると、同社のKubernetesコミュニティとの関係は継続する。ContainershipはCloud Native Computing Foundationのメンバーで、この買収を機にメンバーではなかったHitachi Vantaraも変わるかもしれない。

関連記事:ContainerShipはコンテナ化したアプリケーションのマルチクラウド展開を助ける

[原文へ]

(翻訳:iwatani、a.k.a. hiwa

サーバーレス開発モニタリングのEpsagonが17億円超を調達

イスラエルのEpsagonは(エプサゴン)、サーバーレスやコンテナなどのモダンな開発環境のモニタリングを助ける。同社はこのほど1600万ドル(約17億6200万円)のシリーズA調達を発表した。

同社にとって新しい投資家であるU.S. Venture Partners(USVP)が、このラウンドをリードした。また、これまでの投資家であるLightspeed Venture PartnersとStageOne Venturesも参加した。同社によると、これで調達総額は2000万ドル(約22億円)になる。

CEOで創業者のNitzan Shapira(ニッツァン・シャピラ)氏によると、同社は昨年プロダクトを拡張して、同社のルーツであるサーバーレス以外にも手を広げたが、同時にまた、さまざまな形のモダンな開発への深いインサイトを提供している。

シャピラ氏は「5月にEpsagonのマイクロサービスのためのプラットホームをクラウドに立ち上げたときお話したように、それにはコンテナやサーバーレスなど、マイクロサービスのアプリケーションを作るためのありとあらゆるワークロードが含まれている。さらにその後も、かなりの数の重要な発表を行なった」と語る。

最初に同社が発表したのはKubernetesのワークロードのトレーシングとメトリックスで、それにはネイティブのKubernetesのほかに、AWS EKSやGoogle GKEのようなマネージドKubernetesサービスも含まれている。シャピラ氏によると「数カ月前に、Kubernetesの統合を発表した。だからKubernetesのワークロードがあるところならワンクリックでEpsagonと統合でき、すぐにすべてのメトリックスを得られる。トレーシングのセットアップも数分でできる。これによって弊社のプロダクトには、極めて多数のユースケースが開けたことになる」とのこと。

同社はさらに、Amazonのクラウド上で使えるノーコードプログラミングツールであるAWS AppSyncのサポートも発表した。「AppSyncにトレーシングを導入したモニタリングプロバイダーはうちが唯一だが、しかしノーコードプログラミングは多くの人たちがモニタリングやトラブルシューティングで苦戦している分野なのだ」と同氏は語る。

「今回の資金でプロダクトをさらに拡張し、特にMicrosoft AzureとGoogle Cloud Platformのサポートを充実させたい。手作業で構成している一部のタスクの自動化を拡張したい」」とシャピラ氏。「プロダクトはできるかぎり最大限自動化したい。そうすればユーザーは、わずか数分ですごい体験を得られる。それらは、より高度なモニタリングや、さまざまな問題の検出とトラブルシューティングなどだ」と続けた。シャピラ氏によると、今の社員数はだいたい25名だが、年内に倍増したいそうだ。

関連記事:サーバーレスをモニタするEpsagonがAWS Lambdaオンリーを脱して多極化

[原文へ]

(翻訳:iwatani(a.k.a. hiwa

Kubernetesのバグ褒賞金制度は多数のセキュリティ研究者の参加を期待

Cloud Native Computing Foundation(CNCF)が米国時間1月14日、Kubernetesの初めてのバグ褒賞金事業(bug bounty)を発表した。Kubernetesは、最初Googleが作ったコンテナオーケストレーションシステムで、現在、至るところで使われている。このバグ褒賞金制度はCNCFとGoogleとHackerOneが共同で運営し、賞金額は100ドル(約1万1000円)から最高1万ドル(約110万円)までとなっている。

KubernetesにはすでにProduct Security Committee(セキュリティ委員会)があり、Google自身のKubernetesセキュリティチームが委員になっている。もちろん実際にコードをチェックするのは、外部も含めもっと多くの人びとだ。褒賞金制度ではもっと多くの新たなセキュリティの研究者の参加が期待されており、コードを調べ、バグ調査など行っている人を報いるものになっている。

Googleでコンテナのセキュリティを担当しているプロダクトマネージャーMaya Kaczorowski(マヤ・カツォロフスキ)氏は「Kubernetesにはすでに強力なセキュリティチームとセキュリティへの対応能力があり、最近のKubernetesセキュリティ監査によってそれはさらに強化されている。現在のKubernetesは、過去に例がないほど強力で安全なオープンソースプロジェクトだ。バグ褒賞金制度が立ち上がったことで、セキュリティに対する実践力が上がり、また、すでにバグの検出という重要な仕事をしている研究者たちに報いることができる。今後はもっと多くのセキュリティ研究者が参加して、コードを見る目が増えることを期待したい。Kubernetesのセキュリティ問題の洗い出しとバグ発見活動のバックアップに、財政的支援が加わったことになる」と言う。

褒賞金の対象は、GitHubのリポジトリにあるKubernetesの主要部位すべてだ。チームが特に重視しているのは、認証関連のバグと、故意や不故意による特権(プリビレッジ)のアップ、そしてkubeletやAPIサーバーのリモートコード実行バグだ。CNCFが特に強調するのは、研究者たちがKubernetesのサプライチェーンの全体をよく見ること。この事業と制度の詳細は、ここで確認できる。

関連記事: How Kubernetes came to rule the world…Kubernetesはどうやって世界を支配したのか(未訳、有料記事)

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

Amazon EKS on AWS Fargateが公開された

米国時間12月3日、ラスベガスで開催されているAWS re:Inventカンファレンスで、AWS FargateでEKS(Elastic Kubernetes Service)を利用できるようになったことが発表された。

画像:Ron Miller

EKSは、Amazonが提供するKubernetesのフレーバーだ。Fargateは2017年に公開されたサービスで、基盤インフラストラクチャを気にせずにコンテナアプリケーションを起動できる。

同社はこの新機能について発表するブログで「今日からAmazon EKSを使ってAWS FargateでKubernetesのPodを実行できる。Amazon EKSとFargateにより、Podのためのプロビジョニングやインフラストラクチャの管理は必要なくなり、AWS上でKubernetesベースのアプリケーションを簡単に実行できるようになる」と述べている。

Podは同一のKubernetesクラスタ上で起動されるコンテナの集まりだ。KubernetesではPodを自動で起動できることから、Podを自動で実行させるために必要な基盤インフラストラクチャをプロビジョニングすることにも意味がある。

同社はブログで「AWS Fargateにかかる費用は、Podを実行するのに必要なvCPUとメモリのリソースの分だけだ。これにはPodが要求するリソースと、Podとともに動作するKubernetesのコンポーネントを実行するために必要な少量のメモリが含まれる。Fargateで動作するPodは、既存の価格モデルに従う」と述べている。

つまり開発者は、オーバープロビジョニングを心配する必要はない。Fargateは、その時点でPodが動作するために必要なリソースだけを実行する仕組みになっているからだ。

この機能は同日から、米国東部(バージニア北部)、米国東部(オハイオ)、ヨーロッパ(アイルランド)、アジア太平洋(東京)で公開されている。

[原文へ]

(翻訳:Kaori Koyama)

ホスティングの古参LinodeがKubernetes Engineをベータでローンチ

ハイパークラウドの前には、Linode(リノード)やMediatemple(メディアテンプル)、HostGator(ホストゲーター)など、非常にたくさんのホスティングサービスがあり、自分の開発ニーズのためにそれらの仮想プライベートサーバーを手頃な料金で借りることができた。いまではそれらが日常の話題になることもないが、例外的にDigital Oceanは数年前にその低料金でクラウド市場への参入に成功し、現在のデベロッパーに適応したサービスを提供し続けている。当然ながらその適応サービスには、多くの場合コンテナのサポートが含まれるが、実はこのほどLinodeLinode Kubernetes Engine(LKE)を立ち上げた。

類似のサービスと同じく今年で16歳になるLinodeも、そのサービスにより従来よりも多くのデベロッパーが、この種のインフラストラクチャを管理するエキスパートでなくてもコンテナを採用できるようになると主張している。

LinodeのCEOで創業者のChristopher Aker(クリストファー・アーカー)氏は「Linode Kubernetes Engineをローンチして、Kubernetesをどんなデベロッパーでも使えるようにした。持ってるリソースや専門知識が十分でなくても、立派に使える。Kubernetesのクラスターの構成とノードのプロビジョニングと管理を自動化して、現代的なアプリケーションを速く容易に作れるし動かせるようにした。またリアルタイムのオートスケール機能と、無料のマスターサービス(主サービス)、そして直感的なクラウドマネージャーのインタフェイスとオープンAPIにより、デベロッパーは従来の複雑なコンテナ管理をバイパスして自分のイノベーションにフォーカスできる」と語る。

無論このサービスはLinodeのそのほかのツールを統合している。今ではそれは、ブロックとオブジェクトのストレージ、ロードバランシング、などなどのサーバーオプションだ。オートスケールをサポートしており、また高度なユーザーはHelmチャートやTerraform、Rancherなども利用できる。さらに、ワンクリックアプリサポート機能により、頻繁に使うアプリケーションを便利にデプロイできる。

Linodeのサービスは、すでに機能満載の他のプレーヤーで混み合っている市場に参入する。でもコンテナはまだまだこれからの技術だから、さまざまなツールの成長の余地も大きい。Kubernetesのようなツールがある今では、Linodeのような企業でも既存の顧客を超えた領域に進出し、顧客企業はおそらく最初はテスト用のプラットホームとしてツールとサービスを利用、その評価により本番利用にも採用、という過程になるのだろう。もちろん、いきなりLinodeの本番利用でも構わない。

[原文へ]

(翻訳:iwatani、a.k.a. hiwa

カオスエンジニアリングの対象をKubernetesクラスターに拡張したGremlin

10年前にAmazonとNetflixがカオスエンジニアリングを開発した。これは両社のようなネット企業に起きるかもしれないワーストケースを、実際に起きる前にテストする方法だ。両社の社員だったある人物がその実装としてGremlinを立ち上げ、Site Reliability Engineers(SREs)のチームがいなくても大規模プラットホームのテストを実行できるようにした。そしてGremlinは米国時間11月18日、Kubernetesのクラスターに対してもカオスエンジニアリング的なテストをサポートすると発表した。

同社はその発表を今週サンディエゴで行われているKubernetesのカンファレンスKubeConの冒頭で行った。

Gremlinの共同創業者でCEOのKolton Andrus(コルトン・アンドラス)氏によると、そのサービスはKubernetesのクラスターを、エラーを起こさないようにあるいはその可能性を下げるためにテストし構成することが目標だ。彼によると、Kubernetesのクラスターであろうとなかろうと、ライブの環境でミッションクリティカルなシステムを極端に過酷な状況に置いてテストするカオステストが重要とのこと。しかし、しかしそのようなテストには危険も伴う。そこでリスクを最小限に抑えるためのベストプラクティスとして、重要な情報が確実に得られる範囲内でテストの規模を最小にする。

アンドラス氏は「必要最小限のクラスターだけをテストする。そしてそれらの部分にエラーがあったらKubernetesに何が起きるか、実際にエラーを起こして理解する。例えば、スケジューラーが休止したら何が起きるだろうか。目標は人々がいわゆる爆発半径を知ることだ。そして実験を安全に行えるようガイドしていく」と語る。

さらにGremlinは、Kubernetesのクラスターに一連のベストプラクティスで焼きを入れて頑丈にし、エラー耐性を増す。「Gremlinには、この種のテストを実行するために必要なツールはあるが、これまでにとても多くの顧客との対話や彼らの実験から学んだのは、クラスターを本当にフォールトトレラント(エラー許容性)にしレジリエント(エラー耐性)にするためには、クラスターのチューニングや正しい構成が必要なことだ」とアンドラス氏。

Gremlinのインターフェイスは、このようにターゲットに合わせた実験ができるようになっている。テストをしたい部分を指定すると、どこをテストしているかを視覚的に表示する。そして、制御不能の状況になったら、キルスイッチでテストを停止できる。

GremlinがKubernetesをテストしている(スクリーンショット提供: Gremlin)

Gremlinは、2016年にローンチした。本社はサンノゼにある。プロダクトは、フリーミアムと有料制の両方がある。Crunchbaseのデータによると、同社はこれまで2700万ドルを調達している。

関連記事:How you react when your systems fail may define your business(ビジネスの生死を握るのは危機管理だ、未訳)

[原文へ]

(翻訳:iwatani、a.k.a. hiwa

Kubernates利用のクラウドサービス、MirantisがDocker Enterpriseを買収

米国時間11月13日、Mirantis日本サイト)はDockerのエンタープライズ事業を買収したことを発表した。

Docker EnterpriseはDockerのビジネスの中心だった。この売却の結果、評判の高いユニコーンだったDockerのビジネスはいわば以前の抜け殻となった。 残されたDocker自体は今年初めに就任した新CEOの指揮で開発ワークフローを効率化させるツールに引き続き注力するという。一方、MirantisはDocker Enterpriseというブランドを存続させるため混乱が生じることないという。

今回の買収により、MirantisはDocker Enterprise Technology Platformおよび関連するすべての知財(Docker Enterprise Engine、Docker Trusted Registry、Docker Unified Control Plane、Docker CLI等)を取得した。Docker Enterpriseのすべてのクライアント、既存の契約、戦略的技術提携、パートナープログラムも継承する。Docker、MirantisはともにDockerプラットフォームのオープンソースプロダクトの開発を継続するとしている。

両社は買収価格を明らかにしていないが、最近の資金調達ラウンドにおけるDockerの会社評価額を大幅に下回ることは間違いない。Dockerの評価額がこのところ下降を続けてきたことは公然の秘密だった。コンテナ革命のリーダーとして出発したものの、GoogleがKubernetesをオープンソース化し、業界が一斉にに殺到した後は付録のような存在に落ち込んでいた。ただしエンターブライズ事業は多数の大企業をクライアントにもち、健全な運営を続けていた。

Dockerによれば、Fortune 100の3分の1、Global 500の5分の1の大企業がDocker Enterpriseを使用しているという。これはどんな基準からしても高く評価できる成果だろう。Dockerが今回中核ビジネスの売却を急いだということは、こうしたクライアントの大分はDockerのテクノロジーに見切りをつけようとしている同社が考えたことを意味するのかもしれない。

アップデート:Dockerの広報はBenchmark Capitalから3500万ドル(約38億円)の資金を調達したことも発表した。 これは以下の記事の内容に影響を与えるものではないが、Dockerの今後の方向性を考える上で参考になる。なおTechchCrunchはこの資金調達について事前に情報を入手していない。

Dockerは以下のように声明している。

「Dockerは、新しい時代に対応するため、アプリケーションの構築、共有、実行に際して開発者のワークフローの効率化を進めることに焦点を当てることで我々の出発点に戻る。我々のビジネスの重点を再調整する一環として、MirantisはDocker Enterpriseプラットフォーム事業を買収し、このことを発表した。今後我々はDocker DesktopとDocker Hubの役割を拡大することによってアプリの開発者ワークフローを助けていく。具体的には、クラウドサービスの拡大に注力し、開発者がアプリケーションを構築する際に使用するテクノロジーを容易に発見し、アプリを関連する部署、コミュニティと簡単に共有し、オンプレミスであれ、クラウドであれ、Kubernetesが稼働するエンドポイントでアプリをスムーズに実行できるようにしていく」。

一方Mirantis自身もこれまでに相当の波乱を経験している。 Mirantisは十分な資金を調達してOpenStackのディストリビューターとしてスタートしたが、現在ではKubernetesベースのオンプレミスクラウドプラットフォームと関連するアプリケーション配信をサービスの中心としている。CEOのAdrian Ionel(エイドリアン・イオネル)氏は今日の発表に先立って私の取材に答え、「この買収は我々にとって最も重要な決定となるかもしれない」と述べた。

ではMirantisはDocker Enterprise買収で正確に言って何を目指したのだろうか?イオネル氏は 「Docker Enterpriseは我々がすでに目指している方向完全に合致し、また加速するものだ。Mirantisは の方向に大きく踏み出している。目標はKubernetesとコンテナテクノロジーの利用により、 マルチレイヤーのクラウド、エッジコンピューティングとクラウドのハイブリッドを含むあらゆるユースケースに対応することだ。いついかなる場合にもデベロッパーのインフラを開発を助ける一貫したエクスペリエンスを提供する。デベロッパーやクラウド運用者に使いやすいツールをオンデマンドで提供しその負担となるフリクションを最小化する」と述べた。

現在Mirantisの社員は450人ほどだ。買収により新たに元Dockerの社員300人程度を組織に新しく統合する必要がある。Ionel氏によると、当面Dockerのマーケティング部門と営業部門は独立の存在となるという。「我々にとって最も重要なのはクライアントに混乱をもたらさないことだ。そのためチームの統合においても優れたカスタマーエクスペリエンスを維持しなければならない」という。

このことはつまり現在のDocker Enterpriseのクライアントにとっては当面大きな変化はないことを意味する。 Mirantisによれば「Kubernetesとライフサイクル管理テクノロジーの開発、統合を加速すると同時に将来はDocker Enterprise向けのマネージドサービスソリューションを提供していくという。

MirantisとDocker Enterpriseのカスタマーの一部は重複しているものの、この買収によりMirantisは新たに700社のエンターブライズをクライアントに追加することになる。

イオネル氏は「MirantisのライバルはVMware、IBM/Red Hatのような巨大企業だが、我々はクラウドネイティブであり、レガシーのテクノロジーにクライアントをしばりつけることなく、クライアントのコンピューティングをスケールさせることを可能にする」と主張した。

MirantisにとってDockerのエンターブライズ事業の買収が大きな勝利であると同時にDocker時代の終わりを告げるものであることも間違いない。Dockerでは将来に向けた戦略についてさらに発表するとしているが、我々はまだ説明を受けていない。

画像: Chantip Ditcharoen / Getty Images

原文へ

(翻訳:滑川海彦@Facebook

SuseのOpenStackクラウドが終了へ

Suse Linuxディストリビューションをその名の由来とし、ますます多くのマネージドエンタープライズサービスを提供し、最近新しく独立オープンソース企業に戻ったSuse(スーゼ)は、企業向け開発者スペースにおける変化のトレンドの先端にとどまるために米国時間10月9日、ちょっとした新しい戦略を発表した。

過去数年間にわたって、SuseはOpenStackプラットフォームに重点を置いていた。OpenStackプラットフォームは、大企業が自身のデータセンターの中に、AWSやAzureなどのパブリッククラウドのコアサービスに似たものを構築できるようにするための、オープンソースプロジェクトだ。今回の新しい戦略によって、SuseはOpenStackから離れていくことになる。同社はOpenStack Cloudの新しいバージョンの開発と、既存のOpenStack製品の販売の両方を中止する。

「Suseは、世界最大の独立系オープンソース企業として、成長と進化の次の段階に着手するために、私たちの戦略を現在ならびに将来の企業ユーザーの皆さまのニーズに合わせることによって成長していきます。企業ユーザーの皆さまは、ますます動的でハイブリッドなマルチクラウドアプリケーション環境とDevOpsプロセスに移行しようとしています」と同社は声明の中で述べている。「私たちはお客さまが、エッジからクラウドに至る、あらゆるコンピューティング環境を受け入れていくプロセスを助ける、こうした戦略を進めて行く上で、理想的なポジションにいるのです」。

Suseが今後注力するのは、よりアプリケーションデリバリーを強化するためのCloud Application Platform(オープンソースのCloud Foundryプラットフォームに基づくもの)とKubernetesベースのコンテナプラットフォームである。

もしこのセグメントでの売上が成長を続けるようなら、SuseはOpenStackサービスを停止しない可能性もある。OpenStackに関する過剰な宣伝は近年鳴りを潜めたとはいえ、それはいまだに世界でもっともアクティブなオープンソースプロジェクトであり、世界最大規模の企業(通信大手も含まれる)の実運用環境を支えている。OpenStackプロジェクトが、すべてのマインドシェアがコンテナ、特にKubernetesに移行してしまった世界で、自分の立ち位置を見出すためには、数年の時間が必要だった。とはいえ、同時にコンテナは、OpenStackの新しいチャンスを生み出している。なぜなら、これらのコンテナとインフラストラクチャの残りの部分を管理する何らかの方法がまだ必要だからだ。

プロジェクトの舵取りを行う、包括組織のOpenStack Foundationは楽観的だ。

「OpenStackディストリビューションの市場は、Linuxや他の大規模なオープンソースプロジェクトがそうだったように、高度なサポートを提供する、よく慣れたコアグループによって支えられています」と声明の中で語るのはOpenStack FoundationのCOOのMark Collier(マーク・コリアー)氏だ。「すべての企業は戦略的な優先順位を随時調整しています。そしてプライベートクラウドへのコンテナーやVM、そしてベアメタルなどのオープンソースインフラストラクチャ製品の提供に、引き続き注力しているディストリビューションプロバイダーにとって、OpenStackは市場をリードする選択肢なのです」。

コリアー氏によれば、分析会社451 Researchは、KubernetesとOpenStackを合わせた市場規模が約110億ドル(約1兆1800億円)あると考えていて、そのうち77億ドル(約8260億円)はOpenStackに集中していると指摘しているという。「オープンソースクラウド市場全体が、各自8桁(1000万ドル、約10億7000万円)以上の収益に向けて前進を続けていて、そのほとんどがOpenStack製品とサービスに集中していますので、ディストリビューション同士の自然な統合が採択に影響を与えないことは明らかです」と同氏は主張する。

Suseにとっては、OpenStack製品は終わりを迎える。ただし現時点では、同社は引き続きOpenStack Foundationのトップレベルのプラチナスポンサーであり、SuseのAlan Clark(アラン・クラーク)氏はFoundationの役員を務めている。SuseはOpenStackブランドのその他のプロジェクトのいくつかに関与しているため、同社はスポンサーであり続ける可能性が高いが、おそらくトップレベルのスポンサーを続けることはないだろう。

関連記事:SUSEがエンタープライズサービス好調で再び独立企業に

[原文へ]
(翻訳:sako)

MesosphereはD2IQに名称を変更しKubernetesとクラウドネイティブにフォーカス

Mesosphereは、オープンソースであるMesosプロジェクトの、商用サービスを提供するために誕生した会社だ。仮想マシン群をより効率的に実行することは、確かに賢いソリューションだったが、時は移り企業も変化する。8月5日に同社は、名前をDay2IQ(略称はD2IQ)に変更し、Mesosの登場後、数年で急速に成長したKubernetesとクラウドネイティブに焦点を当てることを発表した。

D2IQのCEOであるマイク・フェイ(Mike Fey)氏は、新しい名前は会社自身の新しいアプローチを反映していると語る。Mesosプロジェクトだけに焦点を合わせるのではなく、より多くの成熟した組織がクラウドネイティブテクノロジーを採用することを支援することに、焦点を合わせたいと考えているのだ。

「Mesosphereという名前は、いくぶん窮屈なものだと感じていました。その名前では、会社がある技術に特化しているようなメッセージを出すからです。本当は私たちは通常運用(Day Two operations)をサポートすることをコアミッションとしているのです、すなわちクラウドネイティブアプローチを、単にアーリーアダプターたちのものではなくすべてのユーザーのために役立つものにすることが目的なのです」とフェイ氏は説明した。

なお同社が引き続きMesos駆動のDC/OSソリューションのサポートを続けるという点を、フェイ氏は注意深く指摘した。しかし会社の全体的な焦点はシフトし、新しい名称がそれを表現している。「Mesosプロダクトラインはまだ順調に機能しており、他のものでは提供できないものもまだあります。なので、私たちはそれを完全に放棄してしまうわけではありません。とはいえ、私たちは Kubernetesが非常に強力なことを理解しており、それを支えるコミュニティが素晴らしいことも知っています。私たちはそのコミュニティに付加価値を加えるメンバーの一員になりたいのです」と彼は言う。

彼は、この動きはクラウドネイティブの流行に突然跳び乗ろうとしたものではない、と付け加えた。彼の会社は、DC/OS上で実行されているKubernetesプロダクトを1年以上利用しており、クラウドネイティブコミュニティに貢献している立場なのだと指摘している。

今回の動きは、単に名前と会社の目標、そしてブランドの変更だけに留まるものではなく、同社が様々な顧客、より多くの成熟企業を支援するために開発した、いくつかの新しいクラウドネイティブプロダクトも含まれている(こうした新しいプロダクトたちが新しい会社名をインスパイアしたのだ)。

まず手始めに、同社はKonvoyという名の、独自の味付けを行ったKubernetesを提供する。これは「エンタープライズ品質のKubernetesエクスペリエンス」を提供するという。同社はまた、サポートおよびトレーニングサービスを提供する。これは現在世の中に欠けているものであり、クラウドネイティブに移行したい大きな組織が必要としているものだと同社が考えているものだ。

さらに、クラウドネイティブのやり方で、大量のデータを統合できるように設計されたデータ統合レイヤーを提供する。そのために、同社はKudoベータ版を導入する。これは、Kubernetesでステートフルな運用を構築するための、オープンソースのクラウドネイティブツールだ。同社はすでに、このツールを、Kubernetesやその他のクラウドネイティブプロジェクトを管理するオープンソース組織であるCloud Native Computing Foundationに寄付することを提案している。

同社は、この分野で、IBMとRed Hatの組み合わせのような新たな強打者との厳しい競争に直面している。だが同社は、強いオープンソースの精神を保つことで、Mesosの出自を乗り越えてクラウドネイティブ世界のプレイヤーになることができると信じているのだ。それがいい賭けだったかどうかは時間が経てばわかるだろう。

関連記事:Mesosphere hauls in $125 M Series D investment

画像クレジット: Andrey Suslov / Getty Images

[原文へ]

(翻訳:sako)

Atlassianがデータセンターアプリケーションをコンテナに入れて管理を容易に

5月20日〜23日、Linux Foundation主催で行われたKubeCon + CloudNativeConカンファレンスの大量の発表の中で、特に目立ったのがAtlassianだ。

同社はデベロッパーの効率的な仕事を支える開発ツールでよく知られている企業だが、最近ではクラウドインフラストラクチャのプロバイダーとしても台頭してきた。でも、このコンテナ化の時代においては、AtlassianといえどもKubernetesの栄光の輝きをその肩に浴びざるをえない。そこで同社はカンファレンス初日の5月20日に、チャネルパートナーのPraqmaがAtlassian Software in Kubernetes(ASK)をローンチしたことを発表した。それは、エンタープライズがJira Data Centerなどのオンプレミスアプリケーションを、Kubernetesを利用してコンテナとして動かし管理できる、という新しいソリューションだ。

Praqmaは現在、ASKをオープンソースで提供している。

同社は今日の発表の中で言っているが、データセンターアプリケーションを動かして高い可用性を確保することは、今日までの方法では膨大な作業になる。AKSを使ってアプリケーションをコンテナ化すれば、スケーリングと管理は容易になるはずだ。ダウンタイムも避けやすくなる。

Praqmaのチームはこう説明する。「ASKでは可用性が鍵だ。自動化によって、ミッションクリティカルなアプリケーションは何が起きても動き続けるようになる。もしもJiraサーバーが落ちたら、Data Centerアプリケーションは自動的にトラフィックを健康なサーバーへリダイレクトする。アプリケーションやサーバーがクラッシュしたら、Kubernetesが新しいアプリケーションを起動して自動的に解決する。Jiraのゼロダウンタイムアップグレード、というものもある(正常稼働を続けながらのアップグレード)」。

AKSはスケーリングと多くのアドミンタスクを担当し、オープンソースのGrafanaとPrometheusをベースとするモニタリングも提供する。

さまざまなベンダーが、今ではコンテナを最良のディストリビューションメデイアとして使っている。エンタープライズが既存のアプリケーションをコンテナに移行させていくと、同じシステムにある、サードパーティベンダーからの既存のオンプレミスアプリケーションも同様に管理できると思うようになる。一部のベンダーにとっては、これによってサーバーごとのライセンスからユーザーの人数割りのライセンスへの移行を意味するかもしれない。その意味ではこれはビジネス上の含意もあるけど、でも一般的には、多くのベンダーにとって論理的な動きだ。

[原文へ]

(翻訳:iwatani、a.k.a. hiwa

サーバーレスとコンテナは両者を一緒に使うのがベストプラクティスだ

コンテナに収めたソフトウェアを継続的デリバリ方式で使用するクラウドネイティブモデルは、ランタイムにクラウドベンダーがワークロードを動かすために必要なだけの量のリソースを生成するサーバーレスコンピューティングを利用すると、なお一層有利だ。大手のクラウドベンダーはこのことを知っていて、すでにそのインフラストラクチャを抽象化して隠すプロダクトを作っているが、利点はあるにもかかわらず、どんな状況でも有効とは言えないようだ。

クラウドネイティブは、簡単に言うと、コンテナ化したアプリケーションとKubernetesを使って、ソフトウェアをマイクロサービスと呼ばれる小さなパッケージで配布する。これによってデベロッパーは、継続的デリバリ方式により、ソフトウェアを迅速かつ効率的に配布できる。クラウドネイティブの世界では、コードを開発するのは一度だけ、そしてそれを、オンプレミスでも、どんなパブリッククラウドでもそのまま動かせることが理想だ。

一方サーバーレスは、やや間違った名前だ。このモデルでもコードはサーバーが動かすが、しかしそれは専用の仮想マシンではなく、クラウドのベンダーがワークロードを動かすためにつねに適正な量と時間だけ提供するコンピューティングリソースだ。

万能の完全解はない

このような方式は継続的デリバリモデルによく合ってるようだし、ベンダーもそのことを知っているが、しかしあるエンジニアの言葉を借りれば、そのプロセスは相当複雑であり、また、すべての状況に通用する1つの完全なソリューションはない。

Googleでプロダクト管理を担当しているArpana Sinha氏によれば、Kubernetesのコミュニティはサーバーレスという考え方を本当は歓迎しているのだが、その現在の実装形式に制約がある。つまりAWS LambdaやGoogle Cloud Functions、MicrosoftのAzure Functionsなど現在のの実装形式はいずれも、ファンクションという形式だ。

「ファンクションというコンセプトは制約のあるコンセプトだ。サーバーレスといえばファンクションしか連想しない今の状況は、不幸だ」、と彼女は言う。

彼女によると、Googleはその定義の拡張をトライした。「デベロッパーにとってサーバーレスとは、コーディングからデプロイまでを彼らがシームレスに行い、それ以降のことはすべてインフラストラクチャが面倒見てくれること。黙っていても自分のコードが、インフラストラクチャの適切でもっとも自己回復力のある部分へ確実にデプロイされることだ。必要なリソースは自動的に確保されるからスケーリングも自動化され、スケールダウンも必要に応じて自動的に行われるから無駄な出費がない」と彼女は説明した。

しかしAtlassianのKubernetesチームの上級エンジニアであるMatt Whittington氏に言わせると、理論的にはそれで良くても、実際には完全に自動化されたインフラストラクチャでは現実に合わない場合がある。「デベロッパーがコーディングだけに集中できるからサーバーレスはある種のワークロードにとっては理想的だが、でも完全なソリューションではない。インフラを自分でチューニングしなければならない場合もある」、と彼は言う。

彼によると、ベンダーに完全に任せっきりにできるのは、各コンテナの要求をベンダーに対して指定する方法があるときのみだ。たとえば、コンテナのロードタイムの上限下限をベンダーに指定できるだろうか。ある種のコンテナは時間を食うし、また特定の位置へのデリバリが必要かもしれない。彼によると、実際には完全な自動化はできないし、とくにデベロッパーが設定をいじくって過不足のないリソースが得られるようにしたいときは、自動ではなく手作業になる。

ベンダーも新たな解を提供

これらの問題ではベンダーもツールの提供を始めている。例えばGoogleが先月のGoogle Cloud Nextで発表したサービスGoogle Cloud Runは、オープンソースのKnativeプロジェクトをベースとし、コンテナを動かしているデベロッパーにサーバーレスの長所を結びつける。これと同様のサービスに、AWS FargateAzure Container Instancesがあり、どちらもやはり2つの技術を1つのパッケージにまとめようとしている。

というかMicrosoftのパートナー事業マネージャーのGabe Monroy氏によると、Azure Container Instancesは、この問題をファンクション型のプログラミング方式に依存せずに解決することが狙いだ。「Azure Container Instancesを使うと、コンテナをAzureのコンピュートファブリックの上で直接動かせる。仮想マシンや、ハイパーバイザーによる隔離、秒単位の課金などはない。私たちはそれをサーバーレスコンテナと呼んでいる」と彼は語る。

サーバーレスとコンテナは相性がとても良いように思えるが、でもMonroy氏が指摘するのは、クラウドネイティブの技術には、すべてに通用する唯一の方式はない、ということだ。AWS LambdaやAzure Functionsのようなファンクション型のサーバーレスを今後も使い続けたい人もいれば、コンテナに移行して二つの技術を一体化したい者もいる。しかしいずれにしても、デベロッパーのニーズが変わっていくにつれて、オープンソースのコミュニティとベンダーの両方が、それらのニーズを助けるツールを提供していかなければならない。サーバーレスとコンテナの一体化も、そんな例のひとつだ。

関連記事: いまさら聞けないコンテナ入門

画像クレジット: Ron Miller/TechCrunch

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

使いやすくて親切なKubernetesサービスを目指すDigital Oceanはユニークな機能を揃える

クラウドインフラの意欲的なプロバイダーの例にもれずDigital Oceanも最近、そのプラットホーム上でKubernetesのクラスターを動かすための同社独自のソリューションを発表した。バルセロナで行われたKubeCon + CloudNativeCon Europeで同社は米国時間5月20日に、そのプラットホームDigital Ocean Kubernetesが一般公開されたことを発表した。

このリリースで同社はKubernetesの最新リリース(1.14)を提供し、このプラットホームのユーザーには自動パッチによるアップグレードもそのスケジュールとともに提供される。

一般公開に伴いDigital Oceanは、そのサービスを同社の世界中のデータセンターに持ち込み、いくつかの新しい機能も導入する。その中にはたとえば、ガイド付きの構成体験がある。それによりユーザーはクラスターのプロビジョニングからデプロイへ移行する。また健康診断(Health Metrics)と呼ばれる機能により、デベロッパーがクラスターの状態をモニタできる。それには、ポッドのデプロイステータスやCPU、メモリの使用、などのデータが含まれる。

また、サードパーティが自分のソリューションにDigital Ocean Kubernetesのサポートを容易に統合できるための、オープンなAPIも提供する。

さらに同社はもうすぐ、Kubernetes用のワンクリックアプリケーションを集めたマーケットプレースを開店する。Kubernetesのクラスターへアプリケーションをデプロイすることが、それらのツール的アプリケーションでより容易になるだろう。この機能は、すでにKubernetes用のパッケージ管理のデファクトスタンダードであるオープンソースのHelmをベースとする。

[原文へ]

(翻訳:iwatani、a.k.a. hiwa

GoogleのKubernetes Engineが3種のリリースチャネルとWindows Containerをサポート

2年に一度行われるクラウドネイティブのカンファレンスKubeCon+CloudNativeConでGoogle(グーグル)は米国時間5月20日、Google Kuberentes Engine(GKE)の3つのリリースチャネル、RapidとRagularをStableを発表した。

これによりGoogle Cloudのユーザーは、最新のリリースを選ぶか、それともいちばん安定したやつで行くかなどを選択でき、また最新のアップデートを開発環境の中で容易に評価できる。このリリースチャネル機能は、目下アルファテストの段階だ。

Googleのリリースノートには「各チャネルで、成熟度と鮮度が異なる。デベロッパーはリスクの許容度とビジネスの要求のあいだで適正なバランスを取りながらクラスターをアップデートのストリームにサブスクライブできる」と書かれている。

今アルファで提供されているのはRapidチャネルの最初のリリースで、それがデベロッパーにKubernetesの最新バージョンのアーリーアクセスを与える。

Rapidへのリリースとともに、GoogleはまたGKEによるWindows Containersの初期的サポートを提供する。最近の何回かのリリースの過程でKubernetesのコミュニティはWindowsサポートを徐々に改良し、そして今度はGoogleが6月にWindows Server Containersのサポートを提供する。

これらの機能に加えてさらに、同社はKubernetesをモニタリングするStackdriverツールをリリース。このツールでGKEのモニタリングとロギングができ、また他のクラウドやオンプレミスのインフラストラクチャでのKubernetesのデプロイにも対応できる。

画像クレジット: Alija

[原文へ]

(翻訳:iwatani、a.k.a. hiwa

マイクロソフトとRed HatのコラボでイベントドリブンのKubernetesオートスケーリングツールをローンチ

今やどんなデベロッパーカンファレンスでも、必ずKubernetesのお話がある。そこで当然ながら米国時間5月6日に開催されたMicrosoft(マイクロソフト)のBuildカンファレンスでも、このコンテナオーケストレーションサービスをめぐるいくつかの新しい機能に光が当てられた。

それらの多くは比較的ささやかなもので、Azure Policyのサポートの改良や、コンテナの構築とデバッグのための新しいツール、Azure Containerレジストリのアップデートなどが紹介された。レジストリは、ユーザーがHelmチャートを使ってCI/CD(継続的インテグレーションとデプロイメント)のワークフローを自動化できるようになった。

しかし今回いちばんおもしろいのは、Red HatとMicrosoftのコラボレーションによるオープンソースのコラボレーションツールKEDAで、それはサーバーレスでイベントドリブンなコンテナのデプロイを助ける。KEDAはKubernetes-based Eevent-Driven Autoscaling(Kubernetesベースのイベントドリブンなオートスケーリング)の略で、これによりユーザーは、自分のイベントドリブンアプリケーションをKubernetes上に作れる。KEDAがトリガーを処理し、他のサービスで起きたイベントに応答して、必要に応じワークロードをスケールする。

KEDAは、パブリッククラウドでもプライベートクラウドでも、そしてオンプレミスでも使える。クラウドはベンダを特定しないが、もちろん当然Azure Kubernetes ServiceやRed HatのOpenShiftでもよい。KEDAがあるとデベロッパーは、MicrosoftのサーバーレスプラットホームAzure FunctionsをKubernetesクラスターの中のコンテナとしてデプロイできる。それは、OpenShift上でもいい。

画像クレジット: Ron Miller

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

GoogleがGKE Advancedでコンテナサービスをエンタープライズ向けに拡充

Google Cloudは長年、Kubernetes Engine(GKE)でそのプラットホーム上でコンテナを動かすためのマネージドサービスを提供してきた。Kubernetesユーザーのニーズはさまざまだが、でもこれまでのところGoogleはGKEの単一のティアのみを提供し、それは必ずしも、同社が顧客として捉えようとしているハイエンドのエンタープライズユーザーには向いていなかった。しかしながら米国時間4月16日に同社は、新しい機能を数多く備え、SLAに経済的条件を導入し、セキュリティと自動化の機能を高めた、より高度なエディションのGKEであるGKE Advancedを発表した。GKE Advancedはいわば、GKEのエンタープライズバージョンだ。

この新しいサービスは本年の第2四半期にローンチするが、料金はまだ発表されていない。通常のバージョンのGKEは、GKE Standardと呼ばれる。Googleによるとこのサービスは、社内的に何年間も複雑なコンテナインフラストラクチャを動かしてきた経験から学んだことが、ベースになっている。

エンタープライズの顧客にとっては、SLAに経済的条件(SLOが達成されないときの返金制)が盛られていることが嬉しいボーナスだ。ここでの基本的な約束は、リージョナルクラスターの保証可用性(SLO)が99.95%であることだ。

マネージドなKubernetes環境を選んだユーザーの多くは、クラスターを自分で管理する面倒を避けたいからそうしている。しかしGKE Standardでは、クラスターのスケーリングに関してユーザーが一部の作業をしなければならない。そこでGKE AdvancedではVertical Pod Autoscalerと呼ばれるツールがリソースの使用状況をたえずウォッチし、必要に応じてリソースの伸縮を図る。またNode Auto Provisioningツールは、GKE Standardにあるクラスターオートスケーリングの高性能バージョンだ。

GKE Advancedは本体のこれらの機能だけでなく、GKE Sandboxのようなセキュリティ機能も加えている。このサンドボックスは目下ベータだが、GKE Advancedだけにしかない機能になる。そして、コンテナ環境では署名があって検証されたイメージだけしか使われないように強制する。

このサンドボックスは、GoogleのコンテナサンドボックスランタイムgVisorを用いる。これによってどのサンドボックスも自分だけ用のユーザースペースカーネルを取得し、セキュリティの層がひとつ増える。またBinary AuthorizationによってGKE Advancedのユーザーは、すべてのコンテナイメージが信頼された機関によって署名されてからでないとプロダクションに入れられないようにできる。コンテナに悪意あるコードを潜ませることは論理的には可能だが、コンテナのリリースにこのプロセスが課せられることによって、検定され認可されたコンテナのみがその環境で動けるようになる。

GKE AdvancedにはGKEの利用計測機能があるので、社内での利用状況に応じて各部門に課金の適性な分担を求めることもできる。これもやはり、GKE Advancedのみの機能だ。

[原文へ]

(翻訳:iwatani、a.k.a. hiwa