Kubernetesを使用した複数の環境（ステージング、QA、本番など）

複数の環境（QA、ステージング、本番、開発など）を管理するためのK8Sの良い習慣とは何ですか？

例として、チームがフロントエンドアプリケーションとともにいくつかのAPIをデプロイする必要がある製品に取り組んでいるとしましょう。通常、これには少なくとも2つの環境が必要です。

• ステージング：クライアントにリリースする前の反復/テストおよび検証用
• 本番：クライアントがアクセスできる環境。安定した十分にテストされた機能が含まれている必要があります。

では、チームがKubernetesを使用していると仮定すると、これらの環境をホストするための良い方法は何でしょうか？これまでに2つのオプションを検討しました。

1. 各環境にK8sクラスターを使用する
2. K8sクラスターを1つだけ使用し、異なる名前空間に保持します。

（1）人為的なミスや生産環境を危険にさらす可能性のある機械の故障のリスクを最小限に抑えるため、最も安全なオプションのようです。ただし、これには、より多くのマスターマシンのコストと、より多くのインフラストラクチャ管理のコストが伴います。

（2）クラスターが1つしかないため、インフラストラクチャとデプロイメント管理が簡素化されるように見えますが、次のようないくつかの質問が生じます。

• 人的ミスが本番環境に影響を与える可能性があることをどのように確認しますか？
• ステージング環境の高負荷によって本番環境のパフォーマンスが低下しないようにするにはどうすればよいですか？

他にも懸念事項がある可能性があるため、StackOverflowのK8sコミュニティに連絡して、人々がこの種の課題にどのように対処しているかについて理解を深めています。

複数のクラスターに関する考慮事項

Vadim Eisenberg（IBM / Istio）からのこのブログ投稿をご覧ください。チェックリスト：複数のKubernetesクラスターを使用することの長所と短所、およびそれらの間でワークロードを分散する方法。

長所/短所のいくつかを強調したいと思います：

複数のクラスターがある理由

• 本番/開発/テストの分離：特に、サービスメッシュや他のクラスターソフトウェアの新しいバージョンのKubernetesをテストする場合
• コンプライアンス：一部の規制によると、一部のアプリケーションは個別のクラスター/個別のVPNで実行する必要があります
• セキュリティのためのより良い分離
• クラウド/オンプレミス：オンプレミスサービス間で負荷を分割する

単一のクラスターを持つ理由

• セットアップ、メンテナンス、管理のオーバーヘッドを削減
• 使用率を向上させる
• コスト削減

あまり高価ではない環境で、平均的なメンテナンスを行いながら、本番アプリケーションのセキュリティの分離を保証することを考えると、次のことをお勧めします。

• DEVおよびSTAGING用の1つのクラスター（名前空間によって分離され、場合によっては、Calicoのようなネットワークポリシーを使用して分離されます）
• PROD用の1つのクラスター

環境パリティ

開発、ステージング、プロダクションをできる限り同じに保つことは良い習慣です：

バッキングサービス間の違いは、小さな非互換性が生じ、開発またはステージングで機能してテストに合格したコードが本番環境で失敗することを意味します。これらのタイプのエラーは、継続的な展開を阻害する摩擦を引き起こします。

強力なCI / CDツールをhelmと組み合わせます。helm値の柔軟性を使用して、デフォルトの構成を設定できます。環境によって異なる構成をオーバーライドするだけです。

AutoDevopsを備えたGitLab CI / CDは Kubernetesと強力に統合されており、helmサポートを使用して複数のKubernetesクラスターを管理できます。

複数のクラスターの管理 （kubectl対話）

複数のKubernetesクラスターを使用している場合、コンテキストをめちゃくちゃにしてkubectl、間違ったクラスターで実行するのは簡単です。さらに、Kubernetesにはクライアント（）とサーバー（kubernetesマスター）の間のバージョンの不一致に対する制限があるためkubectl、適切なコンテキストでコマンドを実行しても、適切なクライアントバージョンを実行する必要はありません。

これを克服するには：

• asdf複数のkubectlバージョンを管理するために使用します
• KUBECONFIG複数のkubeconfigファイル間で変更するように環境変数を設定する
• kube-ps1現在のコンテキスト/名前空間を追跡するために使用します
• kubectxとkubensを使用して、クラスター/名前空間間ですばやく変更する
• エイリアスを使用してそれらをすべて組み合わせる

これを実現する方法を例示する記事があります。複数のKubernetesクラスターで異なるkubectlバージョンを使用する

また、以下の記事もお勧めします。

• Ahmet Alp BalkanによるKUBECONFIGファイルの習得（Googleエンジニア）
• ZalandoがHenning Jacobsによって140以上のKubernetesクラスターを管理する方法（Zalando Tech）

開発とDockerイメージの作成には、必ず別のクラスターを使用して、ステージング/本番クラスターを安全にロックダウンできるようにします。個別のクラスターを使用するかどうかstaging + productionは、リスク/コストに基づいて決定する必要があります。クラスターを個別に維持することで、staging影響を回避できproductionます。

また、GitOpsを使用して、環境間でアプリのバージョンを宣伝することを強くお勧めします。

人的エラーを最小限に抑えるために、CI / CDとプロモーションのためにできる限り自動化を検討することをお勧めします。

ここだGitOps使用Kubernetes上の複数の環境でCI / CDを自動化する方法のデモジェンキンスXが最もkubernetesクラスタをサポートしているもののGKEに生きて行われたプル要求に環境やプレビュー環境間のプロモーションのためには、

各シナリオで何をテストするかによって異なります。一般に、不必要な副作用（パフォーマンスへの影響など）を回避するために、運用クラスターでテストシナリオを実行しないようにします。

本番システムを正確に模倣するステージングシステムを使用してテストする場合は、完全なクラスターの正確なレプリカを起動し、テストが完了してデプロイメントを本番環境に移動した後でシャットダウンすることをお勧めします。

アプリケーションの展開を可能にするステージングシステムのテストが目的である場合は、小規模なステージングクラスターを永続的に実行し、継続的なテストに必要なように展開を縮小します（展開の縮小版も使用）。

異なるクラスターを制御するには、クラスターの一部ではないが、クラスターの起動とシャットダウン、デプロイメント作業の実行、テストの開始などに使用される個別のci / cdマシンを用意することをお勧めします。これにより、セットアップとシャットダウンが可能になります自動テストシナリオの一部としてのクラスター。

運用クラスターをステージングクラスターから遠ざけることで、運用サービスに影響を与える潜在的なエラーのリスクが軽減されることは明らかです。ただし、少なくとも次のものが必要になるため、インフラストラクチャ/構成管理のコストが高くなります。

• 本番クラスター用に少なくとも3つのマスターとステージング用に少なくとも1つのマスター
• 2 CI / CDシステムに追加されるKubectl構成ファイル

また、複数の環境が存在する可能性があることも忘れないでください。たとえば、少なくとも3つの環境がある企業で働いています。

• QA：毎日のデプロイを行った場所と、クライアントにリリースする前に内部QAを行った場所）
• クライアントQA：クライアントが本番環境にリリースする前に環境を検証できるように、本番環境にデプロイする前にデプロイした場所）
• 本番：本番サービスがデプロイされる場所。

エフェメラル/オンデマンドのクラスターは理にかなっていると思いますが、特定のユースケース（ロード/パフォーマンステストまたは非常に「大きな」統合/エンドツーエンドのテスト）に限られますが、より永続的でスティッキーな環境ではオーバーヘッドが削減される可能性がありますそれらを単一のクラスター内で実行する。

私が説明したようなシナリオに使用されているパターンを確認するために、k8sコミュニティに連絡したいと思います。

コンプライアンスまたは他の要件で特に指示されていない限り、私はすべての環境で単一のクラスターを使用します。このアプローチでは、注意点は次のとおりです。

• ラベルを使用して、環境ごとにノードもグループ化するようにしてください。次に、nodeSelectoronリソースを使用して、それらが特定のノードで実行されていることを確認できます。これにより、（過剰な）リソース消費が環境間でこぼれる可能性が低くなります。

• 名前空間をサブネットとして扱い、デフォルトですべての下り/上りトラフィックを禁止します。https://kubernetes.io/docs/concepts/services-networking/network-policies/を参照してください。

• サービスアカウントを管理するための戦略があります。ClusterRoleBindingsクラスターが複数の環境をホストしている場合は、別のものを意味します。

• Helmなどのツールを使用する場合は、精査してください。一部のグラフでは、クラスター全体の権限を持つサービスアカウントを露骨にインストールしていますが、サービスアカウントへの権限は、それらが存在する環境に限定する必要があります。

複数のクラスターを使用することは、本番と「非本番」の間の強力な分離を実施するための非常に一般的な基準です。

その精神で、GitLab 13.2（2020年7月）には以下が含まれることに注意してください。

Coreでの複数のKubernetesクラスターのデプロイ

GitLabを使用して複数のKubernetesクラスターをGitLabでデプロイするには、以前はプレミアムライセンスが必要でした。
私たちのコミュニティが話し、耳を傾けました。複数のクラスターへのデプロイは、個々の貢献者にとっても有用です。
フィードバックに基づいて、GitLab 13.2以降、Coreの複数のグループおよびプロジェクトクラスターにデプロイできます。

ドキュメントと問題を参照してください/

単一のクラスターを実行することは、オーバーヘッドとモニターを削減するので意味があると思います。ただし、ネットワークポリシーとアクセス制御を適切に配置する必要があります。

ネットワークポリシー-開発/ QA環境のワークロードが製品/ステージングストアとやり取りすることを禁止します。

アクセス制御-ClusterRoles、ロールなどを使用して、さまざまな環境リソースにアクセスできるユーザー。