2021 年に注目すべき 5 つのオープンソース Kubernetes プロジェクト

オープンソース プロジェクトにより、Kubernetes はさらに強力になります。 Java、可観測性、継続的インテグレーション (CI)/継続的デリバリー (CD) パイプラインなどに関連する問題を解決する有望なオープン ソース プロジェクトについて学びます。

[[358648]]

Kubernetes はそれ自体で IT 組織に多くの価値をもたらし、開発者にとって興味深いものから、本番環境で大規模に展開できるものへと変化しています。 Cloud Native Computing Foundation (CNCF) による 2019 年の調査では、クラウド コンピューティング コミュニティにおける Kubernetes の使用率が 2018 年の 58% から 2019 年には 78% に増加したことがわかりました。この価値の大部分は、Kubernetes コミュニティに参加している個人や組織の努力によるものです。

しかし、これは、Kubernetes と連携して動作し、Kubernetes をさらに強力にする補完的な機能を備えたオープンソース ツールを作成する個人や組織の取り組みも反映しています。以下では、開発者とオペレーターにとって特に興味深いコンテンツをいくつか紹介します。

1. クオークス

Java は最も人気のあるプログラミング言語の 1 つであり、1990 年代半ばに作成されました。ほぼ 20 年間、初期のサービス指向アーキテクチャ (SOA) アプローチにもかかわらず、(仮想化された) ホスト CPU とメモリの単独所有権を前提とする動的アプリケーションの実行に主に最適化されてきました。エンタープライズ アプリケーションはこのように記述されます。

大規模なアプリケーションはまだ存在していますが (「モノリシック モノリス」が依然として最善のアプローチである場合もあります)、組織は生産性、柔軟性、効率性の観点から、マイクロサービス、リアクティブ性、Function as a Service (FaaS)、12 要素の原則、クラウド ネイティブ アプリケーションをサポートする世界へと移行しています。このような環境で Java を最適に使用する方法を再考する必要があります。

2. オープンテレメトリー

EMA アナリストの Torsten Volk 氏は、最近の Kubecon でのホットな話題の 1 つは可観測性だったと指摘しました。可観測性という用語は多くの領域をカバーしますが、一般的な定義ではメトリック、トレース、およびログ記録がカバーされます。この分野における 2 つの大規模プロジェクトは、時系列データ モデルに基づいて構築されたシステム監視およびアラート ツールキットである Prometheus と、分散トレース ツールである Jaeger です。監視も重要ですが、観測可能性とは異なると考えられることが多いです。

OpenTelemetry は、この分野で最も新しいサービスであり、2019 年に Google の OpenCensus と Lightstep の OpenTracing が統合されて誕生しました。

プロジェクト自体とは別に、OpenTelemetry が興味深い理由の 1 つは、分散システムの可観測性領域において少なくとも何らかの統一性を提示していることです。実際、広大な CNCF 環境内には、ある程度重複し、ある程度補完し、時には統合するオープンソース プロジェクトが多数存在し、関連プロジェクトのより広範なポートフォリオ パターンが出現する可能性があります。

3. Argo CDとKeptn

継続的インテグレーション (CI)/継続的デリバリー (CD) 分野のプロジェクトでは、ビルドおよびデプロイメント パイプラインに Kubernetes ネイティブの開発パターンとプロセスを使用することを検討しています。たとえば、Tekton Pipelines は Kubernetes 上で実行され、Kubernetes クラスターを第一クラスとして扱い、コンテナ (およびポッド) を構成要素として使用します。人気の高い Jenkins ビルド ツールのフォークである Jenkins X も、クラウド ネイティブ開発の世界を対象としています。

Tekton は完全な継続的インテグレーション (CI)/継続的デリバリー (CD) パイプラインを処理できますが、一部の新しいプロジェクトでは、デプロイメント パイプラインに柔軟性と機能を追加することを目的としています。

Tekton は、デプロイメントを 1 つ以上の Kubernetes クラスターに効果的にプッシュします。障害が発生した場合、Tekton はデプロイメントをすべての場所に再プッシュする必要があります。または、オペレーターが失敗したデプロイメントを手動でプッシュする必要があります。対照的に、Argo CD は宣言型の GitOps ツールです。正しいデプロイメント状態がアクティブなクラスターに反映されていることを確認し、それらを継続的に監視し、望ましい状態と実際の状態を一致させるために必要なアクションを実行します。

Keptn は、Argo CD のデプロイメント機能をスタンドアロンで利用する別のプロジェクトです。しかし、主な焦点は、本番環境で使用されるコードの追加テスト、評価、およびアップグレードにあります。

4. エンボイとコンター

上記では、マイクロサービス ベースの分散アプリケーションに関連する可観測性の課題について触れました。クラスター内のマイクロサービス間、およびクラスターと外部間のトラフィックを処理することも必要です。

データ転送、つまり Kubernetes の「データ プラットフォーム」は、Envoy を中心に標準化されています。 Envoy は各アプリケーションと並行して実行され、プラットフォームに依存しない方法で共通機能を提供することでネットワークを抽象化します。

Istio のようなサービス メッシュを Envoy 上に構築すると、クラスター内部 (東西トラフィック) とクラスターと外部の間 (南北トラフィック) の両方に対するセキュリティ、トラフィック方向、洞察を提供できます。サービス メッシュは、大規模なマイクロサービス ベースのアプリケーションを運用するための貴重なツールになります。また、複雑でサイズが大きすぎる場合もあります。 Contour のようなプロジェクトは南北の交通のみに焦点を当てています。これにより、Envoy は Kubernetes ユーザーにシンプルで信頼性の高い負荷分散ソリューションとして提供されます。

5. OKD 4、Fedora CoreOS、CodeReady コンテナー

開発者および運用ツールを備えた Kubernetes コミュニティ ディストリビューションを探している組織は、OKD を確認する必要があります。これは、Red Hat OpenShift 製品の「アップストリーム」プロジェクトと考えてください。ただし、ユニバーサル ベース イメージの導入は、実際には兄弟関係に近いものであり、更新されたコードをプロジェクトや製品に並行して流すことができます。

OKD 4 は、ノードのベース オペレーティング システムとして Fedora CoreOS を使用します。 Fedora CoreOS は、コンテナ化されたワークロードを安全に実行するための、自動的に更新される小型のオペレーティング システムです。 OKD 4 は、最新のセキュリティ修正と cgroups v2 のサポートなどの新機能を備えた Kubernetes クラスターを提供し、Kubernetes Operator のサポートも提供します。

OKD はインストーラーによって提供されるインフラストラクチャもサポートします。多くのプラットフォームでは、インストーラーがインストール プロセスのすべての領域を制御します。ユーザーが提供するインフラストラクチャほど柔軟ではありませんが、使い方がはるかに簡単なので、一般的にほとんどのユーザーにとってデフォルトと見なされます。

最後に、開発者が継続的インテグレーション (CI)/継続的デリバリー (CD) パイプラインにコードをプッシュする準備ができる前に、OKD 4 では、開発とテストに CodeReady コンテナーを使用して、ラップトップやデスクトップ上に事前構成されたローカル Kubernetes クラスターを少数設定できるようになりました。これらは、OKD (または OpenShift) クラスターの構築を開始するための最も早い方法です。

Kubernetes コミュニティからのその他の情報

CNCF の状況を見ると、Kubernetes に関するコミュニティの革新はほとんどないことがわかります。しかし、これらは、新年に心に留めておくべきプロジェクトや分野についての洞察を提供するはずです。