Kubernetes を本番環境で 2 年間使用して学んだ教訓

約 2 年前、私たちは EC2 にアプリケーションをデプロイするための Ansible ベースの構成管理セットアップをやめ、Kubernetes を使用してアプリケーションをコンテナ化およびオーケストレーションすることに移行することを決定しました。当社ではインフラストラクチャの大部分を Kubernetes に移行しました。これは大規模な取り組みであり、ハイブリッド インフラストラクチャを実行する技術的な課題から、移行の大部分を完了すること、まったく新しい運用モデルについてチーム全体をトレーニングすることまで、独自の課題が伴いました。

この投稿では、私たちの経験を振り返り、この旅で学んだことを皆さんと共有し、皆さんがより良い決断を下し、成功の可能性を高めるお手伝いをしたいと思います。

[[383951]]

Kubernetesに移行する理由を明確に述べる

サーバーレスやコンテナ関連のものはすべて素晴らしいです。新しいビジネスを立ち上げ、すべてをゼロから構築する場合は、帯域幅（または帯域幅がない）とテクノロジーをプロビジョニングおよび構成するスキルがあれば、必ずコンテナを使用してアプリケーションをデプロイし、Kubernetes を使用してオーケストレーションしてください。 Kubernetes を操作し、Kubernetes 上にアプリケーションをデプロイします。

Kubernetes 操作を EKS、GKE、AKS などのマネージド Kubernetes サービスにオフロードする場合でも、Kubernetes 上でアプリケーションを適切にデプロイして操作するには学習が必要です。開発チームはこの課題に取り組む必要があります。チームが DevOps の哲学に従う場合にのみ、多くのメリットを実現できます。他のチームによって開発されたアプリケーションのマニフェストを作成する中央システム管理チームがある場合、DevOps の観点から見ると、Kubernetes のメリットは少なくなると私たちは個人的に考えています。もちろん、Kubernetes を選択することで、コスト、実験の高速化、自動スケーリングの高速化、弾力性など、他にも多くのメリットが得られます。

すでにクラウド VM またはその他の PaaS にデプロイしている場合、既存のインフラストラクチャから Kubernetes への移行を実際に検討する必要があるのはなぜでしょうか? Kubernetes が問題に対する唯一の解決策であると確信していますか?既存のインフラストラクチャを Kubernetes に移行するのは困難な作業であるため、その動機を明確にする必要があります。

この点に関して私たちはいくつかの間違いを犯しました。 Kubernetes に移行した主な理由は、長年にわたって多くのアーキテクチャを悩ませてきたマイクロサービスを迅速に再構築するのに役立つ継続的インテグレーション インフラストラクチャを構築することでした。ほとんどの新機能では複数のコード ベースに触れる必要があるため、それらすべてを一緒に開発してテストすると、作業が遅くなります。私たちは、誰が「共有ステージング環境」を取得するかを調整する必要なく、開発とテストのサイクルをスピードアップするために、すべての開発者とすべての変更に対して統合された環境が必要であると考えています。

> すべてのマイクロサービスを含む新しい統合環境をプロビジョニングし、自動テストを実行する継続的インテグレーションパイプラインの1つ

今日は素晴らしい仕事をしました。本日、Kubernetes 上の統合環境で 8 分で 21 個のマイクロサービスをプロビジョニングしました。私たちが独自に開発したツールを使用すれば、どの開発者でもこれを実行できます。これら 21 個のマイクロサービスに対して作成されたすべてのプル リクエストに対して、その環境のサブセットも提供されます。テスト サイクル全体 (環境のプロビジョニングとテストの実行) には 12 分もかかりません。長く感じるかもしれませんが、現在のアーキテクチャの混乱に大きな変化を加えることを防ぐことができます。

> 継続的インテグレーションパイプライン実行レポート

わーい！これらすべてを構築するには何が必要だったのでしょうか?約1年半かかりました。それは価値があるでしょうか？

追加のツールやテレメトリを構築し、各アプリケーションを再デプロイすることで、この複雑な CI セットアップを安定させるのに、ほぼ 1.5 年かかりました。開発と本番環境の整合性を実現するには、これらすべてのマイクロサービスを本番環境にデプロイする必要がありました。そうしないと、インフラストラクチャとデプロイメントの設定に差異があるため、開発者にとってアプリケーションの正当性が証明されにくくなり、開発者にとって選択の悪夢となっていたでしょう。

この件に関して私たちは異なる見解を持っています。振り返ってみると、開発と製品の同等性を実現するためにすべてのマイクロサービスを本番環境にプッシュする複雑さによって、継続的インテグレーションの高速化の課題がより複雑かつ困難になったため、継続的インテグレーションの問題の解決がさらに困難になったと考えられます。 Kubernetes 以前は、インフラストラクチャのプロビジョニング、構成管理、およびデプロイメントに、Hashicorp Consul および Vault と連携した Ansible を使用していました。遅い？はい、もちろんです。しかし、Consul 経由でサービス検出を導入し、Ansible デプロイメントを最適化することで、比較的短期間で目標に十分近づくことができると考えました。

Kubernetes に移行すべきでしょうか?はい、もちろんです。 Kubernetes を使用すると、サービス検出、コスト管理の改善、弾力性、ガバナンス、クラウド インフラストラクチャ インフラストラクチャの抽象化など、多くの利点があります。今日、私たちはこれらすべての恩恵を享受しています。しかし、それは私たちが始めたときの主な目的ではなかったし、自分の思い通りにしようとしてストレスや苦痛を味わう必要はないのかもしれません。

私たちにとっての大きな収穫は、Kubernetes を別の、より抵抗の少ない方法で導入できたかもしれないということでした。私たちは、Kubernetes を導入することにしました。それが私たちが持つ唯一のソリューションであり、他の選択肢を評価することすら気にしていませんでした。

このブログ記事で説明するように、Kubernetes への移行と運用は、クラウド VM またはベアメタルへのデプロイとは異なります。クラウド エンジニアリング チームと開発チームには学習曲線があります。あなたのチームにとって試してみる価値があります。しかし、今あなたはこれをする必要があります。明確に答えるように努めなければなりません。

Kubernetesをそのまま使うだけでは、ほとんどの人にとって十分ではない

多くの人が Kubernetes を PaaS ソリューションとして混同していますが、これは PaaS ソリューションではありません。 PaaS ソリューションを構築するためのプラットフォームです。 OpenShift はその一例です。

Kubernetes をそのまま使用するだけでは、ほとんどの人にとって十分ではありません。学習と探索に最適な遊び場です。しかし、開発者にとってより意味のあるものにするためには、おそらく、さらに多くのインフラストラクチャ コンポーネントを上に配置し、それらをアプリケーションのソリューションとしてうまく結び付ける必要があるでしょう。通常、追加のインフラストラクチャ コンポーネントとポリシーを含む Kubernetes のバンドルは、オンプレミス Kubernetes プラットフォームと呼ばれます。これは非常に便利なパラダイムであり、Kubernetes を拡張する方法はいくつかあります。

メトリクス、ログ、サービス検出、分散トレース、構成とシークレットの管理、CI/CD、ローカル開発エクスペリエンス、カスタム メトリクスの自動スケーリングなど、すべてに注意を払い、決定を下す必要があります。これらは私たちが求めているもののほんの一部です。確かに、下すべき決定や構築すべきインフラはまだまだたくさんあります。重要な側面は、開発者が Kubernetes のリソースとインベントリをどのように使用するかです。これについては、このブログ投稿の後半で詳しく説明します。

ここに私たちの決定と理由のいくつかを挙げます。

索引

最終的にプロメテウスに決めました。 Prometheus は事実上のメトリクス インフラストラクチャです。 CNCF と Kubernetes はそれを気に入っています。 Grafana エコシステムで非常にうまく機能します。そして私たちはGrafanaが大好きです!唯一の問題は、InfluxDB を使用していることです。私たちは、InfluxDB から移行し、Prometheus に全面的にコミットすることを決定しました。

ログ

私たちにとって、伐採は常に大きな問題でした。私たちはELKを使用して安定したログ記録プラットフォームを作成するために一生懸命取り組んできました。 ELK には、私たちのチームが実際には使用できない機能があることがわかりました。これらの機能には料金がかかります。さらに、Elasticsearch をログ記録に使用すると、高価なログ記録ソリューションになってしまうという固有の課題があると考えています。 Grafana によって Loki が完成しました。とても簡単です。私たちのチームのニーズを満たすために必要な機能が備わっています。非常にコスト効率が良いです。しかし最も重要なのは、クエリ言語が PromQL に非常に似ているため、優れた UX を備えていることです。また、Grafana との連携も優れています。これにより、メトリックの監視とログ記録のエクスペリエンス全体を単一のユーザー インターフェイスに集中させることができます。

メトリクスと対応するログを並べて視覚化した Grafana ダッシュボードの例

構成とキー

ほとんどの記事では、Kubernetes の configmap と secret オブジェクトが使用されています。私たちが学んだことは、これで始めることはできるが、私たちのユースケースでは十分ではないということだ。既存のサービスで configmap を使用するにはコストがかかります。 Configmaps は何らかの方法でポッドにインストールできますが、環境変数を使用するのが最も一般的な方法です。 Puppet、Chef、Ansible などの構成管理ツールによって提供されるファイルから構成を読み取るレガシー マイクロサービスが多数ある場合は、環境変数から読み取るために、すべてのコードベースにわたって構成処理をやり直す必要があります。合理的な状況下でこれを行う十分な理由は見つかりませんでした。さらに、構成やシークレットが変更された場合は、パッチを適用してデプロイメントを再デプロイする必要があります。これは、kubectl コマンドの追加の命令型オーケストレーションになります。

> アシフ・ジャマルによるデザイン

これらすべてを回避するために、構成管理には Consul、Vault、および Consul テンプレートを使用することにしました。現在、Consul テンプレートを init コンテナとして実行しており、Pod 内のサイドカーとして実行して、Consul での構成変更を監視し、Vault 内の期限切れのキーを更新し、アプリケーション プロセスを適切にリロードできるようにする予定です。

CI/CD

Kubernetes に移行する前は、Jenkins を使用していました。 Kubernetes に移行した後、私たちは Jenkins を使い続けることにしました。これまでの経験から、Jenkins はクラウドネイティブ インフラストラクチャを扱うための最適なソリューションではないことがわかりました。すべてを機能させるために、Python、Bash、Docker、スクリプト化/宣言型の Jenkins パイプラインを使用して多くの作業を行っています。これらのツールとパイプラインの構築と維持にはコストがかかり始めます。現在、新しい CI/CD プラットフォームとして Tekton と Argo ワークフローを検討しています。 Jenkins X、Screwdriver、Keptn など、CI/CD 環境でさらに多くのオプションを検討できます。

開発経験

開発ワークフローで Kubernetes を使用する方法は多数あります。私たちは主に、Telepresence.io と Skaffold の 2 つのオプションに絞り込みました。 Skaffold はローカルの変更を監視し、それを Kubernetes クラスターに継続的にデプロイできます。一方、Telepresence を使用すると、Kubernetes クラスターとの透過的なネットワーク プロキシを確立しながらサービスをローカルで実行できるため、ローカル サービスはクラスターにデプロイされているかのように Kubernetes 内の他のサービスと通信できます。それは個人的な意見と好みの問題です。 1つのツールに決めるのは難しいです。現在、私たちは主にテレプレゼンスの実験を行っていますが、Skaffold が私たちにとってより良いツールになる可能性を諦めたわけではありません。どちらを使用するかは時間が経てばわかるでしょう。あるいは、両方を使用するかもしれません。 Draft のような、言及する価値のある他のソリューションもあります。

分散トレース

分散トレースはまだありません。しかし、私たちは近いうちにこの分野に投資する予定です。ロギングと同様に、Grafana の次にメトリクスを、ロギングの次に分散トレースを利用できるようにして、開発チームにより統合された可観測性エクスペリエンスを提供したいと考えています。

アプリケーションのパッケージ化、展開、ツール

Kubernetes の重要な側面は、開発者がクラスターと対話し、ワークロードをデプロイする方法を考慮することです。私たちは物事をシンプルかつスケーラブルに保ちたいと考えています。開発者がアプリケーションをデプロイおよび管理する方法として、Kustomize、Skaffold、およびいくつかのネイティブ CRD が採用されつつあります。そうは言っても、オープンソースであり、オープン スタンダードに基づいて構築されている限り、どのチームもクラスターと対話するために任意のツールを自由に使用できます。

Kubernetesクラスタの運用は難しい

当社は主に AWS のシンガポールリージョンで事業を展開しています。私たちが Kubernetes の取り組みを始めたとき、EKS サービスはまだシンガポール リージョンで利用できませんでした。したがって、kops を使用して EC2 上に独自の Kubernetes クラスターをセットアップする必要があります。

基本的なクラスターの設定はそれほど難しくないかもしれません。最初のクラスターを 1 週間以内にセットアップすることができました。ほとんどの問題は、ワークロードのデプロイを開始したときに発生します。クラスター オートスケーラーの調整から、適切なタイミングでのリソースのプロビジョニング、適切なパフォーマンスを実現するためのネットワークの正しい構成まで、自分で調査して構成する必要があります。ほとんどの場合、デフォルト設定は機能しません (少なくともその時点では機能しませんでした)。

私たちが学んだことは、Kubernetes の運用は複雑だということです。可動部分がたくさんあります。また、Kubernetes の操作方法を学ぶことは、おそらくビジネスの中心ではありません。可能な場合は、クラウド サービス プロバイダー (EKS、GKE、AKS) にオフロードします。これを自分でやっても価値はありません。

アップグレードを検討する必要がある

Kubernetes は複雑であり、マネージド サービスを使用する場合でも、アップグレードが必ずしもスムーズに進むとは限りません。

マネージド Kubernetes サービスを使用する場合でも、早い段階でインフラストラクチャ アズ コード セットアップに投資して、将来の災害復旧とアップグレードのプロセスを比較的容易にし、災害発生時に迅速な復旧を可能にします。

よろしければ、GitOps をプッシュしてみてください。それができない場合は、手動の手順を最小限に抑えることから始めるのが良いでしょう。私たちは、eksctl、terraform、およびクラスター構成マニフェスト（プラットフォーム サービスのマニフェストを含む）を組み合わせて、「Grofers Kubernetes プラットフォーム」と呼ばれるものをセットアップします。セットアップとデプロイメントのプロセスをよりシンプルかつ繰り返し可能にするために、新しいクラスターをセットアップし、既存のクラスターに変更をデプロイするための自動化されたパイプラインを構築しました。

リソース要求と制限

移行を開始した後、誤った構成が原因でクラスターに多くのパフォーマンスと機能の問題が見られました。その結果、リソース制限を平滑化するために、リソース要求と制限に多くのバッファが追加され、パフォーマンスが低下します。

最も初期の観察結果の 1 つは、ノード上のメモリ制約によるエビクションでした。その理由は、リソース要求に比べてリソース制限が高すぎるためです。トラフィックが急増すると、メモリ消費量の増加によりノード上のメモリが飽和し、さらにポッドの排除が発生する可能性があります。

私たちが学んだことは、リソース要求を十分に高く保ちつつも、トラフィックが少ない時間帯にリソースが無駄にならないように高く保ち、リソース制限をリソース要求に比較的近い値に保ち、ノードのメモリ負荷によってポッドが排除されることなくトラフィックの急増に余裕を持たせることです。制限がリクエストにどれだけ近づくかは、トラフィック パターンによって異なります。

これは、非本番環境 (開発、ステージング、CI など) には適していません。これらの環境ではトラフィックの急増は発生しません。理論的には、CPU 要求をゼロに設定し、コンテナの CPU 制限を十分に高く設定すると、無制限の数のコンテナを実行できます。コンテナが CPU を大量に使用し始めると、スロットルがかけられます。メモリ要求と制限についても同様のことが可能です。ただし、メモリ制限に達したときの動作は CPU とは異なります。設定されたメモリ制限を超えるメモリを使用すると、コンテナは OOM によって強制終了され、コンテナが再起動されます。メモリ制限が異常に高い場合 (ノードの容量よりも高いなど)、メモリは引き続き使用できますが、ノードの空きメモリが少なくなると、最終的にスケジューラはポッドの削除を開始します。

非本番環境では、リソース要求を非常に低く抑え、リソース制限を非常に高くすることで、可能な限り安全にリソースを過剰に割り当てます。この場合、制限要因はメモリです。つまり、メモリ要求がどれだけ低く、メモリ制限がどれだけ高くても、ポッドの削除は、ノードでスケジュールされているすべてのコンテナによって使用されるメモリの合計の関数になります。

セキュリティとガバナンス

Kubernetes は、開発者向けにクラウド プラットフォームのロックを解除し、開発者の独立性を高め、DevOps 文化を促進することを目的としています。プラットフォームを開発者に開放し、クラウド エンジニアリング チーム (またはシステム管理者) の介入を減らし、開発チームを独立させることが重要な目標の 1 つになるはずです。

場合によっては、この独立性が重大なリスクをもたらすことがあります。たとえば、EKS で LoadBalancer タイプのサービスを使用すると、デフォルトで ELB に面したパブリック ネットワークが構成されます。特定の注釈を追加すると、内部 ELB がプロビジョニングされるようになります。私たちは早い段階でいくつかの間違いを犯しました。

当社では、Open Policy Agent を使用して、さまざまなセキュリティ リスクを軽減し、コスト、セキュリティ、技術的負債に関連するリスクを削減しています。

Open Policy Agent を導入して適切なコントロールを構築することで、変更管理プロセス全体を自動化し、開発者向けの適切なセーフティ ネットを構築することができました。 Open Policy Agent を使用すると、前述したようなシナリオを制限できます。つまり、開発者が誤ってパブリック ELB を作成しないように、正しいアノテーションが存在しない限り、サービス オブジェクトの作成を制限できます。

料金

移行後、コスト面で大きなメリットが得られました。ただし、すべてのメリットがすぐに得られるわけではありません。

注: 最近のコスト最適化の取り組みについて、より詳細な投稿を作成中です。ラムダに注意してください。

リソース容量の有効活用

これは最も明白なものです。現在、当社のインフラストラクチャは、以前よりもはるかに少ないコンピューティング、メモリ、ストレージで構成されています。コンテナ/プロセスのパッケージ化の改善による容量使用率の向上に加えて、プロセスの可観測性 (メトリック、ログ) などの共有サービスを以前よりも有効に活用できるようになりました。

しかし、当初は移行中に多くのリソースを無駄にしていました。自社管理の Kubernetes クラスターを適切に調整できないためにパフォーマンス上の問題が大量に発生したため、コンピューティングやメモリの不足による障害やパフォーマンス上の問題の可能性を減らすための保険のような役割として、バッファーとして Pod に大量のリソースが必要になりました。

リソース バッファーが大きいため、インフラストラクチャ コストが高くなることが大きな問題となります。 Kubernetes では、容量使用率のメリットが期待通りに得られていません。 EKS に移行した後、それがもたらす安定性を観察して自信が深まり、リソース要件を修正し、リソースの無駄を大幅に削減するために必要な手順を実行することができました。

例

Kubernetes でスポット インスタンスを使用する方が、raw VM でスポット インスタンスを使用するよりもはるかに簡単です。 VM を使用すると、スポット インスタンスを自分で管理することもできますが、これは少し複雑で、アプリケーションの適切な稼働時間を保証できない可能性があります。または、SpotInst などのサービスを使用することもできます。同じことが Kubernetes にも当てはまりますが、Kubernetes がもたらすリソース効率により、バッファーを保持するのに十分な余裕が生まれ、クラスター内のいくつかのインスタンスが中断された場合でも、それらのインスタンスにスケジュールされているコンテナーを別の場所にすぐに再スケジュールできます。現場での停止を効果的に管理するためのオプションがあります。

スポットインスタンスにより、多額の費用を節約できました。現在、当社の Kubernetes クラスターのすべてがスポット インスタンスで実行されており、運用中の Kubernetes クラスターの 99% がリザーブド インスタンス、Savings Plans、スポット インスタンスでカバーされています。

最適化の次のステップは、スポットインスタンスで本番クラスター全体を実行する方法です。このトピックの詳細については、別のブログ投稿で説明します。

ELB マージ

Ingress を使用してステージ環境に ELB を統合し、ELB の固定コストを大幅に削減しました。コード間の開発/本番環境の相違を回避するために、ステージ クラスター内の ingress オブジェクトとともに LoadBalancer タイプのサービスを NodePort タイプのサービスに変更するコントローラーを実装することにしました。

Nginx Ingress への移行は私たちにとっては比較的簡単で、コントローラー アプローチのおかげで大量の変更は必要ありませんでした。本番環境でも Ingress を使用すれば、さらにコストを節約できます。これは簡単な変化ではありません。本番環境へのイングレスを正しく構成する際には、いくつかの側面を考慮する必要があり、セキュリティと API 管理の観点からも考慮する必要があります。これは私たちが近い将来取り組む予定の分野です。

AZ間のデータ転送を増加

インフラストラクチャの支出は大幅に削減されましたが、可用性ゾーン間のデータ転送というインフラストラクチャ コストの一部は依然として増加していました。

ポッドは任意のノードにデプロイできます。クラスター全体にポッドを分散する方法を制御したとしても、あるサービスのポッドが同じ AZ 内の別のサービスのポッドと通信してアベイラビリティーゾーン間のデータ転送を削減するような方法で、サービスが互いを検出する方法を制御する簡単な方法はありません。

多くの調査と他社の同僚との会話を経て、ポッドからターゲット ポッドへのトラフィックのルーティング方法を制御するサービス メッシュを導入することでこれを実現できることがわかりました。可用性ゾーン間でデータを転送するコストを節約するためだけに、サービス メッシュを自分たちで運用するという複雑さを引き受ける準備はできていません。

CRD、オペレーター、コントローラー – 簡素化された操作とより包括的なエクスペリエンスへの一歩

すべての組織には独自のワークフローと運用上の課題があります。私たちにもそれがあります。

Kubernetes との 2 年間の取り組みで、Kubernetes は素晴らしいが、コントローラー、オペレーター、CRD などの機能を使用して日常業務を簡素化し、開発者に統合されたエクスペリエンスを提供すると、さらに優れたものになることを学びました。

私たちは多くのコントローラーとCRDへの投資を開始しました。たとえば、LoadBalancer サービス タイプを Ingress に変換することは、コントローラー アクションです。同様に、新しいサービスが展開されるたびに、コントローラーを使用して DNS プロバイダーに CNAME レコードを自動的に作成します。これらはいくつかの例です。当社には、日常業務を簡素化し、作業負荷を軽減するために社内コントローラーを活用する 5 つの個別のユースケースがあります。

CRDもいくつか構築しました。その 1 つは、どの監視ダッシュボードを使用するかを宣言的に指定することで、Grafana で監視ダッシュボードを生成するために現在広く使用されています。これにより、開発者は監視ダッシュボードをアプリケーション コードベースと一緒に埋め込み、同じワークフロー (kubectl apply -f) を使用してすべてをデプロイできるようになります。 。

コントローラーと CRD の利点を多数実感しています。クラウドベンダーの AWS と緊密に連携してクラスターインフラストラクチャの運用を簡素化したため、開発チームを可能な限り最善の方法でサポートするように設計された「Grofers Kubernetes プラットフォーム」の構築に集中できるようになりました。

元のリンク: https://lambda.grofers.com/learnings-from-two-years-of-kubernetes-in-production-b0ec21aa2814