Kubernetes を使用すると、ユーザーはアプリケーション管理とインフラストラクチャ オプションのオープン エコシステムからコンポーネントを選択でき、CNCF のリーダーシップのもと、Kubernetes は新しい Linux になりました。

これが、Kubernetes がコンテナ オーケストレーションの事実上の選択肢となった理由です。

[[324018]]

なぜ？

多様なユースケースに対応するため、初期のKubernetes開発者はプラットフォームを意図的に空白のままにし、ユーザーに柔軟性を提供しました。Kubernetesは万能なプラットフォームではなく、むしろスケーラブルなプラットフォームです。ユーザーとベンダーは、カスタムリソース（CRD）、コンテナストレージインターフェース（CSI）、コンテナネットワークインターフェース（CNI）を使用して、それぞれのニーズに合わせて環境を簡単にカスタマイズできます。Kubernetesにおけるこの意図的な空白化は、インフラストラクチャ層とアプリケーション層の両方で柔軟性を提供します。

クラウドネイティブ環境の構成要素

クラウドネイティブインフラストラクチャにおける意図的な省略

インフラストラクチャー

現在、Kubernetesを実行するためのインフラストラクチャには、多くの選択肢があります。オンプレミスでもパブリッククラウドでも実行できます。また、仮想マシンやベアメタルサーバー上でも実行できます。そのため、ユーザーは、具体的な機能、パフォーマンス要件、効率性のニーズ、コスト要件に基づいて、十分な情報に基づいた意思決定を行う必要があります。しかし、誤った意思決定は、プロジェクトの成果や顧客体験に悪影響を及ぼす可能性があります。

ストレージ

インフラストラクチャと同様に、Kubernetesユーザーにとってストレージソリューションの選択は困難な作業となる可能性があります。ストレージ技術は長年にわたり大きく進歩してきたにもかかわらず、多くのユーザーは依然としてI/Oボトルネックに直面しています。Kubernetesがステートレスアプリケーションとステートフルアプリケーションの両方の標準となるにつれ、高スループットと低レイテンシで、災害復旧（DR）や高可用性（HA）などの最新のデータサービスを提供するストレージシステムの選択が重要になります。

ネットワーク

ネットワークは、あらゆるクラウドネイティブアプリケーションにとって基本的な要件です。Kubernetesはクラスタネットワークを管理できますが、アプリケーションを外部に公開し、スケーリングし、安全に相互接続することがKubernetesユーザーにとって最大の課題です。そのため、ネットワークソリューションを選択する際には、ネットワークトポロジ、セキュリティ、レイテンシ、スループットを考慮する必要があります。

リソース利用率

KubernetesはCPUとメモリレベルでノイジーネイバー問題に対処していますが、共有ストレージと共有ネットワークは依然としてリソースを大量に消費するアプリケーションからの攻撃に対して脆弱です。ユーザーは、ストレージとネットワークにおけるノイジーネイバー問題を回避し、リソース利用率を最大化するための対策を講じる必要があります。

共有インフラストラクチャを備えたクラウド環境では、ノイジーネイバーとは、帯域幅、ディスク I/O、CPU、およびその他のリソースを過度に消費するテナントのことです。これにより、他のユーザーのクラウド パフォーマンスに悪影響が及ぶ可能性があり、共有インフラストラクチャ内の他の仮想マシンやアプリケーションでクラウド ネットワーク パフォーマンスの不均一性が発生する可能性があります。

クラウドネイティブアプリケーション管理における意図的なギャップ

ユーザーとクラスターの管理

Kubernetesはインフラストラクチャに依存しないため、基本的なクラスター管理とユーザー管理のみを提供します。多くの企業は、Active Directoryとの統合、ユーザーとイベントの追跡、ログ記録といった、すぐに利用できる機能よりも堅牢な機能を求めています。

高度なカスタマイズオプション

Kubernetes はコンテナのオーケストレーションと管理を目的として設計されていますが、強化されたセキュリティや構成制御などの領域を含む、さらなるカスタマイズのための高度なオプションも多数含まれています。

Linux と同様に、これらのオプションは Linux に精通しているユーザー向けです。

アプリケーションライフサイクル管理 (ALM)

Kubernetesはコンテナのオーケストレーションは行いますが、アプリケーションのオーケストレーションは行いません。開発者は通常、個々のコンテナの管理よりもアプリケーションのライフサイクル管理を重視します。注：ALMコンポーネントを使用したアプリケーションのアップグレードは、Kubernetesでは複雑になります。

マルチクラスタ管理

Kubernetesの急速な導入に伴い、組織は簡素化と分離を実現するために、複数のKubernetesクラスター（開発用、テスト用、本番用など）を使用する傾向にあります。しかし、これは単一のパネルから複数のクラスターを管理するという複雑さをもたらします。異なる（または同じ）クラウドプロバイダー、異なるデータセンター、異なるリージョン間でのアプリケーションとそのデータの移動も、複雑さを増します。

Kubernetesコミュニティからの改善

CNCFのリーダーシップの下、Kubernetesコミュニティは標準化されたインターフェースとフレームワークを通じて、プラットフォームのコア機能を積極的に開発・改善してきました。これらの取り組みにより、エコシステム内のベンダーやその他の貢献者は、前述のギャップを埋めることができました。

オペレーターフレームワーク

Operatorは、Kubernetesアプリケーションのライフサイクル管理専用に設計された専用コントローラーです。このフレームワークは、Kubernetesコミュニティによって開発され、アプリケーション管理における自動化、標準化、使いやすさ、柔軟性を実現します。

オペレーターの例としては、Microsoft SQL Server、MongoDB、CrunchyPostgreSQLなど、様々なベンダーからリリースされているデータベースオペレーターが挙げられます。データベースオペレーターを使用することで、データベースの作成、破棄、クローン作成、スケーリング、シャーディングなどを完全に自動化できます。さらに、オペレーターは高可用性（HA）、レプリケーション、負荷分散、フェイルオーバー、スナップショットなど、本番環境でデータベースを運用するために必要な主要な機能を提供します。

CSIとCNI

Kubernetesの初期段階では、Kubernetesへのストレージ統合はサポートされていませんでした。Diamantiは「FlexVolume」と呼ばれるストレージプラグインを提供し、Kubernetesへのストレージ統合への道を開きました。

FlexVolumeプラグインは、Kubernetes上でステートフルアプリケーションを実行できるようにします。FlexVolumeは後にCSIへと進化し、Kubernetes 1.13以降で完全にサポートされています。同様に、KubernetesコミュニティはCNIプラグインを開発し、ユーザーがKubernetesを好みのネットワークソリューションと統合できるようにしました。

これらの標準インターフェースは、サードパーティソリューションによるKubernetesの拡張を容易にします。しかし、ストレージとネットワークのニーズを満たす適切なベンダーまたはソリューションを選択するという新たな課題が生じます。

空白を埋める

前述の通り、Kubernetes にはあらゆるプラットフォームで柔軟に動作できるように、意図的に多くのギャップが設けられています。サービスプロバイダーとインフラストラクチャプロバイダーには、これらのギャップを埋める責任があります。

すべてのパブリッククラウドプロバイダーはKubernetesサービスを提供し、特定のコンピューティング、ストレージ、ネットワークインフラとの統合におけるギャップを意図的に埋めています。しかし、パブリッククラウドは均質なリソースとして設計されています。つまり、本番環境のアプリケーションは「ノイジーネイバー」と呼ばれる問題に悩まされる可能性があり、ユーザーはインフラの過剰プロビジョニングを余儀なくされ、コスト増加につながります。

Kubernetesエコシステムのリファレンスアーキテクチャ

さらに、Kubernetesをローカルインフラストラクチャ上で実行するのは必ずしも簡単ではありません。DIYアプローチでKubernetesをデプロイする場合、CSI、CNI、ハードウェア、オペレーティングシステム、セキュリティ、ID、ユーザー管理など、多数の異なるコンポーネントの選択と管理が課題となります。昨年、多くのベンダーがCNCF認定のKubernetesディストリビューションの提供を開始しました。

Kubernetes向けに設計されたDiamantiハイパーコンバージドインフラストラクチャ

DIY Kubernetes の代替手段は、最新のハイパーコンバージド インフラストラクチャ (HCI) アプローチを活用してこれらのギャップを埋めることです。

Diamanti はこの分野の先駆者であり、完全に統合されたコンピューティング、ストレージ、ネットワーク、セキュリティ ソリューションのほか、クラスター管理、ID およびユーザー管理、監視、ハイブリッド クラウド管理も提供しています。

これにより、開発者と運用者はアプリケーションの開発と展開に集中できます。さらに、Diamantiプラットフォームは独自のIO管理ソリューションを通じて、ノイジーネイバー問題を完全に排除し、高いアプリケーションパフォーマンスを実現します。

結論は

Kubernetesは、あらゆる環境で動作するように設計された、コンテナオーケストレーションに最適なプラットフォームであることは明らかです。しかし、Kubernetesを支える基本原則は、既製のプログラムを稼働させることを困難にしています。その結果、Kubernetesは多くの問題を意図的に未解決のまま残し、コミュニティとベンダーが対処することになります。

したがって、組織でKubernetesを導入する際には、全体的な要件を満たすインフラストラクチャとアプリケーションの管理に必要な時間、労力、コストをどのように削減するかを検討することが重要です。統合アプローチは、これらのギャップをすべて埋めながら、デリバリータイムを短縮できる方法の一つです。

翻訳者: ワン・ヤンフェイ

オリジナルリンク: https://thenewstack.io/why-those-gaps-in-kubernetes-are-really-a-good-thing/