Connectivity Link を使用した Gateway ポリシーの設定およびデプロイ

手順

1. Gateway namespace が存在しない場合は、以下のように作成します。

   kubectl create ns ${gatewayNS}

2. Connectivity Link のインストール時に DNS プロバイダー認証情報のシークレットが作成されていない場合は、以下のように Gateway namespace にこのシークレットを作成します。

   kubectl -n ${gatewayNS} create secret generic aws-credentials \
     --type=kuadrant.io/aws \
     --from-literal=AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID \
     --from-literal=AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY

3. TLS 発行者を追加する前に、以下のように cert-manager namespace に認証情報シークレットを作成する必要もあります。

   kubectl -n cert-manager create secret generic aws-credentials \
     --type=kuadrant.io/aws \
     --from-literal=AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID \
     --from-literal=AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY

手順

1. 次のコマンドを入力して、TLS 発行者を定義します。この例では Let's Encrypt を使用しており、これをすべてのクラスターに適用する必要があります。

   kubectl apply -f - <<EOF
   apiVersion: cert-manager.io/v1
   kind: ClusterIssuer
   metadata:
     name: ${clusterIssuerName}
   spec:
     acme:
       email: ${EMAIL}
       privateKeySecretRef:
         name: le-secret
       server: https://acme-v02.api.letsencrypt.org/directory
       solvers:
         - dns01:
             route53:
               hostedZoneID: ${zid}
               region: ${AWS_REGION}
               accessKeyIDSecretRef:
                 key: AWS_ACCESS_KEY_ID
                 name: aws-credentials
               secretAccessKeySecretRef:
                 key: AWS_SECRET_ACCESS_KEY
                 name: aws-credentials
   EOF

2. ClusterIssuer の準備が完了するまで待ちます。

   kubectl wait clusterissuer/${clusterIssuerName} --for=condition=ready=true

手順

1. 以下のコマンドを入力してゲートウェイを作成します。

   kubectl apply -f - <<EOF
   apiVersion: gateway.networking.k8s.io/v1
   kind: Gateway
   metadata:
     name: ${gatewayName}
     namespace: ${gatewayNS}
     labels:
       kuadrant.io/gateway: "true"
   spec:
       gatewayClassName: istio
       listeners:
       - allowedRoutes:
           namespaces:
             from: Same
         hostname: "*.${rootDomain}"
         name: api
         port: 443
         protocol: HTTPS
         tls:
           certificateRefs:
           - group: ""
             kind: Secret
             name: api-${gatewayName}-tls
           mode: Terminate
   EOF

2. 次のとおり、ゲートウェイのステータスを確認します。

   kubectl get gateway ${gatewayName} -n ${gatewayNS} -o=jsonpath='{.status.conditions[?(@.type=="Accepted")].message}'
   kubectl get gateway ${gatewayName} -n ${gatewayNS} -o=jsonpath='{.status.conditions[?(@.type=="Programmed")].message}'

   ゲートウェイは受け入れられ、プログラムされるはずです。これは、ゲートウェイが有効で、外部アドレスが割り当てられたことを意味します。

3. ただし、以下に示すとおり HTTPS リスナーのステータスを確認すると、不正な TLS 設定が原因でプログラムされていない、またはトラフィックを受け入れる準備ができていないことがわかります。

   kubectl get gateway ${gatewayName} -n ${gatewayNS} -o=jsonpath='{.status.listeners[0].conditions[?(@.type=="Programmed")].message}'

   このような場合も、Connectivity Link は TLSPolicy を使用して有効な手段を提供できます。この点は、次のステップで説明しています。

手順

1. このゲートウェイを複数のクラスターに分散するには、クラスターごとにこのセットアッププロセスを繰り返します。

   デフォルトでは、これによりラウンドロビン DNS ストラテジーが実装され、複数のクラスターにトラフィックが均等に分散されます。現在の設定では、地理的位置に基づきクライアントにサービスを提供するように、ゲートウェイを簡単にセットアップできます。

2. このガイドでは複数のクラスターにゲートウェイインスタンスをデプロイしていると想定していますが、その場合の次のステップとして、認識可能なゲートウェイの地理的リージョンを使用して DNS コントローラーを更新します。

   たとえば、北アメリカにクラスターが 1 つあり、EU に別のクラスターがある場合は、適切なポリシーを設定することで、位置に基づきトラフィックをゲートウェイに誘導できます。その場合は、北アメリカのクラスターに対し、DNSPolicy を作成して loadBalancing:geo フィールドを US に設定します。

手順

1. アプリケーションの名前空間がまだ存在しない場合は、次のように作成します。

   kubectl create ns ${devNS}

2. デプロイされていない場合は、次のようにして、toystore アプリケーションを開発者名前空間にデプロイします。

   kubectl apply -f https://raw.githubusercontent.com/Kuadrant/Kuadrant-operator/main/examples/toystore/toystore.yaml -n ${devNS}

手順

1. 次のコマンドを入力して、Toystore アプリケーション API の HTTP ルートを定義します。

   kubectl apply -f - <<EOF
   apiVersion: gateway.networking.k8s.io/v1
   kind: HTTPRoute
   metadata:
     name: toystore
     labels:
       deployment: toystore
       service: toystore
   spec:
     parentRefs:
     - name: ${gatewayName}
       namespace: ${gatewayNS}
     hostnames:
     - "api.${rootDomain}"
     rules:
     - matches:
       - method: GET
         path:
           type: PathPrefix
           value: "/cars"
       - method: GET
         path:
           type: PathPrefix
           value: "/dolls"
       backendRefs:
       - name: toystore
         port: 80
     - matches:
       - path:
           type: PathPrefix
           value: "/admin"
       backendRefs:
       - name: toystore
         port: 80
   EOF

   この HTTPRoute が配置されると、デプロイしたサービスがゲートウェイによって公開されます。

2. 次のとおり、HTTPS 経由で API エンドポイントにアクセスできます。

   export INGRESS_HOST=$(kubectl get gtw ${gatewayName} -o jsonpath='{.status.addresses[0].value}' -n api-gateway)
   
   curl --resolve api.${rootDomain}:443:${INGRESS_HOST} "https://api.${rootDomain}/cars"

手順

1. 次のとおり、ユーザーである bob および alice の API キーを定義します。

   kubectl apply -f - <<EOF
   apiVersion: v1
   kind: Secret
   metadata:
     name: bob-key
     labels:
       authorino.kuadrant.io/managed-by: authorino
       app: toystore
     annotations:
       secret.kuadrant.io/user-id: bob
   stringData:
     api_key: IAMBOB
   type: Opaque
   ---
   apiVersion: v1
   kind: Secret
   metadata:
     name: alice-key
     labels:
       authorino.kuadrant.io/managed-by: authorino
       app: toystore
     annotations:
       secret.kuadrant.io/user-id: alice
   stringData:
     api_key: IAMALICE
   type: Opaque
   EOF

2. 次のとおり、AuthPolicy をオーバーライドして API キーの受け入れを開始します。

   kubectl apply -f - <<EOF
   apiVersion: kuadrant.io/v1
   kind: AuthPolicy
   metadata:
     name: toystore
   spec:
     targetRef:
       group: gateway.networking.k8s.io
       kind: HTTPRoute
       name: toystore
     rules:
       authentication:
         "api-key-users":
           apiKey:
             selector:
               matchLabels:
                 app: toystore
           credentials:
             authorizationHeader:
               prefix: APIKEY
       response:
         success:
           filters:
             "identity":
               json:
                 properties:
                   "userid":
                     selector: auth.identity.metadata.annotations.secret\.kuadrant\.io/user-id
   EOF

手順

1. 次のコマンドを実行して、特定ユーザーに流量制御を設定します。

   kubectl apply -f - <<EOF
   apiVersion: kuadrant.io/v1
   kind: RateLimitPolicy
   metadata:
     name: toystore
   spec:
     targetRef:
       group: gateway.networking.k8s.io
       kind: HTTPRoute
       name: toystore
     limits:
       "general-user":
         rates:
         - limit: 1
           duration: 3
           unit: second
         counters:
         - metadata.filter_metadata.envoy\.filters\.http\.ext_authz.identity.userid
         when:
         - selector: metadata.filter_metadata.envoy\.filters\.http\.ext_authz.identity.userid
           operator: neq
           value: bob
       "bob-limit":
         rates:
         - limit: 2
           duration: 3
           unit: second
         when:
         - selector: metadata.filter_metadata.envoy\.filters\.http\.ext_authz.identity.userid
           operator: eq
           value: bob
   EOF

   注記

   クラスターによっては、RateLimitPolicy が適用されるまでに数分間がかかる場合があります。

   別の例として、bob に対して、その他ユーザーの 2 倍のリクエスト数を付与できます。

2. 新しいセットアップをテストするには、次のとおり alice としてリクエストを送信します。

   while :; do curl --resolve api.${rootDomain}:443:${INGRESS_HOST} --write-out '%{http_code}\n' --silent --output /dev/null -H 'Authorization: APIKEY IAMALICE' "https://api.${rootDomain}/cars" | grep -E --color "\b(429)\b|$"; sleep 1; done

3. 次のとおり、bob としてリクエストを送信します。

   while :; do curl --resolve api.${rootDomain}:443:${INGRESS_HOST} --write-out '%{http_code}\n' --silent --output /dev/null -H 'Authorization: APIKEY IAMBOB' "https://api.${rootDomain}/cars" | grep -E --color "\b(429)\b|$"; sleep 1; done

   注記

   プラットフォームエンジニアのワークフローで説明されているとおり、DNS プロバイダーをセットアップして DNSPolicy を設定した場合は、--resolve api.${rootDomain}:443:${INGRESS_HOST} フラグを省略できます。たとえば alice の場合は、次のようになります。

   while :; do curl --write-out '%{http_code}\n' --silent --output /dev/null -H 'Authorization: APIKEY IAMALICE' "https://api.${rootDomain}/cars" | grep -E --color "\b(429)\b|$"; sleep 1; done

   注記

   複数のクラスターでこのガイドの手順を実行すると、HTTPRoute ホスト名の DNS レコードに複数の IP アドレスが含まれるようになります。これは、DNS プロバイダーが異なるレスポンスをルックアップに送信するため、リクエストがクラスターをまたいでラウンドロビンパターンで実行されることを意味します。