8 lipca 2026 zespół SIG etcd ogłosił wydanie etcd v3.7.0, czyli nowej wersji rozproszonego magazynu klucz-wartość, który w praktyce jest sercem control plane większości klastrów Kubernetes. To nie jest kosmetyczna aktualizacja biblioteki schowanej pod spodem. Wersja 3.7 wprowadza RangeStream, zmiany obniżające zużycie CPU i pamięci, nowe metryki dla ścieżki watch, obsługę endpointów przez Unix socket oraz definitywne sprzątanie po starym v2store. Dla administratora Linuksa i platform engineerów oznacza to dwie rzeczy naraz: realną szansę na lżejszy control plane oraz konieczność bardziej rygorystycznego przygotowania upgrade’u.
etcd jest często niewidoczny do momentu awarii. Gdy API server zaczyna odpowiadać wolniej, gdy watch’e robią się kosztowne, gdy baza rośnie szybciej niż przewidziano, albo gdy rolling update masterów blokuje się na jednym węźle, nagle okazuje się, że kondycja trzech lub pięciu procesów etcd decyduje o jakości całej platformy. Dlatego etcd 3.7 warto traktować nie jako „kolejną paczkę do podbicia”, ale jako zmianę w warstwie krytycznej infrastruktury.
Co dokładnie wydarzyło się 8 lipca 2026
Wydanie etcd 3.7.0 zostało opublikowane 8 lipca 2026 jako nowa wersja minor. Lista najważniejszych zmian jest konkretna: RangeStream, optymalizacja zapytań typu keys-only, szybsze i stabilniejsze leases, przebudowa zależności protobuf, start wyłącznie z v3store, bbolt 1.5.1, raft 3.7.0, dodatkowe metryki i obsługa Unix socket endpointów. W świecie Kubernetes szczególnie ważne jest to, że RangeStream ma być dostępny dla użytkowników nadchodzącego Kubernetes v1.37 przez feature gate EtcdRangeStream. Zapowiedź Kubernetes v1.37 z 31 lipca 2026 wskazuje planowaną datę wydania tej wersji na 26 sierpnia 2026, więc administratorzy mają sensowne okno na testy w stagingu przed pojawieniem się tej funkcji w szerszym użyciu.
Najbardziej medialna funkcja, RangeStream, rozwiązuje bardzo praktyczny problem. W etcd 3.6 i starszych wersjach duże odczyty zakresowe były buforowane jako pełny wynik przed wysłaniem odpowiedzi. Przy dużej liczbie obiektów Kubernetes, rozbudowanych CRD albo ciężkich operatorach oznaczało to nieprzewidywalne skoki pamięci i opóźnień po stronie serwera oraz klienta. RangeStream pozwala aplikacjom odbierać wynik partiami. To brzmi jak detal implementacyjny, ale dla dużych klastrów może oznaczać mniej ostrych pików RAM, krótszy czas oczekiwania na pierwsze dane i mniejsze ryzyko, że pojedynczy szeroki odczyt zaburzy pracę pozostałych klientów.
Dlaczego to ważne dla administratorów Linuksa
etcd jest procesem użytkowym, ale jego zachowanie bardzo mocno zależy od klasycznych elementów administracji Linuksem: dysku, sieci, limitów plików, harmonogramowania CPU, pamięci i obserwowalności przez Prometheusa. Wersja 3.7 dotyka kilku z tych obszarów bezpośrednio.
- Mniej zbędnych odczytów z backendu — optymalizacja
keys_onlypowoduje, że przy zapytaniach o same klucze etcd może korzystać z indeksu w pamięci zamiast ładować wartości z bbolt, z wyjątkiem sortowania po wartości. - Stabilniejsze leases — priorytetyzacja
LeaseRevokei szybszyFastLeaseKeepAlivemają znaczenie dla komponentów, które intensywnie używają TTL, blokad i mechanizmów koordynacji. - Nowe metryki watch — łatwiej odróżnić problem w API serverze od problemu w ścieżce watch w samym etcd.
- Unix socket endpoints — przydatne w środowiskach testowych, developerskich i edge, gdzie lokalna komunikacja bez wystawiania portu TCP upraszcza izolację.
- Koniec legacy v2store — mniej długu technicznego, ale też większe ryzyko dla starych integracji, które nie zostały poprawnie zmigrowane.
Najbardziej linuksowy element tej układanki to Unix socket support. Nie jest to funkcja dla typowego, produkcyjnego, trzywęzłowego klastra etcd używanego przez Kubernetes. Dokumentacja i ogłoszenie wskazują raczej scenariusze single-member, development, testing i edge. Mimo to jest to ważny sygnał: etcd nadal dostaje funkcje przydatne dla administratorów, którzy chcą ograniczać powierzchnię sieciową i trzymać lokalne usługi za uprawnieniami plików oraz politykami systemowymi zamiast wystawiać je na interfejs TCP.
Największa zmiana operacyjna: upgrade nie wybacza długu technicznego
etcd 3.7 usuwa pozostałości v2store i stare komponenty v2. Znikają m.in. v2 HTTP API, emulacja v2-on-v3, v2 discovery service, pakiet client/v2 oraz ładowanie snapshotów v2. Jeżeli klaster był utrzymywany zgodnie z cyklem 3.6, problem powinien być ograniczony. Jeżeli jednak w organizacji istnieją stare narzędzia, skrypty lub integracje pamiętające etcd v2, ta wersja wymusza porządki.
Oficjalna ścieżka aktualizacji z v3.6 do v3.7 mówi jasno: działający klaster musi mieć wersję 3.6.11 lub nowszą, a upgrade należy wykonywać tylko o jedną wersję minor naraz. To ważne, bo w wielu środowiskach etcd jest aktualizowany przy okazji podnoszenia Kubernetes albo dystrybucji klastra, więc administratorzy mogą nawet nie zauważyć, że przeskakują kilka warstw zależności. W produkcji nie należy tego robić „przy okazji”. Najpierw trzeba potwierdzić wersje, zdrowie klastra i snapshot.
export ETCDCTL_API=3
export ENDPOINTS=https://etcd-1:2379,https://etcd-2:2379,https://etcd-3:2379
etcdctl --endpoints=${ENDPOINTS} \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \
--key=/etc/kubernetes/pki/etcd/healthcheck-client.key \
endpoint status -w table
etcdctl --endpoints=${ENDPOINTS} \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \
--key=/etc/kubernetes/pki/etcd/healthcheck-client.key \
endpoint healthPrzed wymianą binarek albo obrazów kontenerów warto też jawnie poszukać starych flag --experimental-*. W etcd 3.7 usunięto zdeprecjonowane flagi eksperymentalne, a model funkcji został dopasowany do cyklu feature gates znanego z Kubernetes. Jeżeli konfiguracja systemd, manifest statycznego poda lub Helm chart nadal zawiera takie przełączniki, proces etcd 3.7 może po prostu nie wystartować. To jest typ awarii, który najlepiej wykryć przez prosty grep w repozytorium infrastruktury, a nie w oknie serwisowym.
grep -R --line-number -- '--experimental-' \
/etc/systemd/system /etc/kubernetes/manifests ./infra ./clusters 2>/dev/null
# Minimalny snapshot przed oknem serwisowym:
etcdctl --endpoints=${ENDPOINTS} \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \
--key=/etc/kubernetes/pki/etcd/healthcheck-client.key \
snapshot save etcd-pre-3.7-$(date +%F).dbRolling upgrade: mieszane wersje są dozwolone, ale tylko tymczasowo
Dokumentacja upgrade’u podkreśla, że przejście z etcd 3.6 do 3.7 może być rolling upgrade’em bez przestoju: zatrzymujesz jeden proces 3.6, zastępujesz go 3.7, sprawdzasz zdrowie i przechodzisz do kolejnego członka klastra. W stanie mieszanym klaster działa protokołem najniższej wspólnej wersji i uznaje się go za w pełni zaktualizowany dopiero po podniesieniu wszystkich memberów do v3.7. To daje możliwość cofnięcia binarki w trakcie migracji, ale tylko dopóki co najmniej jeden member pozostaje na 3.6.
Po aktualizacji wszystkich memberów rollback przez samo podstawienie starej binarki nie jest już właściwą ścieżką. Wtedy zostaje odtworzenie snapshotu sprzed upgrade’u albo formalna procedura downgrade. Z punktu widzenia administratora oznacza to, że snapshot nie jest „dobrą praktyką”, tylko elementem planu powrotu. Powinien być zapisany poza hostem, przetestowany przez etcdutl snapshot status i opisany w runbooku razem z kolejnością przywracania.
Observability: na co patrzeć po aktualizacji
etcd 3.7 dodaje m.in. metryki dotyczące pętli wysyłania watch oraz nową metrykę etcd_server_request_duration_seconds. W praktyce warto po upgrade’ie obserwować kilka klas sygnałów: latency zapytań, liczbę aktywnych watch’y, rozmiar bazy, fsync latency, wybory lidera, liczbę proposal failures i użycie CPU per member. Jeżeli w klastrze są agresywne operatory albo dużo CRD, szczególnie interesujące będą zmiany na ścieżce watch oraz zachowanie szerokich odczytów.
Nie należy jednak zakładać, że sam upgrade rozwiąże każdy problem wydajnościowy control plane. Jeżeli etcd stoi na wolnych dyskach sieciowych, ma zbyt wysoki RTT między memberami albo jest współdzielony z innymi obciążeniami I/O, nowa wersja nie zastąpi poprawnej architektury. Optymalizacje w 3.7 pomagają, ale nadal wymagają zdrowego fundamentu: szybkiego storage, przewidywalnej sieci i sensownej liczby memberów.
Wpływ na Kubernetes v1.37 i planowanie zmian
Zapowiedź Kubernetes v1.37 z 31 lipca 2026 jest istotna, bo pokazuje szerszy kierunek: control plane Kubernetes staje się bardziej zależny od nowoczesnych mechanizmów Linuksa i nowszych wersji komponentów bazowych. W tym samym materiale pojawiają się m.in. dalsze zmiany wokół cgroup v1, SELinux volume relabeling oraz rootless kubelet w Linux user namespaces. Na tym tle etcd 3.7 wpisuje się w trend: mniej kompatybilności z historycznym długiem, więcej nacisku na przewidywalność, metryki i nowsze mechanizmy systemowe.
Dla zespołów utrzymujących klastry najlepszy moment na przygotowania to nie dzień wydania Kubernetes v1.37, lecz okres przed nim. Jeżeli używasz kubeadm, Ranchera, Talosa, OpenShift, K3s, RKE2 albo zarządzanej usługi cloud, sprawdź, kiedy dana dystrybucja planuje przejście na etcd 3.7 i czy pozwala wpływać na kolejność upgrade’u. W managed Kubernetes część pracy wykona dostawca, ale monitoring, testy obciążeń, weryfikacja CRD i ocena wpływu na operatory pozostają po stronie użytkownika platformy.
Praktyczne podsumowanie
etcd 3.7.0 z 8 lipca 2026 warto potraktować jako technicznie ważne wydanie dla całego ekosystemu Kubernetes na Linuksie. Przynosi RangeStream, mniej kosztowne odczyty keys-only, lepsze leases, nowe metryki, Unix sockety i porządki po v2store. Przed aktualizacją upewnij się, że wszystkie membery są na etcd 3.6.11 lub nowszym, usuń stare flagi eksperymentalne, wykonaj snapshot, przetestuj upgrade w stagingu i monitoruj watch latency oraz request duration po wdrożeniu. To aktualizacja z potencjalnym zyskiem wydajnościowym, ale tylko dla zespołów, które potraktują ją jak zmianę w warstwie krytycznej, a nie zwykłe podbicie wersji obrazu.
