Invert Traffic Split and EmojiVoto Creation

linkerd.io/content/2-edge/overview/_index.md

@@ -35,7 +35,7 @@ latency.
 
 In order to be as small, lightweight, and safe as possible, Linkerd's
 micro-proxies are written in [Rust](https://www.rust-lang.org/) and specialized
-for Linkerd. You can learn more about the these micro-proxies in our blog post,
+for Linkerd. You can learn more about these micro-proxies in our blog post,
 [Under the hood of Linkerd's state-of-the-art Rust proxy,
 Linkerd2-proxy](/2020/07/23/under-the-hood-of-linkerds-state-of-the-art-rust-proxy-linkerd2-proxy/),
 (If you want to know why Linkerd doesn't use Envoy, you can learn why in our blog

linkerd.io/content/2-edge/reference/proxy-configuration.md

@@ -52,7 +52,7 @@ instead of their original destination. This will inform Linkerd to override the
 endpoint selection of the ingress container and to perform its own endpoint
 selection, enabling features such as per-route metrics and traffic splitting.
 
-The proxy can be made to run in `ingress` mode by using the `linkerd.io/inject:
+The proxy can be configured to run in `ingress` mode by using the `linkerd.io/inject:
 ingress` annotation rather than the default `linkerd.io/inject: enabled`
 annotation. This can also be done with the `--ingress` flag in the `inject` CLI
 command:

linkerd.io/content/2-edge/tasks/automatic-failover.md

@@ -48,29 +48,14 @@ them in that cluster:
 > helm --kube-context=west install linkerd-failover -n linkerd-failover --create-namespace --devel linkerd-edge/linkerd-failover
 ```
 
-## Installing and Exporting Emojivoto
+## Create the emojivoto namespace
 
-We'll now install the Emojivoto example application into both clusters:
+First, we need to create the namespace where we will deploy our application
+and the `TrafficSplit` resource.
 
 ```bash
-> linkerd --context=west inject https://run.linkerd.io/emojivoto.yml | kubectl --context=west apply -f -
-> linkerd --context=east inject https://run.linkerd.io/emojivoto.yml | kubectl --context=east apply -f -
-```
-
-Next we'll "export" the `web-svc` in the east cluster by setting the
-`mirror.linkerd.io/exported=true` label. This will instruct the
-multicluster extension to create a mirror service called `web-svc-east` in the
-west cluster, making the east Emojivoto application available in the west
-cluster:
-
-```bash
-> kubectl --context=east -n emojivoto label svc/web-svc mirror.linkerd.io/exported=true
-> kubectl --context=west -n emojivoto get svc
-NAME          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
-emoji-svc     ClusterIP   10.96.41.137    <none>        8080/TCP,8801/TCP   13m
-voting-svc    ClusterIP   10.96.247.68    <none>        8080/TCP,8801/TCP   13m
-web-svc       ClusterIP   10.96.222.169   <none>        80/TCP              13m
-web-svc-east  ClusterIP   10.96.244.245   <none>        80/TCP              92s
+> kubectl --context=west create ns emojivoto
+> kubectl --context=east create ns emojivoto
 ```
 
 ## Creating the Failover TrafficSplit
@@ -106,6 +91,38 @@ This TrafficSplit indicates that the local (west) `web-svc` should be used as
 the primary, but traffic should be shifted to the remote (east) `web-svc-east`
 if the primary becomes unavailable.
 
+## Installing and Exporting Emojivoto
+
+We'll now install the Emojivoto example application into both clusters:
+
+```bash
+> linkerd --context=west inject https://run.linkerd.io/emojivoto.yml | kubectl --context=west apply -f -
+> linkerd --context=east inject https://run.linkerd.io/emojivoto.yml | kubectl --context=east apply -f -
+```
+
+Next we'll "export" the `web-svc` in the east cluster by setting the
+`mirror.linkerd.io/exported=true` label. This will instruct the
+multicluster extension to create a mirror service called `web-svc-east` in the
+west cluster, making the east Emojivoto application available in the west
+cluster:
+
+```bash
+> kubectl --context=east -n emojivoto label svc/web-svc mirror.linkerd.io/exported=true
+> kubectl --context=west -n emojivoto get svc
+NAME          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
+emoji-svc     ClusterIP   10.96.41.137    <none>        8080/TCP,8801/TCP   13m
+voting-svc    ClusterIP   10.96.247.68    <none>        8080/TCP,8801/TCP   13m
+web-svc       ClusterIP   10.96.222.169   <none>        80/TCP              13m
+web-svc-east  ClusterIP   10.96.244.245   <none>        80/TCP              92s
+```
+
+{{< warning >}}
+The order in which the Application and the ServiceProfile used by the TrafficSplit
+resource are created is important. If a ServiceProfile is created after the pod has
+already started, the workloads will need to be restarted. For more details on Service
+Profiles, check out the [Service Profiles documentation](../features/service-profiles.md).
+{{< /warning >}}
+
 ## Testing the Failover
 
 We can use the `linkerd viz stat` command to see that the `vote-bot` traffic

linkerd.io/content/2.10/reference/proxy-configuration.md

@@ -46,7 +46,7 @@ instead of their original destination. This will inform Linkerd to override the
 endpoint selection of the ingress container and to perform its own endpoint
 selection, enabling features such as per-route metrics and traffic splitting.
 
-The proxy can be made to run in `ingress` mode by used the `linkerd.io/inject:
+The proxy can be configured to run in `ingress` mode by used the `linkerd.io/inject:
 ingress` annotation rather than the default `linkerd.io/inject: enabled`
 annotation. This can also be done with the `--ingress` flag in the `inject` CLI
 command:

linkerd.io/content/2.11/reference/proxy-configuration.md

@@ -46,7 +46,7 @@ instead of their original destination. This will inform Linkerd to override the
 endpoint selection of the ingress container and to perform its own endpoint
 selection, enabling features such as per-route metrics and traffic splitting.
 
-The proxy can be made to run in `ingress` mode by used the `linkerd.io/inject:
+The proxy can be configured to run in `ingress` mode by used the `linkerd.io/inject:
 ingress` annotation rather than the default `linkerd.io/inject: enabled`
 annotation. This can also be done with the `--ingress` flag in the `inject` CLI
 command:

linkerd.io/content/2.11/tasks/automatic-failover.md

@@ -48,29 +48,14 @@ them in that cluster:
 > helm --kube-context=west install linkerd-failover -n linkerd-failover --create-namespace --devel linkerd-edge/linkerd-failover
 ```
 
-## Installing and Exporting Emojivoto
+## Create the emojivoto namespace
 
-We'll now install the Emojivoto example application into both clusters:
+First, we need to create the namespace where we will deploy our application
+and the `TrafficSplit` resource.
 
 ```bash
-> linkerd --context=west inject https://run.linkerd.io/emojivoto.yml | kubectl --context=west apply -f -
-> linkerd --context=east inject https://run.linkerd.io/emojivoto.yml | kubectl --context=east apply -f -
-```
-
-Next we'll "export" the `web-svc` in the east cluster by setting the
-`mirror.linkerd.io/exported=true` label. This will instruct the
-multicluster extension to create a mirror service called `web-svc-east` in the
-west cluster, making the east Emojivoto application available in the west
-cluster:
-
-```bash
-> kubectl --context=east -n emojivoto label svc/web-svc mirror.linkerd.io/exported=true
-> kubectl --context=west -n emojivoto get svc
-NAME          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
-emoji-svc     ClusterIP   10.96.41.137    <none>        8080/TCP,8801/TCP   13m
-voting-svc    ClusterIP   10.96.247.68    <none>        8080/TCP,8801/TCP   13m
-web-svc       ClusterIP   10.96.222.169   <none>        80/TCP              13m
-web-svc-east  ClusterIP   10.96.244.245   <none>        80/TCP              92s
+> kubectl --context=west create ns emojivoto
+> kubectl --context=east create ns emojivoto
 ```
 
 ## Creating the Failover TrafficSplit
@@ -82,7 +67,7 @@ TrafficSplit resource in the west cluster with the
 backend is the primary and all other backends will be treated as the fallbacks:
 
 ```bash
-> cat <<EOF | kubectl --context=west apply -f -
+kubectl --context=west apply -f - <<EOF
 apiVersion: split.smi-spec.io/v1alpha2
 kind: TrafficSplit
 metadata:
@@ -106,6 +91,38 @@ This TrafficSplit indicates that the local (west) `web-svc` should be used as
 the primary, but traffic should be shifted to the remote (east) `web-svc-east`
 if the primary becomes unavailable.
 
+## Installing and Exporting Emojivoto
+
+We'll now install the Emojivoto example application into both clusters:
+
+```bash
+> linkerd --context=west inject https://run.linkerd.io/emojivoto.yml | kubectl --context=west apply -f -
+> linkerd --context=east inject https://run.linkerd.io/emojivoto.yml | kubectl --context=east apply -f -
+```
+
+Next we'll "export" the `web-svc` in the east cluster by setting the
+`mirror.linkerd.io/exported=true` label. This will instruct the
+multicluster extension to create a mirror service called `web-svc-east` in the
+west cluster, making the east Emojivoto application available in the west
+cluster:
+
+```bash
+> kubectl --context=east -n emojivoto label svc/web-svc mirror.linkerd.io/exported=true
+> kubectl --context=west -n emojivoto get svc
+NAME          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
+emoji-svc     ClusterIP   10.96.41.137    <none>        8080/TCP,8801/TCP   13m
+voting-svc    ClusterIP   10.96.247.68    <none>        8080/TCP,8801/TCP   13m
+web-svc       ClusterIP   10.96.222.169   <none>        80/TCP              13m
+web-svc-east  ClusterIP   10.96.244.245   <none>        80/TCP              92s
+```
+
+{{< warning >}}
+The order in which the Application and the ServiceProfile used by the TrafficSplit
+resource are created is important. If a ServiceProfile is created after the pod has
+already started, the workloads will need to be restarted. For more details on Service
+Profiles, check out the [Service Profiles documentation](../features/service-profiles.md).
+{{< /warning >}}
+
 ## Testing the Failover
 
 We can use the `linkerd viz stat` command to see that the `vote-bot` traffic

linkerd.io/content/2.12/overview/_index.md

@@ -35,7 +35,7 @@ latency.
 
 In order to be as small, lightweight, and safe as possible, Linkerd's
 micro-proxies are written in [Rust](https://www.rust-lang.org/) and specialized
-for Linkerd. You can learn more about the these micro-proxies in our blog post,
+for Linkerd. You can learn more about these micro-proxies in our blog post,
 [Under the hood of Linkerd's state-of-the-art Rust proxy,
 Linkerd2-proxy](/2020/07/23/under-the-hood-of-linkerds-state-of-the-art-rust-proxy-linkerd2-proxy/),
 (If you want to know why Linkerd doesn't use Envoy, you can learn why in our blog

linkerd.io/content/2.12/reference/proxy-configuration.md

@@ -52,7 +52,7 @@ instead of their original destination. This will inform Linkerd to override the
 endpoint selection of the ingress container and to perform its own endpoint
 selection, enabling features such as per-route metrics and traffic splitting.
 
-The proxy can be made to run in `ingress` mode by using the `linkerd.io/inject:
+The proxy can be configured to run in `ingress` mode by using the `linkerd.io/inject:
 ingress` annotation rather than the default `linkerd.io/inject: enabled`
 annotation. This can also be done with the `--ingress` flag in the `inject` CLI
 command:

linkerd.io/content/2.12/tasks/automatic-failover.md

@@ -48,29 +48,14 @@ them in that cluster:
 > helm --kube-context=west install linkerd-failover -n linkerd-failover --create-namespace --devel linkerd-edge/linkerd-failover
 ```
 
-## Installing and Exporting Emojivoto
+## Create the emojivoto namespace
 
-We'll now install the Emojivoto example application into both clusters:
+First, we need to create the namespace where we will deploy our application
+and the `TrafficSplit` resource.
 
 ```bash
-> linkerd --context=west inject https://run.linkerd.io/emojivoto.yml | kubectl --context=west apply -f -
-> linkerd --context=east inject https://run.linkerd.io/emojivoto.yml | kubectl --context=east apply -f -
-```
-
-Next we'll "export" the `web-svc` in the east cluster by setting the
-`mirror.linkerd.io/exported=true` label. This will instruct the
-multicluster extension to create a mirror service called `web-svc-east` in the
-west cluster, making the east Emojivoto application available in the west
-cluster:
-
-```bash
-> kubectl --context=east -n emojivoto label svc/web-svc mirror.linkerd.io/exported=true
-> kubectl --context=west -n emojivoto get svc
-NAME          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
-emoji-svc     ClusterIP   10.96.41.137    <none>        8080/TCP,8801/TCP   13m
-voting-svc    ClusterIP   10.96.247.68    <none>        8080/TCP,8801/TCP   13m
-web-svc       ClusterIP   10.96.222.169   <none>        80/TCP              13m
-web-svc-east  ClusterIP   10.96.244.245   <none>        80/TCP              92s
+> kubectl --context=west create ns emojivoto
+> kubectl --context=east create ns emojivoto
 ```
 
 ## Creating the Failover TrafficSplit
@@ -106,6 +91,38 @@ This TrafficSplit indicates that the local (west) `web-svc` should be used as
 the primary, but traffic should be shifted to the remote (east) `web-svc-east`
 if the primary becomes unavailable.
 
+## Installing and Exporting Emojivoto
+
+We'll now install the Emojivoto example application into both clusters:
+
+```bash
+> linkerd --context=west inject https://run.linkerd.io/emojivoto.yml | kubectl --context=west apply -f -
+> linkerd --context=east inject https://run.linkerd.io/emojivoto.yml | kubectl --context=east apply -f -
+```
+
+Next we'll "export" the `web-svc` in the east cluster by setting the
+`mirror.linkerd.io/exported=true` label. This will instruct the
+multicluster extension to create a mirror service called `web-svc-east` in the
+west cluster, making the east Emojivoto application available in the west
+cluster:
+
+```bash
+> kubectl --context=east -n emojivoto label svc/web-svc mirror.linkerd.io/exported=true
+> kubectl --context=west -n emojivoto get svc
+NAME          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
+emoji-svc     ClusterIP   10.96.41.137    <none>        8080/TCP,8801/TCP   13m
+voting-svc    ClusterIP   10.96.247.68    <none>        8080/TCP,8801/TCP   13m
+web-svc       ClusterIP   10.96.222.169   <none>        80/TCP              13m
+web-svc-east  ClusterIP   10.96.244.245   <none>        80/TCP              92s
+```
+
+{{< warning >}}
+The order in which the Application and the ServiceProfile used by the TrafficSplit
+resource are created is important. If a ServiceProfile is created after the pod has
+already started, the workloads will need to be restarted. For more details on Service
+Profiles, check out the [Service Profiles documentation](../features/service-profiles.md).
+{{< /warning >}}
+
 ## Testing the Failover
 
 We can use the `linkerd viz stat` command to see that the `vote-bot` traffic

linkerd.io/content/2.13/overview/_index.md

@@ -35,7 +35,7 @@ latency.
 
 In order to be as small, lightweight, and safe as possible, Linkerd's
 micro-proxies are written in [Rust](https://www.rust-lang.org/) and specialized
-for Linkerd. You can learn more about the these micro-proxies in our blog post,
+for Linkerd. You can learn more about these micro-proxies in our blog post,
 [Under the hood of Linkerd's state-of-the-art Rust proxy,
 Linkerd2-proxy](/2020/07/23/under-the-hood-of-linkerds-state-of-the-art-rust-proxy-linkerd2-proxy/),
 (If you want to know why Linkerd doesn't use Envoy, you can learn why in our blog

linkerd.io/content/2.13/reference/proxy-configuration.md

@@ -52,7 +52,7 @@ instead of their original destination. This will inform Linkerd to override the
 endpoint selection of the ingress container and to perform its own endpoint
 selection, enabling features such as per-route metrics and traffic splitting.
 
-The proxy can be made to run in `ingress` mode by using the `linkerd.io/inject:
+The proxy can be configured to run in `ingress` mode by using the `linkerd.io/inject:
 ingress` annotation rather than the default `linkerd.io/inject: enabled`
 annotation. This can also be done with the `--ingress` flag in the `inject` CLI
 command:

linkerd.io/content/2.13/tasks/automatic-failover.md

@@ -48,29 +48,14 @@ them in that cluster:
 > helm --kube-context=west install linkerd-failover -n linkerd-failover --create-namespace --devel linkerd-edge/linkerd-failover
 ```
 
-## Installing and Exporting Emojivoto
+## Create the emojivoto namespace
 
-We'll now install the Emojivoto example application into both clusters:
+First, we need to create the namespace where we will deploy our application
+and the `TrafficSplit` resource.
 
 ```bash
-> linkerd --context=west inject https://run.linkerd.io/emojivoto.yml | kubectl --context=west apply -f -
-> linkerd --context=east inject https://run.linkerd.io/emojivoto.yml | kubectl --context=east apply -f -
-```
-
-Next we'll "export" the `web-svc` in the east cluster by setting the
-`mirror.linkerd.io/exported=true` label. This will instruct the
-multicluster extension to create a mirror service called `web-svc-east` in the
-west cluster, making the east Emojivoto application available in the west
-cluster:
-
-```bash
-> kubectl --context=east -n emojivoto label svc/web-svc mirror.linkerd.io/exported=true
-> kubectl --context=west -n emojivoto get svc
-NAME          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
-emoji-svc     ClusterIP   10.96.41.137    <none>        8080/TCP,8801/TCP   13m
-voting-svc    ClusterIP   10.96.247.68    <none>        8080/TCP,8801/TCP   13m
-web-svc       ClusterIP   10.96.222.169   <none>        80/TCP              13m
-web-svc-east  ClusterIP   10.96.244.245   <none>        80/TCP              92s
+> kubectl --context=west create ns emojivoto
+> kubectl --context=east create ns emojivoto
 ```
 
 ## Creating the Failover TrafficSplit
@@ -106,6 +91,38 @@ This TrafficSplit indicates that the local (west) `web-svc` should be used as
 the primary, but traffic should be shifted to the remote (east) `web-svc-east`
 if the primary becomes unavailable.
 
+## Installing and Exporting Emojivoto
+
+We'll now install the Emojivoto example application into both clusters:
+
+```bash
+> linkerd --context=west inject https://run.linkerd.io/emojivoto.yml | kubectl --context=west apply -f -
+> linkerd --context=east inject https://run.linkerd.io/emojivoto.yml | kubectl --context=east apply -f -
+```
+
+Next we'll "export" the `web-svc` in the east cluster by setting the
+`mirror.linkerd.io/exported=true` label. This will instruct the
+multicluster extension to create a mirror service called `web-svc-east` in the
+west cluster, making the east Emojivoto application available in the west
+cluster:
+
+```bash
+> kubectl --context=east -n emojivoto label svc/web-svc mirror.linkerd.io/exported=true
+> kubectl --context=west -n emojivoto get svc
+NAME          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
+emoji-svc     ClusterIP   10.96.41.137    <none>        8080/TCP,8801/TCP   13m
+voting-svc    ClusterIP   10.96.247.68    <none>        8080/TCP,8801/TCP   13m
+web-svc       ClusterIP   10.96.222.169   <none>        80/TCP              13m
+web-svc-east  ClusterIP   10.96.244.245   <none>        80/TCP              92s
+```
+
+{{< warning >}}
+The order in which the Application and the ServiceProfile used by the TrafficSplit
+resource are created is important. If a ServiceProfile is created after the pod has
+already started, the workloads will need to be restarted. For more details on Service
+Profiles, check out the [Service Profiles documentation](../features/service-profiles.md).
+{{< /warning >}}
+
 ## Testing the Failover
 
 We can use the `linkerd viz stat` command to see that the `vote-bot` traffic

linkerd.io/content/2.14/overview/_index.md

@@ -35,7 +35,7 @@ latency.
 
 In order to be as small, lightweight, and safe as possible, Linkerd's
 micro-proxies are written in [Rust](https://www.rust-lang.org/) and specialized
-for Linkerd. You can learn more about the these micro-proxies in our blog post,
+for Linkerd. You can learn more about these micro-proxies in our blog post,
 [Under the hood of Linkerd's state-of-the-art Rust proxy,
 Linkerd2-proxy](/2020/07/23/under-the-hood-of-linkerds-state-of-the-art-rust-proxy-linkerd2-proxy/),
 (If you want to know why Linkerd doesn't use Envoy, you can learn why in our blog

linkerd.io/content/2.14/reference/proxy-configuration.md

@@ -52,7 +52,7 @@ instead of their original destination. This will inform Linkerd to override the
 endpoint selection of the ingress container and to perform its own endpoint
 selection, enabling features such as per-route metrics and traffic splitting.
 
-The proxy can be made to run in `ingress` mode by using the `linkerd.io/inject:
+The proxy can be configured to run in `ingress` mode by using the `linkerd.io/inject:
 ingress` annotation rather than the default `linkerd.io/inject: enabled`
 annotation. This can also be done with the `--ingress` flag in the `inject` CLI
 command: