Kubernetesのヒントとコツ：ノードの割り当てとWebアプリケーションのロードについて

Kubernetesでの日々の作業を楽にする方法についての実用的な手順を記事に続けて、特定のタスクへの個々のノードの割り当てと、高負荷のためのphp-fpm（または別のアプリケーションサーバー）の構成について、運用の世界から2つのストーリーについて説明します。 前に説明したように、ここで説明するソリューションは理想的であると主張するものではありませんが、特定の事例の出発点として、また反省の基礎として提供されます。 コメントの質問や改善は大歓迎です！

1.特定のタスクに対する個々のノードの割り当て

仮想サーバー、クラウド、またはベアメタルサーバーでKubernetesクラスターを作成しています。 すべてのシステムソフトウェアとクライアントアプリケーションを同じノードにインストールすると、問題が発生する可能性があります。

• クライアントアプリケーションは、その制限が非常に高いものの、突然メモリから「リーク」し始めます。
• ログハウス、プロメテウス、またはイングレスへの複雑な1回限りの要求*はOOMにつながり、その結果、クライアントアプリケーションは苦しみます。
• コンポーネントが互いに論理的に接続されていない場合でも、システムソフトウェアのバグによるメモリリークによりクライアントアプリケーションが強制終了されます。

*特に、古いバージョンのIngressに関連していました。多数のwebsocket接続とnginxの継続的なリロードにより、「ハングしたnginxプロセス」が表示され、数千にのぼり、膨大なリソースを消費しました。



実際のケースは、多数のメトリックを備えたPrometheusのインストールです。「重い」ダッシュボードを表示すると、多数のアプリケーションコンテナーが表示され、それぞれからグラフが描画され、メモリ消費が15 GBまで急速に増加します。 その結果、OOMキラーはホストシステムに「侵入」し、他のサービスを強制終了する可能性があり、その結果、「クラスター内のアプリケーションの理解できない動作」が発生しました。 また、クライアントアプリケーションのCPU負荷が高いため、不安定なIngressクエリ処理時間を簡単に取得できます...



ソリューションはすぐにそれを促しました。異なるタスクに個々のマシンを割り当てる必要がありました。 タスクグループには、主に3つのタイプがあります。

1. 他のサービスがリクエストの処理時間に影響を与えないように、イングレスのみを配置するFronts 。
2. VPN 、 ログハウス 、 プロメテウス 、ダッシュボード、CoreDNSなどを展開するシステムノード 。
3. アプリケーションのノード -実際、クライアントアプリケーションが展開される場所。 また、環境または機能（dev、prod、perfなど）に割り当てることもできます。

解決策

これをどのように実装しますか？ 非常に簡単：2つのネイティブKubernetesメカニズム。 1つ目は、各ノードにインストールされているラベルに基づいて、アプリケーションが移動する必要のあるノードを選択するnodeSelectorです。



kube-system-1



ノードがあるとします。 追加のラベルを追加します。

 $ kubectl label node kube-system-1 node-role/monitoring=
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

...そして、このノードにDeployment



れるDeployment



で、次のように記述します。

 nodeSelector: node-role/monitoring: ""
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2番目のメカニズムは汚染と許容です。 その助けを借りて、これらのマシンでは、この汚染に耐えられるコンテナのみを起動できることを明示的に示します。



たとえば、イングレスのみを展開するkube-frontend-1



マシンがあります。 このノードに汚染を追加します。

 $ kubectl taint node kube-frontend-1 node-role/frontend="":NoExecute
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

...そしてDeployment



で許容を作成します：

 tolerations: - effect: NoExecute key: node-role/frontend
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

kopsの場合、同じニーズに合わせて個々のインスタンスグループを作成できます。

 $ kops create ig --name cluster_name IG_NAME
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

...そして、kopsでこのインスタンスグループ構成のようなものを取得します。

 apiVersion: kops/v1alpha2 kind: InstanceGroup metadata: creationTimestamp: 2017-12-07T09:24:49Z labels: dedicated: monitoring kops.k8s.io/cluster: k-dev.k8s name: monitoring spec: image: kope.io/k8s-1.8-debian-jessie-amd64-hvm-ebs-2018-01-14 machineType: m4.4xlarge maxSize: 2 minSize: 2 nodeLabels: dedicated: monitoring role: Node subnets: - eu-central-1c taints: - dedicated=monitoring:NoSchedule
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、このインスタンスグループのノードは、追加のラベルと汚染を自動的に追加します。

2.負荷が重い場合のphp-fpmの構成

Webアプリケーションの実行に使用されるサーバーには、php-fpm、gunicornなど、さまざまな種類があります。 Kubernetesでそれらを使用することは、次のことを常に考慮する必要があることを意味します。

• 各コンテナにphp-fpmで割り当てたいワーカーの数を大まかに理解する必要があります。 たとえば、受信リクエストを処理するために10人のワーカーを割り当て、ポッドに割り当てるリソースを減らし、ポッドの数に合わせてスケーリングすることができます-これは良い習慣です。 別の例では、各ポッドに500人のワーカーを割り当て、そのようなポッドを2〜3本生産しています...しかし、これはかなり悪い考えです。
• 各ポッドの正常な動作を確認するため、およびネットワークの問題やデータベースアクセスのためにポッドが「スタック」している場合は、 ライブ/レディネステストが必要です（オプションと理由がある場合があります）。 このような状況では、問題のあるポッドを再作成する必要があります。
• アプリケーションがこのサーバー上のすべてのサービスを「フロー」せず、すべてのサービスに損害を与えないように、明示的にリクエストを登録し、各コンテナのリソースを制限することが重要です。

解決策

残念ながら、アプリケーションに必要なリソース（CPU、RAM）の数をすぐに理解するのに役立つ特効薬はありません 。 可能なオプションは、リソースの消費を確認し、毎回最適な値を選択することです。 サービスに大きな影響を与える不当なOOM kill'ovとCPU throttling'aを回避するために、以下を提供できます。

• このコンテナが正しく動作していることを確認できるように、正しい活性/準備テストを追加してください。 ほとんどの場合、すべてのインフラストラクチャ要素の可用性を確認するサービスページ（アプリケーションがポッドで動作するために必要）と200 OK応答コードを返します。
• リクエストを処理するワーカーの数を正しく選択し、それらを正しく配布します。

たとえば、2つのコンテナで構成される10個のポッドがあります。nginx（静的を送信し、バックエンドにリクエストをプロキシするため）とphp-fpm（実際には動的ページを処理するバックエンド）です。 php-fpmプールは、静的な数のワーカー用に構成されています（10）。 したがって、単位時間内に、バックエンドへの100のアクティブなリクエストを処理できます。 各リクエストが1秒でPHPによって処理されるようにします。



現在10個のリクエストをアクティブに処理している特定のポッドに別のリクエストが到着するとどうなりますか？ PHPはそれを処理できず、IngressはGETリクエストである場合、次のポッドに再試行するために送信します。 POSTリクエストがあった場合、エラーを返します。



そして、10個すべてのリクエストの処理中にkubelet（liveness probe）からチェックを受け取ることを考慮すると、失敗し、Kubernetesはこのコンテナに何か問題があると考え始め、それを強制終了します。 この場合、その時点で処理されたすべてのリクエストはエラー（！）で終了します。また、コンテナの再起動時にバランスが崩れ、他のすべてのバックエンドのリクエストが増加します。

明らかに

ポッドが2つあり、それぞれに10個のphp-fpmワーカーが設定されているとします。 以下は、「ダウンタイム」中の情報を表示するグラフです。 php-fpmを要求する唯一のphp-fpmエクスポーター（アクティブなワーカーがそれぞれ1人いる）の場合：







次に、同時実行19でブートを開始します。







では、同時処理を処理できる範囲よりも高くしてみましょう（20）... 23としましょう。すべてのphp-fpmワーカーは、クライアントリクエストの処理で忙しくなります。







Vorkerは活力サンプルを処理するのに十分ではないため、Kubernetesダッシュボードにこの写真が表示されます（またはdescribe pod



）。







現在、ポッドの1つがリブートすると、 雪崩効果が発生します 。リクエストは2番目のポッドに落ち始めますが、これも処理できず、クライアントから多数のエラーを受け取ります。 すべてのコンテナのプールがいっぱいになった後、サービスを上げることには問題があります。これは、ポッドまたはワーカーの数を急激に増やすことによってのみ可能です。

最初のオプション

PHPを使用するコンテナーでは、2つのfpmプールを構成できます。1つはクライアントリクエストの処理用、もう1つはコンテナーの存続可能性の確認用です。 次に、nginxコンテナーで同様の構成を行う必要があります。

  upstream backend { server 127.0.0.1:9000 max_fails=0; } upstream backend-status { server 127.0.0.1:9001 max_fails=0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

あとは、処理用の活性サンプルをbackend-status



というアップストリームに送信するだけです。



livenessプローブが個別に処理されるようになったため、一部のクライアントでエラーが引き続き発生しますが、少なくともポッドの再起動と他のクライアントの切断に関連する問題はありません。 したがって、バックエンドが現在の負荷に対処できない場合でも、エラーの数を大幅に削減します。



このオプションは何もないよりは確かに優れていますが、メインプールに何かが起こる可能性があるため、悪いことでもあります。これは、活性テストの使用については学習しません。

2番目のオプション

nginx-limit-upstreamと呼ばれるあまり人気のないnginxモジュールを使用することもできます。 次に、PHPで11人のワーカーを指定し、nginxを含むコンテナーで同様の構成を作成します。

  limit_upstream_zone limit 32m; upstream backend { server 127.0.0.1:9000 max_fails=0; limit_upstream_conn limit=10 zone=limit backlog=10 timeout=5s; } upstream backend-status { server 127.0.0.1:9000 max_fails=0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

フロントエンドレベルでは、nginxはバックエンドに送信されるリクエストの数を制限します（10）。 興味深い点は、特別なバックログが作成されることです：クライアントがnginxの11番目のリクエストを受信し、nginxがphp-fpmプールがビジーであることを確認した場合、このリクエストは5秒間バックログに置かれます。 この間にphp-fpmが解放されない場合、Ingressが動作し、別のポッドへのリクエストを再試行します。 活性サンプルを処理するために常に1つの無料のPHPワーカーがあるため、これにより状況がスムーズになります。雪崩の影響を回避できます。

その他の考え

この問題を解決するためのより汎用的で美しいオプションについては、 Envoyとその類似物の方向性を調べる価値があります。



一般に、Prometheusが労働者を明確に雇用するために、問題を迅速に発見（および通知）するのに役立つため、ソフトウェアからPrometheus形式にデータを変換する既製の輸出業者を取得することを強くお勧めします。

PS

その他のK8sのヒントとトリックのサイクル：

• 「 NGINX Ingressのパーソナライズされたエラーページ 」;
• 「 クラスターで動作しているリソースのHelm 2管理への転送 」。
• 「 開発サイトへのアクセス 」;
• 「 大規模データベースのブートストラップの高速化。 」

ブログもご覧ください。

• “ Kubernetesでの高可用性の提供方法 ”;
• 監視とKubernetes （レビューおよびビデオレポート） ;
• 「 小規模プロジェクトでのKubernetesでの経験 」 （ビデオレポート、Kubernetes技術デバイスの紹介を含む） 。