[question] why is etcd needed when using a different storage

[raffaelespazzoli]

hello, I'm building an api-server with a similar approach to the non-etcd example.
When the api-serve rtarts it complains that it needs the --etcd-servers parameter.
After I set some value there, the process tarts and I can see that it tries to connect to etcd.
Why is this needed if I am not using etcd as the storage?

[yue9944882]

@raffaelespazzoli that's b/c the apiserver is mostly re-using the original kube-apiserver's code where non-etcd storage is not supported. usually as a workaround, we can set a dummy etcd address, what storage backend are you actually replacing etcd?

[raffaelespazzoli]

I'm building an api-proxy more than a proper api-server, so my api-server is proxying calls to hashicorp vault (which of course is, in turn, an api-server, just with different conventions/models). Here is my work in progress:
https://github.com/raffaelespazzoli/vault-apiserver

[yue9944882]

After I set some value there, the process tarts and I can see that it tries to connect to etcd.

@raffaelespazzoli mm how did observe the fact that ur apiserver is actually connecting the dummy etcd? is there any logging to share w/ us plz?

[yue9944882]

W0413 17:53:47.360445   20048 clientconn.go:1223] grpc: addrConn.createTransport failed to connect to {http://foo-bar:2379  <nil> 0 <nil>}. Err :connection error: desc = "transport: Error while dialing dial tcp: lookup foo-bar: no such host". Reconnecting...
W0413 17:53:53.367572   20048 clientconn.go:1223] grpc: addrConn.createTransport failed to connect to {http://foo-bar:2379  <nil> 0 <nil>}. Err :connection error: desc = "transport: Error while dialing dial tcp: lookup foo-bar: no such host". Reconnecting...
W0413 17:54:00.280357   20048 clientconn.go:1223] grpc: addrConn.createTransport failed to connect to {http://foo-bar:2379  <nil> 0 <nil>}. Err :connection error: desc = "transport: Error while dialing dial tcp: lookup foo-bar: no such host". Reconnecting...

by setting the etcd address to a constantly-failing address, i found a few WARN level log message from the local apiserver. they're baiscally negligible and doesnt influence the apiserver from working, see #587

[yue9944882]

$ curl -k https://127.0.0.1/healthz
[+]ping ok
[+]log ok
[-]etcd failed: reason withheld
[+]poststarthook/generic-apiserver-start-informers ok
[+]poststarthook/priority-and-fairness-config-consumer ok
[+]poststarthook/priority-and-fairness-filter ok
[+]poststarthook/start-sample-server-informers ok
healthz check failed

after digging a bit further, i found that the warning messages above is actually caused by the etcd health checker from the kube-apiserver which cannot be disabled as far as i can see. but the bright side is that it wont fail the apiserver from running..

[yue9944882]

i cut a new release of apiserver-runtime in which etcd dependency can be completely removed by having WithoutEtcd() in the builder flow. can you try?

[raffaelespazzoli]

It worked, thanks.