10年間のコンテナ技術の進化

この記事では、10年にわたるコンテナ技術の進化と、それが最新のソフトウェアインフラストラクチャと配信をどのように改革するかについて説明します。

著者 Zhang Lei：Alibaba Cloud Container Platformのシニアテクニカルエキスパート、CNCFアンバサダー、シニアメンバー、Kubernetesメンテナー

今年、世界中の開発者がソフトウェアのテストとオンラインリリースにコンテナを使い始め、コンテナベースのソフトウェアのビルドと配信に慣れてきました。クラウドネイティブな技術や、マルチクラウド時代のアプリケーションガバナンスの方法についての議論も一般的になってきました。当然のことながら、"サイドカー "と呼ばれるコンテナパターンがデフォルトの選択です。クラウドが一般的なインフラになった現代では、コンテナを現代のソフトウェアインフラの基本的な依存関係と考えることが当たり前になっています。今では、毎日Eclipseを使ってJavaコードを書くように、自然にコンテナを使っています。

しかし、2年前には、コンテナのエコシステム全体がDockerを巡って激しい議論を繰り広げており、コンテナサービスの見通しは全く不透明に思えました。その時点では、中国の多くのパブリッククラウドプロバイダーは、正式なKubernetesサービスを持っていませんでした。コンテナ技術を使ってソフトウェアのライフサイクル全体をクラウド上で管理するというのは、かなり最先端の試みでした。わずか2年の間に、コンテナが技術者の日常業務の一部になるとは、誰が想像できたでしょうか。

コンテナ技術が普及するにつれ、この2年間で、現代のソフトウェアの提供方法に重要な改革が行われました。

起源

仮想化コンテナ技術の起源は、1970年代末にさかのぼります。1979年、ベル研究所では、OS「Unix V7（バージョン7 Unix）」のリリースに向けて、最終的な開発・テスト作業が開始されました。

PDP-11でのKen Thompson（座っている方）とDennis Ritchie ©wikipedia

その頃、Unix OSはまだベル研究所の内部プロジェクトでした。Unixが動作するマシンは、PDPシリーズの巨大な箱で、オーディオのダイヤルやコントロールがついているようなものでした。ソフトウェア危機の最終局面で、巨大なUnix OSプロジェクトを開発・維持するのは、ベル研究所にとっても容易ではなく、さらに困難だったのは、プログラマーがUnixの開発と並行してC言語も開発しなければならなかったことでした。

Unix V7の開発では、構築とテストの効率化が最も難しい問題の一つでした。その理由は明白で、システム・ソフトウェア・アプリケーションがコンパイルされ、インストールされると、テスト環境全体が実際に「汚染」されるからでした。次のビルド、インストール、テストを実施するためには、テスト環境を再構築し、再構成しなければなりません。クラウドコンピューティングが可能な現在では、仮想マシン（VM）などの手法を用いてクラスタ全体を再現することも可能です。しかし、64KBのメモリチップが419ドルもした時代に、インフラを素早く破壊して再構築するというのは、一種のファンタジーだったのです。

ベル研究所の頭脳は、効率化のために、既存のOS環境下でソフトウェアのビルドとテストを行う隔離された環境を作ることを考案しました。具体的には、カレントディレクトリをルートディレクトリとして使用するように、簡単なディレクティブを実行することで、アプリケーションの表示を変更できるかどうかを調べようとしました。もしそれが可能であれば、OS全体のファイルシステム部分をカレントディレクトリに置くだけで、ソフトウェアアプリケーションの実行に必要なすべての依存関係が整うことになります。

さらに重要なことは、この機能があれば、開発者は間接的に、環境構築後に依存関係をインストールして設定する必要がなくなり、アプリケーションのインフラを素早く破壊して再現することができるようになります。なぜなら、ソフトウェアアプリケーションの実行に必要なすべての依存関係が、OSの下のファイルディレクトリの形であらかじめ用意されているからです。開発者は、アプリケーションを構築してテストする際に、アプリケーションのルートディレクトリをファイルディレクトリに切り替えるだけでよいのです。

そこで、「chroot（Change Root）」というシステム呼び出しが生まれました。

chrootは、その名の通り、現在実行中のプロセスとその子プロセスのルートディレクトリをファイルシステム上の新しい場所に変更し、現在のプロセスがその場所の上位にアクセスできなくするものです。この隔離された環境は、Chroot Jailという名前で呼ばれました。

なお、chrootを生んだUnix V7 OSは、Bell Laboratories社がリリースしたUnixのファーストクラスの社内版です。その年の暮れには、AT&T社によってUnixが正式に商品化され、外部での使用が許可されました。

chrootの誕生により、初めてプロセス分離の扉が開かれる

この仕組みを採用するユーザーが増えるにつれ、chrootは開発・テスト環境の設定やアプリケーションの依存関係を管理するための重要なツールにもなっています。また、プロセス環境の隔離を表す「Jail」という概念は、この技術分野でのさらなる成果を鼓舞しています。

2000年、同じくUnix系のOSであるFreeBSD、「jail」コマンドがリリース

これは、FreeBSD の jail 環境が一般的に利用可能であることを示しています。Chroot Jailと比較して、FreeBSDのjailメカニズムは、「隔離」の概念をプロセスの全体像にまで拡張し、隔離されたプロセス環境とユーザシステムを提供し、jailには独立したIPアドレスを割り当てます。したがって、正確に言えば、chrootはプロセス環境の隔離の原点そのものですが、実際にjailされたプロセスをサンドボックス化するのはFreeBSDのjailメカニズムです。重要なのは、このサンドボックスの実装が、ハードウェアの仮想化ではなく、OSレベルの隔離と制限に基づいている点です。しかし、FreeBSD jail（Unix上）も、その後のOracle Solaris Containers（Solaris上）も、より幅広いソフトウェアや配信のシナリオにおいて、より重要な役割を果たすことができませんでした。jailの時代には、クラウドの概念が普及していなかったため、プロセス・サンドボックスの技術は常に限定的で、小さなコミュニティにしか知られていませんでした。

開発:クラウドとアプリコンテナ

実は、jailが過度に普及したここ数年で、Linux VServerやOpenVZ（カーネルトランクには含まれていない）など、サンドボックスに似た技術が、急速に発展するLinuxプラットフォーム上で複数開発されています。しかし、これらのサンドボックス的な技術も、刑務所と同様に、ごく一部のコミュニティでしか知られていません。これは、プロセス・サンドボックスの開発において、クラウドの役割が欠けていたことが、大きな悪影響を及ぼしたことを改めて証明しています。クラウドについては、インフラ分野のリーディングカンパニーであるグーグルを抜きにしては語れません。

クラウドコンピューティングを支える中核的な要素であるインフラの分野におけるグーグルの影響力は、業界で広く認識されています。画期的な3つの論文にしても、BorgやOmegaといった長年業界をリードしてきた社内のインフラプロジェクトにしても、グーグルはこの業界で重要な役割を果たしています。しかし、現在のクラウドコンピューティング市場では、Google Cloudよりもわずか1年早くリリースされたAWSが、間違いなく業界をリードしています。GAEでの経験を考えると、これは賛否両論ある結論だと思われる方も多いのではないでしょうか。

Google App Engine（GAE）は、何世代にもわたって中国の技術者たちの心に忘れがたい印象を残してきました。しかし、これらの忠実なGAEユーザーも、実はGAEが当時GoogleがAWSに対抗するために計画した中核的なクラウド製品であることを知らないかもしれません。実際、GAE自体はPaaSというよりも、Serverlessの簡易版と言った方がいいでしょう。GAEのような製品が2008年にエンタープライズレベルのユーザーを獲得するのは難しく、ほとんどの人がクラウドコンピューティングとは何かを全く理解していない時代でした。

ここでお話しするのは、Googleのクラウド戦略ではなく、なぜGoogleがGAEのようなアプリケーションホスティングサービスを技術的にクラウドコンピューティングサービスとして捉えているのかということです。

多くの人がすでに知っているであろう重要な理由の一つは、Googleのインフラストラクチャテクノロジースタックが、実は仮想マシンテクノロジースタックではなく、標準的なコンテナテクノロジースタックであるということです。さらに重要なことは、Googleのシステムでは、Borgプロジェクトが提供する独自のアプリケーション・オーケストレーションと管理機能により、コンテナはもはや分離されたプロセスのための単なるサンドボックスではなく、アプリケーション自体をカプセル化する手法であるということです。この軽量なアプリケーションのカプセル化に頼ることで、Googleのインフラは自然とアプリケーション中心のホスティングとプログラミングのフレームワークになると考えられています。多くの元Google社員が「Borgがないとコードの書き方がわからない」と冗談を言うのはこのためです。このアーキテクチャと形態が、外部のクラウドサービスにマッピングされた後に、GAEのようなPaaS/サーバーレス製品になることを理解するのは簡単でしょう。

Googleにおけるコンテナベースのインフラストラクチャの大規模な適用と成熟は、2004年から2007年にさかのぼります。その中で重要なマイルストーンの1つが、プロセスコンテナのリリースです。

プロセスコンテナの目標は、仮想化技術と同様に、プロセスに対してOSレベルのリソース制限、優先度制御、リソース監査、プロセス制御の機能を提供することであり、前述のサンドボックス技術の目標とほぼ一致しています。これらの機能は、グーグルの社内インフラ実装の基本要件であり、依存関係にあります。また、Googleのコンテナ技術のプロトタイプを構成するものでもあります。2006年にGoogleのエンジニアによってリリースされたプロセスコンテナは、翌年にはLinuxカーネルトランクに搭載されました。

Linuxカーネルでは「コンテナ」という言葉が使われていたため、プロセスコンテナはLinuxではCgroupsと改称されました。Cgroupsの登場は、Linuxにおける「コンテナ」コンセプトの新たな見直しと実装を意味しています。今回、コンテナ技術を提唱したのは、コンテナ技術を大規模に使用して世界クラスのインフラを定義しているパイオニアであるGoogleです。

2008年、Cgroupsのリソース管理とLinux Namespacesのビュー隔離を組み合わせた完全なコンテナ技術であるLinux Container (LXC)がLinuxカーネルに登場しました。LXCは、前述のJailやOpenVZといった初期のLinuxサンドボックス技術と同様の機能をユーザーに提供していますが、Linux OSが商用サーバー市場で急速にシェアを獲得し始めたことで、先行する技術よりもはるかに有利な状況にありました。

2008年以降、AWSやMicrosoftなどの業界大手がパブリッククラウド市場に継続的に取り組み、やがてPaaSと呼ばれる新興産業を育て上げました。

パブリッククラウドやクラウドコンピューティングの後継者たちの影響を受けた多くのテクノロジー企業は、IaaSの上に新しい技術やビジネス価値を開発し、かつてGAEが辿った誤った道を回避する方法を検討し始めています。このような状況の中で、抽象的な「PaaS」の概念を初めて実装・適用するためのオープンソースやプラットフォームレベルのプロジェクト群が登場します。

これらのPaaSプロジェクトは、アプリケーションホスティングサービスとして位置づけられています。GAEのようなパブリッククラウドのホスティングサービスとは異なり、これらのオープンPaaSプロジェクトは、IaaSレイヤーから完全に独立したアプリケーション管理エコシステムを構築することが期待されています。目標は、PaaSが開発者に近いという利点を利用して、クラウド、さらにはすべてのデータセンターへの上位層のエントリーを占有することです。つまり、PaaSプロジェクトは、ユーザーが提出したアプリケーションをカプセル化し、IaaS層の仮想化に依存することなく、基盤となるインフラに迅速にデプロイすることができなければなりません。オープンソースで、中立的で、軽量かつ俊敏なLinuxコンテナは、PaaSを利用してアプリケーションをホストし、デプロイするための最適な選択肢となります。

2009年にSpringSource（Spring Frameworkの創始者）を買収したVMwareは、SpringSource内のJava PaaSプロジェクトの名前を自社の社内PaaSプロジェクトの名前として使用し、その後2011年にオープンソースのプロジェクトとしました。このプロジェクトは「Cloud Foundry」と呼ばれています。2009年に作られたCloud Foundryは、初めてPaaSを明確かつ完全に定義しました。

このプロジェクトは、クラウドコンピューティング業界に多くの重要なコンセプトを初めてもたらし、それも広く認知されています。これらのコンセプトには、「PaaSプロジェクトが実現した、インフラではなくビジネスロジックに焦点を当てた直接的なアプリケーション管理、オーケストレーション、スケジューリング」や「PaaSプロジェクトが実現した、コンテナ技術によるアプリケーションのカプセル化と起動」などがあります。特筆すべきは、Cloud FoundryがWardenを使ってコンテナを起動・運用していることです。Wardenは当初、LXCをカプセル化したもので、後にCgroupsやLinux Namespaceに直接対応するアーキテクチャとして再構築されました。

人気が高まっているこれらのPaaSプロジェクトは、先にGoogleが発表したGAEプロジェクトと同じ目的を持っています。これらのプロジェクトに共通しているのは、開発者は基盤となるインフラ（仮想マシンなど）ではなく、最も価値のあるビジネスロジックに集中すべきだという考え方です。このコンセプトが説得力を持つようになったのは、クラウドの普及により、インフラ管理の複雑さとコストの高さを多くの人が認識するようになってからです。コンテナとアプリケーションの間に対等な関係が築かれ、最終的にはプラットフォーム層のシステムがアプリケーションのライフサイクル管理を完全に実施できるようになります。

このまま進めば、コンテナ技術やクラウドコンピューティングは、PaaSや「アプリケーション中心」の流れに向かって進化していくはずです。これは、Docker社が設立されていなければ、そうなっていたでしょう。

コンテナが ソフトウェア・デリバリー・プロセスを変える

この変化を目撃していなければ、2013年にオープンソースプロジェクトを公開したスタートアップによって、PaaS、さらにはクラウドコンピューティング業界全体が完全に変革されたとは、極めて信じがたいことだと思うかもしれません。しかし、このオープンソースプロジェクトのリリースは、まさに過去5年間のクラウドコンピューティング業界全体の変革の縮図なのです。

DockerプロジェクトのリリースとPaaSとの関係については、詳しく説明する必要はないでしょう。「次元削減攻撃」というコンセプトだけで、もともと業界で行われていた激しい議論に明確な終止符を打つには十分だと思います。

私たちは、Dockerがリリースされたとき、LXCのユーザーに過ぎなかったことを知っています。Dockerがアプリのコンテナを作成して使用するためのロジックは、Wardenのそれと本質的な違いはありません。しかし、本当にPaaSを変えるのは、Dockerプロジェクトの最も強力なキラーであるコンテナイメージであることがわかってきました。

アプリケーションそのものをどのようにカプセル化するかは、開発者にとって関心事ではありません。そのため、PaaSプロジェクトが大きな役割を果たしているのかもしれません。しかし、アプリケーションをどのように定義するかは、各開発者に密接に関係します。この問題を解決するために、Cloud Foundryはアプリケーションの実行ファイル（例えばWARパッケージ）をカプセル化したBuildpackを提供しています。Buildpackには、Cloud Foundryが認識する起動・停止スクリプトや設定情報が組み込まれています。

しかし、Dockerでは、アプリケーションの実行に必要な環境全体（すなわち、OS上のファイルシステム）を、コンテナイメージを使って直接パッケージ化します。このアプローチは、長い間PaaSユーザーを悩ませてきた一貫性の問題を解決します。一度公開すればどこでも動作するDockerイメージを作成することは、統一された開発・テスト環境を実現することすらできないBuildpackを構築するよりもはるかにスマートです。

さらに重要なのは、Dockerはコンテナイメージを作成する際のレイヤーも導入していることです。レイヤー（つまりコミット）に基づいてビルド、プッシュ、アップデートの操作を実装するのは、明らかにGitを参考にしています。このアプローチの利点は、GitHubと同じでもあります。イメージホスティング倉庫であるDocker Hubによって、あなたとあなたのソフトウェアがグローバルなソフトウェア配布に参加できるので、Dockerイメージの構築はもはや退屈でつまらない仕事ではありません。

この時点で、あなたはDockerが実際にはもっと大きな問題をより高い次元で解決していることに気づくかもしれません。ソフトウェアの配信方法が明確かつ完全に定義されていれば、PaaSプラットフォームのようなソフトウェアホスティングプラットフォームを作ることは簡単で容易になります。過去10年間に、Linuxコンテナのような多くの有用な技術が誕生し、改良されていなければ、1つのオープンソースプロジェクトを使ってソフトウェアの提供方法を定義し、統一することは白昼夢だったでしょう。

クラウド、アプリケーション、クラウド・ネイティブ

今日、コンテナイメージは、現代のソフトウェア配信・配布のデファクトスタンダードとなっています。Docker社は「コンテナイメージ」という巧妙なイノベーションにより、「アプリケーション配信」という最も重要な技術的問題を見事に解決しました。開発者と密接な関係にある "アプリケーション "の分野では、複雑性と柔軟性の要求が常に不可欠です。一方、コンテナ技術では、アプリケーションの "マイクロサービス化 "と "単一責任化 "が当然要求されますが、これは大多数の実際の企業ユーザーにとっては非常に困難です。そして、これらのユーザーがクラウドコンピューティング業界の鍵を握っています。

しかし、Dockerシステムの「単一コンテナ」を核としたアプリケーション定義方法と比較して、Kubernetesプロジェクトは、コンテナ化された設計モードとそれに対応する制御モデルの完全なセットを提唱しており、これにより、開発者と真にインタフェースするコンテナを核としたアプリケーション配信・開発パラダイムの構築方法が明確になっています。Docker、Mesosphere、Kubernetesプロジェクトは、いわゆる「オーケストレーションの競争」の核となる「アプリケーション」レイヤーに関する理解とトップレベルの設計が異なります。

2017年末、過去10年にわたって世界最先端のコンテナ化インフラをコンパイルしてきたグーグルの経験は、やがてKubernetesプロジェクトが重要なリーダーシップを獲得することにつながり、「クラウドネイティブ」をキーワードにした組織・エコシステムであるCNCFを頂点に押し上げることになりました。

KubernetesがAPIを多用するプロジェクトであることは承知していますが、同時にKubernetesがAPI中心のプロジェクトであることも理解しておく必要があります。Kubernetesのコンテナデザインパターン、コントローラモデル、そして非常に複雑なapiserverの実装と拡張メカニズムは、この宣言型APIに基づいて初めて意味を成すものです。しかし、これらの一見複雑な設計や実装の背後には、実際にはたった1つの目的があります。それは、ユーザーがアプリケーションを管理する際に、コンテナやクラウドの価値を最大限に高めることです。

この目的のために、Kubernetesはコンテナを組み合わせ、Podの概念を使ってプロセスグループの動作をシミュレートしています。また、Kubernetesが宣言型APIに加えてコントローラモデルを使ってアプリケーションをオーケストレーションし、APIリソースオブジェクトの作成と更新（PATCH）を使ってシステム全体の継続的な運用を推進することにこだわっているのも、この目的のためです。具体的には、Podやコンテナのデザインパターンを用いることで、アプリケーションインフラは（コンテナではなく）アプリケーションと対話したり、アプリケーションに応答したりすることができ、クラウドとアプリケーションの直接的な接続が可能になります。また、宣言型APIにより、アプリケーションインフラは、下位のリソース、スケジューリング、オーケストレーション、ネットワーク、ストレージなど、クラウドの詳細やロジックから真に切り離すことができます。今ではこれらの設計を「クラウドネイティブアプリケーション管理の考え方」と呼び、開発者がビジネスロジックに集中し、クラウドの価値を最大限に引き出すための重要な道筋となっています。

そのため、Kubernetesプロジェクトが取り組んできたのは、「アプリケーションの配信」という恒常的なテーマをさらに明確にすることでした。ただし、Kubernetesプロジェクトが目指しているのは、コンテナやコンテナイメージの配信ではなく、クラウド時代の「アプリケーション」の概念を明確に定義することです。ここでいうアプリケーションとは、コンテナ群を有機的に組み合わせたものであり、アプリケーションの実行に必要なネットワークやストレージの要件の記述も含まれます。このようなアプリケーションを記述したYAMLファイルをEtcdに格納し、コントローラモデルを使ってインフラ全体の状態を駆動し、ユーザーが宣言した状態に常に近づけていきます。これがKubernetesの中核となる動作原理です。

未来:アプリケーション配信の革命は止まらない

ソフトウェア配信がKubernetesとコンテナによって再定義される2019年に戻ってきました。

現時点では、Kubernetesプロジェクトは、アプリケーションの定義、管理、配信を新たな高みへと押し上げる試みを続けています。実際に既存モデルの問題点や欠点、特に宣言型APIがどのようにユーザーエクスペリエンスとより一致するかを見てきました。この問題に関しては、Kubernetesプロジェクトはまだ長い道のりを歩んでいますが、本当に速く前進しています。

また、クラウドコンピューティングのエコシステム全体が、PaaSの「ストーリー」を見直そうとしています。「Google Cloud Next 2019」で公開された「Cloud Run」では、実際にKubernetesやKnativeの標準APIを使って、GAEが生まれ変わることを間接的に宣言しています。もう1つの典型的な例は、より "極端 "に機能を抽象化して、インフラに依存しない環境（FaaS）で完全にホストされるようなアプリケーションが増えていることです。コンテナがアプリケーション環境を完全にカプセル化して開発者にアプリケーションの提供権を返すとすれば、ファンクションはアプリケーションと環境の関係を分離してFaaSプラットフォームにアプリケーションの提供権を渡します。クラウドコンピューティングは、PaaSへの発展の中でDockerに破壊された後、コンテナという全く新しいアイデアでPaaSに収束し始めたことは想像に難くありません。

また、テクノロジーやオープンソースによって、クラウドの境界が急速に平滑化されていることもわかります。ますます多くのソフトウェアやフレームワークが、もはやクラウドに直接バインドするように設計されています。結局のところ、ユーザーのビジネス競争への不安や心配を和らげることはできませんし、世界中のあらゆるクラウドやデータセンターにKubernetesを展開するユーザーが増えていくのを防ぐこともできません。未来のクラウドの世界では、開発者は自分のアプリケーションを世界中のどんな場所にも違いなく届けることになり、それは今のようにコンピュータを部屋のどのジャックにも接続するのと同じくらい自然なことになります。これが、「クラウドネイティブ」について議論する開発者が増えている理由です。

未来を予見することはできませんが、コードとテクノロジーの進化は、未来のソフトウェアがクラウドをベースにしたものでなければならないという事実を教えてくれています。これは、「ソフトウェア・デリバリー」という本質的な問題の絶え間ない自己変革の究極の傾向であり、「クラウドネイティブ」というコンセプトの中核的な前提となるものです。いわゆる「クラウドネイティブ」とは、実際には、アプリケーションがクラウドの機能を最大限に活用し、クラウドの価値を発揮できるような最適な道筋を定義することです。この道筋では、キャリアである「アプリケーション」を抜きにしては、「クラウドネイティブ」は論外です。コンテナ技術は、このコンセプトを実現し、ソフトウェア配信の革命を続けるための重要な手段の一つです。

Kubernetesプロジェクトについては、確かに「クラウドネイティブ」というコンセプト全体を実現するための中核であり、鍵となるものです。しかし、より重要なことは、ソフトウェアに関するこの技術革命において、KubernetesはPaaSの分野に働きかける必要はないということです。クラウドとアプリケーションをつなぐ "ハイウェイ "となり、世界のあらゆる場所に標準的かつ効率的な方法でアプリケーションを迅速に配信することができるようになります。ここでの配信先は、エンドユーザーでもPaaS/サーバーレスでも構わないので、より多様なアプリケーションホスティングのエコシステムを構築することができます。クラウドの価値は、間違いなくアプリケーション自体に還元されます。

一緒にクラウドネイティブアーキテクチャの時代へ

クラウドの流れの中で、多くの企業がビジネスとテクノロジーを「クラウドネイティブ」に進化させ始めています。その過程で最も難しい課題は、アプリケーションやソフトウェアをKubernetesシステムにどのように移行し、配信し、継続的にリリースするかということです。このような技術変化の波の中で、「クラウドネイティブ・アプリケーションデリバリー」は、2019年のクラウドコンピューティング市場で最も注目される技術キーワードの一つとなっています。

2011年以降、アリババはコンテナを活用したクラウドネイティブ技術体系の実践に着手しています。業界全体で参照できる例がないため、Alibabaはコンテナ化されたインフラストラクチャアーキテクチャを徐々に開発しています。これは、世界の一流テクノロジー企業のアーキテクチャに匹敵し、Alibabaグループ全体にサービスを提供します。これらの数万のクラスター管理経験の中で、Alibaba Container Platformチームは、配信をよりインテリジェントで標準化するための4つの方法を調査および要約しました。すべてがKubernetesにあります。K8Sを使用して、K8S自体を含むすべてを管理します。

アプリケーションリリースのロールバックポリシー。アプリケーションは、kubelets自体の公開も含めて、ルールによって段階的に公開されます。環境は画像分割により、模擬環境と本番環境に分けられます。モニタリング側にも十分な工夫をして、Kubernetesの透明性を高め、問題の早期発見・予防・解決につなげます。

先日、Alibaba Cloud Container Platform Teamは、2つのコミュニティプロジェクトを発表しました。Cloud Native App Hub（中国語版のみ）とOpenKruiseです。Cloud-Native App Hubは、すべての開発者のためのKubernetesアプリケーション管理センターであり、OpenKruiseは、世界のトップレベルのインターネットシナリオから設定されたKubernetes自動化オープンソースプロジェクトです。

Cloud-Native App Hubは、国内の開発者向けにHelm Application Domestic Image Siteを提供し、ユーザーがクラウド・ネイティブ・アプリケーションのリソースを入手しやすくします。また、アプリケーションパッケージフォーマットの標準化を推進し、ワンクリックでK8Sクラスターにアプリケーションを配信することで、クラウドネイティブアプリケーションを複数のクラスターに配信するプロセスを大幅に簡素化します。OpenKruise/クルーゼプロジェクトは、大規模なアプリケーションシナリオにおける多くのO&Mのペインポイントを解決する「クラウドネイティブアプリケーションオートメーションエンジン」になることを目指しています。OpenKruiseプロジェクトは、過去数年間のアリババ・エコノミーにおける大規模アプリケーションのデプロイメント、リリース、管理のベストプラクティスから派生しています。OpenKruiseプロジェクトは、Kubernetes上のアプリケーションの自動化に関する問題を、デプロイメント、アップグレード、エラスティックリサイズ、QoS調整、ヘルスチェック、マイグレーション、リペアなど、さまざまな側面から解決します。

次のステップでは、Alibaba Cloud Container Platform Teamもこれをベースに、エコシステム全体と協力して、クラウドネイティブアプリケーションの定義、K8S CRDとOperatorのプログラミングパラダイム、強化されたK8S自動化プラグインなどの一連の標準化を引き続き推進し、クラウドネイティブアプリケーションが大規模なマルチクラスタシナリオで迅速な配信、更新、展開を実現できるようにしていきます。

クラウドネイティブ時代の到来を皆様と一緒に迎えられることを楽しみにしています。

著者について

ZhangはHyperとMicrosoft Research（MSR）に勤務し、現在はKubernetesとそれに関連するアップストリームおよびダウンストリームの研究を行っています。

本ブログは英語版からの翻訳です。オリジナルはこちらからご確認いただけます。一部機械翻訳を使用しております。翻訳の間違いがありましたら、ご指摘いただけると幸いです。

アリババクラウドは日本に２つのデータセンターを有し、世界で60を超えるアベラビリティーゾーンを有するアジア太平洋地域No.1(2019ガートナー)のクラウドインフラ事業者です。
アリババクラウドの詳細は、こちらからご覧ください。
アリババクラウドジャパン公式ページ