製品アップデート情報
製品リリース記録
Nginxのインストール-ingressインスタンス
フォーカスモード
フォントサイズ
注意：
NginxIngressコンポーネントをインストールする
1. TKEコンソールにログインし、左側ナビゲーションバーからクラスターを選択します。
2. 「クラスター管理」ページで目標のクラスターIDをクリックし、クラスター詳細ページに進みます。
3. 左側メニューバーのコンポーネント管理を選択し、「コンポーネントリスト」ページに進みます。
4. 「コンポーネントリスト」ページで新規作成を選択し、「コンポーネントの新規作成」ページでNginxIngressにチェックを入れます。
5. 完了をクリックしてコンポーネントをインストールします。サービスとルーティング > NginxIngressでコンポーネントの詳細を確認できます。
注意事項
Tencent Cloud Load Balancerインスタンスは2023年3月6日にアーキテクチャがアップグレードされます。アップグレード後、パブリックネットワークCLBはドメイン名の方式でサービスを提供します。VIPは業務リクエストに応じて動的に変化し、コンソールはVIPアドレスを表示しなくなります。ドメイン名型パブリックネットワークCLBリリースのお知らせをご参照ください。
新規登録したTencent Cloudユーザーはデフォルトでアップグレード後のドメイン名型CLBを使用します。
既存のユーザーは元のCLBを継続して使用することを選択でき、アップグレードの影響を受けません。CLBサービスをアップグレードする必要がある場合は、同時にTencent Cloud製品のCLBおよびTKEをアップグレードする必要があります。アップグレードしない場合、TKE内のすべてのパブリックネットワークタイプの Service/Ingressの同期は影響を受ける可能性があります。CLBのアップグレード操作の詳細については、ドメイン名型CLBアップグレードガイドをご参照ください。TKEがService/Ingressコンポーネントのバージョンをアップグレードするには、チケットを提出してお問い合わせください。
インストール方法
さまざまな業務シナリオのニーズに応じて、以下のいくつかのインストール方法を使用してTencent Kubernetes Engine（TKE）にNginx-ingressをインストールすることができます。
DaemonSet形式によって指定ノードプールにデプロイする（推奨）
Nginxをキーとするトラフィックはゲートウェイにアクセスするため、Nginxとその他の業務を同じノード内にデプロイすることはお勧めしません。指定したノードプールを使用してNginx-ingressをデプロイすることをお勧めします。デプロイアーキテクチャは下図のように表示されます。
インストール手順
説明
このインストール方法を使用すると、ノードプールの高速スケーリングの機能をすべて使用でき、その後ノードプールの数量を調整するだけで、Nginxのレプリカをスケーリングすることができます。
1. Nginx-ingressのデプロイに使用するノードプールを準備すると同時に、taint（その他のPodがこのノードプールにスケジューリングすることを防止する）を設定します。デプロイノードプールの詳細については、ノードプール関連説明をご参照ください。
2. クラスター内でNginxIngressコンポーネントをインストールする。
3. クラスター情報ページで、サービスとルーティング > NginxIngressを選択し、Nginx Ingressインスタンスの追加をクリックします（1つのクラスター内には同時に複数のNginxを存在させることができます）。
4. 「NginxIngressの新規作成」で、デプロイオプションのDaemonSetノードプールを指定してデプロイを選択し、必要に応じてその他のパラメータを設定します。下図のように表示されます。
ノードプール：ノードプールを設定します。
Nginx設定：Requstはノードプールのモデルコンフィグレーションより小さく設定する必要があります（ノード自体にリソースの予約があります）。Limitを設定しなくてもかまいません。
イメージバージョンの説明：
Kuberentesのバージョン範囲 | Nginx Ingressコンポーネントがインストールをサポートしているバージョン | Nginxインスタンスがサポートするイメージバージョン |
<=1.18 | 1.1.0、1.2.0 | v0.41.0、v0.49.3 |
| 1.0.0 | v0.41.0 |
1.20 | 1.1.0、1.2.0 | v1.1.3 |
| 1.0.0 | v0.41.0 |
>=1.22 | 1.1.0、1.2.0 | v1.1.3 |
説明
1. コンポーネントで使用するEIPの説明：Nginx Ingressコンポーネントのバージョン1.0.0および1.1.0はTencent CloudEIPサービス（EIP）に依存します。バージョンv1.2.0ではコンポーネントはEIPに依存しません。EIPの使用を制限する必要がある場合、Nginx Ingressコンポーネントをアップグレードすることをお勧めします。コンポーネントのアップグレードは既存のNginx Ingressインスタンスへの影響がなく、業務アクセスやデータセキュリティへの影響もありません。
2. アップグレードの説明：Nginxインスタンスのバージョン説明はingress-nginxドキュメントをご参照ください。クラスターのアップグレードはクラスターのアップグレード操作手順をご参照ください。Nginx Ingressコンポーネントのアップグレードはコンポーネントのアップグレード操作手順をご参照ください。
5. OKをクリックすると、インストールが完了します。
Deployment+HPA形式によってスケジューリングルールを指定してデプロイする
Deployment+HPAの形式を使用してNginx-ingressをデプロイします。業務上のニーズに応じてテイントとトレランスを設定してNginxおよび業務Podを分散してデプロイします。同時にHPAを組み合わせ、Nginxを設定してCPU/メモリなどの指標に基づいて自動スケーリングすることができます。デプロイアーキテクチャは下図のように表示されます。
インストール手順
1. Nginx-ingressのデプロイに使用するノードプールを準備すると同時に、taint（その他のPodがこのノードプールにスケジューリングすることを防止する）を設定します。デプロイノードプールの詳細については、ノードプール関連説明をご参照ください。
2. クラスター内でNginxIngressコンポーネントをインストールする。
3. クラスター情報ページで、サービスとルーティング > NginxIngressを選択し、Nginx Ingressインスタンスの追加をクリックします（1つのクラスター内には同時に複数のNginxが存在することができます）。
4. 「NginxIngressの新規作成」で、デプロイオプションのカスタムDeployment+HPAのデプロイを選択し、必要に応じてその他のパラメータを設定します。下図のように表示されます。
Nginx設定：Requstはノードプールのモデルコンフィグレーションより小さく設定する必要があります（ノード自体にリソースの予約があります）。Limitを設定しなくてもかまいません。
ノードスケジューリングポリシー：ご自身で指定する必要があります。
イメージバージョンの説明：
Kubernetesが1.20以下のバージョンのクラスターは、Nginx Ingressコンポーネントのバージョンが1.0.0で、Nginxインスタンスのイメージバージョンはv41.0のみ選択できます。
Kubernetesが1.20以下のバージョンのクラスターは、Nginx Ingress コンポーネントバージョンが1.1.0ｄｄで、Nginxインスタンスのイメージバージョンはv41.0、 v49.3のみ選択できます。
Kubernetesが1.22バージョン以上のクラスターは、Nginx Ingressコンポーネントのバージョンが1.1.0のみをサポートし、 Nginxインスタンスのイメージバージョンはv1.1.3のみ選択できます。
説明
Nginxインスタンスのバージョン説明はingress-nginxドキュメントをご参照ください。クラスターのアップグレードはクラスターのアップグレード操作手順をご参照ください。Nginx Ingressコンポーネントのアップグレードはコンポーネントのアップグレード操作手順をご参照ください。
5. OKをクリックすると、インストールが完了します。
NginxフロントエンドがLBデプロイにアクセスする方式
Nginxをクラスター内にデプロイしただけでは外部トラフィックを受信することはできず、さらにNginxのフロントエンドLBを設定する必要があります。TKEは現在製品化されたインストール機能を提供し、業務上のニーズに応じてさまざまなデプロイモードを選択することができます。
VPC-CNIモードのクラスターはCLBの使用によりNginxのSerivceと直接アクセスさせる（推奨）
クラスターがVPC-CNIモードのクラスターの場合、CLBを使用してNginxのSerivceに直接アクセスさせることをお勧めします。下図はノードプールでデプロイされたロードの例です。
現在の方法は性能が高く、手動でCLBをメンテナンスする必要がなく、最も理想的な方法です。この方法はクラスターがVPC-CNIをサポートしている必要があり、クラスターにVPC-CNIネットワークプラグインが設定されているか、Global Routerネットワークプラグインが設定されている場合はVPC-CNIのサポート（2種類のモードを併用）を有効化し、この方法を使用することをお勧めします。
Globalrouterモードのクラスターは通常LoadbalancerモードのServiceを使用する
クラスターがVPC-CNIモードのネットワークをサポートしていない場合、通常のLoadbalancerモードServiceによってトラフィックにアクセスします。現在TKEのLoadBalancerタイプのServiceはデフォルトでNodePortに基づいて実現され、CLBは各ノードのNodePortをバックエンドRSとしてバインドし、トラフィックをノードのNodePortに転送します。その後ノード上でさらにiptablesまたはipvsによってリクエストをServiceに対応するバックエンドPodにルーティングします。この方法は最も簡単な方法ですが、トラフィックはNodePortを通過し、もうひとつの層によって転送されます。以下のような問題が存在する可能性があります。
転送パスが長い場合、トラフィックはNodePortに到達するとさらにk8s内部のCLB、iptablesまたはipvsを介してNginxに転送され、ネットワークの消費時間が増加します。
NodePortを通過すると必然的にSNATが発生します。トラフィックが集中しすぎるとソースポートの枯渇またはconntrack插入の競合によってパケットロスを引き起こしやすくなり、一部のトラフィックに異常が発生します。
各ノードのNodePortも1つのロードバランサとしても機能します。CLBが大量ノードのNodePortをバインドしている場合、CLBの状態は各ノードに分散し、コンテナはグローバルロードバランシングが不均一になります。
CLBはNodePortにヘルスチェックを行い、検出パケットは最終的にnginx ingressのPodに転送されます。 CLBにバインドされたノードが多く、Nginx-ingressのPodが少ない場合、検出パケットはNginx-ingressに対して大きな圧力を発生させます。
HostNetwork+LBモードを使用する
コンソールは現時点ではサポートしていません。手動でNginxワークロードのYaml設定ネットワークモードをHostNetworkに変更し、CLBバインドNginxが公開するノードポートを手動で作成します。
hostNetworkを使用する時は、ポートリスニングの競合を避けるために、Nginx-ingressのPodは同一ノードにスケジューリングすることができないことに注意する必要があります。
TKEによってNginx-ingressのデフォルトパラメータをインストールする
Nginx-ingressパラメータを設定する
Nginx-ingressコンポーネント詳細ページで、Ningxパラメータtabから選択したNginx-ingressインスタンスにYAML編集を行います。
注意
デフォルト状態で設定パラメータはNginxを再起動させず、有効時間がわずかに遅延します。
1. TKEコンソールにログインし、左側ナビゲーションバーからクラスターを選択します。
2. 「クラスター管理」ページで目標のクラスターIDをクリックし、クラスター詳細ページに進みます。
3. 左側メニューバーのコンポーネント管理を選択し、「コンポーネントリスト」ページに進みます。
4. パラメータを設定する必要があるコンポーネント右側のNginx設定の更新をクリックし、「Nginx設定」ページに進みます。
5. Nginx Ingressインスタンスを選択し、YAMLの編集をクリックします。
6. 「ConfigMapの更新」ページで編集し、完了をクリックすればパラメータの設定は完了です。
パラメータの設定例
apiVersion: v1kind: ConfigMapmetadata:name: alpha-ingress-nginx-controllernamespace: kube-systemdata:access-log-path: /var/log/nginx/nginx_access.logerror-log-path: /var/log/nginx/nginx_error.loglog-format-upstream: $remote_addr - $remote_user [$time_iso8601] $msec "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $request_length $request_time [$proxy_upstream_name] [$proxy_alternative_upstream_name] [$upstream_addr] [$upstream_response_length] [$upstream_response_time] [$upstream_status] $req_idkeep-alive-requests: "10000"max-worker-connections: "65536"upstream-keepalive-connections: "200"
注意
access-log-path 、error-log-path、log-format-upstreamを変更しないでください。変更した場合、 CLSログ収集に影響を与える可能性があります。業務に応じて異なるパラメータを設定する必要がある場合は、公式ドキュメントをご参照ください。
フィードバック