Right order for initContainers / integration with Istio.
Actual Behavior
Description:
During the upgrade of CloudSQL Operator to version 1.6.0, issues were encountered when deploying new instances of the
application. While the existing application instances continued functioning as expected, attempts to start new pods
failed due to critical container startup errors, which would be unacceptable in a production environment.
Details:
After upgrading to version 1.6.0 to utilize the minSigtermDelay parameter, the following problem was observed:
New instances of the application failed to initialize due to startup probe errors from the CloudSQL container:
Startup probe failed: Get "http://10.210.0.89:15020/app-health/csql-apps-apps/startupz": dial tcp 10.210.0.89:15020: connect: connection refused.
Existing pods already in operation continued to function correctly, with no observed disruptions in their database
interactions.
The issue seems tied to Istio sidecar injection. Specifically:
New pods attempted to start the istio-init container but failed before Istio was fully initialized.
The behavior differs from previous versions of the operator, which allowed greater compatibility in Istio-managed
environments.
Resolution Attempt:
Disabling Istio temporarily resolved the problem, allowing the CloudSQL container to start correctly in the new pods.
However, this is not an acceptable solution for production workloads where Istio is required.
Proposed Fix for CloudSQL Operator team:Reintroduce
user-configurable options for sidecar compatibility (e.g., sidecarType), as seen in earlier commits, to
prevent such failures in Istio environments and ensure robust behavior during deployment in production scenarios.
Steps to Reproduce the Problem
Install Istio (1.19.3)
Install Operator
Create a Deployment with CloudSQL annotation in namespace managed by Istio
Expected Behavior
Right order for initContainers / integration with Istio.
Actual Behavior
Description: During the upgrade of CloudSQL Operator to version 1.6.0, issues were encountered when deploying new instances of the application. While the existing application instances continued functioning as expected, attempts to start new pods failed due to critical container startup errors, which would be unacceptable in a production environment.
Details: After upgrading to version 1.6.0 to utilize the minSigtermDelay parameter, the following problem was observed:
Startup probe failed: Get "http://10.210.0.89:15020/app-health/csql-apps-apps/startupz": dial tcp 10.210.0.89:15020: connect: connection refused
.The issue seems tied to Istio sidecar injection. Specifically:
Resolution Attempt: Disabling Istio temporarily resolved the problem, allowing the CloudSQL container to start correctly in the new pods. However, this is not an acceptable solution for production workloads where Istio is required.
Proposed Fix for CloudSQL Operator team: Reintroduce user-configurable options for sidecar compatibility (e.g., sidecarType), as seen in earlier commits, to prevent such failures in Istio environments and ensure robust behavior during deployment in production scenarios.
Steps to Reproduce the Problem
Specifications