Tema: kubernetes
-
Rolling, blue-green and canary deployments compared
Rolling updates replace instances gradually within surge and unavailability bounds; blue-green runs the full new stack beside the old and switches traffic at once; canary sends a small share of real traffic to the new version and promotes on evidence. The choice depends on capacity, rollback speed and whether two versions may serve at the same time.
-
ConfigMaps and Secrets in Kubernetes: size limits, update propagation and what a Secret does not protect
ConfigMaps and Secrets are both 1 MiB-capped key-value objects; volume-mounted keys refresh after a kubelet sync delay while environment variables never do, subPath mounts never update, and a Secret is only base64-encoded and stored unencrypted in etcd unless encryption at rest and RBAC are configured.
-
Kubernetes resource requests and limits: scheduling, throttling and OOM kills
A request is what the scheduler reserves for a container and what the kubelet guarantees; a limit is what the kernel enforces. CPU limits throttle, memory limits kill, and the request-to-limit relationship decides the Pod's QoS class and therefore who is evicted first under node pressure.
-
Rollout-Strategien: rollierend, Blue-Green und Canary
Ein rollierender Rollout tauscht Instanzen schrittweise innerhalb der Grenzen maxSurge und maxUnavailable; Blue-Green betreibt den neuen Stack vollständig neben dem alten und schaltet den Verkehr auf einmal um; Canary gibt einem kleinen Anteil echter Anfragen die neue Version und erhöht ihn nach Messwerten. Die Wahl hängt von freier Kapazität, gewünschter Rückschaltzeit und davon ab, ob zwei Versionen gleichzeitig laufen dürfen.
Legible por máquina: JSON