Ingress/IngressController/IngressClass の違いを 5 分で理解する

一言でまとめると、Ingress は Ingress ルール、IngressController、IngressClass の 3 つの部分で構成されます。入力リソースは、一連のルーティング転送構成にすぎません。ルーティング ルールを有効にするには IngressController を使用する必要があります。IngressClass は IngressController の特定の実装です。使用原則: 最初に IngressController をデプロイし、次に Ingress リソースをデプロイします。

1. 理論

1.1 イングレスの概念

Ingress の前に、Service の nodePort を通じてサービスを公開し、コンテナ ポートを Service の nodePort にマップできます。この方法では、クラスター内の任意のノードの IP:nodePort にアクセスすることでクラスターにアクセスできます。この形式のサービス公開は TCP/IP 層で機能します。または、Pod ポートを HostPort にマップします。

ただし、これには、ノード ポートが多すぎることやドメイン名を転送できないことなど、多くの欠点があります。

そこで、Ingressという概念が導入されました。 Ingress は、Nginx に似た 7 層のルーティング フォワーダーです。ルーティング転送に Ingress を使用する場合、ingressController は Ingress ルールに基づいて、クライアント要求をサービスに対応する Pod に直接転送します。これにより、kube-proxy によって設定されたルーティング転送ルールがスキップされ、ネットワーク転送の効率が向上します。

1.2.イングレス構成

Ingress リソースは一種の仮想リソースとルール定義であり、有効にするには ingressController と連携する必要があります。したがって、Ingress リソースが機能するには、クラスターで ingressController が実行されている必要があります。

Ingress は、Ingress ルール、IngressController、IngressClass の 3 つの部分で構成されます。 Ingress ルールは、有効にするために IngressController で使用する必要のある一連の構成にすぎず、IngressClass は IngressController の特定の実装です。関係は次のようになります。

1.3. Ingress の機能とワークフロー

ingressController の実装は Ingress-Nginx、Traefik、Kong Ingress など多数あるため、YAML オーケストレーション ファイルで ingressClass を指定する必要があります。

Ingress リソースが正常にデプロイされ、作成されると、IngressController は構成されたルーティング ポリシーを監視し、それを Nginx 構成ファイルに更新して有効にします。

まとめると、IngressController の機能は次のとおりです。

• 外部トラフィックを受け入れ、内部で実行されているポッドへのリクエストを負荷分散する
• イングレスルーティングと転送ルールをデプロイする
• Kubernetesで実行中のPodを監視し、Podが追加または削除されたときに負荷分散ルールを自動的に更新します。

Ingress のワークフローは次のとおりです。

2. 練習

2.1、IngressClassのインストール

この記事では ingress-nginx を使用していますが、自分で練習することもできます。

公式ウェブサイトアドレス: https://kubernetes.github.io/ingress-nginx/deploy/#quick-start

helm または kubectl を通じてインストールできます。この記事では kubectl を使用してインストールします。 yaml ファイルには多くのコンテンツが含まれているため、ダウンロードして自分で読むことができます。インストールするには、次のコマンドを実行します。

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

2.2. YAMLのアレンジ

IngressController がデプロイされたら、YAML の配置を開始します。

コンテナ イメージが Nginx である Pod は YAML で定義され、Service を通じて Pod に関連付けられ、Ingress ルールを通じてアクセスされます。

 apiVersion: v1 kind: Pod metadata: name: web-app namespace: demo labels: app: web-app spec: containers: - name: web-app image: nginx imagePullPolicy: IfNotPresent ports: - containerPort: 80 --- apiVersion: v1 kind: Service metadata: name: web-service namespace: demo labels: app: web-service spec: selector: app: web-app # ClusterIP | LoadBalancer | NodePort，使用Ingress就没必要设置成NortPort type: ClusterIP clusterIP: None ports: - name: web-service-port protocol: TCP port: 80 targetPort: 80 --- # 创建Ingress策略apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/rewrite-target: / name: web-ingress namespace: demo spec: # 指定ingressClass ingressClassName: nginx rules: - host: web-ingress.mangod.top http: paths: - path: / pathType: Prefix backend: service: name: web-service port: number: 80

2.3 展開テスト

YAML を配置したら、kubectl apply コマンドを使用してデプロイします。デプロイ後、ドメイン名と K8S-Node ノード間のマッピング関係をローカルの /etc/hosts で設定します (もちろん、本番環境でのアクセス リンクはこれよりも長くなりますが、これについては後で説明します。この記事では、簡単にテストできるように、DNS をローカルで直接設定します)。マッピング関係は次のようになります。

 10.20.1.23 web-ingress.mangod.top

次に、ブラウザを使用して http://web-ingress.mangod.top/ にアクセスします。インターフェースは次のようになり、Ingress が正常に使用されていることがわかります。

今回は以下のコマンドを使用して、ingressController に対応するポッドに入り、検証を続けます。おなじみの nginx.conf が表示されます。以前に構成されたイングレス ルールは、次のように構成で確認できます。

 kubectl get pods -n ingress-nginx kubectl exec ingress-nginx-controller-nginx-d864d97df-22ljk -it -n ingress-nginx /bin/bash

これで練習のプロセスは終了です。

3. まとめ

要約すると、Ingress は Ingress ルール、IngressController、IngressClass の 3 つの部分で構成されます。入力リソースは、一連のルーティング転送構成にすぎません。ルーティング ルールを有効にするには IngressController を使用する必要があります。IngressClass は IngressController の特定の実装です。使用原則: 最初に IngressController をデプロイし、次に Ingress リソースをデプロイします。