Witamy w naszej serii Kubernetes Szybki start. To stała rubryka z najciekawszymi pytaniami, jakie otrzymujemy online i na naszych szkoleniach. Odpowiedzi ekspertów Kubernetes.
Dzisiejszym ekspertem jest Daniel Polenchik (). Daniel pracuje jako instruktor i programista w firmie .
Jeżeli chcesz uzyskać odpowiedź na swoje pytanie w kolejnym poście, lub .
Przegapiłeś poprzednie posty? .
Jak połączyć klastry Kubernetes w różnych centrach danych?
Krótko: , a także polecam poczytać o и .
Dość często infrastruktura jest replikowana i dystrybuowana w różnych regionach, zwłaszcza w kontrolowanych środowiskach.
Jeśli jeden region jest niedostępny, ruch jest przekierowywany do innego, aby uniknąć przerw.
Dzięki Kubernetes możesz zastosować podobną strategię i dystrybuować obciążenia w różnych regionach.
Na zespół, region, środowisko lub kombinację tych elementów można utworzyć jeden lub więcej klastrów.
Twoje klastry mogą być hostowane w różnych chmurach i lokalnie.
Ale jak zaplanować infrastrukturę pod kątem takiego rozmieszczenia geograficznego?
Czy potrzebujesz utworzyć jeden duży klaster dla kilku środowisk chmurowych w ramach jednej sieci?
A może masz wiele małych klastrów i szukasz sposobu na ich kontrolowanie i synchronizację?
Jeden klaster przywódczy
Utworzenie jednego klastra w ramach jednej sieci nie jest takie proste.
Wyobraź sobie, że masz wypadek i łączność między segmentami klastra zostaje utracona.
Jeśli masz jeden serwer główny, połowa zasobów nie będzie mogła otrzymać nowych poleceń, ponieważ nie będzie mogła skontaktować się z serwerem głównym.
A jednocześnie masz stare tablice routingu (kube-proxy nie można pobrać nowych) i żadnych dodatkowych podów (kubelet nie może żądać aktualizacji).
Co gorsza, jeśli Kubernetes nie widzi węzła, oznacza go jako osierocony i dystrybuuje brakujące pody do istniejących węzłów.
W rezultacie masz dwa razy więcej strąków.
Jeśli utworzysz jeden serwer główny dla każdego regionu, wystąpią problemy z algorytmem konsensusu w bazie danych etcd. (około. wyd. — Tak naprawdę baza danych etcd nie musi koniecznie znajdować się na serwerach głównych. Można go uruchomić na osobnej grupie serwerów w tym samym regionie. To prawda, jednocześnie uzyskując punkt awarii klastra. Ale szybko.)
itp. używa aby wynegocjować wartość przed zapisaniem jej na dysku.
Oznacza to, że większość instancji musi osiągnąć konsensus, zanim będzie można zapisać stan w itd.
Jeśli opóźnienie pomiędzy instancjami ettd drastycznie wzrasta, jak ma to miejsce w przypadku trzech instancji ettd w różnych regionach, wynegocjowanie wartości i zapisanie jej na dysku zajmuje dużo czasu.
Znajduje to odzwierciedlenie w kontrolerach Kubernetes.
Menedżer kontrolera potrzebuje więcej czasu, aby dowiedzieć się o zmianie i zapisać odpowiedź do bazy danych.
A ponieważ nie ma jednego kontrolera, ale kilka, następuje reakcja łańcuchowa i cały klaster zaczyna działać bardzo powoli.
etcd jest tak wrażliwy na opóźnienia, że .
Obecnie nie ma dobrych przykładów dużej sieci dla pojedynczego klastra.
Zasadniczo społeczność programistów i grupa klastrów SIG próbują znaleźć sposób na orkiestrację klastrów w taki sam sposób, w jaki Kubernetes organizuje kontenery.
Opcja 1: federacja klastrów z kubefedem
Oficjalna odpowiedź klastra SIG - .
Po raz pierwszy próbowaliśmy zarządzać kolekcją klastrów jako pojedynczym obiektem za pomocą narzędzia kube Federation.
Początek był dobry, ale ostatecznie federacja kube nigdy nie zyskała popularności, ponieważ nie wspierała wszystkich zasobów.
Obsługuje stowarzyszone dostawy i usługi, ale nie na przykład StatefulSets.
Ponadto konfiguracja federacji była przekazywana w formie adnotacji i nie była elastyczna.
Wyobraź sobie, jak możesz opisać partycjonowanie replik dla każdego klastra w federacji, używając samych adnotacji.
To był kompletny bałagan.
Klaster SIG wykonał dużo pracy po Kubefed v1 i zdecydował się podejść do problemu z innej perspektywy.
Zamiast adnotacji postanowiono wypuścić kontroler instalowany na klastrach. Można go dostosować za pomocą niestandardowych definicji zasobów (CRD).
Dla każdego zasobu, który będzie częścią federacji, masz niestandardową definicję CRD z trzema sekcjami:
- standardowa definicja zasobu, na przykład wdrożenie;
- sekcja
placement, gdzie definiujesz sposób dystrybucji zasobu w federacji; - sekcja
override, gdzie dla konkretnego zasobu możesz zastąpić wagę i parametry z miejsca docelowego.
Oto przykład łączonego wyświetlania z sekcjami umieszczania i zastępowania.
apiVersion: types.federation.k8s.io/v1alpha1
kind: FederatedDeployment
metadata:
name: test-deployment
namespace: test-namespace
spec:
template:
metadata:
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- image: nginx
name: nginx
placement:
clusterNames:
- cluster2
- cluster1
overrides:
- clusterName: cluster2
clusterOverrides:
- path: spec.replicas
value: 5Jak widać, podaż jest rozdzielona na dwa klastry: cluster1 и cluster2.
Pierwszy klaster dostarcza trzy repliki, a drugi ma wartość 5.
Jeśli potrzebujesz większej kontroli nad liczbą replik, kubefed2 udostępnia nowy obiekt ReplicaSchedulingPreference, w którym można ważyć repliki:
apiVersion: scheduling.federation.k8s.io/v1alpha1
kind: ReplicaSchedulingPreference
metadata:
name: test-deployment
namespace: test-ns
spec:
targetKind: FederatedDeployment
totalReplicas: 9
clusters:
A:
weight: 1
B:
weight: 2Struktura CRD i API nie są jeszcze w pełni gotowe, trwają aktywne prace w oficjalnym repozytorium projektu.
Miej oko na kubefed2, ale pamiętaj, że nie nadaje się on jeszcze do produkcji.
Dowiedz się więcej o kubefed2 z na blogu o Kubernetesie oraz w .
Opcja 2: łączenie klastrów w stylu Booking.com
Twórcy Booking.com nie pracowali na kubefed v2, ale wymyślili Shipper – operatora dostaw w kilku klastrach, w kilku regionach i w kilku chmurach.
nieco podobny do kubefed2.
Obydwa narzędzia umożliwiają dostosowanie strategii wdrażania w wielu klastrach (które klastry są używane i ile mają replik).
Ale Celem nadawcy jest zmniejszenie ryzyka błędów podczas dostawy.
W Shipper możesz zdefiniować szereg kroków opisujących podział replik pomiędzy wdrożeniem poprzednim i bieżącym oraz wielkość ruchu przychodzącego.
Kiedy wypychasz zasób do klastra, kontroler nadawcy stopniowo wprowadza tę zmianę we wszystkich połączonych klastrach.
Ponadto nadawca jest bardzo ograniczony.
Naprzykład akceptuje wykresy steru jako dane wejściowe i nie obsługuje zasobów waniliowych.
Ogólnie rzecz biorąc, Shipper działa w ten sposób.
Zamiast standardowej dostawy musisz utworzyć zasób aplikacji zawierający wykres Helma:
apiVersion: shipper.booking.com/v1alpha1
kind: Application
metadata:
name: super-server
spec:
revisionHistoryLimit: 3
template:
chart:
name: nginx
repoUrl: https://storage.googleapis.com/shipper-demo
version: 0.0.1
clusterRequirements:
regions:
- name: local
strategy:
steps:
- capacity:
contender: 1
incumbent: 100
name: staging
traffic:
contender: 0
incumbent: 100
- capacity:
contender: 100
incumbent: 0
name: full on
traffic:
contender: 100
incumbent: 0
values:
replicaCount: 3Shipper to dobra opcja do zarządzania wieloma klastrami, ale jego bliskie powiązania z Helmem tylko przeszkadzają.
Co by było, gdybyśmy wszyscy przeszli z Helma na lub ?
Więcej o Shipperze i jego filozofii dowiesz się na stronie .
Jeśli chcesz zagłębić się w kod, .
Opcja 3: „magiczne” łączenie klastrów
Kubefed v2 i Shipper współpracują z federacją klastrów, dostarczając nowe zasoby do klastrów poprzez niestandardową definicję zasobów.
Ale co, jeśli nie chcesz przepisywać wszystkich dostaw, zestawów StatefulSets, DaemonSets itp. w celu połączenia?
Jak włączyć istniejący klaster do federacji bez zmiany YAML?
, który zajmuje się planowaniem obciążeń w klastrach.
Zamiast jednak wymyślać nowy sposób interakcji z klastrem i zawijania zasobów w niestandardowe definicje, harmonogram wieloklastrowy jest osadzony w standardowym cyklu życia Kubernetes i przechwytuje wszystkie wywołania tworzące pody.
Każdy stworzony kapsuła jest natychmiast zastępowany manekinem.
wykorzystuje harmonogram wieloklastrowy aby przechwycić połączenie i utworzyć bezczynną fikcyjną kapsułę.
Oryginalna kapsuła przechodzi kolejny cykl planowania, w którym po przeprowadzeniu ankiety w całej federacji podejmowana jest decyzja o rozmieszczeniu.
Na koniec kapsuła jest dostarczana do klastra docelowego.
W rezultacie masz dodatkową kapsułę, która nic nie robi, po prostu zajmuje miejsce.
Zaletą jest to, że nie trzeba pisać nowych zasobów, aby połączyć zasoby.
Każdy zasób tworzący pod jest automatycznie gotowy do połączenia.
To interesujące, ponieważ nagle masz zapasy rozproszone w kilku regionach i nawet tego nie zauważyłeś. Jest to jednak dość ryzykowne, gdyż wszystko tutaj opiera się na magii.
Jednak podczas gdy nadawca stara się głównie złagodzić wpływ dostaw, harmonogram wieloklastrowy obsługuje bardziej ogólne zadania i być może lepiej nadaje się do zadań wsadowych.
Nie ma zaawansowanego mechanizmu stopniowego dostarczania.
Więcej informacji na temat harmonogramu wieloklastrowego można znaleźć pod adresem .
Jeśli chcesz przeczytać o harmonogramie wieloklastrowym w działaniu, Admiralicja to zrobiła — przepływy pracy, zdarzenia, CI i CD Kubernetes.
Inne narzędzia i rozwiązania
Łączenie i zarządzanie wieloma klastrami jest zadaniem złożonym i nie ma uniwersalnego rozwiązania.
Jeśli chcesz bliżej zgłębić ten temat, oto kilka zasobów:
- to narzędzie łączące sieci nakładkowe różnych klastrów Kubernetes.
- Sieć detaliczna Docelowe zastosowania .
- Spróbuj użyć protokołu IPV6 i .
- Możesz na przykład użyć siatki usług .
- Oferuje Cilium, wtyczkę interfejsu sieciowego kontenera , co umożliwia łączenie kilku klastrów
To wszystko na dzisiaj
Dziękuję za przeczytanie do końca!
Jeśli wiesz, jak efektywniej łączyć wiele klastrów, .
Dodamy Twoją metodę do linków.
Specjalne podziękowania dla Chrisa Nesbitta-Smitha () i Vincenta de Sme () (inżynier niezawodności w ) za przeczytanie artykułu i podzielenie się przydatnymi informacjami na temat działania federacji.
Źródło: www.habr.com