W miarę jak zaczynasz tworzyć coraz więcej usług Kubernetes, proste na początku zadania zaczynają się komplikować. Na przykład zespoły deweloperskie nie mogą tworzyć usług ani wdrożeń o tej samej nazwie. Jeżeli masz tysiące podów, ich proste zliczenie zajmie mnóstwo czasu, nie mówiąc już o zapewnieniu odpowiedniego zarządzania. I to tylko wierzchołek góry lodowej.
Przyjrzyjmy się, jak przestrzenie nazw ułatwiają zarządzanie zasobami Kubernetes. Więc czym właściwie jest przestrzeń nazw? Przestrzeń nazw można postrzegać jako wirtualny klaster w obrębie twojego klastra Kubernetes. Możesz mieć kilka izolowanych od siebie przestrzeni nazw w obrębie jednego klastra Kubernetes. Mogą one naprawdę pomóc tobie i twoim zespołom w organizacji, bezpieczeństwie, a nawet wydajności systemu.
W większości dystrybucji Kubernetes klaster „wychodzi z pudełka” z przestrzenią nazw o nazwie „default”. W rzeczywistości istnieją trzy przestrzenie nazw, z którymi Kubernetes ma do czynienia: default, kube-system oraz kube-public. Obecnie kube-public nie jest zbyt często używane.
Nie dotykanie przestrzeni nazw kube to dobry pomysł, zwłaszcza w takim zarządzanym systemie jak Google Kubernetes Engine. Używa on przestrzeni nazw „default” jako miejsca, w którym tworzone są twoje usługi i aplikacje. Nie ma w nim absolutnie nic wyjątkowego, poza tym, że Kubernetes jest „z pudełka” skonfigurowany na jego używanie, i nie możesz go usunąć. To świetne dla rozpoczęcia pracy i systemów z niewielką wydajnością, ale nie polecałbym korzystania z przestrzeni nazw default w dużych systemach produkcyjnych. W takim przypadku jeden zespół deweloperski może łatwo nadpisać kod innego zespołu i zakłócić jego działanie, nawet nie zdając sobie z tego sprawy.
W związku z tym warto stworzyć kilka przestrzeni nazw i używać ich do segmentacji twoich usług w zarządzane jednostki. Przestrzeń nazw można stworzyć za pomocą jednej komendy. Jeśli chcesz stworzyć przestrzeń nazw o nazwie test, użyj komendy $ kubectl create namespace test lub po prostu stwórz plik YAML i użyj go jak każdy inny zasób Kubernetes.
Aby wyświetlić wszystkie przestrzenie nazw, użyj komendy $ kubectl get namespace.
Po jego wykonaniu zobaczysz trzy wbudowane przestrzenie nazw oraz nową przestrzeń nazw o nazwie „test”. Przyjrzyjmy się prostemu plikowi YAML, zaplanowanemu do tworzenia pod. Można zauważyć, że nie ma w nim żadnego odniesienia do przestrzeni nazw.
Jeśli zastosujesz kubectl do uruchomienia tego pliku, utworzy moduł mypod w bieżącej aktywnej przestrzeni nazw. Będzie to przestrzeń nazw domyślna, dopóki jej nie zmienisz. Istnieją dwa sposoby, aby poinformować Kubernetes, w której przestrzeni nazw chcesz stworzyć swój zasób. Pierwszym sposobem jest użycie flagi przestrzeni nazw podczas tworzenia zasobu.
Drugim sposobem jest wskazanie przestrzeni nazw w deklaracji YAML.
Jeśli wskażesz przestrzeń nazw w YAML, zasób zawsze będzie tworzony w tej przestrzeni. Jeśli spróbujesz użyć innej przestrzeni nazw przy użyciu flagi przestrzeni nazw, polecenie zakończy się błędem. Teraz, jeśli spróbujesz znaleźć swój pod, nie będziesz w stanie tego zrobić.
Dzieje się tak, ponieważ wszystkie polecenia są wykonywane poza bieżącą aktywną przestrzenią nazw. Aby znaleźć swój pod, musisz użyć flagi przestrzeni nazw, jednak to szybko staje się nużące, zwłaszcza jeśli jesteś programistą w grupie, która używa własnej przestrzeni nazw i nie chce używać tej flagi dla każdego poszczególnego polecenia. Zobaczmy, jak można to naprawić.
Na dzień dobry Twoja aktywna przestrzeń nazw nazywa się default. Jeśli nie określisz przestrzeni nazw w YAML zasobu, wszystkie polecenia Kubernetes będą korzystać z tej aktywnej przestrzeni default. Niestety próba zarządzania aktywną przestrzenią nazw za pomocą kubectl może się nie udać. Istnieje jednak bardzo dobre narzędzie o nazwie Kubens, które znacznie ułatwia ten proces. Kiedy uruchamiasz polecenie kubens, widzisz wszystkie przestrzenie nazw z oświetloną aktywną przestrzenią nazw.
Aby przełączyć aktywną przestrzeń nazw na przestrzeń nazw test, wystarczy uruchomić polecenie $ kubens test. Jeśli następnie ponownie wpiszesz polecenie $ kubens, zobaczysz, że teraz wyróżniona jest nowa aktywna przestrzeń nazw – test.
Oznacza to, że nie potrzebujesz flagi przestrzeni nazw, aby zobaczyć pod w przestrzeni nazw test.
Tak więc przestrzenie nazw są ukryte przed sobą, ale nie są od siebie izolowane. Usługa z jednej przestrzeni nazw może dość łatwo komunikować się z usługą w innej przestrzeni nazw, co często okazuje się bardzo przydatne. Możliwość komunikacji między różnymi przestrzeniami nazw oznacza, że usługa twoich programistów może współdziałać z usługą innego zespołu deweloperskiego w innej przestrzeni nazw.
Zazwyczaj, gdy twoja aplikacja chce uzyskać dostęp do usługi Kubernetes, używasz wbudowanej funkcji odkrywania DNS i po prostu wskazujesz swojej aplikacji nazwę usługi. Jednak w tym przypadku możesz utworzyć usługę o tej samej nazwie w kilku przestrzeniach nazw, co jest niedopuszczalne.
Na szczęście łatwo to obejść, używając rozwiniętej formy adresu DNS. Usługi w Kubernetes wystawiają swoje punkty końcowe, używając wspólnego wzoru DNS. Wygląda to mniej więcej tak:
Zazwyczaj potrzebujesz tylko nazwy usługi, a DNS automatycznie określi pełny adres.
Jednak jeśli potrzebujesz uzyskać dostęp do usługi w innej przestrzeni nazw, po prostu użyj nazwy usługi plus nazwa przestrzeni nazw:
Na przykład, jeśli chcesz połączyć się z bazą danych usługi w przestrzeni nazw test, możesz użyć adresu database.test.
Jeśli natomiast chcesz połączyć się z bazą danych usługi w przestrzeni nazw prod, używasz database.prod.
Jeśli naprawdę chcesz izolować i ograniczać dostęp do przestrzeni nazw, Kubernetes pozwala to zrobić za pomocą polityk sieciowych Kubernetes Network Policies. O tym opowiem w następnej serii.
Często otrzymuję pytanie, ile przestrzeni nazw należy utworzyć i do jakich celów? Czym właściwie jest zarządzany fragment danych?
Jeśli utworzysz zbyt wiele przestrzeni nazw, będą one tylko przeszkadzać. Z drugiej strony, jeśli będzie ich za mało, stracisz wszelkie korzyści płynące z tego rozwiązania. Uważam, że istnieją cztery podstawowe etapy, przez które przechodzi każda firma w procesie tworzenia swojej struktury organizacyjnej. W zależności od etapu rozwoju, na którym znajduje się twój projekt lub firma, możesz zastosować odpowiednią strategię tworzenia 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 produkcyjnych w przestrzeni nazw default. Oczywiście, dla większej swobody działania możesz użyć dwóch przestrzeni nazw — osobno dla prod i dev. Najprawdopodobniej testujesz swoją aplikację na lokalnym komputerze za pomocą czegoś takiego jak Minikube.
Załóżmy, że sytuacja się zmieniła i masz teraz szybko rosnący zespół, który jednocześnie pracuje nad ponad 10 mikroserwisami. Nastaje moment, w którym konieczne staje się korzystanie z kilku klastrów lub przestrzeni nazw, osobno dla prod i dev. Można podzielić zespół na kilka podgrup, tak aby każda z nich miała swoje własne mikroserwisy i każda z tych drużyn mogła wybrać swoje własne przestrzenie nazw dla ułatwienia procesu zarządzania rozwojem i wydawaniem oprogramowania.
W miarę jak każdy z członków zespołu zyskuje zrozumienie, jak działa system jako całość, koordynowanie każdej zmiany z pozostałymi programistami staje się coraz trudniejsze. Próba uruchomienia pełnego stosu na swoim lokalnym komputerze z każdym dniem staje się coraz bardziej skomplikowana.
W dużych firmach programiści często nie mają pojęcia, kto dokładnie nad czym pracuje. Zespoły porozumiewają się za pomocą kontraktów serwisowych lub używają technologii Service mesh, która dodaje poziom abstrahowania nad siecią, na przykład narzędzie konfiguracyjne Istio. Próba uruchomienia całego stosu lokalnie jest po prostu niemożliwa. Zdecydowanie zalecam korzystanie w Kubernetes z takiej platformy ciągłej dostawy (CD), jak Spinnaker. Nadszedł zatem czas, gdy każdemu zespołowi zdecydowanie potrzebna jest własna przestrzeń nazw. Każdy zespół może nawet wybrać kilka przestrzeni nazw dla środowiska dev i produkcji.
Wreszcie, istnieją duże przedsiębiorstwa, w których jedna grupa programistów nawet nie ma pojęcia o istnieniu innych grup. Taka firma może zatrudniać zewnętrznych programistów, którzy współpracują z dobrze udokumentowanymi API. W każdej takiej grupie znajduje się kilka zespołów i kilka mikrousług. W takim przypadku należy skorzystać ze 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 sensowne jest posiadanie kilku klastrów, aby zmniejszyć 'promień eksplozji' źle skonfigurowanych aplikacji, uprościć procesy rozliczeniowe i zarządzanie zasobami.
Tak więc właściwe wykorzystanie przestrzeni nazw przez twoją organizację sprawia, że Kubernetes staje się bardziej kontrolowany, zarządzany, bezpieczny i elastyczny.
Trochę reklamy 🙂
Dziękujemy, że jesteś z nami. Podobają Ci się nasze artykuły? Chcesz zobaczyć więcej interesujących materiałów? Wspieraj nas składając zamówienie lub polecając nas znajomym, , unikatowy odpowiednik serwerów entry-level, który został stworzony przez nas dla Ciebie: (dostępne opcje z RAID1 i RAID10, do 24 rdzeni i do 40GB DDR4).
Dell R730xd dwa razy tańszy w centrum danych Equinix Tier IV w Amsterdamie? Tylko u nas w Holandii! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — od 99 dolarów! Czytaj o tym
Źródło: habr.com
