ブログ
Moderator Moderator , Moderator Moderator Moderator
ブログ
Kubernetes:カーネルについて
Dec 11, 2019

 


1Blog1.jpg

 

来たる KubeCon + CloudNativeCon North America 2019 に向けて、このイベントで話題をさらいそうなトピックに関するブログ連載をお届けしています。第 1 では、モノリシック アプリケーションからマイクロサービスベース アプリケーションへの移行を取り上げ、マイクロサービスがもたらすスピードや規模のメリットと、それらすべてをオーケストレーションする Kubernetes について紹介しました。

 

Kubernetes は、Software-Defined ネットワーク(SDN)のような万能の Software-Defined の新種と思われがちです。ジュニパーの JKitty(アニメ キャラクターのレインボー バタフライ ユニコーン キティ)による擬人化で知られています。しかし、バタフライ効果をご存じでしょう。Kubernetes キティが羽ばたくと、嵐が起こるのです。Kubernetes は本当に素晴らしいものですが、驚くほど容易であるとはまだ言えません。マイクロサービス アーキテクチャへの移行に伴い、Kubernetes には課題を解決しても同じだけ課題が生まれてきます。

 

アプリケーションをマイクロサービスに分割するには、セキュリティとネットワークが重要です。ネットワークによってマイクロサービスは互いに通信し、大きなアプリケーションに統合されていくからです。間違いがあると、本当に嵐が起こります。

 

今週の KubeCon でジュニパーがご紹介するソリューションは、ジュニパーのエンジニアリングとして広く認知されている分野に関するものです。つまり、大規模なネットワークとセキュリティです。

 

幸いなことに、これらは Kubernetes の課題を簡素化するうえで最適です。詳しく見てみましょう。

 

マイクロサービスと Kubernetes の課題


正しく設計されたマイクロサービスベース アプリケーションでは、単一コンテナ/サーバー ノードの損失を回避できます。ただし、オーケストレーション プラットフォームを実装し、適切なサービスのインスタンスを十分な数だけアクティブにして、アプリケーションが需要に対応できるようにする必要があります。マイクロサービスベース アプリケーションは、詰まるところ、各サービス インスタンスを必要に応じて追加/削除できるように設計されたものです。

 

スケールアウト対応で耐障害性に優れたこの種のオーケストレーションは、その他多くの制約されたスケジュール機能とともに Kubernetes によって実行されます。そのため、Kubernetes はクラウドのためのオペレーティング システム カーネルとよく呼ばれます。さまざまな場面で、分散した一連のマイクロサービスベース アプリケーションの強力なプロセス スケジューラーとして機能します。ただ、アプリケーションの稼働に必要なのはカーネルだけではありません。

 

業界で最も難しい問題を正しく解決するために、ジュニパーは Engineering Simplicity を掲げ、ストレージ、セキュリティ、ネットワーク、モニタリングの課題に取り組んでいます。お客様や自分たちの経験からわかっているのは、独自の Kubernetes 環境を管理する場合、この新しい IT プラットフォームを適切に管理するには、こうした課題に正面から対処しなければならないということです。

 

1 つの解決方法として、アウトソーシングがあります。サービスとしての Kubernetes など、簡素化するというアプローチもありますが、経済性を取るか、マルチクラウドの移植性や一貫性を取るかという問題が伴います。そこで、多くの企業に合うのが Kubernetes クラスタの運用です。これは、ジュニパーの得意分野です。

 

挑戦に限界を設けるのではなく、限界に挑戦する

 

Kubernetes を運用する企業の多くは、クラスタのサイズを制限することで課題に対処しています。

 

クラスタのサイズが小さいほど、セキュリティと信頼性の対象範囲が限定され、モニタリング、ストレージ、ネットワークの需要が小規模になるため、サイズの大きい共有クラスタよりも課題の解決が容易であるように思えます。場合によっては、アプリケーション チームごとに独自のクラスタを導入しています。また、開発ライフサイクルのフェーズ(開発、テスト、ステージング、実稼働)ごとに独自の Kubernetes クラスタを使用している場合もあります。細かい違いはさておき、Kubernetes を運用する企業の多くは、サイズの小さいクラスタ(たとえば、ノード数が 1020 で、各ノードに 23 のアプリケーションがあるクラスタ)を導入しています。しかし、Kubernetes を桁違いに拡張することが可能なのです。

 

多数の小さいクラスタという現象には、すでに名前があり、Kube スプロールといいます。

 

小さいクラスタの設計にもメリットはあると思いますが、このアプローチでさっそく新しい課題が発生しています。複雑ではないものの、よく見られます。多数のクラスタの管理における運用上の課題には、扱う Kubernetes の現行バージョン、アップグレード、パッチが増えるということも含まれます。当然、それらすべてに対処したり、その自動化のために追加作業を行うエンジニアの数も増えます。

 

さらに、明らかなデメリットがあります。各サーバー/VM ノードが属すことができる Kubernetes クラスタは 1 つのみであるため、サイズの大きい共有クラスタに比べて効率が低下します。リソースのスケール効率とスケール メリットは、アプリケーション、チーム、バッチ、ピーク使用時間が非常に多様な場合に達成されます。

 

小さいクラスタで少数のアプリケーションを実行している場合は、それらのアプリケーションは、リソース プール全体を常に使用するほど多様ではないでしょう。そのため、無駄が発生します。Kubernetes の運用では、コンテナ化されたアプリケーションのように、クラスタ ノードの数自体に柔軟性を持たせようとすることはできます。しかし、小さい各クラスタ内にあるアプリケーション固有のニーズに応じてこのオーケストレーションを自動化および構築することは困難です。たとえば、高可用性を確保するために各 Kubernetes クラスタに 3 つ以上のサーバー ノードが必要だとすると、維持しているクラスタの数だけ複製が無駄に行われることにもなります。

 

多数のクラスタは、開発者にとって新たな課題です。クラウドネイティブのツール(マイクロサービス追跡ツールなど)は開発者にメリットをもたらしますが、これらのツールやその他のミドルウェア サービスは一般にクラスタ間ではなくクラスタ内で機能するように設計されています。その他の新しいツール(サービス メッシュなど)は、クラスタ間で連携させると複雑化する可能性があります。

 

エッジ クラウドやマルチクラウドにまたがるアプリケーションがクラウドネイティブ インフラストラクチャにも必要

 

Kubernetes は、複数サーバーの単一クラスタとそれらのサーバー上で実行されているコンテナの管理に長けています。ただし、一部のアプリケーションは、複数の障害ドメインまたは可用性ゾーン(AZ)にまたがる複数のクラスタ内で実行されます。これは、同一のデータ センター AZ 内にある複数の小さいクラスタではありません。可用性を高め、グローバルな対象範囲を拡大し、ユーザーのレイテンシを改善するために、複数のデータ センターにまたがっています。

 

セキュリティ、ネットワーク、モニタリング、ストレージの問題をクラスタごとに解決するのが第一歩です。ただし、AZ、地域、エッジ クラウド、マルチクラウドの間で複数のクラスタを連携させるという課題には、強力なソリューションで対処する必要があります。ここでも、ジュニパーは市場をリードしています。その点については、KubeCon でご紹介します。

 

このシナリオでは、セキュリティとネットワークがさらに複雑化します。グローバルなアプリケーション アーキテクチャで果たす役割がさらに重要になるからです。ネットワークでは、マルチクラウドだけでなく、マイクロサービス同士もリンクさせる必要があります。多層防御では、1 つのクラスタを保護する必要があります。広域防御では、トップツーボトムに加え、エンドツーエンドにもポリシーを一律に適用する必要があります。

 

レガシーをいつも残しておけるわけではない

 

実際の企業環境では、クラウドネイティブ アプリケーションで使用されるサービスは「未だにメインフレームで実行されるもの」から「まさにマイクロサービスと呼べるもの」までいろいろあります。根本的に異なるタイプの複数のサービスがアプリケーションを構成し、それぞれ違う種類のインフラストラクチャ上で実行され、場合によっては世界各地のさまざまなプロバイダから提供されている状況で、安全性、性能、拡張性に優れた Software-Defined インフラストラクチャをアプリケーションのために用意するにはどうしたらよいでしょうか?

 

ここでも Kubernetes のセキュリティ、ネットワーク、モニタリング、ストレージの問題を解決することに問題はありませんが、VM やベアメタルのレガシーの管理についてはどうでしょうか?Kubernetes 用の目新しいツールの多くが終了しても、Kubernetes はそれに対応しますが、アプリケーションは対応しません。さらに、運用も対応しません。運用チームは別のツールも習得して導入しなければならず、負担が減るどころか増えます。今日の技術とツールは、クラウドネイティブに関連する新しい問題を解決する必要があります。最高のツールを使えば、現状での最も難しい問題、つまり運用の簡素化という問題を解決することができるでしょう。これが実現するのは、新旧の間にある垣根を越え、将来の進化の可能性を保てる場合のみです。

 

運用の簡素化のためのソリューション

 

この時点で、次に何が来るのかを推測するのは簡単です。ジュニパーには、ハイパフォーマンスで拡張性に優れたシステムの構築に成功してきた長年の経験があります。

 

ぜひ次回のブログもお見逃しなく。Kubernetes ユーザーを始めとする皆様にジュニパーが提供する運用の簡素化について取り上げる予定です。それまで、ジュニパーのクラウドネイティブ ソリューションの詳細を juniper.net/cloud-native でご確認ください。 

0 件の賞賛