さまざまなクラウドサービスモードにおける Kubernetes のベストプラクティス

[51CTO.com からのオリジナル記事] この記事では、さまざまなクラウドサービスモデルで Kubernetes クラスターを正常に展開および実行するための主な運用上の難しさやベストプラクティスについて説明します。

2018 年のクラウドコンピューティングステータスレポートによると、現在、企業の 81% が複数のクラウドサービスモデルを使用しています。パブリッククラウドサービス、最新のインフラストラクチャプラットフォーム、パブリッククラウドとプライベートクラウドの継続的な組み合わせを導入することで、規模と容量を迅速かつ柔軟に調整し、顧客に価値をより早く提供できるようになります。

実際、IDCの最新データによると、2018年第1四半期の世界のサーバー出荷台数は前年同期比20.7%増の270万台となり、総収益は38.6%増加し、3四半期連続で2桁の成長を記録しました。

[[236964]]

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

もちろん、上記の利点は一定の複雑さももたらします。コンテナは DevOps 関連の問題を解決しますが、管理が必要な新しい抽象化レイヤーも導入します。

Kubernetes 自体は管理が必要な分散アプリケーションであるため、運用上の問題をすべて解決できるわけではなく、一部の問題しか解決できません。

この記事では、複数のクラウドサービスモデルで Kubernetes クラスターを正常に展開および実行するための主要な運用上の課題とベストプラクティスについて説明します。

一般的に、IT 運用チームは他の複数の社内チーム向けにエンタープライズレベルの Kubernetes 戦略を構築する必要があるというのが私たちの見解です。

最高のインフラストラクチャを使用する

従来のオンプレミスインフラストラクチャプロバイダーと同様に、すべてのクラウドサービスプロバイダーは、ストレージやネットワークなどのサービスを提供できます。

複数のクラウドサービスモデルの戦略を検討する場合、さまざまなベンダーが提供する既存の機能を使用する必要があるかどうかが注目に値します。あるいは抽象化レイヤーが必要です。

どちらのアプローチも可能ですが、抽象化レイヤーを最小限に抑え、ベンダーが提供するソリューションを使用するように注意する必要があります。

たとえば、AWS でオーバーレイネットワークを実行する代わりに、AWS が提供する Kubernetes CNI (Container Network Interface) プラグインを使用して、Kubernetes にネイティブネットワーク機能を提供する方が適切です。

このアプローチでは、セキュリティグループや IAM (翻訳者注: Identity and Access Management) などの他のサービスも使用できます。

独自の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 ソフトウェア適合性 (https://www.cncf.io/certification/software-conformance/) プログラムも提供しています。

企業内で内部使用する場合、実稼働環境では安定したバージョンを使用するのが最適です。ただし、一部のチームでは、GA 前の機能を備えたクラスターが必要になる場合があります。

したがって、最善のアプローチは、チームがさまざまな実績のあるアップストリームバージョンから選択する柔軟性を与えるか、必要に応じて新しいバージョンを試せるようにすることですが、その場合のリスクはチームに任せます。

ポリシーに基づいてクラスタの展開を規制する

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

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

上記の決定はクラスターのインストールごとに実行できますが、クラスターのインストールのテンプレートまたは戦略として記録しておけば、後で再利用するときに効率的です。

たとえば、Terraform スクリプト (https://www.terraform.io/docs/providers/kubernetes/index.html) または Nirmata クラスター戦略 (http://nirmata-documentation.readthedocs.io/en/latest/Clusters.html) を使用できます。

クラスターのインストールが自動化されると、高レベルのワークフローの一部として呼び出すことができます。例: サービスカタログに基づいてセルフサービスプロビジョニング要求を実行します。

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

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

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

上記のセキュリティ対策はそれぞれ個別に使用できますが、複数のクラウドプロバイダーにまたがる場合は、セキュリティ戦略を総合的に検討して計画する必要があります。

これは、AquaSec、Twistlock などのセキュリティソリューションを、Nirmata や OpenShift などのプラットフォームと組み合わせて使用することで実現できます。

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

セキュリティと同様に、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 として明記してください]

<<: クラウドにも独自のネットワークが必要です。 SDNとVPCの存在

>>: ハイブリッドクラウドファイルサービスが企業のファイル問題を解決する方法