Questions about Migrating from Configuration API to Airbyte API in GKE Helm Deployment

[karolur]

Hi Airbyte team,

OSS user here, we have Airbyte deployed in GKE using Helm chart 0.248.5 and Airbyte version 0.63.4.

I recently discovered that we were using the configuration API through an exposed webapp service, but I'm in the process of switching to the Airbyte API. However, I’m encountering difficulties understanding the correct Kubernetes setup for this.

Here is a list of the pods I see in our deployment:

airbyte-chart1-airbyte-api-server-7547c7cdfb-xfzp4
airbyte-chart1-airbyte-bootloader
airbyte-chart1-connector-builder-server-864f77bf45-mp9vk
airbyte-chart1-cron-6dc54d8fb7-xqcz8
airbyte-chart1-pod-sweeper-578785d785-6n4n8
airbyte-chart1-server-86669ff556-hffq7
airbyte-chart1-temporal-6748c64449-bchcb
airbyte-chart1-webapp-7bfb4f9b45-ts5vz
airbyte-chart1-worker-c74fc85b5-6fv8k
airbyte-minio-0

The previous setup exposed the webapp pod service, and all API calls were made using the external IP and port of the webapp service. Example: http://ExternalIP:Port/api/v1/connections...

After reading the documentation about the standalone server deprecation (reference link), I believe I should be exposing the server service instead, meaning I would have to expose pod airbyte-chart1-server-86669ff556-hffq7 and re-route the API calls to that IP.

Could you help confirm whether I should be using the server service for API calls, or does it even matter if I continue using the webapp service?

Any help or suggestions would be greatly appreciated!

[szemek]

You can continue using webapp for API calls.

webapp is reverse proxy for server for all endpoints starting with /api/...
default.conf.template#L41-L49
default.conf.template#L1-L3

The only difference is extra public after api for endpoints
/api/public/v1/connections

ServerConstants.kt#L11-L31

[karolur]

Thank you very much!