Sierpień 2026: CNCF nadaje status Graduated projektom — Kubeflow i Cloud Native Buildpacks

Sierpień 2026 przyniósł dwa ważne ogłoszenia CNCF: 11 sierpnia status Graduated osiągnęły Cloud Native Buildpacks, a 17 sierpnia — Kubeflow. Oba projekty docierają do najwyższego poziomu dojrzałości w CNCF po latach produkcyjnej adopcji i intensywnego rozwoju społeczności. Razem wysyłają wyraźny sygnał: ekosystem cloud native dorósł poza samą infrastrukturę i dostarcza teraz produkcyjne, neutralne od dostawców podstawy dla pełnego cyklu życia danych i AI.

Co oznacza status Graduated w CNCF

Zanim przejdziemy do szczegółów, warto przypomnieć co graduation faktycznie oznacza. CNCF definiuje trzy poziomy dojrzałości: Sandbox (wczesny etap), Incubating (rosnąca adopcja) i Graduated (produkcyjna dojrzałość).

Graduated to najwyższy poziom. Aby go osiągnąć, projekt musi spełnić rygorystyczne wymagania: przeprowadzić niezależny audyt bezpieczeństwa przez zewnętrzną firmę, udowodnić szeroką produkcyjną adopcję przez niezależne organizacje, ustanowić formalny komitet sterujący z przejrzystym zarządzaniem i przyjąć Kodeks Postępowania CNCF.

Projekty na poziomie Graduated to Kubernetes, Prometheus, Envoy, Argo, Flux — fundament ekosystemu cloud native. Kubeflow i Cloud Native Buildpacks dołączają do tego grona.

Kubeflow — Kubernetes jako platforma kontrolna dla AI

Historia projektu

Dziewięć lat temu Jeremy Lewi, Vishnu Kannan i David Aronchick przygotowali szalone demo z hot dogami i Kubernetes, i tak narodził się Kubeflow — powiedział współzałożyciel projektu podczas ogłoszenia graduacji.

Kubeflow powstał w Google w 2017 roku jako wewnętrzne narzędzie do uruchamiania pipeline'ów TensorFlow na Kubernetes. Szybko przyciągnął uwagę społeczności i stał się projektem open source. Kubeflow dołączył do CNCF 25 lipca 2023 roku na poziomie Incubating i przeszedł na poziom Graduated 24 lipca 2026. Publiczne ogłoszenie CNCF nastąpiło 17 sierpnia.

Co Kubeflow robi

Kubeflow standaryzuje pełny cykl życia AI i ML — od przetwarzania danych i interaktywnego tworzenia, przez rozproszony trening, dostrajanie (fine-tuning), wnioskowanie i obsługę modeli — w środowiskach chmury publicznej, prywatnej i hybrydowej.

W praktyce Kubeflow składa się z kilku zintegrowanych komponentów:

Kubeflow Pipelines — orkiestracja wieloetapowych przepływów ML jako DAG-ów (directed acyclic graphs). Każdy krok pipeline'u uruchamiany jest jako kontener Kubernetes, co zapewnia pełną reprodukowalność eksperymentów i możliwość śledzenia każdego uruchomienia.

Kubeflow Trainer — rozproszony trening modeli z natywnym wsparciem dla PyTorch, TensorFlow i JAX, z automatycznym zarządzaniem węzłami GPU i elastycznym skalowaniem workload'ów treningowych.

KServe (wcześniej KFServing) — serwowanie modeli w produkcji z autoskalowaniem do zera, kanarkowym wdrażaniem i obsługą wielu framework'ów jednocześnie.

Katib — automatyczne strojenie hiperparametrów (AutoML) z algorytmami Bayesian optimization, grid search i random search.

Notebooks — serwer zarządzający Jupyter Notebooks uruchomionymi bezpośrednio w klastrze Kubernetes, z dostępem do GPU i trwałym przechowywaniem danych.

Projekt współpracuje z technologiami CNCF takimi jak Prometheus do monitorowania, KServe, Feast i Kueue do kolejkowania zadań oraz Istio do bezpiecznej komunikacji między usługami.

Dlaczego ta graduacja jest ważna — i co mówi o Kubernetes

Graduacja Kubeflow to nie dowód, że Kubernetes jest idealnym środowiskiem uruchomieniowym dla AI. To znaczący głos, że Kubernetes może stać się wspólną płaszczyzną sterowania, przez którą przedsiębiorstwa budują, eksploatują, zabezpieczają i zarządzają produkcyjnym AI.

Workload'y AI nie pasują naturalnie do systemu zaprojektowanego pierwotnie do orkiestracji konteneryzowanych aplikacji. Wymagają planowania świadomego akceleratorów (GPU, TPU), zarządzania dużymi wolumenami danych treningowych, długotrwałych zadań z punktami kontrolnymi i obsługi wnioskowania o zmiennym obciążeniu. Kubeflow dostarcza te możliwości jako warstwa natywna dla Kubernetes — zamiast oddzielnych, wyspecjalizowanych platform ML.

Jako jeden z pierwszych projektów natywnych dla AI osiągających status Graduated, Kubeflow wyznacza punkt przełomowy dla portfolio AI w CNCF, bo ekosystem cloud native dorósł poza samą infrastrukturę i dostarcza teraz produkcyjne, neutralne od dostawców podstawy dla pełnego cyklu życia danych i AI.

Roadmap

Nadchodzący roadmap Kubeflow skupia się na rozszerzeniu orkiestracji dużych modeli językowych (LLM), ulepszeniu możliwości po-treningowych z dostrajaniem, inżynierii danych na dużą skalę i agentycznych workloadach dla cyklu życia danych i AI.

Dla środowisk AKS

Azure Kubernetes Service ma natywną integrację z Azure Machine Learning, który sam wewnętrznie używa komponentów Kubeflow do orkiestracji pipeline'ów ML. Graduacja Kubeflow w CNCF to sygnał, że inwestycja w Kubernetes jako platformę ML jest bezpieczna długoterminowo — niezależnie od dostawcy chmury.

Cloud Native Buildpacks — koniec z ręcznym pisaniem Dockerfile'ów

Historia projektu

Zakorzeniony w modelu buildpack'ów Heroku, następnie szerzej przyjęty przez Cloud Foundry, Cloud Native Buildpacks zostały wspólnie stworzone przez Pivotal i Heroku w styczniu 2018 roku i dołączyły do CNCF w październiku 2018.

Projekt przeszedł długą drogę od narzędzia jednej platformy do ujednoliconej specyfikacji zgodnej z OCI. Społeczność projektu urosła do 535 kontrybutorów z 164 organizacji i rozszerzającej się bazy ponad 20 użytkowników, w tym DigitalOcean, GitLab, Google, HashiCorp, Spring i VMware.

Co to jest i jak działa

Cloud Native Buildpacks (CNB) to narzędzie przekształcające kod źródłowy aplikacji bezpośrednio w obrazy kontenerów zgodne z OCI — bez pisania Dockerfile'a.

Tradycyjne podejście z Dockerfile wymaga od każdego zespołu samodzielnego definiowania środowiska budowania, zarządzania obrazami bazowymi i obsługi zależności systemowych. Każda aplikacja ma własny Dockerfile, każdy Dockerfile może mieć własne podatności, każda aktualizacja wymaga modyfikacji dziesiątek plików w dziesiątkach repozytoriów.

CNB odwraca ten model: platforma (buildpack) automatycznie wykrywa język i framework aplikacji, instaluje zależności i buduje obraz według standaryzowanego procesu. Zmiana buildpack'a — na przykład by zaktualizować wersję Node.js lub usunąć podatność w OpenSSL — automatycznie dotyczy wszystkich aplikacji korzystających z tego buildpack'a, bez modyfikowania pojedynczych repozytoriów.

W dużych implementacjach w sektorze finansowym obejmujących ponad 500 aplikacji, zespoły skróciły czas rozwiązywania podatności z tygodni do godzin dzięki scentralizowanym łatkom buildpack'ów.

Dlaczego to ma znaczenie dla DevSecOps

Scentralizowane zarządzanie obrazami bazowymi to bezpośrednia odpowiedź na jeden z największych problemów DevSecOps: fragmentacja Dockerfile'ów prowadząca do nierównej jakości zabezpieczeń między zespołami.

Gdy pojawia się krytyczna podatność w warstwie systemu operacyjnego (jak podatności opisywane co miesiąc przez CNCF i Red Hat), organizacje używające CNB mogą zaktualizować buildpack w jednym miejscu i przebudować wszystkie obrazy. Organizacje używające ręcznie zarządzanych Dockerfile'ów muszą śledzić każde repozytorium osobno.

Cloud Native Buildpacks przeszły niezależny audyt bezpieczeństwa przeprowadzony przez Quarkslab i OSTIF i otrzymały odznakę OpenSSF Best Practices. To standardowy wymóg dla projektów CNCF Graduated — i ważny sygnał dla organizacji z wymaganiami regulacyjnymi.

Integracja z ekosystemem

Projekt współpracuje z dodatkowymi projektami CNCF, takimi jak Helm i Harbor, produkując obrazy kontenerów zgodne z OCI gotowe do wdrożenia na Kubernetes.

Praktyczne integracje dostępne już dziś: pack CLI dla lokalnego budowania, kpack dla budowania napędzanego przez Kubernetes (automatyczne przebudowy przy aktualizacji buildpack'a lub kodu), integracja z Tekton Pipelines i dostępność jako krok w GitHub Actions i GitLab CI.

Roadmap

Nadchodzący roadmap projektu skupia się na rozszerzeniu wsparcia dla artefaktów OCI, wzmocnieniu przepływów pracy z zestawieniami materiałów oprogramowania (SBOM) i ulepszeniu kompatybilności z formatami workloadów następnej generacji, w tym WebAssembly.

Wsparcie SBOM jest szczególnie ważne w kontekście wymagań regulacyjnych i ataków na łańcuch dostaw — CNB z natury generuje powtarzalne, weryfikowalne obrazy z pełną widocznością co się w nich znajduje.

Dwa projekty, jeden kierunek

Dwie sierpniowe graduacje CNCF są pozornie niezwiązane — jedna dotyczy AI/ML, druga budowania kontenerów. Łączy je jednak wspólna logika: oba projekty odpowiadają na problem standaryzacji w środowiskach z dużą liczbą aplikacji i zespołów.

Kubeflow standaryzuje sposób uruchamiania workload'ów AI na Kubernetes — zamiast każdej organizacji budującej własne skrypty i orkiestratory. Cloud Native Buildpacks standaryzują sposób budowania obrazów kontenerów — zamiast każdego zespołu utrzymującego własne Dockerfile.

Graduacja w CNCF oznacza, że oba projekty przeszły przez pełny cykl weryfikacji: audyt bezpieczeństwa, dowód szerokiej produkcyjnej adopcji i zarządzanie gotowe na długoterminowe utrzymanie. To nie marketing — to weryfikowalne kryteria, które CNCF egzekwuje przed nadaniem najwyższego statusu.

Dla zespołów DevOps i Platform Engineering wybierających technologie na kolejne lata: Kubeflow i Cloud Native Buildpacks są teraz na tym samym poziomie dojrzałości co Kubernetes, Prometheus i Argo. Inwestycja w te projekty jest bezpieczna długoterminowo.