Klastry Kubernetes w centrach danych Tier III w EU z opcjami single-node i HA
Kubernetes na jednym węźle, preinstalowany przy pierwszym uruchomieniu, bez niespodzianek!
Infrastruktura klasy korporacyjnej z gwarancją 99,9% dostępności w lokalizacjach UE
Uruchom swoje serwery i zasoby online w ciągu godzin, nie dni. Bez opłaty za instalację
Możesz rozszerzyć lub zmniejszyć swój serwer cloud online używając panelu osobistego na naszej stronie internetowej
Wybierasz rozmiary węzłów, a klaster zostaje zbudowany i przekazany gotowy do pracy: control plane, runtime kontenerów, sieć CNI, kontroler ingress i storage class oparta na tym samym NVMe, którego używa każda inna maszyna tutaj. Kubeconfig pobierzesz z panelu w chwili, gdy klaster wstanie.
To prawdziwy klaster na prawdziwych maszynach wirtualnych w naszych centrach danych, a nie zarządzana abstrakcja nad czyimś API. kubectl, Helm i wszystko, co rozmawia z API Kubernetesa, działa dokładnie tak jak wszędzie indziej, bo pośrodku nie ma niczego niestandardowego.
Wyjdź od tego, co ma działać na klastrze, a nie od liczby węzłów. Zsumuj żądania CPU i pamięci wszystkiego, co zamierzasz uruchomić, dodaj narzut control plane i podów systemowych, a potem zostaw taki zapas, żeby jeden węzeł mógł paść, a pozostałe nie odmówiły przyjęcia jego podów.
Trzy małe węzły zwykle biją jeden duży, gdy tylko zależy Ci na ciągłości, bo pojedynczy węzeł dzieli od przestoju jeden restart. Do developmentu i CI jeden węzeł wystarcza i wychodzi znacznie taniej.
Płacisz za węzły - w tych samych cenach CPU, RAM i NVMe co każdy serwer cloud - plus niewielka stała opłata za zarządzanie samym klastrem. Klastry Kubernetes zaczynają się od 22 EUR miesięcznie.
Oznacza to, że klaster nigdy nie jest w tajemniczy sposób droższy niż maszyny, z których się składa, a jego skalowanie to ta sama arytmetyka co skalowanie czegokolwiek innego tutaj.
Zestawy mikroserwisów, które wyrosły z pojedynczego hosta Dockera, aplikacje wymagające wdrożeń kroczących bez okna serwisowego oraz obciążenia CI lub agentów, które chcą się rozrosnąć, a potem zniknąć.
Samodzielnie hostowane runnery CI to częste połączenie: klaster daje im miejsce, w które mogą się rozlać, i trzyma artefakty builda oraz kod źródłowy we własnej europejskiej infrastrukturze.
Jeśli chcesz zbudować klaster samodzielnie - konkretna dystrybucja, określony CNI, nietypowa topologia - zamów zwykłe serwery cloud i potraktuj je jak węzły. Nic Ci tu nie przeszkadza, a maszyny są identyczne.
Wybierz wariant zarządzany, gdy wolisz nie spędzać pierwszego tygodnia nad control plane i gdy działający ingress oraz storage class pierwszego dnia są warte więcej niż samodzielny dobór każdego komponentu.
Węzły można dodawać i zmieniać ich rozmiar wraz ze zmianą zapotrzebowania, tak samo jak serwer cloud. Aktualizacje klastra są uzgadniane z Tobą, a nie wykonywane pod Tobą, bo wersja minor Kubernetesa to zmiana API, którą coś w Twoich manifestach zwykle zauważa.
Migracja to głównie praca na manifestach: skierować Helma na nowy klaster, odtworzyć wolumeny trwałe z własnych kopii, a potem przełączyć DNS, gdy nowy ingress zacznie odpowiadać poprawnie.
Często zadawane pytania
Działający klaster Kubernetes na maszynach wirtualnych w naszym własnym centrum danych: control plane, runtime kontenerów, sieć CNI, kontroler ingress i domyślna storage class oparta na NVMe. Kubeconfig pobierzesz z panelu, gdy tylko klaster wstanie
Jeden węzeł wystarcza do developmentu, CI i wszystkiego, co możesz stracić na czas restartu. Wiele węzłów wybierz w chwili, gdy awaria zaczyna mieć znaczenie: przy trzech węzłach klaster może stracić jeden i przenieść jego pody na dwa pozostałe
Pobierz kubeconfig z panelu zarządzania i wskaż go kubectl albo Helmowi. Nic nie jest opakowane ani przepuszczone przez proxy - to standardowy endpoint API Kubernetesa, więc każde narzędzie rozmawiające z Kubernetesem działa bez zmian
Płacisz za węzły w tych samych stawkach CPU, RAM i NVMe co za dowolny serwer cloud, plus niewielka stała opłata za zarządzanie samym klastrem. Skalowanie klastra kosztuje dokładnie tyle, ile kosztowałoby dodanie odpowiadających mu serwerów
Tak. Węzły można dodawać, usuwać i zmieniać ich rozmiar wraz ze zmianą zapotrzebowania, tak samo jak każdy serwer cloud: dysk rośnie w locie, a zmiany CPU i RAM wymagają jedynie restartu tego węzła
Aktualizacje są uzgadniane z Tobą, a nie wykonywane pod Tobą. Wersja minor Kubernetesa to zmiana API, a w prawdziwym zestawie manifestów zwykle coś to zauważa, więc ustalamy okno i możesz wcześniej przetestować
Tak, a maszyny są identyczne - zamów serwery cloud i potraktuj je jak węzły, jeśli chcesz konkretną dystrybucję, CNI albo topologię. Wariant zarządzany istnieje po to, żeby działający ingress i storage class pierwszego dnia były problemem kogoś innego
Jeśli potrzebujesz pomocy lub masz dodatkowe pytania, skontaktuj się z menedżerami lub napisz do zespołu wsparcia pod adresem support@dcxv.com
