diff --git a/docs/.vuepress/configs/sidebar.ts b/docs/.vuepress/configs/sidebar.ts index f85dac18..ebc71291 100644 --- a/docs/.vuepress/configs/sidebar.ts +++ b/docs/.vuepress/configs/sidebar.ts @@ -274,6 +274,10 @@ export const sidebarEn: SidebarConfig = [ text: "Extending Manager ClusterRole", link: "/content/sre/tenant-operator/usecases/manager-clusterrole", }, + { + text: "Freeing up Unused Resources", + link: "/content/sre/tenant-operator/usecases/hibernation.md", + }, ], }, "/content/sre/tenant-operator/hibernation.md", diff --git a/docs/content/sre/tenant-operator/features.md b/docs/content/sre/tenant-operator/features.md index 121d342b..2a2f5fba 100644 --- a/docs/content/sre/tenant-operator/features.md +++ b/docs/content/sre/tenant-operator/features.md @@ -8,23 +8,23 @@ RBAC is one of the most complicated and error-prone parts of Kubernetes. With Te Tenant-Operator provides several ClusterRoles that are automatically bound to the Tenants Namespaces used for managing access to the Namespaces and the resources they contain. You can also modify the default roles or create new roles to have full control and customize access control for your users and teams. -Tenant-Operator also is able to leverage existing OpenShift groups or external groups synced from 3rd party identity management system for maintaining Tenant membership in your organizations current user management system. +Tenant-Operator is also able to leverage existing OpenShift groups or external groups synced from 3rd party identity management systems, for maintaining Tenant membership in your organization's current user management system. ## Self-Service With Tenant-Operator, you can empower your users to safely provision namespaces for themselves and their teams (typically mapped to SSO groups). Team-owned namespaces and the resources inside of them count towards the team's quotas rather than the user's individual limits and are automatically shared with all team members according to the access rules you configure in tenant-operator. -Also by leveraging Tenant-Operators templating mechanism, namespaces can be provisioned and automatically pre-populated with any kind of resource or multiple resources such as network policies, docker pull secrets or even Helm charts etc +Also by leveraging Tenant-Operator's templating mechanism, namespaces can be provisioned and automatically pre-populated with any kind of resource or multiple resources such as network policies, docker pull secrets or even Helm charts etc ## HashiCorp Vault Multitenancy Tenant-Operator is not only providing strong Multi Tenancy for the OpenShift internals but also extends the tenants permission model to HashiCorp Vault where it can create Vault paths and greatly ease the overhead of managing RBAC in Vault. -## ArgoCD Multitenancy +## ArgoCD Multitenancy Tenant-Operator is not only providing strong Multi Tenancy for the OpenShift internals but also extends the tenants permission model to ArgoCD were it can provision AppProjects and Allowed Repositories for your tenants greatly ease the overhead of managing RBAC in ArgoCD. -## Cost/Resource Optimization +## Cost/Resource Optimization Tenant-Operator provides a mechanism for defining Resource Quotas at the tenant scope, meaning all namespaces belonging to a particular tenant share the defined quota, which is why you are able to safely enable dev teams to self serve their namespaces whilst being confident that they can only use the resources allocated based on budget and business needs. @@ -44,7 +44,7 @@ Common use cases for namespace templates may be: - Adding development tooling to a namespace - Deploying pre-populated databases with test data - Equipping new namespaces with optional credentials such as image pull secrets - + ## Tenant level Hibernation Tenant-operator can downscale Deployments and StatefulSets in a tenant's Namespace according to a defined sleep schedule. The Deployments and StatefulSets are brought back to their required replicas according to the provided wake schedule. @@ -53,7 +53,7 @@ Tenant-operator can manage Mattermost to create Teams for tenant users. All tena ## Everything as Code/GitOps Ready -Tenant-Operator is designed and built to be 100% OpenShift native and to be configured and managed the same familiar way as native OpenShift resources so is perfect for modern shops that are dedicated to GitOps as it is fully configurable using Custom Resources +Tenant-Operator is designed and built to be 100% OpenShift-native and to be configured and managed the same familiar way as native OpenShift resources so is perfect for modern shops that are dedicated to GitOps as it is fully configurable using Custom Resources. ## Preventing Clusters Sprawl Share a single cluster with multiple teams, groups of users, or departments by saving operational and management efforts. diff --git a/docs/content/sre/tenant-operator/installation.md b/docs/content/sre/tenant-operator/installation.md index 513de924..2b52ebb4 100644 --- a/docs/content/sre/tenant-operator/installation.md +++ b/docs/content/sre/tenant-operator/installation.md @@ -98,7 +98,7 @@ You can uninstall Tenant-Operator by following these steps * Now the operator has been uninstalled. -* `Optional:` you can also manually remove tenant operators CRDs and it's resources from the cluster. +* `Optional:` you can also manually remove tenant operators CRDs and its resources from the cluster. ## Installing via Subscription @@ -203,7 +203,7 @@ subscription.operators.coreos.com "tenant-operator" deleted * Now the operator has been uninstalled. -* `Optional:` you can also manually remove tenant operators CRDs and it's resources from the cluster. +* `Optional:` you can also manually remove tenant operators CRDs and it's resources from the cluster. ## Installing via Helm diff --git a/docs/content/sre/tenant-operator/integration-config.md b/docs/content/sre/tenant-operator/integration-config.md index 78f2e6d6..93a3105f 100644 --- a/docs/content/sre/tenant-operator/integration-config.md +++ b/docs/content/sre/tenant-operator/integration-config.md @@ -156,11 +156,11 @@ users: ### Privileged Namespaces -`privilegedNamespaces:` Contains the list of `namespaces` ignored by the tenant-operator. The tenant-operator will not manage the `namespaces` in this list. Values in this list are regex patterns. For example, to ignore the `default` namespace, we can specify `^default$`; and to ignore all `namespaces` starting with the `openshift-` prefix, we can specify `^openshift-*`. +`privilegedNamespaces:` Contains the list of `namespaces` ignored by the tenant-operator. The tenant-operator will not manage the `namespaces` in this list. Values in this list are regex patterns. For example, to ignore the `default` namespace, we can specify `^default$`; and to ignore all `namespaces` starting with the `openshift-` prefix, we can specify `^openshift-*`. ### Privileged ServiceAccounts -`privilegedServiceAccounts:` Contains the list of `ServiceAccounts` ignored by the tenant-operator. The tenant-operator will not manage the `ServiceAccounts` in this list. Values in this list are regex patterns. For example, to ignore all `ServiceAccounts` starting with the `system:serviceaccount:openshift-` prefix, we can use `^system:serviceaccount:openshift-*`; and to ignore the `system:serviceaccount:builder` service account we can use `^system:serviceaccount:builder$.` +`privilegedServiceAccounts:` Contains the list of `ServiceAccounts` ignored by the tenant-operator. The tenant-operator will not manage the `ServiceAccounts` in this list. Values in this list are regex patterns. For example, to ignore all `ServiceAccounts` starting with the `system:serviceaccount:openshift-` prefix, we can use `^system:serviceaccount:openshift-*`; and to ignore the `system:serviceaccount:builder` service account we can use `^system:serviceaccount:builder$.` ### Namespace Access Policy diff --git a/docs/content/sre/tenant-operator/tenant-roles.md b/docs/content/sre/tenant-operator/tenant-roles.md index a3fd9c2d..c90b8a90 100644 --- a/docs/content/sre/tenant-operator/tenant-roles.md +++ b/docs/content/sre/tenant-operator/tenant-roles.md @@ -170,7 +170,7 @@ fig 4. Shows viewers role in a tenant using Tenant Operator Viewer role will only have view access on there `Project`. -#### Access Permissions +#### Access Permissions * ServiceAccount access in `Project` * get diff --git a/docs/content/sre/tenant-operator/troubleshooting.md b/docs/content/sre/tenant-operator/troubleshooting.md index d74f833d..f8c90277 100644 --- a/docs/content/sre/tenant-operator/troubleshooting.md +++ b/docs/content/sre/tenant-operator/troubleshooting.md @@ -10,7 +10,7 @@ If a user is added to tenant resource, and the user does not exist in RHSSO, the Description/steps after which this situation occurs: -1. Add a new user to Tenant CR +1. Add a new user to Tenant CR 2. Attempt to log in to Vault with the added user 3. Vault denies that the user exists, and signs the user up via RHSSO. User is now created on RHSSO (You may check for the user on RHSSO). diff --git a/docs/content/sre/tenant-operator/usecases/distributing-secrets-using-sealed-secret-template.md b/docs/content/sre/tenant-operator/usecases/distributing-secrets-using-sealed-secret-template.md index 15dc4f1f..1a5e610b 100644 --- a/docs/content/sre/tenant-operator/usecases/distributing-secrets-using-sealed-secret-template.md +++ b/docs/content/sre/tenant-operator/usecases/distributing-secrets-using-sealed-secret-template.md @@ -28,7 +28,7 @@ resources: "jenkins.io/credentials-description": credentials from Kubernetes ``` -Once the template has been created, Bill has to edit the `Tenant` to add unique label to namespaces in which the secret has to be deployed. +Once the template has been created, Bill has to edit the `Tenant` to add unique label to namespaces in which the secret has to be deployed. For this, he can use the support for [common](./tenant.html#distributing-common-labels-and-annotations-to-tenant-namespaces-via-tenant-custom-resource) and [specific](./tenant.html#distributing-specific-labels-and-annotations-to-tenant-namespaces-via-tenant-custom-resource) labels across namespaces. Bill has to specify a label on namespaces in which he needs the secret. He can add it to all namespaces inside a tenant or some specific namespaces depending on the use case. @@ -54,14 +54,14 @@ spec: - build - prod - # use this if you want to add label to some specific namespaces + # use this if you want to add label to some specific namespaces specificMetadata: - namespaces: - test-namespace labels: distribute-image-pull-secret: true - # use this if you want to add label to all namespaces under your tenant + # use this if you want to add label to all namespaces under your tenant commonMetadata: labels: distribute-image-pull-secret: true diff --git a/docs/content/sre/tenant-operator/usecases/hibernation.md b/docs/content/sre/tenant-operator/usecases/hibernation.md new file mode 100644 index 00000000..92497a3a --- /dev/null +++ b/docs/content/sre/tenant-operator/usecases/hibernation.md @@ -0,0 +1,116 @@ +# Freeing up unused resources at night time with tenant hibernation + +Bill is a cluster admin who wants to free unused cluster resources in an effort to reduce costs during the night when the cluster isn't being used. + +First, Bill creates a tenant with the `hibernation` schedules mentioned in the spec, or adds the hibernation field to existing tenant: + +```yaml +apiVersion: tenantoperator.stakater.com/v1beta1 +kind: Tenant +metadata: + name: sigma +spec: + hibernation: + sleepSchedule: 0 20 * * 1-5 + wakeSchedule: 0 8 * * 1-5 + owners: + users: + - user + editors: + users: + - user1 + quota: medium + namespaces: + withoutTenantPrefix: + - build + - stage + - dev +``` + +The schedules above will make all namespaces that belong to the tenant put the deployments and statefulSets within those namespaces to sleep, by reducing their pod count to 0 at 8 PM every weekday. At 8 AM on a weekday, the namespaces will then wake up by restoring their applications' previous pod count. + +Bill can verify this behaviour by checking the newly created ResourceSupervisor resource at running time: + + +```bash +oc get ResourceSupervisor -A +NAME AGE +sigma 5m +``` + +The ResourceSupervisor will look like this at running time: + +```yaml +apiVersion: tenantoperator.stakater.com/v1beta1 +kind: ResourceSupervisor +metadata: + finalizers: + - tenantoperator.stakater.com/resourcesupervisor + name: example +spec: + argocd: + appProjects: [] + namespace: '' + hibernation: + sleepSchedule: 0 20 * * 1-5 + wakeSchedule: 0 8 * * 1-5 +status: + currentStatus: running + nextReconcileTime: '2022-10-12T20:00:00Z' +``` + +The ResourceSupervisor will look like this at sleeping time: + +```yaml +apiVersion: tenantoperator.stakater.com/v1beta1 +kind: ResourceSupervisor +metadata: + finalizers: + - tenantoperator.stakater.com/resourcesupervisor + name: example +spec: + argocd: + appProjects: [] + namespace: '' + hibernation: + sleepSchedule: 0 20 * * 1-5 + wakeSchedule: 0 8 * * 1-5 +status: + currentStatus: sleeping + nextReconcileTime: '2022-10-13T08:00:00Z' + sleepingApplications: + - Namespace: build + kind: Deployment + name: example + replicas: 3 + - Namespace: stage + kind: Deployment + name: example + replicas: 3 +``` + +Bill wants to prevent the `build` namespace from going to sleep, so they can add the `hibernation.stakater.com/exclude: 'true'` annotation to it. The ResourceSupervisor will now look like this after reconciling: + +```yaml +apiVersion: tenantoperator.stakater.com/v1beta1 +kind: ResourceSupervisor +metadata: + finalizers: + - tenantoperator.stakater.com/resourcesupervisor + name: example +spec: + argocd: + appProjects: [] + namespace: '' + hibernation: + sleepSchedule: 0 20 * * 1-5 + wakeSchedule: 0 8 * * 1-5 +status: + currentStatus: sleeping + nextReconcileTime: '2022-10-13T08:00:00Z' + sleepingApplications: + - Namespace: stage + kind: Deployment + name: example + replicas: 3 +``` diff --git a/docs/content/sre/tenant-operator/usecases/manager-clusterrole.md b/docs/content/sre/tenant-operator/usecases/manager-clusterrole.md index fcee2db4..3c7c9417 100644 --- a/docs/content/sre/tenant-operator/usecases/manager-clusterrole.md +++ b/docs/content/sre/tenant-operator/usecases/manager-clusterrole.md @@ -18,3 +18,6 @@ managerRoleExtendedRules: - update - watch ``` +## What’s next + +See how Bill can [hibernate unused namespaces at night](./hibernation.html) diff --git a/docs/content/sre/tenant-operator/usecases/namespace.md b/docs/content/sre/tenant-operator/usecases/namespace.md index 01c2350b..e86ac039 100644 --- a/docs/content/sre/tenant-operator/usecases/namespace.md +++ b/docs/content/sre/tenant-operator/usecases/namespace.md @@ -62,7 +62,7 @@ Additionally, to remove namespaces from a tenant, simply remove the tenant label ## Remove Namespaces from your Cluster via GitOps. - GitOps is a quick and efficient way to automate the management of your K8S resources. + GitOps is a quick and efficient way to automate the management of your K8s resources. To remove namespaces from your cluster via GitOps; diff --git a/docs/content/sre/tenant-operator/usecases/quota.md b/docs/content/sre/tenant-operator/usecases/quota.md index 983435d0..e265ead3 100644 --- a/docs/content/sre/tenant-operator/usecases/quota.md +++ b/docs/content/sre/tenant-operator/usecases/quota.md @@ -7,7 +7,7 @@ Using Tenant-Operator, the cluster-admin can set and enforce resource quotas and Bill is a cluster admin who will first creates a resource quota where he sets the maximum resource limits that Anna's tenant will have. Here `limitrange` is an optional field, cluster admin can skip it if not needed. -The annotation `quota.tenantoperator.stakater.com/is-default: "true"` sets the quota as default quota. +The annotation `quota.tenantoperator.stakater.com/is-default: "true"` sets the quota as default quota. ```yaml kubectl create -f - << EOF @@ -30,11 +30,11 @@ spec: limits: - type: "Pod" max: - cpu: "2" - memory: "1Gi" + cpu: "2" + memory: "1Gi" min: - cpu: "200m" - memory: "100Mi" + cpu: "200m" + memory: "100Mi" EOF ``` @@ -46,7 +46,7 @@ NAME STATE AGE small Active 3m ``` -Bill then proceeds to create a tenant for Anna, while also linking the newly created `quota`. +Bill then proceeds to create a tenant for Anna, while also linking the newly created `quota`. ```yaml kubectl create -f - << EOF diff --git a/docs/content/sre/tenant-operator/usecases/template.md b/docs/content/sre/tenant-operator/usecases/template.md index 61d6eedd..500700b0 100644 --- a/docs/content/sre/tenant-operator/usecases/template.md +++ b/docs/content/sre/tenant-operator/usecases/template.md @@ -75,4 +75,4 @@ Parameters can be used with both `manifests` and `helm charts` ## What’s next -See how Anna can deploy a [template in a namespace](./deploying-templates.html) \ No newline at end of file +See how Anna can deploy a [template in a namespace](./deploying-templates.html)