生産の経験
1、限制了容器资源，还经常被杀死？
2、滚动更新之健康检查重要性
3、滚动更新之流量的丢失私は、コンテナのリソースを制限し、最初の質問についてお話しましょう、だけでなく、多くの場合、その理由は、殺すために？
すぐにそのJavaアプリケーションの展開、および再起動し、再起動が実際にあなたのポッドが不健康であることを意味し、再構築され、その後、再K8Sは、あなたがプルアップするのに役立つので、我々は問題を探してください調査に、白が実際に殺されていることを言って、あなたがイベントを見るために記述することができ、通常ので健康チェックのそれはjavaアプリケーションであるため、ヒープオーバーフローするので、再び引っ張られた後、通過しないことがわかります私が遭遇したの前にして、それがデータのやり取りを行うヒープ自体がJVMを持つメモリ、JVMのメインメモリをロックされていないということです、その再起動の理由を見て、フィールドの最後の行を殺すログに表示されます、殺しますそれは、ヒープメモリは、主にデザインの業績に反映されているので、彼は簡単にそれを超えて、ヒープメモリを超える可能性があり、それが限度を超えているためK8Sは、それを殺す理由K8Sを殺される可能性がある、デフォルトドリフトを達成するために、ホスト全体に影響する制約をリソースでない場合、コンテナは、ホストにすべてのリソースを使用し、リソースの全体のホストが不十分となり、それが他に転送されます マシンでは、その後、異常な、それは、関連するアバランシェ効果を果たしている可能性がある一般的に、我々は、リソースの制約を行い、この制限を行うにしているので、あなたはJavaアプリケーションを制限することはできませんか？K8Sアプリケーションをデプロイが、それは、まだ非常に便利ですが、Javaアプリケーションの展開または互換性のない、他の制限であることができなかった
ように、それは現在のJavaコンテナの限界を認識していない、我々だけで指定された限界を認識することができない、つまり、あなたはYAMLに行くように制限がK8S自体、それはこの戦略を持って、メモリコンテナが限定されるものではないが、それは制限が限界を超えている場合、K8Sはそれを殺すだろう、この制限を超えるヒープリミットはこの容量を超えている場合、それはあなたを助けます殺し、その後、あなたはプルアップに役立ちます。
このJavaのヒープメモリとトラフィックバーストを少し直面し、それがテーブル上の情報の利用可能なので、この範囲は非常に大きく、これはK8S殺すつながり、その後のサイクルをプルアップされ、1日には、いくつかのかもしれませんこの効果の百分の。
そのことについては、実際には、このリソースの制限または実行するには、このドッキングウィンドウを使用するが、彼は変換K8S、どのようにリソースの制約を解決するためのドッキングウィンドウが、K8Sは作る方法を、実際には、いくつかの制限を行うためのインターフェースを呼び出しますこの問題を解決するために、制限のJavaヒープメモリを識別するために、ドッカー。
次いで、これをJavaヒープメモリを使用するように構成されている二つのオプションがある。この問題を解決するために
、構成Javaヒープメモリの使用量
のJava -Xmx最大ヒープメモリ使用量が、-Xms初期ヒープメモリ使用量があり
、一般的に最大に設定されていますヒープメモリ使用量は、この設定を超えて設定しない場合は、ヒープ・メモリ・オーバーフローの現象の出現は、これは非常に一般的ですが、十分ではありません物理メモリで、その結果、メモリのホストを使用していきます、私たちは、ときに高速-Xmxが使用されているこのJavaを使用します。とき、完全な、それは、ガベージコレクションを持っているし、その後のサイクルを使用しますが、これはこのJavaのアプリケーションの安定した動作を保証します、我々はリソース制限を設定するには、YAMLすべては間違いなく十分ではありません、我々は、Javaのヒープ・メモリを設定する必要があり、我々はこれを書き、そして一般的にこの値を渡すためにdockerfile、ファイルYAMLで変数を設定しdockerfileに手を行くことができません
env:
- name: JAVA_OPTS
value: “-Xmx1g “ここでは、この建物の中になりポッドが渡されます私たちの以前の設定のこの変数コンテナリソースのいくつかの制限は、コンテナCMDコマンドは、入ってくる$ JAVA_OPTS変数を一蹴されたコンテナのミラーがされており、それが私たちを呼び出します。システムシステムの変数、システム変数がそれに価値を与えてきたので、この変数を飲むことは安全であり、このアプリケーションをプレイするために、それによって、ヒープサイズを設定し、推奨値はlimltsよりも小さくする必要があります、小さい10％ 、ので、この制限を超えて限界を殺し、その後、引き上げます。
一般的には、他がそのように設定されている、あなたが見ることができるプロセスに容器に見て、どのようなミラーを再構築設定しました
第二の問題は、ヘルスチェックのロールオーバーの重要性
ロールオーバーは、我々はあなたがヘルスチェックを設定するときに使用する最初のK8Sに展開し、通常の後、ロールオーバー状態のプローブに基づいて行われます、デフォルトの戦略K8Sです裁判官は、アクセスの流れを更新し続けることは許されないし、それはあなたの現在のアプリケーションは、サービスを提供することではない、ので、あなたがスムーズなアップグレードを確実にするために使用可能なノードがないことを保証するプロセスを更新スクロールするので、このローリング更新が最初に設定されている、の健康状態をチェックすることが重要である
どのような役割をローリングアップデートを開始するヘルスチェックを！
事業開始後の申し出のコピーを含めることは、彼が準備ができていないことを確認するために、何のヘルスチェックがされていない場合は、よりゆっくりと開始Javaなどのサービスを提供するために時間がかかる、あなたは、すぐにこの期間中に起動することができる状態だと思います新しいトラフィックは、確かにこれは最初のケースで、ハンドルされていないので、それは、数分以内にサービスを提供することができない、データベース接続など、人間の構成エラーに起因する第二の場合は、オンになっていない、または接続されていません他の場所、または場所のプロファイルが間違っていた、それが完了したすべてのロールの更新、それのこのポッド、ロールオーバーをトリガし、結果は問題であり、これは、古いコピーを交換みなさ新しいコピー場合であるので、その、本番環境の後、結果は深刻で、多くのサービスが利用できないので、設定更新スクロールしたとき、ヘルスチェックが伴わなければならない、そしてそれはヘルスチェックと相まって検査が完了した後に、新しいコピーが転送されますそれはそれのすべてを置き換えることはありませんパスしない場合、新しいフローは、それが更新し続けないということです、それは限られた使用可能なノードで使用可能なノードがこの数に達した場合、それはヘルスチェックを引き続き更新されないだろう、二つのタイプがあり、readinessprobeをチェックする準備ができているので、チェックして、例えば2つの異なった方法もありますHTTP、URLだけでなく、TCPソケット、スニファポートだけでなく、シェルコマンドの実行を鳴らし、readinessprobeの準備チェックがあなたである、ヘルスチェック方式の3種類のプロバイダので、戻り値を決定するためにシェルコマンドを実行しますそれがhttpポッドチェックは、あなたは戻りステータスコードを決定するためのプローブによるページには、ローカルポートが意味をなさない場合、その後、それがサービスをバックに参加させません検出することができ、失敗し、サービスあなたがさて統一入り口の全体へのアクセスなどから、それが渡されていない場合は、新しいトラフィックがそれに転送されることはありません、それは準備チェックだ、健康状態が通過しない場合、他のはinitialDelaySecondsであるあなたに新しいトラフィックの転送を与えることはありません：60、なぜなら一般的なJavaアプリケーション、60秒をチェックすることですまた、10：スタートは分とperiodSecondsについてです 10秒に一度行われ、その後、livenessProbeはされないが：サバイバルチェック。
それは、チェックが、それは、その後、あなたに新しい引っ張るコンテナを与え、一般的に、あなたの戦略を再起動し、再構築するためによると、コンテナを殺す裁判官への準備の方法はまた、これらのポートの検出に基づいているが存在しないかを決定するか、特別な使用することができます失敗し、あります他の2つの方法は、http、幹部は、それが2に設定することが一般的である、それはあなたの生存に新しいトラフィックの割り当てをチェックする準備ができていないあなたがプルを再確認する手助けをすることです。
最後の質問欠落のロールオーバーの流れ
一般的には、接続拒否応答エラーで呼び出すことはできません
一般的なロールオーバーが近い既存のポッドで、新しいポッドを更新し、その後、apiserver、ポッドを削除し、既存の事実を閉じますあなたがkubeletするように通知され、その後、kubeletは、コンテナを閉じ、バックエンドサービスから削除し、新しい流れを分配し、その後オフ除去し、その後、KUBE-プロキシ教えていない、あなたは新しい転送ルールを扱うことができる、とされますノード上でスケジュール、実際には、これはポッドダウンライン・サイクルである
ことは、可能性が転送され、追加のプロセス、新しいポッド期間を転送し、それはインターバルで、この時点では、ポッドを閉じた後の待機時間があるでしょうまた、新しいトラフィックの番号にアクセスしないが、そのサービスは、もはや新しい要求を処理しているので、接続は実際には、この問題を解決する方法を、拒否した引き起こす可能性があり、即応プローブをプロセス全体で、キーを弾きます役割、一度プローブの結果の準備状況に関係されていませんでしたエンドポイントのイベントポッドを、削除受け
それに対処するためにエレガントであることを確認するには？
実際には、シャットダウンと起動フックに、あなたはポッドにこの時間を閉じたときに、実際には、この問題を解決することができ、睡眠を追加する必要性が存在感を持っている、あなたは、コンテナ、このフックの実装を閉じる前に、シェルの定義をフックすることができ、すべての、yはまた、HTTP要求を定義することができ、また、2種類の支持者であった、それは、コンテナ内の同じレベルで、ここでのenvが
5秒に眠るあなたはすぐに終了しません密閉容器で、閉じて行くために5秒間眠ります5秒KUBE-プロキシリフレッシュこのルールのための十分なことができ、アプリケーション、ので、新規参入はそのKUBEので、ちょうど閉じポッドは、このフックを使用すると、ポッドを閉じて休止時間を増やすことができるようになりますトラフィックに転送されることはありませんルールをリフレッシュする時間を増やす-proxy、
追加
lifecycle :
preStop :
exec :
command :
- sh
- -c
- “sleep 5”このように、あなたはあなたのアプリケーションのコードを変更する必要はありませんので、ロールオーバーは、ポッドをオフに来に転送されませんので、関連の問題を解決することができます。