クラウドネイティブテクノロジー初心者向けガイド

クラウド ネイティブ テクノロジーに初めて触れるときは、少し複雑でわかりにくいと感じるかもしれません。しかし、まずはオープンで活気のあるソフトウェア コミュニティである Cloud Native Computing Foundation (CNCF) について学ぶことができます。数え切れないほどのクラウドネイティブテクノロジープロジェクトに継続的なサポートと貢献を提供します。さらに、CNCF にはすべてのクラウド ネイティブ ソリューションを網羅した全体像があり、この図には多くの有名なプロジェクト ソリューションが含まれています。

[[254613]]

私は幸運にも CNCF のアンバサダーとして、カナダでのコミュニティ活動とクラウド ネイティブ教育の推進に取り組んでいます。同時に、CloudOps コミュニティでは、クラウド ネイティブ テクノロジーを普及させ、DevOps チームが関連する技術アプリケーションを実践できるように支援するために、Docker および Kubernetes セミナーも主催しています。

また、Kubernetes やクラウド ネイティブ テクノロジーに関連するカンファレンスも主催し、世界中から講演者を招いてさまざまな技術プロジェクトを発表してもらっています。これらの講演者は、モントリオール、オタワ、トロント、キッチナー・ウォータールー、ケベック・シティでプログラムを実施してきました。メールまたはブログ @archyufaor で連絡を取り合ってください。クラウドネイティブテクノロジーに関する情報コンサルティングを提供します。

クラウド ネイティブ テクノロジーの初心者向けガイドも執筆しました。読者がこの分野を理解し、この分野でより良い進歩を遂げるのに役立つことを願っています。

CNCFの歴史

2014 年に、Google は主にコンテナ オーケストレーションに使用される Borg と呼ばれる社内プロジェクトをオープンソース化しました。プロジェクトを管理する組織がなかったため、Google は Linux Foundation と協力して Cloud Native Computing Foundation (CNCF) を設立し、Kubernetes やその他のクラウド ネイティブ ソリューションの開発とコラボレーションを促進しました。 BorgプロジェクトはKubernetesと改名され、実装部分はGo言語で書き直され、CNCFのスタートアップ寄付プロジェクトとなった。 Kubernetes はまだ始まりに過ぎないことは間違いありません。今後もCNCFには多数の新規プロジェクトが追加され、Kubernetesを中心とした機能が継続的に拡張されます。

CNCFの使命

さまざまなオプションを提供する開発ソフトウェア コミュニティを通じて、エンドユーザーがクラウド ネイティブ アプリケーションを構築できるように支援します。これにより、クラウドネイティブのオープンソース プロジェクトのエコシステムが育成されます。 CNCF はプロジェクト間のコラボレーションを奨励し、CNCF メンバー プロジェクトから完全に進化した成熟したテクノロジ スタックを実現することを目指しています。これがクラウドにおける CNCF の使命です。

CNCFの歴史

現在、合計 25 のプロジェクトが CNCF に承認され、Kubernetes エコシステムの開発が進められています。 CNCF への参加を希望するプロジェクトは、技術監視委員会 (TOC) によって選出され、投票評価に合格する必要があり、過半数の投票を得た場合にのみ参加できます。投票プロセスは、CNCF メンバー企業の代表者である TOC コントリビューターの素晴らしいコミュニティによって促進されており、幸運なことに私もその 1 人です。選考を通過したプロジェクトは CNCF メンバー プロジェクトと呼ばれます。 CNCF は、メンバー プロジェクトを、コードの成熟度に応じて、サンドボックス、インキュベーション、卒業段階として定義します。

サンドボックスステージ

この段階のプロジェクトは非常に初期段階であり、実稼働環境に展開される前に、コードの成熟度を大幅に向上させ、オープンソース コミュニティの交流に積極的に参加する必要があります。プロジェクトが選ばれる主な理由は、コミュニティが持っていない可能性を持っているからです。 CNCF ガイドラインでは、CNCF はサンドボックス プロジェクトの公開を促進し、既存のプロジェクトとの統合を促進すると規定されています。しかし、サンドボックス プロジェクトは CNCF からほとんど資金やマーケティング サポートを受けられず、12 か月ごとにレビューされ、十分に開発されていないプロジェクトは排除される可能性があります。

孵化段階

プロジェクトがサンドボックスのすべての基準を満たし、成長と成熟の明確な特徴を備えている場合、インキュベーション フェーズに入ります。この時点で、少なくとも 3 社の本番環境で使用されており、コミュニティからの新機能やコード要件への対応を含め、コミュニティへの安定した貢献を確保するための安定したチームを備えている必要があります。

卒業

インキュベーション プロジェクトが実稼働使用の重要なポイントに達すると、TOC は投票により、プロジェクトを卒業段階に移行させるかどうかを決定できます。卒業プロジェクトは、高い採用率を示し、すべてのインキュベーション基準を満たす必要があります。プロジェクトには、少なくとも 2 つの異なる組織からのコミッターが参加し、文書化され構造化されたガバナンス プロセスがあり、Linux Foundation Core Infrastructure Program のベスト プラクティス バッジの要件を満たしている必要があります。現時点では、卒業したプロジェクトは Kubernetes と Prometheus の 2 つだけです。

CNCF プロジェクトの紹介

私は CNCF メンバー プロジェクトを、オーケストレーション、アプリケーション開発、監視、ログ記録、トレース、コンテナ レジストリ、ストレージとデータベース、ランタイム、サービス検出、サービス メッシュ、サービス プロキシ、セキュリティ、データとメッセージ フローの 12 のカテゴリに分類しました。提供される情報が、企業や個人が各プロジェクトの機能、進化の過程、他の CNCF プロジェクトとの統合方法を評価する上で役立つことを願っています。

オーケストレーション

クベネフィット

Kubernetes (卒業) - Kubernetes という言葉は古代ギリシャ語で舵取りを意味します。自動化と宣言型構成に重点を置くことで、コンテナ化されたアプリケーションの展開、スケーリング、管理を自動化できます。 Kubernetes は、移植可能でモジュール化されたマイクロサービス パッケージであるコンテナをオーケストレーションします。アプリケーションに抽象化レイヤーを追加し、コンテナをグループ化してポッドで実行することで、コンテナ オーケストレーションを実現します。 Kubernetes は、オペレーターがワークロードをスケジュールし、マルチクラウド環境でコンテナを大規模に展開できるようにするのに役立ちます。 Kubernetesは卒業後も広く利用されています。 CNCF の調査によると、回答した企業の 40% 以上が本番環境で Kubernetes を使用しています。

アプリケーション開発

舵

Helm (Incubator) — Helm は、ユーザーがチャート形式で Kubernetes アプリケーションを簡単に検索、共有、インストール、アップグレードできるようにするパッケージ マネージャーです。 KubeApps Hub を使用して、エンドユーザーが既存のアプリケーション (MySQL、Jenkins、Artifactory など) をデプロイできるように支援します。 KubeApps Hub には、Kubernetes コミュニティによって管理されている安定版およびインキュベーション リポジトリ内のすべてのチャートがリストされます。 Helm を使用すると、ユーザーは Kubernetes 上にすべての CNCF プロジェクトをインストールできます。また、企業は Kubernetes 上でカスタマイズされたアプリケーションやマイクロサービスを作成し、展開することもできます。もちろん、これには YAML マニフェストの作成、さまざまな環境や CI/CD プロセスに応じたさまざまなデプロイメント パラメータのマッチングなどが含まれます。Helm によって作成された単一のチャートは、アプリケーションまたは構成の変更に基づいてバージョン管理され、さまざまな環境にデプロイされ、組織間で共有できます。

Helm プロジェクトは、Kubernetes ユーザー向けのカスタム エクスペリエンスを作成するために Deis プロジェクトから生まれました。 Helm の初期バージョンにはクライアントしかありませんでしたが、後に Deis 氏は Google と協力して、Kubernetes 1.2 と同時にリリースされた Helm V2 にサーバー側の「tiller」を追加しました。これにより、Helm は Kubernetes にアプリケーションをデプロイする標準的な方法になります。

Helm は現在、2018 年末の Helm V3 リリースに向けて一連の変更と更新が行われています。Reddit、Ubisoft、Nike など、日常の CI/CD 開発に Helm を利用している企業には、新しい設計に合わせて最適化することをお勧めします。

テレプレゼンス

Telepresence (サンドボックス ステージ) - プライベート クラウド コンテナー アプリケーション開発には、Docker Compose や Minikube などの一般的なツールがあります。しかし、Kubernetes 上でコンテナ化されたアプリケーションを開発するのは、依然として非常に困難です。現在のクラウドネイティブ アプリケーションのほとんどはリソースを大量に消費し、複数のデータベース、サービス、依存関係を伴うためです。さらに、Docker Compose や Minikube でのメッセージング システムやデータベースなどのクラウド依存関係をエミュレートするのは複雑な問題です。 1 つの解決策としては、完全にリモートの Kubernetes クラスターを使用することですが、これは IDE やデバッガーなどのローカル開発ツールの使用に影響し、開発者が CI による変更のテストを待たなければならない「内部ループ」効果を引き起こします。

Datawire が開発した Telepresence は、上記の概念に対する優れたソリューションを提供します。これにより、開発者は、開発ニーズに合わせて単一のマイクロサービスをローカルで実行しながら、リモート Kubernetes クラスターで実行されているアプリケーションの残りの部分 (「ライブ コード」と呼びます) との接続を維持できます。 Telepresence は、双方向ネットワーク プロキシを含む Pod をリモート Kubernetes クラスターにデプロイします。ローカル マシンをネットワーク プロキシに接続します。これにより、コーディング、デバッグ、編集用のローカル ツールをフリーズすることなく、現実的な開発/テスト環境を展開できるようになります。

モニター

プロメテウス

Prometheus (卒業) - Kubernetes の歴史と同様に、Prometheus は CNCF に参加した 2 番目のプロジェクトであり、卒業した 2 番目のプロジェクトです。動的なクラウドおよびコンテナ環境に適した監視ソリューションです。 Google の Borgman 監視システムにインスピレーションを得ました。 Prometheus は完全にプルベースのシステムであり、いつどのデータをプルするかは構成によって決まります。これは、エージェントを介してデータをプッシュするプッシュ型監視システムとは異なります。 Prometheus は取得したメトリックを TSDB に保存します。ユーザーは PromSOL のようなクエリ言語を使用してデータを抽出し、Grafana ダッシュボードでグラフィカルに表示できます。ユーザーは、組み込みのアラート マネージャーを使用してアラートを生成し、Slack や電子メール経由でさまざまな宛先に送信することもできます。

Prometheus の成功により、クラウド ネイティブ監視の事実上の標準となりました。 Prometheus を使用すると、ユーザーは、特に Kubernetes のような動的システムの場合、どこでも実行されている VM、Kubernetes クラスター、マイクロサービスを監視できます。 Prometheus メトリックは、HPA、VPA、クラスターの自動スケーリングなどの Kubernetes 機能を利用して、自動スケーリングの決定を行うこともできます。 Rook、Vitesse、Envoy、Linkerd、CoreDNS、Fluentd、NATS などの他の CNCF プロジェクトの監視もサポートされています。 Prometheus の出力は、他の多くのアプリケーションや分散システムと統合されます。初心者にはHelm Chartから始めることをお勧めします。

オープンメトリクス

OpenMetrics (サンドボックス) - OpenMetrics は、アプリケーションの外部メトリックの形式に中立的な標準を設定します。この標準により、ユーザーはより広範囲のシステム間でインジケータ データを転送できるようになります。 OpenMetrics は実際には Prometheus のインジケーター形式に基づいており、Borgmon の運用経験を活用しています。 Borgmon は「ホワイト ボックス モニタリング」と低オーバーヘッドの大量データ収集を実装しており、300 を超えるサービス プロバイダーを擁しています。 OpenMetrics 以前は、監視環境は主に、独自のインジケーター形式を使用する SNMP などの比較的時代遅れの標準とテクノロジに基づいていました。インジケーターのフォーマット仕様を気にする人が少なく、システムの違いも多かった。 OpenMetrics の登場後、Prometheus インジケーター形式に基づいて、よりコンパクトで明確かつ厳密な構文が定義されました。システム間の指標の差異の問題が大幅に改善されました。

OpenMetrics はまだサンドボックス段階ですが、AppOptics、Cortex、Datadog、Google、InfluxData、OpenCensus、Prometheus、Sysdig、Uber などの企業によってすでに本番環境で使用されています。

皮質

Cortex (サンドボックス フェーズ) - Prometheus の主な設計目標は、操作の簡素化です。したがって、単一のノードまたは単一のコンテナ内でのみ実行され、使用されるストレージも永続的または長期のストレージ機能を持たないローカル ストレージです。運用がより複雑になるクラスターや分散ストレージを回避する目的は、Prometheus のシンプルさの原則に準拠するためでもあります。 Cortex は、水平方向にスケーラブルで、マルチテナントをサポートし、長期ストレージ デバイスを使用する補助ソリューションです。これは Prometheus への良い追加機能だと考えています。これにより、大企業は高可用性と長期ストレージ デバイスへのアクセスを備えた Prometheus を使用できるようになります。この分野では、現在、Thanos、Timbala、M3DB など、コミュニティの注目を集めている他のプロジェクトもあります。ただし、Cortex は GrafanaLabs と Weaveworks で SaaS 製品として実戦テストされており、EA と StorageOS もオンプレミス プラットフォームに導入しています。

ログ記録とトレース

流暢

Fluentd (インキュベーション) — Fluentd は、統一されたアプローチを使用してアプリケーション ログを収集、解析、および送信します。これにより、ユーザーはログ情報をよりよく理解し、活用できるようになります。この統一されたアプローチでは、ログ データを JSON 形式で定義し、複数のソースと宛先にわたるログの収集、フィルタリング、バッファリング、および出力を実現します。 Fluentd の利点の 1 つは、VM と従来のアプリケーションのログを収集できることですが、その本当の利点は、動的に実行されるマイクロサービスに作用するクラウドネイティブ環境 Kubernetes にあります。

Fluentd は、Kubernetes 上の各 Pod ノードでデーモンセットとして実行されます。コンテナ内のすべてのアプリケーション (CNCF のものを含む) のログを収集するだけでなく、ログを STDOUT に送信します。 Fluentd には、ログ レコードを 1 つずつ解析してバッファリングし、フォーマットされたログを Elasticsearch、Hadoop、Mongo などの設定された送信先に送信する機能があり、ユーザーは後続の処理を実行できます。

Fluentd はもともと Ruby で書かれました。比較的機能的ですが、実行時に 50Mb を超えるメモリが必要になるため、ペアコンテナの展開や操作には明らかに適していません。そこで、Fluentd と同時に開発された Fluentbit が代替ソリューションとなりました。 Fluentbit は C で記述されており、実行時に数 KB のメモリしか必要としません。 CPU とメモリの面ではより効率的ですが、機能は Fluentd よりもはるかに単純で、制限も多くあります。

Fluentd はもともと Treasuredata によるオープンソース開発プロジェクトであり、Kubernetes 用のログ記録プラグインにすぎません。以前のデプロイ可能なバージョンは 0.12 です。これは比較的古いものですが、非常に安定しており、さまざまな本番環境に広くデプロイされています。最近開発された新しいバージョン 1.X には、新しい API の追加、ナノ秒レベルの応答、Windows 環境のサポートなど、多くの改善が含まれています。 Fluentd は徐々にクラウドネイティブ環境でのログ収集の標準になりつつあり、次の CNCF 卒業プロジェクトになる可能性があります。

オープントレーシング

OpenTracing (インキュベーション中) - 開発者はすべてのトランザクションを確認し、マイクロサービスの動作を理解できる必要があります。大規模なマイクロサービスを構築するために分散トレースを使用することの重要性は過小評価できません。ただし、分散トレースは非常に困難であり、既存のサービス、パッケージ、および特定のアプリケーション コードを通じてプロセス内およびプロセス間でトレースのコンテキストを伝播するためのトレース ツールが必要です。 OpenTracing を使用すると、アプリケーション コード、OSS パッケージ、OSS サービスの開発者は、特定のベンダーに縛られることなくコードをインストルメント化できます。個別の API と 9 つの言語で利用可能なライブラリを備えた、アプリケーションおよび OSS パッケージ向けの分散トレース標準を提供します。分散トレースに重点を置いているため、OpenTracing はサービス クラスターや分散システムに最適です。しかし、OpenTracing 自体は、UI でトレースを実行してスパンを分析するトレース システムではありません。これは、アプリケーションのビジネス ロジック、フレームワーク、既存のツールと連携して、スパンを作成、伝播、ラベル付けする API です。バックエンドまたは UI 形式で保存されるトレースを作成します。現在、OpenTracing はオープンソース (Jaeger、Zipkin など) と商用のトレース ソリューション (Instana、Datadog など) を統合しています。

イェーガー

Jaeger (インキュベーション中) — Jaeger は、OpenTracing と互換性があり、もともと Uber によって開発およびテストされたオープンソースの分散トレース ソリューションです。その名前は「yā′gər」と発音され、ハンターを意味します。 Google の内部トレース システム Dapper と Zipkin からインスピレーションを得ました。 Zipkin は、Twitter によって作成され、OpenTracing 標準を使用して構築されたオープン ソースのトレース システムです (ただし、統合サポート機能は制限されています)。 Jaeger は、Zipkin との下位互換性を保ちながら、HTTP 経由で Zipkin 形式のスパンを受け入れます。 Jaeger のユースケース監視およびマイクロサービス ベースのトラブルシューティング機能は、分散コンテキスト伝播、分散トランザクション監視、根本原因分析、サービス依存性分析、パフォーマンスとレイテンシの最適化機能を提供します。 Jaeger のデータ モデルとツールキット ライブラリは OpenTracing と互換性があります。 Web UI は React/Javascript で構築されており、Cassandra、Elasticsearch、メモリなどのバックエンドに対する複数のサポートを提供します。同時に、Jaeger は Istio や Linkerd などのサービス コンポーネントを統合し、トレースの実装を容易にします。

Jaeger はデフォルトで Prometheus メトリックを公開し、ログ転送のために Fluentd と統合しているため、非常に監視しやすくなります。これは、Helm チャートまたは最近開発された Jaeger Operator を介して Kubernetes にデプロイできます。 Uber と RedHat は、Jaeger コード ベースへの貢献の大部分を提供しています。しかし、クラウド環境やマイクロサービスベースの分散トレース向けに Jaeger を調整している企業は数百社あります。

コンテナレジストリ

港

Harbor (サンドボックス フェーズ) - Harbor はもともと、オープン ソース ソリューションとして VMWare によって開発されました。これは、Docker イメージを保存、タグ付け、スキャンするためのオープンソースの信頼できるコンテナ レジストリであり、無料の拡張された Docker レジストリ機能を提供します。ロールベースのアクセス制御 (RBAC) や LDAP 認証サポートなどのセキュリティ機能を備えた Web インターフェイスを提供します。これは、脆弱性スキャン用に CoreOS が開発したオープンソース プロジェクトである Clair と、コンテンツの信頼性のために Notary (後ほど紹介する CNCF インキュベーション プロジェクト) を統合したものです。 Harbor は、アクティビティ監査、Helm チャート管理、Harbor インスタンス間のイメージ レプリケーション (高可用性と災害復旧の目的) を提供します。現在、TrendMicro、Rancher、Pivo​​tal、AXA など多くの企業で使用されています。

ストレージとデータベース

ルーク

Rook (インキュベーション中) — Rook は、Kubernetes 用のオープンソース ストレージ オーケストレーターです。これは、OPS 担当者が Kubernetes 上で Ceph などのソフトウェア分散システム (SDS) を実行するのに役立ちます。開発者はストレージを使用して Kubernetes で永続ボリューム (PV) を動的に作成し、Jenkins や WordPress などのステートフル アプリケーションをデプロイできます。

Ceph は、従来のハードウェア上で実行され、オブジェクト ストレージ、ブロック ストレージ、ファイル システムなどのさまざまな主流のストレージ サービスを提供する、人気の高いオープン ソース SDS です。ユーザーは、Ceph クラスターをハードウェア上に直接デプロイし、CSI プラグインを使用して Kubernetes に接続できます。ただし、そうすると、OPS 担当者が Ceph クラスターを展開して運用する難易度が間違いなく上がり、作業の課題が増え、Ceph クラスターの人気は低下します。 Rook は、カスタム リソース定義 (CRD) を使用して Ceph を Kubernetes のクラス オブジェクトとしてデプロイし、運用フレームワークを使用してそれを自己管理型、自己スケーリング型、自己修復型のストレージ サービスに変換します。これは、人間の運用知識をソフトウェアにエンコードし、簡単にパッケージ化してエンドユーザーと共有できるようにするという Kubernetes 運用の​​概念とまったく同じです。

Helm が Kubernetes アプリケーションのパッケージ化とデプロイに重点を置いているのに対し、Rook Operator は複雑な SDS アプリケーション ライフサイクルをデプロイおよび管理できます。 Ceph を例にとると、Rook オペレーターは、展開、ブートストラップ、構成、パフォーマンス仕様、水平スケーリング、修復、アップグレード、バックアップ、災害復旧、監視などのストレージ管理者の作業を自動化できます。

オリジナルの Rook Operator は Ceph のみをサポートしていました。バージョン 0.8 では、Ceph のサポートがベータ版に達し、その後、ストレージ ベンダー向けの Rook フレームワークがリリースされました。このフレームワークは、Rook を汎用のクラウドネイティブ ストレージ オーケストレーターに拡張しました。再利用可能な仕様、ロジック、ポリシー、テストをサポートする複数のストレージ ソリューションを備えています。現在、Rook はアルファ版で CockroachDB、Minio、NFS をサポートしており、将来的には Cassandra、Nexenta、Alluxio もサポートする予定です。ますます多くの企業が、CENGN、Gini、RPR などのプレミアム プラットフォームを中心に、Ceph の Rook Operator を本番環境で使用しており、多くの企業が評価段階にあります。

ヴィテス

Vitess (Incubator) — Vitess はデータベース ミドルウェアです。一般的なシャーディング テクノロジを使用して、MySQL インスタンス間でデータを分散します。水平スケーラビリティを実現し、アプリケーションに影響を与えることなく水平方向に拡張できます。ユーザーのシャードが最大容量に達すると、Vitess はダウンタイムなしで優れた観測性を維持しながら、基盤となるデータベースを再シャードして拡張できます。 Vitess はトランザクション データに関連する多くの問題も解決しており、プロジェクトは順調に成長しています。

ティクヴ

TiKV (サンドボックス) — TiKV は、簡素化されたスケジュール機能と自動バランス調整機能を備えたトランザクション キー値データベースです。分散ストレージ層として機能し、強力なデータ一貫性、分散トランザクション管理、水平スケーラビリティを提供します。 TiKV の設計は Google Spanner と HBase にヒントを得ていますが、分散ファイルシステムがないことが利点です。 TiKV は PingCAP によって開発され、現在は Samsung、Tencent Cloud、UCloud からの貢献者がいます。

コンテナランタイム

R

RKT (インキュベーター) - RKT (ロケットと発音) は、もともと Docker の代替として CoreOS によって開発されたアプリケーション コンテナーです。当時、Docker は Kubernetes のデフォルト コンテナになりましたが、kubelet からの圧力に直面し、Kubernetes コミュニティと Docker コミュニティの間には相互連携の面で相違がありました。 Docker を開発した Docker Inc. は独自の製品ロードマップを持ち、Docker にいくつかの複雑な機能を追加しています。たとえば、Docker のクラスター モードを追加し、ファイル システムを AUFS から overlay2 に変更します。ただし、この作業中に情報が公開されなかったため、これらの変更は Kubernetes コミュニティと Kubernetes ロードマップの計画およびリリース日に影響を及ぼします。さらに、Kubernetes ユーザーが使用する必要があるのは、コンテナの起動と停止の機能、スケーリング、アップグレードなどの機能を備えたシンプルなコンテナだけです。そのため、CoreOS は RKT を Kubernetes 専用に構築された Docker の代替品として開発する予定です。しかし驚くべきことに、この動きは、Kubernetes SIG-Node チームが Kubernetes 用のコンテナ インターフェイス (CRI) を開発するきっかけとなり、これによりあらゆる種類のコンテナを接続し、コア コードから Docker コードを削除できるようになりました。 RKT は OCI イメージと Docker イメージの両方を使用できます。 RKT は Kubernetes エコシステムにプラスの影響を与えましたが、エンドユーザー、特に Docker CLI に慣れていてアプリケーションをパッケージ化する別の方法を学びたくない開発者には受け入れられませんでした。さらに、Kubernetes の人気により、多くのコンテナ ソリューションがこの市場セグメントで競合しています。たとえば、Gvisor と OCI ベースの cri-o はますます人気が高まっていますが、RKT は時代遅れのようで、CNCF インキュベーターから削除されるプロジェクトになる可能性があります。

コンテナ

Containerd (インキュベーション) - Containerd は、シンプルさ、堅牢性、移植性を重視したコンテナです。 RKT と同様に、OCI および Docker イメージ形式をサポートしていますが、Containerd は開発者やエンドユーザーに直接提供されるのではなく、より大規模なシステムに組み込むように設計されている点が異なります。 Containerd も Docker から CNCF に寄贈されたプロジェクトです。初期の頃、Docker は高度に統合されたアプリケーションでしたが、時間の経過とともに、クラスター モードなどの機能が追加されたため、複雑で管理が困難なアプリケーションになりました。さらに、シンプルなコンテナ機能を必要とする Kubernetes ユーザーにとって、Docker の複雑な機能は多少冗長です。そのため、Kubernetes はデフォルトの Docker コンテナを置き換えるために、RKT を含む代替手段を探し始めました。この時点で、Docker プロジェクトは疎結合のコンポーネントに分割し、よりモジュール化されたアーキテクチャを採用することを決定しました。これは Moby プロジェクトであり、Containerd はこのプロジェクトの中核機能です。分割された Containerd は CRI インターフェースを介して Kubernetes に統合され、ri-Containerd に名前が変更されました。ただし、Kubernetes 1.10 以降では、組み込みの CRI プラグインを介して統合を実現するために Containerd がデフォルトで使用され、追加の grpc ジャンプが排除されます。

cri-o や Gvisor などの OCI ベースのプロジェクトの人気が高まるにつれて、Containerd はコミュニティから徐々に無視されるようになっています。ただし、これは依然として Docker プラットフォームの不可欠な部分であり、Kubernetes エコシステム内に位置付けられています。

サービス検出

コアDNS

CoreDNS (インキュベーション中) — CoreDNS は、クラウドネイティブ展開でサービス検出を提供する DNS サーバーです。バージョン 1.12 以降、Kubernetes は CoreDNS をデフォルトのクラスター DNS サーバーとして使用しています。以前は、SkyDNS は Kubernetes クラスターの DNS コンポーネントであり、それ自体が Caddy とその後の KubeDNS のブランチでした。 SkyDNS は DNS に基づく動的サービス検出ソリューションですが、そのアーキテクチャは柔軟性に欠けており、新しい機能を追加したり拡張したりすることが困難です。そこで Kubernetes は KubeDNS に切り替えました。しかし、KubeDNS は実行時に 3 つのコンテナ (Kube-dns、Dnsmasq、Sidecar) で実行されるため、Dnsmasq の脆弱性の影響を受けやすく、新機能の拡張においても SkyDNS と同様の問題を抱えています。この時点で、CoreDNS は Go 言語で完全に書き直され、プラグインに基づく柔軟でスケーラブルな DNS ソリューションになりました。さらに、Kubernetes では、運用中に起動するコンテナは 1 つだけなので、脆弱性の問題もありません。提供されている ConfigMap ツールは、構成を動的に更新できます。さらに、CoreDNS は、厳密な設計 (Pod レコードの検証など) を通じて、KubeDNS に存在する多くの問題を修正します。プラグインベースのアーキテクチャにより、ユーザーはプラグインを通じていつでも機能を追加または削除できます。現在、CoreDNS には 30 を超える独自プラグインと 20 を超える外部プラグインが含まれています。プラグインを連鎖させることで、ユーザーは Prometheus モニタリング、Jaeger ログ追跡、Fluentd ロギング、Kubernetes API または etcd 構成、その他の高度な DNS 機能と統合機能を有効にすることができます。

サービスメッシュ

リンカード

Linkerd (インキュベーター) — Linkerd は、サービス メッシュ デプロイメント用のオープン ソース ネットワーク プロキシ サービスです。サービス メッシュは、アプリケーション内のサービス間通信を管理、制御、監視する独立したレイヤーです。 Linkerd は、アプリケーション コードを変更することなく、プログラム可能なループ ブレーキ、レート制限、タイムアウト、再試行構成を通じてアプリケーションのフォールト トレランスを向上させることで、開発者が大規模なマイクロサービスを実行できるようにします。 Zipkin はマイクロサービスの視覚化を提供します。また、カナリア、ステージング、ブルーグリーンのデプロイメントをサポートする高度なトラフィック制御機器も提供します。 SecOps チームは、Kubernetes クラスター内の TLS を介してすべてのノード間通信を透過的に暗号化する Linkerd の機能の恩恵を受けます。 Linkerd は、実稼働環境で広く使用されており、サービス ネットワークを検討している多くの企業の関心を集めている Twitter の Finagle プロジェクトをベースに開発されました。現在、Linkerd は Kubernetes、DC/OS、AWS/ECS で使用できます。 DaemonSet として Kubernetes にデプロイされると、クラスター内の各ノードが Linkerd Pod を実行することも意味します。

サービス メッシュ エコシステムでは最近、Kubernetes と緊密に統合された Istio プロジェクトの導入や、マイクロサービスと並行して実行される軽量プロキシである Envoy の出現など、新たな変化が起こっています。これらのサービス メッシュ コンポーネントは Linkerd よりも多くの機能を提供するため、Linkerd の人気は大幅に低下し、Linkerd の存在価値を疑問視する声さえ出ています。コミュニティの関心を再び集め、多数の既存顧客をサポートするために、Linkerd を所有する企業である Buoyant は、DaemonSets が Istio をサイドカー プロキシとして使用できるようにし、データプレーンを書き直し、コントロール プレーンを Go で書き直した Conduit というプロジェクトを発表しました。これらの変更により、多くの機能にサイドカー アプローチを使用できるようになります。少し前に、Conduit プロジェクトは Linkerd 2.0 に名前が変更され、GA がリリースされました。これは、Linkerd が本番環境で使用できる状態にあることを示しています。サービス メッシュは依然として急速に進化しており、Istio や Linkerd 2 などのプロジェクトがその中心となります。

サービスエージェント

特使

Envoy (インキュベーター) — Envoy は、クラウドネイティブ アプリケーション向けに設計されたエッジ ノードおよびサービス プロキシです。これは C++ で書かれた CNCF インキュベーション プロジェクトです。これは、Lyft で開発され、実戦テストされた、ベンダーに依存しない高性能な軽量アプリケーション プロキシ サービスです。 Envoy は、既存のアプリケーション コードを変更することなく、タイムアウト、セキュリティ、再試行、ループバック ブレーキなどのフォールト トレランス機能を備えたマイクロサービスを提供します。 Prometheus、Fluentd、Jaeger、Kiali との統合により、マイクロサービス間のイベントを自動的に可視化します。 Envoy には、トラフィック ルーティングとトラフィック分散、および負荷分散フェイルオーバーのドメイン認識を実行する機能も備わっているため、エッジ プロキシ (Kubernetes L7 Ingress コントローラーなど) としても機能します。

サービス プロキシの分野にはすでに多くのオプション プロジェクトがありますが、Envoy はサービス メッシュと最新の負荷分散に関する多くの関心と革新的なアイデアを刺激し、既存のエコシステムをうまく補完します。 Envoy のデプロイメントには、Heptio が発表した Contour プロジェクトが関係しており、このプロジェクトでは Envoy プロキシをリバース プロキシおよびロード バランサとしてデプロイし、Kubernetes のイングレス コントローラとして機能します。 Contour は、動的な構成の更新とマルチチームの Kubernetes クラスターをサポートし、仮想ホストと TLS 証明書を構成できる名前空間を制限し、高度な負荷分散戦略を提供します。 Envoy を中核とするもう 1 つのプロジェクトは、強力な Kubernetes ネイティブ API ゲートウェイである Datawire Ambassador です。 Envoy は C++ で書かれており、非常に軽量であるため、Kubernetes 内でサイドカー モードで実行するのに最適であり、API 駆動型の構成更新スタイルとの調整にも最適であり、データプレーン サービス メッシュに最適な候補となります。さらに、サービス メッシュ Istio は、Envoy がデータプレーンのデフォルトのサービス プロキシであることを発表しました。 Envoy プロキシは、サイドカー モードで Kubernetes の各インスタンスにデプロイされます。 Istio のコントロール プレーン構成によって管理される透過的なサービス メッシュを作成します。このアプローチは、各サービスへの可視性と、Kubernetes やハイブリッド クラウド シナリオでも各サービスに安全な TLS を作成する機能を提供した Linkerd v1 で使用されていた DaemonSet パターンとはまったく対照的です。最近、Hashicorp は、オープンソース プロジェクト Consul Connect でもマイクロサービス間の TLS 接続を確立するために Envoy を使用すると発表しました。

現在、Envoy は、ベンダーや商用プロジェクトの支援なしに、大規模で活発なオープンソース コミュニティを構築しています。 Envoy を試してみたい場合は、Istio、Ambassador、Contour も試してみることをお勧めします。 2018年12月10日、シアトルで、KubeconのEnvoyコミュニティは第1特使を首尾よくホストしました。誰もがコミュニティに参加できます。

安全性

ファルコ

Falco（Sandbox Phase） - Falcoは、Sysdigが開発したオープンソースのリアルタイムセキュリティツールであり、Kubernetesオーケストレーションシステムの異常な活動と侵入を検出するように設計されています。ユーザースペースに存在し、sysdigカーネルモジュールを使用してシステムコールアクティビティを取得します。 Falcoには、SecCompやApparmorなどの執行ツールよりも多くの監査機能があります。

Falcoは、注意を必要とする行動とイベントを定義する、事前に設定された一連のルールを使用します。次に、daemonetとしてkubernetesで走ります。これらのルールに基づいて、FALCOはLinuxシステムを呼び出す動作を検出し、これらの動作のアラートを追加できます。同様の動作は、コンテナ内のシェルでスクリプトを実行すること、またはアウトバウンドネットワーク接続を行うバイナリから生じる可能性があります。これらのイベントは、fluentdによってstderrでキャプチャし、フィルタリングまたはクリアアラートのためにElasticsearchに送信できます。これにより、ユーザーはコンテナの破壊や損害などのセキュリティインシデントに迅速に対応し、そのような事件によって引き起こされる経済的損失を減らすことができます。

FalcoはCNCF Sandboxステージに含まれているため、公式のヘルムチャートをFalcoに統合するなど、将来、より多くのCNCFプロジェクトと深く統合されることを願っています。

スピッフ

Spiffe（Sandbox Stage） - アプリケーションの負荷間で相互信頼を確立することは複雑な問題であり、弾力性のスケーリングと負荷の動的スケジューリングにより、この問題はより困難で危険になります。しかし、Spiffeはこの問題に対するクラウドネイティブの解決策です。 Spiffeは、ポリシー駆動型のAPI駆動型で完全に自動化されたセキュリティ製品識別フレームワークを提供します。 IDを確認することにより、アプリケーションペイロード間の通信を可能にします。 Spiffはまだ比較的新しいものであり、主にSpireプロジェクトと緊密に連携するように設計されています。

尖塔

Spire（Sandbox Phase） - Spireは、クラウドプロバイダーとミドルウェアレイヤーに統合できるソフトウェアコンポーネントのセットであるSpiffeのランタイム環境です。 Spireはモジュラーアーキテクチャを採用し、複数のプラットフォームをサポートします。現在、SpiffeとSpireの周りのコミュニティは非常に急速に成長しています。 Hashicorpは、VaultのSpiffe IDのサポートを発表したばかりで、重要な情報と定期的なローテーションに利用できるようにしました。 SpiffeとSpireの両方が現在CNCFサンドボックスステージにあります。

tuf

TUF（インキュベーションフェーズ） - TUFは「更新フレームワーク」の略語です。これは、信頼できるコンテンツ配信のフレームワークです。 Content Trustの問題は、重要なセキュリティの問題です。 TUFは、ソフトウェアの出所を確認し、ソフトウェアの新しいバージョンのみが使用されるようにすることにより、コンテンツトラストを提供することにより、この問題を改善します。 TUFプロジェクトは、以下に説明する公証人プロジェクトで非常に重要な多くの役割を果たしています。また、Docker、DigitalOcean、Flynn、CloudFlare、VMwareなど、生産環境で内部ツールと製品を構築するために多くの企業が使用しています。

公証人

公証（インキュベーション） - 公証人は安全なソフトウェア分布の実装です。本質的に、抽出されたすべてのDocker画像が署名され、正しいか、アンペアのない画像バージョンに署名されるようにするためのTUFに基づいています。公証人は、CI/CDワークフローのすべての段階で使用でき、KubernetesのDockerベースの展開における主要なセキュリティ問題を解決できます。公証人は、信頼できるコンテンツのコレクションを公開および管理します。 DevOpsエンジニアは、公開された信頼できるデータを承認し、署名付きコレクションを作成することができます。これは、Linux Systemsのソフトウェアライブラリの管理ツールに似ていますが、Docker画像管理にのみ使用されます。公証人の主な目標には、ミラーバージョンが最新であることを確認すること（常に脆弱性を回避するための新しいコンテンツがある）、およびオブジェクト間の委任を信頼することが含まれます。たとえば、ユーザー間の信頼されていない画像と送信チャネルの信頼できる配布。 TUFと公証人は通常、エンドユーザーが直接使用していませんが、そのソリューションは、ハーバー、Docker Enterprise Registry、Quay Enterprise、Aquaなど、信頼できる配布のためのコンテンツ署名または画像署名のためのさまざまな商用製品またはオープンソースプロジェクトに統合されています。このスペースのもう1つの興味深いオープンソースプロジェクトは、オープンソースメタデータAPIであるGrafeasです。保存された「証明」または画像署名は、いくつかの承認コントロールのチェックサムとして使用でき、コンテナ分析APIおよびGCPのバイナリ認証にも使用できます。 JFrogとAquasecと同様の機能を備えています。

オパ

Open Policy Agent（Sandbox Phase） - Open Policy Agent（OPA）は、必須の宣言的アプローチを使用してポリシーを指定し、さまざまな種類のポリシーをテクノロジースタックに配布し、再コンパイルまたは再配置せずに自動的に更新できるようにします。アプリケーションおよびプラットフォームレイヤーで、OPAはサービスからクエリを送信することにより、ポリシーの決定を通知します。 Docker、Kubernetes、ISTIO、その他のアプリケーションとの統合効果が良好です。

データフローとメッセージフロー

ナット

NATS（インキュベーションフェーズ） - NATSは、インフラストラクチャが分散システム間でメッセージを送信および受信できるミドルウェア中心のメッセージングサービスです。クラスタリングおよび自動修理技術は非常に利用可能であり、ログベースのデータフローにより、履歴データ参照メッセージの配信とすべての情報の受信が保証されます。 NATSには、従来のメッセージング、マイクロサービス送信、コントロールプレーン、クラウド内のサービス発見などのメッセージングなど、さまざまな技術的ユースケースをサポートする比較的単純なAPIがあります。上記のロギング、監視、追跡ソリューションとは異なり、NATSはアプリケーションレイヤーで動作します。

GRPC

GRPC（インキュベーションフェーズ）-GRPCは、複数のプラットフォームでライブラリ、クライアント、サーバー間で通信する機能を提供する高性能RPCフレームワークです。あらゆる環境で実行し、EnvoyやNginxなどのエージェントをサポートできます。 GRPCは、効率的な接続サービスを有効にするために、負荷分散、追跡、健康チェック、および認証のためのプラグ可能なサポートを提供します。デバイス、アプリケーション、およびブラウザを接続して、サービスをバックエンドします。 GRPCは、メッセージングを容易にするアプリケーション層ツールです。

CloudEvents

CloudEvents（Sandbox Stage） - CloudEventsは、マルチクラウド環境で発生するイベントを説明する一般的な方法を開発者に提供します。 CloudEventsは、イベントデータを説明する仕様を提供することにより、サービスとプラットフォーム全体のイベント宣言と配信を簡素化します。このプロジェクトはまだサンドボックスステージにあり、アプリケーションの携帯性と効率を大幅に改善する必要があります。

フォローアップの見通し

クラウドネイティブエコシステムは急速に成長しています。近い将来、より多くのプロジェクトがサンドボックスフェーズに含まれ、コミュニティの関心と意識を獲得する機会を与えます。 Vitess、Nats、Rookなどのインフラに関連するプロジェクトが、CNCFの注目とサポートを引き続き受け取ることを願っています。それらはクラウドネイティブの展開の重要なイネーブラーであるためです。同時に、連続したクラウドネイティブ配信のフィールドはまだ比較的空白であり、CNCFが引き続き注意を払うことができることを願っています。

CNCFは常に新しいプロジェクトを統合しており、成熟したプロジェクトが卒業できるようにしています。しかし、コミュニティの注目の喪失により、価値のない、または他のプロジェクトに置き換えられないプロジェクトを削除するための実用的なメカニズムを持つことも同様に重要です。プロジェクトの提出プロセスは誰にでも公開されていますが、TOC委員会が引き続き優れた候補者のみに資金を提供し、CNCFをプロジェクト間でよく組織化された多様なエコシステムにすることを願っています。

CNCFの大使として、私はこれらのテクノロジーの使用方法を人々に教えたいと思います。 CloudOpsでは、DockerとKubernetesのワークショップをリードして、Cloud-Native Technologiesを促進し、DevOpsチームがアプリケーションを練習できるよう支援しています。また、Kubernetesとクラウドネイティブテクノロジーに関連する会議を開催し、世界中のスピーカーを招待して、さまざまな種類のテクノロジープロジェクトを紹介しました。スピーカーは、モントリオール、オタワ、トロント、キッチナーウォータールー、ケベック市などの場所でプロジェクトを運転しています。また、みんながCloudNativeconに参加することをお勧めします。