クラスタ管理に Google Kubernetes を使用するにはどうすればよいでしょうか?

この記事はAI新メディアQuantum Bit（公開アカウントID：QbitAI）より許可を得て転載しております。転載については出典元にお問い合わせください。

Kubernetes は、2014 年に Google がリリースしたオープンソース プロジェクトです。

これは、アプリケーション コンテナの展開、スケーリング、および操作を自動化し、インフラストラクチャに真のコンテナ中心の開発環境を迅速に提供できるオープン ソース プラットフォームです。

結局のところ、今日のクラウドネイティブの世界では、コンテナが最も重要なコンピューティング リソースの形式になります。

Kubernetes テクノロジーは過去 1 年間でどのように発展しましたか?

おそらく、成熟と安定という言葉がそれを最もよく表しているでしょう。

言及する価値のある点の 1 つは、ますます多くの大手企業がクラウド ネイティブ市場に参入していることです。

もはや、技術革新に熱心なスタートアップ企業が集まる時代ではありません。

牧場主は今でもこの景観の変化を覚えているに違いない。

Rancher Labs は、CloudStack の父である Liang Sheng によって設立され、この分野に最初に参入した「先駆者」として常に評価されてきました。

同社の主力製品であるオープンソースのエンタープライズレベルのKubernetes管理プラットフォーム「Rancher」は、ハイブリッドクラウド＋ローカルデータセンターにおけるKubernetesクラスターの集中的な展開と管理を初めて実現し、2020年2月に中国でのローカライズと現地化を完了しました。

この点については、Rancher China の CTO である Jiang Peng 氏も同様の考えを持っています。 2017年から2018年にかけて、より多くのクラウド サービス プロバイダーがコンテナーを自社のサービスの一種とみなしましたが、最も中核的なサービスとはみなしていませんでした。

しかし、現在では、すべての参加者がコンテナに代表されるクラウドネイティブ サービスをコア サービスのカテゴリにアップグレードすることになります。

もちろん、この変化は、参加者がクラウドネイティブ分野やテクノロジースタックを認識している一方で、ビジネスの「実装」の問題をより懸念しているという事実にも反映されています。

たとえば、アプリケーションの運用、マイクロサービスのガバナンス、Kubernetes クラスターの管理とセキュリティ、さらには AI などの新しいテクノロジーとの統合などです。

これを踏まえると、エコシステムレベルでのイノベーションにもっと注意を払い、ユーザーニーズの変化にもっと柔軟に適応し、革新的なプロジェクト製品を通じてクラウドネイティブを推進または実装する過程で多くの問題を解決することが、企業にとってクラウドネイティブの戦いに勝つための鍵となるかもしれません。

さらに、クラウドネイティブの実装においては、K8S マルチクラスタ管理、コンテナエッジ展開、AI テクノロジとの統合など、避けられない困難が伴います。

コンテナの実装で問題がある場合は、以下を読み進めてコンテナの詳細を学んでください。これは、概念に関する混乱をいくらか解消するのに役立つかもしれません。

開発重視から実戦対応へ：クラスター管理は「言いたいことがある」

私たちの推論が信頼できるものであれば、実用的なクラウド ネイティブへの鍵の 1 つは、Kubernetes クラスターの管理に集中することができます。

Rancher の初期の製品の位置付けと同様に、マルチクラスター管理またはハイブリッド クラウドとマルチクラウドのマルチクラスター管理に重点を置いています。

マルチクラスターとは具体的に何でしょうか?

実用的な観点から見ると、クラウド ネイティブまたは Kubernetes テクノロジーの使用を開始したばかりのほとんどの企業では、単一のクラスターを使用しているのではなく、より単純に少数のクラスターとして定義されています。

たとえば、多くの企業では、開発環境に 1 つのクラスターがあり、運用環境に別のクラスターがあります。これは、オンライン化を始めたばかりのときの典型的なシナリオかもしれません。

しかし、ビジネス規模が拡大するにつれて、コンテナ プラットフォームが企業内でますます採用されるようになり、ユーザーはより多くのアプリケーションをクラスターに移行する必要があることに気付くでしょう。

単一のデータセンター展開から複数のデータセンター、さらにはマルチクラウド シナリオへの移行により、マルチクラスター管理の問題が発生します。

江鵬氏はさらに、マルチクラスター管理における「マルチ」はクラスターの規模だけでなく、異なるチーム間でも概念が大きく異なることにも反映されていると明らかにした。

プラットフォーム構築チームにとって、マルチクラスター管理テクノロジーは、基盤となるインフラストラクチャの違いを保護して、一貫した認証と承認、および管理、運用、保守機能を提供する方法を意味します。

アプリケーション チームとしては、これらのクラスターを統一された一貫した方法で展開して使用し、異なるクラスター上で一貫した上位層サポート機能を提供することを好みます。重要なのは、監視、アラート、ログ収集、マイクロサービス ガバナンスなどのさまざまなアプリケーションを複数のクラスターに迅速に展開することです。

金融ユーザー向けのマルチアクティブ データ センターを例にとると、これは典型的な 2 サイト 3 センター アーキテクチャです。アプリケーション チームの場合、次の点に重点を置いています。コア ビジネス システムをワンクリックでデータ センターに迅速に展開し、災害復旧やデータ センター間のマルチアクティブ化を実現できるかどうか。

これを基に、Rancher は、マルチクラスター、マルチテナントの監視機能や、複数の Kubernetes クラスターにわたる単一アプリケーションの展開と管理など、製品にいくつかの機能強化を加えました。

具体的には、クラスターテンプレートの定義に基づいて、アプリストアのアプリケーションシステムをワンクリックで任意の数のクラスター内の複数のプロジェクトにシームレスにデプロイできます。

セキュリティに関しては、企業にとって常に大きな懸念事項であり、コンテナ クラスターの管理も例外ではありません。

プラットフォーム全体のセキュリティを考慮すると、セキュリティの問題について議論する際には、エンドツーエンドのソリューションが必要になります。

コンテナ プラットフォームのセキュリティの観点からは、クラスター自体のセキュリティだけに重点が置かれることはあまりありません。

代わりに、アプリケーション開発からコンテナ化された操作の最終的な配信までのライフサイクル全体のセキュリティ プロセスのより多くをカバーします。

たとえば、方向安全性。

コンテナ イメージ全体の組み込みコンポーネントまたはサービスにセキュリティ上の脆弱性がないことをどのように確認するかについて、ユーザーが懸念するのはよくあることです。

クラスターのセキュリティに関しては、業界のベスト推奨事項に準拠することが重要になります。

たとえば、セキュリティ ベンチマークに従い、匿名アクセス ポートを閉じ、コンポーネント間で双方向 TLS 暗号化を使用し、関連するコンポーネントが最小限の権限で起動されているかどうかを判断します。

さらに、クラスターの運用セキュリティには、コンテナー ランタイムなど、クラスターの上位層にあるアプリケーション ランタイムのいくつかの構成も含まれます。

マルチテナントのシナリオの場合は、異なるテナント間でネットワークを分離する方法も考慮され、専門的なセキュリティベンダーからの技術サポートが求められる場合もあります。

コンテナのセキュリティは複雑ですが、セキュリティ管理を無視することはできません。

エッジシナリオでのクラスター管理の難しさは何ですか?

実際、エッジでのコンテナ技術の使用は目新しいものではなく、Jiang Peng 氏もこの意見に同意しています。

たとえば、Microsoft の Azure および Azure IoT Center 構成は、業界で長い間存在してきた例です。

違いは、Azure IoT Center は Docker コンテナー テクノロジに基づいており、現段階では Kubernetes のようなオーケストレーションを使用しない可能性があることです。

さらに重要なのは、コンテナ テクノロジは、アプリケーション配信またはアプリケーション パッケージ配信の方法として自然に存在できることです。

つまり、この「自然な」性質は、エッジ側などの大規模なアプリケーションでの統一された標準化された展開に適しています。

この要約により、それがさらに一般的なものになります。

コンテナには固有の特性がありますが、展開および管理プロセスで直面する問題は、クラウド、データセンター、さらには異機種混在のインフラストラクチャに展開する場合ほど単純ではありません。

直感的な定量的な観点から見ると、エッジ側のクラスターの規模は、従来のデータセンターの数十から数十のクラスターではなくなりました。

代わりに、クラスターのサイズは数千、数万、さらには数十万になることもあります。

さらに重要なのは、エッジ シナリオと従来のクラウドまたはデータ センター シナリオの最大の違いは、エッジ シナリオが非常に多様で断片化されていることです。

データ センターと比較すると、誰もが標準の X86 サーバーと統合ストレージを使用しています。 Kubernetes は、標準化されたビジネス オペレーションをサポートする一貫した API を提供できます。

ただし、エッジ側では、ビジネス シナリオで使用されるデバイスと使用されるプロトコルの両方に大きな違いがあります。

「たとえば、製造業の顧客の中には、生産ラインに Linux システムではなく Windows システムを多数導入しているところもあります。Windows Server ではないシステムもさらに多いかもしれません。これらのデバイスが何らかのプロトコルを介して生産ライン上の他のデバイスとやり取りする場合、どれほど困難になるかは想像に難くありません。」

では、このような大規模なクラスターをどのように管理すればよいのでしょうか?

現時点では、統一された標準を形成するために立ち上げられた統一されたデータセンターのシナリオやプラットフォームはありません。

エッジ シナリオでは、ユーザーは一部のシステムまたはアプリケーションをコンテナ化またはクラウド ネイティブに変換する必要があり、段階的な適応と変換のプロセスが必要になります。

しかし、江鵬氏は、エッジでのコンテナ技術の使用は確かに推進すべきトレンドであり需要でもあると認めた。

「エッジでの Docker エンジンの使用は確認されていますが、エッジでより強力なオーケストレーション機能を実現するために、標準の Kubernetes をエッジにプッシュするかどうかはまだ議論中です。」

Quantum によると、コンテナに投資するクラウド サービス プロバイダーのほとんどは、効果的な管理のために、依然として標準の Kubernetes をエッジに導入することを選択しています。しかし、Rancher は例外であり、そのため K3s が適切なタイミングで登場したのです。

これにより、ユーザーにとっての Kubernetes の導入と管理の複雑さが軽減されます。ユーザーはさまざまな複雑なコンポーネントを管理する必要がなくなり、箱から出してすぐにワンクリックで展開できるようになります。

ETCD などの比較的新しいキー値データを維持するために多大な労力を費やす必要はありません。

上記を踏まえると、リソース消費を削減し、ユーザーがコンピューティング リソースの少ないデバイス上で Kubernetes クラスターを実行できるようにすることが、K3s の利点であると考えられます。

さらに、最近オープンソースとして正式に発表された Fleet は、Rancher が牛と同じように部門サブクラスターを管理する方法でもあり、大規模な Kubernetes クラスターの集中管理の利点を体験できるようにします。

「重点は、特定のクラスターのアプリケーション展開ではなく、クラスターをクラスター グループとして扱い、より高い次元から管理することにあります。」

コンテナ + AI で何ができるでしょうか?

昨今、AI業界の専門メーカーや実際のAIトレーニングシナリオアプリケーションなどでも、コンテナ上でAIビジネスを運営するケースが増えてきています。これは徐々に、事業の実現を模索する上で重要な課題の一つとなってきました。

たとえば、AI モデルのトレーニングでは、大量のデータ、画像、ソース ファイルにアクセスしたり読み取ったりすると、大規模な計算能力が消費されることになります。ただし、典型的な大規模コンピューティング シナリオは、まさにコンテナーに必要なものです。

しかし、状況は複雑です。コンテナ シナリオでの AI の実際の実装には、まだいくつかの課題が残っています。

たとえば、リソース共有分割の粒度。

現在、Kubernetes 自体には CPU リソースを共有およびスケジュールするための強力な機能がありません。

江鵬氏は、Nvidia が vGPU を正式に実装していないため、標準の Kubernetes やコミュニティ バージョンの Kubernetes クラスターにおけるリソース スケジューリングの粒度は比較的粗く、リソース利用率はあまり高くないと述べました。

さらに、コンテナ化されたシナリオでは、モデルトレーニング用の断片化された小さなファイルや大規模なファイルの処理パフォーマンスが理想的ではない可能性があります。

それにもかかわらず、ガートナーは2019年に発表したAIに関する予測レポートで依然としてその「姿勢」を表明した。

企業の CIO が AI を最優先事項と見なす場合、Kubernetes の重要な役割を過小評価することはできません。

ガートナーは、Kubernetes が企業内の AI アプリケーションに最適なオペレーティング環境およびプラットフォームになるだろうと述べています。

コンテナとサーバーレスにより、機械学習モデルを独立した機能として提供できるようになり、より低いオーバーヘッドで AI アプリケーションを実行できるようになります。これは、Kubernetes + AI の見通しが明るいことを示しています。

Kubernetes の成熟度と安定性についてどう思いますか?

付録：インタビューゲストの簡単な紹介