<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Best Practices on Capsule</title><link>https://lorenzbischof.ch/capsule-website/v0.10/docs/operating/best-practices/</link><description>Recent content in Best Practices on Capsule</description><generator>Hugo -- gohugo.io</generator><language>en</language><atom:link href="https://lorenzbischof.ch/capsule-website/v0.10/docs/operating/best-practices/index.xml" rel="self" type="application/rss+xml"/><item><title>Architecture</title><link>https://lorenzbischof.ch/capsule-website/v0.10/docs/operating/best-practices/architecture/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lorenzbischof.ch/capsule-website/v0.10/docs/operating/best-practices/architecture/</guid><description>Ownership In Capsule, we introduce a new persona called the Tenant Owner. The goal is to enable Cluster Administrators to delegate tenant management responsibilities to Tenant Owners. Here’s how it works:
Tenant Owners: They manage the namespaces within their tenants and perform administrative tasks confined to their tenant boundaries. This delegation allows teams to operate more autonomously while still adhering to organizational policies. Cluster Administrators: They provision tenants, essentially determining the size and resource allocation of each tenant within the entire cluster.</description></item><item><title>General Advice</title><link>https://lorenzbischof.ch/capsule-website/v0.10/docs/operating/best-practices/general-advice/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lorenzbischof.ch/capsule-website/v0.10/docs/operating/best-practices/general-advice/</guid><description>This is general advice you should consider before making Kubernetes Distribution consideration. They are partly relevant for Multi-Tenancy with Capsule.
Authentication User authentication for the platform should be handled via a central OIDC-compatible identity provider system (e.g., Keycloak, Azure AD, Okta, or any other OIDC-compliant provider). The rationale is that other central platform components — such as ArgoCD, Grafana, Headlamp, or Harbor — should also integrate with the same authentication mechanism.</description></item><item><title>Workloads</title><link>https://lorenzbischof.ch/capsule-website/v0.10/docs/operating/best-practices/workloads/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lorenzbischof.ch/capsule-website/v0.10/docs/operating/best-practices/workloads/</guid><description>User Namespaces Info The FeatureGate UserNamespacesSupport is active by default since Kubernetes 1.33. However every pod must still opt-in
When you are also enabling the FeatureGate UserNamespacesPodSecurityStandards you may relax the Pod Security Standards for your workloads. Read More
A process running as root in a container can run as a different (non-root) user in the host; in other words, the process has full privileges for operations inside the user namespace, but is unprivileged for operations outside the namespace.</description></item><item><title>Networking</title><link>https://lorenzbischof.ch/capsule-website/v0.10/docs/operating/best-practices/networking/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lorenzbischof.ch/capsule-website/v0.10/docs/operating/best-practices/networking/</guid><description>Network-Policies It&amp;rsquo;s a best practice to not allow any traffic outside of a tenant (or a tenant&amp;rsquo;s namespace). For this we can use Tenant Replications to ensure we have for every namespace Networkpolicies in place.
The following NetworkPolicy is distributed to all namespaces which belong to a Capsule tenant:
apiVersion: capsule.clastix.io/v1beta2 kind: GlobalTenantResource metadata: name: default-networkpolicies namespace: solar-system spec: resyncPeriod: 60s resources: - rawItems: - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-policy spec: # Apply to all pods in this namespace podSelector: {} policyTypes: - Ingress - Egress ingress: # Allow traffic from the same namespace (intra-namespace communication) - from: - podSelector: {} # Allow traffic from all namespaces within the tenant - from: - namespaceSelector: matchLabels: capsule.</description></item><item><title>Container Images</title><link>https://lorenzbischof.ch/capsule-website/v0.10/docs/operating/best-practices/images/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lorenzbischof.ch/capsule-website/v0.10/docs/operating/best-practices/images/</guid><description>Until this issue is resolved (might be in Kubernetes 1.34)
it&amp;rsquo;s recommended to use the ImagePullPolicy Always for private registries on shared nodes. This ensures that no images can be used which are already pulled to the node.</description></item></channel></rss>