<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Tenants on Capsule</title><link>https://deploy-preview-82--docs-projectcapsule.netlify.app/docs/tenants/</link><description>Recent content in Tenants on Capsule</description><generator>Hugo -- gohugo.io</generator><language>en</language><atom:link href="https://deploy-preview-82--docs-projectcapsule.netlify.app/docs/tenants/index.xml" rel="self" type="application/rss+xml"/><item><title>Quickstart</title><link>https://deploy-preview-82--docs-projectcapsule.netlify.app/docs/tenants/quickstart/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://deploy-preview-82--docs-projectcapsule.netlify.app/docs/tenants/quickstart/</guid><description>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 - &amp;lt;&amp;lt; EOF apiVersion: capsule.clastix.io/v1beta2 kind: Tenant metadata: name: oil spec: permissions: matchOwners: - matchLabels: team: platform owners: - name: alice kind: Us You can check the tenant just created ```bash $ kubectl get tenants NAME STATE NAMESPACE QUOTA NAMESPACE COUNT NODE SELECTOR READY STATUS AGE oil Active 0 True reconciled 13s We create dedicated TenantOwners who represent cluster administrators.</description></item><item><title>Namespaces</title><link>https://deploy-preview-82--docs-projectcapsule.netlify.app/docs/tenants/namespaces/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://deploy-preview-82--docs-projectcapsule.netlify.app/docs/tenants/namespaces/</guid><description>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.</description></item><item><title>Permissions</title><link>https://deploy-preview-82--docs-projectcapsule.netlify.app/docs/tenants/permissions/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://deploy-preview-82--docs-projectcapsule.netlify.app/docs/tenants/permissions/</guid><description>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).</description></item><item><title>Quotas</title><link>https://deploy-preview-82--docs-projectcapsule.netlify.app/docs/tenants/quotas/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://deploy-preview-82--docs-projectcapsule.netlify.app/docs/tenants/quotas/</guid><description>With help of Capsule, Bill, the cluster admin, can set and enforce resources quota and limits for Alice&amp;rsquo;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&amp;rsquo;s Tenant. Set resources quota for each Namespace in the Alice&amp;rsquo;s Tenant by defining them in the Tenant spec:</description></item><item><title>Rules</title><link>https://deploy-preview-82--docs-projectcapsule.netlify.app/docs/tenants/rules/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://deploy-preview-82--docs-projectcapsule.netlify.app/docs/tenants/rules/</guid><description>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.</description></item><item><title>Administration</title><link>https://deploy-preview-82--docs-projectcapsule.netlify.app/docs/tenants/administration/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://deploy-preview-82--docs-projectcapsule.netlify.app/docs/tenants/administration/</guid><description>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 droped. Any Updates to Subresources (i.</description></item><item><title>Enforcement</title><link>https://deploy-preview-82--docs-projectcapsule.netlify.app/docs/tenants/enforcement/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://deploy-preview-82--docs-projectcapsule.netlify.app/docs/tenants/enforcement/</guid><description>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&amp;rsquo;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: &amp;#34;50m&amp;#34; memory: &amp;#34;5Mi&amp;#34; max: cpu: &amp;#34;1&amp;#34; memory: &amp;#34;1Gi&amp;#34; - limits: - type: Container defaultRequest: cpu: &amp;#34;100m&amp;#34; memory: &amp;#34;10Mi&amp;#34; default: cpu: &amp;#34;200m&amp;#34; memory: &amp;#34;100Mi&amp;#34; min: cpu: &amp;#34;50m&amp;#34; memory: &amp;#34;5Mi&amp;#34; max: cpu: &amp;#34;1&amp;#34; memory: &amp;#34;1Gi&amp;#34; - limits: - type: PersistentVolumeClaim min: storage: &amp;#34;1Gi&amp;#34; max: storage: &amp;#34;10Gi&amp;#34; Limits will be inherited by all the Namespaces created by Alice.</description></item><item><title>Metadata</title><link>https://deploy-preview-82--docs-projectcapsule.netlify.app/docs/tenants/metadata/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://deploy-preview-82--docs-projectcapsule.netlify.app/docs/tenants/metadata/</guid><description>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: &amp;lt;tenant-name&amp;gt; (Legacy label) projectcapsule.dev/tenant: &amp;lt;tenant-name&amp;gt; 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 RequiredMetadata The cluster admin can enforce tenant owners to add specific metadata as Labels and Annotations to the Namespaces they create.</description></item></channel></rss>