2019 年に大人気の 9 つのクラウドネイティブ オープンソース プロジェクト

[[276535]]

コンテナを使用していますか? Cloud Native Computing Foundation のプロジェクトについて詳しく学びましょう。

コンテナを使用してアプリケーションを開発する慣行が普及するにつれて、クラウドネイティブアプリケーションも増加しています。定義によれば:

「クラウド ネイティブ テクノロジーは、コンテナーにカプセル化されたサービスを使用して構築され、マイクロサービスとしてデプロイされ、アジャイル DevOps プロセスと継続的デリバリー ワークフローを通じて柔軟なインフラストラクチャ上で管理されるアプリケーションの開発に使用されます。」

この説明には、クラウド ネイティブ アプリケーションに不可欠な 4 つの要素が含まれます。

1. 容器
2. マイクロサービス
3. デブオプス
4. 継続的インテグレーションと継続的デリバリー (CI/CD)

これらのテクノロジーは非常に異なる歴史を持っていますが、互いに非常にうまく補完し合い、短期間でクラウドネイティブのアプリケーションとツールセットが飛躍的に成長しました。 Cloud Native Computing Foundation (CNCF) のこのインフォグラフィックは、クラウド ネイティブ アプリケーション エコシステムの規模と範囲を示しています。

クラウドネイティブコンピューティング財団プロジェクトマップ

というか、これを見てください！これはほんの始まりに過ぎません。 Node.JS の作成によって JavaScript ツールが爆発的に増加したのと同様に、コンテナ テクノロジの人気によってクラウド ネイティブ アプリケーションが急激に成長し始めました。

幸いなことに、点と点を結び付けて監視する責任を負う組織が複数あります。 1 つは Open Container Initiative (OCI) で、これは Linux Foundation の支援の下で形成された軽量のオープン ガバナンス構造 (またはプロジェクト) です。 OCI の目的は、コンテナ形式とランタイムに関するオープンな業界標準を作成することです。もう 1 つは CNCF です。これは、「クラウド ネイティブ コンピューティングを普及させ、持続可能にすることに専念するオープン ソース ソフトウェア財団」です。

CNCF は、クラウド ネイティブ アプリケーションを中心としたコミュニティの構築全般に加えて、プロジェクトがクラウド ネイティブ アプリケーションを中心に構造化されたガバナンスを確立するのを支援します。 CNCF は、成熟度レベル「サンドボックス」、「インキュベーション」、「グラデュエイト」の概念を作成しました。これは、下の図のイノベーター、アーリーアダプター、アーリーマジョリティの各層に相当します。

CNCF 成熟度モデル

1) サンドボックスステージ

サンドボックスに受け入れられるには、プロジェクトに少なくとも 2 つの TOC スポンサーが必要です。詳細な手順については、CNCF サンドボックス ガイドライン v1.0 を参照してください。

2) 孵化段階

注: インキュベーション レベルは、プロジェクトに対して完全なデューデリジェンスを実行することを目指すポイントです。

インキュベーション段階に入るには、プロジェクトはサンドボックス段階の要件に加えて、以下の要件を満たす必要があります。

• TOCの判断で十分な品質と範囲を持つ、少なくとも3人の独立したエンドユーザーによる生産での成功した使用が文書化されている
• 適切な数のコミッターを用意します。コミッターは、コミット ビットを持つ人、つまりコードの一部または全部を送信することでプロジェクトに貢献できる人として定義されます。
• コードのコミットとマージの連続的な流れを示します
• これらの指標はプロジェクトの種類、範囲、規模によって大きく異なる可能性があるため、これらの基準を満たすのに適切な活動レベルについては TOC が最終決定権を持ちます。

3) 卒業

プロジェクトが「サンドボックス」または「インキュベーション」ステージから「卒業」ステージに到達する場合、または「卒業」ステージに直接入る場合、プロジェクトはインキュベーションステージの基準に加えて、以下の条件を満たす必要があります。

• 少なくとも2つの組織からのコミッターがいる
• コアインフラストラクチャプログラムのベストプラクティスバッジを獲得し、維持している
• 以下の例と同様の範囲と品質の結果が公開された独立したサードパーティのセキュリティ監査を完了しました (https://github.com/envoyproxy/envoy#security-audit にリストされている解決済みの重大な脆弱性を含む)。すべての重大な問題は「卒業」前に解決する必要があります。
• CNCF実装ガイドラインに適応する
• プロジェクトのガバナンスとコミッターのプロセスを明確に定義します。これは、現在のコミッターと引退したコミッターを示すowners.mdファイルを参照して、governance.mdファイルにリストするのが最善です。
• プロジェクトの採用者の公開リストが少なくとも 1 つ (例: Adopters.md またはプロジェクト Web サイトのロゴ)
• TOC の圧倒的多数の投票により、プロジェクトは「卒業」フェーズに入ります。プロジェクトが十分な成熟度を証明できる場合は、サンドボックスから卒業に直接移行することができます。プロジェクトは無期限にインキュベーションに留まる可能性がありますが、通常は 2 年以内に卒業に達することが期待されます。

検討する価値のある9つのプロジェクト

1 つの記事ですべての CNCF プロジェクトを網羅することは不可能ですが、「卒業」段階と「インキュベーション」段階にある 9 つの興味深いオープン ソース プロジェクトを紹介したいと思います。

1. 卒業プロジェクト

「卒業」プロジェクトは多くの組織で成熟しているとみなされ、CNCF ガイドラインに準拠する必要があります。ここでは、非常に人気のある 3 つのオープン ソース CNCF 卒業プロジェクトを紹介します。 (これらの説明の一部は、プロジェクトの Web サイトから改変して再利用されていることに注意してください。)

1. Kubernetes

ああ、Kubernetes。 Kubernetes について言及せずにクラウドネイティブ アプリケーションについて語ることはできるでしょうか? Kubernetes は、Google によって発明されたコンテナベースのアプリケーション向けの非常に有名なコンテナ オーケストレーション プラットフォームであり、オープン ソース ツールでもあります。

コンテナ オーケストレーション プラットフォームとは何ですか?基本的に、スタンドアロン コンテナ エンジンは複数のコンテナを管理できます。ただし、数千のコンテナと数百のサービスについて話す場合、これらのコンテナの管理は非常に複雑になります。ここでコンテナ エンジンが役立ちます。コンテナ オーケストレーション エンジンは、コンテナの展開、管理、ネットワーク、可用性を自動化することで、コンテナの拡張に役立ちます。

Docker Swarm と Mesosphere Marathon は、他の 2 つのコンテナ オーケストレーション エンジンですが、Kubernetes が競争に勝っていると言っても過言ではありません。 Kubernetes は、OKD などの Container-as-a-Service (CaaS) プラットフォームも生み出しました。 RedHat の OpenShift に影響を与えた最初の Kubernetes コミュニティ ディストリビューション。

まず、Kubernetes Github リポジトリを読み、Kubernetes ドキュメント サイトのドキュメント学習リソースにアクセスします。

2. プロメテウス

Prometheus は、2012 年に SoundCloud で構築されたオープンソースのシステム監視およびアラート ツールキットです。それ以来、多くの企業や組織が Prometheus を採用しており、このプロジェクトには非常に活発な開発者とユーザーのコミュニティがあります。現在は独立したオープンソース プロジェクトであり、会社から独立して管理されています。

プロメテウスアーキテクチャ

Prometheus を理解する最も簡単な方法は、1 日 24 時間、1 年 365 日稼働する必要がある実稼働システムを想像することです。完璧なシステムというものはなく、障害を減らす技術（フォールト トレラント システムと呼ばれる）が存在します。ただし、問題が発生した場合には、できるだけ早くその問題を特定することが最も重要です。ここで、Prometheus のような監視ツールが役立ちます。Prometheus は単なるコンテナ監視ツールではなく、クラウドネイティブ アプリケーションを持つ企業の間で人気があります。さらに、Grafana を含む他のオープンソース監視ツールを Prometheus に接続することもできます。

Prometheus を使い始める最良の方法は、GitHub コード リポジトリにアクセスすることです。 Prometheus をローカルで実行するのは簡単ですが、事前にコンテナ エンジンを用意する必要があります。ユーザーは、Prometheus の公式 Web サイトでより詳細なドキュメントを入手できます。

3. 特使

Envoy (または Envoy Proxy) は、オープン ソースのエッジおよびサービス プロキシです。 LyFT によって作成された Envoy は、単一のサービスとアプリケーション向けに設計された C++ で記述された高性能な分散プロキシであり、大規模なマイクロサービス メッシュ アーキテクチャ向けに設計された通信バスとユニバーサル データ プレーンでもあります。 Envoy は、Nginx、HAProxy、ハードウェア ロード バランサ、クラウド ロード バランサなどのソリューションから得た知識に基づいて、各アプリケーションと並行して実行され、プラットフォームに依存しない方法で共通機能を提供することでネットワークを抽象化します。

インフラストラクチャ内のすべてのサービス トラフィックが Envoy メッシュを通過すると、一貫した可観測性を通じて問題領域を観察し、全体的なパフォーマンスを調整し、低レベルの機能を 1 か所に追加することが容易になります。基本的に、Envoy Proxy は、組織が本番環境向けにフォールト トレラント システムを構築するのに役立つサービス メッシュ ツールです。

ServiceMesh アプリケーションには、Uber の Linkerd (後述) や Isito など、多くの代替手段があります。 Istio は、サイドカーとしてデプロイされ、Mixer 構成モデルを活用することで、Envoy Proxy を拡張します。 Envoy の主な特徴は次のとおりです。

• サポートされているすべての機能が含まれています（Istioなどのコントロールプレーンで使用する場合）
• 負荷時のリソース消費が非常に少ない
• 中核的にはL3/L4フィルタリングとして機能し、多くの優れたL7フィルタリングを提供することができます。
• GRPC および HTTP/2 (アップストリーム/ダウンストリーム) をサポート
• API駆動型で、動的構成とホットリロードをサポートします。
• メトリクスの収集、トレース、全体的な可観測性に焦点を当てる

Envoy について詳しく理解し、その機能を活用し、そのメリットを最大限に享受するには、ユーザーは実稼働レベルの環境を実行する豊富な経験を持っている必要があります。ユーザーは、Envoy の GitHub コード リポジトリにアクセスしてドキュメントを読むことで、より詳細な情報を得ることができます。

II. 「インキュベーション」段階のプロジェクト

以下に、非常に人気のある 6 つのオープンソース CNCF インキュベーション プロジェクトを紹介します。

1. rkt

rkt (「ロケット」と発音) は、ポッドネイティブ エンジンです。 Linux 上でコンテナを実行するためのコマンドライン インターフェイス (cli) を備えています。ある意味、Podman、Docker、CRI-O などの他のコンテナに似ています。

rkt はもともと CoreOS (後に Red Hat に買収) によって開発され、詳細なドキュメントは同社の Web サイトで確認でき、ソース コードには Github からアクセスできます。

2. イエガー

Jaeger は、クラウドネイティブ アプリケーション向けのオープンソースのエンドツーエンドの分散トレース システムです。ある意味、これは Prometheus のような監視ソリューションです。しかし、その使用例が以下にまで及ぶ点が異なります。

• 分散トランザクション監視
• パフォーマンスとレイテンシの最適化
• 根本原因分析
• サービス依存性分析
• 分散コンテキスト伝播

Jaeger は Uber が構築したオープンソース テクノロジーです。詳細なドキュメントは Web サイトに、ソース コードは GitHub にあります。

3. リンカード

Envoy Proxy を使用した Lyft と同様に、Uber はサービスを実稼働レベルに維持するために、オープンソース ソリューションとして Linkerd を開発しました。ある意味では、Linkerd は Envoy に似ており、どちらも構成やコードの変更を必要とせずにプラットフォーム全体の可観測性、信頼性、セキュリティを提供するサービス メッシュ ツールです。

ただし、両者の間には微妙な違いがいくつかあります。 Envoy と Linkerd はプロキシとして機能し、接続されたサービスについてレポートできますが、Envoy は Linkerd のような Kubernetes イングレス コントローラーとして設計されていません。 Linkerd の注目すべき機能は次のとおりです。

• 複数のプラットフォーム（Docker、Kubernetes、DC/OS、Amazon ECS、または任意のスタンドアロンマシン）をサポート
• 複数のシステムを統合するための組み込みサービス検出抽象化
• GRPC、HTTP/2、HTTP/1.xリクエストとすべてのTCP通信をサポート

Linkerd の詳細については、同社の Web サイトをご覧ください。また、GitHub でソース コードにアクセスすることもできます。

4. ヘルム

Helm は基本的に Kubernetes 用のパッケージ マネージャーです。 Apache Maven、Maven Nexus、または同様のサービスを使用したことがある場合は、Helm の目的を理解しているでしょう。 Helm は Kubernetes アプリケーションの管理に役立ちます。 「Helm チャート」を使用して、最も複雑な Kubernetes アプリケーションでも定義、インストール、アップグレードできます。 Helm がこれを行う唯一の方法ではありません。もう 1 つの人気の概念は、Red Hat OpenShift 4 で使用される Kubernetes Operators です。

ドキュメント (https://github.com/helm/helm) のクイック スタート ガイドまたは Github ガイドに従って、Helm を試すことができます。

5. その他

Etcd は、分散システムで最も重要なデータを保存するために使用される、分散型の信頼性の高いキー値データ ストアです。主な機能は次のとおりです。

• 明確に定義されたユーザー向け API (gRPC)
• オプションのクライアント証明書認証による自動 TLS
• 速度（1秒あたり10,000回の書き込みに基づく）
• 信頼性（Raft ディストリビューションを使用）

Etcd は、Kubernetes や他の多くのテクノロジーの組み込みのデフォルト データ ストアとして使用されます。つまり、独立して実行されたり、別のサービスとして実行されたりすることはほとんどありません。代わりに、Kubernetes、OKD/OpenShift、またはその他のサービスに統合されたサービスを使用します。ライフサイクルを管理し、API 管理機能のロックを解除する Etcd オペレーターもあります。

詳細については、etcd のドキュメントを参照してください。また、Github でソース コードにアクセスすることもできます。

6. クリオー

CRI-O は、Kubernetes ランタイム インターフェースの Open Container Initiative (OCI) 準拠の実装です。 CRI-O は、次のようなさまざまな機能に使用されます。

• ランタイムはrunc（または任意のOCIランタイム仕様実装）とOCIランタイムツールを使用する。
• コンテナ/イメージを使用したイメージ管理
• コンテナ/ストレージを使用してイメージレイヤーを保存および管理する
• コンテナ ネットワーク インターフェイス (CNI) によるネットワーク サポート

CRI-O は、ガイド、チュートリアル、記事、さらにはポッドキャストを含む広範なドキュメントを提供しており、Github ページ (https://github.com/cri-o/cri-o) も参照できます。

元のリンク:

https://opensource.com/article/19/8/cloud-native-projects

翻訳者紹介:

ArthurGuo さんは職場のベテランです。 21 世紀初頭、私たちはオープンソースを採用し始め、その後プロジェクト管理へと移行しました。彼は現在、クラウドコンピューティング企業でテクニカルディレクターとして働いています。複数のコンピュータ言語を習得しますが、人間の言語の方が得意です。私は言葉遊びは好きですが、皮肉を言うのは好きではありません。