プロダクショングレードのKubernetesで複雑さを軽減

編集者– この投稿は10 部構成のシリーズの一部です。

1. プロダクショングレードの Kubernetes で複雑さを軽減する (この投稿)
2. 高度なトラフィック管理で Kubernetes の回復力を向上させる方法
3. Kubernetes の可視性を向上させる方法
4. トラフィック管理ツールを使用して Kubernetes を保護する 6 つの方法
5. Ingress コントローラーの選択ガイド、パート 1: 要件を特定する
6. Ingress コントローラーの選択ガイド、パート 2: リスクと将来への備え
7. Ingress コントローラーの選択ガイド、パート 3: オープンソース vs. デフォルト vs. コマーシャル
8. Ingress コントローラーの選択ガイド、パート 4: NGINX Ingress コントローラー オプション
9. サービスメッシュの選択方法
10. 動的 Kubernetes クラウド環境での NGINX Ingress コントローラーのパフォーマンス テスト

また、ブログの完全セットを無料の電子書籍「 Taking Kubernetes from Test to Production」としてダウンロードすることもできます。

2020年は、私たちにとって忘れられない年となりました。 学校、企業、公共サービスの突然の閉鎖により、私たちは突然コミュニティから孤立し、安全と経済的安定について不安に陥りました。 さて、これが 2000 年、あるいは 2010 年に起こったと想像してみてください。 何が違うのでしょうか? テクノロジー。 私たちが当たり前だと思っている高品質のデジタルサービス（医療、ストリーミングビデオ、リモートコラボレーションツールなど）がなければ、パンデミックはまったく異なる経験になっていたでしょう。 2020 年のテクノロジーは過去数十年と比べて何が大きく変わったのでしょうか? コンテナとマイクロサービス。

一般的にコンテナとKubernetesを使用するマイクロサービスアーキテクチャは、デジタル エクスペリエンスの市場投入までの時間を短縮することで、ビジネスの成長とイノベーションを促進します。 従来のアーキテクチャと併用する場合でも、スタンドアロンとして使用する場合でも、これらの最新のアプリ テクノロジーにより、優れたスケーラビリティと柔軟性、より迅速な展開、さらにはコスト削減も実現できます。

2020 年以前、ほとんどのお客様がすでにデジタル変革戦略の一環としてマイクロサービスの導入を開始していましたが、パンデミックによりアプリのモダナイゼーションが真に加速しました。 2020 年に NGINX ユーザーを対象に実施した調査では、回答者の 60% が本番環境でマイクロサービスを使用しており、2019 年の 40% から増加していること、また、コンテナーは他の最新のアプリ テクノロジーの 2 倍以上人気があることがわかりました。

Kubernetes は、コンテナ化されたアプリを管理するための事実上の標準です。これは、 Cloud Native Computing Foundation (CNCF) の 2020 年の調査によって証明されており、回答者の 91% が Kubernetes を使用しており、そのうち 83% が本番環境で使用していることがわかりました。 多くの組織は、Kubernetes を導入する際に大幅なアーキテクチャの変更に備えていますが、最新のアプリ テクノロジーを大規模に実行することによる組織への影響に驚いています。 Kubernetes を実行している場合、おそらく次の 3 つのビジネスクリティカルな障壁すべてに遭遇したことがあるでしょう。

• 文化
  アプリ チームがアジャイル開発や DevOps などの最新のアプローチを採用したとしても、通常は「組織は独自のコミュニケーション構造を反映するシステムを設計する」というコンウェイの法則に従います。 つまり、分散アプリケーションは、独立して運用されながらもリソースを共有する分散チームによって開発されます。 この構造は、チームの迅速な実行を可能にするのに理想的ですが、サイロの確立も促進します。 その結果、コミュニケーション不足（それ自体に結果がある）、セキュリティの脆弱性、ツールの無秩序な拡散、一貫性のない自動化の実践、チーム間の衝突などが起こります。
• 複雑
  エンタープライズ グレードのマイクロサービス テクノロジーを実装するには、組織は可視性、セキュリティ、トラフィック管理を提供する重要なコンポーネントのスイートを組み合わせる必要があります。 通常、チームはインフラストラクチャ プラットフォーム、クラウド ネイティブ サービス、オープン ソース ツールを使用してこのニーズを満たします。 これらの戦略にはそれぞれ適切な場面がありますが、それぞれに複雑さを増す欠点があります。 そして、多くの場合、単一の組織内の異なるチームが同じ要件を満たすために異なる戦略を選択し、「運用負債」が発生します。 さらに、チームはプロセスとツールをある時点で選択し、コンテナを使用した最新のマイクロサービス駆動型アプリケーションのデプロイと実行に関する要件の変化に関係なく、それらを使い続けます。

  CNCF クラウド ネイティブ インタラクティブ ランドスケープは、マイクロサービス ベースのアプリケーションをサポートするために必要なインフラストラクチャの複雑さを示す良い例です。 組織はさまざまな異なるテクノロジーに習熟する必要があり、その結果、インフラストラクチャのロックイン、シャドー IT、ツールの無秩序な拡散、インフラストラクチャの保守を担当する人々の急激な学習曲線などが生じます。

• 安全
  リングフェンス セキュリティなどの戦略は Kubernetes では実行できないため、クラウド ネイティブ アプリと従来のアプリではセキュリティ要件が大きく異なります。 コンテナ化されたアプリの大規模なエコシステムと分散型の性質により、攻撃対象領域ははるかに大きくなり、外部の SaaS アプリケーションに依存することで、従業員や部外者が悪意のあるコードを挿入したり、情報を盗み出したりする機会が大幅に増えます。 さらに、文化と複雑さの領域で概説した結果、特にツールの無秩序な増加は、最新のアプリのセキュリティと回復力に直接影響を及ぼします。 同じ問題を解決するためにエコシステム全体でさまざまなツールを使用することは、非効率的であるだけでなく、各コンポーネントを適切に構成する方法を学習する必要がある SecOps チームにとって大きな課題となります。

解決策: プロダクショングレードのKubernetes

ほとんどの組織の問題と同様に、Kubernetes の課題を克服するための答えは、テクノロジーとプロセスの組み合わせです。 この投稿の残りの部分ではテクノロジーの要素に焦点を当てますが、プロセスやその他のトピックに関する今後のブログにも注目してください。

Kubernetes はオープンソース テクノロジーであるため、実装方法は数多くあります。 独自のバニラ Kubernetes を展開することを好む組織もありますが、多くの組織は、Amazon Elastic Kubernetes Service (EKS)、 Google Kubernetes Engine (GKE)、Microsoft Azure Kubernetes Service (AKS)、 Red Hat OpenShift Container Platform 、 Rancherなどのサービスによって提供される柔軟性、規範性、サポートの組み合わせに価値を見出しています。

Kubernetes プラットフォームは簡単に起動して実行できますが、深さよりもサービスの幅広さに重点を置いています。 したがって、必要なサービスはすべて 1 か所で入手できるかもしれませんが、大規模な本番環境への本格的な対応に必要な機能セットが提供されることはほとんどありません。 つまり、Kubernetes は高度なネットワークとセキュリティに重点を置いておらず、この点で多くの顧客を失望させています。

Kubernetes を本番環境にするには、次の順序でさらに 3 つのコンポーネントを追加する必要があります。

1. クラスタへのトラフィックの入出力を可能にするスケーラブルなイングレス・エグレス層
   これは、Kubernetes ネットワークの複雑さを抽象化し、Kubernetes クラスター内のサービスと外部のサービス間の橋渡しをする特殊なロードバランサーであるIngress コントローラーによって実現されます。 このコンポーネントは、回復力を高める機能 (高度なヘルスチェックや Prometheus メトリックなど)、迅速なスケーラビリティを実現する機能 (動的再構成)、セルフサービスをサポートする機能 (ロールベースのアクセス制御 [RBAC]) が含まれている場合に、本番環境グレードになります。

   

2. クラスター全体の脅威から保護するための組み込みセキュリティ
   クラスターの外部では「粗い」セキュリティで十分かもしれませんが、クラスターの内部では「細かい」セキュリティが必要です。 クラスターの複雑さに応じて、柔軟なWeb アプリケーション ファイアウォール(WAF) を Ingress コントローラー上、サービスごとのプロキシとして、およびポッドごとのプロキシとしてデプロイする必要がある場所が 3 つあります。 この柔軟性により、請求などの機密性の高いアプリにはより厳格な制御を適用し、リスクが低いアプリにはより緩い制御を適用できます。

   

3. クラスタ内のトラフィックを最適化するためのスケーラブルな東西トラフィック層
   この 3 番目のコンポーネントは、Kubernetes アプリケーションが基本的なツールで処理できる複雑さと規模のレベルを超えたときに必要になります。 この段階では、クラスター内のアプリケーション サービスに対してさらにきめ細かいトラフィック管理とセキュリティを提供するオーケストレーション ツールであるサービス メッシュが必要です。 サービス メッシュは通常、コンテナ化されたアプリケーション間のアプリケーション ルーティングの管理、自律的なサービス間相互 TLS (mTLS) ポリシーの提供と適用、アプリケーションの可用性とセキュリティの可視性の提供を担当します。

   

これらのコンポーネントを選択するときは、移植性と可視性を優先してください。 プラットフォームに依存しないコンポーネントにより、複雑さが軽減され、セキュリティが向上します。チームが学習して保護する必要があるツールが少なくなり、ビジネス ニーズに基づいてワークロードを簡単に移行できるようになります。 可視性と監視の重要性は、いくら強調してもし過ぎることはありません。 Grafana や Prometheus などの一般的なツールとの統合により、インフラストラクチャの統一された「単一のペイン」ビューが作成され、顧客が問題を発見する前にチームが問題を検出できるようになります。 さらに、本番環境レベルの Kubernetes には必ずしも必要ではありませんが、最新のアプリ開発に不可欠なその他の補完的なテクノロジーも存在します。 たとえば、組織が従来のアプリを最新化する準備ができたとき、最初のステップの 1 つは、 API ゲートウェイを使用してマイクロサービスを構築することです。

NGINX がどのように役立つか

当社の Kubernetes ソリューションはプラットフォームに依存せず、本番環境レベルの Kubernetes を有効にするために必要な 3 つのコンポーネントが含まれています。 NGINX Ingress Controller をイングレス-エグレス層として、 NGINX App Protect をWAF として、 NGINX Service Mesh をイースト-ウェスト層として使用します。

これらのソリューションは、次の 4 つの主要領域を実現することで、Kubernetes をあなたの最高のパートナーにします。

• 自動化 – アプリをより早く、より安全に市場に投入
  NGINX Ingress Controller のトラフィック ルーティングとアプリ オンボーディング機能と、NGINX Service Mesh の NGINX Plus サイドカーの自動展開を組み合わせて、アプリを展開、拡張、保護、更新します。
• セキュリティ – 既存および新たな脅威から顧客とビジネスを保護する
  NGINX Service Mesh と NGINX Ingress Controller を使用してサービス間のエンドツーエンドの暗号化を管理および適用しながら、クラスター内の任意の場所に NGINX App Protect を展開することで、潜在的な障害ポイントを減らします。
• パフォーマンス – 顧客やユーザーが期待するデジタルエクスペリエンスを提供する
  他の WAF、Ingress コントローラー、ロード バランサーよりも優れたパフォーマンスを発揮する NGINX ソリューションにより、パフォーマンスを犠牲にすることなく、トラフィックの急増やセキュリティの脅威に簡単に対処できます。
• インサイト – ビジネスを進化させ、顧客により良いサービスを提供
  NGINX Ingress Controller と NGINX Service Mesh から、アプリのパフォーマンスと可用性に関する的を絞った分析情報を取得し、詳細なトレースを活用して、マイクロサービス アプリ全体でリクエストがどのように処理されているかを理解します。

NGINX で本番環境の準備を整える

NGINX Ingress Controller は30 日間の無料トライアルとして提供されており、コンテナ化されたアプリを保護するための NGINX App Protect が含まれています。 トライアルを最大限に活用するには、常時無料の NGINX Service Mesh ( f5.comからダウンロード可能) を追加することをお勧めします。 現在、任意のクラウドに独自のライセンス (BYOL) を持ち込むことができます。