Skip to main content

Other Topics

Advanced Isolation​

Besides this basic workload isolation, you could also dive into more advanced isolation methods, such as isolating the workloads on separate nodes or through another container runtime. Using different nodes for your vCluster workloads can be accomplished through the --node-selector flag on vCluster syncer.

You should also be aware that pods created in the vCluster will set their tolerations, which will affect scheduling decisions. To prevent the pods from being scheduled to the undesirable nodes you can use the --node-selector flag or admission controller as mentioned above.

Workload & Network Isolation within the vCluster​

The above mentioned methods also work for isolating workloads inside the vCluster itself, as you can just deploy resource quotas, limit ranges, admission controllers and network policies in there. To allow network policies to function correctly, you'll need to enable this in vCluster itself though.

Secret based Service Account tokens​

By default vCluster will create Service Account Tokens for each pod and inject them as an annotation in the respective pods metadata. This can be a security risk in certain scenarios. To mitigate this there's a flag --service-account-token-secrets in vCluster which creates separate secrets for each pods Service Account Token and mounts it accordingly using projected volumes. This option is not enabled by default but can be enabled on demand. To enable this one can use the extraArgs options of the vCluster chart as follows

syncer:
  extraArgs:
    - --service-account-token-secrets=true