Cold start kontenera lub microVM to czas od żądania uruchomienia instancji do momentu, w którym jest ona gotowa obsłużyć ruch. Wśród technologii z jednoznacznie udokumentowanym, cytowalnym pomiarem najkrótszy cold start mają microVM: Firecracker (poniżej 125 ms, oficjalna dokumentacja projektu) i gVisor (50–100 ms, oficjalna dokumentacja Google) — znacznie szybciej niż w pełni izolowane VM typu Kata Containers.
Na skróty
Czego dowiesz się z artykułu:
- Co to jest cold start kontenera/microVM i dlaczego bywa mierzony inaczej dla różnych runtime’ów
- Firecracker: poniżej 125 ms — dlaczego jest tak szybki i gdzie jest używany (AWS Lambda, Fargate)
- gVisor: 50–100 ms i narzut poniżej 1% CPU dla większości aplikacji
- Kata Containers: 150–300 ms — cena za pełną izolację na poziomie jądra gościa
- Docker vs Podman vs containerd — dlaczego świadomie NIE podajemy tu twardych liczb (sprzeczne źródła)
- AWS Lambda: jak cold start obrazu kontenerowego wypada na tle klasycznego pakietu ZIP
- Tabela porównawcza wszystkich technologii z linkami do źródeł
Dla kogo ten artykuł:
- Platform Engineers/DevOps projektujący architekturę serverless i sandboxing
- Tech Leadzi oceniający trade-off bezpieczeństwo vs wydajność startu
- Zespoły migrujące workloady do środowisk multi-tenant (Cloud Run, Fargate, Kubernetes)
Czas czytania: 6 minut
Co to jest cold start kontenera/microVM
Cold start to opóźnienie ponoszone, gdy nowa instancja (kontener, microVM, funkcja serverless) musi zostać uruchomiona od zera — w przeciwieństwie do “warm start”, gdzie istniejąca, wcześniej zainicjalizowana instancja jest ponownie wykorzystywana. W środowiskach serverless i multi-tenant (AWS Lambda, Google Cloud Run, Kubernetes z autoskalowaniem) cold start bezpośrednio wpływa na opóźnienie odpowiedzi pierwszego żądania po skalowaniu do zera lub w górę.
Czas cold startu zależy od tego, co dokładnie trzeba uruchomić: sam proces kontenera (dzielący jądro z hostem) jest zwykle szybszy do wystartowania niż pełna maszyna wirtualna z własnym, minimalnym jądrem gościa (microVM). To fundamentalny trade-off między szybkością a izolacją bezpieczeństwa.
Tabela porównawcza: czasy cold start kontenerów i microVM (2024–2026)
| Technologia | Typ izolacji | Cold start | Źródło |
|---|---|---|---|
| Firecracker (microVM, AWS Lambda/Fargate) | microVM (dedykowane jądro gościa) | <125 ms | Firecracker — oficjalne repo AWS/CNCF (2024) |
| gVisor (sandboxed runtime, Google Cloud Run/GKE) | userspace kernel (przechwytywanie syscalli) | 50–100 ms typowo | gVisor Performance Guide (2024) |
| Kata Containers (VM-based, pełna izolacja) | microVM z pełnym jądrem gościa | 150–300 ms (zależnie od VMM/konfiguracji) | Kata Containers 2.0 — Design & Metrics (2024) |
| containerd / CRI-O / runc (standardowe kontenery Linux) | dzielone jądro hosta | jakościowo: rzędu setek milisekund w testach syntetycznych, silnie zależne od hosta/obciążenia | brak jednego wiarygodnego, powtarzalnego pomiaru — nie podajemy konkretnej liczby |
| Docker vs Podman (rootless/rootful) | dzielone jądro hosta | jakościowo: obie technologie w tej samej klasie wydajności dla typowych obciążeń | źródła publicznie dostępne są ze sobą sprzeczne (raz szybszy Docker, raz Podman, zależnie od konfiguracji) — celowo bez liczb, zgodnie z polityką EITT „zero fabrykowanych metryk” |
Uwaga metodologiczna: liczby w tabeli pochodzą wyłącznie z oficjalnej dokumentacji projektów (Firecracker, gVisor) lub z agregacji oficjalnego repozytorium (Kata Containers — oznaczone jako wiarygodność średnia, bo dokładna wartość zależy od konfiguracji VMM). Tam, gdzie publicznie dostępne testy się kłócą (Docker vs Podman, generyczne containerd/CRI-O/runc), świadomie nie podajemy konkretnej liczby milisekund — to zgodne z zasadą EITT: żadnych własnych, niezweryfikowanych pomiarów ani cytowania sprzecznych źródeł jako pewnika.
Firecracker: poniżej 125 ms — dlaczego tak szybko
Firecracker to open-source’owy monitor maszyn wirtualnych (VMM) stworzony przez AWS, na którym oparte są m.in. AWS Lambda i AWS Fargate. Zamiast emulować pełny sprzęt (jak tradycyjne VM), Firecracker implementuje minimalny, zredukowany model urządzeń — tylko to, co niezbędne do uruchomienia jądra Linux i aplikacji. Efekt: cold start poniżej 125 ms i pamięć narzutu poniżej 5 MiB na microVM (oficjalna dokumentacja projektu).
Dzięki temu jeden host może uruchamiać tysiące izolowanych microVM, każdą z własnym jądrem gościa — co daje izolację bezpieczeństwa zbliżoną do pełnej VM, przy czasie startu bliższym kontenerowi.
gVisor: 50–100 ms i narzut poniżej 1% CPU
gVisor to sandboxed runtime od Google, używany m.in. w Google Cloud Run i GKE Sandbox. Zamiast pełnej wirtualizacji, gVisor implementuje jądro w przestrzeni użytkownika (Sentry), które przechwytuje wywołania systemowe aplikacji i obsługuje je we własnej, izolowanej implementacji — bez bezpośredniego dostępu do jądra hosta.
Wedle oficjalnej dokumentacji Google, 70% aplikacji testowych ma narzut CPU poniżej 1% względem natywnego uruchomienia, a budowa reguł seccomp (część procesu startowego) zajmuje około 10 ms. Typowy cold start mieści się w przedziale 50–100 ms — wolniej niż goły proces kontenera, ale wciąż rząd wielkości szybciej niż pełna maszyna wirtualna.
Kata Containers: 150–300 ms — cena za pełną izolację
Kata Containers łączy interfejs API kontenera (kompatybilny z OCI/Kubernetes CRI) z izolacją pełnej maszyny wirtualnej — każdy kontener działa we własnej, lekkiej VM z dedykowanym jądrem gościa. To najsilniejsza izolacja spośród porównywanych technologii, ale kosztem czasu startu: 150–300 ms w zależności od użytego VMM (QEMU, Cloud Hypervisor, Firecracker jako backend) i konfiguracji.
Kata jest wyborem dla środowisk multi-tenant o podwyższonych wymaganiach bezpieczeństwa (np. uruchamianie niezaufanego kodu klientów w tym samym klastrze Kubernetes), gdzie dodatkowe kilkadziesiąt–kilkaset ms cold startu jest akceptowalnym kosztem za twardą granicę izolacji na poziomie jądra.
Docker vs Podman vs containerd — dlaczego bez twardych liczb
Świadomie NIE publikujemy tu tabeli z konkretnymi milisekundami dla Docker vs Podman vs containerd/CRI-O/runc. Powód: publicznie dostępne testy porównawcze na ten temat są ze sobą sprzeczne — w jednych źródłach szybszy wypada Docker, w innych Podman, z rozbieżnościami sięgającymi kilkukrotności w zależności od trybu (rootless vs rootful), konfiguracji hosta i wersji narzędzia. Żadne z tych źródeł nie spełnia progu wiarygodności, jaki stosujemy dla liczb w tym artykule (oficjalna dokumentacja projektu lub jednoznacznie potwierdzony, powtarzalny benchmark).
Praktyczny wniosek: dla typowych obciążeń produkcyjnych różnice cold startu między Docker, Podman i containerd są zwykle mniej istotne niż wybór architektury (kontener vs microVM) opisany w sekcjach wyżej. Kto potrzebuje pełnego porównania architektonicznego tych trzech runtime’ów (bezpieczeństwo, licencjonowanie, integracja z Kubernetes) — patrz link w sekcji „Przeczytaj również” poniżej.
AWS Lambda: cold start obrazu kontenerowego vs pakiet ZIP
Kontekst serverless zasługuje na osobną wzmiankę. Według oficjalnego bloga AWS Understanding and remediating cold starts: an AWS Lambda perspective (2024), AWS wprowadziło ulepszenia redukujące cold start funkcji pakowanych jako obraz kontenerowy nawet 15-krotnie względem wcześniejszych wersji tego mechanizmu. To pokazuje, że cold start nie jest stałą właściwością technologii, lecz również funkcją optymalizacji platformy hostującej — te same obrazy kontenerowe startują dziś znacząco szybciej niż jeszcze kilka lat temu.
Przeczytaj również
- Docker vs Podman vs containerd – który container runtime wybrać w 2026 — pełne porównanie architektury, bezpieczeństwa i licencjonowania trzech głównych runtime’ów kontenerowych
- Kubernetes w Praktyce: Od Podstaw Architektury do Zarządzania Aplikacjami — jak runtime kontenerowy wpisuje się w szerszą architekturę klastra Kubernetes
Rozwiń kompetencje
Temat tego artykułu jest powiązany ze szkoleniem Docker i Kubernetes: budowa i skalowanie aplikacji kontenerowych. Sprawdź program i zapisz się, aby rozwinąć kompetencje pod okiem ekspertów EITT.
Najczęściej zadawane pytania
Który runtime ma najkrótszy cold start?
Spośród technologii z wiarygodnym, oficjalnie udokumentowanym pomiarem — Firecracker (poniżej 125 ms) i gVisor (50–100 ms) mają najkrótsze, w pełni cytowalne czasy startu. Kata Containers, mimo pełnej izolacji na poziomie VM, potrzebuje zwykle 150–300 ms.
Czym różni się microVM od kontenera pod względem startu?
Kontener dzieli jądro systemu operacyjnego z hostem, więc start sprowadza się do uruchomienia procesu — stąd typowo krótszy czas. MicroVM (Firecracker, Kata Containers) uruchamia osobne, minimalne jądro gościa w izolowanej maszynie wirtualnej, co daje silniejszą izolację bezpieczeństwa kosztem dodatkowego narzutu na starcie.
Czy Docker jest wolniejszy od Podmana przy starcie kontenera?
Publicznie dostępne testy porównawcze Docker vs Podman podają wzajemnie sprzeczne wyniki — w części testów szybszy jest Docker, w innych Podman, w zależności od konfiguracji (rootless vs rootful) i hosta. Bez jednego wiarygodnego, powtarzalnego źródła nie podajemy tu konkretnych liczb — traktujemy to porównanie jako jakościowe.
Czy można poprawić cold start funkcji AWS Lambda pakowanej jako obraz kontenerowy?
Tak — według oficjalnego bloga AWS, platforma wprowadziła optymalizacje redukujące cold start obrazów kontenerowych nawet 15-krotnie względem wcześniejszych wersji mechanizmu. To efekt optymalizacji samej platformy hostującej, nie zmian po stronie aplikacji.