デヴォックス英国。 本番環境での Kubernetes: ブルー/グリーン デプロイメント、自動スケーリング、デプロイメントの自動化。 パート2

Kubernetes は、クラスター化された運用環境で Docker コンテナーを実行するための優れたツールです。 ただし、Kubernetes では解決できない問題もあります。 頻繁に運用環境をデプロイする場合は、プロセスのダウンタイムを回避するために完全に自動化された Blue/Green デプロイメントが必要です。また、外部 HTTP リクエストを処理し、SSL オフロードを実行する必要もあります。 これには、ha-proxy などのロード バランサーとの統合が必要です。 もう XNUMX つの課題は、クラウド環境で実行する場合の Kubernetes クラスター自体の半自動スケーリングです (たとえば、夜間にクラスターを部分的にスケールダウンするなど)。

Kubernetes にはこれらの機能がそのままでは備わっていませんが、同様の問題を解決するために使用できる API が提供されています。 Kubernetes クラスターの自動化された Blue/Green デプロイメントとスケーリングのためのツールは、オープンソースに基づいて作成された Cloud RTI プロジェクトの一部として開発されました。

この記事 (ビデオ トランスクリプト) では、Kubernetes を他のオープン ソース コンポーネントとともにセットアップして、本番環境でダウンタイムなしで git コミットからコードを受け入れる本番環境を作成する方法を説明します。

デヴォックス英国。 本番環境での Kubernetes: ブルー/グリーン デプロイメント、自動スケーリング、デプロイメントの自動化。 パート1

したがって、外部からアプリケーションにアクセスできるようになると、自動化の完全なセットアップを開始できます。つまり、git commit を実行できる段階まで自動化を進め、この git commit が本番環境に確実に反映されるようにすることができます。 当然のことながら、これらの手順を実装するとき、展開を実装するときに、ダウンタイムが発生することは望ましくありません。 したがって、Kubernetes の自動化は API から始まります。

Kubernetes は、そのまま使用すれば生産的に使用できるツールではありません。 もちろん、kubectl などを使用してそれを行うこともできますが、それでも、このプラットフォームで最も興味深く便利なのは API です。 API を一連の関数として使用すると、Kubernetes で実行したいほぼすべてのことにアクセスできます。 kubectl 自体も REST API を使用します。

これは REST であるため、この API を操作するには任意の言語やツールを使用できますが、カスタム ライブラリを使用すると作業がはるかに簡単になります。 私のチームはそのようなライブラリを 2 つ作成しました。XNUMX つは Java/OSGi 用、もう XNUMX つは Go 用です。 XNUMX 番目のものはあまり使用されませんが、いずれの場合でも、これらの便利なものを自由に使用できます。 これらは部分的にライセンスされたオープンソース プロジェクトです。 さまざまな言語に対応したこのようなライブラリが多数あるため、最適なものを選択できます。

したがって、展開の自動化を開始する前に、プロセスがダウンタイムの影響を受けないことを確認する必要があります。 たとえば、私たちのチームは、人々がアプリケーションを最もよく使用する日中の時間帯に本番環境のデプロイメントを実行するため、このプロセスの遅延を避けることが重要です。 ダウンタイムを回避するために、Blue/Green デプロイメントまたはローリング アップデートの 2 つの方法が使用されます。 後者の場合、アプリケーションの 5 つのレプリカが実行されている場合、それらは XNUMX つずつ順番に更新されます。 この方法はうまく機能しますが、展開プロセス中に異なるバージョンのアプリケーションを同時に実行している場合には適していません。 この場合、バックエンドが古いバージョンを実行している間にユーザー インターフェイスを更新すると、アプリケーションは動作を停止します。 したがって、プログラミングの観点から、そのような状況で作業することは非常に困難です。

これが、アプリケーションのデプロイメントを自動化するために Blue/Green デプロイメントを使用することを好む理由の XNUMX つです。 この方法では、一度に XNUMX つのバージョンのアプリケーションのみがアクティブになるようにする必要があります。

青/緑の展開メカニズムは次のようになります。 アプリケーションのトラフィックは ha-proxy 経由で受信され、同じバージョンのアプリケーションの実行中のレプリカに転送されます。

新しいデプロイメントが行われるときは、Deployer を使用します。これにより、新しいコンポーネントが与えられ、新しいバージョンがデプロイされます。 アプリケーションの新しいバージョンをデプロイするということは、新しいレプリカのセットが「生成」され、その後、新しいバージョンのこれらのレプリカが別の新しいポッドで起動されることを意味します。 ただし、ha-proxy はそれらについて何も認識せず、まだワークロードをそれらにルーティングしません。

したがって、まず、新しいバージョンのヘルス チェックのパフォーマンス チェックを実行して、レプリカが負荷に対応できる状態であることを確認する必要があります。

すべての展開コンポーネントは、何らかの形式のヘルス チェックをサポートする必要があります。 これは、ステータス 200 のコードを受信した場合の非常に単純な HTTP 呼び出しチェック、またはレプリカとデータベースおよび他のサービスとの接続、動的環境接続の安定性をチェックするより詳細なチェックです。 、そしてすべてが正しく起動して動作するかどうか。 このプロセスは非常に複雑になる場合があります。

更新されたすべてのレプリカが動作していることをシステムが確認した後、Deployer は構成を更新し、ha-proxy を再構成する正しい confd を渡します。

この後初めて、トラフィックは新しいバージョンのレプリカを持つポッドに送信され、古いポッドは消えます。

このメカニズムは Kubernetes の機能ではありません。 ブルー/グリーン デプロイメントの概念はかなり前から存在しており、常にロード バランサーが使用されてきました。 まず、すべてのトラフィックをアプリケーションの古いバージョンに転送し、更新後にトラフィックを新しいバージョンに完全に転送します。 この原則は Kubernetes だけで使用されるわけではありません。

次に、新しい展開コンポーネントである Deployer を紹介します。これは、ヘルス チェックの実行、プロキシの再構成などを行います。 これは外部の世界には適用されない概念であり、Kubernetes の内部に存在します。 オープンソース ツールを使用して独自の Deployer コンセプトを作成する方法を説明します。

したがって、Deployer が最初に行うことは、Kubernetes API を使用して RC レプリケーション コントローラーを作成することです。 この API は、さらにデプロイするためのポッドとサービスを作成します。つまり、アプリケーション用にまったく新しいクラスターを作成します。 RC は、レプリカが開始されたことを確認するとすぐに、レプリカの機能についてヘルス チェックを実行します。 これを行うために、Deployer は GET /health コマンドを使用します。 適切なスキャン コンポーネントを実行し、クラスターの操作をサポートするすべての要素をチェックします。

すべてのポッドが正常性を報告した後、Deployer は新しい構成要素である etcd 分散ストレージを作成します。これは、ロード バランサー構成の保存など、Kubernetes によって内部的に使用されます。 データを etcd に書き込み、confd と呼ばれる小さなツールが etcd の新しいデータを監視します。

初期設定への変更を検出すると、新しい設定ファイルを生成し、ha-proxy に転送します。 この場合、ha-proxy は接続を失うことなく再起動し、アプリケーションの新しいバージョンが動作できるようにする新しいサービスへの負荷に対処します。

ご覧のとおり、コンポーネントが豊富であるにもかかわらず、ここでは複雑なことは何もありません。 API と etcd にはもっと注意を払う必要があります。 私たち自身が使用しているオープンソース デプロイヤー、Amdatu Kubernetes Deployer についてお話したいと思います。

これは Kubernetes デプロイメントを調整するためのツールであり、次の機能があります。

• ブルー/グリーン展開。
• 外部ロードバランサーのセットアップ。
• デプロイメント記述子の管理。
• 実際の展開を管理する。
• 導入時にヘルスチェックの機能をチェックする。
• ポッドへの環境変数の実装。

この Deployer は Kubernetes API 上に構築されており、ハンドルとデプロイメントを管理するための REST API と、デプロイメント プロセス中にログをストリーミングするための Websocket API を提供します。

ロード バランサー構成データを etcd に配置するため、すぐに使用できるサポートを備えた ha-proxy を使用する必要はなく、独自のロード バランサー構成ファイルを簡単に使用できます。 Amdatu Deployer は、Kubernetes 自体と同様に Go で書かれており、Apache によってライセンスされています。

このバージョンのデプロイヤを使い始める前に、必要なパラメータを指定する次のデプロイメント記述子を使用しました。

このコードの重要なパラメータの XNUMX つは、「useHealthCheck」フラグを有効にすることです。 デプロイメントプロセス中に健全性チェックを実行する必要があることを指定する必要があります。 検証する必要のないサードパーティのコンテナをデプロイメントで使用する場合、この設定を無効にすることができます。 この記述子は、ha-proxy に必要なレプリカの数とフロントエンド URL も示します。 最後はポッド仕様フラグ「podspec」で、Kubernetes を呼び出してポート構成やイメージなどの情報を取得します。 これは非常に単純な JSON 記述子です。

オープンソース Amdatu プロジェクトの一部であるもう 2 つのツールは、Deploymentctl です。 デプロイメントを構成するための UI があり、デプロイメント履歴を保存し、サードパーティ ユーザーや開発者からのコールバック用の Webhook が含まれています。 Amdatu Deployer 自体は REST API であるため、UI を使用することはできませんが、このインターフェイスを使用すると、API を使用せずにデプロイメントがはるかに簡単になります。 Deploymentctl は、Angular XNUMX を使用して OSGi/Vertx で作成されます。

ここでは、事前に録画した録音を使用して上記の内容を画面上でデモンストレーションしますので、待つ必要はありません。 単純な Go アプリケーションをデプロイします。 これまでに Go を試したことがなくても、心配する必要はありません。これは非常に単純なアプリケーションなので、理解できるはずです。

ここでは、/health にのみ応答する HTTP サーバーを作成しているため、このアプリケーションはヘルス チェックのみをテストし、他は何もテストしません。 チェックに合格すると、以下に示す JSON 構造が使用されます。 これには、デプロイヤーによってデプロイされるアプリケーションのバージョン、ファイルの先頭に表示されるメッセージ、およびアプリケーションが動作しているかどうかを示すブール データ型が含まれています。

ファイルの先頭に固定のブール値を配置したため、最後の行で少しごまかしました。これは、将来的には「異常な」アプリケーションでもデプロイするのに役立ちます。 これについては後で扱います。

それでは始めましょう。 まず、コマンド ~ kubectl get pods を使用して実行中のポッドの存在を確認し、フロントエンド URL からの応答がないことに基づいて、現在デプロイメントが行われていないことを確認します。

次に画面には、前述した Deploymentctl インターフェイスが表示されます。ここでは、名前空間、アプリケーション名、デプロイメント バージョン、レプリカの数、フロントエンド URL、コンテナー名、イメージ、リソース制限、ヘルス チェック用のポート番号などのデプロイメント パラメーターが設定されています。等。 リソース制限は、可能な限り最大量のハードウェアを使用できるようにするため、非常に重要です。 ここで、展開ログを表示することもできます。

ここでコマンド ~ kubectl get pods を繰り返すと、システムが 20 秒間「フリーズ」し、その間に ha-proxy が再構成されていることがわかります。 この後、ポッドが起動し、デプロイメント ログにレプリカが表示されます。

ビデオから 20 秒の待機部分を切り取ったところ、アプリケーションの最初のバージョンがデプロイされたことが画面上で確認できます。 これはすべて UI のみを使用して行われました。

次に、XNUMX 番目のバージョンを試してみましょう。 これを行うには、アプリケーションのメッセージを「Hello, Kubernetes!」から変更します。 「Hello, Deployer!」というメッセージが表示されると、システムはこのイメージを作成して Docker レジストリに配置します。その後、Deploymentctl ウィンドウで [Deploy] ボタンを再度クリックするだけです。 この場合、アプリケーションの最初のバージョンをデプロイしたときと同じ方法で、デプロイメント ログが自動的に起動されます。

コマンド ~ kubectl get pods は、現在 2 つのバージョンのアプリケーションが実行中であることを示していますが、フロントエンドではまだバージョン 1 が実行中であることが示されています。

ロード バランサーは、ヘルス チェックが完了するのを待ってから、トラフィックを新しいバージョンにリダイレクトします。 20 秒後、curl に切り替えると、アプリケーションのバージョン 2 がデプロイされ、最初のバージョンが削除されたことがわかります。

これは「健全な」アプリケーションの展開でした。 アプリケーションの新しいバージョンで、Healthy パラメーターを true から false に変更した場合、つまり、ヘルス チェックに失敗した異常なアプリケーションをデプロイしようとした場合に何が起こるかを見てみましょう。 これは、開発段階でアプリケーションに何らかの構成エラーが発生し、この形式で運用環境に送信された場合に発生する可能性があります。

ご覧のとおり、デプロイメントは上記のすべての手順を実行し、~kubectl get pods は両方のポッドが実行中であることを示します。 ただし、前の展開とは異なり、ログにはタイムアウト ステータスが表示されます。 つまり、ヘルスチェックが失敗したため、アプリケーションの新しいバージョンをデプロイできません。 その結果、システムは古いバージョンのアプリケーションの使用に戻り、新しいバージョンは単にアンインストールされたことがわかります。

これの良い点は、アプリケーションに同時に膨大な数のリクエストが入ってきたとしても、デプロイメント手順の実装中にダウンタイムが発生することにさえ気付かないことです。 可能な限り多くのリクエストを送信する Gatling フレームワークを使用してこのアプリケーションをテストすると、これらのリクエストはいずれもドロップされません。 これは、ユーザーがリアルタイムでのバージョン更新に気付かないことを意味します。 失敗した場合は古いバージョンで作業が続行され、成功した場合はユーザーは新しいバージョンに切り替えます。

失敗する可能性があるのは XNUMX つだけです。ヘルス チェックは成功したが、ワークロードが適用されるとすぐにアプリケーションが失敗する場合です。つまり、展開が完了した後にのみ崩壊が発生します。 この場合、手動で古いバージョンにロールバックする必要があります。 そこで、Kubernetes 用に設計されたオープンソース ツールを使用して Kubernetes を使用する方法を検討しました。 これらのツールをビルド/デプロイ パイプラインに組み込むと、デプロイ プロセスがはるかに簡単になります。 同時に、デプロイメントを開始するには、ユーザー インターフェイスを使用するか、マスターへのコミットなどを使用してこのプロセスを完全に自動化することができます。

私たちのビルド サーバーは Docker イメージを作成し、それを Docker Hub または使用するレジストリにプッシュします。 Docker Hub は Webhook をサポートしているため、上記の方法で Deployer 経由でリモート デプロイメントをトリガーできます。 このようにして、潜在的な運用環境へのアプリケーションのデプロイメントを完全に自動化できます。

次のトピック、Kubernetes クラスターのスケーリングに進みましょう。 kubectl コマンドはスケーリング コマンドであることに注意してください。 さらに多くの助けを借りれば、既存のクラスター内のレプリカの数を簡単に増やすことができます。 ただし、実際には、通常はポッドではなくノードの数を増やす必要があります。

同時に、業務時間中は実行中のアプリケーション インスタンスの数を増やす必要がある場合があり、夜間は Amazon サービスのコストを削減するために、実行中のアプリケーション インスタンスの数を減らす必要がある場合があります。 これは、ポッドの数をスケーリングするだけで十分であるという意味ではありません。ノードの XNUMX つがアイドル状態であっても、Amazon に料金を支払う必要があるからです。 つまり、ポッドのスケーリングとともに、使用するマシンの数もスケーリングする必要があります。

Amazon を使用するか他のクラウド サービスを使用するかにかかわらず、Kubernetes は使用されているマシンの数について何も知らないため、これは困難な場合があります。 ノード レベルでシステムを拡張できるツールがありません。

したがって、ノードとポッドの両方を管理する必要があります。 AWS API とスケーリング グループ マシンを使用して新しいノードの起動を簡単にスケールし、Kubernetes ワーカー ノードの数を構成できます。 また、cloud-init または同様のスクリプトを使用して、Kubernetes クラスターにノードを登録することもできます。

新しいマシンは Scaling グループで起動し、ノードとして自身を起動し、マスターのレジストリに登録して動作を開始します。 この後、結果のノードで使用するレプリカの数を増やすことができます。 スケールダウンには、「不要な」マシンの電源をオフにした後、すでに実行中のアプリケーションが破壊されないようにする必要があるため、より多くの労力が必要です。 このようなシナリオを防ぐには、ノードを「スケジュール不可」ステータスに設定する必要があります。 これは、デフォルトのスケジューラーが DaemonSet ポッドをスケジュールするときにこれらのノードを無視することを意味します。 スケジューラーはこれらのサーバーから何も削除しませんが、そこで新しいコンテナーを起動することもありません。 次のステップは、ドレイン ノードを削除することです。つまり、実行中のポッドをドレイン ノードから別のマシン、またはこれに十分な容量を持つ他のノードに転送します。 これらのノードにコンテナーが存在しないことを確認したら、Kubernetes からコンテナーを削除できます。 この後、それらは Kubernetes に対して存在しなくなります。 次に、AWS API を使用して、不要なノードまたはマシンを無効にする必要があります。
AWS API に似た別のオープンソース スケーリング ツールである Amdatu Scalerd を使用できます。 クラスター内のノードを追加または削除するための CLI を提供します。 その興味深い機能は、次の json ファイルを使用してスケジューラーを構成できることです。

示されているコードは、夜間のクラスター容量を半分に減らします。 使用可能なレプリカの数と Amazon クラスターの必要な容量の両方を構成します。 このスケジューラーを使用すると、夜間にノード数が自動的に減り、朝にノード数が増えるため、Amazon などのクラウド サービスのノードを使用するコストを節約できます。 この機能は Kubernetes には組み込まれていませんが、Scalerd を使用すると、このプラットフォームを必要に応じて拡張できます。

多くの人が「それはそれでいいのですが、通常は静的である私のデータベースはどうなるのでしょうか?」と言うことを指摘しておきたいと思います。 Kubernetes のような動的環境でこのようなものを実行するにはどうすればよいでしょうか? 私の意見では、これはすべきではなく、Kubernetes でデータ ウェアハウスを実行しようとするべきではありません。 これは技術的には可能であり、インターネット上にこのテーマに関するチュートリアルがありますが、それはあなたの人生を非常に複雑にするでしょう。

はい、Kubernetes には永続ストアの概念があり、Mongo や MySQL などのデータ ストアを実行してみることもできますが、これは非常に労力を要する作業です。 これは、データ ウェアハウスが動的環境との対話を完全にはサポートしていないためです。 ほとんどのデータベースは、クラスターの手動構成を含む大幅な構成を必要とし、自動スケーリングなどを好みません。
したがって、Kubernetes でデータ ウェアハウスを実行しようとして作業が複雑になるべきではありません。 使い慣れたサービスを使用して従来の方法で作業を整理し、それらを使用する機能を Kubernetes に提供するだけです。

このトピックの締めくくりとして、私のチームが取り組んでいる Kubernetes ベースの Cloud RTI プラットフォームを紹介したいと思います。 集中ログ、アプリケーションとクラスターの監視、その他多くの便利な機能を提供します。 Grafana などのさまざまなオープンソース ツールを使用してモニタリングを表示します。

Kubernetes で ha-proxy ロードバランサーを使用する理由についての質問がありました。 現在、負荷分散には 2 つのレベルがあるため、良い質問です。 Kubernetes サービスは依然として仮想 IP アドレス上に存在します。 Amazon がクラウド ホストに過負荷をかけるとアドレスが変更されるため、外部ホスト マシンのポートにこれらを使用することはできません。 これが、トラフィックが Kubernetes とシームレスに通信できるように、より静的な構造を作成するために、ha-proxy をサービスの前に配置する理由です。

もう XNUMX つの良い質問は、ブルー/グリーン デプロイメントを実行するときにデータベース スキーマの変更にどのように対処できるかということです。 実際のところ、Kubernetes を使用するかどうかに関係なく、データベース スキーマの変更は困難な作業です。 古いスキーマと新しいスキーマに互換性があることを確認する必要があります。その後、データベースを更新して、アプリケーション自体を更新できます。 データベースをホットスワップしてからアプリケーションを更新できます。 新しいスキーマを使用して完全に新しいデータベース クラスターを起動した人を私は知っています。Mongo のようなスキームレス データベースがある場合、これはオプションですが、いずれにせよ簡単な作業ではありません。 他にご質問がございましたら、ご静聴いただきありがとうございます。

いくつかの広告 🙂

いつもご宿泊いただきありがとうございます。 私たちの記事が気に入っていますか? もっと興味深いコンテンツを見たいですか? 注文したり、友人に勧めたりして私たちをサポートしてください。 開発者向けのクラウド VPS は 4.99 ドルから, 当社があなたのために発明した、エントリーレベルのサーバーのユニークな類似物です。 VPS (KVM) E5-2697 v3 (6 コア) 10GB DDR4 480GB SSD 1Gbps 19 ドルからの真実、またはサーバーを共有する方法? (RAID1 および RAID10、最大 24 コア、最大 40GB DDR4 で利用可能)。

アムステルダムのエクイニクス Tier IV データセンターでは Dell R730xd が 2 倍安い? ここだけ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV 199 ドルから オランダで！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 ドルから! について読む インフラストラクチャー企業を構築する方法730 ペニーで 5 ユーロの価値がある Dell R2650xd E4-9000 vXNUMX サーバーを使用したクラスですか?

出所： habr.com