{"id":19523886,"url":"https://github.com/eitansuez/istio-flagger","last_synced_at":"2026-02-27T11:14:29.237Z","repository":{"id":96637466,"uuid":"601818710","full_name":"eitansuez/istio-flagger","owner":"eitansuez","description":"Exploring and learning Flagger for streamlining canary deployments based on Istio","archived":false,"fork":false,"pushed_at":"2024-05-03T14:55:35.000Z","size":18,"stargazers_count":1,"open_issues_count":0,"forks_count":0,"subscribers_count":2,"default_branch":"master","last_synced_at":"2025-01-08T14:43:18.082Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/eitansuez.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2023-02-14T22:16:54.000Z","updated_at":"2024-10-04T21:22:21.000Z","dependencies_parsed_at":null,"dependency_job_id":"c94de8c2-3a05-41f9-8625-91eaf92cb4dd","html_url":"https://github.com/eitansuez/istio-flagger","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/eitansuez%2Fistio-flagger","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/eitansuez%2Fistio-flagger/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/eitansuez%2Fistio-flagger/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/eitansuez%2Fistio-flagger/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/eitansuez","download_url":"https://codeload.github.com/eitansuez/istio-flagger/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":240773517,"owners_count":19855220,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-11T00:45:05.320Z","updated_at":"2026-02-27T11:14:24.216Z","avatar_url":"https://github.com/eitansuez.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"2023.02.13\n\n# Streamlining canary deployments with [Flagger](https://flagger.app/) and Istio\n\n## Introduction\n\nFlagger is an open-source tool for progressive delivery.\n\nRead about Flagger at https://docs.flagger.app/.\n\nThis document helps you understand and learn Flagger by excercising it using Istio's [`bookinfo`](https://istio.io/latest/docs/examples/bookinfo/) sample application.\n\nWhat follows is the general recipe.\n\n## Prerequisites\n\n- A running Kubernetes cluster, with the ability to configure ingress\n\n## Install Istio\n\n```shell\nistioctl install\n```\n\nNote that the above will use the \"default\" profile.\n\n## Install Istio observability addons\n\nThe addons are located in the `samples/addons` folder of the Istio distribution, and include:\n\n- Prometheus\n- Grafana\n- Jaeger\n- Kiali\n\nFeel free to deploy only Prometheus and Grafana, or the entire set.\n\nAssuming your [Istio distribution](https://istio.io/latest/docs/setup/getting-started/#download) is located in the path denoted by the variable `$ISTIO_DISTRIBUTION`:\n\n```shell\nkubectl apply $ISTIO_DISTRIBUTION/samples/addons/prometheus.yaml\nkubectl apply $ISTIO_DISTRIBUTION/samples/addons/grafana.yaml\n```\n\netc..\n\n\u003e ### Question\n\u003e\n\u003e The Flagger documentation mentions their own Grafana dashboards to expose RED metrics.\n\u003e As far as I can tell this is not necessary.  Perhaps their instructions predate the introduction of Istio's observability dashboard samples.\n\n\n## Install Flagger\n\nSee https://docs.flagger.app/install/flagger-install-on-kubernetes\n\n```shell\nhelm repo add flagger https://flagger.app\nhelm repo update\n```\n\nApply the CRD:\n\n```shell\nkubectl apply -f https://raw.githubusercontent.com/fluxcd/flagger/main/artifacts/flagger/crd.yaml\n```\n\nInstall Flagger:\n\n```shell\nhelm upgrade -i flagger flagger/flagger \\\n  --namespace=istio-system \\\n  --set crd.create=false \\\n  --set meshProvider=istio \\\n  --set metricsServer=http://prometheus:9090\n```\n\n## Install the Flagger load tester\n\nIt's necessary to drive traffic to the application in order to generate the metrics necessary for Flagger to determine the state of the application during a progressive rollout.\n\nSee https://docs.flagger.app/usage/webhooks\n\n```shell\nkubectl create ns test\nkubectl label ns test istio-injection=enabled\nhelm upgrade -i flagger-loadtester flagger/loadtester \\\n  --namespace=test \\\n  --set cmd.timeout=1h \\\n  --set cmd.namespaceRegexp=''\n```\n\n## The scenario\n\nThe `bookinfo` demo application comes with three versions of the `reviews` service.\nThe idea is to deploy `bookinfo` with initial version 1, and to use Flagger to canary-upgrade `reviews` to subsequent versions.\n\n## How does it work?  A general outline\n\n- You define a \"canary\" Custom Resource (CR)\n- Flagger creates two clusterIP services: `reviews-canary` and `reviews-primary`, backed by two deployments: `reviews` and `reviews-primary`.\n- When the application is not being upgraded, the \"primary\" version receives all of the traffic.  The other workload is scaled to zero replicas.\n- During progressive delivery, we progressively promote the new version (`reviews`) to be `primary`.\n- Flagger watches for changes made to the `reviews` deployment.  When a change is made, it triggers a promotion.\n\n## Deploy `bookinfo`\n\nThe manifests for the initial deployment of the `bookinfo` application are in [`bookinfo.yaml`](bookinfo.yaml).\n\nThis manifest differs from the original version published on istio.io as follows:\n\n- The `reviews` Deployment is named `reviews`, not `reviews-v1` or `reviews-v2` etc..\n- The `version` label has been removed.\n- We do not initially deploy versions 2 and 3.  We will let Flagger do that.  The manifests for those deployments have been separated out to [`reviews-v2.yaml`](reviews-v2.yaml) and [`reviews-v3.yaml`](reviews-v3.yaml).  The only difference between these deployments and the original is the container image name they reference.\n\n\n1. Create the `bookinfo` namespace\n\n    ```shell\n    kubectl create ns bookinfo\n    ```\n\n1. Label it for sidecar injection:\n \n    ```shell\n    kubectl label ns bookinfo istio-injection=enabled\n    ```\n\n1. Deploy `bookinfo`:\n\n    ```shell\n    kubectl apply -f bookinfo.yaml -n bookinfo\n    ```\n\n1. Configure ingress for the `productpage` service:\n\n    ```shell\n    kubectl apply -f bookinfo-gateway.yaml -n bookinfo\n    ```\n\n## Draft a Canary custom resource\n\nSee [`reviews-canary.yaml`](reviews-canary.yaml).\n\nThis file configures the parameters that become a part of the canary deployment algorithm that Flagger performs.\n\n## Apply the Canary resource:\n\n```shell\nkubectl apply -f reviews-canary.yaml -n bookinfo\n```\n\nThe status of the resource will initially be \"Initializing\".  When flagger has finished initializing, the status will change to \"Initialized.\"\n\nDescribe the reviews canary:\n\n```shell\nkubectl -n bookinfo describe canary/reviews\n```\n\n- Note the events section at the end of the output.  After the canary status switches from \"Initializing\" to \"Initialized\", you should see an event stating \"Initialization done! reviews.bookinfo\".\n\nTwo new services `reviews-canary` and `reviews-primary` will have been created by Flagger:\n\n```shell\nkubectl get svc -n bookinfo\n```\n\n\u003e ### Question\n\u003e \n\u003e What does this message mean?:\n\u003e \n\u003e _reviews-primary.bookinfo not ready: waiting for rollout to finish: observed deployment generation less than desired generation_\n\nAlso note that the reviews deployment is set to 0 replicas and replaced with \"reviews-primary\".\nThat's because that deployment will become the canary version when changes are applied.\nSo it should not be receiving any traffic during stable (non-promotion) periods.\n\nAt this point, test that the `productpage` comes up and that it shows served reviews: \"reviews served by reviews-primary-...\".\n\n## Turn on Envoy sidecar console logging\n\nBefore we proceed, we need to ensure that we can see or detect when requests are made against the canary workload.\n\nWe deployed Istio with the default profile, which does not turn on console logging for Envoy sidecars (the demo profile does).\n\nThis can be done using with the [Telemetry](https://istio.io/latest/docs/tasks/observability/logs/access-log/#enable-envoys-access-logging) resource.\n\n1. Apply the [`telemetry.yaml`](telemetry.yaml) Telemetry resource:\n\n    ```shell\n    kubectl apply -f telemetry.yaml\n    ```\n\n1. Tail the sidecar logs:\n\n    ```shell\n    kubectl logs --follow -n bookinfo -l app=reviews -c istio-proxy\n    ```\n\nThe canary is configured to load-test the new version of the app using the Flagger loadtester.  You can see the requests come through by tailing those logs.\n\n## Trigger a canary upgrade\n\nDeploy an update to the `reviews` deployment:\n\n```shell\nkubectl apply -f reviews-v2.yaml -n bookinfo\n```\n\n## Observe the progress\n\nWatch the events section of the canary resource:\n\n```shell\nwatch \"kubectl describe canary -n bookinfo reviews | tail -20\"\n```\n\nYou should see the progression go from 20% of traffic siphoned to the canary, to 40%, then 60%, and ultimately the promotion of the canary to \"primary\".\n\nThe last events should state \"Routing all traffic to primary\" followed by \"Promotion completed\".\n\nThe `reviews-primary` pod id will change after promotion, since it represents a newer version.\n\nThe product page should now show ratings using black colored stars.\n\n## Repeat for `reviews-v3`\n\n```shell\nkubectl apply -f reviews-v3.yaml -n bookinfo\n```\n\nYou may see a warning-type event that states:\n\n\u003e _Halt advancement no values found for istio metric request-success-rate probably reviews.bookinfo is not receiving traffic: running query failed: no values found_\n\nI suspect what happens here is that there's a delay in getting the metrics needed to ascertain whether to proceed.  So the algorithm waits.  Once Flagger knows the new version of the app meets the specified metrics thresholds, we proceed (or rollback).\n\nUltimately, the promotion succeeds.\n\nEnd-to-end the process (as configured) takes 8-9 minutes.\n\n## Thoughts/Questions\n\n- Why do I need to remove the `version` label on the deployment?\n- The contract is the deployment, which feels odd.\n- The documentation doesn't clearly explain what the user's contract actually is.\n  I'd like to see an explanation of how Flagger expects the app to be initially deployed before control over the application is transferred over to Flagger.\n  \n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Feitansuez%2Fistio-flagger","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Feitansuez%2Fistio-flagger","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Feitansuez%2Fistio-flagger/lists"}