Deploying Workloads

A workspace member shares the cluster with other tenants and has a restricted ability to manage resources. This limited access to the cluster is provided via the workspace's ServiceAccount.

How to deploy a workload using GitOps

Clone the workspace repository and commit and push your deployment.

git add deployment.yaml

git commit --message "Adds deployment"

git push

The cluster will momentarily sync any changes to the repo, adding or removing resources as needed.

Make sure that the namespace of the deployment or any other resource in git repository is a namespace managed by this workspace.

Which namespaces does a Workspace manage?

These are set by the cluster admin and can be seen by getting the specific workspace object:

kubectl --kubeconfig foo-workspace-kubeconfig get workspace foo-workspace -n wkp-workspaces -oyaml

Accessing the workspace via kubectl

A cluster administrator can provide a kubeconfig file to manage the resources of a specific workspace. This file contains the credentials of the Workspace's ServiceAccount that can be used by kubectl.

kubectl --kubeconfig foo-workspace-kubeconfig get pods

The kubeconfig file sets the default namespace to the first namespace the Workspace manages. Other namespaces can be accessed by using the namespace flag: --namespace foo-namespace-2.

Notes

A current limitation of the Workspace Controller is its inability to apply an empty repository to a cluster. If you have deployments and other manifests commited to this repository, and then delete all of them so there are 0 manifests left, then the apply will fail and the resources will not be removed from the cluster. You can either:

1. Ask your admin to delete the workspace if you are done with it.
2. Add a dummy ConfigMap after deleting everything else so that you have at least 1 manifest to apply.