mcpField
G
gke-networking-edge

gke-networking-edge

github.com/googlecloudplatformクラウド・DevOps16948 回インストール2 日前に更新
リポジトリ

gke-networking-edge について

gke-networking-edgeは、GKE上のアプリケーションをインターネットや内部ネットワークに公開するための設定手順を示すスキルです。Gateway API、Ingress、セキュリティ、証明書、ロードバランシング、Private Service Connectを扱います。

主な機能

  1. 01Gateway APIとHTTPRouteの設定
  2. 02GKE Ingressの構成
  3. 03Cloud Armorによるエンドポイント保護
  4. 04マネージドSSL証明書の設定
  5. 05コンテナネイティブの負荷分散
  6. 06PSCによるサービス公開

活用シーン

  1. 01GKEアプリケーションのインターネット公開
  2. 02WAFとDDoS対策による受信通信の保護
  3. 03SSL証明書の発行と更新
  4. 04他のVPCへの内部サービス提供

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/googlecloudplatform/gke-mcp --skill gke-networking-edge

インストール後、Claude Code で/gke-networking-edgeを入力して読み込まれたか確認します。

詳細

GKE ネットワーキングエッジスキル

このスキルでは、GKE 上で稼働するアプリケーションをインターネットまたは内部ネットワークに安全に公開するワークフローを提供します。

ワークフロー

1. Gateway API を構成する（推奨）

Gateway API は、Kubernetes でルーティングを管理する最新の方法です。

前提条件：クラスターで Gateway API が有効になっている必要があります（GKE 1.24 以降ではデフォルトで有効です）。

Gateway マニフェストの例：

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
  namespace: my-namespace
spec:
  gatewayClassName: gke-l7-global-external-managed # GKE managed external L7 load balancer
  listeners:
    - name: http
      protocol: HTTP
      port: 80

HTTPRoute マニフェストの例：

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-route
  namespace: my-namespace
spec:
  parentRefs:
    - name: my-gateway
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: my-service
          port: 80
2. 標準の GKE Ingress を構成する

よりシンプルなユースケースやレガシー環境では、標準の Ingress を使用します。

Ingress マニフェストの例：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  namespace: my-namespace
  annotations:
    kubernetes.io/ingress.class: "gce"
spec:
  rules:
    - http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-service
                port:
                  number: 80
3. Cloud Armor で保護する

Cloud Armor は WAF と DDoS 保護を提供します。

BackendConfig を介して Cloud Armor を有効にする：

  1. Cloud Armor でセキュリティポリシーを作成します（通常は gcloud または Terraform を使用します）。
  2. GKE の BackendConfig でそのポリシーを参照します。

BackendConfig の例：

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backend-config
  namespace: my-namespace
spec:
  securityPolicy:
    name: my-cloud-armor-policy
  1. アノテーションを使用して BackendConfig を Service に関連付けます。
4. Google 管理の SSL 証明書を構成する

SSL 証明書を自動的にプロビジョニングし、更新します。

ManagedCertificate の例（レガシー Ingress）：

apiVersion: networking.gke.io/v1
kind: ManagedCertificate
metadata:
  name: my-certificate
spec:
  domains:
    - example.com

Ingress のアノテーションで参照します：networking.gke.io/managed-certificates: my-certificate。

Gateway API を使用する方法： 証明書管理との統合には、gateway.networking.k8s.io API を使用します。

5. コンテナネイティブのロードバランシングを有効にする（推奨）

コンテナネイティブのロードバランシングでは、ロードバランサーがノードではなく Kubernetes Pod を直接ターゲットにできます。これにより、レイテンシーと負荷分散が改善されます。

前提条件：クラスターが VPC ネイティブである必要があります。

仕組み：

  • GKE Ingress と Gateway API では、Network Endpoint Group（NEG）を介してコンテナネイティブのロードバランシングがデフォルトで有効になります。
  • Service で有効になっていることを確認する、または明示的に有効にするには、cloud.google.com/neg アノテーションを使用します。

Service マニフェストの例：

apiVersion: v1
kind: Service
metadata:
  name: my-service
  annotations:
    cloud.google.com/neg: '{"ingress": true}' # Enabled for Ingress
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  selector:
    app: my-app
  type: ClusterIP
6. Private Service Connect（PSC）を構成する

Private Service Connect を使用すると、VPC ピアリングを使わずに、ある VPC 内のサービスを別の VPC の利用者に安全に公開できます。

手順：

  1. サービス用の内部ロードバランサーを作成します。
  2. ロードバランサーを参照する ServiceAttachment を作成します。

ServiceAttachment マニフェストの例：

apiVersion: networking.gke.io/v1
kind: ServiceAttachment
metadata:
  name: my-psc-attachment
  namespace: my-namespace
spec:
  connectionPreference: ACCEPT_AUTOMATIC
  natSubnets:
    - my-psc-nat-subnet # Subnet dedicated for PSC NAT
  targetService:
    name: my-service
    namespace: my-namespace

ServiceAttachment URI を利用者と共有し、利用者の VPC に PSC エンドポイントを作成してもらいます。

ベストプラクティス

  1. Gateway API を優先する：Ingress よりも柔軟性が高く、役割を分離できます。
  2. Cloud Armor を有効にする：パブリックに公開するエンドポイントは、必ず Cloud Armor で保護します。
  3. マネージド証明書を使用する：証明書の更新を手動で管理する必要がなくなります。
  4. コンテナネイティブのロードバランシングを使用する：レイテンシーを削減し、トラフィック分散を改善するため、HTTP(S) ロードバランシングには必ず NEG を使用します。

コメント

Markdown 対応