Wait for network before starting up

[bmears-aaxis]

Question

We seem to be having an issue with the SQL proxy failing to initialize on the first try due to a timing issue with it and the istio sidecar deployed by ASM. Is there a way to delay the SQL proxy from trying to make a connection to cloud SQL so that the istio sidecar can establish itself?
Our backup plan is to disable the port for Istio egress for cloud SQL.

[enocom]

When you say failing to initialize, do you mean the initial call to collect instance metadata fails, or are you talking about the first connection attempt failing?

Assuming you're seeing the initial call to collect instance metadata failing, I don't see a great way to delay initialization. I can think of a few things to try though (in order of preference):

1. If you start the proxy with -fuse using a Unix socket (e.g., cloud_sql_proxy -fuse -dir /tmp/cloudsql), the proxy won't do any initial setup until an application attempts to connect to it.
2. You could try compiling a custom version of the proxy with a sleep just before this line: https://github.com/GoogleCloudPlatform/cloudsql-proxy/blob/22080999a649eb110513523b889ded2596313970/cmd/cloud_sql_proxy/cloud_sql_proxy.go#L526 Granted that's a hack, but if that works for you, we could discuss a feature to wait on some external event before proceeding with initialization.

[bmears-aaxis]

"When you say failing to initialize, do you mean the initial call to collect instance metadata fails, or are you talking about the first connection attempt failing?"
I'm not sure about the specific details. Whatever the initial egress call from the proxy container is is failing. At this point the container is toast and has to re-initialize.
We were considering #2 as another option, but would prefer not to have to manage our own container.
Let me try your other suggestion.
Thanks.

[bmears-aaxis]

Just a note, since these are both google authorized features, I assume this will come up again with other clients. Maybe a discussion with the ASM team to come up with a solid approach to handle this condition is in order?

[enocom]

Yes. In any case, I suspect there's a general need to sometimes delay the proxy at startup.

[bmears-aaxis]

Sounds good. Thanks again.

[bmears-aaxis]

Here's additional details:

*url.Error Get "http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/scopes": dial tcp 169.254.169.254:80: connect: connection refused | Get "http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/scopes": dial tcp 169.254.169.254:80: connect: connection refused

Trying to get SA details for the account used by the proxy. Obviously, adding a port override for istio on 80 would not be a good idea! :)

[enocom]

So just to clarify the issue, you're deploying the proxy as a sidecar along with an Istio sidecar. Before the Istio sidecar starts up, the proxy will fail to run because it can't send network calls. The proxy repeatedly crashes, the network comes up, and then the proxy comes up successfully. Is that what you're seeing?

[bmears-aaxis]

Exactly. We were able to get around the issue with IP filtering on the istio proxy, disabling the metadata service call and the subsequent call to the cloud SQL API.
The problem is the SQL API does not appear to have a static IP, so there is no way to provide istio with a filtering range.
Essentially, these 2 sidecars do not play well together.
I'm not sure if there is a way to check for a mesh proxy and ping it's readiness probe before starting any activity with the SQL proxy? It might make more sense than adding a delay.
BTW, I tried using the fuse flag to see if that would squash the initial SQL API call and it hosed the container. I couldn't even get to the logs to see what was going on.

[bmears-aaxis]

It's really mostly an annoyance cause the proxy recovers fairly quickly. You can see the restarts here.