🤽🏼 ⏲️ 🔚 DEVOXX UK。本番環境でのKubernetes：青/緑のデプロイ、自動スケーリング、デプロイの自動化。パート2 🕺🏼 📝 📧

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

Kubernetesにはこれらの機能はそのままではありませんが、そのような問題を解決するために使用できるAPIを提供します。 Kubernetesクラスターの自動化された青/緑のデプロイとスケーリングツールは、Cloud RTIオープンソースプロジェクトの一部として開発されました。

このビデオのトランスクリプトは、Kubernetesを他のオープンソースコンポーネントとともに構成して、本番環境でのダウンタイムなしでgit commit change commitからコードを受け入れる本番環境に対応する環境を取得する方法について説明しています。

DEVOXX UK。本番環境でのKubernetes：青/緑のデプロイ、自動スケーリング、デプロイの自動化。パート1

したがって、外部からアプリケーションにアクセスした後、自動化を完全に構成し始めることができます。つまり、自動化をgit commitを実行できる段階に持ってきて、このgit commitが本番環境で終了することを確認します。当然、これらのステップの実装、デプロイメントの実装では、ダウンタイムに直面したくありません。したがって、Kubernetesの自動化はすべてAPIから始まります。

Kubernetesは、「そのまま」生産的に使用できるツールではありません。もちろん、これを実行したり、kubectlを使用したりすることもできますが、このプラットフォームではAPIが最も面白くて便利です。 APIを機能セットとして使用すると、Kubernetesで実行したいほとんどすべての機能にアクセスできます。 Kubectl自体もREST APIを使用します。

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

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

これが、ブルー/グリーン展開を使用してアプリケーションの展開を自動化することを好む理由の1つです。この方法では、特定の時点で、アプリケーションの1つのバージョンのみがアクティブであることを確認する必要があります。

青/緑の展開メカニズムは次のとおりです。アプリケーションのトラフィックはha-proxyを介して取得されます。ha-proxyは、同じバージョンの実行中のアプリケーションレプリカにトラフィックを送ります。

新しいデプロイメントが実行されると、新しいコンポーネントが提供されているDeployerを使用して、新しいバージョンをデプロイします。アプリケーションの新しいバージョンをデプロイすると、新しいレプリカのセットが「立ち上がり」、その後、新しいバージョンのこれらのレプリカが別の新しいポッドで起動されます。ただし、ha-proxyはそれらについて何も認識しておらず、これまでのところ、ワークロードを送信していません。

したがって、最初に、レプリカが負荷を処理する準備ができていることを確認するために、新しいバージョンのヘルスチェックの状態をチェックする必要があります。

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

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

その後、トラフィックは新しいバージョンのレプリカでアンダーに送られ、古いバージョンは消えます。

このメカニズムはKubernetesの機能ではありません。 Blue / Greenのデプロイメントコンセプトはかなり前からあり、ロードバランサーを常に使用しています。最初に、すべてのトラフィックを古いバージョンのアプリケーションに転送し、アップグレード後に完全に新しいバージョンに転送します。この原則は、Kubernetesだけで使用されるわけではありません。

ここで、新しいデプロイコンポーネントであるDeployerを紹介します。Deployerは、ヘルスチェックを実行したり、プロキシを再構成したりします。これは外界には当てはまらない概念であり、Kubernetes内に存在します。オープンソースツールを使用して独自のDeployerコンセプトを作成する方法を示します。

したがって、Deployerが最初に行うことは、Kubernetes APIを使用してRCレプリケーションコントローラを作成することです。このAPIは、さらにデプロイするためのポッドとサービスを作成します。つまり、アプリケーションの完全に新しいクラスターを作成します。 RCは、レプリカが開始されたことを確認すると、それらのヘルスチェックをチェックします。これを行うには、DeployerはGET / healthコマンドを使用します。対応する検証コンポーネントを起動し、クラスターの動作を保証するすべての要素を検証します。

すべてのポッドが「正常性」を報告した後、Deployerは新しい構成アイテムを作成します。これは、ロードバランサー構成の保存など、Kubernetes内部で使用される分散ストレージetcdです。 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によってライセンスされています。

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

このコードの重要なパラメータの1つは、「useHealthCheck」フラグを有効にすることです。展開プロセス中にヘルスチェックが必要であることを示す必要があります。検証する必要のないサードパーティのコンテナをデプロイメントで使用する場合、このオプションをオフにすることができます。この記述子は、ha-proxyが必要とするレプリカの数とフロントエンドURLも示します。最後にpodspecポッドの仕様フラグがあり、ポート構成、イメージなどの情報をKubernetesに呼び出します。これは、JSON形式のかなり単純な記述子です。

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

ここでは、既成の記録を使用して画面上で上記のデモを行うので、待つ必要はありません。シンプルなアプリケーションをGoにデプロイします。 Goに出会ったことがない場合、これは非常にシンプルなアプリケーションなので、心配しないでください。すべてを理解する必要があります。

ここでは、/ヘルスのみに応答するHTTPサーバーを作成します。したがって、このアプリケーションはヘルスチェックのみをチェックし、それ以外はチェックしません。チェックに合格すると、以下に示すJSON構造が呼び出されます。これには、デプロイヤーによってデプロイされるアプリケーションのバージョン、ファイルの上部に表示されるメッセージ、およびブール論理データタイプ（アプリケーションが機能しているかどうかに関係なく）が含まれています。

ファイルの先頭に固定ブール値を配置したため、最後の行で少し浮気しました。これは、将来的には「不健全な」アプリケーションでもデプロイできるようになるためです。これについては後で扱います。

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

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

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

ビデオから20秒の待機時間を切り取り、画面にアプリケーションの最初のバージョンがデプロイされていることがわかります。これはすべて、UIの助けを借りて行われました。

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

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

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

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

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

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

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

Build Serverビルドサーバーは、Dockerイメージを作成し、それをDocker Hubまたは使用するその他のレジストリに貼り付けます。 Dockerハブはwebhookをサポートしているため、上記のようにDeployerを介してリモートデプロイメントを開始できます。したがって、潜在的な本番環境でのアプリケーションのデプロイメントを完全に自動化できます。

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

同時に、勤務時間中に、Amazonサービスのコストを削減するために、夜間にアプリケーションの実行中のインスタンスの数を減らす必要がある場合があります。これは、ポッドの数だけで十分にスケーリングされることを意味しません。ノードの1つがビジー状態でなくても、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などのさまざまなオープンソースツールを使用して監視を表示します。

なぜha-proxyロードバランサーをKubernetesで使用するのかという質問が出されました。現在、負荷分散には2つのレベルがあるため、良い質問です。 Kubernetesサービスは引き続き仮想IPアドレスに配置されます。 Amazonがクラウドホストを再起動するとアドレスが変更されるため、これらを外部ホストポートに使用することはできません。そのため、サービスの前にha-proxyサービスを配置し、Kubernetesとのシームレスなトラフィック相互作用のためのより静的な構造を作成します。

もう1つの良い質問は、青/緑の展開中にデータベーススキーマを変更する方法を教えてください。実際には、Kubernetesの使用に関係なく、データベーススキーマの変更は複雑な作業です。古いスキームと新しいスキームの互換性を確保する必要があります。その後、データベースを更新してからアプリケーション自体を更新できます。データベースをホットスワップしてから、アプリケーションをアップグレードできます。新しいスキームで完全に新しいデータベースクラスターをダウンロードした人を知っています。これは、Mongoのようなスキームのないデータベースの場合のオプションですが、いずれの場合も簡単な作業ではありません。他にご不明な点がございましたら、よろしくお願いいたします。

広告のビット:)

いつもご利用いただきありがとうございます。私たちの記事は好きですか？もっと面白い資料を見たいですか？私たちが開発したエントリーレベルサーバーのユニークなアナログで ある$ 4.99から、注文またはお友達への開発者向けクラウドベースVPSの開発者への推奨によって私たちをサポートしてください：VPS（KVM）E5-2697 v3（6コア）10GB DDR4 480GB SSD 1Gbpsの真実19ドルから、またはサーバーを分割する方法？（オプションは、RAID1およびRAID10、最大24コア、最大40GB DDR4で利用可能です）。

Dell R730xdは、アムステルダムのEquinix Tier IVデータセンターで2倍安いですか？オランダでは、199ドルから、インテルTetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TVを2台だけ持っています！デルR420-2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB-$ 99から！インフラストラクチャビルディングの構築方法についてお読みください。Dell R730xd E5-2650 v4サーバーを使用するクラスcは、1ペニーで9,000ユーロかかりますか？

DEVOXX UK。本番環境でのKubernetes：青/緑のデプロイ、自動スケーリング、デプロイの自動化。パート2

広告のビット:)

More articles: