Tenant#
A minimal Tenant definition requires only a quota field, essential for limiting resource consumption:
apiVersion: tenantoperator.stakater.com/v1beta3
kind: Tenant
metadata:
name: alpha
spec:
quota: small
For a more comprehensive setup, a detailed Tenant definition includes various configurations:
apiVersion: tenantoperator.stakater.com/v1beta3
kind: Tenant
metadata:
name: tenant-sample
spec:
quota: small
accessControl:
owners:
users:
- kubeadmin
groups:
- admin-group
editors:
users:
- devuser1
- devuser2
groups:
- dev-group
viewers:
users:
- viewuser
groups:
- view-group
hibernation:
# UTC time
sleepSchedule: "20 * * * *"
wakeSchedule: "40 * * * *"
namespaces:
sandboxes:
enabled: true
private: true
withoutTenantPrefix:
- analytics
- marketing
withTenantPrefix:
- dev
- staging
onDeletePurgeNamespaces: true
metadata:
common:
labels:
common-label: common-value
annotations:
common-annotation: common-value
sandbox:
labels:
sandbox-label: sandbox-value
annotations:
sandbox-annotation: sandbox-value
specific:
- namespaces:
- tenant-sample-dev
labels:
specific-label: specific-dev-value
annotations:
specific-annotation: specific-dev-value
desc: "This is a sample tenant setup for the v1beta3 version."
Access Control#
Structured access control is critical for managing roles and permissions within a tenant effectively. It divides users into three categories, each with customizable privileges. This design enables precise role-based access management.
These roles are obtained from IntegrationConfig's TenantRoles field.
Owners
: Have full administrative rights, including resource management and namespace creation. Their roles are crucial for high-level management tasks.Editors
: Granted permissions to modify resources, enabling them to support day-to-day operations without full administrative access.Viewers
: Provide read-only access, suitable for oversight and auditing without the ability to alter resources.
Users and groups are linked to these roles by specifying their usernames or group names in the respective fields under owners
, editors
, and viewers
.
Quota#
The quota
field sets the resource limits for the tenant, such as CPU and memory usage, to prevent any single tenant from consuming a disproportionate amount of resources. This mechanism ensures efficient resource allocation and fosters fair usage practices across all tenants.
For more information on quotas, please refer here.
Namespaces#
Controls the creation and management of namespaces within the tenant:
-
sandboxes
:- When enabled, sandbox namespaces are created with the following naming convention - {TenantName}-{UserName}-sandbox.
- In case of groups, the sandbox namespaces will be created for each member of the group.
- Setting
private
to true will make the sandboxes visible only to the user they belong to. By default, sandbox namespaces are visible to all tenant members.
-
withoutTenantPrefix
: Lists the namespaces to be created without automatically prefixing them with the tenant name, useful for shared or common resources. withTenantPrefix
: Namespaces listed here will be prefixed with the tenant name, ensuring easy identification and isolation.onDeletePurgeNamespaces
: Determines whether namespaces associated with the tenant should be deleted upon the tenant's deletion, enabling clean up and resource freeing.metadata
: Configures metadata like labels and annotations that are applied to namespaces managed by the tenant:common
: Applies specified labels and annotations across all namespaces within the tenant, ensuring consistent metadata for resources and workloads.sandbox
: Special metadata for sandbox namespaces, which can include templated annotations or labels for dynamic information.- We also support the use of a templating mechanism within annotations, specifically allowing the inclusion of the tenant's username through the placeholder
{{ TENANT.USERNAME }}
. This template can be utilized to dynamically insert the tenant's username value into annotations, for example, asusername: {{ TENANT.USERNAME }}
.
- We also support the use of a templating mechanism within annotations, specifically allowing the inclusion of the tenant's username through the placeholder
specific
: Allows applying unique labels and annotations to specified tenant namespaces, enabling custom configurations for particular workloads or environments.
Hibernation#
hibernation
allows for the scheduling of inactive periods for namespaces associated with the tenant, effectively putting them into a "sleep" mode. This capability is designed to conserve resources during known periods of inactivity.
- Configuration for this feature involves two key fields,
sleepSchedule
andwakeSchedule
, both of which accept strings formatted according to cron syntax. - These schedules dictate when the namespaces will automatically transition into and out of hibernation, aligning resource usage with actual operational needs.
Description#
desc
provides a human-readable description of the tenant, aiding in documentation and at-a-glance understanding of the tenant's purpose and configuration.
⚠️ If same label or annotation key is being applied using different methods provided, then the highest precedence will be given to
namespaces.metadata.specific
followed bynamespaces.metadata.common
and in the end would be the ones applied fromopenshift.project.labels
/openshift.project.annotations
inIntegrationConfig