https://deploy-preview-117--docs-projectcapsule.netlify.app/docs/tenants/Recent content in Tenants on CapsuleHugo -- gohugo.ioenhttps://deploy-preview-117--docs-projectcapsule.netlify.app/docs/tenants/tenant-owner-guide/Mon, 01 Jan 0001 00:00:00 +0000https://deploy-preview-117--docs-projectcapsule.netlify.app/docs/tenants/tenant-owner-guide/This guide is for Tenant Owners: users who have been assigned ownership of a Capsule Tenant and are responsible for managing namespaces and team access within it. You do not need cluster-admin rights. Everything here is done with your own kubeconfig. If you have not set up your kubeconfig yet, ask your cluster administrator or follow the Proxy Access section of the Quickstart. See your Tenant Start by confirming which Tenant you own:https://deploy-preview-117--docs-projectcapsule.netlify.app/docs/tenants/namespaces/Mon, 01 Jan 0001 00:00:00 +0000https://deploy-preview-117--docs-projectcapsule.netlify.app/docs/tenants/namespaces/Assignment Alice, once logged with her credentials, can create a new Namespace in her Tenant, as simply issuing: kubectl create ns solar-production Alice started the name of the Namespace prepended by the name of the Tenant: this is not a strict requirement but it is highly suggested because it is likely that many different Tenants would like to call their Namespaces production, test, or demo, etc. The enforcement of this naming convention is optional and can be controlled by the cluster administrator with forceTenantPrefix option.https://deploy-preview-117--docs-projectcapsule.netlify.app/docs/tenants/permissions/Mon, 01 Jan 0001 00:00:00 +0000https://deploy-preview-117--docs-projectcapsule.netlify.app/docs/tenants/permissions/Administrators Administrators are users that have full control over all Tenants and their namespaces. They are typically cluster administrators or operators who need to manage the entire cluster and all its Tenants. However as administrator you are automatically Owner of all Tenants.Tenants This means that administrators can create, delete, and manage namespaces and other resources within any Tenant, given you are using label assignments for tenants. Ownership Capsule introduces the principal, that tenants must have owners (Tenant Owners).https://deploy-preview-117--docs-projectcapsule.netlify.app/docs/tenants/administration/Mon, 01 Jan 0001 00:00:00 +0000https://deploy-preview-117--docs-projectcapsule.netlify.app/docs/tenants/administration/Cordoning Bill needs to cordon a Tenant and its Namespaces for several reasons: Avoid accidental resource modification(s) including deletion during a Production Freeze Window During the Kubernetes upgrade, to prevent any workload updates During incidents or outages During planned maintenance of a dedicated nodes pool in a BYOD scenario With the default installation of Capsule all CREATE, UPDATE and DELETE operations performed by Capsule Users are dropped. Any Updates to Subresources (i.https://deploy-preview-117--docs-projectcapsule.netlify.app/docs/tenants/metadata/Mon, 01 Jan 0001 00:00:00 +0000https://deploy-preview-117--docs-projectcapsule.netlify.app/docs/tenants/metadata/Managed By default all namespaced resources within a Namespace which are part of a Tenant labeled at admission with the following labels: capsule.clastix.io/managed-by: <tenant-name> (Legacy label) projectcapsule.dev/tenant: <tenant-name> The labels are used by Capsule to identify resources belonging to a specific tenant. This is currently important for the Capsule Proxy to filter resources accordingly. Namespaces ManagedMetadataOnly Disallows any further metadata to be added to the Namespaces created by the tenant owners.https://deploy-preview-117--docs-projectcapsule.netlify.app/docs/tenants/enforcement/Mon, 01 Jan 0001 00:00:00 +0000https://deploy-preview-117--docs-projectcapsule.netlify.app/docs/tenants/enforcement/Deprecated This page covers legacy enforcement configuration. Use Rules for all current policy and restriction management. Scheduling LimitRanges This feature will be deprecated in a future release of Capsule. Instead use TenantReplications Bill, the cluster admin, can also set Limit Ranges for each Namespace in Alice’s Tenant by defining limits for pods and containers in the Tenant spec: apiVersion: capsule.clastix.io/v1beta2 kind: Tenant metadata: name: solar spec: ... limitRanges: items: - limits: - type: Pod min: cpu: "50m" memory: "5Mi" max: cpu: "1" memory: "1Gi" - limits: - type: Container defaultRequest: cpu: "100m" memory: "10Mi" default: cpu: "200m" memory: "100Mi" min: cpu: "50m" memory: "5Mi" max: cpu: "1" memory: "1Gi" - limits: - type: PersistentVolumeClaim min: storage: "1Gi" max: storage: "10Gi" Limits will be inherited by all the Namespaces created by Alice.https://deploy-preview-117--docs-projectcapsule.netlify.app/docs/tenants/quotas/Mon, 01 Jan 0001 00:00:00 +0000https://deploy-preview-117--docs-projectcapsule.netlify.app/docs/tenants/quotas/Deprecated This page covers the legacy quota approach. It will be removed in a future release. Use Resource Pools or Custom Quotas instead. With help of Capsule, Bill, the cluster admin, can set and enforce resources quota and limits for Alice’s Tenant. Resource Quota Deprecated This feature will be deprecated in a future release of Capsule. Instead use Resource Pools or Custom Quotas to handle any cases around distributed ResourceQuotas With help of Capsule, Bill, the cluster admin, can set and enforce resources quota and limits for Alice’s Tenant.