|
| 1 | +--- |
| 2 | +template: main.html |
| 3 | +--- |
| 4 | + |
| 5 | +# Your first blue-green release |
| 6 | + |
| 7 | +This tutorial shows how Iter8 can be used to release a basic Kubernetes application using a blue-green rollout strategy. |
| 8 | +In a blue-green rollout, a percentage of requests are directed to a candidate version of the model. |
| 9 | +This percentage can be changed over time. |
| 10 | +The user declaratively describes the desired application state at any given moment. |
| 11 | +An Iter8 `release` chart assists users who describe the application state at any given moment. |
| 12 | +The chart provides the configuration needed for Iter8 to automatically deploy application versions and configure the routing to implement the blue-green rollout strategy. |
| 13 | + |
| 14 | + |
| 15 | + |
| 16 | +???+ warning "Before you begin" |
| 17 | + 1. Ensure that you have a Kubernetes cluster and the [`kubectl`](https://kubernetes.io/docs/reference/kubectl/) and [`helm`](https://helm.sh/) CLIs. You can create a local Kubernetes cluster using tools like [Kind](https://kind.sigs.k8s.io/) or [Minikube](https://minikube.sigs.k8s.io/docs/). |
| 18 | + 2. Install [Istio](https://istio.io). It suffices to install the [demo profile](https://istio.io/latest/docs/setup/getting-started/), for example by using: |
| 19 | + ```shell |
| 20 | + istioctl install --set profile=demo -y |
| 21 | + ``` |
| 22 | + |
| 23 | +## Install the Iter8 controller |
| 24 | + |
| 25 | +--8<-- "docs/getting-started/install.md" |
| 26 | + |
| 27 | +## Deploy initial version |
| 28 | + |
| 29 | +Deploy the initial version of the application using the Iter8 `release` chart by identifying the environment into which it should be deployed, a list of the versions to be deployed (only one here), and the rollout strategy to be used: |
| 30 | + |
| 31 | +```shell |
| 32 | +cat <<EOF | helm upgrade --install httpbin --repo https://iter8-tools.github.io/iter8 release --version 0.18 -f - |
| 33 | +environment: deployment-istio |
| 34 | +application: |
| 35 | + versions: |
| 36 | + - metadata: |
| 37 | + labels: |
| 38 | + app.kubernetes.io/version: v0 |
| 39 | + image: kennethreitz/httpbin |
| 40 | + strategy: blue-green |
| 41 | +EOF |
| 42 | +``` |
| 43 | + |
| 44 | +??? note "What happens?" |
| 45 | + Because `environment` is set to `deployment-istio`, a `Deployment` and a `Service` object are created. |
| 46 | + - The namespace `default` is inherited from the Helm release namespace since it is not specified in the version or in `application.metadata`. |
| 47 | + - The name `httpbin-0` is derived from the Helm release name since it is not specified in the version or in `application.metadata`. The name is derived by appending the index of the version in the list of versions; `-0` in this case. |
| 48 | + - Alternatively, a `deploymentSpecification` and/or a `serviceSpecification` could have been specified. |
| 49 | + |
| 50 | + To support routing, a `Service` (of type `ExternalName`) named `default/httpbin` pointing at the Istio gateway, `istio-ingressgateway.istio-system`, is deployed. The name is the Helm release name since it not specified in `application.metadata`. Further, an Iter8 [routemap](../user-guide/topics/routemap.md) is created. Finally, to support the blue-green rollout, a `ConfigMap` (`httpbin-0-weight-config`) is created to be used to manage the proportion of traffic sent to this version. |
| 51 | + |
| 52 | +Once the application components are ready, the Iter8 controller automatically configures the routing by creating an Istio `VirtualService`. It is configured to route all traffic to the only deployed version, `httpbin-0`. |
| 53 | + |
| 54 | +### Verify routing |
| 55 | + |
| 56 | +You can verify the routing configuration by inspecting the `VirtualService`: |
| 57 | + |
| 58 | +```shell |
| 59 | +kubectl get virtualservice httpbin -o yaml |
| 60 | +``` |
| 61 | + |
| 62 | +You can also send requests from a pod within the cluster: |
| 63 | + |
| 64 | +1. Create a `sleep` pod in the cluster from which requests can be made: |
| 65 | +```shell |
| 66 | +curl -s https://raw.githubusercontent.com/iter8-tools/docs/v0.17.3/samples/kserve-serving/sleep.sh | sh - |
| 67 | +``` |
| 68 | + |
| 69 | +2. Exec into the sleep pod: |
| 70 | +```shell |
| 71 | +kubectl exec --stdin --tty "$(kubectl get pod --sort-by={metadata.creationTimestamp} -l app=sleep -o jsonpath={.items..metadata.name} | rev | cut -d' ' -f 1 | rev)" -c sleep -- /bin/sh |
| 72 | +``` |
| 73 | + |
| 74 | +3. Send requests: |
| 75 | +```shell |
| 76 | +curl httpbin.default -s -D - | grep -e '^HTTP' -e app-version |
| 77 | +``` |
| 78 | + |
| 79 | +The output includes the success of the request (the HTTP return code) and the version of the application that responded (the `app-version` response header). For example: |
| 80 | + |
| 81 | +``` |
| 82 | +HTTP/1.1 200 OK |
| 83 | +app-version: httpbin-0 |
| 84 | +``` |
| 85 | + |
| 86 | +??? note "To send requests from outside the cluster" |
| 87 | + To configure the release for traffic from outside the cluster, a suitable Istio `Gateway` is required. For example, this [sample gateway](https://raw.githubusercontent.com/kalantar/docs/release/samples/iter8-sample-gateway.yaml). When using the Iter8 `release` chart, set the `gateway` field to the name of your `Gateway`. Finally, to send traffic: |
| 88 | + |
| 89 | + (a) In a separate terminal, port-forward the ingress gateway: |
| 90 | + ```shell |
| 91 | + kubectl -n istio-system port-forward svc/istio-ingressgateway 8080:80 |
| 92 | + ``` |
| 93 | + (b) Send requests using the `Host` header: |
| 94 | + ```shell |
| 95 | + curl -H 'Host: httpbin.default' localhost:8080 -s -D - | grep -e '^HTTP' -e app-version |
| 96 | + ``` |
| 97 | + |
| 98 | +## Deploy candidate |
| 99 | + |
| 100 | +A candidate can deployed by simply adding a second version to the list of versions comprising the application: |
| 101 | + |
| 102 | +```shell |
| 103 | +cat <<EOF | helm upgrade --install httpbin --repo https://iter8-tools.github.io/iter8 release --version 0.18 -f - |
| 104 | +environment: deployment-istio |
| 105 | +application: |
| 106 | + versions: |
| 107 | + - metadata: |
| 108 | + labels: |
| 109 | + app.kubernetes.io/version: v0 |
| 110 | + image: kennethreitz/httpbin |
| 111 | + - metadata: |
| 112 | + labels: |
| 113 | + app.kubernetes.io/version: v1 |
| 114 | + image: kennethreitz/httpbin |
| 115 | + strategy: blue-green |
| 116 | +EOF |
| 117 | +``` |
| 118 | + |
| 119 | +??? note "About the candidate version" |
| 120 | + In this tutorial, the candidate image is the same as the one for the primary version. In a real world example, it would be different. The version label (`app.kubernetes.io/version`) can be used to distinguish between versions. |
| 121 | + |
| 122 | +When the second version is deployed and ready, the Iter8 controller automatically reconfigures the routing; the `VirtualService` is updated to distribute traffic between versions based on the weights. |
| 123 | + |
| 124 | +### Verify routing |
| 125 | + |
| 126 | +You can verify the routing configuration by inspecting the `VirtualService` and/or by sending requests as described above. Requests will now be handled equally by both versions. |
| 127 | + |
| 128 | +## Modify weights (optional) |
| 129 | + |
| 130 | +To modify the request distribution between the versions, add a `weight` to each version. The weights are relative to each other. |
| 131 | + |
| 132 | +```shell |
| 133 | +cat <<EOF | helm upgrade --install httpbin --repo https://iter8-tools.github.io/iter8 release --version 0.18 -f - |
| 134 | +environment: deployment-istio |
| 135 | +application: |
| 136 | + versions: |
| 137 | + - metadata: |
| 138 | + labels: |
| 139 | + app.kubernetes.io/version: v0 |
| 140 | + image: kennethreitz/httpbin |
| 141 | + weight: 30 |
| 142 | + - metadata: |
| 143 | + labels: |
| 144 | + app.kubernetes.io/version: v1 |
| 145 | + image: kennethreitz/httpbin |
| 146 | + weight: 70 |
| 147 | + strategy: blue-green |
| 148 | +EOF |
| 149 | +``` |
| 150 | + |
| 151 | +Iter8 automatically reconfigures the routing to distribute traffic between the versions based on the new weights. |
| 152 | + |
| 153 | +### Verify routing |
| 154 | + |
| 155 | +You can verify the routing configuration by inspecting the `VirtualService` and/or by sending requests as described above. 70 percent of requests will now be handled by the candidate version; the remaining 30 percent by the primary version. |
| 156 | + |
| 157 | +## Promote candidate |
| 158 | + |
| 159 | +The candidate can be promoted by redefining the primary version and removing the candidate: |
| 160 | + |
| 161 | +```shell |
| 162 | +cat <<EOF | helm upgrade --install httpbin --repo https://iter8-tools.github.io/iter8 release --version 0.18 -f - |
| 163 | +environment: deployment-istio |
| 164 | +application: |
| 165 | + versions: |
| 166 | + - metadata: |
| 167 | + labels: |
| 168 | + app.kubernetes.io/version: v1 |
| 169 | + image: kennethreitz/httpbin |
| 170 | + strategy: blue-green |
| 171 | +EOF |
| 172 | +``` |
| 173 | +??? note "What is different?" |
| 174 | + The version label (`app.kubernetes.io/version`) of the primary version was updated. In a real world example, the image would also have been updated (with that from the candidate version). |
| 175 | + |
| 176 | +Once the (reconfigured) primary version ready, the Iter8 controller will automatically reconfigure the routing to send all requests to it. |
| 177 | + |
| 178 | +### Verify routing |
| 179 | + |
| 180 | +You can verify the routing configuration by inspecting the `VirtualService` and/or by sending requests as described above. They will all be handled by the primary version. |
| 181 | + |
| 182 | +## Cleanup |
| 183 | + |
| 184 | +Delete the application and its routing configuration: |
| 185 | + |
| 186 | +```shell |
| 187 | +helm delete httpbin |
| 188 | +``` |
| 189 | + |
| 190 | +Uninstall Iter8 controller: |
| 191 | + |
| 192 | +--8<-- "docs/getting-started/uninstall.md" |
0 commit comments