Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

add rollout support to weaver kube #32

Merged
merged 3 commits into from
Jul 24, 2023
Merged

add rollout support to weaver kube #32

merged 3 commits into from
Jul 24, 2023

Commits on Jul 24, 2023

  1. add rollout support to weaver kube 

    In the current implementation, with weaver kube you have to pause the
world when you want to rollout a new version of the app.

In this PR we enable rolling upgrades, a deployment strategy that is
supported by Kubernetes.

In the near future, we might want to provide integration with argo
rollouts (or something else) to enable blue/green and canary
deployments.

Main changes:
* for each component that exports a listener, we create a deployment
  with an unique name; this doesn't change across rollouts, so a rolling
  update will update the existing pods one by one
* one a pod is updated to the new version, whenever it gets a request,
  it will only talk with other services within the same version
* for each public listener, the name should be unique and not deployment
  specific
* also, for jaeger and prometheus, we want unique instances that persist
  across multiple versions (and captures the metrics/traces for all the
  deployer versins of an app)
* Prometheus used to scrape an address that was passed to the pods to
  export metrics on; this doesn't really work across versions; so we
  change the prometheus config to scrape all pods based on a label (the
  label is based on the app name, so it scrapes all pods across all
  versions of the app)

Drawbacks of this approach (things that might not work):
* what if a listener moves between components
* what if a listener is dropped

For now, in all our examples we have a simple listener exported by main.
So we can restrict to be only one listener exported by main, and this
might cover most of the scenarios. However, how to handle listeners
across versions is something to think about.
    @rgrandl
    rgrandl committed Jul 24, 2023
    Configuration menu
    Copy the full SHA
    2d0feeb View commit details
    Browse the repository at this point in the history

  2. Fixed comments.

    @rgrandl
    rgrandl committed Jul 24, 2023
    Configuration menu
    Copy the full SHA
    3003e28 View commit details
    Browse the repository at this point in the history

  3. Fixed last comments

    @rgrandl
    rgrandl committed Jul 24, 2023
    Configuration menu
    Copy the full SHA
    a92242f View commit details
    Browse the repository at this point in the history