【フォーカス】さまざまなクラウドサービス形態におけるKubernetesの優れた実践

[51CTO.com クイック翻訳] 2018 年のクラウド コンピューティング ステータス レポートによると、現在、企業の 81% が複数のクラウド サービス モデルを使用しています。パブリック クラウド サービス、最新のインフラストラクチャ プラットフォーム、パブリック クラウドとプライベート クラウドの継続的な組み合わせを導入することで、自社の規模と容量を迅速かつ柔軟に調整しながら、顧客に価値をより早く提供できるようになります。実際、IDCの最新データによると、2018年第1四半期の世界のサーバー出荷台数は前年同期比20.7%増の270万台となり、総収益は38.6%増加し、3四半期連続で2桁の成長を記録しました。

もう 1 つのエキサイティングなトレンドは、アプリケーション コンポーネントをパッケージ化して管理するための最適な方法を提供するコンテナーの出現です。 Kubernetes は、コンテナ化されたアプリケーションの導入と運用に最適なソリューションとしても広く受け入れられています。さらに、Kubernetes の重要な価値は、複数のクラウド プロバイダーが提供するサービス機能を標準化できることです。

もちろん、上記の利点は一定の複雑さももたらします。コンテナは DevOps 関連の問題を解決しますが、管理が必要な新しい抽象化レイヤーも導入します。 Kubernetes 自体は管理が必要な分散アプリケーションであるため、運用上の問題をすべて解決できるわけではなく、一部の問題しか解決できません。

この記事では、さまざまなクラウド サービス モデルで Kubernetes クラスターを正常に展開および実行するための主要な運用上の課題とベスト プラクティスについて説明します。一般的に、IT 運用チームは複数の社内チーム向けに全体的なエンタープライズ レベルの Kubernetes 戦略を構築する必要があるというのが私たちの見解です。

1. 最高のインフラを利用する

従来のオンプレミス インフラストラクチャ プロバイダーと同様に、すべてのクラウド サービス プロバイダーは、ストレージやネットワークなどのサービスを提供できます。複数のクラウド サービス モデルの戦略を検討する際には、さまざまなベンダーが提供する既存の機能を使用する必要があるかどうかに留意する必要があります。それとも抽象化レイヤーを使うべきでしょうか?どちらのアプローチも可能ですが、抽象化レイヤーを最小限に抑え、ベンダーが提供するソリューションを使用するように注意する必要があります。

たとえば、AWS でオーバーレイ ネットワークを実行する代わりに、AWS が提供する Kubernetes CNI (Container Network Interface) プラグインを使用して、Kubernetes にネイティブ ネットワーク機能を提供する方が適切です。このアプローチでは、セキュリティ グループや IAM (翻訳者注: Identity and Access Management) などの他のサービスも使用できます。

2. 独自のKubernetesバージョンを管理する

Kubernetes は急速に進化しているプロジェクトで、毎年 3 月に更新バージョンがリリースされます。したがって、ベンダーに Kubernetes のさまざまなリリースのテストと管理を依頼するか、または自社のチームがそれらのリリースを直接使用できるようにするかを決定する必要があります。

すべての物事には考慮する価値のある長所と短所があります。 Kubernetes の管理にベンダーを利用する場合、ベンダーはテストと検証に関して追加の支援を提供します。もちろん、Cloud Native Computing Foundation (CNCF) の Kubernetes コミュニティ自体には、成熟した開発、テスト、リリース プロセスがあります。

Kubernetes プロジェクトは、Special Interest Group (SIG) によって管理されています。リリース SIG (https://github.com/kubernetes/sig-release#mission) は、さまざまなプロセスを通じて各新しいバージョンの品質と安定性を確保する責任を負っています。 CNCF は、さまざまなベンダーに対して、自社のソフトウェアが Kubernetes のさまざまな API と 100% 互換性があることを証明するための Kubernetes ソフトウェア適合プログラムも提供しています。

企業内で内部使用する場合、実稼働環境では安定したバージョンを使用するのが最適です。ただし、一部のチームでは、GA 前の機能を備えたクラスターが必要になる場合があります。したがって、最善のアプローチは、チームがさまざまな実績のあるアップストリーム バージョンから選択する柔軟性を与えるか、必要に応じて新しいバージョンを試せるようにすることですが、その場合のリスクはチームに任せます。

3. ポリシーを通じてクラスタの展開を標準化する

Kubernetes クラスターをインストールするときは、次の重要な決定を行う必要があります。

1. バージョン:使用する Kubernetes コンポーネントのバージョン。
2. ネットワーク:使用するネットワーク テクノロジーは、CNI (Container Networking Interface、https://github.com/containernetworking/cni) プラグインを通じて構成されます。
3. ストレージ:使用するストレージ テクノロジーは、CSI (Container Storage Interface、https://github.com/container-storage-interface/spec) プラグインを通じて構成されます。
4. Ingress: Ingress コントローラーはロード バランサーとして使用でき、さまざまな外部リクエストをさまざまなアプリケーション サービスにリバース プロキシするために使用できます。
5. モニタリング:クラスター内の Kubernetes コンポーネントとワークロードを監視するために使用できるアドオン。
6. ロギング:クラスターの Kubernetes コンポーネントとアプリケーション ワークロードからログを収集、集約し、集中ロギング システムに転送するために使用できる集中ロギング ソリューション。
7. その他のアドオン: DNS やセキュリティ コンポーネントなど、クラスターの一部として実行する必要があるその他のサービス。

上記の決定はクラスターのインストールごとに実行できますが、クラスターのインストールのテンプレートまたは戦略として記録しておけば、後で再利用するときに効率的です。たとえば、Terraform スクリプト (https://www.terraform.io/docs/providers/kubernetes/index.html) または Nirmata クラスター戦略 (http://nirmata-documentation.readthedocs.io/en/latest/Clusters.html) を使用できます。クラスターのインストールが自動化されると、高レベルのワークフローの一部として呼び出すことができます。例: サービス カタログに基づいてセルフサービス プロビジョニング要求を実行します。

4. エンドツーエンドのセキュリティを提供する

コンテナと Kubernetes のセキュリティについては、次の側面を考慮する必要があります。

1. イメージスキャン:コンテナイメージを実行する前に、さまざまな脆弱性をスキャンする必要があります。したがって、このステップは、イメージが企業のプライベート ストレージ テーブルに入る前に、継続的デリバリー パイプラインの一部として実装できます。
2. イメージソース:イメージの脆弱性スキャンを実行することに加えて、実行中のクラスター環境に「信頼できる」イメージのみを許可する必要があります。
3. ホストとクラスターのスキャン:イメージに対するセキュリティ制御を実装することに加えて、クラスター ノードに対するスキャンも実行する必要があります。 CIS (Center for Internet Security) のさまざまなセキュリティ ベースライン (https://www.cisecurity.org/benchmark/kubernetes/) を使用して、Kubernetes のセキュリティを定期的に強化することがベスト プラクティスです。
4. セグメンテーションと分離:マルチテナンシーは必須ではありませんが、複数の異種ワークロード間でクラスターを共有することで、効率が向上し、コストを節約できます。 Kubernetes は、分離 (名前空間やネットワーク ポリシーなど) とリソース オーバーヘッド (リソース クォータなど) を管理するための構造を提供します。
5. ID 管理:一般的な企業展開では、ユーザー ID は集中ディレクトリによって提供されます。したがって、クラスターをどこに展開する場合でも、一貫した管理とアプリケーションを容易にするために、共同ユーザー ID を制御する必要があります。
6. アクセス制御: Kubernetes にはユーザーの概念はありませんが、指定されたロールと権限に対して豊富な制御を提供できます。クラスターでは、さまざまなデフォルト ロールのほか、権限セットを指定するカスタム ロールも使用できます。同じ企業内のすべてのクラスターが共通の役割定義とクラスター間の管理方法を使用することが重要です。

上記のセキュリティ対策はそれぞれ個別に使用できますが、複数のクラウド プロバイダーにまたがる場合は、セキュリティ戦略を総合的に検討して計画する必要があります。これは、AquaSec、Twistlock などのセキュリティ ソリューションを、Nirmata や OpenShift などのプラットフォームと組み合わせて使用​​することで実現できます。

5. 集中アプリケーション管理

セキュリティと同様に、Kubernetes クラスター上のさまざまなアプリケーションを管理するには、集中化された一貫性のあるソリューションも必要です。 Kubernetes は、さまざまなアプリケーションを定義および操作するために使用できる完全な構成要素のセットを提供します。アプリケーションに関するいくつかの概念が組み込まれているため、さまざまなアプリケーション タイプを柔軟にサポートし、Kubernetes 上でさまざまな方法でさまざまなアプリケーション プラットフォームを構築できます。

もちろん、Kubernetes アプリケーション管理プラットフォームもいくつかの共通のプロパティと機能を提供します。 Kubernetes ワークロードの集中アプリケーション管理を実装する際に考慮すべき事項は次のとおりです。

アプリケーションのモデリングと定義

ユーザーはアプリケーションのコンポーネントを定義し、既存のコンポーネントに基づいて新しいアプリケーションを作成する必要があります。ユーザーは、Kubernetes の宣言的な性質を通じて、システムのターゲット状態を定義できます。 Kubernetes ワークロード API は、リソースの望ましい状態を定義するためのいくつかの構成要素を提供します。

たとえば、デプロイメントを使用してステートレスなワークロード コンポーネントをモデル化できます。これらの定義は通常、YAML または JSON マニフェストのセットとして記述されます。もちろん、開発者は Git などのバージョン管理システム (VCS) を使用してこれらのリストを整理および管理することもできます。

開発者はアプリケーション マニフェストの一部を定義および管理するだけでよく、運用チームは残りの部分の運用ポリシーと特定の運用環境を指定できます。したがって、アプリケーション マニフェストは、デプロイと更新の前に動的に生成されるパイプラインとして理解できます。

Helm は、Kubernetes のパッケージ管理を支援するツールです。アプリケーションのグループ化、バージョン管理、展開、更新が簡単になります。 Kubernetes アプリケーション プラットフォームは、開発と運用のさまざまな観点からアプリケーション マニフェストと Helm Charts をモデル化、整理、構築するための簡単な方法を提供する必要があります。プラットフォームは、一般的なエラーを早期に検出するためにさまざまな定義の検証を提供するとともに、それらのアプリケーションの定義を簡単に再利用できる方法も提供する必要があります。

アプリケーションランタイム環境管理

アプリケーションがモデル化され、検証されたら、クラスターにデプロイする必要があります。私たちの最終的な目標は、これらのクラスターをさまざまなワークロードで再利用して、効率を向上させ、コストを節約することです。したがって、アプリケーションのランタイム環境をクラスターから分離し、共通のポリシーと制御を環境に適用するのが最適です。

Kubernetes では名前空間とネットワーク ポリシーを使用して仮想クラスターを作成できるため、Kubernetes アプリケーション プラットフォームではこれらの構造を簡単に活用して、論理的なセグメンテーションと分離、およびリソース制御を備えた環境を作成できるはずです。

変更管理

ほとんどの場合、ランタイム環境は永続的であるため、制御された方法で変更する必要があります。これらの変更は、多くの場合、ビルド システムまたは配信パイプラインの上流環境から発生します。

Kubernetes アプリケーション プラットフォームでは、CI/CD (継続的インテグレーションと継続的デリバリー) ツールのさまざまな統合を提供し、外部リポジトリへの変更を監視する必要があります。変更が検出されると、さまざまな環境の変更管理戦略に従って検証および処理される必要があります。もちろん、ユーザーは変更を確認して承認したり、自動更新プロセスに完全に依存したりすることもできます。

アプリケーション監視

さまざまなアプリケーションが複数の環境とさまざまなクラスターで実行されます。監視の観点からは、アプリケーション インスタンスに集中できるように、渡されるメッセージのノイズを除去する方法を見つける必要があります。したがって、アプリケーションのメトリック、状態、イベントをランタイム環境のファブリックに関連付ける必要があります。同時に、Kubernetes アプリケーション プラットフォームでは、監視と自動化されたきめ細かいラベル付けを統合して、ユーザーがあらゆる環境のアプリケーション インスタンスを詳細に把握できるようにする必要があります。

アプリケーションログ

監視と同様に、ログ データもアプリケーション定義をオペレーティング環境情報に関連付け、任意のアプリケーション コンポーネントからアクセスできるようにする必要があります。 Kubernetes アプリケーション プラットフォームは、実行中のさまざまなコンポーネントからのログをストリーミングおよび集約できる必要があります。集中ログ システムを使用する場合は、アプリケーションにタグを付けて、さまざまなアプリケーションや環境からのログを分離するとともに、チームやユーザー間でのアクセス管理を可能にする必要があります。

アラートと通知

サービス レベル管理を実現するには、メトリック値、状態の変化、さまざまな条件に基づいてアラートをカスタマイズできる必要があります。同様に、関連性を使用して、即時の対応が必要なアラートと遅延できるアラートを区別することもできます。

たとえば、同じアプリケーションが複数の環境 (開発およびテスト、ステージング、運用環境など) にデプロイされ、実行される場合、運用ワークロードでのみトリガーされるアラート ルールを定義できる必要があります。 Kubernetes アプリケーション プラットフォームは、きめ細かいアラート ルールの定義と管理を提供するために、環境とアプリケーションを認識する必要があります。

リモートアクセス

クラウド サービス環境は動的であるため、コンテナーはこのダイナミズムを新たなレベルに引き上げます。したがって、問題が検出されて報告されると、システム内の影響を受けるコンポーネントに迅速にアクセスできる必要があります。 Kubernetes アプリケーション プラットフォームは、VPN や SSH を介してさまざまなクラウド サービスのインスタンスにアクセスすることなく、実行中のコンテナーでシェルを起動し、コンテナーの動作環境に関する詳細情報にアクセスする方法を提供する必要があります。

インシデント管理

通常、Kubernetes アプリケーションでは、コンテナが終了して再起動することがあります。この終了は、通常のワークフロー (アップグレードなど) の一部である場合もあれば、メモリ不足などのエラーによって発生する場合もあります。 Kubernetes アプリケーション プラットフォームは、オフライン分析とトラブルシューティングを実行できるように、障害を識別し、障害の詳細情報をすべて取得できる必要があります。

要約する

コンテナと Kubernetes により、企業は業界のベストプラクティスの共通セットを活用して、複数のクラウド サービスにわたってアプリケーションを運用および管理できるようになります。すべての主要なクラウド サービス プロバイダーとアプリケーション プラットフォームは、Kubernetes をサポートすることを約束しています。その中には、「開発者がコード成果物を提供し、プラットフォームが残りの処理を処理する」というモデルに基づく Platform-as-a-Service (PaaS) ソリューションがあります。 「開発者がコンテナイメージを提供し、プラットフォームが残りの処理を処理する」というモデルに基づく Container-as-a-Service (CaaS) ソリューションもあります。また、「開発者は機能を提供するだけで、残りはプラットフォームが処理する」というモデルに基づく Functions-as-a-Service (FaaS) ソリューションもあります。 Kubernetes は新しいクラウドネイティブ オペレーティング システムになったと言えます。

したがって、複数のクラウド サービス モデル向けの Kubernetes 戦略を策定する場合、企業はインフラストラクチャ サービスをどのように使用するか、Kubernetes コンポーネントのバージョンをどのように管理するか、Kubernetes クラスターをどのように設計および管理するか、共通のセキュリティ レイヤーをどのように定義するか、アプリケーションをどのように管理するかを慎重に検討する必要があります。

原題: マルチクラウドKubernetesのベストプラクティス、著者: Jim Bugwadia

[51CTOによる翻訳。パートナーサイトに転載する場合は、元の翻訳者と出典を51CTO.comとして明記してください。