Kubernetes でアプリケーションを開発するための要件

今日は、アプリケーションの作成方法と、アプリケーションが Kubernetes で適切に動作するための要件について説明する予定です。 そのため、アプリケーションに関して頭痛の種がなくなり、アプリケーションの周りに「亀裂」を発明したり構築したりする必要がなく、すべてが Kubernetes 自体が意図したとおりに動作します。

この講演は「」の一環です。Kubernetes 上の Slurm Night School」 夜間学校の公開理論講義をご覧いただけます Youtube ではプレイリストにグループ化されています。 動画ではなくテキストを好む方のために、この記事を用意しました。

私の名前は Pavel Selivanov です。現在、Mail.ru Cloud Solutions の主要な DevOps エンジニアを務めています。私たちはクラウドを作成し、管理 kubernetes などを作成しています。 現在の私の仕事には、開発の支援、これらのクラウドの展開、作成したアプリケーションの展開、およびユーザーに提供するツールの直接開発が含まれます。

私はここ XNUMX 年間、DevOps を行ってきたと思います。 しかし、原則として、私は DevOps が行っていることをおそらく XNUMX 年ほど続けています。 それまでは、主に管理業務に携わっていました。 私が Kubernetes を使い始めたのはかなり前です。おそらく、使い始めてから約 XNUMX 年が経過しました。

一般に、私は Kubernetes がバージョン 1.3、おそらく 1.2 の頃、つまりまだ初期段階にあったときに始めました。 現在では、Kubernetes は初期段階ではありません。Kubernetes を実行できるようにしたいエンジニアに対して、市場で大きな需要があることは明らかです。 そして企業はそのような人材に対する需要が非常に高いのです。 そこで、実はこの講演会が登場したのです。

これから話す内容の計画に従って話すと、次のようになります。括弧内に（TL;DR）と書かれています。「長すぎます。 読まないでください。」 今日の私のプレゼンテーションは無限のリストで構成されます。

実際、私自身もそのようなプレゼンテーションが行われるのは好きではありませんが、これは非常に重要なテーマであるため、このプレゼンテーションを準備していたとき、この情報を別の方法で整理する方法がまったくわかりませんでした。

概して、この情報は「ctrl+c、ctrl+v」であり、特に、Wiki の DevOps セクションにあるものであり、開発者向けの要件が次のように書かれています。 Kubernetes はこうあるべきです。」

プレゼンテーションがこれほど膨大なリストになったのはそのためです。 ごめん。 できれば退屈しないように、できるだけお伝えしていきたいと思います。

これから見ていきたいこと:

• これらは、第一に、ログ (アプリケーション ログ?)、Kubernetes でのログの処理方法、ログの処理方法、ログはどうあるべきか、です。
• Kubernetes の構成をどうするか、Kubernetes 用にアプリケーションを構成する最良の方法と最悪の方法は何ですか。
• アクセシビリティ チェックとは一般的にどのようなものなのか、どのようなものであるべきなのかについて話しましょう。
• 正常なシャットダウンとは何かについて話しましょう。
• リソースについてもう一度話しましょう。
• データ ストレージの話題にもう一度触れましょう。
• 最後に、この謎のクラウドネイティブ アプリケーションという用語について説明します。 この用語の形容詞としてのクラウドネイティブネス。

ログ

ログから始めることをお勧めします。これらのログを Kubernetes のどこに配置する必要があるのか​​を考えます。 これで、Kubernetes でアプリケーションが起動されました。 古典によれば、以前のアプリケーションは常にファイルのどこかにログを書き込んでいました。 不正なアプリケーションは、アプリケーションを起動した開発者のホーム ディレクトリ内のファイルにログを書き込みます。 優れたアプリケーションは、次の場所のファイルにログを書き込みます。 /var/log.

したがって、さらに、優れた管理者は、これらのログがローテーションできるようにインフラストラクチャ内にいくつかの設定を行っていました。同じ rsyslog は、これらのログを調べ、ログに何かが発生した場合、大量のログが存在し、バックアップ コピーを作成し、ログをそこに保存します。 、XNUMX 週間以上、XNUMX か月以上の古いファイルを削除します。 理論的には、アプリケーションがログを書き込むという理由だけで、実稼働サーバー (戦闘サーバー?) 上のスペースが不足しないように準備する必要があります。 したがって、ログが原因で生産全体が停止することはありませんでした。

Kubernetes の世界に移行し、そこで同じことを実行すると、最初に注目できるのは、ユーザーがファイルにログを書き込んだときと同様に、ログを書き続けるという事実です。

Kubernetes について言えば、Docker コンテナからどこかにログを書き込む適切な場所は、単にアプリケーションからいわゆる Stdout/Stderr、つまりオペレーティング システムの標準出力ストリーム、標準エラーにログを書き込むことであることがわかります。出力。 これは、原則として Docker、特に Kubernetis にログを配置する最も正しく、最も簡単で、最も論理的な方法です。 なぜなら、アプリケーションがログを Stdout/Stderr に書き込む場合、これらのログをどう扱うかは Docker と Kubernetes アドオン次第だからです。 Docker はデフォルトで特殊ファイルを JSON 形式で構築します。

ここで、これらのログを次にどうするかという疑問が生じます。 最も簡単な方法は明らかです。私たちには次のことが可能です。 kubectl logs これらの「ポッド」のログを見てください。 しかし、おそらく、これはあまり良い選択肢ではありません。ログに対して何か他のことを行う必要があります。

とりあえず、ログの話題に触れたので、同時にログがどうあるべきかについても話しましょう。 つまり、これは Kubernetes に直接当てはまるわけではありませんが、ログをどうするかを考え始めるときに、これについても考えてみるとよいでしょう。

Docker がファイルに保存したこれらのログを友好的な方法で取得し、どこかに送信する何らかのツールが必要です。 一般に、私たちは通常、DaemonSet の形式で Kubernetes 内で何らかのエージェントを起動します。ログ コレクターは、Docker が収集するログの場所を単に通知するものです。 そして、この収集エージェントは単にそれらを取得し、おそらく途中で何らかの方法で解析し、追加のメタ情報で強化し、最終的にはどこかに保存するためにそれらを送信します。 そこではすでにバリエーションが可能です。 最も一般的なのはおそらく Elasticsearch で、ログを保存し、そこから簡単に取得できます。 次に、リクエストを使用して、たとえば Kibana を使用して、それらに基づいてグラフを作成し、それらに基づいてアラートを作成します。

最も重要な考え方は、もう一度繰り返しますが、Docker 内、特に Kubernetes 内でログをファイルに保存するのは非常に悪い考えであるということです。

まず、コンテナ内のログをファイルに取得するのが難しいためです。 まずコンテナに移動し、そこで実行してからログを確認する必要があります。 次のポイントは、ファイルにログがある場合、通常、コンテナーには最小限の環境があり、通常のログの作業に必要なユーティリティが存在しないということです。 それらを埋めて、眺め、テキストエディタで開きます。 次の瞬間は、コンテナ内のファイルにログがあるときです。このコンテナが削除されると、ご存知のとおり、ログもコンテナとともに消滅します。 したがって、コンテナが再起動されると、ログがなくなることを意味します。 繰り返しますが、悪い選択肢です。

そして最後のポイントは、通常、コンテナー内にはアプリケーションがあり、それだけであるということです。通常、それが実行されている唯一のプロセスです。 ログを含むファイルをローテーションするプロセスについてはまったく話されていません。 ログがファイルに書き込まれ始めるとすぐに、申し訳ありませんが、運用サーバーが失われ始めることを意味します。 なぜなら、第一に、ファイルを見つけるのが難しく、誰もそれらを追跡せず、さらに誰もそれらを制御しないためです。したがって、ファイルはサーバー上のスペースがなくなるまで際限なく増大します。 したがって、Docker、特に Kubernetes でファイルにログインするのは悪い考えだともう一度言います。

次の点は、ここでもう一度話したいと思います。ログのトピックに触れているので、ログを扱いやすくするためにログがどのように見えるべきかについて話しておくとよいでしょう。 先ほども述べたように、このトピックは Kubernetes とは直接関係ありませんが、DevOps のトピックと非常によく関連しています。 誰もが快適に過ごせるように、開発と運用という XNUMX つの異なる部門間の開発文化と友情についてのトピックです。

これは、現在、ログは JSON 形式で書き込むのが理想的であることを意味します。 何らかの印刷物などを挿入するため、理解できない形式でログを書き込む、理解できない独自のアプリケーションをお持ちの場合は、通常のロギングを実装できるようにするある種のフレームワークやラッパーをグーグルで検索してください。 そこで JSON のロギングパラメータを有効にします。JSON は単純な形式なので、解析は簡単です。

JSON が何らかの基準に従って機能しない場合 (何が原因かは誰にもわかりません)、少なくとも解析可能な形式でログを書き込んでください。 ここではむしろ、考慮する価値があります。たとえば、多数のコンテナまたは nginx を使用したプロセスだけを実行していて、それぞれに独自のログ設定がある場合、おそらく、次のことを行うのは非常に不便になるように思われます。それらを解析します。 新しい nginx インスタンスごとにログの書き込み方法が異なるため、独自のパーサーを作成する必要があるからです。 繰り返しになりますが、これらすべての nginx インスタンスが同じログ構成を持ち、すべてのログが完全に均一に書き込まれることを確認することはおそらく検討する価値がありました。 同じことがまったくすべてのアプリケーションに当てはまります。

最後に、理想的には複数行形式のログは避けるべきだという火に油を注ぎたいと思います。 ここで重要なのは、ログ コレクターを使用したことがある場合は、ログ コレクターが複数行のログを処理できること、収集方法を知っていることなどを約束していることを見たことがあるでしょう。 実際、私の意見では、現在、複数行のログを正常に、完全に、エラーなく収集できるコレクターは一人もいません。 人間のやり方で、便利で間違いがないように。

ただし、スタック トレースは常に複数行のログになるので、それを回避する方法を説明します。 ここでの問題は、ログはイベントの記録であり、stactrace は実際にはログではないということです。 ログを収集して Elasticsearch のどこかに配置し、そこからグラフを作成し、サイト上のユーザー アクティビティのレポートを作成し、スタック トレースを取得した場合、それはアプリケーション内で予期せぬ何かが発生し、未処理の状況が発生していることを意味します。 そして、スタック トレースを追跡できるシステムのどこかに自動的にアップロードすることは理にかなっています。

これは、スタック トレースを扱うために特別に作られたソフトウェア (同じ Sentry) です。 自動化されたタスクをすぐに作成し、誰かに割り当てたり、スタクトレースが発生したときにアラートを発したり、これらのスタクトレースを XNUMX つのタイプごとにグループ化したりすることができます。 原則として、ログについて話すときに stactrace について話すのはあまり意味がありません。結局のところ、これらは目的が異なる別のものだからです。

設定

次に、Kubernetes の構成について説明します。つまり、Kubernetes で何を行うか、および Kubernetes 内のアプリケーションをどのように構成する必要があるかについて説明します。 一般に、私は Docker はコンテナに関するものではないとよく言います。 Docker をあまり扱ったことがない人でも、Docker がコンテナに関するものであることは誰もが知っています。 繰り返しますが、Docker はコンテナに関するものではありません。

私の考えでは、Docker は標準に関するものです。 そして、アプリケーションを構築するための標準、アプリケーションをインストールするための標準など、事実上あらゆるものに標準が存在します。

そして、これは以前にも使用しましたが、コンテナーの出現で特に人気が高まったばかりです。これは ENV (環境) 変数、つまりオペレーティング システムに含まれる環境変数と呼ばれます。 これは一般に、アプリケーションを構成する理想的な方法です。JAVA、Python、Go、Perl、神は禁じられているアプリケーションを使用しており、それらがすべてデータベース ホスト、データベース ユーザー、データベース パスワード変数を読み取ることができる場合、これが理想的です。 データベース プランでは、同じ方法で XNUMX つの異なる言語でアプリケーションが構成されています。 これ以上異なる構成はありません。

すべては ENV 変数を使用して設定できます。 Kubernetes について話すとき、デプロイメント内で ENV 変数を宣言する優れた方法があります。 したがって、シークレット データについて話している場合は、すぐに ENV 変数 (データベースへのパスワードなど) からシークレット データをシークレットにプッシュし、シークレット クラスターを作成し、Deployment の ENV 説明で直接宣言していないことを示すことができます。この変数の値と、このデータベース パスワード変数の値がシークレットから読み取られます。 これは標準的な Kubernetes の動作です。 これは、アプリケーションを構成するための最も理想的なオプションです。 コード レベルで言えば、これは開発者にも当てはまります。 あなたが DevOps であれば、次のように尋ねることができます。「皆さん、アプリケーションに環境変数を読み取るように教えてください。 そして私たち全員が幸せになります。」

社内の全員が同じ名前の環境変数を読み取るのであれば、それは素晴らしいことです。 そのため、ある者は postgres データベースを待機し、他の者はデータベース名を待機し、他の者は他の何かを待機し、他の者は何らかの種類の dbn を待機するということが起こらないように、従って均一性が保たれます。

問題は、環境変数が多すぎて、Deployment を開くだけで XNUMX 行もの環境変数がある場合に発生します。 この場合、環境変数が大きくなりすぎただけなので、もう自分自身を苦しめる必要はありません。 この場合、構成の使用を開始するのが合理的です。 つまり、構成を使用するようにアプリケーションをトレーニングします。

唯一の疑問は、構成があなたが考えているものではないということです。 Config.pi は、使いやすい構成ではありません。 または、独自の形式の構成、またはギフトとして提供される構成 - これも私が意味する構成ではありません。

私が話しているのは、許容可能な形式での構成についてです。つまり、最も人気のある標準は .yaml 標準です。 読み方、人間が読める形式、アプリケーションからの読み方も明確です。

したがって、YAML に加えて、たとえば JSON を使用することもできます。そこからアプリケーション構成を読み取るという点では、解析は YAML とほぼ同じくらい便利です。 人々が読むのは著しく不便です。 フォーマットを試してみることができます。 人間の観点からは、これを読み取るのは非常に便利ですが、独自の構成を生成したい場合に、ini 形式はすでに生成するのに不便である可能性があるという意味で、自動的に処理するのは不便かもしれません。

しかし、いずれにせよ、どの形式を選択するにせよ、重要なのは、Kubernetes の観点からは非常に便利であるということです。 構成全体を Kubernetes 内の ConfigMap に配置できます。 次に、この構成マップを取得して、ポッド内の特定のディレクトリにマウントするように依頼します。アプリケーションは、この構成マップから構成を単なるファイルであるかのように読み取ります。 実際、これは、アプリケーションに多くの構成オプションがある場合に行うと良いことです。 あるいは、それは単なるある種の複雑な構造であり、ネストがあります。

configmap がある場合は、たとえば、configmap がマウントされているファイルの変更を自動的に追跡したり、構成が変更されたときにアプリケーションを自動的にリロードしたりするようにアプリケーションに非常にうまく教えることができます。 これは通常、理想的なオプションです。

繰り返しますが、これについてはすでに説明しました - 秘密情報は configmap にありません、秘密情報は変数にありません、秘密情報は秘密にありません。 そこから、この機密情報を外交に結び付けていきます。 通常、Kubernetes オブジェクト、デプロイメント、構成マップ、サービスのすべての記述を git に保存します。 したがって、それが社内にある git であっても、データベースにパスワードを git に入れるのは悪い考えです。 なぜなら、少なくとも git はすべてを記憶しており、そこからパスワードを削除するだけではそれほど簡単ではないからです。

健康診断

次のポイントは、これ、ヘルスチェックというものです。 一般に、ヘルスチェックは単にアプリケーションが動作していることをチェックすることです。 同時に、私たちは特定の Web アプリケーションについて話していることがほとんどですが、そのため、ヘルスチェックの観点から (ここではさらに翻訳しないほうがよいでしょう)、これは特別な URL となり、次のように処理されます。標準です、彼らは通常そうします /health.

したがって、この URL にアクセスすると、アプリケーションは「はい、大丈夫です、200 は大丈夫です」または「いいえ、すべて大丈夫ではありません、500 くらいです」と表示します。 したがって、アプリケーションが http ではなく、Web アプリケーションでもない場合は、ある種のデーモンについて話していることになり、ヘルスチェックを行う方法を理解できます。 つまり、アプリケーションが http でない場合はヘルス チェックなしですべてが動作し、これはいかなる方法でも実行できません。 ファイル内の一部の情報を定期的に更新したり、デーモン用の特別なコマンドを考え出すことができます。 daemon status「はい、すべて問題ありません。デーモンは動作しています。生きています。」と表示されます。

それはなんのためですか？ まず最も明白なことは、おそらくヘルスチェックが必要な理由、つまりアプリケーションが動作していることを理解するためです。 つまり、それはただの愚かなことであり、今起動しているときは、それが機能しているように見えるので、それが機能していることを確信できます。 そして、アプリケーションが実行され、コンテナが実行され、インスタンスが動作し、すべてが正常であることが判明しました。その後、ユーザーはすでにテクニカル サポートからの電話番号をすべて遮断し、「あなたは何ですか...、あなたは」と言いました。眠ってしまった、何も機能していない。」

ヘルスチェックは、ユーザーの観点からそれが機能しているかどうかを確認するための手段です。 方法の一つ。 このようにしましょう。 Kubernetes の観点から見ると、これはアプリケーションの開始時期を理解する方法でもあります。これは、コンテナーが起動、作成、開始されたときと、アプリケーションがこのコンテナー内で直接起動されたときとの間には違いがあることが理解されているためです。 なぜなら、平均的な Java アプリケーションをドックで起動しようとすると、XNUMX 秒間、場合によっては XNUMX 分間、さらには XNUMX 秒間でも、問題なく起動できるからです。 この場合、少なくともポートをノックすることはできますが、そこでは応答しません。つまり、まだトラフィックを受信する準備ができていません。

繰り返しますが、ヘルスチェックの助けと、ここでの方向転換の助けを借りて、Kubernetes では、アプリケーション内でコンテナーが起動しただけでなく、アプリケーション自体が起動し、すでに応答していることを理解できます。ヘルスチェック。つまり、そこにトラフィックを送信できることを意味します。

私が今話していることは、Kubernetes 内の Readiness/Liveness テストと呼ばれるものであり、したがって、私たちの Readiness テストは、バランシングにおけるアプリケーションの可用性を担当します。 つまり、アプリケーションで準備テストが実行されている場合は、すべてが正常であり、クライアント トラフィックがアプリケーションに送信されます。 準備テストが実行されない場合、アプリケーションは単純に参加しません。この特定のインスタンスはバランシングに参加せず、バランシングから削除され、クライアント トラフィックは流れません。 したがって、アプリケーションが停止した場合に再起動できるように、Kubernetes 内の Liveness テストが必要です。 Kubernetes で宣言されたアプリケーションに対して活性テストが機能しない場合、アプリケーションはバランシングから削除されるだけでなく、再起動されます。

ここで、言及しておきたい重要な点があります。実用的な観点から見ると、readiness テストは通常​​、liveness テストよりも頻繁に使用され、より頻繁に必要となります。 つまり、Kubernetes はそれができるので、準備テストとライブネス テストの両方を単純に宣言するのは、あまり良い考えではありません。 その理由を説明します。 テストの 200 番目のポイントは、ヘルスチェックで基礎となるサービスをチェックすることをお勧めするためです。 これは、何らかの情報を提供する Web アプリケーションがある場合、当然のことながら、その情報をどこかから取得する必要があることを意味します。 たとえばデータベース内。 この REST API に入ってくる情報は同じデータベースに保存されます。 したがって、ヘルスチェックが単に連絡先のスラッシュヘルスと同じように応答した場合、アプリケーションは「200、オーケー、すべて問題ありません」と表示し、同時にアプリケーションのデータベースにアクセスできなくなり、ヘルスチェック アプリケーションは「XNUMX、オーケー、すべて問題ありません」と応答します。 」 - これは悪い健康診断です。 これは本来の動作ではありません。

つまり、アプリケーションにリクエストが来たとき、 /health単に「200、ok」と応答するのではなく、まずデータベースにアクセスして接続を試み、200 つを選択するなどの非常に基本的な操作を行い、接続があるかどうかを確認するだけです。データベースを作成し、データベースにクエリを実行できます。 これがすべて成功した場合、答えは「XNUMX、OK」です。 成功しない場合は、エラーが発生し、データベースが利用できないことが表示されます。

したがって、この点に関して、Readiness/Liveness テストに再び戻ります。Readiness テストが必要である可能性が最も高いのに、Liveness テストに疑問がある理由です。 なぜなら、先ほど述べたとおりにヘルスチェックを記述すると、インスタンス部分ではヘルスチェックが利用できないことが判明するからです。в или со всех instanceたとえばデータベース内。 準備テストを宣言すると、ヘルスチェックが失敗し始めたため、データベースにアクセスできないすべてのアプリケーションは単にバランス調整をオフにし、実際には無視された状態で「ハング」し、データベースが回復するのを待ちます。仕事。

ライブネス テストを宣言した場合、データベースが破損し、ライブネス テストが失敗したために Kubernetes ですべての半分が再起動し始めると想像してください。 つまり、再起動する必要があります。 これはあなたが望んでいることではありません。私自身も実際に経験したことがあります。 JS で書かれ、Mongo データベースに入力されたチャット アプリケーションがありました。 そして問題は、私が Kubernetes を使って仕事を始めた当初、Kubernetes で実行できるという原則に基づいてテストの準備性と稼働性を説明したため、Kubernetes を使用するということでした。 したがって、ある時点で Mongo は少し「鈍くなり」、サンプルは失敗し始めました。 したがって、降雨量テストによると、サヤは「殺し」始めました。

ご理解のとおり、彼らが「殺された」とき、これはチャットです。つまり、クライアントからの接続がたくさん接続されています。 また、それらは「強制終了」されます - いいえ、クライアントではなく、接続のみです - すべて同時にではなく、同時に強制終了されないという事実により、一部は早く、一部は後で、同時に開始されません。時間。 さらに、標準的なランダムでは、アプリケーションの開始時間を毎回ミリ秒の精度で予測することはできないため、一度に XNUMX つのインスタンスずつ実行されます。 XNUMX つの Infospot が上昇し、バランシングに追加され、すべてのクライアントがそこに来ますが、単独であるため、そのような負荷に耐えることができません。大まかに言えば、そこでは数十の情報スポットが作業しているため、低下します。 次の人が立ち上がると、すべての負荷が彼にかかり、彼も倒れます。 そうですね、これらの滝は滝のように流れ続けます。 結局、これはどのように解決されたのかというと、このアプリケーションへのユーザー トラフィックを厳密に停止し、すべてのインスタンスを起動してから、すべてのユーザー トラフィックを一度に開始して、XNUMX 個のインスタンスすべてに分散されるようにするだけでした。

すべての再起動が強制されるこのライブネス テストが発表されていなければ、アプリケーションは問題なく処理したでしょう。 しかし、データベースにアクセスできず、すべてのユーザーが「落ちた」ため、バランス調整からすべてが無効になっています。 このデータベースが利用可能になると、すべてがバランシングに含まれますが、アプリケーションを再度起動する必要はなく、これに時間とリソースを浪費する必要もありません。 それらはすべてすでにここにあり、トラフィックの準備ができているため、トラフィックが開くだけで、すべてが正常です。アプリケーションは適切に配置されており、すべてが引き続き動作します。

したがって、readiness テストと liveness テストは異なります。さらに、理論的には、たとえば XNUMX つのタイプの radii と XNUMX つのタイプの liv など、異なるヘルスチェックを実行して、さまざまなことをチェックすることができます。 準備テスト中に、バックエンドを確認してください。 また、たとえば、活性テストでは、活性テストは一般にアプリケーションが応答しているだけであるという観点から、アプリケーションが応答できるかどうかを確認しません。

なぜなら、生存テストは概して、私たちが「行き詰まった」ときだからです。 無限ループが開始されたか、その他の理由で、それ以上のリクエストは処理されません。 したがって、それらを分離し、それらに異なるロジックを実装することさえ意味があります。

検査や健康診断の際に答える必要があることについて。 それは本当に苦痛です。 これに詳しい人はおそらく笑うでしょう - しかし真剣に、私はこれまでの人生で、200% のケースで「XNUMX」と答えるサービスを見てきました。 つまり、誰が成功するのかということです。 しかし同時に、応答の本文には「これこれのエラー」と書かれています。

つまり、すべてが成功したという応答ステータスが表示されます。 しかし同時に、本文を解析する必要があります。なぜなら、本文には「申し訳ありませんが、リクエストはエラーで終了しました」と表示されているからです。これはまさに現実です。 これを実際に見ました。

面白いと思わない人もいれば、非常に苦痛だと感じる人もいるかもしれないので、それでも単純なルールに従う価値があります。 ヘルスチェック、および原則として Web アプリケーションを操作する場合。

すべてがうまくいった場合は、204 番目の答えで応答します。 原則として、5 番目の答えはどれでも当てはまります。 ragsy をよく読んで、一部の応答ステータスが他の応答ステータスと異なることがわかっている場合は、適切なステータス (10、15、502、XNUMX など) で答えてください。 あまり良くなかったら「ツーゼロゼロ」でいい。 すべてがうまくいかず、ヘルスチェックが応答しない場合は、XNUMX 分の XNUMX で答えてください。 繰り返しますが、対応方法、さまざまな対応ステータスが互いにどのように異なるかを理解していればです。 理解できない場合は、何か問題が発生した場合にヘルスチェックに応答するオプションは XNUMX です。

これはもう XNUMX つの点ですが、基盤となるサービスの確認について少し戻りたいと思います。 たとえば、アプリケーションの背後にあるすべての基礎となるサービス (一般的にすべて) をチェックし始めるとします。 マイクロサービス アーキテクチャの観点から理解すると、「低結合」、つまりサービスの相互依存が最小限であるという概念があります。 そのうちの XNUMX つが失敗しても、この機能を持たない他のすべての機能はそのまま動作し続けます。 一部の機能が動作しません。 したがって、すべてのヘルスチェックを相互に結び付けると、インフラストラクチャで XNUMX つのものが失敗することになります。そして、それが失敗したため、すべてのサービスのすべてのヘルスチェックも失敗し始めます。そして、一般に、インフラストラクチャがより多く存在します。マイクロサービス アーキテクチャ全体 No. そこですべてが真っ暗になりました。

したがって、基盤となるサービスを確認する必要があることをもう一度繰り返したいと思います。これらのサービスがなければ、XNUMX% の場合、アプリケーションは機能できません。 つまり、ユーザーがデータベースに保存したり、データベースから取得したりするための REST API がある場合、データベースがなければ、ユーザーとの連携を保証できないのは当然です。

ただし、ユーザーをデータベースから取り出すときに、フロントエンドに応答を送信する前に入力する、別のバックエンドからの他のメタデータでさらに強化され、このバックエンドが利用できない場合、これは、メタデータの一部を含めずに回答します。

次に、アプリケーションの起動時に厄介な問題が XNUMX つあります。

実際、これは Kubernetes 全般に当てはまることではなく、たまたま、ある種の大量開発、特に DevOps の文化が Kubernetes とほぼ同時期に広がり始めたのです。 したがって、概して、Kubernetes を使用せずにアプリケーションを正常にシャットダウンする必要があることがわかります。 Kubernetes が登場する前から、人々はこれを行っていましたが、Kubernetes の出現により、私たちはそれについて一斉に話し始めました。

グレースフルシャットダウン

一般に、正常なシャットダウンとは何ですか?また、それが必要な理由は何ですか? これは、アプリケーションが何らかの理由でクラッシュしたときのことです。次のことを行う必要があります。 app stop - または、たとえばオペレーティング システムからシグナルを受信した場合、アプリケーションはそれを理解し、それに対して何らかの処理を行う必要があります。 もちろん、最悪のシナリオは、アプリケーションが SIGTERM を受け取り、「SIGTERM、ちょっと待って、作業しましょう。何もしないでください」というような場合です。 これはまったく悪い選択肢です。

ほぼ同様に悪い選択肢は、アプリケーションが SIGTERM を受け取り、「segterm と言った、つまり終了することを意味します、見ていません、ユーザーのリクエストがわかりません、どのようなリクエストなのかわかりません」というような場合です。私が現在取り組んでいるリクエストについて、彼らは SIGTERM、つまり終了することを意味すると言いました。」 これも悪い選択肢です。

どのオプションが良いでしょうか? XNUMXつ目のポイントは、業務の完了を考慮することです。 適切なオプションは、サーバーが SIGTERM を受信した場合の動作を考慮することです。

SIGTERM はソフト シャットダウンであり、特別に設計されており、コード レベルでインターセプトでき、処理できます。たとえば、「さあ、待ってください。まず作業を完了してから終了します。」

Kubernetes の観点から見ると、次のようになります。 Kubernetes クラスター内で実行中のポッドに「停止してください、去ってください」と言うと、再起動されたり、Kubernetes がポッドを再作成するときに更新が発生したりすると、Kubernetes は同じ SIGTERM メッセージをポッドに送信し、待機します。しばらくの間、そしてこれは彼が待つ時間であり、これも設定されており、ディプロマにはそのような特別なパラメータがあり、それはGraceful ShutdownTimeoutと呼ばれます。 ご理解のとおり、それは無駄にそう呼ばれているわけではありませんし、私たちが今それについて話しているのも無駄ではありません。

そこでは、SIGTERM をアプリケーションに送信してから、アプリケーションが何かでおかしくなったか、「スタック」して終了しないことがわかった時点までに、どのくらいの時間を待つ必要があるかを具体的に言うことができます。 SIGKILL を送信します。つまり、その作業をハード完了します。 つまり、何らかのデーモンが実行されており、操作が処理されます。 デーモンが実行する操作は、平均して一度に 30 秒以上続かないことを理解しています。 したがって、SIGTERM が到着すると、デーモンは SIGTERM 後最大 30 秒以内に終了できることがわかります。 念のため、たとえば 45 秒と書いて、SIGTERM と言います。 その後、45 秒待ちます。 理論的には、この間に悪魔はその仕事を完了し、自滅するはずです。 しかし、突然できなくなった場合は、おそらくスタックしている可能性が高く、リクエストを正常に処理できなくなっていることを意味します。 そして実際、45 秒以内に安全に彼を釘付けにすることができます。

そしてここでは、実際には 2 つの側面も考慮に入れることができます。 まず、リクエストを受け取った場合は、何らかの方法でそのリクエストの処理を開始し、ユーザーに応答を返さなかったものの、たとえば SIGTERM を受け取ったということを理解してください。 それを改良してユーザーに答えを提供することは理にかなっています。 これがこの点での XNUMX 番目のポイントです。 ここでの XNUMX 番目のポイントは、独自のアプリケーションを作成する場合、通常、アプリケーションのリクエストを受信して​​から作業を開始し、どこかからファイルをダウンロードしたり、データベースをダウンロードしたりするような方法でアーキテクチャを構築することです。それ。 一般に、ユーザー、あなたのリクエストは XNUMX 分間ハングし、あなたが彼に答えるのを待ちます。その後、おそらくアーキテクチャに取り組む必要があります。 つまり、操作が短い場合は、SIGTERM を無視して変更するのが理にかなっているという常識さえ考慮に入れてください。 操作が長い場合、この場合に SIGTERM を無視しても意味がありません。 このような長時間の操作を回避するには、アーキテクチャを再設計するのが合理的です。 ユーザーがただぶらぶらして待つことがないようにするためです。 わかりません。そこにある種の Web ソケットを作成し、サーバーがすでにクライアントに送信するリバースフックを作成します。その他何でもできますが、ユーザーを XNUMX 分間強制的にハングさせず、セッションが完了するまで待機する必要はありません。彼に答えてください。 どこで壊れるか予測できないからです。

アプリケーションが終了するときは、適切な終了コードを提供する必要があります。 つまり、アプリケーションが閉じるか停止するように要求され、アプリケーションが正常に停止できた場合は、何らかの終了コード 1,5,255、0、0 などを返す必要はありません。 少なくとも Linux システムでは、ゼロコードでないものはすべて失敗とみなされます。 つまり、この場合、アプリケーションはエラーで終了したと見なされます。 したがって、友好的な方法で、アプリケーションがエラーなしで完了した場合、出力では XNUMX と表示されます。 アプリケーションが何らかの理由で失敗した場合、出力では非 XNUMX と表示されます。 そして、この情報を活用して作業することができます。

そして最後の選択肢。 ユーザーがリクエストを送信し、その処理中に XNUMX 分間ハングするのは問題です。 しかし、一般的に、クライアント側から見て一般的に価値があることについてもお話したいと思います。 モバイル アプリケーションやフロントエンドなどを持っているかどうかは関係ありません。 一般に、ユーザーのセッションは終了する可能性があり、あらゆることが起こる可能性があることを考慮する必要があります。 たとえば、リクエストが送信されても​​処理が不十分で、応答が返されない可能性があります。 フロントエンドまたはモバイル アプリケーション (フロントエンド全般、そう言えましょう) は、これを考慮する必要があります。 WebSocket を使用する場合、これは私がこれまでに経験した中で最もひどい苦痛です。

通常のチャットの開発者がそれを知らないと、WebSocket が壊れる可能性があることが判明しました。 彼らにとって、プロキシで何かが起こったとき、設定を変更するだけでリロードが行われます。 当然のことながら、この場合、存続期間の長いセッションはすべて破棄されます。 開発者が私たちのところに走ってきて、こう言います。「皆さん、何をしているのですか。すべてのクライアントのチャットが中断されました。」 私たちは彼らにこう言います。 クライアントは再接続できませんか? 彼らはこう言います。「いいえ、セッションが中断されないようにする必要があります。」 要するに、これは実際にはナンセンスです。 クライアント側を考慮する必要があります。 特に、先ほども言ったように、WebSocket などの存続期間の長いセッションではセッションが中断される可能性があり、ユーザーが気付かないうちにそのようなセッションを再インストールできる必要があります。 そして、すべてが完璧になります。

リソース

実は、ここでストレートな話をします。 またしても実生活から。 資源について今まで聞いた中で最も不快な話。

この場合のリソースとは、Kubernetes クラスター内のポッドに設定できるある種のリクエスト、制限を意味します。 開発者から聞いた中で最も面白かったのは... 以前の職場での開発仲間の一人は、かつてこう言いました。「私のアプリケーションはクラスター内で起動しません。」 私はそれが始まっていないことを確認しましたが、リソースに収まらなかったか、非常に小さな制限が設定されていたかのどちらかでした。 つまり、リソースが原因でアプリケーションを起動できません。 私はこう言います。「リソースがあるから始まるわけではありません。必要な量を判断し、適切な値を設定してください。」 彼はこう言います。「どのようなリソースですか?」 私は彼に、Kubernetes、リクエストの制限、そしてなんとか、何とか、なんとか設定する必要があることを説明し始めました。 その男性はXNUMX分間話を聞き、うなずいてこう言いました。「私は開発者として働くためにここに来ました。リソースについては何も知りたくないのです。」 コードを書くためにここに来ただけです。」 悲しいですね。 これは開発者の観点からすると非常に悲しい概念です。 特に、いわば進歩的な Devop の現代世界では。

そもそもなぜリソースが必要なのでしょうか? Kubernetes には 2 種類のリソースがあります。 リクエストと呼ばれるものもあれば、制限と呼ばれるものもあります。 リソースによって、基本的に常に XNUMX つの基本的な制限のみがあることが理解されます。 つまり、Kubernetes で実行されるコンテナーの CPU 時間制限と RAM 制限です。

制限により、アプリケーションでのリソースの使用方法に上限が設定されます。 つまり、制限内に 1 GB の RAM があるとすると、アプリケーションは 1 GB を超える RAM を使用できなくなります。 そして、彼が突然これを望んで実行しようとすると、oom Killerと呼ばれるプロセスがメモリ不足でやって来て、アプリケーションを強制終了します。つまり、アプリケーションは単に再起動されます。 アプリケーションは CPU に基づいて再起動されません。 CPU に関しては、アプリケーションが制限で指定された量を超えて大量に使用しようとすると、CPU が厳密に選択されます。 これでは再起動にはつながりません。 これが限界です - これが上限です。

そして、リクエストがあります。 リクエストは、Kubernetes クラスター内のノードにアプリケーションがどのように配置されるかを Kubernetes が理解する方法です。 つまり、リクエストはアプリケーションのコミットの一種です。 そこには、「これくらいの CPU とこれくらいのメモリを確保してほしい」という使いたいことが書かれています。 とても単純なたとえです。 わかりませんが、合計 8 個の CPU を備えたノードがある場合はどうなるでしょうか。 そしてそこにポッドが到着しますが、そのリクエストには 1 CPU が含まれており、これはノードに 7 CPU が残っていることを意味します。 つまり、8 つのポッドがこのノードに到着し、それぞれのリクエストに 1 つの CPU が含まれるとすぐに、そのノードは、Kubernetes の観点から見ると CPU が不足し、リクエストを持つそれ以上のポッドを作成できなくなります。このノードで起動されました。 すべてのノードで CPU が不足すると、Kubernetes は、CPU が不足したためにポッドを実行するのに適したノードがクラスター内に存在しないと通知し始めます。

なぜリクエストが必要なのでしょうか?また、リクエストがなければ、Kubernetes で何も起動する必要がないのはなぜでしょうか? 仮定の状況を想像してみましょう。 リクエストなしでアプリケーションを起動すると、Kubernetes は、どれだけのものを持っているか、どのノードにプッシュできるかを知りません。 さて、彼はノードを押し、押し、押し込みます。 ある時点で、アプリケーションへのトラフィックの受信が開始されます。 そして、アプリケーションの XNUMX つが突然、制限に応じた制限までリソースを使用し始めます。 近くに別のアプリケーションがあり、それもリソースを必要としていることがわかりました。 ノードは実際に、OP などのリソースを物理的に使い果たし始めます。 ノードは実際に、ランダム アクセス メモリ (RAM) などのリソースを物理的に使い果たし始めます。 ノードの電力がなくなると、まず Docker が応答を停止し、次に cubelet、次に OS が応答を停止します。 彼らは単に意識を失い、すべてが間違いなく機能しなくなります。 つまり、これによりノードがスタックしてしまい、ノードを再起動する必要があります。 一言で言えば、状況はあまり良くありません。

また、リクエストがある場合、その制限は制限やリクエストとそれほど変わらない、少なくとも何倍にもならない場合、Kubernetes クラスターのノード全体でアプリケーションを正常かつ合理的に満たすことができます。 同時に、Kubernetes は、何がどこにどれだけ配置され、何がどこで使用されているかをほぼ認識します。 つまり、まさにそんな瞬間なのです。 それを理解することが重要です。 そして、これが示されるように制御することが重要です。

データ保存

次のポイントはデータストレージについてです。 それらをどうするか、そして一般に、Kubernetes の永続性をどうするか?

もう一度私たちの中で思うのは、 イブニングスクール、Kubernetesのデータベースに関する話題がありました。 そして、「Kubernetes でデータベースを実行することは可能ですか?」と質問されたときに同僚が何と言ったか、おおよそ知っているような気がします。 どういうわけか、同僚は、Kubernetes でデータベースを実行できるかどうかという質問をしているのであれば、それは不可能であると答えるべきだったのではないかと私には思えます。

ここでのロジックは単純です。 念のため、もう一度説明します。もしあなたが分散型ネットワーク ストレージのかなりフォールト トレラントなシステムを構築できる本当に優れた人であれば、このケースにデータベースを適合させる方法や、コンテナ内のクラウド ネイティブがどのように機能するかを理解している必要があります。データベース全般で。 おそらく、それを実行する方法について疑問を持たないでしょう。 このような疑問があり、それがすべて展開され、本番環境で死ぬまで耐え、決して落ちないことを確認したい場合、そのようなことは起こりません。 このアプローチでは、間違いなく自分の足を撃つことになります。 だから、しないほうがいいのです。

アプリケーションが保存したいデータ、ユーザーがアップロードした写真、アプリケーションの動作中 (起動時など) に生成されたものはどうすればよいでしょうか? Kubernetes ではそれらをどうすればよいでしょうか?

一般に、理想的には、はい、もちろん、Kubernetes は非常によく設計されており、通常、当初はステートレス アプリケーション用に考えられていました。 つまり、情報をまったく保存しないアプリケーションの場合です。 これが理想的です。

しかし、もちろん、理想的な選択肢が常に存在するとは限りません。 だから何？ 最初の最も簡単なポイントは、ある種の S3 を入手することです。自家製のものではなく、それがどのように機能するかは不明ですが、プロバイダーから提供されています。 優れた通常のプロバイダー - アプリケーションに S3 を使用するように教えます。 つまり、ユーザーがファイルをアップロードしたいときに、「S3 にアップロードしてください」と言います。 彼がそれを受け取りたいときは、「ここに S3 へのリンクがあります。ここから受け取ってください。」と言います。 これが理想的です。

何らかの理由でこの理想的なオプションが突然適切ではなくなった場合、自分が作成したものではないアプリケーション、自分が開発したものではないアプリケーション、またはある種のひどいレガシーである場合、そのアプリケーションは S3 プロトコルを使用できませんが、ローカル ディレクトリで動作する必要があります。ローカルフォルダー。 多かれ少なかれ単純なこととして、Kubernetes をデプロイします。 つまり、いくつかの最小限のタスクのためにすぐに Ceph をフェンシングするのは悪い考えであるように私には思えます。 Ceph はもちろん良いし、ファッショナブルだからです。 しかし、自分が何をしているのかよく理解していない場合は、一度 Ceph に何かを置いたら、非常に簡単に、そして二度とそこから取り出すことができなくなります。 ご存知のとおり、Ceph は単純なファイルの形式ではなく、バイナリ形式でクラスタにデータを保存するためです。 したがって、Ceph クラスターが突然故障すると、そこからデータを再び取得できなくなる可能性が高くなります。

Ceph に関するコースを開催します。 プログラムについてよく理解し、申請書を提出してください.

したがって、NFS サーバーのような単純なものを使用することをお勧めします。 Kubernetes はそれらと連携でき、NFS サーバーの下にディレクトリをマウントできます。アプリケーションはローカル ディレクトリと同じです。 同時に、当然のことながら、やはり NFS で何かをする必要があること、アクセスできなくなる場合があることを理解し、この場合に何をするかという問題を検討する必要があることを理解する必要があります。 おそらく、別のマシンのどこかにバックアップする必要があります。

次にお話ししたのは、アプリケーションが動作中にファイルを生成した場合にどうするかということです。 たとえば、アプリケーションが起動時にのみ受信する情報に基づいて、静的ファイルが生成されます。 なんて瞬間でしょう。 そのようなデータがあまりない場合は、わざわざこのアプリケーションを自分でインストールして作業するだけです。 ここでの唯一の疑問は、何をするかということです。 非常に多くの場合、WordPress などのあらゆる種類のレガシー システム、特に改良されたある種の賢いプラグインや賢い PHP 開発者は、自分で何らかのファイルを生成する方法を知っていることがよくあります。 したがって、XNUMX つ目は XNUMX つのファイルを生成し、XNUMX つ目は XNUMX つ目のファイルを生成します。 それらは違う。 クライアントの Kubernetes クラスター内でバランシングは単に偶然に発生します。 したがって、彼らは実際にどのように協力するかを知らないことがわかりました。 XNUMX つはある情報をユーザーに提供し、もう XNUMX つはユーザーに別の情報を提供します。 これは避けるべきことです。 つまり、Kubernetes では、起動するものはすべて複数のインスタンスで動作することが保証されています。 Kubernetes は動くものだからです。 したがって、彼は誰にも頼まなくても、いつでも好きなときに何でも動かすことができます。 したがって、これを頼りにする必要があります。 XNUMX つのインスタンスで起動されたものはすべて、遅かれ早かれ失敗します。 予約が多ければ多いほど良いです。 しかし、繰り返しになりますが、そのようなファイルがいくつかある場合は、それらをすぐ下に置くことができます。それらの重量はわずかです。 もう少し多い場合は、コンテナ内に押し込まないほうがよいでしょう。

Kubernetes にはボリュームを使用できるという素晴らしい機能があることをお勧めします。 特に、タイプが空のディレクトリのボリュームがあります。 つまり、Kubernetes は、起動したサーバー上のサービス ディレクトリにディレクトリを自動的に作成するだけです。 そして、あなたがそれを使えるように、彼はそれをあなたに与えます。 重要な点が XNUMX つだけあります。 つまり、データはコンテナー内ではなく、実行中のホストに保存されます。 さらに、Kubernetes は通常の構成でそのような空のディレクトリを制御でき、その最大サイズを制御してそれを超えないようにすることができます。 唯一のポイントは、空のディレクトリに書き込んだ内容がポッドの再起動時に失われないことです。 つまり、ポッドが誤って落ちて再び立ち上がった場合、空のディレクトリ内の情報はどこにも行きません。 彼は新たなスタート時にそれを再び使用できる - それは良いことだ。 あなたのポッドがどこかに去った場合、当然のことながら、彼はデータなしで去ります。 つまり、空のディレクトリで起動されたノードのポッドが消えるとすぐに、空のディレクトリは削除されます。

空のディレクトリには他に何が良いのでしょうか? たとえば、キャッシュとして使用できます。 私たちのアプリケーションがその場で何かを生成し、ユーザーに提供し、それを長時間実行すると想像してみましょう。 したがって、アプリケーションは、たとえば、それを生成してユーザーに提供すると同時に、それをどこかに保存します。これにより、ユーザーが次に同じものを求めに来たときに、すぐに生成したものを提供する方が速くなります。 空のディレクトリをメモリ内に作成するように Kubernetes に要求できます。 したがって、ディスク アクセス速度の点で、キャッシュは通常、超高速で動作します。 つまり、メモリ内に空のディレクトリがあり、OS ではメモリに保存されますが、ポッド内のユーザーにとっては、単なるローカル ディレクトリのように見えます。 特別に魔法を教えるためにアプリは必要ありません。 ファイルを直接取得してディレクトリに配置するだけですが、実際には OS 上のメモリに配置されます。 これは Kubernetes の観点からも非常に便利な機能です。

ミニオはどんな悩みを抱えているのでしょうか？ Minio の主な問題は、これが動作するためにはどこかで実行されている必要があり、何らかのファイル システム、つまりストレージが必要であることです。 そしてここで、Ceph が抱えているのと同じ問題に遭遇します。 つまり、Minio はファイルをどこかに保存する必要があります。 これは単にファイルへの HTTP インターフェイスです。 しかもAmazonのS3と比べると明らかに機能が劣っています。 以前は、ユーザーを適切に認証できませんでした。 私の知る限り、すでに異なる権限を持つバケットを作成できますが、やはり主な問題は、いわば基盤となるストレージ システムにあるように思えます。

メモリ内の空のディレクトリは制限にどのように影響しますか? 制限にはまったく影響しません。 これはコンテナのメモリではなく、ホストのメモリにあります。 つまり、コンテナはメモリ内の空のディレクトリを占有メモリの一部として認識しません。 ホストはこれを見ます。 したがって、はい、Kubernetes の観点から、これを使用し始めるときは、メモリの一部を空のディレクトリに費やしていることを理解するのが良いでしょう。 したがって、アプリケーションだけでなく、誰かがこれらの空のディレクトリに書き込むことによってもメモリが不足する可能性があることを理解してください。

クラウドネイティブネス

そして最後のサブトピックは、Cloudnative とは何かということです。 なぜ必要なのでしょうか? クラウドネイティブネスなど。

つまり、最新のクラウド インフラストラクチャで機能し、動作するように記述されたアプリケーションです。 しかし、実はCloudnativeにはもう一つそのような側面があります。 これは、最新のクラウド インフラストラクチャのすべての要件を考慮したアプリケーションであるだけでなく、この最新のクラウド インフラストラクチャと連携する方法を熟知しており、これらのクラウドで動作するという事実の長所と短所を活用します。 単にやりすぎてクラウドで作業するのではなく、クラウドで作業する利点を活用してください。

Kubernetes を例に挙げてみましょう。 アプリケーションは Kubernetes で実行されています。 アプリケーションはいつでも、あるいはアプリケーションの管理者はいつでもサービス アカウントを作成できます。 つまり、Kubernetes 自体のサーバー内の承認用のアカウントです。 そこに必要な権利をいくつか追加します。 また、アプリケーション内から Kubernetes にアクセスできます。 この方法で何ができるでしょうか？ たとえば、アプリケーションから、他のアプリケーションや他の同様のインスタンスがどこにあるかに関するデータを受け取り、必要に応じて何らかの方法で Kubernetes 上にクラスタリングします。

繰り返しになりますが、文字通り最近事件が発生しました。 キューを監視するコントローラーが XNUMX つあります。 そして、いくつかの新しいタスクがこのキューに現れると、それは Kubernetes に送られ、Kubernetes 内で新しいポッドが作成されます。 このポッドに新しいタスクを与え、このポッドのフレームワーク内でポッドはタスクを実行し、コントローラー自体に応答を送信し、コントローラーはこの情報を使用して何らかの処理を行います。 たとえば、データベースを追加します。 つまり、繰り返しになりますが、これはアプリケーションが Kubernetes で実行されるという事実の利点です。 組み込みの Kubernetes 機能自体を使用して、アプリケーションの機能を拡張してより便利にすることができます。 つまり、アプリケーションの起動方法やワーカーの起動方法に関するある種の魔法を隠さないでください。 Kubernetes では、アプリケーションが Python で記述されている場合、アプリケーション内でリクエストを送信するだけです。

Kubernetes を超えた場合にも同じことが当てはまります。 Kubernetes はどこかで実行されていますが、何らかのクラウド上にあれば問題ありません。 繰り返しになりますが、私たちは、実行しているクラウド自体の機能を使用することができ、使用すべきだとさえ思います。 クラウドが提供する基本的なものから。 バランシング、つまりクラウドバランサーを作成して使用できます。 これは、私たちが使用できるものの直接的な利点です。 なぜなら、クラウドのバランシングは、第一に、その仕組みや構成に対する責任を愚かにも私たちから取り除くだけだからです。 さらに、通常の Kubernetes はクラウドと統合できるため、非常に便利です。

スケーリングについても同様です。 通常の Kubernetes はクラウド プロバイダーと統合できます。 クラスターでノードが不足した場合、つまりノードのスペースが不足した場合、追加する必要があることを理解する方法を知っています。Kubernetes 自体が新しいノードをクラスターに追加し、それらのノード上でポッドの起動を開始します。 つまり、荷物が来ると、炉の数が増え始めます。 クラスター内のノードでこれらのポッドが不足すると、Kubernetes は新しいノードを起動するため、ポッドの数はさらに増加する可能性があります。 そしてとても便利です。 これは、クラスターをオンザフライでスケールする直接的な機会です。 新しいノードを追加するのに XNUMX 秒ではなく、XNUMX 分ほどかかるという意味では、それほど高速ではありません。

しかし、私の経験から言えば、これは私が今まで見た中で最もクールなものです。 Cloudnative クラスターが時刻に基づいてスケーリングされたとき。 これはバックオフィスの人々が使用するバックエンド サービスでした。 つまり、彼らは午前 9 時に出勤し、システムへのログインを開始します。それに応じて、すべてが実行されている Cloudnative クラスターが膨張し始め、出勤する全員がアプリケーションを操作できるように、新しいポッドが起動されます。 午後 8 時または午後 6 時に退社すると、Kubernetes クラスターはアプリケーションをもう誰も使用していないことに気づき、縮小し始めます。 最大 30% の節約が保証されます。 当時のアマゾンではそれがうまくいきましたが、当時ロシアにはこれほど上手にできる人はいませんでした。

率直に言いますが、単純に Kubernetes を使用し、クラウドの機能を活用しているため、節約率は 30% です。 これがロシアでも実現できるようになりました。 もちろん、誰にも宣伝するつもりはありませんが、これを実行できるプロバイダーがあり、ボタンを使ってすぐに提供できるとだけ言っておきましょう。

最後にもう XNUMX つ注意していただきたい点があります。 アプリケーションやインフラストラクチャを Cloudnative にするためには、最終的に Infrastructure as a Code と呼ばれるアプローチの適応を開始するのが理にかなっています。コード アプリケーションやビジネス ロジックをコードの形式で記述します。 そして、それをコードとして扱います。つまり、テストし、展開し、git に保存し、CICD を適用します。

これにより、第一に、インフラストラクチャを常に制御し、インフラストラクチャがどのような状態にあるかを常に把握できるようになります。 次に、エラーを引き起こす手動操作を避けてください。 第三に、同じ手動タスクを常に実行する必要がある、いわゆる離職を避けてください。 XNUMX 番目に、障害が発生した場合に、より迅速に回復できるようになります。 ロシアでは、私がこのことについて話すたびに、いつも膨大な数の人がこう言う。「はい、それは明らかですが、アプローチはあります。要するに、何も修正する必要はありません。」 しかし、それは本当です。 インフラストラクチャで何かが壊れた場合、Cloudnative アプローチの観点およびコードとしてのインフラストラクチャの観点からすると、それを修正するよりも、サーバーにアクセスして何が壊れているのかを特定して修正する方が簡単です。サーバーを削除して再度作成します。 そして、これをすべて復元します。

これらすべての問題については、以下で詳しく説明されています。 Kubernetes ビデオ コース: ジュニア、ベーシック、メガ。 リンクをたどることで、プログラムと条件を理解することができます。 便利なのは、自宅や職場で1日2〜XNUMX時間勉強するだけでKubernetesをマスターできることです。

出所： habr.com