<?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.11/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.11/docs/operating/best-practices/index.xml" rel="self" type="application/rss+xml"/><item><title>Architecture</title><link>https://lorenzbischof.ch/capsule-website/v0.11/docs/operating/best-practices/architecture/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lorenzbischof.ch/capsule-website/v0.11/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>Workloads</title><link>https://lorenzbischof.ch/capsule-website/v0.11/docs/operating/best-practices/workloads/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lorenzbischof.ch/capsule-website/v0.11/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.11/docs/operating/best-practices/networking/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lorenzbischof.ch/capsule-website/v0.11/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.11/docs/operating/best-practices/images/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lorenzbischof.ch/capsule-website/v0.11/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>