vichaos opened a new issue, #882:
URL: https://github.com/apache/apisix-helm-chart/issues/882

   # Helm Release Name Restriction in Standalone API-driven Mode Causes APISIX 
Gateway Readiness Probe Failures
   
   ## Description
   
   I have been following the installation instructions from the [official 
APISIX 
documentation](https://apisix.apache.org/docs/ingress-controller/install/#install-apisix-and-apisix-ingress-controller-standalone-api-driven-mode)
 for installing APISIX and APISIX Ingress Controller in Standalone API-driven 
mode.
   
   I discovered that when using this configuration, the Helm release name 
**must** be `apisix`. If I change the release name to anything else (e.g., 
`apisix-private`), the APISIX gateway fails on the readiness probe and never 
starts successfully.
   
   This limitation significantly impacts my use case where I need to deploy 
**two separate APISIX gateways** in the same namespace to serve public and 
private connections with different configurations.
   
   ## Steps to Reproduce
   
   ### Working Configuration (Release name: `apisix`)
   ```bash
   helm template apisix \
       --namespace ingress-apisix \
       --create-namespace \
       --set apisix.deployment.role=traditional \
       --set apisix.deployment.role_traditional.config_provider=yaml \
       --set etcd.enabled=false \
       --set ingress-controller.enabled=true \
       --set ingress-controller.config.provider.type=apisix-standalone \
       --set ingress-controller.config.kubernetes.ingressClass=apisix-private \
       --set ingress-controller.apisix.adminService.namespace=ingress-apisix \
       --set ingress-controller.gatewayProxy.createDefault=true \
       apisix/apisix
   ```
   
   ### Failing Configuration (Release name: `apisix-private`)
   ```bash
   helm template apisix-private \
       --namespace ingress-apisix \
       --create-namespace \
       --set apisix.deployment.role=traditional \
       --set apisix.deployment.role_traditional.config_provider=yaml \
       --set etcd.enabled=false \
       --set ingress-controller.enabled=true \
       --set ingress-controller.config.provider.type=apisix-standalone \
       --set ingress-controller.config.kubernetes.ingressClass=apisix-private \
       --set ingress-controller.apisix.adminService.namespace=ingress-apisix \
       --set ingress-controller.gatewayProxy.createDefault=true \
       apisix/apisix
   ```
   
   ## Expected Behavior
   
   The Helm chart should allow custom release names while maintaining proper 
functionality of the APISIX gateway in standalone API-driven mode.
   
   ## Actual Behavior
   
   - ✅ **Working**: Release name `apisix` - Gateway starts successfully and 
passes readiness probes
   - ❌ **Failing**: Release name `apisix-private` - Gateway fails readiness 
probes and never becomes ready
   
   ## Impact
   
   This restriction prevents deploying multiple APISIX instances in the same 
namespace, which is a common requirement for:
   - Separating public and private traffic
   - Multi-tenant environments
   - Blue-green deployments
   - Different security configurations
   
   ## Visual Evidence
   
   ![Comparison showing working vs failing 
configurations](https://github.com/user-attachments/assets/c5d0ba5e-e245-4ede-ba18-b7731f996e24)
   
   *Left panel: Working configuration with release name `apisix`*  
   *Right panel: Failing configuration with release name `apisix-private`*
   
   ## Environment
   
   - APISIX Helm Chart: [2.11.6]
   - Kubernetes: [v1.31.2]
   - Helm: [v3.18.2]
   
   ## Suggested Solution
   
   The Helm chart templates should be updated to properly handle custom release 
names in standalone API-driven mode, ensuring that all internal references and 
configurations are dynamically generated based on the actual release name 
rather than hardcoded to expect `apisix`.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to