mirror of
https://github.com/fluxcd/flagger.git
synced 2026-04-15 06:57:34 +00:00
Yusuke Kuoka
1ba595bc6f
Resolves #371 --- This adds the support for `corev1.Service` as the `targetRef.kind`, so that we can use Flagger just for canary analysis and traffic-shifting on existing and pre-created services. Flagger doesn't touch deployments and HPAs in this mode. This is useful for keeping your full-control on the resources backing the service to be canary-released, including pods(behind a ClusterIP service) and external services(behind an ExternalName service). Major use-case in my mind are: - Canary-release a K8s cluster. You create two clusters and a master cluster. In the master cluster, you create two `ExternalName` services pointing to (the hostname of the loadbalancer of the targeted app instance in) each cluster. Flagger runs on the master cluster and helps safely rolling-out a new K8s cluster by doing a canary release on the `ExternalName` service. - You want annotations and labels added to the service for integrating with things like external lbs(without extending Flagger to support customizing any aspect of the K8s service it manages **Design**: A canary release on a K8s service is almost the same as one on a K8s deployment. The only fundamental difference is that it operates only on a set of K8s services. For example, one may start by creating two Helm releases for `podinfo-blue` and `podinfo-green`, and a K8s service `podinfo`. The `podinfo` service should initially have the same `Spec` as that of `podinfo-blue`. On a new release, you update `podinfo-green`, then trigger Flagger by updating the K8s service `podinfo` so that it points to pods or `externalName` as declared in `podinfo-green`. Flagger does the rest. The end result is the traffic to `podinfo` is gradually and safely shifted from `podinfo-blue` to `podinfo-green`. **How it works**: Under the hood, Flagger maintains two K8s services, `podinfo-primary` and `podinfo-canary`. Compared to canaries on K8s deployments, it doesn't create the service named `podinfo`, as it is already provided by YOU. Once Flagger detects the change in the `podinfo` service, it updates the `podinfo-canary` service and the routes, then analyzes the canary. On successful analysis, it promotes the canary service to the `podinfo-primary` service. You expose the `podinfo` service via any L7 ingress solution or a service mesh so that the traffic is managed by Flagger for safe deployments. **Giving it a try**: To give it a try, create a `Canary` as usual, but its `targetRef` pointed to a K8s service: ``` apiVersion: flagger.app/v1alpha3 kind: Canary metadata: name: podinfo spec: provider: kubernetes targetRef: apiVersion: core/v1 kind: Service name: podinfo service: port: 9898 canaryAnalysis: # schedule interval (default 60s) interval: 10s # max number of failed checks before rollback threshold: 2 # number of checks to run before rollback iterations: 2 # Prometheus checks based on # http_request_duration_seconds histogram metrics: [] ``` Create a K8s service named `podinfo`, and update it. Now watch for the services `podinfo`, `podinfo-primary`, `podinfo-canary`. Flagger tracks `podinfo` service for changes. Upon any change, it reconciles `podinfo-primary` and `podinfo-canary` services. `podinfo-canary` always replicate the latest `podinfo`. In contract, `podinfo-primary` replicates the latest successful `podinfo-canary`. **Notes**: - For the canary cluster use-case, we would need to write a K8s operator to, e.g. for App Mesh, sync `ExternalName` services to AppMesh `VirtualNode`s. But that's another story!
Flagger end-to-end testing
The e2e testing infrastructure is powered by CircleCI and Kubernetes Kind.
CircleCI e2e Istio workflow
- install latest stable kubectl e2e-kind.sh
- install Kubernetes Kind e2e-kind.sh
- create local Kubernetes cluster with kind e2e-kind.sh
- install latest stable Helm CLI e2e-istio.sh
- deploy Tiller on the local cluster e2e-istio.sh
- install Istio CRDs with Helm e2e-istio.sh
- install Istio control plane and Prometheus with Helm e2e-istio.sh
- load Flagger image onto the local cluster e2e-istio.sh
- deploy Flagger in the istio-system namespace e2e-istio.sh
- create a test namespace with Istio injection enabled e2e-tests.sh
- deploy the load tester in the test namespace e2e-tests.sh
- deploy a demo workload (podinfo) in the test namespace e2e-tests.sh
- test the canary initialization e2e-tests.sh
- test the canary analysis and promotion using weighted traffic and the load testing webhook e2e-tests.sh
- test the A/B testing analysis and promotion using cookies filters and pre/post rollout webhooks e2e-tests.sh
CircleCI e2e Linkerd workflow
- install latest stable kubectl e2e-kind.sh
- install Kubernetes Kind e2e-kind.sh
- create local Kubernetes cluster with kind e2e-kind.sh
- install Linkerd e2e-linkerd.sh
- load Flagger image onto the local cluster e2e-linkerd.sh
- deploy Flagger in the linkerd namespace with Kustomize e2e-linkerd.sh
- create a test namespace with Linkerd injection enabled e2e-linkerd-tests.sh
- deploy the load tester in the test namespace e2e-linkerd-tests.sh
- deploy a demo workload (podinfo) in the test namespace e2e-linkerd-tests.sh
- test the canary initialization with port discovery enabled and service target port e2e-linkerd-tests.sh
- test the canary analysis and promotion using gPRC acceptance tests and HTTP load tests e2e-linkerd-tests.sh
- test the canary rollback on HTTP 500 errors e2e-linkerd-tests.sh
CircleCI e2e NGINX ingress workflow
- install latest stable kubectl e2e-kind.sh
- install Kubernetes Kind e2e-kind.sh
- create local Kubernetes cluster with kind e2e-kind.sh
- install latest stable Helm CLI e2e-nginx.sh
- deploy Tiller on the local cluster e2e-nginx.sh
- install NGINX ingress with Helm e2e-nginx.sh
- load Flagger image onto the local cluster e2e-nginx.sh
- install Flagger and Prometheus in the ingress-nginx namespace e2e-nginx.sh
- create a test namespace e2e-nginx-tests.sh
- deploy the load tester in the test namespace e2e-nginx-tests.sh
- deploy the demo workload (podinfo) and ingress in the test namespace e2e-nginx-tests.sh
- test the canary initialization e2e-nginx-tests.sh
- test the canary analysis and promotion using weighted traffic and the load testing webhook e2e-nginx-tests.sh
- test the A/B testing analysis and promotion using header filters and pre/post rollout webhooks e2e-nginx-tests.sh
- cleanup test environment e2e-nginx-cleanup.sh
- install NGINX Ingress and Flagger with custom ingress annotations prefix e2e-nginx-custom-annotations.sh
- repeat the canary and A/B testing workflow e2e-nginx-tests.sh