著者は、TencentCloudのコンテナ製品エンジニアであるLinYuxinです。現在、彼は主にTencent CloudTKEコンソールの研究開発を担当しています。
概要概要
オープンソースコミュニティでは、KubernetesのIngress Controllerを実装する方法はたくさんありますが、Nginx Ingressはその1つにすぎません。もちろん、コミュニティで最も広く使用されているIngress Controllerでもあります。強力であるだけでなく、パフォーマンスも向上します。非常に高い。この記事では、主にTencent Cloud ContainerServiceを使用してNginxIngressの展開を複数の方法で実装する方法を紹介し、実装の原則、長所と短所、および各方法の適用可能なシナリオを簡単に紹介します。
NginxIngressとは
Nginx Ingressは、nginx転送ルール変換としてnginx-ingress-controller
宣言nginx-ingress
されたユーザーによるオブジェクトKubernetesです。解決すべき中心的な問題は、東西方向のトラフィックの転送と負荷分散です。
主な動作原理は、変更をnginx-ingress-controller
監視しapi-server
(Kubernetes Informers)、Ingress、Service、Endpoint、Secret、ConfigMapなどのオブジェクトのKubernetesの変更を監視して、トラフィックを転送することでNginxインスタンスの構成を変更することです。
現在コミュニティには、主に次の2つのNginxIngressの実装方法があります。
NginxIngressが必要な理由
オープンソースコミュニティの中で、Ingress Controller
さまざまな方法を実現するために、それぞれにコントローラーに適用可能なシナリオとその長所と短所がありますが、なぜ使用することが推奨されるのnginx-ingress-controller
ですか?話しましょう、使わないnginx-ingress-controller
と何が困ったのかビジネスになります
ここでは、例としてTKE
推奨さingress controller
れるデフォルトのTencentクラウドコンテナサービスコンソール(以下、以下)には、次のようないくつかの問題があります。
- CLBタイプの入力機能は、同じ外部ネットワークエントリを共有できない、デフォルトの転送バックエンドをサポートできないなど、既存のサービスのニーズを満たすことができません。
- 元のビジネスが使用され
nginx-inrgess
、運用と保守が構成nginx.conf
に慣れてきたので、あまり多くの変更を加えたくない
を使用nginx-ingress-controller
すると、上記の問題を解決できます。
必要な前提条件
nginx-ingress-operatorをデプロイします
コンポーネントの展開とインストール
コンソール間のコンテナへのTencentクラウドサービスNginx Ingress
、クラスターを展開する必要性を選択し、クラスターを入力します-コンポーネントの管理、展開、インストールのNginx Ingess
コンポーネントは次のとおりです。
コンポーネントがインストールされ、正常に機能している
展開計画
TKEは、さまざまなnginx-ingress-controller
展開ソリューションと、さまざまなビジネスシナリオに適応するためにLBにアクセスする方法を提供します。以下では、さまざまなソリューションを紹介します。
nginx-ingress-controller展開計画
オプション1:DaemonSet +ノードプール
主要なトラフィックアクセスゲートウェイとして、Nginxは重要なコンポーネントです。Nginxと他のサービスを同じノードに展開することはお勧めしません。ノードプールに汚染を設定することで展開できます。ノードプールの関連手順については、Tencent Cloud ContainerServiceノードプールの概要を確認してください。
この展開スキームを使用するときは、次の項目に注意する必要があります。
-
nginx-ingress-controller
ノードプールを展開する準備を進め、ノードプールの問題を設定Taint
しLabel
、他のポッドがノードプールにディスパッチされないようにします。 -
インストールされた
nginx-ingress-operator
コンポーネントの展開が成功していること、リファレンスガイドより上の展開であることを確認してください -
コンポーネントの詳細を入力し、作成します
nginx-ingress-controller
インスタンス(複数のインスタンスが単一のクラスターに同時に存在できます)
- 展開方法の選択
指定节点池DaemonSet部署
- トレランスステインを設定
- リクエスト/制限を設定します。リクエストをノードプールのモデル構成よりも小さく設定する必要があります(リソースが不足しているためにインスタンスが使用できなくなるのを防ぐために、ノード自体にリソースが予約されています)、制限を設定できません
- その他のパラメータは、ビジネスニーズに応じて設定できます
- 展開方法の選択
オプション2:展開+ HPA
展開にDeployment + HPAソリューションを使用すると、ビジネスニーズに応じて汚染と耐性を構成し、Nginxとビジネスポッドを分散して展開できます。HPAを使用して、エラスティックスケーリング用のCPU /メモリなどのインジケータを設定します。
この展開スキームを使用するときは、次の項目に注意する必要があります。
-
クラスター
nginx-ingress-controller
ラベルノードにデプロイするように設定 -
nginx-ingress-operator
上記の展開リファレンスガイドで、インストールされているコンポーネントが正常に展開されていることを確認してください。 -
コンポーネントの詳細を入力し、作成します
nginx-ingress-controller
インスタンス(複数のインスタンスが単一のクラスターに同時に存在できます)
- 展開方法の選択
自定义Deployment+HPA部署
- HPAトリガー戦略を設定する
- リクエスト/制限の設定
- ノードスケジューリングポリシーを設定し、
nginx-ingress-controller
排他ノードを推奨し、使用できない占有に起因する他のビジネスリソースを回避します - その他のパラメータは、ビジネスニーズに応じて設定できます
- 展開方法の選択
LB展開方法へのNginxフロントエンドアクセス
彼女は、TKEnginx-ingress-operator
とnginx-ingress-controller
、上記の手順を実行するプロセスの展開と使用の間でクラスターに展開され、関連するコンポーネントNginxのクラスターにのみ展開されますが、外部トラフィックを受信するには、構成、nginxを構成します。フロントエンドLB。現在、TKEはNginx Ingressの製品化サポートを完了しています。ビジネスニーズに応じて、次の展開モードのいずれかを選択できます。
解決策1:VPC-CNIモードクラスターはCLBを使用してNginxサービスと通信します(推奨)
前提条件(そのうちの1つを満たす):
- クラスター独自のネットワークプラグインは
VPC-CNI
- 独自のネットワーク用のクラスタープラグイン
Global Router
、およびVPC-CNI
サポートをオンにしました(両方のモードが混在しています)
ノードプールによって展開された負荷の例を使用します。
現在のソリューションのパフォーマンスは良好です。すべてのポッドはエラスティックネットワークカードを使用します。エラスティックネットワークカードのポッドは、CLBをサポートしてポッドを直接バインドします。これにより、NodePortをバイパスでき、CLBを手動で維持する必要がありません。自動スケーリングをサポートします。コンテンツは最も理想的なソリューションです。
解決策2:グローバルルーターモードクラスターは通常のLoadBalancerモードサービスを使用します
LoadBalancerタイプのサービスの現在のTKEのデフォルト実装はNodePortに基づいており、CLBは各ノードのNodePortをバックエンドRSとしてバインドし、トラフィックをノードのNodePortに転送し、ノードはIptablesまたはIPVSを介してサービスの対応するポストに要求をルーティングします。エンドポッド(Nginx Ingress Controllerのポッドを参照)。
クラスタがVPC-CNI
ネットワークモードでサポートされていない場合は、従来のLoadBalancer
サービスアクセストラフィックアクセス方法で取得できます。
これは、TKEにNginx Ingressをデプロイする最も簡単な方法です。トラフィックはNodePortのレイヤーを通過し、別のレイヤーによって転送されますが、次の問題が発生する可能性があります。
- 転送パスが長い。トラフィックがNodePortに到達すると、Kubernetesの内部負荷バランスを通過し、IptablesまたはIPVSを介してNginxに転送されるため、ネットワーク時間の消費が増加します。
- NodePortの後、必然的にSNATが発生します。トラフィックが集中しすぎると、送信元ポートが使い果たされたり、接続の競合が発生してパケットが失われたり、トラフィックの異常が発生したりする可能性があります。
- 各ノードのNodePortはロードバランサーとしても機能します。CLBが多数のノードのNodePortにバインドされている場合、ロードバランシングの状態が各ノードに分散するため、グローバルな負荷が不均一になりやすくなります。
- CLBはNodePortで正常性検出を実行し、検出パケットは最終的にNginx Ingress Podに転送されます。CLBにバインドされているノードの数がNginxIngress Podを超える場合、検出パケットはNginxIngressに大きな圧力をかけます。
解決策3:HostNetwork + LBを使用する
2番目の解決策は最も単純な展開方法ですが、トラフィックはNodePortのレイヤーを通過するため、上記のような問題が発生する可能性があります。NginxIngressにHostNetworkを使用させ、CLBでノードのIP +ポート(80,443)を直接バインドできます。HostNetworkを使用nginx ingress
しているため、ポートモニタリングの競合を回避するために、ポッドを同じノードにスケジュールすることはできません。
TKEには製品のプログラムがないため、事前に計画を立てて、いくつかのノード、特に展開用に選択しnginx-ingress-controller
、マークされたノードを選択してから、Label
それらのノードに展開するDaemonSetの方法を選択できます(つまり、nginx-ingress-controller
展開シナリオa)。
モニタリングを統合する方法
TKEは、Tencent Cloud Container Team(ポータル:https://console.cloud.tencent.com/tke2/prometheus)の高性能クラウドネイティブ監視サービスを統合し、以前に公開された記事「Prometheusで100,000個のコンテナを監視する方法」でも使用できます。「KubernetesCluster」では、Prometheus、Kvass、およびkvassベースのPrometheusクラスタリングテクノロジーの使用方法について説明します。
監視インスタンスをバインドします
監視データを表示する
ログを収集して消費する方法
TKEログTencentクラウドサービスCLSを統合することにより、完全な製品機能の全範囲を提供し、nginx-ingress-controller
ログの収集と消費電力を実現しますが、注意すべき点がいくつかあります。
- 前提条件:現在のクラスターでログ収集機能が有効になっていることを確認してください
- この
nginx-ingress-controller
例では、ログの取得に関連する構成オプション。
総括する
このペーパーnginx-ingress-controller
では、TKEのNginx Ingressに加えて、TencentクラウドサービスコンソールのFun Nginx Ingressコンテナの使用方法を確認します。主にコンソールに導入されたのは、展開と推奨の2つの方法、および3つの方法のフロントエンドアクセスLBです。ワンクリック展開のTKEはnginx-ingress-controller
、ロギングとモニタリングの機能に関連するクラスター展開製品のサポートも提供します。TKEでNginxIngressを使用したい人にとって、この記事は良いリファレンスとガイドです。