AppScan 360° のアップグレード・パス Ingress to Gateway API

概要

従来の Kubernetes Ingress セットアップからゲートウェイ・ベースのモデル (Istio Gateway API など) への移行により、ルーティングの柔軟性が向上し、マルチクラスター/マルチプロトコル・トラフィックのネイティブ・サポートが提供され、サービス・メッシュ機能との優れた統合が実現します。

このドキュメントでは、クラスター・タイプ、ロード・バランサーの可用性、および運用要件に基づいて、推奨される移行戦略の概要について説明します。

1.アップグレード戦略

アプローチ A: クリーン・アップグレード

  • シナリオ: ワークロードに入力が不要になった。

    プロセス: 1.既存の Ingress コントローラーを取り外します。

    2.ロード・バランサー (MetalLB または SLVLB) を使用して、デフォルト・ポート (80/443) にゲートウェイ・コントローラーを配置します。

    3.サービスが正しい外部 IP で構成されていることを検証します。

アプローチ B: 二次/共存アプローチ

  • シナリオ: 既存のワークロードは依然としてレガシー Ingress コントローラーに依存している。

  • プロセス:
    1. Ingress コントローラーを起動しておきます。
    2. 競合を回避するために、カスタム・ポートにゲートウェイ・コントローラーを配置します。
    3. 移行が検証されたら、最終的に Ingress を除去する計画を立てます。

2.配置シナリオ (共存アプローチ)

シナリオ 1: Ingress コントローラーを配置したゲートウェイ

  • コンテキスト: クラスターは現在、標準配置として Ingress コントローラを実行しています。

  • アプローチ: MetalLB を使用して外部 IP プールを提供するゲートウェイ・コントローラー (Istio Gateway API) を個別の配置として配置します。

  • 長所: 共存が可能。MetalLB を介してルーティングが簡素化されています。

  • 短所: 慎重なポート管理が必要です (80/443 の競合を回避)。

シナリオ 2: SLVLB (Klipper) を備えた K3s 上のゲートウェイ

  • コンテキスト: サービス・ロード・バランサー (Klipper) が有効な K3s 環境。

  • アプローチ: ゲートウェイ・コントローラーをインストールし、サービス・タイプを LoadBalancer に設定します。SLVLB はノード IP を自動的に割り当てます。

  • 長所: 最小限の構成。K3s 用にすぐに使用できます。

  • 短所: IP 割り当ては動的であり、ノード・ポートにファイアウォール・ルールが必要です。

3.カスタム・ポート構成 (共存モード)

既存の Ingress コントローラーがポート 80 および 443 を占有する場合、ASCP によって作成されたゲートウェイにはカスタム・リスナー・ポートを構成する必要があります。

次を使用して構成 singular-singular.clusterkit.yaml

ゲートウェイ・リスナーは、YAML 構成内のカスタム・ポートで定義できます。

次を使用して構成 singular-singular.clusterkit.properties

以下のプロパティーは、カスタム・リスナー・ポートを定義します。

  • CK_GATEWAY_TLS_PASSTHROUGH_LISTENER_PORT_NUMBER: お客様指定の K8s TLS パススルー・ポート。

    CK_GATEWAY_HTTPS_LISTENER_PORT_NUMBER: お客様指定の K8s HTTPS ポート。

    CK_GATEWAY_HTTP_LISTENER_PORT_NUMBER: お客様指定の K8s HTTP ポート。

注: 移行が完了し、レガシー Ingress が削除されたら、デフォルト・ポート (80/443) を使用するようにゲートウェイを再構成できます。

4.戦略の比較マトリックス

アプローチ クラスター・タイプ ロード・バランサー 長所 短所
K3s with SLVLB K3s SLVLB 最小構成、自動 IP 割り当て 動的IP、ノード・アクセスが必要
共存 任意 任意 中断がなく、段階的に移行 カスタム・ポートが必要
クリーン・アプローチ 任意 推奨 最も単純なアーキテクチャー、デフォルト・ポート Ingress の除去が必要
ゲートウェイ + MetalLB 任意 MetalLB 制御された IP 割り当て MetalLB のセットアップが必要

5.ゲートウェイ・プロパティーが必要

プロパティー・ファイルに以下の変数が設定されていることを確認します。

CK_GATEWAY_CLASS_NAME='<GATEWAY_CLASS_NAME>'
CK_GATEWAY_PRIVATE_HOST_DOMAIN='<AS360_DOMAIN>'
CK_GATEWAY_PRIVATE_HOST_SUBDOMAIN='<AS360_SUBDOMAIN>'

6.インストール手順 (Istio Gateway)

注: これらの手順は、Istio Gateway フレーバー専用に検証されています。

ステップ 1: Gateway API CRD をインストールする

ゲートウェイ・コントローラー実装をインストールする前に、CRD をインストールする必要があります。https://github.com/kubernetes-sigs/gateway-api/releases/tag/v1.4.0

GATEWAY_API_VERSION="v1.4.0"

kubectl apply -f 
https://github.com/kubernetes-sigs/gateway-api/releases/download/${G
ATEWAY_API_VERSION}/standard-install.yaml
kubectl apply -f 
https://github.com/kubernetes-sigs/gateway-api/releases/download/${G
ATEWAY_API_VERSION}/experimental-install.yaml
インストールの確認:

kubectl get crds | grep gateway.networking.k8s.io
ステップ 2: Istio Helm リポジトリーを追加する

helm repo add istio 
https://istio-release.storage.googleapis.com/charts || true
helm repo update
ステップ 3: Istio ベース (CRD) をインストールする

kubectl create namespace istio-system --dry-run=client -o yaml | 
kubectl apply -f -
helm install istio-base istio/base -n istio-system
インストールの確認:

helm status istio-base -n istio-system

ステップ 4: Istiod をインストールする (コントロール プレーン)

istiod-values.yaml という名前のファイルを作成します。

global:
 proxy:
   autoInject: disabled

resources:
 requests:
   cpu: 10m
   memory: 64Mi
 limits:
   cpu: 100m
   memory: 256Mi

autoscaleEnabled: false

env:
 PILOT_ENABLE_ALPHA_GATEWAY_API: "true"

telemetry:
 enabled: false
Helm を使用したインストール:


helm install istiod istio/istiod \
 -n istio-system \
 -f istiod-values.yaml
準備完了を待機:

kubectl rollout status deployment/istiod -n istio-system 
--timeout=120s
ステップ 5: 最終確認

# Check Istio pods
kubectl get pods -n istio-system

# Verify GatewayClass resource
kubectl get gatewayclass

インストールが成功すると、Istio GatewayClass が利用可能として表示されます。