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

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

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

クラウドネイティブは、簡単に言うと、コンテナ化したアプリケーションと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

通信市場で争うオープンソースコミュニティ

先日バルセロナで開催されたMWCのことを考えるとき、おそらくあなたは最新のスマートフォンや他の携帯機器について考えることだろう。だがそれは物語の半分に過ぎない。実際には、そうした話題は半分以下なのだ。なにしろMWCで行われているビジネスの大部分は、企業向け通信ビジネスに関わるものだからだ。それほど遠くない昔、そのビジネスとは、高価な専用ハードウェアを売ることに他ならなかった。だが現在は、これらのほとんど全てがソフトウェアに移行している。そして多くのソフトウェアがオープンソースなのだ。

なので、今年Linux Foundation(LF)がMWCに独自のブースを設けたのは当然のことだ。それは巨大なものではなかったが、独自のミーティングスペースを確保できる程度には大きなものだった。ブースはLFによる3つのプロジェクトによって共同利用されていた:Cloud Native Computing Foundation(CNCF)、Hyperledger、そしてONAPOpen Platform for NFV (OPNFV)(どちらも最新ネットワークに欠かせない)などの、基本的なプロジェクトを支えるLinux Foundation Networking (LFN)である。そして5Gの出現により、つかむべき新しい市場シェアがたくさん生まれている。

このイベントにおけるCNCFの役割について議論するために、私はCNCFのエグゼクティブディレクターであるDan Kohn氏の話を聞いた。

MWCでCNCFは、OpenStack上の仮想ネットワーク機能と、CNCFがクラウドネイティブネットワーク機能と呼ぶものの性能を比較したテストベッドを発表した。このクラウドネイティブネットワーク機能は、Kubernetes(とベアメタルホストであるPacket)を利用している。プロジェクトの成果として示されたものは、少なくともこれまでのところは クラウドネイティブコンテナベースのスタックは、競争相手のOpenStackコードよりも1秒あたりにはるかに多くのネットワーク機能を処理できたということである。

「私たちが発信しているメッセージは、ベアメタルもしくは任意のクラウドの上で動作する、汎用プラットフォームとしてのKubernetesを使えば、ほとんどの仮想ネットワーク機能は、クラウドネイティブネットワーク機能上に移植できるということです」とKohn氏は語った。「すべての運用支援システム、すべてのビジネス支援システムソフトウェアも、同じクラスタ上のKubernetesで実行することができます」。

さて、一方OpenStackは、また別の大規模なオープンソースプロジェクトである。ご存知ない方のために説明すると、企業が自身のデータセンターのソフトウェア基盤を管理するための手段を与えるものだ。OpenStackの最大の市場の1つは、長い間通信業界だった。これまでも常にCNCFとOpenStack Foundationの間には、ある種の摩擦が続いていたが、OpenStack Foundationがその組織を、直接コアOpenStackプロジェクトとは関係しないプロジェクトへも開放したことによって、その摩擦傾向は強まった。

私はKohn氏に対して、現在CNCF/Kubernetesスタックを、OpenStackのライバルとして位置付けているのかどうかを尋ねた。「はいそうです。私たちの見解は、Kubernetesをベアメタルサーバー上で動作させるべきで、中間層は不要だというものです」と彼は述べた。これまでCNCFはこうしたことを明言しては来なかったが、内部ではずっとそのように言われていたのだ。彼はまた、こうした摩擦の一部が、CNCFとOpenStack Foundationが、様々なプロジェクトに対して競合関係になっていることから生じていることを認めた。

OpenStack Foundation側は、当然ながらこうした対立には同意しない。OpenStackのCOO、Mark Collierは「KubernetesをOpenStackと対立するものとして扱うことは極めて非生産的です。それに、OpenStackが既に多くのケースで、Kubernetesと組み合わせる形で5Gネットワークを支えているという事実を無視することになります」と私に対して語った。「それに、OpenStackが単なる仮想マシンのオーケストレーターだとおっしゃっているのでしたら、OpenStackが実際に何をしているのかについての理解が不足なさっていることも意味していますね。そうした説明は、もう数年前の過去のものです。多くのワークロードにとって意味のある、仮想マシンからの離脱が、OpenStackからの離脱を意味するわけではありません。今ではOpenStackはそうした環境のなかで、Ironic、Neutron、およびKeystoneサービスを通じてベアメタル、ネットワーク、そして認証を管理しているのです」。

同様に、OpenStack Foundationの元ボードメンバー(ならびにMirantisの共同創業者)であるBoris Renski氏は、私に対して以下のように語った「単にコンテナーがVMに取って代わることができるからといって、KubernetesがOpenStackに取って代わるわけではありません。Kubernetesの基本設計は、低レベルのインフラストラクチャを抽象化する以外のものがあることを前提としています、すなわちアプリケーションを意識したコンテナスケジューラであることを目指しています。一方OpenStackは、ベアメタル、ストレージなどの低レベルのインフラストラクチャ構造を抽象化することを目的に、特別に設計されているのです」。

この議論はKohn氏とCNCFによるKata Containersへの批判にもつながっている。Kata Containersとは、OpenStack Foundationがその組織をOpenStack以外のプロジェクトに対しても開放した後に手がけた、最初のプロジェクトである。Kata Containersは、従来の仮想マシンに対してさらなるセキュリティを加え、コンテナの柔軟性と組み合わせて提供することを約束している。

「KataをめぐるFUD(不安や疑念)に関してはこう言うことができます:通信会社は(a)騒がしい隣人問題(同じテナントに載る他のインスタンスとのリソース競合問題)と、(b)セキュリティに関する問題に対応するために、Kataを使う必要が出てくるでしょう」とKohn氏は語る。「それは未知のものに対するFUDに過ぎませんし、(Kataの採用する)マイクロVMは本当に興味深い技術なのです」。

しかし彼は、サードパーティのコードを実行しているような状況(Firecrackerを実行しているAWS Lambdaを想像して欲しい)に対しては、Kataのやりかたは興味深いと考えているが ―― 残念ながら通信業者たちは通常そのようなコードを実行したりはしないのだ。そして彼はまた、Kubernetesも騒がしい隣人たちをうまく扱うことができると主張している。なぜならそれぞれのコンテナが抱えることのできるリソースの数を限定することができるからだ。

どちらの組織もここではフェアな議論をしているように見える。KubernetesはいくつかのユースケースではOpenStackよりも、よりうまい処理を行い、高いスループットを提供できるかもしれないが、その一方では、OpenStackはそれ以外の多数のユースケースを上手く扱うことができる。だが明らかなのは、ここにかなりの摩擦が生まれていることなのだ。残念なことである。

画像クレジット: Jean Joselle Rosal / EyeEm / Getty Images

[原文へ]
(翻訳:sako)

CNCFプロジェクトへのトップコントリビューターは変わらずGoogle

ある企業が、オープンソースにどれだけコントリビュートしているかを視覚化するプロジェクトStackalyticsの最新のデータによれば、CNCFオープンソースエコシステムに対して、Googleが変わらぬ大きな影響力を保持していることが明らかになった(Stackalyticsは、Mirantisによって設立され、OpenStack Foundationによってホストされている)。確かに、このデータによれば、GoogleはCNCFプロジェクトへコミットされる全てのコードの、およそ53%を担っている。2番目に大きなコントリビューターであるRed Hatは、7.4%とはるかに引き離されている。

CNCFはKubernetesの総本山だ。KubernetesはGoogleがオープンソース化した非常に人気の高いコンテナオーケストレーションサービスである。このことを考えれば、Googleがトップコントリビューターである事実に大きな驚きはないだろう。しかし、データによれば、Kubernetesを考慮に入れなかったとしても、Googleは依然として、全CNCFプロジェクトに対するトップコードコントリビューターなのだ。その理由の一部は、同社がCNCFに寄付したキューイングプロジェクトであるGRPCと、YouTubeのために開発したデータベースクラスタリングシステムVitessの主要コントリビューターでもあることにも由来している。

それでもGoogleが主なコントリビューターではないプロジェクトも沢山ある。例えばJaegerの64%のコントリビューションはUberから提供されたものであり、LinkerDのコードコミットの84%はBuoyantのエンジニアから出てきたものだ。興味深いのは、レポートによれば、特定の1社が40%以上のコントリビュートを行っていないプロジェクトは1つしかないということだ。それはモニタリングソリューションのPrometheusである。これはSoundCloudによってCNCFに寄付されたものだが、現在その大部分がRedHatの個人開発者たちによって保守されている。

こうした統計情報を読めば、GoogleはCNCFエコシステムの中で少々支配的すぎると言いたくなるかもしれない。だがもちろんGoogleは、そうは考えていない。

「Googleは、オープンソースソフトウェアへのコントリビューションに対して、長い貢献と尊重の歴史を持っています。私たちは還元することが喜びなのです」と語るのは、GKEならびにKubernetes、そしてGoogle CloudのグループプロダクトマネージャーであるAparna Sinhaである。「まず心に浮かぶ例はKubernetesです。オープンソース史上最も速く成長したプロジェクトの1つであり、現在は活発なコミュニティと幅広い業界からの支持を受けています。Googleは、コミュニティとより広範なCNCFの中で変わらぬ推進力を発揮し、中心的な役割を果たして来ました。その勢いの主要な部分は、広範なエンジニアリングの専門知識、コードのコントリビューション、そして計算機リソースの供与、あるいはプロジェクトマネジメントや、テストならびにドキュメンテーションの提供といった、Googleによるプロジェクトの成功への深いコミットメントによるものです。私たちはこれまで同様に、プロジェクトに献身的に取り組んでおり、より広いKubernetesコミュニティがプロジェクトの未来を形作り、その長期的な成功を確実にし始めていることに興奮を抑えることができません」。

CNCFがDevStatsツールを介して自身のデータを公開していることも注目に値する。これは内容的にはStackalyticsと似たような傾向は読み取れるものの、コントリビューターとしてのGoogleの優位性をさほど大きく示してはいない。Mirantisの共同創業者でCMOのBoris Renskiにこれらの不整合について尋ねたところ、Stackalyticsがコミットそのものに焦点を当てているのに対し、CNCF自身のツールはレビュー、コメント、提出されたイシューなどへのコントリビューションに着目していることを指摘した。またStackalyticsは、Red Hatがかなりのコントリビューションを行っている、CNCFのサンドボックスプロジェクトも考慮に入れていない。2つのツールはまた、属性を異なる方法で処理している。DevStatsは、以前CoreOSから提供されていたコントリビューションに関しては、RedHatによる買収後は全てRedHadからのコントリビューションとして取り扱っている。

Twitter上でRenskiは、それぞれの組織はこうした不整合を取り除くために各データソースをマージすべきであると提案した。だが筆者の見るところ、CNCFとOpenStackが、現在どれほどきちんと共同作業を行うことができるのかはわからない。

[原文へ]
(翻訳:sako)

Cloud Native Computing Foundationが抱えるオープンソースプロジェクトにetcdが加わった

KubernetesVitessなど、クラウドに関連したオープンソースプロジェクトが身を寄せる事務管理団体Cloud Native Computing Foundation(CNCF)が今日、その技術委員会が新しいプロジェクトの入会を認める票決を行った、と発表した。そのプロジェクトetcdは、CoreOSで開発されたキー-ヴァリューストアで、今回Red HatがこのプロジェクトをCNCFに寄贈した。CoreOSはかつてRed Hatが買収、そしてそのRed Hatは近くIBMがオーナーになる、という関係だ。

etcdはGoで書かれていて、すでに多くのKubernetesデプロイメントの主要な部位のひとつだ。そこではetcdが、他と重複しない唯一の真実の情報源として機能し、クラスターのコーディネーションやシステムのステートの管理に使用される。同じくオープンソースのCloud Foundryもetcdを使い、Alibaba, ING, Pinterest, Uber, The New York Times, Nordstromなどの企業はプロダクション(本番稼働)でetcdを使っている。

CNCFのCOO Chris Aniszczykが、今日の発表声明で言っている: “KubernetesやCloud Foundryなど多くのプロジェクトが、信頼できるデータストレージをetcdに依存している。etcdがインキュベーションプロジェクトとしてCNCFに加わったことは喜ばしいし、今後はドキュメンテーションやガバナンスなどなどの改良によりコミュニティをさらに育成していきたい。etcdがわれわれのプロジェクトのコミュニティに加わったことは、本当にすばらしい”。

今日、etcdには450名を超えるコントリビューターと、8社からの9名から成るメンテナーがいる。すでにKubernetesをホストしているCNCFに身を寄せたことは、きわめてロジカルだ。これでCNCFがホストするプロジェクトは17になり、それらが同団体の“育成技術”の傘下に入る。それらはetcdのほかに、OpenTracing, Fluentd, Linkerd, gRPC, CoreDNS, containerd, rkt, CNI, Jaeger, Notary, TUF, Vitess, NATS Helm, Rook, そしてHarborだ。Kubernetes, Prometheus, そしてEnvoyは、すでに育成段階を卒業している。

ひとつのファウンデーションが管理するプロジェクトにしては多いが、しかしCNCFのコミュニティ自体が相当大きい。今週だけでも、シアトルで開かれた同団体最大のカンファレンスKubeCon/CloudNativeConに8000名のデベロッパーが集まり、コンテナに関するありとあらゆることを議論しあるいは講演した。AWS, Microsoft, Google, IBM, Oracleといった大物が参加してコラボレーションしていることの意義も大きい。OpenStackプロジェクトのように、成長後期に手を広げすぎて焦点がぼやける危険性もあるが、そうならないための、同団体の今後の管理の手腕を見守りたい。たぶん次にCNCFに加わるのは、ますます人気急増中のサービスメッシュIstioだろう。

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

GoogleがKubernetesの開発インフラの自社負担から降りてすべてをCNCFに委ねる

Googleが今日(米国時間8/29)、同社がCloud Native Computing Foundation(CNCF)に、Google Cloudのクレジット900万ドルを提供して、Kubernetesコンテナオーケストレータの同団体による今後の開発を支援し、プロジェクトの運用に関わるコントロールを同団体に委ねる、と発表した。このクレジットは3年分割で提供され、Kubernetesソフトウェアの構築や試験、配布などに要する費用に充当される。

これまではGoogleが、このプロジェクトを支えるクラウドリソースのほとんどすべてをホストしていた。その中にはたとえばCI/CDによるテストのためのインフラストラクチャや、コンテナのダウンロード、同社クラウド上のDNSサービスなども含まれている。しかしGoogleは今回、一歩後退することになった。Kubernetesコミュニティの成熟に伴い、GoogleはKubernetesのすべてのサポートワークをコミュニティに移そうとしている。

テストのためのインフラストラクチャからコンテナダウンロードのホスティングまで、すべてを合わせるとKubernetesプロジェクトは常時、15万あまりのコンテナを5000基の仮想マシン上で動かしている。その費用は、相当に大きい。Kubernetesのコンテナレジストリはこれまで、1億3000万回近いダウンロードに応じてきた。

それにまた現在のCNCFは、互いに競合する多様なメンバーを抱えている。Alibaba Cloud, AWS, Microsoft Azure, Google Cloud, IBM Cloud, Oracle, SAP, VMwareなどがその例だ。全員がCNCFの仕事やKubernetesのコミュニティから利益を得ている。Googleはこれまで黙っていたが、そろそろKubernetesのインフラストラクチャを動かす重荷を、それにふさわしい者に担わせるべきだろう。それにコミュニティのメンバーの一部は、KubernetesがGoogleのインフラストラクチャにあまりにも密接に結びついていることを、嫌っていた。

GoogleのKubernetes EngineのプロダクトマネージャーWilliam Denissが、今日の発表声明でこう書いている: “Kubernetesの運用責任をプロジェクトのコントリビューターが共有することによって、彼ら全員が持ち寄る新しいアイデアや効率性を生かせるようになるだろう。それが楽しみである”。彼によると今後も、Kubernetesのインフラストラクチャの運用には、Googleの意思が適宜反映されていく、という。

CNCFの事務局長Dan Kohnはこう述べる: “KubernetesのコミュニティにGoogleの大きな財政支援があることによって、このプロジェクトのイノベーションと採用の安定的なペースが今後も減衰することなく維持されるだろう。Google CloudがKubernetesのテストとインフラストラクチャに関わるプロジェクトをコントリビューターの手に渡したことによって、プロジェクトはオープンソースであるだけでなく、オープンなコミュニティによってオープンに管理されるものになる”。

今後長期的には、インフラストラクチャがGoogleのクラウドから離れることになるのか、そのへんはまだ分からないが、3年後に他のクラウドプロバイダーが同様のクレジットを提供することは、大いにありえるだろう。

[原文へ]
(翻訳: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)

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

Cloud Native Computing Foundationに署名方式の強力なセキュリティプロジェクトNotaryとTUFが加わる

Cloud Native Computing Foundation(CNCF)は、コンテナオーケストレーションツールKubernetesのホームとして知られているが、そのほかにもさまざまなオープンソースプロジェクトが身を寄せている。どれも、現代的なクラウドネイティブ関連のツールで、GoogleやMicrosoft、Facebookなどをはじめ、各社において、今ではそれらの利用が日常化している。

今日(米国時間10/23)はCNCFの厩(うまや)に、Docker生まれの2頭、NotaryThe Update Framework(TUF)が入った。その最初の開発者はニューヨーク州立大学のJustin Cappos教授と、そのTandonエンジニアリングスクールのチームだ。二つは互いに関連していて、どんなコンテンツにも保護と安心の層を加えるNotaryは、TUFの実装なのだ。

これらの背後にある基本的な考え方は、単純にTLSプロトコルを使ってWebサーバーとクライアント間のコミュニケーションを保護するのでは不十分、サーバー自身がハックされることもある、という認識だ。たとえば、Dockerのコンテナを配布して、それらが安全であると保証したいなら、Notary/TUFのクライアント/サーバアプリケーションがメタデータの署名を扱うことによって、さらなる安心の層を加えるのだ。

“デベロッパーのワークフローの中で、セキュリティは後知恵になりがちだ。しかしそれでも、
デプロイされるコードはOSからアプリケーションに至るまですべての部分が署名されていなければならない。Notaryは強力な安心保証を確立して、ワークフローの過程中に悪質なコンテンツが注入されることを防ぐ”、とDockerのシニアソフトウェアエンジニアDavid Lawrenceは語る。“Notaryはコンテナの分野で広く使われている実装だ。それがCNCFに加わることによって、さらに広く採用され、さまざまな新しいユースケースが登場してきてほしい”。

たとえばDockerはこれを使って、そのDocker Content Trustシステムを実装しているし、LinuxKitはカーネルとシステムパッケージの配布に利用している。自動車業界も、TUFの別の実装であるUptane使って、車載コードの安全を図っている。

Notary/TUFについて詳しく知りたい方には、Dockerのドキュメンテーションが勉強の入り口として最適だろう。

“NotaryとTUFの仕様は、コンテンツのデリバリに関する、信頼性の高いクロスプラットホームなソリューションを提供することによって、コンテナを利用するエンタープライズの重要な課題に対応している”、とCNCFのCOO Chris Aniszczykが今日の発表声明に書いている。“これらのプロジェクトが一体的なコントリビューションとしてCNCFに加わることは、とても嬉しい。今後、これらを軸としてさまざまなコミュニティが育っていくことを、期待したい”。

Docker Platform(EnterpriseとCommunityの両エディション)や、Moby Project, Huawei, Motorola Solutions, VMWare, LinuxKit, Quay, KubernetesなどはすべてすでにNotary/TUFを統合しているから、CNCFのそのほかのツールとの相性の良いプロジェクトであることも確実だ。

NotaryとTUFが加わったことによって、CNCFを実家とするプロジェクトは計14になる。

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

コンテナ化という大きな趨勢にとってはスタンダードがきわめて重要、AWSは自らその意思を示す

AWSが今日(米国時間8/9)、コンテナの標準化団体Cloud Native Computing Foundation(CNCF)の正会員になったとき、同社の重要なマイルストーンが刻まれた。GoogleやIBM, Microsoft, Red Hatなど、この分野の有力企業の仲間入りをすることによって、コンテナの管理に関してはスタンダードを無視できないことを、認めたのだ。

なにしろ、これまでもっぱら我が道を行くだったAWSである。しかもAWSは今や、その強力な巨体で広大なマーケットシェアを支配しているから、さまざまな面で自分流を貫いても平気だ。しかし、コンテナは違った。今コンテナを支配しているのは、かつてGoogleで生まれたオープンソースのコンテナ管理ツールKubernetesだ。

聡明なAWSは、Kubernetesが業界標準になりつつあることと、作るか買うかオープンソースで行くかの三択に関しては、戦いがすでに終わっていること、とっくに結論が出ていることを悟った。

コンテナ管理におけるGoogleの優勢を認めたからには、次の論理的ステップはCNCFに加わり、業界全体が使っている同じコンテナの規格に従うことだ。人生には戦うよりも自分を変えた方が得策なこともあり、これがまさに、その典型的な例だ。

そしてAWSがCNCFに加わったことによって、業界全体としてのコンテナ化に向かう路程が明確になった。今それは、とくに大企業において大きなブームになっている技術だが、それには十分な理由がある。アプリケーションをいくつもの離散的な塊に分割して構築していくので、メンテナンスとアップデートがきわめて容易である。そしてDevOpsのモデルにおいて、デベロッパーのタスクとオペレーションのタスクを明確に分離できる。

いくつかのスタンダードが、コンテナを開発し管理するための共通基盤を提供している。その上で各人が、独自のツールを作ることもできる。GoogleのKubernetesも、最初はそのひとつだったし、Red HatのOpenShiftやMicrosoftのAzure Container Serviceなども、そんな独自ツールの例だ。

しかしスタンダードがあると、誰が何を作っても、その構造や動作の共通性をあてにできるし、したがってその利用も楽だ。どのベンダーもサービスのベースはほぼ同じであり、違いは上位的な機能や構造にのみ現れる。

業界の大半がスタンダードに合意すると、その技術は離陸していく。World Wide Webは、その偉大なる例だ。それは、Webサイトを作るスタンダードな方法だから、完全な共通技術へと離陸できた。ビルディングブロックに関して多くの企業が合意したら、そのあとはすべてがうまく行く。

スタンダードの欠如が、技術の足を引っ張った例も少なくない。全員が共通のビルディングブロック(構築部材)を持つことは、きわめて有意義なのだ。しかしときには、だんとつのマーケットリーダーが合意に参加しないこともある。今日のAWSは、そんなリーダーにとってもスタンダードが重要であるという認識を、示したのだ。

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