Kubernetes を 2500 ノードに拡張する際に発生する問題と解決策

Kubernetes はバージョン 1.6 以降、5,000 を超えるノードをサポートできると主張していますが、数十から 5,000 までのノード数の増加に伴い、問題が発生することは避けられません。

この記事では、Kubernetes 5000 への道のりにおける Open API の経験、遭遇した問題、問題解決の試み、実際の問題の発見などについて説明します。

[[227083]]

遭遇した問題とその解決方法

質問1: 1〜500ノード後

質問：

kubectl がタイムアウトすることがあります (ps kubectl -v=6 ですべての API の詳細を表示できます)

解決を試みる:

最初は kube-apiserver サーバーの負荷に問題があると思ったので、負荷分散を支援するためにプロキシをレプリカとして追加してみました。
しかし、バックアップマスターが 10 個を超えると、問題は kube-apiserver が負荷に耐えられないことによるものではないことがわかります。 GKE は 32 コアの VM で 500 ノードをサポートできます。

理由：

上記の理由を除いて、マスター上の残りのサービス（etcd、kube-proxy）の確認を開始します。

etcdの調整を開始する
Datadog を使用して etcd スループットをチェックすると、異常なレイテンシが見つかりました (レイテンシの急上昇 ~100 ms)
Fio ツールを使用してパフォーマンスを評価したところ、IOPS (1 秒あたりの入力/出力) の 10% しか使用されておらず、書き込み遅延 (書き込み遅延 2 ミリ秒) によりパフォーマンスが低下していることがわかりました。
各マシンのSSDをネットワークハードドライブからローカル一時ドライブ（SSD）に変更してみてください。
~100msから200usまでの結果

質問2: ノードが約1000個ある場合

質問：

kube-apiserverはetcdから毎秒500MBを読み込むことが判明した。

解決を試みる:

Prometheus を通じてコンテナ間のネットワークトラフィックを表示する

理由：

FluentdとDatadogは各ノードのデータを頻繁にクロールしていることが判明した。
2 つのサービスのクロール頻度を減らすと、ネットワークパフォーマンスは 500 MB/秒からほぼゼロに低下しました。

etcd のヒント: --etcd-servers-overrides を使用すると、Kubernetes イベントデータをセグメントとして書き込み、異なるマシンで処理することができます (以下を参照)。

 --etcd-servers-overrides=/events#https://0.example.com:2381;https://1.example.com:2381;https://2.example.com:2381

問題3: 1000～2000ノード

質問：

これ以上データを書き込めません。エラーが連鎖的に発生しました

kubernetes-ec2-autoscalerは、すべてのetcdが停止した後にのみ問題を返し、すべてのetcdをシャットダウンします。

解決を試みる:

etcd ハードディスクがいっぱいになっていると思いますが、SSD をチェックしたところ、まだ十分なスペースがあります。
事前に設定されたスペース制限があるかどうかを確認し、2GBのサイズ制限があることを確認します。

解決：

etcd 起動パラメータに --quota-backend-bytes を追加します。
kubernetes-ec2-autoscaler ロジックを修正 - 50% を超える問題がある場合は、クラスターをシャットダウンします

各種サービスの最適化

Kubeマスターの高可用性

一般的に言えば、私たちのアーキテクチャは、kube-master (kube-apiserver、kube-scheduler、kube-control-manager を含む主要な Kubernetes サービスプロバイダーコンポーネント) と複数のスレーブで構成されます。ただし、高可用性を実現するには、次の方法を参照してください。

kube-apiserverは複数のサービスを設定し、再起動してパラメータ--apiserver-countを設定する必要があります。
kubernetes-ec2-autoscaler はアイドル状態のリソースを自動的にシャットダウンするのに役立ちますが、これは Kubernetes スケジューラの原則に反します。ただし、これらの設定により、リソースを最大限に集中させることができます。

 {
 「種類」 : 「ポリシー」 、
 「apiバージョン」 : 「v1」 、
 「述語」 : [
  { "name" : "GeneralPredicates" },
  { "名前" : "MatchInterPodAffinity" },
  { "名前" : "NoDiskConflict" },
  { "名前" : "NoVolumeZoneConflict" },
  { "名前" : "PodToleratesNodeTaints" }
  ]、
 「優先順位」 : [
  { "名前" : "MostRequestedPriority" , "重み" : 1},
  { "名前" : "InterPodAffinityPriority" 、 "重み" : 2}
  ]
 }

上記はKubernetesスケジューラを調整する例です。 InterPodAffinityPriority の重みを増やすことで、目標を達成できます。参考までに、その他の例もご覧ください。

現在の Kubernetes スケジューラポリシーは動的切り替えをサポートしておらず、kube-apiserver を再起動する必要があることに注意してください (問題: 41600)

スケジューラポリシーの調整による影響

OpenAIはKubeDNSを使用していましたが、すぐに

質問：

DNS クエリが頻繁に失敗する (ランダムに発生する)

約200QPS以上のドメイン検索

解決を試みる:

なぜこのようなことが起こるのかを調べようとしたところ、一部のノードで 10 個を超える KuberDNS が実行されていることがわかりました。

解決：

スケジューラポリシーにより、多くのPODが集中する
KubeDNS は非常に軽量で、同じノードに簡単に割り当てることができるため、ドメイン検索が集中化されます。
POD アフィニティ (関連する紹介) を変更し、KubeDNS を別のノードに割り当てる必要があります。

親和性:
 ポッドアンチアフィニティ:
   スケジュール中は必須、実行中は無視:
   -重量: 100
     ラベルセレクター:
       一致表現:
       -キー: k8s-app
         演算子:  
値：
         - kube-dns
     トポロジキー: kubernetes.io/ホスト名

新しいノードを作成するときにDockerイメージのプルが遅くなる

質問：

新しいノードが構築されるたびに、Dockerイメージのプルに30分かかります

解決を試みる:

約 17 GB の大きなコンテナイメージ Dota があり、ノード全体のイメージのプルに影響を及ぼします。
kubeletに他のイメージプルオプションがあるかどうかの確認を開始する

解決：

kubelet にオプション --serialize-image-pulls=false を追加してイメージのプルを有効にし、他のサービスが早くプルできるようにします。
このオプションでは、docker storgae を overlay2 に切り替える必要があります。
また、DockerイメージをSSDに保存すると、イメージのプルが速くなります。

補足: ソーストレース

// serializeImagePulls を有効にすると、Kubelet に画像を 1 つずつプルするように指示します。
 //一度に.ノードのデフォルト値を変更しないことを推奨します。
 //バージョン 1.9 未満のdocker デーモンまたはAufs ストレージ バックエンドを実行します。
 // 問題 #10959 に詳細が記載されています。
 SerializeImagePulls *bool `json: "serializeImagePulls" `