Kubernetes Ingressの説明

ポイント: Kubernetes Ingressは、Kubernetesクラスター内のサービスへのアクセスのためのルーティングルールを管理し、セキュリティと負荷分散を向上させるAPIオブジェクトです。これにより、単一のエントリーポイントとして機能し、サービスの公開を簡素化します。

Ingressは、トラフィックルーティングのためのAPIオブジェクトとIngressコントローラーで構成されています。
複数のプロトコル、認証、コンテンツベースのルーティングをサポートしています。

任意のKubernetesクラスターでは、アプリケーションが外部と接続できる必要があり、エンドユーザーにアプリケーションへのアクセスを提供します。Kubernetes Ingressは利用可能なオプションの1つです。見てみましょう。

Kubernetes Ingressとは何ですか？

Kubernetes Ingressは、Kubernetesクラスター内のサービスへのアクセスを管理するルーティングルールを提供するAPIオブジェクトです。通常、HTTPSおよびHTTPプロトコルを使用してルーティングを容易にします。

Ingressは、プロダクション環境に最適な選択肢です。ユーザーは、複数のロードバランサを作成したり、サービスを手動で公開したりすることなく、Kubernetesクラスター内のサービスを公開できます。

さらに、K8s Ingressはクラスターの単一のエントリーポイントを提供し、管理者がアプリケーションを簡単に管理し、ルーティングの問題を診断できるようにします。これにより、クラスターの攻撃面が減少し、全体的なセキュリティが自動的に向上します。

Kubernetes Ingressのいくつかのユースケースには、以下が含まれます：

サービスのための外部からアクセス可能なURLを提供する
トラフィックの負荷分散
名前ベースの仮想ホスティングを提供する
SSL（セキュアソケットレイヤー）またはTLS（トランスポート層セキュリティ）の終了

Kubernetes Ingressは複数のプロトコル、認証、コンテンツベースのルーティングなどをサポートし、ユーザーがKubernetesクラスター内で簡単に管理および構成できるようにします。

Kubernetes Ingressは、2つのコアコンポーネントで構成されています：

Ingress APIオブジェクト。 APIオブジェクトは、クラスターの外部に公開する必要のあるサービスを示します。ルーティングルールで構成されています。
Ingressコントローラー。 Ingressコントローラーは、Ingressの実際の実装です。通常、APIからKubernetesクラスター内の目標サービスにトラフィックをルーティングするロードバランサです。

Ingressコントローラーとは何ですか？

Kubernetes Ingressの実際の実装であるIngressコントローラーは、外部ソースからKubernetesクラスター内の適切なサービスへのトラフィックをルーティングする責任があります。Ingressコントローラーは、OSIモデルのトランスポート層（OSI - レイヤー4）およびアプリケーション層（OSI - レイヤー7）を通じてルーティングをサポートします。

アプリケーション層のルーティングは、要求に基づいた外部トラフィックの負荷分散など、より大きな制御を提供するため、単純なトランスポート層のルーティングよりも好まれます。Ingressコントローラーは、Kubernetesクラスターで自動的に起動されることはなく、デフォルトの「kube-controller-manager」バイナリの一部でもありません。

Kubernetesは、AWS、GCE、およびnginx Ingressコントローラーのための組み込みサポートを提供し、サードパーティのIngressコントローラーとの統合もサポートしています。Ingressコントローラーの選択は、以下に依存します：

あなたのアプリケーションの要件
ホスト環境

簡単に言えば、IngressコントローラーはKubernetesクラスター内で実行されるアプリケーションであり、Ingressの要件に従ってロードバランサをプロビジョニングします。（ロードバランサはソフトウェアロードバランサ、外部ハードウェアロードバランサ、またはクラウドロードバランサであり、各タイプは異なるコントローラー実装を必要とします。）

サービスを公開するためのIngressと代替手段

Ingressを使用することは、サービスを公開する唯一の方法ではありません。

Kubernetesサービスリソースは、ターゲットアプリケーションポッドのセットをネットワークサービスとして公開するための抽象的な方法を提供します。同時に、Kubernetesは、クラスター内部およびクラスター外部でサービスを公開するために、ClusterIP、NodePort、およびLoad Balancerメソッドを使用します。

ClusterIPは、内部クラスターIPを使用してサービスを公開するデフォルトのサービスタイプです。この方法では、クラスター内のサービスのみが公開され、外部からは到達できません。
NodePortは、望ましいノードに関連付けられた静的ポートを使用してサービスを公開します。NodePortの構成は、自動的にClusterIPを作成し、内部でトラフィックをルーティングします。ユーザーは、ノードのIPアドレスと公開されたポートを使用して、外部からサービスにアクセスできます。
LoadBalancerは、クラウドプロバイダーのロードバランサを使用してサービスを公開し、自動的に必要なNodePortとClusterIPを作成して目的のトラフィックをルーティングします。

(NodePort、ポートおよびTargetPortについて学ぶ。)

サービスを個別に公開して管理することは、非効率的であり、大規模なKubernetesクラスターではスケーラブルではありません。それが、Ingressが理想的なソリューションとなる理由です。クラスター全体のエントリーポイントとして機能することで、ユーザーは以下を実現できます：

集中リソースからすべてのルーティングルールを管理する
単一のIPアドレスの下で複数のサービスを公開する

Ingressリソースの作成

では、Ingressリソースを作成する方法を見てみましょう。

Kubernetesの他のリソースと同様に、IngressリソースもapiVersion、kind、およびmetadataフィールドで構成され、specセクションの下に必要なルールと構成があります。

シンプルなIngress設定

    apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/app-root: /test_app
  name: testapproot
  namespace: default
spec:
  rules:
  - host: testapproot.mycluster.com
    http:
      paths:
      - backend:
          serviceName: http-svc
          servicePort: 80
        path: /

Ingressリソースを定義する際、Ingressオブジェクトの名前は有効なサブドメインDNS命名規則に従う必要があります。さらに、アノテーションを使用して特定のオプションでIngressリソースを構成することができます。上記のYAMLファイルでは、ルートパスが呼び出されたときにIngressコントローラーがリダイレクトする必要のあるアプリケーションルートを定義するために、"nginx.ingress.kubernetes.io/app-root"オプションを使用しています（パス：/）。

異なるタイプのIngressコントロールは異なるアノテーションサポートを含むため、ユーザーは必要なコントローラーに合わせてアノテーションを修正する必要があります。

Ingressルール

IngressルールはKubernetes Ingressの核心です。これらは、着信トラフィックに何が起こるか、およびそのトラフィックがどのサービスに向かうべきかを定義します。各HTTPルールは、ルールを適切に定義するための複数のフィールドで構成されています。

ホストは、ルールが適用されるホストを定義するオプションのパラメータです。ホストパラメータが定義されていない場合、ルールはすべての着信HTTPトラフィックに適用されます。
パスは、バックエンドに関連付けられたパスのリストを指します。ホストとパスの両方が一致する必要があります。
バックエンドは、着信トラフィックが最終的に向かうべき宛先です。これはKubernetesサービスであるか、同じ名前空間内の別のリソースを示すカスタムリソースバックエンドである可能性があります（例：ストレージバケット）。

定義されたルールのいずれにも一致しないリクエストは、デフォルトのバックエンドに送信されます。このデフォルトのバックエンドはIngressコントローラーの一部であり、Ingressリソース内で指定されません。

複数のIngressルールの定義

Ingressリソースについてより良く理解したので、異なるホストとバックエンドを持つ複数のIngressルールを定義する方法を見てみましょう。

Ingressの種類

    apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: myapp
spec:
  rules:
  - host: "app.mycluster.com"
    http:
      paths:
      - pathType: Prefix
        path: "/home"
        backend:
          serviceName: http-app
          servicePort: 80
      - pathType: Prefix
        path: "/admin"
        backend:
          serviceName: http-app
          servicePort: 8080
  - host: "data.mycluster.com"
    http:
      paths:
      - pathType: Prefix
        path: "/charts"
        backend:
          serviceName: http-charts
          servicePort: 81

上記の構成では、異なるサービスを消費する2つの異なるホストに対して3つのルーティングルールを構成しました。

ホスト: "app.mycluster.com"

このセクションには、app.mycluster.comに向けられたトラフィックにのみ適用される2つのルールが含まれています。URLパスが/homeまたは/adminのいずれかに一致する場合、トラフィックは同じサービスの異なるポートに向けられます。

ホスト: "data.mycluster.com"

単一のルールがdata.mycluster.comホストに向けられたトラフィックに適用され、URLパスが/chartsに一致する場合、そのトラフィックは「http-charts」サービスのポート81に向けられます。

Kubernetes Ingressパスタイプ

ルールを定義する際、パスにはルールを正しく検証するための対応するパスタイプを含める必要があります。Kubernetesには3つのパスタイプがあります：

これは、Ingressコントローラーに定義されたIngressClassの構成と一致します。これは別のパスタイプまたはPrefixまたはExactタイプと同じように扱われます。
ユーザーが大文字小文字を区別してURLパスと完全に一致させる必要がある場合、このタイプを使用できます。
これは、スラッシュ（/）で分割されたパスプレフィックスに基づいてURLと一致します。これも大文字小文字を区別し、一致プロセスはURL内の要素ごとに行われます。

では、いくつかのパスマッチングシナリオを見てみましょう。

パスタイプ	パス	サンプルリクエスト	マッチ
完全一致	/test	www.example.com/test	はい
完全一致	/test	www.example.com/test/	いいえ
接頭辞	/test	www.example.com/test www.example.com/test/	はい（両方のURL）
接頭辞	/test/user	www.example.com/test/us	いいえ

リクエストに対して複数の一致がある場合、最も長い一致パスのリクエストが優先されます。両方のパスが完全に一致する場合、Ingressコントローラーは、必要なIngressルールを適用するために接頭辞よりも完全一致パスタイプを選択します。

(公式Kubernetesのドキュメント）で全てのマッチングシナリオをさらに詳しく見てみましょう。

Kubernetesには3つのタイプのIngressがあります；
単一サービス。これは、単一のサービスが公開されるIngressです。これを定義するには、ルールなしでデフォルトのバックエンドを指定します。
シンプルファンアウト。ファンアウトタイプは、単一のエントリーポイント（単一のIPアドレス）を使用して複数のサービスを公開するものです。ここで、URLトラフィックは要求に応じて目的地にルーティングされます。この方法により、ユーザーはロードバランサの数を減らし、クラスター内のルーティングを簡単に管理できます。
名前ベースの仮想ホスティング。この方法は、単一のエントリ（IPアドレス）からクラスター内の異なるホストにトラフィックをルーティングするために使用できます。ここでは、最初に指定されたホストにトラフィックがターゲットされ、その後に他のルーティングが行われます。
ユーザーは、サポートされたTLSキーと証明書を持つシークレットを指定することでIngressを保護できます。Ingressリソースは単一のTLSポート（443）をサポートし、IngressポイントでのTLS終了を想定しています。その後、内部通信は平文で行われます。
サービスをより良く管理し、セキュリティを向上させる
Kubernetes Ingressは、サービスやロードバランサを手動で管理することなく、Kubernetesクラスター内のアプリケーションへのトラフィックを管理しルーティングするための統一されたリソースを提供します。
関連する読書
 BMC DevOpsブログ
Kubernetesのベストプラクティスによるクラスター効率の向上
コンテナとKubernetesの連携
KubernetesとDocker Swarm：コンテナオーケストレーションツールの比較
Dockerセキュリティ：Dockerコンテナを保護するための14のベストプラクティス
今日のコンテナの状態：報告概要

Kubernetesガイド

これらの投稿は私自身のものであり、必ずしもBMCの立場、戦略、または意見を表しているわけではありません。

ワークフローオーケストレーション

メインフレーム簡素化

人気の目的地

Kubernetes Ingressとは何ですか？

Ingressコントローラーとは何ですか？

サービスを公開するためのIngressと代替手段

Ingressリソースの作成

シンプルなIngress設定

Ingressルール

複数のIngressルールの定義

Ingressの種類

Kubernetes Ingressパスタイプ

サービスをより良く管理し、セキュリティを向上させる

関連する読書

Kubernetesガイド

最新のメインフレーム開発ツールを試す

ITOps・DevOpsの関連記事

The Briefを購読する

ありがとう

ご要望またはご協力できることがございましたらお気軽にお問い合わせください

セールス & お見積り

ヘルプ & サポート

人気の目的地

Kubernetes Ingressの説明

Kubernetes Ingressとは何ですか？

Ingressコントローラーとは何ですか？

サービスを公開するためのIngressと代替手段

Ingressリソースの作成

シンプルなIngress設定

Ingressルール

複数のIngressルールの定義

Ingressの種類

Kubernetes Ingressパスタイプ

サービスをより良く管理し、セキュリティを向上させる

関連する読書

Kubernetesガイド

ITOps・DevOpsの関連記事

The Briefを購読する

ありがとう