[bitnami/apisix] Standalone Mode Not Working

[james-mchugh]

Name and Version

bitnami/apisix:3.1.1

What architecture are you using?

amd64

What steps will reproduce the bug?

1. On K3S 1.27.6
2. Deploy the Helm Chart with the following values.yaml for standalone mode (from the README): (helm install bitnami/apisix --values values.yaml)
3. Observe init container errors:

$ kubectl describe pod apisix-data-plane-77d8db7f9d-68ffg
...
Error: secret "apisix-control-plane-api-token" not found
...

Are you using any custom parameters or values?

controlPlane:
  enabled: false
ingressController:
  enabled: false
etcd:
  enabled: false
dataPlane:
  extraConfig:
    deployment:
      role_data_plane:
        config_provider: yaml
  extraVolumes:
    - name: routes
      configMap:
        name: apisix-routes
  extraVolumeMounts:
    - name: routes
      mountPath: /opt/bitnami/apisix/conf/apisix.yaml
      subPath: apisix.yaml
extraDeploy:
  - apiVersion: v1
    kind: ConfigMap
    metadata:
      name: apisix-routes
    data:
      apisix.yaml: |-
        routes:
          -
            uri: /hello
            upstream:
                nodes:
                    "127.0.0.1:1980": 1
                type: roundrobin

What is the expected behavior?

Data plane pod runs as expected in standalone mode without init containers trying to mount secrets for disabled components.

What do you see instead?

Data plane pod fails with an error as it is trying to mount a secret for the control-plane that doesn't exist.

 Error: secret "apisix-control-plane-api-token" not found

Additional information

Looking at the _helpers.tpl file, it appears that the APISIX_ADMIN_API_TOKEN environment variable that mounts the control plane secret is always included in the apisix.prepareApisixInitContainer template without any conditional logic to remove it if the control-plane is disabled. This named template is always used when deploying the data plane Deployment, so even if the control-plane is disabled, it still adds the environment variable for the control-plane's secret.

[james-mchugh]

I made a few minor updates to get it to deploy in standalone mode. Namely, I added conditional logic to only include the APISIX_*_API_TOKEN env vars in the *InitContainer template functions if the control pane is enabled. Of course, this would break systems that are utilizing an external control plane, so it's probably not what you want. It got things going for us though.

After this was fixed, I hit an issue because the init container was still trying to handle etcd configurations, even though etcd was disabled. To handle this, I removed the etcd lines from dataPlane.defaultConfig in my custom values.yaml file. Helm templating could be used here to automatically remove it if etcd is disabled, but it looks like it's currently written to expect an external etcd in that situation.

Unless I'm missing something, it seems the current standalone instructions do not work, and I'm not sure when they last worked. By team has tried to use this chart a few times in the past to deploy Apisix in standalone mode, but we haven't ever been able to.

[rafariossaa]

Hi @james-mchugh ,
Thanks for your drill down in this issue.
Could you send a PR or share a branch with your changes ? We will be glad to review and merge it.

[james-mchugh]

Hi @james-mchugh , Thanks for your drill down in this issue. Could you send a PR or share a branch with your changes ? We will be glad to review and merge it.

Yep, I should be able to put in a PR for it later today or over the weekend. I don't think the fixes I currently have are exactly what we'll need, as they may impact other deployment modes, but they worked for my use case as I'm currently only concerned about standalone mode.

I'll try to clean it up my branch in hopes I can get it closer to a full solution and then put in a PR for it. I'll probably need feedback from you all during the review to get it finalized.

[james-mchugh]

PR is in! Looking forward to working with you all to get it merged!

[carrodher]

Thank you for opening this issue and submitting the associated Pull Request. Our team will review and provide feedback. Once the PR is merged, the issue will automatically close.

Your contribution is greatly appreciated!