Można zamawiać już teraz · Nowy Jork
Upstreamowy Kubernetes, zbudowany na RKE2, gdzie serwer API, scheduler i etcd są po naszej stronie do obsługi, a każdy węzeł roboczy to dedykowany serwer, który od nas wynajmujesz. Żadnego hypervisora pod Twoimi podami, żadnego sąsiada na Twoich rdzeniach, a na każdym węźle zachowujesz root SSH, konsolę i tryb ratunkowy.
Masz pytania przed zamówieniem? . Nasza AI odpowiada w kilka sekund i może sprawdzić Twoje konto oraz serwery; inżynier przejmuje rozmowę, kiedy tylko poprosisz. Nie masz czatu? Napisz do nas ze strony kontaktowej.
Podział obowiązków
Wiele zarządzanych usług Kubernetes trzyma węzły poza Twoim zasięgiem. Tutaj granica przebiega na płaszczyźnie sterowania: wszystko powyżej to nasze zadanie, każda maszyna poniżej pozostaje Twoja.
Dlaczego pracownicy to bare metal
Pod na maszynie wirtualnej w chmurze działa na jądrze gościa na szczycie jądra hosta. Na dedykowanym węźle jest jedno jądro, bezpośrednio na sprzęcie, więc wynajmowane rdzenie i pamięć trafiają do Twoich podów, a nie do drugiego systemu operacyjnego pod nimi.
Żadne obce obciążenie nie współdzieli maszyny, jej dysków ani przepustowości pamięci. Benchmark uruchomiony w poniedziałek nie zostaje zniweczony przez czyjeś zadanie wsadowe w piątek.
Serwery worker są rozliczane ryczałtowo miesięcznie, bez opłaty za każdy gigabajt opuszczający klaster. Obsługa ruchu nie zamienia się w drugą fakturę.
Kubernetes to otwartoźródłowy projekt CNCF na licencji Apache 2.0, a RKE2 uruchamia go w wersji upstream. Manifesty działające tutaj działają na każdym zgodnym klastrze, więc odejście kosztuje Cię migrację, a nie przepisywanie od nowa.
Stos
| Warstwa | Czym jest |
|---|---|
| Dystrybucja | RKE2, upstream'owy Kubernetes zgodny z CNCF |
| Warstwa sterowania | Obsługiwana przez nas: 1 węzeł dla środowiska deweloperskiego, 3 węzły dla wysokiej dostępności |
| Stan klastra | Wbudowany etcd, snapshoty co 6 godzin |
| Węzły robocze | Serwery dedykowane na Twoim koncie, wybierane pojedynczo z zasobów w Nowym Jorku i brane w stanie, w jakim są, już z Ubuntu 24.04 lub 26.04 (bez ponownej instalacji, bez opłaty instalacyjnej); od 1 do 10 na zamówienie, kolejne dodawane później, do 10 |
| Harmonogramowanie | Jedna pula, każdy węzeł oznaczony etykietą pool=general; dalsze etykiety i tainty ustawiasz sam za pomocą kubectl (cluster-admin) |
| Sieć podów | Cilium z egzekwowaniem Kubernetes NetworkPolicy; brak szyfrowania między węzłami, więc tam, gdzie ruch musi być szyfrowany, stosuj TLS lub mTLS w aplikacjach albo service mesh |
| Load balancery | MetalLB: Service typu LoadBalancer otrzymuje jeden z dodatkowych adresów IPv4 na Twoich serwerach roboczych |
| Sieć węzłów | Publiczne adresy węzłów z firewallem dopuszczającym wyłącznie węzły należące do klastra; brak prywatnego VLAN-u |
| Dostęp | Pobranie kubeconfig; root SSH, konsola i tryb ratunkowy na każdym węźle roboczym |
| Aktualizacje | Uruchamiane przez Ciebie; najpierw warstwa sterowania, potem węzły pojedynczo |
| Lokalizacja | Nowy Jork |
Tak skonstruowany jest każdy klaster, który budujemy w Nowym Jorku. Jeśli jakaś warstwa się zmieni, ta tabela zmieni się razem z nią.
Węzły robocze
Zamówienie obejmuje od 1 do 10 serwerów roboczych, każdy wybierany spośród maszyn w Nowym Jorku gotowych od ręki, a panel może później dodać kolejne — łącznie do 10. Każdy węzeł trafia do jednej puli i otrzymuje etykietę pool=general. Masz uprawnienia cluster-admin, więc oddzielenie maszyn GPU od warstwy webowej to zaledwie jedno polecenie kubectl label i jedno kubectl taint.
pool=general możesz ustawiać dowolnie; nie narzucamy własnych reguł planowania$ kubectl label node k8s-250123-w3 gpu=true
$ kubectl taint node k8s-250123-w3 gpu=true:NoSchedule
apiVersion: v1
kind: Pod
metadata: name: inference
spec: nodeSelector: gpu: "true" tolerations: - key: gpu operator: Exists effect: NoSchedule containers: - name: model image: ghcr.io/example/model:1.0Pytania
Zarządzana. Prowadzimy warstwę kontrolną, w tym etcd i jej migawki, i przeprowadzamy aktualizacje, gdy je rozpoczniesz. Twoje serwery dedykowane dołączają do klastra jako węzły robocze, a Ty nigdy nie musisz samodzielnie obsługiwać warstwy kontrolnej.
RKE2, dystrybucji zgodnej z CNCF, która dostarcza natywny Kubernetes. Twoje manifesty, wykresy Helm i operatory działają tak, jak na każdym innym zgodnym klastrze.
Tak. Każdy węzeł roboczy to serwer dedykowany na Twoim koncie, z root SSH, konsolą i trybem ratunkowym, dokładnie tak, jak gdyby nie był częścią klastra. To główna różnica w porównaniu z większością zarządzanych Kubernetesów, gdzie węzły są często dla Ciebie zamknięte.
MetalLB przypisuje im dodatkowe adresy IPv4 na Twoich serwerach roboczych, więc adres przed Twoją usługą to ten, który już posiadasz, a nie ten, który pożyczamy ze wspólnej puli.
Nie, nie ma prywatnego VLAN-u dla klastra. Węzły komunikują się ze sobą po adresach publicznych w naszej sieci, a zapora na każdym węźle dopuszcza tylko węzły należące do klastra. Ruch między węzłami nie jest szyfrowany przez klaster: polityki sieciowe Cilium kontrolują, które pody mogą się komunikować, a do szyfrowanego ruchu między usługami używaj TLS lub mTLS w swoich aplikacjach albo service mesh.
Tak. Każdy serwer roboczy wybierasz spośród maszyn w Nowym Jorku dostępnych od ręki, więc serwery GPU i CPU mogą dołączyć do tego samego klastra. Wszystkie startują w jednej puli oznaczonej pool=general; z uprawnieniami cluster-admin sam etykietujesz i oznaczasz węzły GPU, a obciążenia wybierają między nimi za pomocą selektorów węzłów i toleracji.
Ty decydujesz kiedy. Najpierw aktualizujemy warstwę kontrolną, potem węzły robocze pojedynczo, dzięki czemu obciążenie uruchomione w więcej niż jednej replice nadal obsługuje ruch, podczas gdy klaster przechodzi na nową wersję.
Tak, w Nowym Jorku. Na stronie zamówienia wybierasz warstwę kontrolną Dev lub HA oraz od jednego do dziesięciu serwerów roboczych spośród maszyn w Nowym Jorku dostępnych od ręki; klaster jest budowany po opłaceniu pierwszych faktur, a jego kubeconfig czeka w Twoim panelu.
Wybierz płaszczyznę sterowania, nazwij klaster i wskaż od jednego do dziesięciu serwerów roboczych. Serwery robocze dostajesz dokładnie w takiej konfiguracji, w jakiej są na stanie, już z Ubuntu 24.04 lub 26.04, więc nie ma opłaty instalacyjnej i dołączają od razu po dostarczeniu, gdy tylko ich pierwsze faktury zostaną opłacone; kubeconfig pojawia się w panelu, gdy klaster zgłosi gotowość.
Wolisz samodzielnie uruchomić Kubernetesa? Zobacz serwery dedykowane pod kontenery. Potrzebujesz jednej małej maszyny zamiast klastra? Cloud VPS to wirtualna maszyna KVM; strona serwerów dedykowanych zawiera listę maszyn, którymi może być serwer roboczy.