W miarę tworzenia coraz większej liczby usług Kubernetes zadania, które początkowo były proste, stają się coraz bardziej złożone. Na przykład zespoły programistów nie mogą tworzyć usług ani wdrożeń pod tą samą nazwą. Jeśli masz tysiące podów, samo ich wystawienie zajmie dużo czasu, nie mówiąc już o właściwym zarządzaniu nimi. A to dopiero wierzchołek góry lodowej.
Przyjrzyjmy się, jak przestrzeń nazw ułatwia zarządzanie zasobami Kubernetes. Czym zatem jest przestrzeń nazw? Przestrzeń nazw można traktować jako klaster wirtualny w klastrze Kubernetes. W jednym klastrze Kubernetes można odizolować wiele przestrzeni nazw. Mogą naprawdę pomóc Tobie i Twoim zespołom w zakresie organizacji, bezpieczeństwa, a nawet wydajności systemu.
W większości dystrybucji Kubernetes klaster jest gotowy do użycia z przestrzenią nazw o nazwie „domyślna”. W rzeczywistości Kubernetes obsługuje trzy przestrzenie nazw: default, kube-system i kube-public. Obecnie Kube-public nie jest używany zbyt często.
Dobrym pomysłem jest pozostawienie samej przestrzeni nazw kube, szczególnie w systemie zarządzanym, takim jak Google Kubernetes Engine. Używa „domyślnej” przestrzeni nazw jako miejsca, w którym tworzone są Twoje usługi i aplikacje. Nie ma w tym absolutnie nic specjalnego, poza tym, że Kubernetes jest od razu skonfigurowany do korzystania z niego i nie można go usunąć. Jest to świetne rozwiązanie na początek i w przypadku systemów o niskiej wydajności, ale nie zalecałbym używania domyślnej przestrzeni nazw w dużych systemach prod. W tym drugim przypadku jeden zespół programistów może łatwo przepisać kod innej osoby i zepsuć pracę innego zespołu, nawet nie zdając sobie z tego sprawy.
Dlatego powinieneś utworzyć wiele przestrzeni nazw i używać ich do segmentowania usług na łatwe do zarządzania jednostki. Przestrzeń nazw można utworzyć za pomocą jednego polecenia. Jeśli chcesz utworzyć przestrzeń nazw o nazwie test, użyj polecenia $ kubectl create namespace test lub po prostu utwórz plik YAML i używaj go jak każdego innego zasobu Kubernetes.
Możesz wyświetlić wszystkie przestrzenie nazw za pomocą polecenia $ kubectl get namespace.
Gdy już to zrobisz, zobaczysz trzy wbudowane przestrzenie nazw i nową przestrzeń nazw o nazwie „test”. Przyjrzyjmy się prostemu plikowi YAML, aby utworzyć pod. Zauważysz, że nie ma wzmianki o przestrzeni nazw.
Jeśli do uruchomienia tego pliku użyjesz programu kubectl, utworzy on moduł mypod w aktualnie aktywnej przestrzeni nazw. Będzie to domyślna przestrzeń nazw, dopóki jej nie zmienisz. Istnieją dwa sposoby poinformowania Kubernetesa, w jakiej przestrzeni nazw chcesz utworzyć zasób. Pierwszym sposobem jest użycie flagi przestrzeni nazw podczas tworzenia zasobu.
Drugi sposób polega na określeniu przestrzeni nazw w deklaracji YAML.
Jeśli określisz przestrzeń nazw w YAML, zasób będzie zawsze tworzony w tej przestrzeni nazw. Jeśli spróbujesz użyć innej przestrzeni nazw podczas korzystania z flagi przestrzeni nazw, wykonanie polecenia zakończy się niepowodzeniem. Jeśli teraz spróbujesz znaleźć kapsułę, nie będziesz w stanie tego zrobić.
Dzieje się tak, ponieważ wszystkie polecenia są wykonywane poza aktualnie aktywną przestrzenią nazw. Aby znaleźć swój pod, musisz użyć flagi przestrzeni nazw, ale szybko się to nudzi, szczególnie jeśli jesteś programistą w zespole, który używa własnej przestrzeni nazw i nie chce używać tej flagi dla każdego pojedynczego polecenia. Zobaczmy, jak możemy to naprawić.
Po wyjęciu z pudełka aktywna przestrzeń nazw nazywa się domyślną. Jeśli nie określisz przestrzeni nazw w zasobie YAML, wszystkie polecenia Kubernetes będą używać tej aktywnej domyślnej przestrzeni nazw. Niestety próba zarządzania aktywną przestrzenią nazw za pomocą kubectl może zakończyć się niepowodzeniem. Istnieje jednak bardzo dobre narzędzie o nazwie Kubens, które znacznie ułatwia ten proces. Po uruchomieniu polecenia kubens zostaną wyświetlone wszystkie przestrzenie nazw z podświetloną aktywną przestrzenią nazw.
Aby przełączyć aktywną przestrzeń nazw na testową przestrzeń nazw, wystarczy uruchomić komendę $kubens test. Jeśli następnie ponownie uruchomisz polecenie $kubens, zobaczysz, że przydzielono nową aktywną przestrzeń nazw - test.
Oznacza to, że nie potrzebujesz flagi przestrzeni nazw, aby zobaczyć moduł w testowej przestrzeni nazw.
W ten sposób przestrzenie nazw są od siebie ukryte, ale nie odizolowane. Usługa w jednej przestrzeni nazw może dość łatwo komunikować się z usługą w innej przestrzeni nazw, co często jest bardzo przydatne. Możliwość komunikowania się w różnych przestrzeniach nazw oznacza, że usługa deweloperów może komunikować się z usługą innego zespołu programistów w innej przestrzeni nazw.
Zwykle, gdy Twoja aplikacja chce uzyskać dostęp do usługi Kubernetes, korzystasz z wbudowanej usługi wykrywania DNS i po prostu nadajesz swojej aplikacji nazwę usługi. Jednak w ten sposób można utworzyć usługę o tej samej nazwie w wielu przestrzeniach nazw, co jest niedopuszczalne.
Na szczęście można to łatwo obejść, korzystając z rozszerzonej formy adresu DNS. Usługi w Kubernetes udostępniają swoje punkty końcowe przy użyciu wspólnego szablonu DNS. Wygląda to mniej więcej tak:
Zwykle wystarczy nazwa usługi, a system DNS automatycznie określi pełny adres.
Jeśli jednak chcesz uzyskać dostęp do usługi w innej przestrzeni nazw, po prostu użyj nazwy usługi i nazwy przestrzeni nazw:
Na przykład, jeśli chcesz połączyć się z bazą danych usług w testowej przestrzeni nazw, możesz użyć adresu bazy danych Database.test
Jeśli chcesz połączyć się z bazą danych usług w przestrzeni nazw prod, użyj Database.prod.
Jeśli naprawdę chcesz odizolować i ograniczyć dostęp do przestrzeni nazw, Kubernetes pozwala to zrobić za pomocą zasad sieciowych Kubernetes. Opowiem o tym w następnym odcinku.
Często spotykam się z pytaniem, ile przestrzeni nazw powinienem utworzyć i w jakim celu? Co to jest zarządzany fragment danych?
Jeśli utworzysz zbyt wiele przestrzeni nazw, po prostu staną ci na drodze. Jeśli będzie ich za mało, stracisz wszystkie zalety takiego rozwiązania. Myślę, że istnieją cztery główne etapy, przez które przechodzi każda firma, tworząc swoją strukturę organizacyjną. W zależności od etapu rozwoju Twojego projektu lub firmy, możesz przyjąć odpowiednią strategię dotyczącą przestrzeni nazw.
Wyobraź sobie, że jesteś częścią małego zespołu, który pracuje nad opracowaniem 5-10 mikroserwisów i możesz łatwo zebrać wszystkich programistów w jednym pomieszczeniu. W tej sytuacji sensowne jest uruchomienie wszystkich usług prod w domyślnej przestrzeni nazw. Oczywiście dla większej elastyczności można użyć 2 przestrzeni nazw - osobno dla prod i dev. Najprawdopodobniej testujesz swój program na komputerze lokalnym, używając czegoś takiego jak Minikube.
Załóżmy, że coś się zmieniło i masz teraz szybko rosnący zespół pracujący nad ponad 10 mikrousługami jednocześnie. Przychodzi moment, kiedy konieczne jest użycie kilku klastrów lub przestrzeni nazw, oddzielnie dla prod i dev. Możesz podzielić zespół na kilka podzespołów, tak aby każdy z nich miał własne mikrousługi i każdy z tych zespołów mógł wybrać własną przestrzeń nazw, aby ułatwić proces zarządzania rozwojem i wydawaniem oprogramowania.
W miarę jak każdy członek zespołu zyskuje wgląd w działanie systemu jako całości, koordynowanie każdej zmiany z pozostałymi programistami staje się coraz trudniejsze. Próba uruchomienia pełnego stosu na komputerze lokalnym staje się z każdym dniem coraz trudniejsza.
W dużych firmach programiści na ogół nie wiedzą, kto dokładnie nad czym pracuje. Zespoły komunikują się za pomocą kontraktów serwisowych lub korzystają z technologii Service Mesh, która dodaje warstwę abstrakcji w sieci, taką jak narzędzie konfiguracyjne Istio. Próba uruchomienia całego stosu lokalnie jest po prostu niemożliwa. Gorąco polecam korzystanie z platformy ciągłego dostarczania (CD), takiej jak Spinnaker na Kubernetesie. Nadchodzi więc moment, w którym każde polecenie zdecydowanie potrzebuje własnej przestrzeni nazw. Każdy zespół może nawet wybrać wiele przestrzeni nazw dla środowiska deweloperskiego i środowiska prod.
Wreszcie istnieją duże, przedsiębiorcze firmy, w których jedna grupa deweloperów nawet nie wie o istnieniu innych grup. Taka firma może zazwyczaj zatrudniać zewnętrznych programistów, którzy komunikują się z nią za pośrednictwem dobrze udokumentowanych interfejsów API. Każda taka grupa zawiera kilka zespołów i kilka mikrousług. W takim przypadku musisz użyć wszystkich narzędzi, o których mówiłem wcześniej.
Programiści nie powinni ręcznie wdrażać usług i nie powinni mieć dostępu do przestrzeni nazw, które ich nie dotyczą. Na tym etapie wskazane jest posiadanie kilku klastrów, aby zmniejszyć „promień wybuchu” źle skonfigurowanych aplikacji, uprościć procesy rozliczeniowe i zarządzanie zasobami.
Zatem właściwe wykorzystanie przestrzeni nazw przez organizację pozwala uczynić Kubernetes łatwiejszym w zarządzaniu, kontrolowaniu, bezpieczeństwie i elastyczności.
Kilka reklam 🙂
Dziękujemy za pobyt z nami. Podobają Ci się nasze artykuły? Chcesz zobaczyć więcej ciekawych treści? Wesprzyj nas składając zamówienie lub polecając znajomym, , unikalny odpowiednik serwerów klasy podstawowej, który został przez nas wymyślony dla Ciebie: (dostępne z RAID1 i RAID10, do 24 rdzeni i do 40 GB DDR4).
Dell R730xd 2 razy taniej w centrum danych Equinix Tier IV w Amsterdamie? Tylko tutaj w Holandii! Dell R420 — 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2x960 GB SSD 1 Gb/s 100 TB — od 99 USD! Czytać o
Źródło: www.habr.com