--- title: "ALB Ingress Controller 活用のユースケース" slug: "k8s-k8sexamples-albingress" tags: ["Kubernetes Service", "vpc", "ALB Ingress Controller"] updated: 2026-09-17T09:31:49Z published: 2026-09-17T09:31:49Z canonical: "guide.ncloud-docs.com/k8s-k8sexamples-albingress" stale: true --- > ## Documentation Index > Fetch the complete documentation index at: https://guide.ncloud-docs.com/llms.txt > Use this file to discover all available pages before exploring further. # ALB Ingress Controller 活用のユースケース VPC環境で利用できます。 Ncloud Kubernetes Serviceでは、Serviceと Ingressにアノテーションを追加することで、様々なルーティング戦略を実装できます。このガイドでは、[ALB Ingress Controller設定](/docs/ja/k8s-k8suse-albingress)を基に使用できるユースケースを提供します。 ## ユースケース用ワークロードのインストール ユースケース用の Deploymentと Serviceは下記のコマンドを実行してインストールできます。コマンドを実行すると、「naver」、「cloud」、「platform」という名前の Deploymentと Serviceが作成されます: ``` kubectl --kubeconfig=$KUBE_CONFIG apply -f https://raw.githubusercontent.com/NaverCloudPlatform/nks-alb-ingress-controller/main/docs/examples/pub/nks-alb-ingress-sample-services.yaml ``` ## ALB Ingress Controller活用のユースケース ### パスベースルーティングのユースケース このユースケースは、リクエストを指定されたパスに応じて異なるサービスにルーティングする方法を示しています。/naverパスに入るリクエストは naverサービスにルーティングされ、/cloudパスに入るリクエストは cloudサービスにルーティングされます。 ``` apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: path-ingress spec: ingressClassName: alb rules: - http: paths: - path: /naver pathType: Prefix backend: service: name: naver port: number: 80 - path: /cloud pathType: Prefix backend: service: name: cloud port: number: 80 ``` ### ホストベースルーティングのユースケース このユースケースは、リクエストを指定されたホストに応じて異なるサービスにルーティングする方法を示しています。svc.naver.comホストに入るすべてのリクエストは naverサービスにルーティングされ、svc.cloud.comホストに入るすべてのリクエストは cloudサービスにルーティングされます。 ``` apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: host-ingress spec: ingressClassName: alb rules: - host: svc.naver.com http: paths: - path: /* pathType: Prefix backend: service: name: naver port: number: 80 - host: svc.cloud.com http: paths: - path: /* pathType: Prefix backend: service: name: cloud port: number: 80 ``` ### HTTPヘッダベースルーティングのユースケース このユースケースは、HTTPヘッダ値をベースにトラフィックをルーティングする方法を示しています。 **alb.ingress.kubernetes.io/conditions** アノテーションを使用して HTTPヘッダルールを定義します。以下の場合、「HeaderName」という HTTPヘッダに「HeaderValue1」または「HeaderValue2」値が含まれているリクエストのみ、NAVERサービスにルーティングされます。 ``` apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: condition-ingress annotations: alb.ingress.kubernetes.io/conditions.naver: > [{"field":"httpHeader","httpHeader":{"key": "HeaderName", "values":["HeaderValue1", "HeaderValue2"]}}] spec: ingressClassName: alb rules: - http: paths: - path: /* pathType: Prefix backend: service: name: naver port: number: 80 ``` ### Serviceの Port Name活用のユースケース Ingressルールでサービスのポート名(port.name)を使用してトラフィックルーティングルールを定義できます。このため、サービス定義時に port.nameを明示的に指定する必要があります。このユースケースでは、NAVERサービスのポートに http-webと名前を指定して Ingressルールで参照します。 ``` apiVersion: v1 kind: Service metadata: name: naver spec: ports: - name: http-web nodePort: 30080 port: 80 protocol: TCP targetPort: 80 selector: app: naver type: NodePort --- apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: portname-ingress spec: ingressClassName: alb rules: - http: paths: - path: /naver pathType: Prefix backend: service: name: naver port: name: http-web ``` ### HTTPを HTTPSにリダイレクトするユースケース このユースケースでは、ssl-redirectアノテーションを活用して HTTPに入るトラフィックを HTTPSにリダイレクトする方法を示しています。ユースケースを実行するには、以下の要素が必要です。 - ドメイン - Certificate Managerに登録された当該ドメインの証明書 HTTP(80)に入るトラフィックを HTTPS(443)にリダイレクトするには、下記のユースケースのように Ingressを作成します。 ``` apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80},{"HTTPS":443}]' alb.ingress.kubernetes.io/ssl-certificate-no: "1004" alb.ingress.kubernetes.io/ssl-redirect: "443" name: redirect-ingress spec: ingressClassName: alb defaultBackend: service: name: cloud port: number: 80 ``` - 以下は、上記の設定で80ポートを443ポートにリダイレクトするために2つのポートを登録する部分です。 ``` alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80},{"HTTPS":443}]' ``` - 以下は、上記の設定で HTTPSリスナーに登録する証明書番号を示す部分です。 ``` alb.ingress.kubernetes.io/ssl-certificate-no: "1004" ``` 参考 証明書番号は Resource Managerの nrnで確認できます。(例: nrn:PUB:CertificateManager::000:Certificate/External/${certificateNo}) - 以下は、上記の設定でリダイレクトするポートを登録する部分です。 ``` alb.ingress.kubernetes.io/ssl-redirect: "443" ``` ### マルチ証明書のユースケース ロードバランサに複数の証明書を登録できます。このユースケースでは、デフォルト(default)証明書と追加証明書を設定する方法を示しています。 ``` apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80},{"HTTPS":443}]' alb.ingress.kubernetes.io/ssl-certificate-no: "1234, 1004" alb.ingress.kubernetes.io/ssl-redirect: "443" name: multi-ssl-ingress spec: ingressClassName: alb rules: - http: paths: - path: /* pathType: Prefix backend: service: name: naver port: number: 80 ``` - 以下は、上記の設定で証明書を登録する部分です。最初の証明書がデフォルト証明書として追加され、残りの証明書は追加証明書として設定されます。 ``` alb.ingress.kubernetes.io/ssl-certificate-no: "1234, 1004" ``` ### actionによる重み付けベースルーティングのユースケース このユースケースでは、Ingressルールと一緒にアノテーションを使用して、特定のパスに対するトラフィックの処理方法を定義します。/navercloudのパスに対してアノテーションでトラフィックが naverと cloudサービスに分散されるように設定されます。 ``` apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: action-ingress annotations: alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}]' alb.ingress.kubernetes.io/description: 'alb ingress controller' alb.ingress.kubernetes.io/actions.navercloud: > {"type":"targetGroup","targetGroup":{"targetGroups":[{"serviceName":"naver","servicePort":80,"weight":50},{"serviceName":"cloud","servicePort":80,"weight":50}]}} spec: ingressClassName: alb defaultBackend: service: name: naver port: number: 80 rules: - http: paths: - path: /platform pathType: Prefix backend: service: name: platform port: number: 80 - path: /navercloud pathType: Exact backend: service: name: navercloud port: name: use-annotation ``` - 以下は、上記の設定でトラフィックを naverと cloudサービスに分散する部分です。 ``` alb.ingress.kubernetes.io/actions.navercloud: > {"type":"targetGroup","targetGroup":{"targetGroups":[{"serviceName":"naver","servicePort":80,"weight":50},{"serviceName":"cloud","servicePort":80,"weight":50}]}} ``` - アノテーションを適用するには、Ingress明細内で定義されたパスと actions.${actionName}の actionNameが一致する必要があります。 ### actionによる異なる名前空間に存在するサービス設定のユースケース このユースケースでは、Ingressルールと一緒にアノテーションを使用して、異なる名前空間にあるサービスを1つの Ingressで管理します。/navercloudパスでアクセスすると、navercloud名前空間に存在する naverサービスにルーティングされます。 ``` apiVersion: v1 kind: Service metadata: name: naver namespace: navercloud spec: type: NodePort selector: app: naver ports: - port: 80 targetPort: 80 --- apiVersion: apps/v1 kind: Deployment metadata: name: naver namespace: navercloud spec: replicas: 1 selector: matchLabels: app: naver template: metadata: labels: app: naver spec: containers: - name: naver image: nks.kr.ncr.ntruss.com/hello:plain-text ports: - containerPort: 80 --- apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: action-ingress annotations: alb.ingress.kubernetes.io/actions.navercloud: > {"type":"targetGroup","targetGroup":{"targetGroups":[{"serviceName":"navercloud/naver","servicePort":80,"weight":100}]}} spec: ingressClassName: alb defaultBackend: service: name: cloud port: number: 80 rules: - http: paths: - path: /navercloud pathType: Exact backend: service: name: navercloud port: name: use-annotation ``` - 上記の設定で他の名前空間に存在するサービスを定義する部分は、以下の通りです。action内のサービスは namespace/service形式で指定する必要があります。 ``` alb.ingress.kubernetes.io/actions.navercloud: > {"type":"targetGroup","targetGroup":{"targetGroups":[{"serviceName":"navercloud/naver","servicePort":80,"weight":100}]}} ``` - アノテーションを適用するには、Ingress明細内で定義されたパスと actions.${actionName}の actionNameが一致する必要があります。 - action内に記載されたサービスは NodePortタイプである必要があります。 ### conditionによる条件追加のユースケース このユースケースでは、Ingressルールと一緒にアノテーションを使用して、特定のパスに対する条件を追加する方法を定義します。明細内部に記載されたルールで、/naverのパスに対して naverサービスにルーティングし、アノテーションで条件を追加します。 ``` apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: condition-ingress annotations: alb.ingress.kubernetes.io/conditions.naver: > [{"field":"hostHeader","hostHeader":{"values":["svc.naver.com"]}},{"field":"pathPattern","pathPattern":{"values":["/cloud"]}}] spec: ingressClassName: alb rules: - http: paths: - path: /naver pathType: Prefix backend: service: name: naver port: number: 80 ``` - 以下は、上記の設定で svc.naver.comホストヘッダ条件と追加パスを適用する部分です。 ``` alb.ingress.kubernetes.io/conditions.naver: > [{"field":"hostHeader","hostHeader":{"values":["svc.naver.com"]}},{"field":"pathPattern","pathPattern":{"values":["/cloud"]}}] ``` - アノテーションを適用するには、Ingress明細内で定義されたパスと conditions.${conditionName}の conditionNameが一致する必要があります。 ### ターゲットグループ別ヘルスチェックパス設定のユースケース アノテーションの適用対象が Ingress、Serviceの場合、そのアノテーションは2つのリソースタイプで使用できます。同じアノテーションが Ingress、Serviceに存在する場合、Serviceに適用されたアノテーションが優先的に適用されます。 このユースケースでは、パス別に登録されたサービスのヘルスチェックをそれぞれ別々に設定します。各サービスの特定のヘルスチェック設定は、サービスのアノテーションで実装されます。 ``` # naver-service.yaml apiVersion: v1 kind: Service metadata: annotations: alb.ingress.kubernetes.io/healthcheck-path: /naver name: naver spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: app: naver type: NodePort --- # cloud-service.yaml apiVersion: v1 kind: Service metadata: annotations: alb.ingress.kubernetes.io/healthcheck-path: /cloud name: cloud spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: app: cloud type: NodePort --- # healthcheck-alb.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: healthcheck-alb annotations: kubernetes.io/ingress.class: alb alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}]' alb.ingress.kubernetes.io/healthcheck-path: "/" spec: defaultBackend: service: name: platform port: number: 80 rules: - http: paths: - path: /naver pathType: Prefix backend: service: name: naver port: number: 80 - path: /cloud pathType: Prefix backend: service: name: cloud port: number: 80 ``` - 以下は、上記の設定で /naverのパスにルーティングされるターゲットグループのヘルスチェック条件です。ターゲットグループごとに特定のヘルスチェック条件を適用したい場合、これらの設定は当該サービスのアノテーションを通じて定義する必要があります。 ``` alb.ingress.kubernetes.io/healthcheck-path: /naver ``` ### Sticky Session指定のユースケース ロードバランサの Sticky Sessionは、リスナーのルールで設定可能な Sticky Session機能とターゲットグループで設定可能な Sticky Session機能で提供されます。 このユースケースでは、作成されるすべてのターゲットグループの Sticky Sessionを設定し、actionで作成されたルールの Sticky Sessionを使用するように設定します。 参考 - NAVERクラウドプラットフォームの Application Load Balancerはターゲットグループにサーバを指定するため、Ncloud Kubernetes Serviceのサービスで Sticky Session機能が正常に動作しないことがあります。 - Sticky Session機能を活用するには、サービスの externalTrafficPolicyを Localに設定し、1つのノードに1つの Podのみをリリースする必要があります。 - この機能は今後改善される予定であり、なるべく運用アプリケーションのセッション管理機能を利用する必要があります。 ``` apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: sticky-ingress annotations: alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}]' alb.ingress.kubernetes.io/enable-sticky-session: 'true' alb.ingress.kubernetes.io/actions.targets: > {"type":"targetGroup","targetGroup":{"targetGroups":[{"serviceName":"naver","servicePort":80,"weight":50},{"serviceName":"cloud","servicePort":80,"weight":50}],"enableStickySession":true}} spec: ingressClassName: alb rules: - http: paths: - path: /navercloud pathType: Prefix backend: service: name: targets port: name: use-annotation - path: /platform pathType: Prefix backend: service: name: platform port: number: 80 ``` - 以下は、上記の設定でターゲットグループの Sticky Sessionを使用する部分です。 ``` alb.ingress.kubernetes.io/enable-sticky-session: 'true' ``` - 以下は、上記の設定で/navercloudのパスに入るリクエストに Sticky Sessionを使用する部分です。 ``` alb.ingress.kubernetes.io/actions.targets: > {"type":"targetGroup","targetGroup":{"targetGroups":[{"serviceName":"naver","servicePort":80,"weight":50},{"serviceName":"cloud","servicePort":80,"weight":50}],"enableStickySession":true}} ``` ### Access Control List設定のユースケース このユースケースは、Access Control List(ACL)機能を活用して指定された ACL IDを基に Ingressリソースへのアクセスを制御する方法を示しています。アノテーションを通じて80番ポートに ACL ID 123を適用しており、/aclパスに入るリクエストは naverサービスにルーディングされます。ACL設定を通じて許可された IPアドレスまたは CIDR範囲内でのリクエストのみ、当該パスにアクセスできるよう制御できます。 ``` apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: acl-ingress annotations: alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}]' alb.ingress.kubernetes.io/listener-acl-id.80: "123" spec: ingressClassName: alb rules: - http: paths: - path: /acl pathType: Prefix backend: service: name: naver port: number: 80 ```