Thema: containers
-
Welche Regeln zur Image-Aufbewahrung halten eine Container-Registry klein, ohne noch eingesetzte Images zu löschen?
Offene Frage: Registrys sammeln per Garbage Collection nur Blobs ein, auf die kein Manifest mehr verweist, und Lifecycle-Regeln lassen Images nach Alter, Anzahl oder Tag-Muster ablaufen; welche Kombination von Regeln haben Teams über Jahre gefahren, ohne dass entweder unbegrenztes Wachstum entstand oder ein Rollback scheiterte, weil sein Image weg war?
-
Agentenhandlungen sandboxen: Grenzen für Dateisystem, Netzwerk und Zugangsdaten
Ein Agent, der Befehle oder Code ausführt, sollte dies innerhalb einer Grenze tun, die einschränkt, auf welche Dateien er zugreifen, welche Hosts er erreichen und welche Geheimnisse er lesen kann; Container mit entzogenen Capabilities und einem seccomp-Profil, User-Space-Kernel wie gVisor, ein standardmässig gesperrtes Netzwerk und kurzlebige, eng begrenzte Zugangsdaten sind die Bausteine dafür.
-
Eine JVM in einem Container dimensionieren: Heap-Prozentsatz, Non-Heap-Speicher und CPU-Anzahl
Die JVM liest standardmässig cgroup-Grenzen (UseContainerSupport) und bemisst den Heap als Prozentsatz des Container-Speichers, nicht des Host-Speichers; der Heap ist nur ein Teil des Speicherbedarfs, daher MaxRAMPercentage so setzen, dass Platz für Metaspace, Thread-Stacks, Direct Buffers und Code-Cache bleibt, die von der JVM gesehene CPU-Anzahl prüfen und mit -Xlog:os+container sowie Native Memory Tracking verifizieren, bevor einer Grenze vertraut wird.
-
Docker Compose für die lokale Entwicklung: Override-Dateien, Profile, gesunde Abhängigkeiten und Watch
Eine einzige committete compose.yaml pflegen, die die Produktionsform widerspiegelt, eine compose.override.yaml für lokale Ports und Bind-Mounts hinzufügen, optionale Werkzeuge hinter Profile stellen, depends_on auf service_healthy warten lassen und develop.watch nutzen, um bei Dateiänderungen zu synchronisieren oder neu zu bauen.
-
Container-Image-Tags versus Digests: veränderliche Namen und Inhaltsadressen
Ein Tag ist ein menschenlesbarer Zeiger, der jederzeit auf ein anderes Manifest umgehängt werden kann; ein Digest ist der Hash der Manifest-Bytes und identifiziert für immer genau ein Image. Nach Tag bauen und testen, nach Digest deployen und pinnen, und den Digest in jeder Release-Notiz festhalten.
-
Which memory metric should alerts and autoscalers use for a containerised service: RSS, PSS, working set or cgroup memory.current?
Open question: process RSS counts shared pages per process, cgroup memory.current includes page cache and kernel memory, and Kubernetes reports a heuristic working set; which of these has been used as the alerting and scaling signal for a long-running service without either paging on reclaimable cache or missing an approach to the OOM limit?
-
Dev containers: devcontainer.json as a reproducible development environment
A devcontainer.json describes the container an editor, cloud workspace or CI runner should build for a repository: image or Dockerfile, features, forwarded ports, lifecycle commands and editor customisations. The open specification at containers.dev makes the same file usable locally, in hosted workspaces and in pipelines, so the toolchain is pinned with the code instead of living on each host.
-
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.
Maschinenlesbar: JSON