You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It should be able to do rolling updates without breaking and be self sufficient in (re)creating the csql container when the selector matches or it fails to be created
Actual Behavior
Fails to update and never recovers by itself
Steps to Reproduce the Problem
Create deployment with a needs-proxy: "1" label
Create AuthProxyWorkload manifest to match the kind: Deployment and selector.matchLabels."needs-proxy" = "1"
First kubectl apply usually works, updating deployments fail half of the time. This error precede this behavior and never recovers by itself, needing to delete the entire pod:
It then proceeds creating the actual Deployment container, but since it doesn't have the SQL proxy listening on localhost, the new created pod will be in an infinite crash loop since it requires the DB connection.
Specifications
Version: 1.5.1
Platform: GKE
Side note: it's very hard to read the logs from this operator on GCP, everything is being put on stderr with ERROR severity and the non-structured payloads is very confusing
The text was updated successfully, but these errors were encountered:
Can you try upgrading to Proxy Operator v1.6.1? This new version uses the new Kubernetes supported sidecar container for the proxy. Now, the proxy container is guaranteed to be available before Kubernetes starts the main application container.
Expected Behavior
It should be able to do rolling updates without breaking and be self sufficient in (re)creating the
csql
container when the selector matches or it fails to be createdActual Behavior
Fails to update and never recovers by itself
Steps to Reproduce the Problem
needs-proxy: "1"
labelAuthProxyWorkload
manifest to match thekind: Deployment
andselector.matchLabels."needs-proxy" = "1"
kubectl apply
usually works, updating deployments fail half of the time. This error precede this behavior and never recovers by itself, needing to delete the entire pod:It then proceeds creating the actual Deployment container, but since it doesn't have the SQL proxy listening on localhost, the new created pod will be in an infinite crash loop since it requires the DB connection.
Specifications
Side note: it's very hard to read the logs from this operator on GCP, everything is being put on
stderr
with ERROR severity and the non-structured payloads is very confusingThe text was updated successfully, but these errors were encountered: