最初のアプリケーションを Kubernetes にデプロイする際の XNUMX つのミス

失敗 by Aris-Dreamer

多くの人は、アプリケーションを (Helm を使用するか手動で) Kubernetes に移行すれば十分であり、満足できると信じています。 しかし、それはそれほど単純ではありません。

チーム Mail.ru クラウド ソリューション DevOps エンジニア Julian Gindi による記事を翻訳しました。 彼は、皆さんが同じ轍を踏まないように、移行プロセス中に会社が遭遇した落とし穴について共有しています。

ステップ XNUMX: ポッドのリクエストと制限を設定する

ポッドが実行されるクリーンな環境をセットアップすることから始めましょう。 Kubernetes は、ポッドのスケジュール設定と障害状態の処理において優れた仕事をします。 しかし、スケジューラが正常に動作するために必要なリソースの数を見積もるのが難しい場合、スケジューラはポッドを配置できない場合があることが判明しました。 ここで、リソースと制限のリクエストが発生します。 リクエストと制限を設定するための最良のアプローチについては多くの議論があります。 時々、それは科学というよりも芸術であると本当に感じることがあります。 これが私たちのアプローチです。

ポッドリクエスト - これは、ポッドを最適に配置するためにスケジューラによって使用される主な値です。

の Kubernetes ドキュメント: フィルタリング ステップにより、ポッドをスケジュールできるノードのセットが決定されます。 たとえば、PodFitsResources フィルターは、ポッドの特定のリソース要求を満たすのに十分なリソースがノードにあるかどうかをチェックします。

リソースの数を見積もるためにアプリケーション リクエストを使用します。 実は アプリケーションが適切に動作するには、それが必要です。 このようにして、スケジューラはノードを現実的に配置できます。 当初、各ポッドに十分な数のリソースが確保されるように、余裕を持ってリクエストを設定したいと考えていましたが、スケジューリング時間が大幅に増加し、一部のポッドはリソース リクエストを受信して​​いないかのように完全にスケジュールされていないことに気付きました。

この場合、スケジューラはポッドをプッシュアウトして再スケジュールできないことがよくありました。これは、コントロール プレーンが、アプリケーションが必要とするリソースの数 (スケジューリング アルゴリズムの重要なコンポーネント) が分からないためです。

ポッドの制限 - これはポッドのより明確な制限です。 これは、クラスターがコンテナーに割り当てるリソースの最大量を表します。

またしても、から 公式ドキュメント注: コンテナーに 4 GiB のメモリー制限が設定されている場合、kubelet (およびコンテナー ランタイム) はそれを強制します。 ランタイムでは、コンテナーが指定されたリソース制限を超えて使用することは許可されません。 たとえば、コンテナ内のプロセスが許容量を超えるメモリを使用しようとすると、システム カーネルは「メモリ不足」(OOM) エラーでプロセスを終了します。

コンテナーは常に、リソース要求で指定されたリソースを超えるリソースを使用できますが、制限で指定されたリソースを超えることはできません。 この値を正しく設定するのは困難ですが、非常に重要です。

理想的には、システム内の他のプロセスに干渉することなく、プロセスのライフサイクル全体にわたってポッドのリソース要件が変化することが望まれます。これが制限を設定する目的です。

残念ながら、どのような値を設定するかについて具体的な指示を与えることはできませんが、私たち自身は次のルールを遵守しています。

1. 負荷テスト ツールを使用して、ベースライン レベルのトラフィックをシミュレートし、ポッド リソース (メモリとプロセッサ) の使用状況を監視します。
2. ポッド リクエストを任意の低い値 (リクエストの値の約 5 倍のリソース制限) に設定して観察します。 リクエストが少なすぎるとプロセスを開始できず、謎の Go ランタイム エラーが発生することがよくあります。

ポッドには十分なリソースが利用可能なターゲット ノードが必要であるため、リソース制限が高くなるとスケジューリングがより困難になることに注意してください。

非常に高いリソース制限 (たとえば 4 GB のメモリ) を持つ軽量の Web サーバーがある状況を想像してください。 このプロセスはおそらく水平方向に拡張する必要があり、各新しいモジュールは少なくとも 4 GB の利用可能なメモリを備えたノード上でスケジュールする必要があります。 そのようなノードが存在しない場合、クラスターはそのポッドを処理するために新しいノードを導入する必要があり、これには時間がかかる場合があります。 高速かつスムーズなスケーリングを実現するには、リソースのリクエストと制限の差を最小限に抑えることが重要です。

ステップ XNUMX: Liveness テストと Readiness テストを設定する

これは、Kubernetes コミュニティでよく議論されるもう XNUMX つの微妙なトピックです。 Liveness テストと Readiness テストはソフトウェアをスムーズに実行し、ダウンタイムを最小限に抑えるためのメカニズムを提供するため、これらのテストについてよく理解することが重要です。 ただし、正しく構成されていない場合、アプリケーションのパフォーマンスに重大な影響を与える可能性があります。 以下に、両方のサンプルの概要を示します。

活気 コンテナが実行されているかどうかを示します。 失敗した場合、kubelet はコンテナーを強制終了し、再起動ポリシーが有効になります。 コンテナーに Liveness プローブが装備されていない場合、デフォルトの状態は成功になります。これは、次のとおりです。 Kubernetes ドキュメント.

Liveness プローブは安価である必要があります。つまり、頻繁に実行され、アプリケーションが実行中であることを Kubernetes に通知する必要があるため、大量のリソースを消費すべきではありません。

オプションを毎秒実行するように設定すると、1 秒あたり XNUMX つのリクエストが追加されるため、このトラフィックを処理するには追加のリソースが必要になることに注意してください。

当社では、データ (リモート データベースやキャッシュなど) に完全にアクセスできない場合でも、Liveness テストでアプリケーションのコア コンポーネントをチェックします。

単純に応答コード 200 を返す「ヘルス」エンドポイントを使用してアプリを構成しました。これは、プロセスが実行中であり、リクエスト (ただしトラフィックはまだ) を処理できることを示します。

サンプル 準備 コンテナがリクエストを処理する準備ができているかどうかを示します。 readiness プローブが失敗した場合、エンドポイント コントローラーは、ポッドに対応するすべてのサービスのエンドポイントからポッドの IP アドレスを削除します。 これは Kubernetes のドキュメントにも記載されています。

Readiness プローブは、アプリケーションが要求を受け入れる準備ができていることを示す方法でバックエンドに送信する必要があるため、より多くのリソースを消費します。

コミュニティでは、データベースに直接アクセスするかどうかについて多くの議論が行われています。 オーバーヘッド (チェックは頻繁に実行されますが、調整は可能です) を考慮して、一部のアプリケーションでは、データベースからレコードが返されたことを確認した後にのみ、トラフィックを処理する準備ができているかどうかがカウントされると判断しました。 適切に設計された準備トライアルにより、より高いレベルの可用性が保証され、展開中のダウンタイムが排除されました。

アプリケーションの準備状況をテストするためにデータベースにクエリを実行する場合は、できるだけ安価であることを確認してください。 このリクエストを受け入れてみましょう:

SELECT small_item FROM table LIMIT 1

Kubernetes でこれら XNUMX つの値を構成する方法の例を次に示します。

livenessProbe: 
 httpGet:   
   path: /api/liveness    
   port: http 
readinessProbe:  
 httpGet:    
   path: /api/readiness    
   port: http  periodSeconds: 2

いくつかの追加の構成オプションを追加できます。

• initialDelaySeconds — コンテナの起動からサンプルの開始までにかかる秒数。
• periodSeconds — サンプル実行間の待機間隔。
• timeoutSeconds — ユニットが緊急状態であるとみなされるまでの秒数。 通常のタイムアウト。
• failureThreshold — 再起動信号がポッドに送信されるまでのテスト失敗の数。
• successThreshold — ポッドが準備完了状態になるまでの成功したプローブの数 (失敗後、ポッドの開始時または回復時)。

ステップ XNUMX: ポッドのデフォルトのネットワーク ポリシーを設定する

Kubernetes は「フラット」ネットワーク トポグラフィーを備えており、デフォルトでは、すべてのポッドが相互に直接通信します。 場合によっては、これは望ましくないこともあります。

潜在的なセキュリティ問題は、攻撃者が単一の脆弱なアプリケーションを使用して、ネットワーク上のすべてのポッドにトラフィックを送信する可能性があることです。 多くのセキュリティ分野と同様に、ここでも最小特権の原則が適用されます。 理想的には、ネットワーク ポリシーでは、ポッド間のどの接続が許可され、どの接続が許可されないかを明示的に指定する必要があります。

たとえば、次の単純なポリシーは、特定の名前空間へのすべての受信トラフィックを拒否します。

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:  
 name: default-deny-ingress
spec:  
 podSelector: {}  
 policyTypes:  
   - Ingress

この構成の視覚化:

(https://miro.medium.com/max/875/1*-eiVw43azgzYzyN1th7cZg.gif)
詳細 ここで.

ステップ XNUMX: フックと init コンテナを使用したカスタム動作

私たちの主な目標の XNUMX つは、開発者にダウンタイムなしで Kubernetes へのデプロイメントを提供することでした。 アプリケーションをシャットダウンして、アプリケーションが使用していたリソースを解放するには多くのオプションがあるため、これは困難です。

特に問題が生じたのは、 nginx。 これらのポッドを順番にデプロイすると、正常に完了する前にアクティブな接続がドロップされることに気付きました。

オンラインで広範な調査を行った結果、Kubernetes は Nginx 接続が枯渇するまで待たずにポッドを終了することがわかりました。 停止前フックを使用して、次の機能を実装し、ダウンタイムを完全に排除しました。

lifecycle: 
 preStop:
   exec:
     command: ["/usr/local/bin/nginx-killer.sh"]

しかし nginx-killer.sh:

#!/bin/bash
sleep 3
PID=$(cat /run/nginx.pid)
nginx -s quit
while [ -d /proc/$PID ]; do
   echo "Waiting while shutting down nginx..."
   sleep 10
done

もう XNUMX つの非常に便利なパラダイムは、init コンテナを使用して特定のアプリケーションの起動を処理することです。 これは、アプリケーションの起動前に実行する必要がある、リソースを大量に消費するデータベース移行プロセスがある場合に特に便利です。 メイン アプリケーションにそのような制限を設定せずに、このプロセスに対してより高いリソース制限を指定することもできます。

もう XNUMX つの一般的なスキームは、メイン モジュールに資格情報を提供する init コンテナ内のシークレットにアクセスすることです。これにより、メイン アプリケーション モジュール自体からシークレットへの不正アクセスが防止されます。

いつものようにドキュメントから引用します: Init コンテナーは、アプリケーション コンテナー イメージのセキュリティを低下させるカスタム コードやユーティリティを安全に実行します。 不要なツールを分離しておくことで、アプリケーション コンテナ イメージの攻撃対象領域を制限できます。

ステップ XNUMX: カーネルの構成

最後に、より高度なテクニックについて話しましょう。

Kubernetes は非常に柔軟なプラットフォームであり、必要に応じてワークロードを実行できます。 当社には、非常にリソースを大量に消費する高性能アプリケーションが多数あります。 大規模な負荷テストを実施した結果、Kubernetes のデフォルト設定が有効な場合、XNUMX つのアプリケーションが予想されるトラフィック負荷の処理に苦労していることがわかりました。

ただし、Kubernetes では、特定のポッドのカーネル パラメーターのみを変更する特権コンテナーを実行できます。 開いている接続の最大数を変更するために使用したものは次のとおりです。

initContainers:
  - name: sysctl
     image: alpine:3.10
     securityContext:
         privileged: true
      command: ['sh', '-c', "sysctl -w net.core.somaxconn=32768"]

これはより高度なテクニックですが、多くの場合必要ありません。 ただし、アプリケーションが高負荷に対処するのに苦労している場合は、これらの設定の一部を調整してみることができます。 このプロセスとさまざまな値の設定の詳細 - いつものように 公式ドキュメントでは.

結論

Kubernetes はすぐに使える既製のソリューションのように見えるかもしれませんが、アプリケーションをスムーズに実行し続けるために実行する必要がある重要な手順がいくつかあります。

Kubernetes の移行全体を通じて、「負荷テスト サイクル」に従うことが重要です。つまり、アプリケーションを起動し、負荷テストを行い、メトリクスとスケーリング動作を観察し、そのデータに基づいて構成を調整し、このサイクルを再度繰り返します。

予想されるトラフィックについて現実的になり、それを超えてプッシュして、どのコンポーネントが最初に壊れるかを確認してください。 この反復的なアプローチでは、リストされた推奨事項のいくつかだけで成功を達成できる可能性があります。 あるいは、より深いカスタマイズが必要になる場合もあります。

常に次の質問を自分自身に問いかけてください。

1. アプリケーションはどれくらいのリソースを消費しますか?この量はどのように変化しますか?
2. 実際のスケーリング要件は何ですか? アプリは平均してどのくらいのトラフィックを処理しますか? ピーク時のトラフィックはどうなるでしょうか?
3. サービスを水平方向に拡張する必要がある頻度はどれくらいですか? トラフィックを受信するには、新しいポッドをどれくらい早くオンラインにする必要がありますか?
4. ポッドはどの程度正確にシャットダウンされますか? そもそもこれは必要なのでしょうか？ ダウンタイムなしで導入を達成することは可能ですか?
5. セキュリティ リスクを最小限に抑え、侵害されたポッドによる被害を制限するにはどうすればよいでしょうか? 必要のない権限やアクセス権を持っているサービスはありますか?

Kubernetes は、クラスター内に何千ものサービスをデプロイするためのベスト プラクティスを活用できる素晴らしいプラットフォームを提供します。 ただし、アプリケーションごとに異なります。 実装にはもう少し作業が必要になる場合があります。

幸いなことに、Kubernetes は、すべての技術的目標を達成するために必要な構成を提供します。 リソースのリクエストと制限、Liveness および Readiness プローブ、init コンテナー、ネットワーク ポリシー、カスタム カーネル チューニングを組み合わせて使用​​することで、フォールト トレランスと迅速なスケーラビリティとともに高いパフォーマンスを実現できます。

他に読むべきこと：

1. 実稼働環境でコンテナーと Kubernetes を実行するためのベスト プラクティスとベスト プラクティス.
2. Kubernetes 用の 90 以上の便利なツール: デプロイメント、管理、モニタリング、セキュリティなど.
3. Telegram の Kubernetes に関する私たちのチャンネル.

出所： habr.com