Skip to content

Readiness check supports configuring minimum number of ready instances #1375

Closed

Description

@rugamaga

Feature Description

  • Allow specify a number of least necessary connected cloud-sql replica for unhealthy condition.

Alternatives Considered

  • Create new cloud-sql-proxy for each cloud-sql (read) replica and make special script for checking ready cloud-sql-proxies.
    • it need to up a lot of other cloud-sql-proxy instances.
    • it mess up readiness probe definitions.

Additional Context

  • If you are using multiple cloud-sql replicas, you can use query retry strategies in your application code.
      1. try to query for 1st instance in the (randomized) list.
      1. if it doesn't work, retry the query in 2nd instance in the list. (continue to last of the list)
      1. when correct response has come, you can use the values.
  • Such query strategy is making our application robust for downing some replicas. (it will avoid a read replica will be a single point of failure)
  • But, current cloud-sql-proxy's readiness check will be unhealthy if single node was down.
  • In Kubernetes, this behavior results the Pod's down if single cloud-sql replica has down the pod cannot handle all requests regardless our application can response it (by using another replica.)
    • This means, the retry strategy is not working with cloud-sql-proxy and a single read replica will be a single point of failure.
  • If there is this feature, we can use this for avoiding such system down.

Activity

  1. added
    type: feature request‘Nice-to-have’ improvement, new feature or different behavior or design.
    on Sep 5, 2022
  2. enocom commented on Sep 5, 2022

    @enocom
    Member

    Thanks for the feature request, @rugamaga. This is something we considered when writing the initial readiness check. So to briefly summarize, are you suggesting the Cloud SQL Proxy support a configurable readiness check? In other words, maybe we allow callers to specify how many instances can fail before the readiness check fails?

  3. rugamaga commented on Sep 5, 2022

    @rugamaga
    Author

    @enocom Yes. If you can specify how many instances can fail before the readiness check fails, it would be useful for making it robust.

  4. added
    priority: p1Important issue which blocks shipping the next release. Will be fixed prior to next release.
    on Sep 6, 2022
  5. enocom commented on Sep 6, 2022

    @enocom
    Member

    How about something like:

    —readiness-check-threshold=n

    where n is the number of instances which can fail before the check fails?

  6. rugamaga commented on Sep 6, 2022

    @rugamaga
    Author

    That's nice. but in this context, I think we want to check minimum alived instances.
    so better option is --min-ready-instances=n where n is ready instances. for example, when n = 2, cloud-sql-proxy will respond ready if over than two instances are alived.

  7. enocom commented on Sep 6, 2022

    @enocom
    Member

    OK, got it. I think that's a pretty simple fix. I'll pull this into my queue.

  8. added
    priority: p0Highest priority. Critical issue. P0 implies highest priority.
    and removed
    priority: p1Important issue which blocks shipping the next release. Will be fixed prior to next release.
    on Sep 7, 2022
  9. changed the title [-]Response ready when connected with over than specified number replica instances[/-] [+]Readiness check supports configuring number of ready instances[/+] on Oct 7, 2022
  10. changed the title [-]Readiness check supports configuring number of ready instances[/-] [+]Readiness check supports configuring minimum number of ready instances[/+] on Oct 7, 2022
  11. added 2 commits that reference this issue on Oct 19, 2022
    ad5c74e
    2bb8e19
  12. enocom commented on Oct 21, 2022

    @enocom
    Member

    I decided to add support for a min-ready query param instead of adding another CLI flag. See #1496 for details.

  13. added a commit that references this issue on Oct 26, 2022
    52ac3a3
  14. added a commit that references this issue on Nov 8, 2022
    73e2999
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

priority: p0Highest priority. Critical issue. P0 implies highest priority.type: feature request‘Nice-to-have’ improvement, new feature or different behavior or design.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions