Kubernetes での Nginx Ingress の理解

Ingress の役割は何ですか?クラスター外部からクラスター内のサービスへのアクセス (通常は HTTP リクエスト) を管理します。負荷分散、SSL 終了、ドメインベースの仮想ホスティングアクセスを提供できます。これらの機能は比較的簡単に実装できることがわかりました。クラスター内のサービスをクラスター外に公開するには、「NodePort」タイプのサービスを使用し、HAProxy を使用して負荷分散を実現し、7 層のリバースプロキシを使用して SSL 終了機能を展開することができます。ドメイン名ベースの仮想ホストアクセスも実装が比較的簡単です。では、Kubernetes が Ingress API オブジェクトを導入するのはなぜでしょうか?

Ingressの可能性

冒頭でも述べたように、Ingress の機能は他の技術を使って実装することも可能ですが、実際に運用してみると、それほど単純ではないことがわかります。 Ingress が参加しない場合、クラスター内のサービスは「NodePort」タイプのサービスを使用してクラスターの外部に公開されます。このタイプのサービスは、マイクロサービスごとに作成する必要があります。サービスが多数ある場合、トラブルシューティングは非常に複雑になり、ホストポートの使用を調整するのも面倒になります。クラスターの外部に Nginx または Apache を展開することで、SSL ターミネーションとドメイン名ベースの仮想ホストアクセスを実現できますが、サービス検出と構成管理が課題となります。クラスター外の Nginx と Apache はクラスター内のサービスの増減を認識できず、手動での構成が必要になります。これはクラスター管理者にとっては悪夢です。幸いなことに、Ingress はここにあります。

インストール

Kubernetes にサービスをインストールするのは通常簡単で、単に「kubectl apply」に続けて yaml ファイルを使用するだけです。もちろん、Kubernetes のパッケージ管理ツールである Helm を使用することもできます。「nginx ingress」には、環境に応じて 3 つのインストール方法があります。

ヘルムを使用します。
kubectl +yamlfiles を適用します。
minikube または MicroK8s では、プラグインとしてインストールします。

著者は、この記事で紹介した方法を使用して Kubernetes クラスターをインストールします。ここでは、2 番目の方法を使用して「nginx ingress」をインストールします。以下のコマンドを実行します（バージョンアップが速いため、実際の展開は公式サイトを参照してください）。

 kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.1.1/deploy/static/provider/baremetal/deploy.yaml

インストールにより、「k8s.gcr.io」イメージリポジトリからイメージが取得されます。プルが失敗した場合は、Alibaba Cloud などを選択できます。

追加されたクラスターリソースを表示します。

 [ root @master ~] # kubectl get all - n ingress-nginx
 名前準備完了ステータス再起動年齢
pod / ingress-nginx-admission-create- 7k9kt 0/1 完了0 14d
 pod / ingress-nginx-admission-patch- 5bcmq 0/1 完了1 14d
 pod / ingress-nginx-controller-687578654b-f92bq 1 / 1 実行中3 ( 42日前) 14日
名前タイプクラスターIP 外部IP ポート( S ) 年齢
サービス/ ingress-nginx-controller NodePort 10.1.70.249 < なし> 80 : 30305 / TCP 、 443 : 31330 / TCP 14d
 サービス/ inginx-nginx-controller-admission ClusterIP 10.1.124.31 <なし> 443 / TCP 14d
 名前準備完了最新利用可能年齢
デプロイメント.apps / ingress-nginx-controller 1 / 1 1 1 14d
 名前希望現在の年齢
レプリカセット.apps / ingress-nginx-controller-687578654b 1 1 1 14d
 名前完了期間年齢
ジョブ.batch / ingress-nginx-admission-create 1 / 1 5秒14日
ジョブ.batch / ingress-nginx-admission-patch 1 / 1 7秒14日

クラスターは独自に構築されているため、「ingress-nginx-controller」のサービスタイプは「NodePort」です。サービスにアクセスするには、次の方法が必要です: NodeIP+30305/31330+Path。

使用

前の操作が正常に実行されたら、Ingress タイプの API オブジェクトを作成できます。著者のクラスターには事前に Web サービスがデプロイされています。サービス情報は以下の通りです。

 [ ルート@master ~] # kubectl get svc
 名前タイプクラスターIP 外部IP ポート( S ) 年齢
nginx クラスタIP 10.1.133.186 < なし> 80 / TCP 14時間

Ingress API オブジェクトを作成します。

 1 > ---
 2 > apiバージョン: ネットワーク.k8s .io / v1
 3 > 種類: イングレス
4 > メタデータ:
 5 > 名前: 自己nginx
 6 > 名前空間: テスト
7 > 注釈:
 8 > nginx .ingress .kubernetes .io / 書き換えターゲット:/
 9 > 仕様:
 10 > イングレスクラス名: nginx
 11 > ルール:
 12 > - ホスト: mynginx .example .com
 13 > http :
 14 > パス:
 15 > - パス: / testpath
 16 > パスタイプ: プレフィックス
17 > バックエンド:
 18 > サービス:
 19 > 名前: nginx
 20 > ポート:
 21 > 番号: 80

以前にインストールした nginx ingress をデフォルトの Ingress として設定しなかった場合は、行 10 を追加する必要があります。そうしないと、Ingress リソースが API サーバーに送信されても、「nginx ingress コントローラー」は応答しません。「ingressClassName」の値を取得します。

 [ root @master ~] # kubectl get ingressclass
 名前コントローラパラメータ年齢
nginx k8s .io / ingress-nginx <なし> 14d

作成された Ingress を表示します。

 [ root @master ~] # kubectl get ingress
 名前クラスホストアドレスポート年齢
自己nginx nginx mynginx .example .com 192.168.52.132 80 125m

Ingress を介して Web サービスにアクセスします (ドメイン名が解決されない場合は、/etc/hosts ファイルを変更します)。

 [ root @master nginx ] # curl mynginx .example .com : 30305 / testpath
 こんにちは、 Kubernetes !

原理

Nginx Ingress の導入と使用は難しくありません。最も重要なことは、問題に遭遇したときにすぐにそれを特定できるように、その動作原理に精通することです。「ingress-nginx-controller」ポッドで実行されているコンテナは 1 つだけですが、このコンテナには複数のデーモンが含まれており、そのうち 2 つ (controller と nginx) が重要です。 Pod に入り、 ps コマンドを実行して以下を表示します。

 [ root @master ~] # kubectl exec -it ingress -nginx-controller-687578654b-f92bq -n ingress -nginx -- / bin / bash
 bash - 5.1 $ ps
 PID ユーザータイムコマンド
1 www-data 0 : 00 / usr / bin / dumb-init -- / nginx-ingress-controller --election-id = ingress-controller-leader --controller -class = k8s.io / ingress-nginx --config
 7 www-data 11 : 28 / nginx-ingress-controller --election-id = ingress-controller-leader --controller-class =k8s.io / ingress-nginx --configmap = ingress-nginx / ingr
 25 www-data 0:00 nginx : マスタープロセス/ usr / local / nginx / sbin / nginx - c / etc / nginx / nginx.conf
 247 www-data 0 : 01 nginx : ワーカープロセス
248 www-data 0 : 00 nginx : キャッシュマネージャープロセス

コントローラは、下図に示すように、サービス検出と自動構成機能を実装するマネージャです（公式サイトからダウンロード）。

nginx ingressの仕組み

この図は複雑に見えますが、一言でまとめると、「Ingress Controller」(図の IC) はシステム管理者に相当します。要求者は Ingress リソースを API サーバーに送信し、IC は API サーバーから Ingress リソースを取得します。 IC は Ingress リソースと Nginx の両方を理解するため、Ingress の「変換」を完了し、Nginx 構成ファイルを更新してリロード操作を実行します。これが核となるロジックです。

上記では、「nginx」サービス用の Ingress リソースを作成し、アクセスパスを「/testpath」として設定しました。ここで、「ingress-nginx-controller」ポッドに入り、Nginx 構成ファイル /etc/nginx/nginx.conf を確認します。

仮想ホスト「mynginx.example.com」には 200 行を超える構成があります。無関係なものは削除してください。

 # # サーバーmynginx .example .com を起動します
サーバー{
 サーバー名mynginx .example .com ;
 聞く80 ;
 443 ssl http2 をリッスンします。
 $ proxy_upstream_name を"-" に設定します。
 ssl_certificate_by_lua_block {
 証明書.call ()
 }
 場所~* "^/testpath" {
 $ 名前空間を「test」 に設定します。
 $ ingress_name を"self-nginx" に設定します。
 $ service_nameを"nginx" に設定します。
 $ service_port を"80" に設定します。
 $ location_path を"/testpath" に設定します。
 $ global_rate_limit_exceeding n を設定します。
 ......
 $ balancer_ewma_score -1 を設定します。
 $ proxy_upstream_nameを"test-nginx-80" に設定します。
 $ proxy_host $ proxy_upstream_name を設定します。
 $ pass_access_scheme $ scheme を設定します。
 ......
 「(?i)/testpath」 を書き換えて、 改行します。
 proxy_pass http :// upstream_balancer ;
 proxy_redirect オフ;
 }
 場所~* "^/" {
 $ 名前空間を「test」 に設定します。
 $ ingress_name を"self-nginx" に設定します。
 $ service_name を"" に設定します。
 $ service_port を"" に設定します。
 $ location_path を"/" に設定します。
 $ global_rate_limit_exceeding n を設定します。
 ......
 proxy_pass http :// upstream_balancer ;
 proxy_redirect オフ;
 }
 }
 # # エンドサーバーmynginx .example .com

設定ファイルからは、「/testpath」に送信されたリクエストが 1 回のジャンプを完了した後に最終的に「upstream_balancer」に送信されていることがわかります。 Nginx 構成ファイルでの定義は次のとおりです。

 アップストリームアップストリームバランサー{
 # # # 注意!!!
 #
 # すべてのバックエンドに対して「アップストリーム」 セクションを作成しなくなりました。
 # バックエンドはLua を使用して動的に処理されます。 デバッグしたい場合 
 # そして、 ingress-nginx のメモリ内にどのようなバックエンドがあるか確認するには、
 # kubectl プラグインをインストールしますhttps://kubernetes.github.io/ingress-nginx/kubectl-plugin 。
 # プラグインを入手したら、 「kubectl ingress-nginx backends」 コマンドを使用して
# 現在のバックエンドを検査します。
 #
 # # #
 サーバー0.0.0.1 ; # プレースホルダー
バランサー_by_lua_block {
 バランサー.バランス()
 }
 キープアライブ320 ;
 キープアライブタイムアウト60秒;
 キープアライブリクエスト10000 ;
 }

Nginx 構成ファイルは Lua に大きく依存しているため、ここで表示される情報は直感的ではありません。バックエンドサービスを表示するには、コメントに従って、kubectl の「ingress-nginx」プラグインをインストールします。以前の Nginx 構成ファイルには、次の行があります。

 $ proxy_upstream_nameを"test-nginx-80" に設定します。

ドメイン名「mynginx.example.com」のバックエンド名が「test-nginx-80」であることを示します。 Ingress のバックエンドを表示します (無関係な行は無視します)。

 [ root @master ~] # kubectl ingress-nginx バックエンド- n ingress-nginx
 [
 {
 「名前」 : 「test-nginx-80」 、
 "サービス" ： {
 「メタデータ」 : {
 「作成タイムスタンプ」 : null
 },
 「仕様」 : {
 「ポート」 : [
 {
 「名前」 : 「http」 、
 「プロトコル」 : 「TCP」 、
 「ポート」 : 80 、
 "ターゲットポート" : 80
 }
 ]、
 「セレクタ」 : {
 「アプリ」 : 「nginx」
 },
 "クラスターIP" : "10.1.133.186" ,
 「クラスターIP」 : [
 「10.1.133.186」
 ]、
 「タイプ」 : 「ClusterIP」 、
 "セッションアフィニティ" : "なし" 、
 「ipファミリー」 : [
 「IPv4」
 ]、
 「ipFamilyPolicy」 : 「シングルスタック」 、
 "内部トラフィックポリシー" : "クラスター"
 },
 "状態" ： {
 「ロードバランサー」 : {}
 }
 },
 「ポート」 : 80 、
 "sslPassthrough" : false 、
 「エンドポイント」 : [
 {
 「アドレス」 : 「10.244.1.26」 、
 「ポート」 : 「80」
 }
 ]、
 "セッションアフィニティ構成" : {
 "名前" ： "" 、
 "モード" : "" ,
 「cookieSessionAffinity」 : {
 "名前" ： ""
 }
 },
 「upstreamHashByConfig」 : {
 「サブセットサイズによる上流ハッシュ」 : 3
 },
 "noServer" : false 、
 「トラフィックシェーピングポリシー」 : {
 「重量」 : 0 ,
 "重量合計" : 0 ,
 「ヘッダー」 : 「」 、
 "ヘッダー値" : "" ,
 "ヘッダーパターン" : "" ,
 「クッキー」 : 「」
 }
 },
 ......

 ]

出力から、バックエンドは実際には「nginx」という名前のサービスに対応するエンドポイントであり、その IP は「10.244.1.26」であることがわかります。

 [ root @master ~] # kb エンドポイントを取得
名前エンドポイント年齢
nginx 10.244.1.26:80 19 時間

ここで強調しておきたいのは、Nginx Ingress はトラフィックを nginx サービスに転送するのではなく、バックエンドの Pod に直接転送するということです。転送戦略も Ingress コントローラによって完全に決定されます。これにより、DNAT が 1 つ削減されるだけでなく、より豊富な負荷分散戦略も可能になります。 Ingress リソースに表示されるサービスオブジェクトは、バックエンドエンドポイントを選択するためだけに使用されます。