Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
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.
- Loading branch information
