{"dataset":{"id":"00000000-0000-0000-0000-000000000015","slug":"kubernetes-best-practices","name":"Kubernetes best practices","description":"Source-linked guidance on core Kubernetes practice: resource requests and limits, health probes, namespaces, ConfigMaps, and labels. Scoped to upstream Kubernetes documentation; not an operator- or distribution-specific corpus.","visibility":"public","version":1,"documentCount":5,"publisher":"Koskamo editorial","license":"Original summaries; linked sources retain their own terms.","reviewedAt":"2026-10-04T00:00:00.000Z","readOnly":true,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},"total":5,"documents":[{"title":"Labels and selectors","sourceUrl":"https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/","text":"Labels are key/value pairs attached to objects such as Pods to record identifying attributes meaningful to users; they carry no semantics for the core system and can be added or modified at any time, with each key unique per object. Non-identifying information belongs in annotations. A key has an optional prefix and a required name separated by a slash: the name is at most 63 characters, beginning and ending with an alphanumeric character, and the prefix, if present, is a DNS subdomain of at most 253 characters; the kubernetes.io/ and k8s.io/ prefixes are reserved for core components. Values are at most 63 characters and may be empty. Label selectors are the core grouping primitive: equality-based and set-based requirements combine with commas as logical AND, and there is no logical OR operator. Scope: Kubernetes. Reviewed October 4, 2026.","id":"kubernetes-best-practices:Labels and selectors","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Configuration with ConfigMaps","sourceUrl":"https://kubernetes.io/docs/concepts/configuration/configmap/","text":"A ConfigMap stores non-confidential configuration as key-value pairs, decoupling environment-specific settings from container images so applications stay portable. Pods consume ConfigMaps as environment variables, command-line arguments, or files in a volume, and the Pod must be in the same namespace as the ConfigMap. ConfigMaps provide no secrecy or encryption — use a Secret for confidential data. The data and binaryData fields hold UTF-8 strings and base64-encoded binary data respectively, and their keys must not overlap; the ConfigMap name must be a valid DNS subdomain name, stored data cannot exceed 1 MiB, and setting the immutable field creates an immutable ConfigMap whose contents can no longer be mutated. Koskamo editorial guidance: mark ConfigMaps immutable when their contents never change, so accidental edits surface as errors instead of silent drift. Scope: Kubernetes. Reviewed October 4, 2026.","id":"kubernetes-best-practices:Configuration with ConfigMaps","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Organizing workloads with namespaces","sourceUrl":"https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/","text":"Namespaces isolate groups of resources within a single cluster: resource names must be unique within a namespace but not across namespaces, and scoping applies only to namespaced objects such as Deployments and Services — not cluster-wide objects such as StorageClasses, Nodes, and PersistentVolumes. Namespaces cannot be nested, each resource lives in exactly one, and they divide cluster resources between users through resource quota. They are meant for environments with many users spread across teams or projects; clusters with a few to tens of users should not need them, and slightly different resources such as versions of the same software are better distinguished with labels within one namespace. A cluster starts with default, kube-node-lease, kube-public, and kube-system; avoid the kube- prefix, which is reserved for system namespaces. Scope: Kubernetes. Reviewed October 4, 2026.","id":"kubernetes-best-practices:Organizing workloads with namespaces","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Liveness, readiness, and startup probes","sourceUrl":"https://kubernetes.io/docs/concepts/configuration/liveness-readiness-startup-probes/","text":"The kubelet can run three probes against a container. A startup probe verifies that the application has started; while one is configured, liveness and readiness probes do not run until it succeeds, and if it fails the kubelet kills the container, which is then handled by its restart policy. A liveness probe determines when to restart a container — for example, to recover from a deadlock — and must be configured carefully because an incorrect implementation can cause cascading failures; use initialDelaySeconds or a startup probe rather than waiting on readiness. A readiness probe determines when a container may receive traffic; on failure the EndpointSlice controller removes the Pod's IP address from the EndpointSlices of all matching Services, and it runs for the container's whole lifecycle. Scope: Kubernetes. Reviewed October 4, 2026.","id":"kubernetes-best-practices:Liveness, readiness, and startup probes","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Resource requests and limits for containers","sourceUrl":"https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/","text":"Resource requests and limits are set per container; CPU and memory are the most common resources. The kube-scheduler uses the request to decide which node a Pod is placed on, while the kubelet enforces limits and reserves at least the request amount for the container. A container may exceed its request when the node has spare capacity. CPU limits are hard limits enforced through CPU throttling; memory limits are enforced reactively by the kernel with out-of-memory (OOM) kills, so a container that exceeds its memory limit may be terminated. If you set a limit without a request and no admission-time default applies, Kubernetes copies the limit as the request. Koskamo editorial guidance: set both requests and limits on every container so scheduling and eviction behave predictably. Scope: Kubernetes. Reviewed October 4, 2026.","id":"kubernetes-best-practices:Resource requests and limits for containers","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"}]}