Kubernetes パフォーマンスに関する XNUMX つのヒント

こんにちは、みんな！ 私の名前はオレグ・シドレンコフです。DomClick でインフラストラクチャ チームの責任者として働いています。 私たちは XNUMX 年以上にわたって実稼働環境で Kubik を使用しており、この間、Kubik でさまざまな興味深い瞬間を経験してきました。 今日は、適切なアプローチを使用して、クラスターの標準的な Kubernetes からさらに多くのパフォーマンスを引き出す方法を説明します。 準備は万全です！

Kubernetes がコンテナ オーケストレーション用のスケーラブルなオープン ソース システムであることは皆さんもよくご存じでしょう。 または、サーバー環境でマイクロサービスのライフサイクルを管理することで魔法のように機能する 5 つのバイナリです。 さらに、レゴのように組み立てることができるかなり柔軟なツールで、さまざまなタスクに合わせて最大限にカスタマイズできます。

そして、すべてがうまくいっているように見えます。Firebox に薪をくべるように、サーバーをクラスタに放り込んでも、何の悲しみも感じなくなるでしょう。 しかし、環境保護を考えているなら、「どうすれば森林を守りながら火を燃やし続けることができるだろうか？」と考えるでしょう。 言い換えれば、インフラを改善し、コストを削減する方法をどのように見つけるかということです。

1. チームとアプリケーションのリソースを監視する

最も一般的だが効果的な方法の XNUMX つは、リクエスト/制限の導入です。 アプリケーションを名前空間ごとに分割し、名前空間を開発チームごとに分割します。 デプロイメントの前に、プロセッサ時間、メモリ、および一時ストレージの消費量についてアプリケーションの値を設定します。

resources:
   requests:
     memory: 2Gi
     cpu: 250m
   limits:
     memory: 4Gi
     cpu: 500m

私たちは経験を通じて、リクエストを制限の 5 倍以上に膨らませるべきではないという結論に達しました。 クラスターのボリュームはリクエストに基づいて計算され、アプリケーションにリソースの差をたとえば 10 ～ XNUMX 倍与えた場合、ノードがポッドでいっぱいになり、突然負荷がかかったときにノードに何が起こるかを想像してください。 何も良いことがない。 最小ではスロットリング、最大ではワーカーに別れを告げ、ポッドが移動を開始した後に残りのノードに周期的な負荷がかかります。

さらに、ご協力のもと、 limitranges 最初に、コンテナーのリソース値 (最小値、最大値、デフォルト) を設定できます。

➜  ~ kubectl describe limitranges --namespace ops
Name:       limit-range
Namespace:  ops
Type        Resource           Min   Max   Default Request  Default Limit  Max Limit/Request Ratio
----        --------           ---   ---   ---------------  -------------  -----------------------
Container   cpu                50m   10    100m             100m           2
Container   ephemeral-storage  12Mi  8Gi   128Mi            4Gi            -
Container   memory             64Mi  40Gi  128Mi            128Mi          2

XNUMX つのチームがクラスターのすべてのリソースを引き継ぐことができないように、名前空間リソースを制限することを忘れないでください。

➜  ~ kubectl describe resourcequotas --namespace ops
Name:                   resource-quota
Namespace:              ops
Resource                Used          Hard
--------                ----          ----
limits.cpu              77250m        80
limits.memory           124814367488  150Gi
pods                    31            45
requests.cpu            53850m        80
requests.memory         75613234944   150Gi
services                26            50
services.loadbalancers  0             0
services.nodeports      0             0

説明からもわかるように resourcequotas運用チームがさらに 10 CPU を消費するポッドをデプロイしたい場合、スケジューラはこれを許可せず、エラーをスローします。

Error creating: pods "nginx-proxy-9967d8d78-nh4fs" is forbidden: exceeded quota: resource-quota, requested: limits.cpu=5,requests.cpu=5, used: limits.cpu=77250m,requests.cpu=53850m, limited: limits.cpu=10,requests.cpu=10

このような問題を解決するには、たとえば次のようなツールを作成できます。 この、コマンド リソースの状態を保存およびコミットできます。

2. 最適なファイルストレージを選択する

ここでは、永続ボリュームと Kubernetes ワーカー ノードのディスク サブシステムのトピックについて触れたいと思います。 本番環境で HDD 上の「Cube」を使用する人がいないことを願いますが、場合によっては、通常の SSD では十分ではないことがあります。 I/O 操作によりログがディスクを破壊するという問題が発生しましたが、解決策はあまりありません。

• 高性能 SSD を使用するか、NVMe に切り替えます (ハードウェアを独自に管理している場合)。

• ログレベルを下げます。

• ディスクを強姦するポッドの「スマートな」バランシングを実行します (podAntiAffinity).

上の画面は、access_logs ログが有効になっている場合 (~12 ログ/秒)、nginx-ingress-controller でディスクに対して何が起こるかを示しています。 もちろん、この状態が発生すると、このノード上のすべてのアプリケーションの機能が低下する可能性があります。

PV に関しては、残念ながらすべてを試したわけではありません 種 永続ボリューム。 自分に合った最適なオプションを使用してください。 歴史的に、我が国ではごく一部のサービスで RWX ボリュームが必要になることがあり、ずっと前からこのタスクに NFS ストレージを使用し始めました。 安くて…十分です。 もちろん、彼と私はひどいものを食べました - 幸いなことに、私たちはそれを避けることを学びました、そして私の頭はもう痛くありません。 可能であれば、S3 オブジェクト ストレージに移動します。

3. 最適化された画像を収集する

Kubernetes がイメージをより速くフェッチし、より効率的に実行できるように、コンテナーに最適化されたイメージを使用することが最善です。 

最適化とは、画像が次のことを意味します。

• アプリケーションを XNUMX つだけ含むか、機能を XNUMX つだけ実行します。

• サイズが大きいと、ネットワーク上での送信が困難になるため、サイズが小さくなります。

• ダウンタイムが発生した場合に Kubernetes がアクションを実行できるようにするヘルスおよびレディネス エンドポイントを備えています。

• 構成エラーに対する耐性が高い、コンテナに適したオペレーティング システム (Alpine や CoreOS など) を使用します。

• マルチステージ ビルドを使用すると、コンパイルされたアプリケーションのみをデプロイでき、付随するソースはデプロイできなくなります。

画像をその場で確認して最適化できるツールやサービスが数多くあります。 常に最新の状態に保ち、安全性をテストすることが重要です。 その結果、次のものが得られます。

1. クラスター全体のネットワーク負荷が軽減されます。

2. コンテナの起動時間を短縮します。

3. Docker レジストリ全体のサイズが小さくなります。

4.DNSキャッシュを使用する

高負荷について言えば、クラスターの DNS システムを調整しないと、非常にひどい状態になります。 かつて、Kubernetes 開発者は kube-dns ソリューションをサポートしていました。 ここでも実装しましたが、このソフトウェアは簡単な作業のように見えましたが、特にチューニングされておらず、必要なパフォーマンスが得られませんでした。 その後 coredns が登場し、私たちはそれに切り替えましたが、特に問題はなく、後に K8s のデフォルトの DNS サービスになりました。 ある時点で、DNS システムへの RPS が 40 に達し、このソリューションでも不十分になりました。 しかし、幸運なことに、Nodelocaldns (別名ノード ローカル キャッシュ) が登場しました。 ノードローカルDNSCキャッシュ.

なぜこれを使用するのでしょうか? Linux カーネルにはバグがあり、UDP 経由で conntrack NAT を介して複数の呼び出しを行うと、conntrack テーブルのエントリの競合状態が発生し、NAT を介したトラフィックの一部が失われます (サービスを介する各トリップは NAT)。 Nodelocaldns は、NAT を取り除き、TCP への接続を上流 DNS にアップグレードし、上流 DNS クエリをローカルにキャッシュする (5 秒間の短いネガティブ キャッシュを含む) ことでこの問題を解決します。

5. ポッドを水平方向と垂直方向に自動的にスケールする

すべてのマイクロサービスが負荷の XNUMX ～ XNUMX 倍の増加に対応できる準備ができていると自信を持って言えますか? アプリケーションにリソースを適切に割り当てるにはどうすればよいでしょうか? ワークロードを超えていくつかのポッドを実行し続けるのは冗長かもしれませんが、それらを連続して実行すると、サービスへのトラフィックの突然の増加によるダウンタイムのリスクが生じます。 などのサービス 水平ポッドオートスケーラー и 垂直ポッドオートスケーラー.

VPA 実際の使用状況に応じて、ポッド内のコンテナーのリクエスト/制限を自動的に引き上げることができます。 どのように役に立ちますか? 何らかの理由 (完全に信頼できるわけではありません) で水平方向にスケーリングできないポッドがある場合は、そのリソースへの変更を VPA に委託してみることができます。 その機能は、メトリック サーバーからの履歴データと現在のデータに基づく推奨システムであるため、リクエスト/制限を自動的に変更したくない場合は、コンテナーの推奨リソースを監視し、設定を最適化するだけで CPU と負荷を節約できます。クラスタ内のメモリ。

画像は https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizo​​ntal-pod-autoscaler-and-vertical-pod-2a441d9ad231 から取得

Kubernetes のスケジューラは常にリクエストに基づいています。 そこにどのような値を入力しても、スケジューラはそれに基づいて適切なノードを検索します。 制限値は、キューブレットがいつポッドをスロットルまたは強制終了するかを理解するために必要です。 唯一の重要なパラメータはリクエスト値であるため、VPA はそれを処理します。 アプリケーションを垂直方向にスケーリングするときは常に、リクエストがどうあるべきかを定義します。 その場合、限界はどうなるでしょうか？ このパラメータも比例してスケールされます。

たとえば、通常のポッド設定は次のとおりです。

resources:
   requests:
     memory: 250Mi
     cpu: 200m
   limits:
     memory: 500Mi
     cpu: 350m

レコメンデーション エンジンは、アプリケーションを適切に実行するには 300m CPU と 500Mi が必要であると判断します。 次の設定が表示されます。

resources:
   requests:
     memory: 500Mi
     cpu: 300m
   limits:
     memory: 1000Mi
     cpu: 525m

上で述べたように、これはマニフェスト内のリクエスト/制限の比率に基づいた比例スケーリングです。

• CPU: 200m → 300m: 比率 1:1.75;

• メモリ: 250Mi → 500Mi: 比率 1:2。

関しては HPAであれば、動作メカニズムはより透明になります。 CPU やメモリなどのメトリクスにはしきい値が設定され、すべてのレプリカの平均がしきい値を超えると、値がしきい値を下回るかレプリカの最大数に達するまで、アプリケーションは +1 サブ単位でスケーリングされます。

画像は https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizo​​ntal-pod-autoscaler-and-vertical-pod-2a441d9ad231 から取得

CPU やメモリなどの通常のメトリクスに加えて、Prometheus からカスタム メトリクスにしきい値を設定し、それがアプリケーションをいつスケールするかを最も正確に示すものであると思われる場合は、それらのメトリクスを使用できます。 アプリケーションが指定されたメトリックしきい値を下回って安定すると、HPA はレプリカの最小数まで、または負荷が指定されたしきい値を満たすまでポッドのスケールダウンを開始します。

6. ノード アフィニティとポッド アフィニティを忘れないでください

すべてのノードが同じハードウェア上で実行されるわけではなく、すべてのポッドがコンピューティング集約型のアプリケーションを実行する必要があるわけではありません。 Kubernetes では、次を使用してノードとポッドの特殊化を設定できます。 ノードアフィニティ и ポッドアフィニティ.

計算負荷の高い操作に適したノードがある場合、効率を最大化するには、アプリケーションを対応するノードに結び付けることをお勧めします。 これを行うには、次を使用します nodeSelector ノードラベル付き。

XNUMX つのノードがあるとします。 CPUType=HIGHFREQ そして、多数の高速コア、もう XNUMX つは MemoryType=HIGHMEMORY より多くのメモリとより高速なパフォーマンス。 最も簡単な方法は、デプロイメントをノードに割り当てることです HIGHFREQセクションに追加することで spec このようなセレクター:

…
nodeSelector:
	CPUType: HIGHFREQ

これを行うためのより高価で具体的な方法は、 nodeAffinity フィールドで affinity セクション spec。 次の XNUMX つのオプションがあります。

• requiredDuringSchedulingIgnoredDuringExecution: ハード設定 (スケジューラは特定のノードにのみポッドをデプロイします (他の場所にはデプロイしません))。

• preferredDuringSchedulingIgnoredDuringExecution: ソフト設定 (スケジューラは特定のノードへのデプロイを試行し、それが失敗した場合は、次に使用可能なノードへのデプロイを試行します)。

ノード ラベルを管理するための特定の構文を指定できます。 In, NotIn, Exists, DoesNotExist, Gt または Lt。 ただし、ラベルの長いリストに複雑なメソッドを使用すると、重要な状況での意思決定が遅くなることに注意してください。 言い換えれば、シンプルにしてください。

前述したように、Kubernetes では現在のポッドのアフィニティを設定できます。 つまり、特定のポッドが同じアベイラビリティーゾーン (クラウドに関連) またはノード内の他のポッドと連携して動作することを確認できます。

В podAffinity 余白 affinity セクション spec の場合と同じフィールドが利用可能です nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution и preferredDuringSchedulingIgnoredDuringExecution。 唯一の違いは、 matchExpressions そのラベルを持つポッドをすでに実行しているノードにポッドをバインドします。

Kubernetes はフィールドも提供します podAntiAffinity逆に、ポッドを特定のポッドを持つノードにバインドしません。

表現について nodeAffinity 同じアドバイスを与えることができます。ルールをシンプルかつ論理的に保つよう努め、複雑なルールのセットでポッド仕様を過負荷にしないでください。 クラスターの条件と一致しないルールを作成することは非常に簡単で、スケジューラーに不要な負荷がかかり、全体的なパフォーマンスが低下します。

7. 汚染と耐性

スケジューラを管理する別の方法もあります。 数百のノードと数千のマイクロサービスを含む大規模なクラスターがある場合、特定のポッドが特定のノードでホストされることを許可しないことは非常に困難です。

これには、汚染のメカニズム (禁止ルール) が役立ちます。 たとえば、特定のシナリオでは、特定のノードがポッドを実行することを禁止できます。 特定のノードにテイントを適用するには、オプションを使用する必要があります taint kubectlで。 キーと値を指定して、次のように汚染します NoSchedule または NoExecute:

$ kubectl taint nodes node10 node-role.kubernetes.io/ingress=true:NoSchedule

汚染メカニズムが XNUMX つの主な効果をサポートしていることにも注目してください。 NoSchedule, NoExecute и PreferNoSchedule.

• NoSchedule これは、現時点ではポッド仕様に対応するエントリが存在しないことを意味します。 tolerations、ノードにデプロイすることはできません (この例では node10).

• PreferNoSchedule - 簡易版 NoSchedule。 この場合、スケジューラは、一致するエントリがないポッドを割り当てないよう試みます。 tolerations ただし、これは厳密な制限ではありません。 クラスター内にリソースがない場合、ポッドはこのノード上でデプロイを開始します。

• NoExecute - この効果は、対応するエントリを持たないポッドの即時退避をトリガーします。 tolerations.

興味深いことに、この動作は許容メカニズムを使用してキャンセルできます。 これは、「禁止された」ノードがあり、そこにインフラストラクチャ サービスを配置するだけでよい場合に便利です。 どうやってするの？ 適切な許容範囲があるポッドのみを許可します。

ポッドの仕様は次のようになります。

spec:
   tolerations:
     - key: "node-role.kubernetes.io/ingress"
        operator: "Equal"
        value: "true"
        effect: "NoSchedule"

これは、次の再デプロイがこの特定のノードに適用されることを意味するものではありません。これはノード アフィニティ メカニズムではなく、 nodeSelector。 ただし、いくつかの機能を組み合わせることで、非常に柔軟なスケジューラ設定を実現できます。

8. ポッドのデプロイ優先度の設定

ポッドをノードに割り当てているからといって、すべてのポッドを同じ優先度で扱う必要があるというわけではありません。 たとえば、一部のポッドを他のポッドより先にデプロイすることができます。

Kubernetes は、ポッドの優先順位とプリエンプションを構成するさまざまな方法を提供します。 設定はいくつかの部分で構成されます: オブジェクト PriorityClass およびフィールドの説明 priorityClassName ポッドの仕様で。 例を見てみましょう:

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 99999
globalDefault: false
description: "This priority class should be used for very important pods only"

作成します PriorityClass、名前、説明、値を入力します。 より高い value、優先度が高くなります。 値は、32 以下の任意の 1 ビット整数にすることができます。これより高い値は、通常プリエンプトできないミッションクリティカルなシステム ポッド用に予約されています。 置き換えは、優先度の高いポッドに向きを変える場所がない場合にのみ発生し、その場合、特定のノードのポッドの一部が退避されます。 このメカニズムが硬すぎる場合は、オプションを追加できます。 preemptionPolicy: Neverその場合、プリエンプションは行われず、ポッドはキューの先頭に立って、スケジューラが空きリソースを見つけるのを待ちます。

次に、名前を指定したポッドを作成します。 priorityClassName:

apiVersion: v1
kind: Pod
metadata:
  name: static-web
  labels:
    role: myrole
 spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80
          protocol: TCP
  priorityClassName: high-priority
          

優先順位クラスは好きなだけ作成できますが、これに夢中にならないことをお勧めします (たとえば、優先順位を低、中、高に制限するなど)。

したがって、必要に応じて、nginx-ingress-controller、coredns などの重要なサービスのデプロイ効率を高めることができます。

9. ETCD クラスターの最適化

ETCD はクラスター全体の頭脳とも言えます。 Cube の操作速度はデータベースに依存するため、このデータベースの操作を高いレベルで維持することが非常に重要です。 かなり標準的であり、同時に優れた解決策は、kube-apiserver への遅延を最小限に抑えるためにマスター ノード上に ETCD クラスターを維持することです。 これができない場合は、参加者間の帯域幅を十分に確保して、ETCD をできるだけ近くに配置します。 また、クラスターに害を及ぼさずに ETCD からどれだけのノードが脱落できるかにも注意してください。

クラスター内のメンバー数を過度に増やすと、パフォーマンスが犠牲になってフォールト トレランスが向上する可能性があることに注意してください。すべては適度に行う必要があります。

サービスのセットアップについて話す場合、いくつかの推奨事項があります。

1. クラスターのサイズに基づいて、適切なハードウェアを用意します (次の情報を参照してください)。 ここで).

2. DC のペア間またはネットワークとディスクの間にクラスターを分散させている場合は、いくつかのパラメーターを微調整します。まだ改善の余地はあります (以下を参照してください)。 ここで).

まとめ

この記事では、私たちのチームが遵守しようとしているポイントについて説明します。 これはアクションを段階的に説明するものではなく、クラスターのオーバーヘッドを最適化するために役立つ可能性のあるオプションです。 各クラスターが独自の方法でユニークであることは明らかであり、構成ソリューションは大きく異なる可能性があるため、Kubernetes クラスターをどのように監視し、そのパフォーマンスをどのように改善するかについてフィードバックを得るのは興味深いことです。 コメントであなたの経験を共有してください。それを知ることは興味深いでしょう。

出所： habr.com