https://linen.dev logo
Join Slack
Powered by
<@U04S8PLJWMT> my airbyte that is running on a gke...
# replication-ask-ai
s
@kapa.ai my airbyte that is running on a gke cluster, was giving me alerts today, one of the pods 
airbyte-temporal-7cdd9c7b6b-pm8nx -n airbyte
had multiple crashes
k
From the logs and issues in the knowledge sources, repeated crashes of the 
airbyte-temporal
pod on Kubernetes/GKE usually fall into a few categories: 1. Temporal cannot reach its database ◦ If you’re using an external Postgres (e.g., RDS, Neon), misconfiguration or latency between Temporal and the DB can cause timeouts and crash loops. [Airbyte Temporal EKS; Neon external DB] ◦ In one EKS case, simply moving the DB into the same region as the cluster resolved 
context deadline exceeded
errors and stabilized the Temporal pod. [Airbyte Temporal EKS] 2. Other Airbyte pods can’t connect to Temporal ◦ When Temporal is unhealthy or not listening correctly, you’ll see connection-refused errors in 
airbyte-server
and other pods, and the UI may return 502s. [K8s check connection issues; Temporal dual-stack issue] ◦ Example error pattern: 
Connection refused: airbyte-temporal-svc:7233
. [K8s check connection issues] 3. Cluster / networking specifics ◦ On some GKE setups (e.g., dual‑stack), Temporal may not bind correctly and other pods keep restarting while “waiting for namespace default to be initialized in temporal.” [Temporal dual-stack issue] Because your message only mentions that the Temporal pod crashed, but not the actual error logs, I can’t pinpoint the exact cause. The knowledge sources suggest these concrete next steps: 1. Check Temporal pod logs
Copy code
kubectl logs airbyte-temporal-7cdd9c7b6b-pm8nx -n airbyte --previous
Look for: ◦ 
context deadline exceeded
◦ 
connection refused
to Postgres or to 
airbyte-temporal-svc:7233
◦ any migration / schema / auth errors against Postgres. 2. Verify Temporal’s database connectivity ◦ If you use an external Postgres: ▪︎ Confirm host, port, DB name, user, password, and SSL options in your Helm values or manifests. [Neon external DB] ▪︎ Ensure the DB is in the same region / low‑latency network path as the GKE cluster if possible. [Airbyte Temporal EKS] ◦ From inside the Temporal pod, test connectivity to the DB (e.g., 
psql
if available). 3. Check other pods for Temporal‑related errors ◦ Inspect 
airbyte-server
, 
airbyte-worker
, and 
airbyte-cron
logs for errors mentioning 
airbyte-temporal-svc:7233
or “waiting for namespace default to be initialized in temporal.” [K8s check connection issues; Temporal dual-stack issue] 4. If using GKE with dual‑stack or custom networking ◦ Compare your setup with the dual‑stack issue where Temporal didn’t bind to the correct address and all dependent pods rolled. [Temporal dual-stack issue] If you can share (sanitized) logs from the crashing 
airbyte-temporal
pod and confirm whether you’re using the built‑in Postgres or an external DB, I can map your exact error to the closest known issue in these sources. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
s
@kapa.ai my log part 1
Copy code
2026-03-08 02:20:22,589 [main]	ERROR	i.a.a.c.a.AccessTokenInterceptor(intercept):120 - Failed to obtain or add access token
java.net.ConnectException: Failed to connect to airbyte-airbyte-server-svc.airbyte/34.118.226.166:8001
	at okhttp3.internal.connection.RealConnection.connectSocket(RealConnection.kt:297)
	at okhttp3.internal.connection.RealConnection.connect(RealConnection.kt:207)
	at okhttp3.internal.connection.ExchangeFinder.findConnection(ExchangeFinder.kt:226)
	at okhttp3.internal.connection.ExchangeFinder.findHealthyConnection(ExchangeFinder.kt:106)
	at okhttp3.internal.connection.ExchangeFinder.find(ExchangeFinder.kt:74)
	at okhttp3.internal.connection.RealCall.initExchange$okhttp(RealCall.kt:255)
	at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.kt:32)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
	at okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.kt:95)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
	at okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.kt:83)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
	at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.kt:76)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
	at okhttp3.internal.connection.RealCall.getResponseWithInterceptorChain$okhttp(RealCall.kt:201)
	at okhttp3.internal.connection.RealCall.execute(RealCall.kt:154)
	at io.airbyte.api.client.auth.AccessTokenInterceptor.fetchNewToken(AccessTokenInterceptor.kt:96)
	at io.airbyte.api.client.auth.AccessTokenInterceptor.getCachedToken(AccessTokenInterceptor.kt:70)
	at io.airbyte.api.client.auth.AccessTokenInterceptor.intercept(AccessTokenInterceptor.kt:116)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
	at io.airbyte.api.client.interceptor.ThrowOn5xxInterceptor.intercept(ThrowOn5xxInterceptor.kt:14)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
	at okhttp3.internal.connection.RealCall.getResponseWithInterceptorChain$okhttp(RealCall.kt:201)
	at okhttp3.internal.connection.RealCall.execute(RealCall.kt:154)
	at dev.failsafe.okhttp.FailsafeCall.lambda$execute$0(FailsafeCall.java:117)
	at dev.failsafe.Functions.lambda$get$0(Functions.java:46)
	at dev.failsafe.internal.RetryPolicyExecutor.lambda$apply$0(RetryPolicyExecutor.java:74)
	at dev.failsafe.SyncExecutionImpl.executeSync(SyncExecutionImpl.java:187)
	at dev.failsafe.CallImpl.execute(CallImpl.java:33)
	at dev.failsafe.okhttp.FailsafeCall.execute(FailsafeCall.java:121)
	at io.airbyte.api.client.generated.DataplaneApi.initializeDataplaneWithHttpInfo(DataplaneApi.kt:2253)
	at io.airbyte.api.client.generated.DataplaneApi.initializeDataplane(DataplaneApi.kt:369)
	at io.airbyte.api.client.generated.DataplaneApi.initializeDataplane$default(DataplaneApi.kt:366)
	at io.airbyte.workload.launcher.authn.DataplaneIdentityService.initialize(DataplaneIdentityService.kt:42)
	at io.airbyte.workload.launcher.StartupApplicationEventListener.onApplicationEvent(StartupApplicationEventListener.kt:34)
	at io.airbyte.workload.launcher.StartupApplicationEventListener.onApplicationEvent(StartupApplicationEventListener.kt:20)
	at io.micronaut.context.event.ApplicationEventPublisherFactory.notifyEventListeners(ApplicationEventPublisherFactory.java:266)
	at io.micronaut.context.event.ApplicationEventPublisherFactory$2.publishEvent(ApplicationEventPublisherFactory.java:226)
	at io.micronaut.http.server.netty.discovery.NettyServiceDiscovery.onStart(NettyServiceDiscovery.java:54)
	at io.micronaut.http.server.netty.discovery.$NettyServiceDiscovery$Definition$Exec.dispatch(Unknown Source)
	at io.micronaut.context.AbstractExecutableMethodsDefinition$DispatchedExecutableMethod.invoke(AbstractExecutableMethodsDefinition.java:456)
	at io.micronaut.context.DefaultBeanContext$BeanExecutionHandle.invoke(DefaultBeanContext.java:3987)
	at io.micronaut.aop.chain.AdapterIntroduction.intercept(AdapterIntroduction.java:91)
	at io.micronaut.aop.chain.MethodInterceptorChain.proceed(MethodInterceptorChain.java:143)
	at io.micronaut.http.server.netty.discovery.NettyServiceDiscovery$ApplicationEventListener$onStart1$Intercepted.onApplicationEvent(Unknown Source)
	at io.micronaut.context.event.ApplicationEventPublisherFactory.notifyEventListeners(ApplicationEventPublisherFactory.java:266)
	at io.micronaut.context.event.ApplicationEventPublisherFactory$2.publishEvent(ApplicationEventPublisherFactory.java:226)
	at io.micronaut.http.server.netty.NettyHttpServer.fireStartupEvents(NettyHttpServer.java:720)
	at io.micronaut.http.server.netty.NettyHttpServer.start(NettyHttpServer.java:330)
	at io.micronaut.http.server.netty.NettyHttpServer.start(NettyHttpServer.java:124)
	at io.micronaut.runtime.Micronaut.start(Micronaut.java:81)
	at io.airbyte.workload.launcher.ApplicationKt.main(Application.kt:10)
Caused by: java.net.ConnectException: Connection refused
	at java.base/sun.nio.ch.Net.pollConnect(Native Method)
	at java.base/sun.nio.ch.Net.pollConnectNow(Net.java:682)
	at java.base/sun.nio.ch.NioSocketImpl.timedFinishConnect(NioSocketImpl.java:542)
	at java.base/sun.nio.ch.NioSocketImpl.connect(NioSocketImpl.java:592)
	at java.base/java.net.SocksSocketImpl.connect(SocksSocketImpl.java:327)
	at java.base/java.net.Socket.connect(Socket.java:751)
	at okhttp3.internal.platform.Platform.connectSocket(Platform.kt:128)
	at okhttp3.internal.connection.RealConnection.connectSocket(RealConnection.kt:295)
	... 51 common frames omitted
k
The knowledge sources show a very similar error pattern: a component inside the cluster cannot reach 
airbyte-airbyte-server-svc:8001
and fails with 
java.net.ConnectException: Connection refused
. [Custom source API issue] In your log, the failing client is the workload launcher (
io.airbyte.workload.launcher
), trying to call the Airbyte Server via the internal service 
airbyte-airbyte-server-svc.airbyte:8001
to obtain an access token:
Copy code
Failed to connect to airbyte-airbyte-server-svc.airbyte/34.118.226.166:8001
Caused by: java.net.ConnectException: Connection refused
This indicates a server-side connectivity problem, not a Temporal problem directly: • The workload launcher is up and starting. • It cannot open a TCP connection to the Airbyte Server service IP/port. • As a result, initialization fails and the pod may crash/restart. From the knowledge sources, the closest guidance is: • When a component cannot connect to 
airbyte-airbyte-server-svc:8001
, it’s usually because the server pod is not running/ready or the service is misconfigured. [Custom source API issue] Given only this log, I can’t see the exact root cause of the crashes, but you can narrow it down with these checks: 1. Check Airbyte Server pod and service
Copy code
kubectl get pods -n airbyte -o wide | grep server
   kubectl get svc -n airbyte | grep airbyte-airbyte-server-svc
◦ Ensure the server pod is 
Running
and 
READY 1/1
. ◦ Confirm the service has a ClusterIP and port 
8001
. 2. Test connectivity from inside another pod For example, from the workload launcher or any other pod in the same namespace:
Copy code
kubectl exec -n airbyte -it <some-pod> -- sh
   # inside the pod:
   curl -v http://airbyte-airbyte-server-svc.airbyte:8001/health
◦ If this fails with 
Connection refused
, the server is not listening or not reachable. 3. Inspect Airbyte Server logs
Copy code
kubectl logs -n airbyte <airbyte-server-pod-name>
Look for startup failures (DB connection issues, config errors, etc.). Several issues in the knowledge sources show that when a core service (Temporal, Server) can’t start, other pods loop with connection errors. [K8s check connection issues; Temporal connection refused] 4. Confirm in-cluster DNS/service IP Your log shows 
34.118.226.166
, which looks like an external IP. The knowledge sources don’t explain this specific mapping, so I can’t say why that IP is used. Normally, 
airbyte-airbyte-server-svc.airbyte
should resolve to a ClusterIP. If it’s resolving to an external IP, there may be a custom Service/Ingress/DNS configuration causing misrouting, but the sources don’t provide details on that pattern. Because the knowledge sources don’t go deeper into this exact GKE/DNS situation, I can’t be more specific than: • The immediate failure is connection refused to the Airbyte Server service. • Focus on making 
airbyte-airbyte-server-svc:8001
healthy and reachable from inside the cluster; once that’s fixed, the workload launcher (and likely Temporal-related workflows) should stop crashing. [Custom source API issue] If you can share the 
kubectl get pods
/ 
kubectl get svc
output for the 
airbyte
namespace and the Airbyte Server logs, I can map them more precisely to the patterns in the knowledge sources. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
s
log part 2 @kapa.ai
Copy code
2026-03-08 02:20:22,592 [main]	ERROR	i.m.r.Micronaut(handleStartupException):362 - Error starting Micronaut server: Failed to initialize data-plane
java.lang.RuntimeException: Failed to initialize data-plane
	at io.airbyte.workload.launcher.authn.DataplaneIdentityService.initialize(DataplaneIdentityService.kt:58)
	at io.airbyte.workload.launcher.StartupApplicationEventListener.onApplicationEvent(StartupApplicationEventListener.kt:34)
	at io.airbyte.workload.launcher.StartupApplicationEventListener.onApplicationEvent(StartupApplicationEventListener.kt:20)
	at io.micronaut.context.event.ApplicationEventPublisherFactory.notifyEventListeners(ApplicationEventPublisherFactory.java:266)
	at io.micronaut.context.event.ApplicationEventPublisherFactory$2.publishEvent(ApplicationEventPublisherFactory.java:226)
	at io.micronaut.http.server.netty.discovery.NettyServiceDiscovery.onStart(NettyServiceDiscovery.java:54)
	at io.micronaut.http.server.netty.discovery.$NettyServiceDiscovery$Definition$Exec.dispatch(Unknown Source)
	at io.micronaut.context.AbstractExecutableMethodsDefinition$DispatchedExecutableMethod.invoke(AbstractExecutableMethodsDefinition.java:456)
	at io.micronaut.context.DefaultBeanContext$BeanExecutionHandle.invoke(DefaultBeanContext.java:3987)
	at io.micronaut.aop.chain.AdapterIntroduction.intercept(AdapterIntroduction.java:91)
	at io.micronaut.aop.chain.MethodInterceptorChain.proceed(MethodInterceptorChain.java:143)
	at io.micronaut.http.server.netty.discovery.NettyServiceDiscovery$ApplicationEventListener$onStart1$Intercepted.onApplicationEvent(Unknown Source)
	at io.micronaut.context.event.ApplicationEventPublisherFactory.notifyEventListeners(ApplicationEventPublisherFactory.java:266)
	at io.micronaut.context.event.ApplicationEventPublisherFactory$2.publishEvent(ApplicationEventPublisherFactory.java:226)
	at io.micronaut.http.server.netty.NettyHttpServer.fireStartupEvents(NettyHttpServer.java:720)
	at io.micronaut.http.server.netty.NettyHttpServer.start(NettyHttpServer.java:330)
	at io.micronaut.http.server.netty.NettyHttpServer.start(NettyHttpServer.java:124)
	at io.micronaut.runtime.Micronaut.start(Micronaut.java:81)
	at io.airbyte.workload.launcher.ApplicationKt.main(Application.kt:10)
Caused by: java.net.ConnectException: Failed to connect to airbyte-airbyte-server-svc.airbyte/34.118.226.166:8001
	at okhttp3.internal.connection.RealConnection.connectSocket(RealConnection.kt:297)
	at okhttp3.internal.connection.RealConnection.connect(RealConnection.kt:207)
	at okhttp3.internal.connection.ExchangeFinder.findConnection(ExchangeFinder.kt:226)
	at okhttp3.internal.connection.ExchangeFinder.findHealthyConnection(ExchangeFinder.kt:106)
	at okhttp3.internal.connection.ExchangeFinder.find(ExchangeFinder.kt:74)
	at okhttp3.internal.connection.RealCall.initExchange$okhttp(RealCall.kt:255)
	at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.kt:32)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
	at okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.kt:95)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
	at okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.kt:83)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
	at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.kt:76)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
	at io.airbyte.api.client.interceptor.AirbyteVersionInterceptor.intercept(AirbyteVersionInterceptor.kt:20)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
	at io.airbyte.api.client.interceptor.UserAgentInterceptor.intercept(UserAgentInterceptor.kt:25)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
	at io.airbyte.api.client.auth.AccessTokenInterceptor.intercept(AccessTokenInterceptor.kt:121)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
	at io.airbyte.api.client.interceptor.ThrowOn5xxInterceptor.intercept(ThrowOn5xxInterceptor.kt:14)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
	at okhttp3.internal.connection.RealCall.getResponseWithInterceptorChain$okhttp(RealCall.kt:201)
	at okhttp3.internal.connection.RealCall.execute(RealCall.kt:154)
	at dev.failsafe.okhttp.FailsafeCall.lambda$execute$0(FailsafeCall.java:117)
	at dev.failsafe.Functions.lambda$get$0(Functions.java:46)
	at dev.failsafe.internal.RetryPolicyExecutor.lambda$apply$0(RetryPolicyExecutor.java:74)
	at dev.failsafe.SyncExecutionImpl.executeSync(SyncExecutionImpl.java:187)
	at dev.failsafe.CallImpl.execute(CallImpl.java:33)
	at dev.failsafe.okhttp.FailsafeCall.execute(FailsafeCall.java:121)
	at io.airbyte.api.client.generated.DataplaneApi.initializeDataplaneWithHttpInfo(DataplaneApi.kt:2253)
	at io.airbyte.api.client.generated.DataplaneApi.initializeDataplane(DataplaneApi.kt:369)
	at io.airbyte.api.client.generated.DataplaneApi.initializeDataplane$default(DataplaneApi.kt:366)
	at io.airbyte.workload.launcher.authn.DataplaneIdentityService.initialize(DataplaneIdentityService.kt:42)
	... 18 common frames omitted
Caused by: java.net.ConnectException: Connection refused
	at java.base/sun.nio.ch.Net.pollConnect(Native Method)
	at java.base/sun.nio.ch.Net.pollConnectNow(Net.java:682)
	at java.base/sun.nio.ch.NioSocketImpl.timedFinishConnect(NioSocketImpl.java:542)
	at java.base/sun.nio.ch.NioSocketImpl.connect(NioSocketImpl.java:592)
	at java.base/java.net.SocksSocketImpl.connect(SocksSocketImpl.java:327)
	at java.base/java.net.Socket.connect(Socket.java:751)
	at okhttp3.internal.platform.Platform.connectSocket(Platform.kt:128)
	at okhttp3.internal.connection.RealConnection.connectSocket(RealConnection.kt:295)
	... 51 common frames omitted
k
Your logs match a known pattern in the knowledge sources: the workload launcher / data‑plane cannot initialize because it cannot reach the Airbyte Server service. Key lines:
Copy code
Error starting Micronaut server: Failed to initialize data-plane
Caused by: java.net.ConnectException: Failed to connect to airbyte-airbyte-server-svc.airbyte/34.118.226.166:8001
...
Caused by: java.net.ConnectException: Connection refused
This is the same failure mode reported in: • 
Failed to connect to airbyte-airbyte-server-svc/…:8001
from the workload launcher / client. [Multiple issues 2.0.0] • 
Failed to connect to airbyte-airbyte-server-svc/…:8001
when creating custom source definitions. [Custom source API] In those issues, the root problem is always that the Airbyte Server service is not reachable or not listening, so any component that needs to talk to it (workload launcher, connectors, etc.) fails and may crash‑loop. From the knowledge sources, the concrete checks / actions are: 1. Verify the Airbyte Server pod is healthy
Copy code
kubectl get pods -n airbyte | grep server
◦ It must be 
Running
and 
READY 1/1
. ◦ If it’s not, inspect its logs:
Copy code
kubectl logs -n airbyte <airbyte-server-pod-name>
In similar cases, server startup failures (DB, Temporal, config) caused all downstream “failed to connect to airbyte-airbyte-server-svc:8001” errors. [K8s check connection; Temporal conn refused] 2. Check the 
airbyte-airbyte-server-svc
Service
Copy code
kubectl get svc -n airbyte | grep airbyte-airbyte-server-svc
◦ It should be a ClusterIP service exposing port 
8001
. ◦ In the issues, the service name 
airbyte-airbyte-server-svc
is the expected internal endpoint for server access. [Custom source API; Multiple issues 2.0.0] 3. Test in‑cluster connectivity to the server From any other pod in the 
airbyte
namespace:
Copy code
kubectl exec -n airbyte -it <some-pod> -- sh
   # inside:
   curl -v http://airbyte-airbyte-server-svc.airbyte:8001/health
◦ If you get 
Connection refused
, that confirms the server is not listening or the service is misrouted. ◦ In the healthy case, 
/health
should return a small JSON and 200, as seen in other Kubernetes deployments. [K8s check connection] 4. Note on the IP 
34.118.226.166
 The knowledge sources don’t explain a case where 
airbyte-airbyte-server-svc.airbyte
resolves to an external IP like 
34.118.x.x
, so I can’t say why that’s happening in your GKE setup. Normally it should resolve to a ClusterIP. If it’s going out of the cluster, that would also cause connection issues, but this specific pattern is not documented in the sources. Given the available information, the actionable conclusion from the docs/issues is: • Your data‑plane / workload‑launcher crashes because it cannot reach the Airbyte Server at 
airbyte-airbyte-server-svc:8001
. • Fixing the Airbyte Server pod and its service (ensuring it is running, healthy, and reachable via the ClusterIP service) is the required first step; once that’s resolved, the “Failed to initialize data‑plane” error should stop. [Multiple issues 2.0.0; Custom source API] If you can share: • 
kubectl get pods -n airbyte
• 
kubectl get svc -n airbyte
• and the Airbyte Server pod logs I can align them more precisely with the patterns in those issues. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Your logs match a known pattern in the knowledge sources: the workload launcher / data‑plane component cannot reach the Airbyte Server service, so its Micronaut app fails to start with:
Copy code
Error starting Micronaut server: Failed to initialize data-plane
Caused by: java.net.ConnectException: Failed to connect to airbyte-airbyte-server-svc.airbyte/34.118.226.166:8001
...
Caused by: java.net.ConnectException: Connection refused
A very similar error appears when other components try to call 
airbyte-airbyte-server-svc:8001
and get 
Connection refused
/ 
Failed to connect
during startup. [Custom source API; Workload launcher/server svc] From the knowledge sources, this typically means: • The Airbyte Server pod is not running or not ready, or • The 
airbyte-airbyte-server-svc
service is misconfigured / not pointing to the right pods, so connections to port 8001 are refused. The “Failed to initialize data‑plane” is just a consequence: the workload launcher tries to call the Server’s 
DataplaneApi.initializeDataplane
endpoint to get an access token and fails, so the pod crashes. [Workload launcher/server svc] The sources do not explain why your service resolves to 
34.118.226.166
(which looks like an external IP), so I can’t say exactly what in your GKE networking causes that; I can only rely on the generic “connection refused to server svc” pattern. What to check (based on the patterns in the sources) 1. Is the Airbyte Server healthy?
Copy code
kubectl get pods -n airbyte | grep server
   kubectl logs -n airbyte <airbyte-server-pod-name>
◦ The server pod should be 
Running
and 
READY 1/1
. ◦ If it’s crashing, look for DB / Temporal / config errors; several issues show that when server can’t start, other pods (like workload launcher) fail with connection errors. [K8s check connection; Temporal connection refused] 2. Is the server service correct and reachable in‑cluster?
Copy code
kubectl get svc -n airbyte | grep airbyte-airbyte-server-svc
From another pod in the same namespace:
Copy code
kubectl exec -n airbyte -it <some-pod> -- sh
   # inside:
   curl -v http://airbyte-airbyte-server-svc.airbyte:8001/health
In the working setups in the forum, this 
/health
endpoint returns 
{"status":"UP"}
when the webapp checks connectivity. [Cannot reach server UI] 3. If the service resolves to an external IP The knowledge sources don’t cover this specific case, so I can’t give a documented fix. But given the pattern, the goal is: ◦ Ensure 
airbyte-airbyte-server-svc
is a ClusterIP service pointing at the server pods, and ◦ Ensure in‑cluster DNS resolves it to that ClusterIP, not to an external address. Once 
airbyte-airbyte-server-svc:8001
is healthy and reachable from inside the cluster, the “Failed to initialize data‑plane” error in the workload launcher / Temporal‑side components should stop, and the crashes should cease. [Custom source API; Workload launcher/server svc] If you can share (sanitized) 
kubectl get pods -n airbyte
and 
kubectl get svc -n airbyte
plus the Airbyte Server logs, I can map them more precisely to the documented issues. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Your log shows the workload launcher / data‑plane failing to start because it cannot reach the Airbyte Server service:
Copy code
Error starting Micronaut server: Failed to initialize data-plane
Caused by: java.net.ConnectException: Failed to connect to airbyte-airbyte-server-svc.airbyte/34.118.226.166:8001
Caused by: java.net.ConnectException: Connection refused
This is the same pattern reported when other components (like the workload launcher or connectors) try to call 
airbyte-airbyte-server-svc:8001
and get 
Connection refused
, which then surfaces as “Failed to initialize data‑plane.” [Multiple issues 2.0.0; Custom source API] From the knowledge sources, that almost always means: • The Airbyte Server pod is not running or not ready, or • The 
airbyte-airbyte-server-svc
Service is not correctly exposing the server pod on port 8001. The docs/issues don’t cover your specific IP (
34.118.226.166
) for that service name, so I can’t say why it resolves externally; I can only rely on the documented pattern that “connection refused to `airbyte-airbyte-server-svc:8001`” indicates a server/service problem. Based on those patterns, the next steps are: 1. Check the Airbyte Server pod
Copy code
kubectl get pods -n airbyte | grep server
   kubectl logs -n airbyte <airbyte-server-pod-name>
In similar cases, server startup failures (DB, Temporal, config) caused all downstream “failed to connect to airbyte-airbyte-server-svc:8001” errors. [K8s check connection issues; Temporal conn refused] 2. Check the 
airbyte-airbyte-server-svc
Service
Copy code
kubectl get svc -n airbyte | grep airbyte-airbyte-server-svc
It should be a ClusterIP service on port 8001 pointing at the server pods, as in the other Helm‑based deployments where components talk to 
airbyte-airbyte-server-svc:8001
. [Custom source API; Multiple issues 2.0.0] 3. Test in‑cluster connectivity From any pod in the 
airbyte
namespace:
Copy code
kubectl exec -n airbyte -it <some-pod> -- sh
   curl -v http://airbyte-airbyte-server-svc.airbyte:8001/health
In healthy setups, this returns a small JSON and 200; when it fails with 
Connection refused
, it confirms the server is not listening or the service is misrouted. [Kubernetes check connection; Cannot reach server UI] Once 
airbyte-airbyte-server-svc:8001
is healthy and reachable from inside the cluster, the workload launcher should be able to call 
DataplaneApi.initializeDataplane
successfully and the “Failed to initialize data‑plane” crashes should stop. [Multiple issues 2.0.0] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
s
@kapa.ai I am setting up airbyte connections via pulumi airbyte I am trying to set up a series of selected fields , what is the format I should follow for selected field
k
For Airbyte connections, the underlying API/TF schema for selected fields is: • At the stream level, 
selected_fields
is a set of objects. • Each object has a single attribute: 
field_path
, which is a list of strings representing the path to the field. [Streams selected_fields; Streams schema] So conceptually, for one stream:
Copy code
"selected_fields": [
  { "field_path": ["top_level_column"] },
  { "field_path": ["another_column"] }
]
Each 
field_path
is the JSON path (as a list) to the field you want to include. Only top‑level fields are supported for selection in Airbyte today. [Select fields] In Pulumi, you should mirror this structure: for each stream configuration, set 
selectedFields
(or equivalent) to an array/set of objects, each with 
fieldPath: ["field_name"]
. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
s
i tried 
fieldPath: ["field_name"]
. it is not working
2 Views
Open in Slack
PreviousNext
Powered by