When operating a large multi-tenant Kubernetes cluster, tenants are usually isolated by Namespaces and Role Base Access Control (RBAC). This approach limits the permissions tenant have on the Namespace object they use to deploy their applications. Some tenants would like to set specific labels on their Namespace; however, they cannot edit it. As operators, we came up with the idea of creating a Custom Resource Definition (CRD), which will allow tenants to edit their Namespace's labels.
Please make sure you have a basic understanding of the following concepts before you continue to read.
This operator should be reasonably straightforward. It should sync between the NamespaceLabel CRD and the Namespace Labels. Various ways could achieve this functionality. Please go ahead and get creative. However, even a simple working solution is good.
An example of a NamespaceLabel CR:
apiVersion: dana.io.dana.io/v1alpha1
kind: NamespaceLabel
metadata:
name: namespacelabel-sample
namespace: default
spec:
labels:
label_1: a
label_2: b
label_3: c
- Can you create/update/delete labels?
- Can you deal with more than one NamespaceLabel object per Namespace? If not, solve it.
- Namespaces usually have labels for management, can you protect those labels?
- Tenant is not able to consume CRDs by default, what needs to be done to let tenant use the NamespaceLabel CRD?
- Code should be documented, tested (unit testing) and well-written.
This repo contains a go project you can fork it and use it as a template, also you will need:
- Kind for creating local cluster
- Go your operator should be written in Go
- Kubebuilder for creating the operator and crd template
- Operator-SDK for documentation about controllers and syntax
- Ginkgo for testing
- Use GitHub actions to protect the main branch and test every pull request automatically
- Implement e2e testing
- Use ECS for logging