Jeśli jesteś jak większość ludzi, prawdopodobnie korzystasz z zasobów działających poza klastrem. Być może używasz Taleo API do wysyłania SMS-ów lub analizujesz obrazy za pomocą Google Cloud Vision API.
Jeśli używasz tego samego punktu końcowego żądań po stronie serwera we wszystkich swoich środowiskach i nie planujesz migracji serwerów do Kubernetes, dobrze jest mieć punkt końcowy usługi bezpośrednio w kodzie. Istnieje jednak wiele innych scenariuszy rozwoju wydarzeń. W tej serii najlepszych praktyk Kubernetes dowiesz się, jak używać wbudowanych mechanizmów Kubernetes do odkrywania usług zarówno wewnątrz, jak i na zewnątrz klastra.
Przykładem typowej usługi zewnętrznej jest baza danych działająca poza klastrem Kubernetes. W przeciwieństwie do baz danych w chmurze, takich jak Google Cloud Data Store lub Google Cloud Spanner, które korzystają z jednego punktu końcowego dla całego dostępu, większość baz danych ma oddzielne punkty końcowe w różnych okolicznościach.
Najlepsze praktyki korzystania z tradycyjnych baz danych, takich jak MySQL i MongoDB, zwykle oznaczają, że łączysz się z różnymi komponentami dla różnych środowisk. Możesz mieć dużą maszynę do przechowywania danych produkcyjnych i mniejszą maszynę do środowiska testowego. Każdy z nich będzie miał swój własny adres IP lub nazwę domeny, ale prawdopodobnie nie będziesz chciał zmieniać swojego kodu przy przechodzeniu z jednego środowiska do drugiego. Zamiast więc kodować te adresy na stałe, możesz użyć wbudowanego wykrywania usług zewnętrznych Kubernetesa w oparciu o DNS w taki sam sposób, jak natywne usługi Kubernetes.
Załóżmy, że używasz bazy danych MongoDB w Google Compute Engine. Utkniesz w tym hybrydowym świecie, dopóki nie uda ci się przenieść go do klastra.
Na szczęście możesz skorzystać ze statycznych usług Kubernetes, aby ułatwić sobie życie. W tym przykładzie utworzyłem serwer MongoDB za pomocą Google Cloud Launcher. Ponieważ jest tworzony w tej samej sieci (lub w klastrze VPC Kubernetes), można uzyskać do niego dostęp za pomocą wewnętrznego adresu IP o wysokiej wydajności.
Jest to domyślne ustawienie w Google Cloud, więc nie musisz niczego konfigurować. Teraz, gdy masz już adres IP, pierwszym krokiem jest utworzenie usługi. Możesz zauważyć, że dla tej usługi nie ma selektorów podów. Oznacza to, że stworzyliśmy usługę, która nie będzie wiedziała, dokąd skierować ruch. Umożliwi to ręczne utworzenie obiektu punktu końcowego, który będzie odbierał ruch z tej usługi.
Poniższy przykład kodu pokazuje, że punkty końcowe określają adres IP bazy danych przy użyciu tej samej nazwy mongo co usługa.
Kubernetes użyje wszystkich adresów IP do znalezienia punktów końcowych tak, jakby były to zwykłe Kubernetes Pody, więc teraz możesz uzyskać dostęp do bazy danych za pomocą prostego ciągu połączenia z powyższą nazwą mongodb://mongo. W ogóle nie ma potrzeby używania adresów IP w kodzie.
Jeśli w przyszłości adresy IP zmienią się, możesz po prostu zaktualizować swoje punkty końcowe o nowy adres IP, a Twoje aplikacje nie będą musiały być modyfikowane w żaden dodatkowy sposób.
Jeśli korzystasz z bazy danych hostowanej na hoście strony trzeciej, prawdopodobnie właściciele hosta udostępnili Ci identyfikator URI Uniform Resource Identifier, z którym możesz się połączyć. Jeśli więc otrzymałeś adres IP, możesz po prostu skorzystać z poprzedniej metody. Ten przykład pokazuje, że mam dwie bazy danych MongoDB hostowane na hoście mLab.
Jedna to baza danych programistów, a druga to baza danych produkcyjnych. Ciągi połączeń dla tych baz danych wyglądają następująco - mLab zapewnia dynamiczny identyfikator URI i dynamiczny port. Jak widać, są różne.
Aby to wyeliminować, użyjmy Kubernetesa i połączmy się z bazą danych programistów. Możesz utworzyć zewnętrzną nazwę usługi Kubernetes, która zapewni usługę statyczną, która będzie przekazywać ruch do usługi zewnętrznej.
Ta usługa wykona proste przekazywanie rekordów CNAME na poziomie jądra przy minimalnym wpływie na wydajność. Dzięki temu można zastosować prostszy ciąg połączenia.
Ponieważ jednak nazwa zewnętrzna korzysta z przekierowania CNAME, nie może wykonać przekierowania portów. Dlatego to rozwiązanie ma zastosowanie tylko do portów statycznych i nie może być używane z portami dynamicznymi. Ale mLab Free Tier domyślnie daje użytkownikowi dynamiczny numer portu i nie można go zmienić. Oznacza to, że potrzebujesz różnych wierszy poleceń połączenia dla deweloperów i prod. Złą rzeczą jest to, że będzie to wymagało zakodowania numeru portu. Jak więc sprawić, by przekierowanie portów działało?
Pierwszym krokiem jest uzyskanie adresu IP z identyfikatora URI. Jeśli uruchomisz nslookup, nazwę hosta lub ping URI, możesz uzyskać adres IP bazy danych. Jeśli usługa zwróci Ci kilka adresów IP, to wszystkie te adresy będą mogły zostać wykorzystane na punktach końcowych obiektu.
Należy pamiętać, że identyfikatory URI adresów IP mogą ulec zmianie bez powiadomienia, co czyni je dość ryzykownymi w użyciu w prod. Używając tego adresu IP, możesz połączyć się ze zdalną bazą danych bez określania portu. Tym samym usługa Kubernetes realizuje przekierowanie portów w sposób dość przejrzysty.
Mapowanie, czyli mapowanie zasobów zewnętrznych na wewnętrzne, zapewnia elastyczność korzystania z tych usług w ramach klastra w przyszłości, minimalizując jednocześnie wysiłki związane z refaktoryzacją. Ułatwia także zarządzanie i zapewnia wgląd w to, z jakich usług zewnętrznych korzysta Twoja firma.
Ciąg dalszy już wkrótce...
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