Open Standards: Anchoring Extensibility for Cloud-Native Tooling

CloudNative Days Tokyo 2021 Day2が開幕しました。本日のキーノート枠(12:40–13:00)では、CNCF Ecosystem AdvocateであるKatie Gamanji氏から、クラウドネイティブの普及を支えた、オープン技術の標準化(Open Standards)についてお話いただきます。
https://event.cloudnativedays.jp/cndt2021/talks/1305

日本語の字幕を用意するのが難しく、Mediumで同氏のセッションの書き起こしと日本語翻訳をご用意しました。セッション拝聴のお供に、また後からから見返すためにもお使いください！

（なお、本書き起こしと翻訳は非公式なものとなります。正確な内容を保証するものではなく、あくまでセッション視聴の参考とお考えください）

翻訳：Yoshiki Fujiwara @antiberial, Kohei Ota @_inductor_
編集：Masato Nabeshima @nabemasat

Open Standards: Anchoring Extensibility for Cloud-Native Tooling

Katie Gamanji

Ecosystem Advocate CNCF

Self introduction

Hello, everyone. My name is Katie Gamanji and currently I am the ecosystem advocate at CNCF. I have joined this role quite recently and my responsibilities are to lead the end user community, while making sure to close the gap between the practitioners of cloud native and the projects within the ecosystem. As well as Currently I am one of the members of the advisory board for Keptn which is a CNCF Sandbox project. I’m working with OpenUK and Udacity to ensure that open standards are used fairly and they’re actually created across data, hardware and software.

自己紹介

みなさん、こんにちは。私の名前はKatie Gamanjiです。現在CNCFで、Ecosystem Advocateを務めています。最近CNCFに参画し、クラウドネイティブの実践者とエコシステム内のプロジェクトとの橋渡しを行いながら、エンドユーザーコミュニティの育成を担っています。また、CNCFのSandboxプロジェクトであるKeptnのアドバイザリー・ボードにも所属しています。私はOpenUKとUdacityと協力して、データ、ハードウェア、ソフトウェアを横断して、オープン・スタンダードの策定と、その公正な使用を保証する役割を担っています。

End User Community

I have mentioned the end user community and I’d like to give a brief introduction of what it actually represents. The end user community is composed of more than 140 vendor neutral organizations across different industries and sectors. These organizations are using cloud native technologies to build and distribute their services. They are not selling cloud native technology. This is quite an important distinction.

エンドユーザーコミュニティ

それでは、エンドユーザーコミュニティとは何を代表しているのでしょうか。エンドユーザーコミュニティは、さまざまな業界やセクターにわたる、140を超えるベンダー中立の組織で構成されています。これらの組織は、サービス開発と提供に、クラウドネイティブ技術を利用しています。彼らはクラウドネイティブ技術そのものを販売しているわけではありません。これが非常に重要な特徴です。

End User driven open source

It is the largest End User open source community and it stands at the CNCF center of end user driven open source.

That means that we’re looking towards this organization to define the production experience and growth of cloud native technologies. Pretty much these users and these organizations are the ones who adopt technologies in their production systems. And based on their feedback, we’ll be able to grow organically the ecosystem.

If you’d like to find out more about the End user community, how can you showcase a usage of cloud native tools as an end users, please visit the CNC f.io/enduser. We’re going to have more information on how you can join and be part of this community.

エンドユーザー主導のオープンソース

我々のコミュニティはエンドユーザー向けのオープンソースコミュニティとしては世界最大規模であり、CNCFにおけるエンドユーザー主導のオープンソース活動の中心に位置付けられています。

つまり、私たちがこの組織に注目しているのは、クラウドネイティブ技術における本番運用の経験と成長を見定めるためであるということです。これらのユーザーと組織のほとんどは、本番システムに技術を採用している組織です。そして、私たちがエコシステムを有機的に成長させることができるのは、彼らのフィードバックがあるからです。

エンドユーザーコミュニティの詳細を知りたい場合や、エンドユーザーとしてクラウドネイティブツールの使い方を紹介したい場合は、cncf.io/enduser をご覧ください。このコミュニティに参加する方法について、さらに詳しい情報を得られます。

Open Standrds

Today however, I would like to talk about open standards and more specifically, how these are anchoring extensibility within the cloud native ecosystem. And to do so I’d like to start by talking about continued globalization. In this session I’m going to focus on

open container initiative, Docker and how these pretty much help to have a wide adoption for containers across the industry.

Next I’d like to focus on standards in interfaces and this is more around the Kubernetes ecosystem, and how these particular initiatives help communities to grow and develop this cloud native landscape.

In this particular section, I’m going to talk about the container runtime interface, container network interface storage service mesh interfaces and the cloud provider interfaces, as well. I’m going to briefly talk about the observability stack, and the open standards across metrics and traceability and I’m going to talk about the open standards within the application delivery, talking about KubeVela and Crossplane. And lastly, I’d like to conclude on the impact of the open standards and interfaces hand in hand on the vendors community and the end users.

オープン・スタンダード

本日はひとまず、オープン・スタンダードが、クラウドネイティブ・エコシステムにおける拡張性をどのように支えているかについて具体的にお話ししたいと思います。そのために、まずはコンテナ普及のための努力の継続についてお話しします。このセッションでは、Open Container Initiative (OCI)、Docker、およびこれらが業界全体でコンテナが広く採用される上でどう貢献してきたかについて焦点を当てます。

次に、インターフェースの標準化に焦点を当てたいと思います。これは、Kubernetesエコシステムに関するものであり、これらの取り組みが、コミュニティによるクラウドネイティブ・ランドスケープの成長と発展にどのように貢献するかに関するお話しです。このセクションでは、Container Runtime Interface (CRI)、Container Network Interface (CNI)、Container Storage Interface (CSI)、Service Mesh Interface (SMI)、およびCloud Provider Interface (CPI)についても説明します。オブザーバビリティスタック、およびメトリックとトレーサビリティ全体のオープン・スタンダードについて簡単に説明し、アプリケーションデリバリーにおけるオープン・スタンダード、特にKubeVelaやCrossplaneについてお話します。そして最後に、オープン・スタンダードとインターフェースがベンダーコミュニティとエンドユーザーに与える影響についてまとめたいと思います。

Container Orchestrators

If you look back seven years ago, the container orchestrator framework space was very heavily diversified. We had tools such as Docker Swarm, Apache Mesos, CoreOS fleet, Kubernetes, and all of them provided a viable solution to run containers at scale. However, Kubernetes nowadays is known for its ability to define how to run containerized workloads. Kubernetes is known for its portability and adaptability, but more importantly, for its approach towards declarative configuration and automation. And this has been extremely beneficial for Kubernetes and we can even see two numbers based on the CNCF survey in 2020. More than 83% of the companies are using Kubernetes within a production system. When it transitioned to the rest of the development community, more than 2500 engineers are actively collaborating towards feature build out and bug fixing. On the look into the end user community or the practitioner community, more than 41K attendees were registered in the KubeCon around the world last year, now this encapsulates KubeCon Europe and North America.

コンテナオーケストレーター

7年前を振り返れば、数多くのコンテナ・オーケストレーションのフレームワークが存在し、混沌としていました。Docker Swarm、Apache Mesos、CoreOS fleet、Kubernetesなどのツールがあり、それらすべてがコンテナを大規模に実行するための実行可能なソリューションを提供しました。しかし今や、コンテナワークロードの実行方法を定義する機能は、Kuberenetesの代名詞として知られています。加えてKuberenetesの特徴として知られているのは、その移植性や適応性、さらに重要なのは宣言型の構成管理と自動化へのアプローチです。これらの特徴は、Kubernetesの普及にとって有利に働きました。2020年にCNCFが行った調査で、2つの数字が明らかになりました。具体的には、CNCF参加企業の83％以上が、Kubernetesを本番システム内で使用しています。残りの開発コミュニティに目を向けると2500人のエンジニアが、機能の構築とバグ修正に向けて積極的に協力しています。エンドユーザーや技術者のコミュニティを調べると、昨年、世界中で（ヨーロッパと北米で開催された合計）41,000人以上の参加者がKubeConに参加登録していました。

Cloud Native Landscape

And this flourishing community around Kubernetes pretty much focused on extending its functionalities. And this created what today we know as the cloud native landscape which resides under the CNCF umbrella or Cloud Native Computing Foundation.

クラウドネイティブ・ランドスケープ

コミュニティはKubernetesの周辺で盛んに活動しながら、その機能を拡張することに力を注いできました。これにより、CNCF傘下またはCloud Native Computing Foundationの下に存在する、今日クラウドネイティブ・ランドスケープとして知られているものが作られました。

Container Globalization

However, the community around Kubernetes was not always as flourishing, but more importantly, it was not always as engaging the victory the beginning was quite different. Nowadays, Kubernetes is known for its adaptability and flexibility to run containerized workloads with predefined technical requirements. It will provision the ecosystem for application execution, while shrinking its footprint in the cluster. However, to reach the state of the art multiple challenges regarding socializing, such as the globalization of the containers.

コンテナ活用の広まり

ただし、Kubernetesを取り巻くコミュニティが常に活発だったわけではありません。それどころか、初期は現状のように市場を勝ち取った状態とはまったく異なるものでした。現在、Kubernetesは、技術要件を事前に定義して、コンテナワークロードを柔軟に、さまざまな状況に適応して実行する能力で知られています。クラスタ内のフットプリントを削減しながら、アプリケーション実行用のエコシステムを用意します。これらの特徴は、コンテナが広く受け入れられる過程で生じた、最先端の複数の課題に対応するためのものです。

Container primitives

To run it effectively, and successfully, the container required two main primitives, the cgroups and the Namespaces. The cgroups are used to impose limits into what resources the process can use, and this refers to CPU and memory. The Namespaces on the other side make sure to control what a process can see. This includes either other processes mounts, network interfaces and so forth.

Or these two primitives have been within the Linux kernel since 2008. And there is a natural question which emerges. “Why containers became popular only in the recent years?“

コンテナ・プリミティブ

コンテナを効果的かつ正常に実行するには、2つの主要なプリミティブとして、cgroupとnamespaceが必要でした。cgroupは、プロセスが使用できるリソースに制限を課すために使用されます。このリソースとはCPUとメモリを指します。一方namespaceは、実行されるプロセスが閲覧できる領域を確実に制御します。これには、他のプロセスにおけるマウントの状態やネットワークインターフェイスなどが含まれます。

さて、これら2つのプリミティブは2008年からLinuxカーネル内にあります。当然、こんな疑問が浮かぶのではないでしょうか。「なぜコンテナはここ数年で突然人気になったのか？」

Technology became the competitive edge

The answer to this is that technology became quickly the competitive edge for any business out there.

And they had to find solutions to the application complexity, fast deployments and environment uniformity. Application complexity refers to the fact that we have a service oriented architecture composed of multiple micro services that construct one bigger application. While this introduces simplicity and uniformity, standardization, it is still a challenge and how can we deploy and keep all of these components up to date within the production system. As well as deployment is an imperative nowadays, the faster you deploy new features, the more of a competitive offering you have for your customers.

And the other challenge was environment uniformity. How can the differences or the delta between the development environment and the production environment can be reduced or completely eliminated?

テクノロジーが競争力の源泉に

これに対する答えは、テクノロジーが急速にあらゆるビジネスにおける競争力の源泉になったということです。

また、アプリケーションの複雑さ、迅速なデプロイメント、環境の均一性に対するソリューションを見つける必要がありました。この「アプリケーションの複雑さ」とは、1つの大きなアプリケーションを構築するために、複数のマイクロサービスで構成されるサービス指向アーキテクチャを指します。これにより、各サービスにはシンプルさと均一性、標準化がもたらされますが、それでも課題は生じます。これらすべてのコンポーネントを本番システム内でデプロイして、常に最新の状態に保つにはどうすればよいでしょうか。今日ではデプロイメントが不可欠であるだけでなく、新機能のデプロイが速ければ速いほど、顧客にとって魅力的な要素が増えます。

そしてもう1つの課題は、環境の均一性でした。開発環境と本番環境の違いや差異をどのように減らすか、あるいは完全になくすことができるでしょうか。

Container Globalization

And to solve all of these challenges, Docker actually was introduced and had a wide adoption within the community. Docker pretty much packages and executes an application in an environment which is loosely isolated called container. With Docker there, of course, by default are a couple of advantages. The first one, there is an application environment defined as code. Within the Dockerfile, we’ll be able to specify how the application can be executed, but more importantly, we’ll be able to pre-define all of the dependencies and these are going to be consistent across all environments. As well, Docker simplified the testing process. That means that you have a reproducible environment between your development, staging and production, and you can have more confidence in what exactly is going to be deployed to every single cluster or every single environment at the time. And of course, we’re going to have frictionless deployment. As long as you have the Docker engine running within the environment, you’ll be able to deploy your application with minimal effort.

コンテナ活用の広まり

これらすべての課題を解決するために、Dockerが導入され、コミュニティ内で広く採用されました。Dockerは、コンテナと呼ばれる疎結合な環境でアプリケーションをパッケージ化して実行します。もちろん、Dockerを使用すると、デフォルトでいくつかの利点があります。1つ目は、アプリケーション環境をコードとして定義できることです。Dockerfile内でアプリケーションの実行方法を指定できます。さらに重要なのは、すべての依存関係を事前に定義でき、これらがすべての環境で一貫していることです。また、Dockerはテストプロセスを簡素化しました。つまり、開発、ステージング、本番の間に再現可能な環境を用意し、その時点でそれぞれのクラスタや環境に何がデプロイされるかを明確にすることができます。そしてもちろん、滞りのないデプロイメントを実現します。環境内でDockerエンジンを実行している限り、最小限の労力でアプリケーションをデプロイできます。

Open Container Initiative(OCI)

However, the introduction of Docker pretty much made sure that containers are widely adopted across the industry. But there was not only Docker, we can see that multiple initiatives at the time were to diversify the ecosystem of runtime images and registries and it was clear that it was necessary to have a set of standards to make sure that all of these container solutions are compatible with each other. And this prompted pretty much for the open container Initiative, or OCI, to be introduced. The open container Initiative is a governance model which focuses on the industry standards across container formats and runtimes. It was established by Docker in June 2015 and other industry leaders and it mainly focuses on three main core principles composability, decentralization and minimalisms. Composability pretty much focused on the fact that every single container should be run independently, but at the same time should be portable and executed securely. Decentralization focuses on the fact that every single container should run similarly on different platforms in different environments. And when talking about minimalism is the fact that that one container, or each application within the container should run a simple process that can be easily applied to different processes or be experimented upon.

Open Container Initiative(OCI)

Dockerの導入により、コンテナが業界全体で広く採用されるようになりました。しかし、当時はDockerだけでなく、複数の取り組みによってランタイムイメージとレジストリのエコシステムが乱立しており、これらすべてのコンテナソリューションが互換性を持つ必要があるのは誰の目から見ても明らかでした。その結果、Open Container Initiative (OCI)の設立が促されました。OCIは、コンテナ規格とランタイム全体の業界標準に焦点を当てたガバナンスモデルです。2015年6月にDockerなど業界をリードする企業によって設立され、主に3つの主要なコア原則である構成可能性、分散化、およびミニマリズムに焦点を当てています。コンポーザビリティは、それぞれのコンテナを独立して実行する必要があると同時に、ポータブルで安全に実行できる必要があるという事実に焦点を当てています。分散化は、それぞれのコンテナが、異なる環境の異なるプラットフォームの下で、同じように動作する必要があるという事実に焦点を当てています。そして、ミニマリズムとはあるコンテナ、またはそのコンテナ内の各アプリケーションは、単純なプロセスを実行し、さまざまなプロセスに簡単に適用したり、実験したりできる必要があるという事実です。

OCI Specifications

And when you’re talking about the OCI Specifications, there are four of them from which two of them are mostly widely known and used. We have the image and the runtime specification, distribution and artifacts. The image specifications pretty much defined how an image for a container should be constructed. It will contain the image index, layers, configuration files and file systems and so forth. Runtime on the other side is a specification which goes into how to initialize and execute a container. Distribution focuses on how these images can actually be distributed and it’s going to be focused on the construction of registries. Pretty much it will look into operations, how to pull and push an image, how to list tags, delete an image and so forth. And artifacts is another specification which focuses on how to distribute artifacts which are not container file system bundles.

OCI仕様

OCI仕様には4つの種類があり、主にそのうちの2つが広く知られ使われています。具体的には、イメージとランタイムの仕様、及び配布とアーティファクトです。イメージ仕様は、コンテナのイメージを構築する方法を定義しています。これには、イメージインデックス、レイヤー、構成ファイル、ファイルシステムなどが含まれます。一方ランタイムは、コンテナを初期化して実行する方法に関する仕様です。配布は、これらのイメージを実際に配布する方法に焦点を当てており、レジストリの構築にも及びます。操作、イメージのプルとプッシュの方法、タグの一覧表示、イメージの削除などについて検討しています。また、アーティファクトは、これらとは別に、コンテナファイルシステムにバンドルされていないものを配布する方法に焦点を当てた仕様です。

Standards and Interfaces

Now at this stage, we can see the open container initiative pretty much introduces standardization and when it comes to the adoption of containers on an industry level. However, at the same time had Kubernetes emerge within the ecosystem and it slowly but surely gain adoption from the community. And it was clear that it is necessary to introduce a set of standards within the Kubernetes ecosystem as well.

The first notable one was the runtime component, the runtime particle is pretty much the one which intercepts any requests from the kubelet and makes sure that the containers are created on the node with the right specification. And this functionality is at the beginning were provisioned by Docker and rkt. One of the challenges with these two runtimes is the fact that they were logically very deeply ingrained in the Kubernetes source code. And this imposed quite a few challenges. The first one was a low rate for feature development. If you’d like to introduce some new features for these runtimes the release process is tightly coupled with the Kubernetes release process, which in itself is quite lengthy.

Another challenge is of course for new runtimes. If you’d like to create a new runtime, pretty much introduce it for Kubernetes because the developers will require a very in depth knowledge of the Kubernetes source code. It was clearly said a runtime interface was necessary to pretty much abstract the integration of runtime capabilities. But more importantly, was that we’re already using the OCI or open container initiative standards.

スタンダードとインターフェース

この段階で分かることは、産業レベルでのコンテナの採用に当たって、OCIが標準化を推し進めたことです。一方で同時期にエコシステム内に登場したKubernetesは、ゆっくりと、しかし確実にコミュニティに普及していきました。もちろん、Kubernetesエコシステム内にも一連の標準を導入する必要があることは明らかでした。

最初に注目されたのはランタイムコンポーネントでした。ランタイムは、kubeletからの要求を受信・中継し、コンテナが正しい仕様でノード上に作成されることを保証するものです。そして、この機能は当初、Dockerとrktによって用意されていました。これら2つのランタイムは、Kubernetesソースコードに論理的に非常に深く根付いていました。そして、これは数多くの課題をもたらしました。1つ目の課題は、機能開発が低迷したことです。これらのランタイムにいくつかの新機能を導入しようとしても、リリースプロセスが、それ自体が非常に長いKubernetesリリースプロセスと密結合になっていました。

もう一つの課題は、おわかりの方もいらっしゃると思いますが、新しいランタイムの追加です。Kubernetes用に新しいランタイムを作成したい場合は、開発者がKubernetesソースコードに精通している必要があるため、学習コストが高くつきました。ランタイム機能の統合を抽象化するには、ランタイム用のインターフェイスが必要であることは明らかでした。しかし、ここで重要になってくるのが、我々がすでにOCI標準を利用していることです。

CRI

As such, the CRI container runtime interface provides an abstraction layer over the integration of container runtimes from which Docker and rkt would be just some of them.

And when you look currently into the ecosystem, there are a plethora of tools provisioning these capabilities from which we have tools such as Kata Containers, CRI-O, gVisor, containerd, AWS firecracker and many more. Containerd here, it currently is a coordinated CNCF project, and is known for its ability to provision this runtime capabilities as an industry standard. CRI-O as well is a lightweight version of a runtime. And, of course, it’s known for his compliance with open container initiative standards. As well it’s only natural to make sure that the containers can be created on any infrastructure. And this means to enable the cloud providers to use their own APIs and libraries to create containers on their infrastructure. As such, Google come up with their own runtime provider which is going to be called gVisor. And there is another one which comes from AWS, for example, which is going to be an AWS firecracker.

CRI

OCIが既に利用されていることから、CRI (Container Runtime Interface)はコンテナランタイムをKubernetesに組み込むために必要な抽象化レイヤーを提供します。その結果Dockerとrktは複数あるランタイムのうちの一つでしかなくなりました

現在のエコシステムを覗き込むと、Kata Containers、CRI-O、gVisor、containerd、AWS firecrackerなど、ランタイムをプロビジョニングするツールが多数あることがわかります。その中でもcontainerdはCNCFプロジェクトの1つであり、ランタイム機能のプロビジョニングにおけるを業界標準として知られています。またCRI-Oは、軽量バージョンのランタイムです。そしてもちろん、OCI標準に準拠していることでも知られ、当然コンテナをどんな種類のインフラストラクチャ上でも作成できることを保証します。これは、クラウドプロバイダーが独自のAPIとライブラリを使用して、インフラストラクチャ上にコンテナを作成できるようにすることを意味します。そのため、GoogleはgVisorと呼ばれる独自のランタイムプロバイダーを考案しました。たとえば、AWS Firecrackerのように、AWSに由来する別のランタイムもあります。

CNI

As well during the same time when the runtime interface was introduced, there are a lot of initiatives to democratize the networking tooling around Kubernetes as well. And this prompted for the container network interface to be prompted, which focuses mainly on the connectivity of containers within a cluster or within a distributed amount of machines. As well, here we have a lot of tools for diversification of tooling, from which we have calico, flannel, NSX from VMware, Open vSwitch, cilium and many more. Flannel has reported a lot of success from the end user community and is known for its simplicity to provision that network overlay for clusters. Calico in addition to provisioning the network hopefully, it will come with a Network Policy Enforcer, which ensures that we have fine grained access control to the services within the cluster. And cilium has gained a lot of momentum as well. And it’s because it allows this transparency of networking packets and the networking and application level.

The runtime in network interfaces were extremely important because they made the adoption of containers with Kubernetes more feasible, and from now on the community concern so more and more with how to extend Kubernetes rather than choose and use very specific tooling, and this can be confirmed by the appearance of other interfaces around storage, service mesh and cloud provider.

CNI

ランタイムインターフェイスが導入されたのと同じ時期に、Kubernetes周辺のネットワーキングツールを民主化するための多くの取り組みが行われました。その結果生まれたのが、Container Network Interface (CNI)です。これは、主にクラスタおよび複数のマシンに分散したコンテナの接続性に焦点を当てています。手法の多様化により、Calico、Flannel、VMware NSX、Open vSwitch、Ciliumなど多くのツールが登場しました。Flannelは、エンドユーザーコミュニティに多くの成功をもたらしており、クラスタにネットワークオーバーレイを簡単に用意できることで知られています。Calicoには、ネットワークのプロビジョニングに加えて、ネットワーク・ポリシー・エンフォーサーが付属します。これにより、クラスタ内のサービスへのきめ細かいアクセス制御が保証されます。そしてCiliumも勢いを増しています。ネットワーキングパケットとネットワーキングおよびアプリケーションレベルで透過性を実現するからです。

ネットワークインターフェースのランタイムは、Kubernetesによるコンテナの採用を現実的にする上で、非常に重要でした。以降、コミュニティは、特定のツールではなく、Kubernetesを拡張する方法にますます関心を寄せています。このことは、ストレージ、サービスメッシュ、クラウドプロバイダー周辺の他のインターフェースの出現によって明らかです。

CSI

The CSI or container storage interface was introduced in communities 1.9 And it moved to general availability in 1.14. Pretty much this interface focuses on how the services within the cluster can consume storage outside of the cluster.

And here we have again many tools provisioning these capabilities. And it’s actually one of the most developed areas within the cloud native landscape because more than 60 providers are actively collaborating and integrating with CSI from which you have Rook, ceph, OpenEBS and many more. Deserve to mention here the Rook have graduated from the CNCF project. And it’s known for simplicity to dynamically allocate storage for an application.

CSI

Container Storage Interface (CSI)は1.9でコミュニティに導入され、1.14で一般提供が開始されました。このインターフェイスは、クラスタ内のサービスがクラスタ外のストレージをどのように利用するかに主な焦点を当てています。

そしてここでも、数多くのツールがこれらの機能を提供しています。実際、60を超えるストレージプロバイダーがRook、Ceph、OpenEBSなどのCSIと積極的に協力し一体となって活動しており、クラウドネイティブ・ランドスケープ内で最も開発が盛んな領域の1つです。ここで言及しておくべきことは、RookがCNCFプロジェクトにおいてGraduatedになったことです。Rookはアプリケーションへのストレージの動的な割り当てが簡単なことで知られています。

SMI

As well as there were a lot of initiatives to democratize the introduction of the service mesh within a cluster and this prompted the service mesh interface to be about. Currently, the SMI integrates with tools such as Istio, Linkerd, Consul, Open Service Mesh and many more. It is opt to mention here that Linkerd is an incubated CNCF project and is known for its simplicity, to provision the service mesh capabilities for a cluster.

SMI

また、クラスタ内でのサービスメッシュの導入を民主化するために多く取り組みが行われた結果、Service Mesh Interface (SMI)が登場しました。現在、SMIは、Istio、Linkerd、Consul、Open ServiceMeshなどのツールと統合されています。ここでLinkerdに言及しておきたいと思います。LinkerdはIncubatedなCNCFプロジェクトであり、クラスタにサービスメッシュ機能をシンプルに提供できることで知られています。

CPI

And the last interface I’d like to talk about is the cloud provider, which is heavily used by cluster API. Now the perspective of interfaces has completely changed in this case.

Because when I talked about the runtime network storage service mesh interfaces all of this resides within the cluster. However, with a cloud provider interface, this takes the idea of standards further step. It defines how the Kubernetes cluster can be created across different cloud providers using the same standards or the same matter. And currently, this container provider interface integrates with tools such as GCP, AWS, vSphere, from VMware, Azure and many more.

CPI

そして、私が取り上げたい最後のインターフェースは、クラウドプロバイダーです。これはクラスタAPIによって頻繁に使用されます。このケースでは、インターフェースについての考え方が完全に変わることになりました。なぜなら、これまで触れてきたランタイム、ネットワーク、ストレージ、サービスメッシュのインターフェイスはすべてクラスタ内に限定されていたからです。ところが、CPIを使用すると、標準化の考え方がさらに一歩前進します。CPIでは、統一のインターフェースおよび要素を用いて、異なるクラウドプロバイダー間でKubernetesクラスタを作成・管理する方法を定義します。そして現在、CPIはVMware、Azure、GCP、AWS、vSphereなどのツールと統合されています。

Observability Stack

Now, there are a lot of initiatives as well to introduce open standards when it comes to the observability stack. When talking about observability usually it encapsulates how we can simplify the instrumentation, while at the same time lowering the cost for data aggregation, but introducing standards to the format’s and frameworks with visibility across the stack.

Pretty much this is going to be focused on how we collect data points from our application to ensure that we have the transparency of what happens within the systems. And this is translated by collecting metrics, events, logs and traces. Metrics are locals to collect but they’re the most efficient to diagnose and verify or to define actually, the state of application. Events are collected from the application to provide these data, data points or historical data points of when exactly an action happened within the system. However, events are supposed to be high abstraction level, just to indicate that something ever has happened or something went wrong. For an actual debugging process logs are necessary which present high fidelity data and the engineering team will be able to recreate step by step, what exactly are the functions called within the system. And traces are necessary especially nowadays in a service oriented architecture, where to solve one request or to serve one request at the time it’s necessary to trace or to invoke multiple micro services. Now with these traces, we’ll be able to put all of these journeys together and we’ll be able to recreate the full end to end path of what exactly the end user experience. When we’re looking into the ecosystem, we have Open Metrics which pretty much focuses on how we can introduce standards into consuming metrics at scale. However, we are looking into the logs tracing and metrics as well, we had OpenTracing and OpenCensus. However, these merged in 2018 with OpenTelemetry. OpenTelemtry, now is focused on how we can identify, gather, collect traces, logs, metrics around an application to make sure that we can have an indicator of the performance and the behaviors of the system.

オブザーバビリティスタック

今、オブザーバビリティスタックについても、オープン・スタンダードを導入するための多くの取り組みが行われています。オブザーバビリティは、一般的にパフォーマンス計測の単純化や、同時にデータ集約のコスト削減について語られることが多いですが、スタック全体にわたって、フォーマットとフレームワークを標準化し、可視性をもたらすことも含まれます。

これは、アプリケーションからデータポイントを収集する方法に焦点を当て、システム内で発生するイベントの透明性を確保します。そして、これは、メトリック、イベント、ログ、およびトレースを収集することによって解釈されます。メトリックは収集できる情報としては局所的ですが、実際のところ、アプリケーションの状態を診断、検証、定義する上で最も効率的な要素です。イベントはアプリケーションから収集され、システム内でアクションが発生したまさにその時のデータ、データポイント、または履歴データポイントを提供します。ただし、イベントは高い抽象化レベルが想定され、何かが起こったことや何かがうまくいかなかったことだけを示すことになります。実際のデバッグプロセスでは、再現性の高いデータを示すログが必要であり、その結果、エンジニアリングチームは、システム内で呼び出される関数を正確に、一歩一歩再現することができます。また、トレースは、特に最近のサービス指向アーキテクチャで必要性が高まっています。サービス指向アーキテクチャでは、1つのリクエストを解決するか、複数のマイクロサービスをトレースまたは呼び出す必要があるときに1つのリクエストを処理します。これらをトレースすることで、これらすべての過程をまとめ、エンドユーザー体験の完全なE2Eの経路を再現することができます。オブザーバビリティのエコシステムの中には、大規模なメトリクスの標準化に主な焦点を当てているOpen Metricsがあります。また一方で、ログのトレースとメトリックに関しても、OpenTracingとOpenCensusがありました。ただし、これらは2018年にOpenTelemetryと統合されました。OpenTelemtryは現在、アプリケーションに関するトレース、ログ、メトリックを識別、収集、収集して、システムのパフォーマンスと動作の指標を確実に取得する方法に焦点を当てています。

Application Deployment

And in addition to a third observability stack, there areinitiatives to introduce standards within the application delivery. Now this pretty much focuses on how an application can be deployed, but at the same time, how can we increase the overall developer experience. And these initiatives have been crowned by tools such as KubeVela and crossplane. KubeVela has been introduced or actually it was revealed at KubeCon North America in 2020, by the open application model community, and it focuses on how you can abstract the deployment of an application completely from an end user perspective. That means that if, as a developer you’d like to deploy using KubeVela you don’t need to be aware of the resources behind Kubernetes such as Deployment, Services, Ingress and so forth. You will just be able to provision a configuration file, just specifying what functionalities, what variables you’d like for your application. And this is going to pretty much deploy your application in the background. As well, Crossplane has gained a lot of momentum from the community lately. And it is because it extends it can bring this API that makes it possible to deploy an application on any platform by using the power of Operators and Custom Resource Definitions.

アプリケーションのデプロイメント

そして、3番目のオブザーバビリティスタックに加えて、アプリケーションデリバリーにスタンダードを導入する取り組みがあります。これは、アプリケーションのデプロイ方法に焦点を当てていますが、同時に、全体的な開発者体験の向上も目指しています。そして、これらの取り組みは、KubeVelaやCrossplaneなどのツールによって支えられています。KubeVelaは、Open Application Model (OAM)のコミュニティによって2020年にKubeCon North Americaで紹介されました。このツールは、エンドユーザーの観点からアプリケーションのデプロイを完全に抽象化する方法に焦点を当てています。つまり、開発者がKubeVelaを使用してデプロイする場合、Deployment、Service、Ingressなど、Kubernetesの背後にあるリソースを意識する必要はありません。アプリケーションに必要な機能、可変要素を指定するだけで、構成ファイルをプロビジョニングできるようになります。そして、これにより、アプリケーションがバックグラウンドでデプロイされます。同様に、Crossplaneは最近コミュニティから大きな支持を得ています。その理由として、APIを拡張することで、Operatorとカスタムリソース定義の機能を使用して任意のプラットフォームにアプリケーションをデプロイできるようになることが挙げられます。

Cloud Native Ecosystem

So we have seen a lot of initiatives to introduce these open standards and interfaces amongst the cloud native ecosystem. And as a result, that means that the cloud native ecosystem transmogrified its identity multiple times.

クラウドネイティブ・エコシステム

ここまで、クラウドネイティブ・エコシステムにこれらのオープン・スタンダードとインターフェースを導入するための多くの取り組みを見てきました。その結果として、クラウドネイティブ・エコシステムがそのアイデンティティを何度も変容させてきたことがわかります。

Non-opinionated

And this role has been possible because Kubernetes overall is not opinionated. Of course, it’s going to be opinionated when it comes to the networking model, for example. As it dictates that every single container should have an IP address, it is not going to be assertive when it comes to the underlying amount of tooling that you’re going to run Kubernetes on top of what kind of plugins you can introduce to ensure a functional cluster.

寛容なコミュニティ

このような動きは、Kubernetes全体として、意見に寛容であることから可能になっています。もちろん、たとえばネットワーキングモデルに関しては人によって意見が分かれるでしょう。Kubernetesで要求するのは「すべてのコンテナにIPアドレスを持つこと」ですから、それを実現するためにご自身の環境でどのようなツール・プラグインを使用して実稼働するクラスタを構成するかに関しては、仕様として断定されることはありません。

The Perspective

And these had a huge impact when you look into the perspective had a huge impact on the vendors and users and the community. When you’re looking into the vendor community, the introduction of open standards and interfaces means innovation, as a vendor doesn’t have to concern how to integrate your services within Kubernetes. Usually these standards, the interface is already going to be there. As such as a vendor you can focus on how to deliver customer value with minimal latency. When you’re looking into the end user community, the emergence of open standards and interfaces means extensibility. It was never as easy as it is today to benchmark different tools with the same capability. As an end user you have the leverage to further empower or create focus on your product and choose the right tool for your problem. And we’re looking into the community. The emergence of interfaces and open standards means interoperability, because we’ve created this canvas of different tooling where multiple solutions for the same problem are actually embraced.

展望

こうした姿勢が、ベンダー、ユーザー、およびコミュニティに大きな影響を与えました。ベンダーコミュニティにとってオープン・スタンダードとインターフェースの導入はイノベーションをもたらします。なぜなら、作成したサービスをKubernetesに統合するための方法を気にしなくて良いからです。標準的なインターフェイスがすでに存在するので、ベンダーは顧客への価値提供の遅れを最小限に留めることに集中できます。エンドユーザーコミュニティにとっては、オープン・スタンダードとインターフェイスの出現は拡張性をもたらします。同じ機能を持つさまざまなツールを比較検討することが、今ほど簡単な時代はありません。エンドユーザーは、製品にさらに力を与えたり、焦点を合わせたりして、問題解決に最適なツールを選択することができます。そしてコミュニティにとっては、インターフェースとオープン・スタンダードの出現は相互運用性を意味します。なぜなら、さまざまなツールが存在し、同じ問題に対する複数のソリューションが歓迎されるキャンバスを、私たちが作り出したからです。

Cloud Native Landscape

And this has been extremely beneficial for Kubernetes because over time, multiple tools for building value to extend its functionalities and this created but today, we know as the cloud native landscape.

クラウドネイティブ・ランドスケープ

そして、これはKubernetesにとって非常に有利でした。なぜなら、時が経つにつれ、価値を生み出し、機能を拡張するための複数のツールが生み出されたからです。それは今日では、クラウドネイティブ・ランドスケープとして知られています。

Emergence of Open Standards

And this has been possible because the open standards and interfaces are the central engine for innovation that anchors extensibility but more importantly, it’s an ecosystem. that embraces contrasting solutions for the same problem.

オープン・スタンダードの出現

そしてこれが可能になったのは、オープン・スタンダードとインターフェースが、拡張性を支えるイノベーションの中心的なエンジンだからです。さらに重要なのは、それが同じ問題への対照的なソリューションを包括するエコシステムであるということです。

Reach out!!

If you’d like to find out more about (the struggle?), please visit my medium account. I’m going to have an article written about this plug in a bit more details. We’re going to find more resources. And if you have any more questions, I’m going to be of course available on social media such as Twitter or LinkedIn.

Enjoy the rest of the conference. Thank you.

ご連絡ください!!

より詳細な内容をお知りになりたい場合は、私のmediumアカウントをご覧ください。今後、より詳細な記事を書いていく予定です。今後、ますます資料を用意していく予定です。疑問点ありましたら、TwitterやLinkedInなどのソーシャルメディアでお気軽に連絡ください。

引き続き、カンファレンスをお楽しみください。ご静聴ありがとうございます。