https://deploy-preview-80--docs-projectcapsule.netlify.app/docs/tenants/Recent content in Tenants on CapsuleHugo -- gohugo.ioenhttps://deploy-preview-80--docs-projectcapsule.netlify.app/docs/tenants/quickstart/Mon, 01 Jan 0001 00:00:00 +0000https://deploy-preview-80--docs-projectcapsule.netlify.app/docs/tenants/quickstart/In Capsule, a Tenant is an abstraction to group multiple namespaces in a single entity within a set of boundaries defined by the Cluster Administrator. The tenant is then assigned to a user or group of users who is called Tenant Owner. Capsule defines a Tenant as Custom Resource with cluster scope. Create the tenant as cluster admin: kubectl create -f - << EOF apiVersion: capsule.clastix.io/v1beta2 kind: Tenant metadata: name: solar spec: owners: - name: alice kind: User EOF You can check the tenant just createdhttps://deploy-preview-80--docs-projectcapsule.netlify.app/docs/tenants/namespaces/Mon, 01 Jan 0001 00:00:00 +0000https://deploy-preview-80--docs-projectcapsule.netlify.app/docs/tenants/namespaces/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-80--docs-projectcapsule.netlify.app/docs/tenants/permissions/Mon, 01 Jan 0001 00:00:00 +0000https://deploy-preview-80--docs-projectcapsule.netlify.app/docs/tenants/permissions/Ownership Capsule introduces the principal, that tenants must have owners (Tenant Owners). The owner of a tenant is a user or a group of users that have the right to create, delete, and manage the tenant’s namespaces and other tenant resources. However an owner does not have the permissions to manage the tenants they are owner of. This is still done by cluster-administrators. At any time you are able to verify which users or groups are owners of a tenant by checking the owners field of the Tenant status subresource:https://deploy-preview-80--docs-projectcapsule.netlify.app/docs/tenants/quotas/Mon, 01 Jan 0001 00:00:00 +0000https://deploy-preview-80--docs-projectcapsule.netlify.app/docs/tenants/quotas/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 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. Set resources quota for each Namespace in the Alice’s Tenant by defining them in the Tenant spec:https://deploy-preview-80--docs-projectcapsule.netlify.app/docs/tenants/enforcement/Mon, 01 Jan 0001 00:00:00 +0000https://deploy-preview-80--docs-projectcapsule.netlify.app/docs/tenants/enforcement/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-80--docs-projectcapsule.netlify.app/docs/tenants/metadata/Mon, 01 Jan 0001 00:00:00 +0000https://deploy-preview-80--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 capsule.clastix.io/tenant: <tenant-name> label. Namespaces AdditionalMetadataList Information Starting from v0.10.8, it is possible to use templated values for labels and annotations. Currently, {{ tenant.name }} and {{ namespace }} placeholders are available. apiVersion: capsule.clastix.io/v1beta2 kind: Tenant metadata: name: solar spec: owners: - name: alice kind: User namespaceOptions: additionalMetadataList: - annotations: templated-annotation: {{ tenant.https://deploy-preview-80--docs-projectcapsule.netlify.app/docs/tenants/rules/Mon, 01 Jan 0001 00:00:00 +0000https://deploy-preview-80--docs-projectcapsule.netlify.app/docs/tenants/rules/Enforcement rules allow Bill, the cluster admin, to set policies and restrictions on a per-Tenant basis. These rules are enforced by Capsule Admission Webhooks when Alice, the TenantOwner, creates or modifies resources in her Namespaces. With the Rule Construct we can profile namespaces within a tenant to adhere to specific policies, depending on metadata. Namespace Selector By default a rule is applied to all namespaces within a Tenant. However you can select a subset of namespaces to apply the rule on, by using a namespaceSelector.https://deploy-preview-80--docs-projectcapsule.netlify.app/docs/tenants/administration/Mon, 01 Jan 0001 00:00:00 +0000https://deploy-preview-80--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 this said, the TenantOwner and the related Service Account living into managed Namespaces, cannot proceed to any update, create or delete action.