Enhanced proxy limits

Overview

New Apigee hybrid organizations can be provisioned with the ability to deploy more than 50 proxies per environment enabled. This feature is also available for Apigee X.

The maximum number of deployed API proxies and shared flows per organization is 6000.
The maximum number of proxy deployment units per Apigee instance is 6000.
The maximum number of API base paths per Apigee organization is 3000.

When more than 50 proxies are deployed in an environment, Apigee will automatically partition the environment into several distinct replica sets, each containing a subset of proxies deployed in the environment. These replica subsets are equivalent in behavior to a single environment in the way it loads and runs a set of proxies and other environment resources. This will be transparent to the user, and you can continue to use the environment as you would a single environment.

Provisioning

To provision a new org with the enhanced number of proxies per environment:

Provide your project ID and organization name to your Apigee representative to set up the enhanced proxy limit.
Follow the Apigee hybrid installation instructions to provision the hybrid org. In your overrides file, add the enhanceProxyLimits top-level property:
```
enhanceProxyLimits: true
```
Apply changes to enhanceProxyLimits by updating the apigee-org chart and the apigee-virtualhost chart for every environment group.

Alert: Do not change this value once set.
Create and deploy a proxy.

Verify that the enhanced proxy limits are enabled:

Get the name of the configmap for your Apigee namespace:

kubectl get configmap -n APIGEE_NAMESPACE

Your output should look similar to the following:

NAME                                                             DATA   AGE
...
apigee-synchronizer-hybr-example-env-dggroupconfi-bc7726a       3      12m
...

Check the named configmap:

kubectl get configmap -n APIGEE_NAMESPACE CONFIGMAP_NAME -o yaml

Where CONFIGMAP_NAME is the name of the configmap from the previous step.

Your output should look similar to the following:

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

Check for the existence of runtime pods containing the substring auto:

kubectl get pods -n APIGEE_NAMESPACE | grep auto

Your output should look similar to the following:

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

Limitations

Apigee offers enhanced proxy limits only on newly created orgs. Converting existing orgs to use enhanced proxy limits is supported.

Backups of an organization that was created without enhanced proxy limits enabled cannot be restored to an organization created with the feature enabled.

Known issues

Proxy chaining:
- Proxy chaining with mTLS is not supported. See known issue 392135466.
- When you have multiple virtual hosts, Helm release creation may fail due to conflicting ApigeeRoute names. The workaround is to run the following commands for every virtual host when installing or upgrading the apigee-virtualhost chart for each environment group:
```
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
```
  where:
  - PROJECT_ID_SUFFIX is a unique suffix for internal chaining for your project in Kubernetes. You can find this suffix with the following command:
```
kubectl get svc -n apigee -l app=apigee-ingressgateway | grep internal-chaining
```
    Your output will look something like:
```
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
```
    In the example output, my-project--1234567 is the PROJECT_ID_SUFFIX.
  - APIGEE_NAMESPACE is your Apigee namespace.
  - NEW_ENV_GROUP_NAME is the name the additional environment group. Update this value for each virtual host.
  See known issue 384937220.

Troubleshooting

Symptom	Resolution
Debug Session does not show requests.	Follow the steps in Set Authorization Flow to verify the permissions for the Apigee runtime service account.