環境ごとのプロキシの上限の強化

概要

新しい Apigee ハイブリッド組織は、環境ごとに 50 を超えるプロキシをデプロイできるようにプロビジョニングできます。この機能は Apigee X でも使用できます。

  • 組織ごとにデプロイできる API プロキシと共有フローの最大数は 6,000 です。
  • Apigee インスタンスあたりのプロキシ デプロイ ユニットの最大数は 6,000 です。
  • Apigee 組織あたりの API ベースパスの最大数は 3,000 です。

環境に 50 を超えるプロキシがデプロイされている場合、Apigee は環境を複数の個別のレプリカセットに自動的に分割します。各レプリカセットには、環境にデプロイされたプロキシのサブセットが含まれます。これらのレプリカ サブセットは、プロキシやその他の環境リソースのセットを読み込んで実行する方法において、単一の環境と同じ動作をします。これはユーザーにとって透過的であり、単一の環境と同様に環境を引き続き使用できます。

プロビジョニング

環境あたりのプロキシ数を増やして新しい組織をプロビジョニングするには:

  1. プロジェクト ID と組織名を Apigee 担当者に提供して、拡張プロキシの上限を設定します。
  2. Apigee ハイブリッドのインストール手順に沿って、ハイブリッド組織をプロビジョニングします。オーバーライド ファイルに enhanceProxyLimits トップレベル プロパティを追加します。
    enhanceProxyLimits: true
    

    環境グループごとに apigee-org チャートと apigee-virtualhost チャートを更新して、enhanceProxyLimits に変更を適用します。

  3. プロキシを作成してデプロイします。
  4. 拡張プロキシの上限が有効になっていることを確認します。
    1. Apigee Namespace の configmap の名前を取得します。
      kubectl get configmap -n APIGEE_NAMESPACE

      出力は次のようになります。

      NAME                                                             DATA   AGE
      ...
      apigee-synchronizer-hybr-example-env-dggroupconfi-bc7726a       3      12m
      ...
    2. 名前付き configmap を確認します。
      kubectl get configmap -n APIGEE_NAMESPACE CONFIGMAP_NAME -o yaml

      ここで、CONFIGMAP_NAME は前の手順の configmap の名前です。

      出力は次のようになります。

      kubectl get configmap -n apigee apigee-synchronizer-hybr-example-env-dggroupconfi-bc7726a -o yaml
      apiVersion: v1
      data:
      contract.revid: "2"
      contract.uid: 4a792429-20fb-4b29-bed3-3f8ce7b3353e
      deploymentGroups: auto-2ecde5ae-04
      kind: ConfigMap
      metadata:
      creationTimestamp: "2024-05-15T20:04:26Z"
      labels:
          apigee.cloud.google.com/platform: apigee
      name: apigee-synchronizer-hybr-test-env-dggroupconfi-bc7726a
      namespace: apigee
      ownerReferences:
      - apiVersion: apigee.cloud.google.com/v1alpha2
          blockOwnerDeletion: true
          controller: true
          kind: ApigeeEnvironment
          name: hybrid-dev--test-env-4f37f70
          uid: 696e84ec-5c54-4858-a2e0-e36db5ff3506
      resourceVersion: "2520100"
      uid: b297bd33-300a-48cf-bf85-6c7cd0ff288f
      
  5. 部分文字列 auto を含むランタイム Pod が存在することを確認します。
    kubectl get pods -n APIGEE_NAMESPACE | grep auto

    出力は次のようになります。

    kubectl get pods -n apigee | grep auto
    apigee-runtime-hybr-test-env-auto-2ecde5a-bca5298-4gsrw   1/1     Running     0                98m

制限事項

Apigee では、新しく作成された組織でのみ、環境ごとのプロキシの上限が強化されています。既存の組織を拡張プロキシの上限を使用するように変換することは可能です。

高度なプロキシの上限を有効にせずに作成された組織のバックアップは、この機能を有効にして作成された組織に復元できません。

既知の問題

  • プロキシ チェーン:
    • mTLS を使用したプロキシ チェーンはサポートされていません。既知の問題 392135466 をご覧ください。
    • 複数の仮想ホストがある場合、ApigeeRoute 名が競合するため、Helm リリースの作成が失敗することがあります。回避策として、環境グループごとに apigee-virtualhost チャートをインストールまたはアップグレードするときに、各仮想ホストに対して次のコマンドを実行します。
      kubectl annotate ar apigee-ingressgateway-internal-chaining-PROJECT_ID_SUFFIX -n APIGEE_NAMESPACE meta.helm.sh/release-name=NEW_ENV_GROUP_NAME --overwrite
      kubectl annotate cert apigee-ingressgateway-internal-chaining-PROJECT_ID_SUFFIX -n APIGEE_NAMESPACE meta.helm.sh/release-name=NEW_ENV_GROUP_NAME --overwrite

      ここで

      • PROJECT_ID_SUFFIX は、Kubernetes 内のプロジェクトの内部チェーンに使用する一意のサフィックスです。この接尾辞は、次のコマンドで確認できます。
        kubectl get svc -n apigee -l app=apigee-ingressgateway | grep internal-chaining

        出力は次のようになります。

        kubectl get svc -n apigee -l app=apigee-ingressgateway | grep internal-chaining
        apigee-ingressgateway-internal-chaining-my-project--1234567    ClusterIP  34.118.226.140  <none>    15021/TCP,443/TCP    5d6h

        出力例の my-project--1234567PROJECT_ID_SUFFIX です。

      • APIGEE_NAMESPACE は Apigee Namespace です。
      • NEW_ENV_GROUP_NAME は、追加の環境グループの名前です。この値は、仮想ホストごとに更新します。

      既知の問題 384937220 をご覧ください。

トラブルシューティング

症状 解決策
デバッグ セッションにリクエストが表示されない。 承認フローを設定するの手順に沿って、Apigee ランタイム サービス アカウントの権限を確認します。