最初のKubernetesアプリをデプロイする際の5つのミス

Aris-Dreamerによる失敗



多くの人々は、アプリケーションをKubernetesに移植するだけで（Helmを使用するか手動で）十分であり、幸福があると考えています。しかし、それはそれほど単純ではありません。Mail.ru Cloud Solutions



チームは、DevOpsエンジニアのJulianGuindiによる記事を翻訳しました。彼は、あなたが同じレーキを踏まないように、移行プロセスで彼の会社が直面した落とし穴について話します。

ステップ1：ポッドリクエストと制限を設定する

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



ポッドリクエストは、最適なポッド配置のためにスケジューラーが使用する主要な値です。

Kubernetes: , . , PodFitsResources , .

アプリケーションリクエストを使用して、アプリケーションが実際に適切に機能するために必要なリソースの数を見積もることができます。これにより、プランナーはノードを現実的に配置できます。当初は、ポッドごとに十分なリソースがあることを確認するために余裕を持ってリクエストを設定したかったのですが、スケジュール時間が大幅に長くなり、一部のポッドは、リソースリクエストがないかのように完全にスケジュールされなかったことがわかりました。



この場合、スケジューラーはポッドを「スクイーズ」し、スケジュールアルゴリズムの重要なコンポーネントであるアプリケーションに必要なリソースの量が制御プレーンにわからないため、ポッドを再スケジュールできません。



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

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

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



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



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

1. 負荷テストツールを使用して、ベースライントラフィックをシミュレートし、ポッドリソースの使用状況（メモリとプロセッサ）を監視します。
2. ( 5 ) . , , Go.

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



4GBのメモリのような非常に高いリソース制約のある軽量のWebサーバーがある状況を想像してみてください。このプロセスは水平方向にスケーリングする必要があり、新しい各モジュールは、少なくとも4GBの使用可能なメモリがあるノードでスケジュールする必要があります。そのようなノードが存在しない場合、クラスターはこのポッドを処理するために新しいノードを導入する必要があります。これには時間がかかる場合があります。高速でスムーズなスケーリングを確保するには、リソース要求と制限の間のマージンをできるだけ小さくすることが重要です。

ステップ2：活性テストと準備テストを設定します

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



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



活性プローブは、頻繁に実行され、アプリケーションが実行されていることをKubernetesに通知する必要があるため、安価である必要があります。つまり、多くのリソースを消費しない必要があります。



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



当社では、データ（リモートデータベースやキャッシュなど）が完全に利用できない場合でも、Livenessテストでアプリケーションの主要コンポーネントを検証します。



応答コード200を返すだけの「ヘルス」エンドポイントをアプリケーションに構成しました。これは、プロセスが稼働中であり、要求を処理できることを示しています（ただし、トラフィックはまだ処理できません）。準備



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



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



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



データベースにクエリを実行してアプリケーションの準備ができていることを確認する場合は、できるだけ安価であることを確認してください。次のようなクエリを実行してみましょう。

SELECT small_item FROM table LIMIT 1

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

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

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

• initialDelaySeconds -コンテナの開始からサンプルの開始までに何秒が経過するか。
• periodSeconds — .
• timeoutSeconds — , . -.
• failureThreshold — , .
• successThreshold — , ( , ).

:

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）}

詳細はこちら。

ステップ4：フックと初期化コンテナを使用したカスタム動作

私たちの主な目標の1つは、開発者にダウンタイムなしで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

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



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

, : init- , . , .

:

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



Kubernetesは非常に柔軟なプラットフォームであり、適切と思われる方法でワークロードを実行できます。非常に効率的でリソースを大量に消費するアプリケーションが多数あります。広範な負荷テストを通じて、Kubernetesのデフォルトが有効な場合、アプリケーションの1つが予想されるトラフィック負荷の処理に苦労していることがわかりました。



ただし、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は、すべての技術的目標を達成するために必要なカスタマイズを提供します。リソースの要求と制限、活性と準備のプローブ、初期化コンテナ、ネットワークポリシー、およびカスタムカーネルの調整を組み合わせて使用​​すると、障害耐性と高速なスケーラビリティとともに、高いパフォーマンスを実現できます。



他に読むべきこと：

1. 実稼働環境でコンテナとKubernetesを実行するためのベストプラクティスとガイドライン。
2. 90+ Kubernetes: , , , .
3. Kubernetes .