Stakater and the RedHat team collaborated to write this article and it was originally published on the RedHat Website.
As a Technology Partner within the Red Hat OpenShift ecosystem, Stakater's Multi Tenant Operator has been officially certified by Red Hat since March 2022, with the latest release certified in November 2023. With Red Hat OpenShift Certified Operators, customers can benefit from validated, verified, mature and supported Operators from Red Hat and partner ISVs in their hybrid cloud environments.
Learn more about Red Hat OpenShift Operator certification here. To learn more about becoming a Red Hat Partner see this link.
You can also explore OpenShift as a Service by Stakater, providing a managed OpenShift environment that ensures high availability, security, and scalability for your applications.
This is the third part in a series featuring the exploration of Multi Tenant Operator (MTO) by Stakater, an operator designed to streamline and secure multi-tenancy in OpenShift and Kubernetes environments. In our two previous blogs (1) (2), we described MTO fundamentals. In this blog, we focus on Templates, TemplateInstance (TI), and TemplateGroupInstance (TGI). Templates serve as a standardized playbook, ensuring consistent deployment and management of resources across multiple tenants. We clarify how these features contribute to operational efficiency and security, providing a comprehensive overview of their use and benefits in multi-tenant architectures.
Templates
Templates in the MTO act like a club's standard playbook or strategy guide in soccer. They provide a predefined set of resources or configurations that are consistently deployed across multiple namespaces or Tenants. This feature is crucial for ensuring conformity, efficiency, and simplifying the management of common resources like Network Policies, Helm charts, or secret mappings.
Custom resource (YAML)
A Template in MTO is defined as a Kubernetes Custom Resource (CR). The types of Templates available are as follows.
Helm chart Template: These Templates define Helm charts for deploying applications or services. Example:
apiVersion: tenantoperator.stakater.com/v1alpha1
kind: Template
metadata:
name: redis
resources:
helm:
releaseName: redis
chart:
repository:
name: redis
repoUrl: https://charts.bitnami.com/bitnami
values: |
redisPort: 6379Manifest Template: These Templates contain Kubernetes manifests for resources like Network Policies, acting like guidelines for specific team strategies. Example:
apiVersion: tenantoperator.stakater.com/v1alpha1
kind: Template
metadata:
name: networkpolicy
parameters:
- name: CIDR_IP
value: 172.17.0.0/16
resources:
manifests:
- apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-cross-ns-traffic
spec:
egress:
- ports:
- port: 5978
protocol: TCP
to:
- ipBlock:
cidr: 10.0.0.0/24
ingress:
- from:
- ipBlock:
cidr: '${{CIDR_IP}}'
except:
- 172.17.1.0/24
- namespaceSelector:
matchLabels:
project: myproject
- podSelector:
matchLabels:
role: frontend
ports:
- port: 6379
protocol: TCP
podSelector:
matchLabels:
role: db
policyTypes:
- Ingress
- EgressResource mapping Template: Used for mapping Secrets and ConfigMaps across namespaces, akin to sharing tactics or training methods across different club teams. Example:
apiVersion: tenantoperator.stakater.com/v1alpha1
kind: Template
metadata:
name: resource-mapping
resources:
resourceMappings:
secrets:
- name: secret-s1
namespace: namespace-n1
configMaps:
- name: configmap-c1
namespace: namespace-n2For more information on Templates, refer to the official MTO docs.
Templates and their relation to TemplateInstances
While we've explored how Templates can be directly integrated into Tenants, it is also worth understanding their relationship with TemplateInstances (TI). Templates are the blueprints–the predefined sets of resources or configurations. TemplateInstances are the mechanisms that deploy these blueprints into specific namespaces.
Key points
Flexibility in Application: TemplateInstances provide flexibility, allowing for the selective application of Templates. This means that certain Templates can be applied only to specific namespaces as required, rather than across all namespaces of a Tenant.
Dynamic Parameter Substitution: TemplateInstances can override or provide values for parameters defined in a Template. This feature is particularly useful when the same Template needs to be applied differently depending on the context.
Streamlined Management: By using TemplateInstances, cluster administrators can manage how and where Templates are applied more granularly. This ensures each namespace gets only what it needs, enhancing efficiency and reducing resource clutter.
Templates, along with TemplateInstances, offer a powerful way to standardize and manage resources across multiple namespaces in a Kubernetes environment. They provide a balance between uniformity and customization, ensuring that each part of the cluster operates both independently and cohesively within the larger organizational structure. For more information on TI, refer to the official MTO docs.
TemplateGroupInstances
TemplateGroupInstances (TGIs) in Multi Tenant Operator act as a mechanism to apply a specific set of configurations, defined in a Template, much like TemplateInstances but across multiple namespaces. This is analogous to a sports league uniformly implementing certain rules or training protocols across various teams.
Custom Resource (YAML)
TGIs are defined as cluster-scoped resources. Here is an example of a TGI to deploy a security-policy Template to all namespaces labeled with security-level: high:
apiVersion: tenantoperator.stakater.com/v1alpha1
kind: TemplateGroupInstance
metadata:
name: security-policy-tgi
spec:
template: security-policy
sync: true
selector:
matchLabels:
security-level: highField explanation:
selector: The selector in a TGI identifies the namespaces where the Template will be applied. In this example, any namespace with the label security-level: high will receive the configurations from the security-policy Template.
sync: When true, this feature keeps the resources in the selected namespaces in synchronization with the Template. If changes are unintentionally made locally within a namespace, the TGI will revert them back to match the Template's specifications.
Example use
Let's take a scenario where Susan, a cluster admin, wants to enforce a standardized logging policy across several critical namespaces in the organization. She decides to use a TGI for this purpose.
1. Template creation (logging-policy):
Susan creates a Template named logging-policy that defines the configurations for a logging tool to be used across critical namespaces:
apiVersion: tenantoperator.stakater.com/v1alpha1
kind: Template
metadata:
name: logging-policy
resources:
manifests:
# <Logging tool configuration added>2. TemplateGroupInstance for logging-policy:
She then creates a TGI named logging-policy-tgi to apply the logging-policy Template to all namespaces meant for critical operations, identified via the operation: critical label:
apiVersion: tenantoperator.stakater.com/v1alpha1
kind: TemplateGroupInstance
metadata:
name: logging-policy-tgi
spec:
template: logging-policy
selector:
matchLabels:
operation: critical
sync: true3. Here is then a Tenant YAML configuration that uses the logging-policy-tgi TemplateGroupInstance:
apiVersion: tenantoperator.stakater.com/v1beta2
kind: Tenant
metadata:
name: critical-operations-tenant
spec:
owners:
users:
- susan@techcompany.com
quota: medium
namespaces:
withTenantPrefix:
- critical-app1
- critical-app2
- critical-app3
commonMetadata:
labels:
operation: criticalField explanation:
Tenant Definition: The Tenant named critical-operations-tenant is set up specifically for critical operations within Susan's organization.
Namespace Creation: Under this Tenant, the namespaces critical-app1, critical-app2, and critical-app3 are created. These are intended for critical applications or operations.
Common Metadata: The commonMetadata field assigns the label operation: critical to all namespaces in this Tenant. This label aligns with the selector criteria defined in the logging-policy-tgi TemplateGroupInstance.
Integration with TemplateGroupInstance: The logging-policy-tgi TemplateGroupInstance is designed to target namespaces with the label operation: critical. As a result of using the matching labels, the logging policy defined in the Template is automatically applied to all namespaces created under the critical-operations-tenant, ensuring a consistent logging approach across these critical applications.
In a diverse OpenShift environment, TGIs offer an efficient way to manage and enforce consistent standards, especially in large organizations with numerous namespaces. Whether it's applying security measures, operational policies, or shared configurations, TGIs simplify the process, ensuring that all relevant parts of the organization adhere to the same standards and practices. For more information on TGI, refer to the official MTO docs.
Conclusion
Features like Templates, TemplateInstances (TI), and TemplateGroupInstances (TGI) are key to efficiently manage multi-tenancy in OpenShift. These elements simplify the deployment and management of resources across tenants, and bolster security and operational efficiency. MTO stands as an indispensable tool for orchestrating complex environments, showcasing its vital role in the modern Kubernetes landscape in the field of multi-tenancy.
Comments