Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Add support for Istio multicluster setup. Fixes #1191. #1274

Merged
merged 7 commits into from
Jul 8, 2021
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Update docs for enabling Argo Rollouts in Istio multicluster setup
Signed-off-by: Shakti <shaktiprakash.das@salesforce.com>
shakti-das committed Jul 7, 2021
commit a76373d0684b0f0b39420c2f86f4330507965068
64 changes: 64 additions & 0 deletions docs/features/traffic-management/istio.md
Original file line number Diff line number Diff line change
@@ -246,6 +246,70 @@ During the lifecycle of a Rollout using Istio DestinationRule, Argo Rollouts wil
label of the canary and stable ReplicaSets


## Multicluster Setup
If you have [Istio multicluster setup](https://istio.io/latest/docs/setup/install/multicluster/)
where the primary Istio cluster is different than the cluster where the Argo Rollout controller
is running, then you need to do the following setup:

1. Create a `ServiceAccount` in the Istio primary cluster.
```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: argo-rollouts-istio-primary
namespace: <any-namespace-preferrably-config-namespace>
```
2. Create a `ClusterRole` that provides access to Rollout controller in the Istio primary cluster.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The default role in the manifest folder should be good

# virtualservice/destinationrule access needed for using the Istio provider
- apiGroups:
- networking.istio.io
resources:
- virtualservices
- destinationrules
verbs:
- watch
- get
- update
- patch
- list

Could you put a note there so that user doesn't need to create extra clusterrole.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. If Argo controller is also installed in the primary cluster (not mandatory), then we could just use the default argo-rollouts-clusterrole instead of creating another in the primary cluster. I will add a note to mention the same. Thanks.

```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: argo-rollouts-istio-primary
rules:
- apiGroups:
- networking.istio.io
resources:
- virtualservices
- destinationrules
verbs:
- get
- list
- watch
- update
- patch
```
3. Link the `ClusterRole` with the `ServiceAccount` in the Istio primary cluster.
```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: argo-rollouts-istio-primary
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: argo-rollouts-istio-primary
subjects:
- kind: ServiceAccount
name: argo-rollouts-istio-primary
namespace: <namespace-of-the-service-account>
```
4. Now, use the following command to generate a secret for Rollout controller to access the Istio primary cluster.
This secret will be applied to the cluster where Argo Rollout is running (i.e, Istio remote cluster),
but will be generated from the Istio primary cluster. This secret can be generated right after Step 1,
it only requires `ServiceAccount` to exist.
[Reference to the command](https://istio.io/latest/docs/reference/commands/istioctl/#istioctl-experimental-create-remote-secret).
```shell
istioctl x create-remote-secret --type remote --name <cluster-name> \
--namespace <namespace-of-the-service-account> \
--service-account <service-account-created-in-step1> \
--context="<ISTIO_PRIMARY_CLUSTER>" | \
kubectl apply -f - --context="<ARGO_ROLLOUT_CLUSTER/ISTIO_REMOTE_CLUSTER>"
```
5. Label the secret.
```shell
kubectl label secret <istio-remote-secret> istio.argoproj.io/primary-cluster="true" -n <namespace-of-the-secret>
```

## Comparison Between Approaches

There are some advantages and disadvantages of host-level traffic splitting vs. subset-level traffic