Alek's Blog - best-practices

K8s & OpenShift: Compliance

aleks — Wed, 01 Jul 2026 00:00:00 +0000

Part 6</a> covered the operational loop: GitOps, observability, cost control, and upgrades. This final part maps the cluster configuration covered throughout this series to the regulatory frameworks that require it — NIS2, DORA, PCI-DSS, HIPAA, and the Cyber Resilience Act (CRA) — and covers the two topics that compliance work adds on top of security: audit logging as evidence and log retention as a contractual obligation.

K8s & OpenShift: Day-2 Operations & GitOps

aleks — Wed, 01 Jul 2026 00:00:00 +0000

Part 5</a> covered the security controls that harden workloads and the cluster. This part covers what keeps a cluster healthy after the initial deployment: GitOps workflows, observability, cost control, and the operational cadence of upgrades.

K8s & OpenShift: The Big Picture

aleks — Wed, 01 Jul 2026 00:00:00 +0000

This is the opening post of a seven-part series on Kubernetes and OpenShift best practices, written from the vantage point of 2026 and eight years of hands-on experience — from initial cluster design through Day-2 operations and production debugging. This first part is deliberately non-technical: it is about whether and when a container platform earns its keep — the decisions that happen before anyone writes a single YAML manifest.

K8s & OpenShift: Resource Management

aleks — Wed, 01 Jul 2026 00:00:00 +0000

Part 2</a> covered the workload contract — probes, security context, graceful shutdown. This part goes one level lower: how the Linux kernel enforces the resource boundaries you declare in your YAML, what happens when a container hits those boundaries, and why misconfigurations here are the single most common source of both cloud waste and production incidents.

K8s & OpenShift: Scaling & Resilience

aleks — Wed, 01 Jul 2026 00:00:00 +0000

Part 3</a> covered resource requests, limits, and how the kernel enforces them. This part covers what sits on top of that foundation: the mechanisms Kubernetes provides to scale workloads automatically and to keep them available when nodes drain, cluster upgrades run, or traffic spikes arrive unexpectedly.

K8s & OpenShift: Security

aleks — Wed, 01 Jul 2026 00:00:00 +0000

Part 4</a> covered scaling and resilience. This part covers security — not as a checklist to complete before an audit, but as a set of controls that reduce real attack surface and limit the blast radius when something goes wrong.

K8s & OpenShift: Building Workloads Right

aleks — Wed, 01 Jul 2026 00:00:00 +0000

Part 1</a> covered the business case and organisational framing. This part goes inside the pod: image hygiene, security context, health probes, graceful shutdown, and the application design choices that determine whether a workload actually fits the platform.

The Kubernetes & OpenShift Best Practices Guide (2026 Edition)

aleks — Wed, 01 Jul 2026 00:00:00 +0000

This is the index and reading guide for a seven-part series on running Kubernetes and OpenShift in production, written from the vantage point of 2026 and eight years of hands-on cluster design, Day-2 operations, and production debugging. Each part stands on its own; together they cover a workload’s whole life on the platform — from the image it ships in to the audit trail it leaves behind.

Kubernetes & OpenShift Best Practices in 2026: The Big Picture

aleks — Thu, 25 Jun 2026 00:00:00 +0000

Hier beschreiben wir ein paar Best practices für Applikation die in Kubernetes laufen sollen.

IMMER Container probes nutzen</li> </ul>
Die Container probes ermöglichen dem Kubernetes System den Zustand der Applikation von außen festzustellen. Die Probes sollten leichtgewichtig sein aber auch aussagekräftig.
Hier ein paar Beispiele für Java basierte Applikationen

Spring Boot: health ac… </li>

Tomcat: Health Check Valve </li> </ul>

Prometheus Endpunkte zur Verfügung stellen was das Monitoring in der Container Welt wesentlich vereinfacht. Es gibt für viele Programmiersprachen CLIENT LIBRARIES was die Verfügungstellung der Endpukte vereinfacht. </li>

Die Applikation MUSS jederzeit bereit sein gestopped zu werden. </li>

Falls mehr als eine Instanz (Pod’s) zur gleichen Zeit laufen sollen ( replicas >1 ) muss die Applikation “Clusterfähig” sein. </li>

Für Session Daten sollte man keine lokale Ablage nutzen. </li>

Logging by default auf STDOUT oder via einem Logshipper auf eine zentrales Logging System </li> </ul>
Best practice für Container Image Erstellung
Hier fassen wir einige Richtlinien und Tips zusammen welche aus unserer Erfahrung hilfreich sind.

Keine spezifischen User
Der Hintergrund dafür ist das man damit die Möglichkeit hat der Container Runtime die Runtime Sicherheit zu spezifizieren und konfigurieren. </li>

Keine Shell freien Basis-Images nutzen (z. B.: Distroless, Scratch, …)
Der Hintergrund dafür ist das man ohne Shell einen laufenden Container gar nicht oder sehr schwer Debuggen kann. </li>

Immer spezifische Versionen in der Produktion laufen lassen
Der Hintergrund dafür ist das “latest” alles mögliche sein kann. </li>

Es sollten zu mindest folgende Tools im Image installiert sein.

curl</li>
ps</li>
dig</li> </ul> </li>

alpine als Basis-Images Image nutzt nicht die glibc sondern die musl libc was zu gewissen Problemen führen kann.

Setzen der Time and timezones geht nicht über TZ Variable</li>
Bisher haben sich ubuntu und UBI Basis-Images als recht zuverlässig herausgestellt</li> </ul> </li> </ul>