Jeśli jesteś jak większość ludzi, prawdopodobnie korzystasz z zasobów działających poza swoim klastrem. Możliwe, że używasz API Taleo do wysyłania wiadomości tekstowych lub analizujesz obrazy za pomocą API Google Cloud Vision.
Jeśli korzystasz z tego samego punktu końcowego — punktu odbioru zapytań po stronie serwera we wszystkich swoich środowiskach i nie planujesz przenosić swoich serwerów do Kubernetes, to całkowicie w porządku jest mieć punkt końcowy usługi bezpośrednio w swoim kodzie. Istnieje jednak wiele innych scenariuszy rozwoju wydarzeń. W tej serii 'Kubernetes Best Practices' dowiesz się, jak wykorzystać wbudowane mechanizmy Kubernetes do odkrywania usług zarówno wewnątrz, jak i na zewnątrz klastra.
Jako przykład powszechnie używanej zewnętrznej usługi można podać bazę danych działającą poza klastrem Kubernetes. W przeciwieństwie do takich baz danych w chmurze, jak Google Cloud Data Store czy Google Cloud Spanner, które używają jednego punktu końcowego do wszystkich rodzajów dostępu, większość baz danych ma oddzielne punkty końcowe dla różnych sytuacji.
Najlepsze praktyki w korzystaniu z tradycyjnych baz danych, takich jak MySQL i MongoDB, zazwyczaj zakładają, że łączysz się z różnymi komponentami dla różnych środowisk. Możesz mieć większą maszynę dla danych produkcyjnych i mniejszą maszynę dla środowiska testowego. Każda z nich będziesz miała swoje adresy IP lub nazwy domen, ale z pewnością nie chciałbyś zmieniać swojego kodu, przechodząc z jednego środowiska do drugiego. Dlatego zamiast twardego kodowania tych adresów możesz skorzystać z wbudowanej w Kubernetes usługi odkrywania zewnętrznych usług opartych na DNS, dokładnie tak samo, jak w przypadku natywnych usług Kubernetes.
Załóżmy, że uruchamiasz bazę danych MongoDB w Google Compute Engine. Utkniesz w tym hybrydowym świecie, dopóki nie uda ci się przenieść jej do klastra.
Na szczęście możesz skorzystać ze statycznych usług Kubernetes, aby choć trochę ułatwić sobie życie. W tym przykładzie stworzyłem serwer MongoDB za pomocą Google Cloud Launcher. Ponieważ został on utworzony w tej samej sieci (lub VPC klastra Kubernetes), dostęp do niego odbywa się za pomocą wydajnego wewnętrznego adresu IP.
W Google Cloud to ustawienie jest domyślne, więc nie musisz nic konfigurować. Teraz, gdy mamy adres IP, pierwszym krokiem jest stworzenie usługi. Można zauważyć, że dla tej usługi nie ma żadnych selektorów podów. Oznacza to, że stworzyliśmy usługę, która nie będzie wiedzieć, gdzie kierować ruch. Umożliwi to ręczne stworzenie obiektu endpoint, który będzie odbierał ruch z tej usługi.
Następny przykład kodu pokazuje, że punkty końcowe określają adres IP dla bazy danych, używając tej samej nazwy mongo, co usługa.
Kubernetes będzie używać wszystkich adresów IP, aby znaleźć punkty końcowe, jakby były zwykłymi podami Kubernetes, więc teraz możesz uzyskać dostęp do bazy danych za pomocą prostego ciągu połączenia do powyższej nazwy mongodb://mongo. Przy tym nie ma potrzeby używania adresów IP w swoim kodzie.
Jeśli w przyszłości adresy IP się zmienią, można po prostu zaktualizować punkty końcowe za pomocą nowego adresu IP, a twoje aplikacje nie muszą być w żaden sposób zmieniane.
Jeśli używasz bazy danych umieszczonej na zewnętrznym hoście, prawdopodobnie właściciele hosta dostarczyli ci do połączenia zunifikowany identyfikator zasobu URI. Jeśli więc otrzymałeś adres IP, można po prostu skorzystać z poprzedniej metody. Ten przykład pokazuje, że mam dwie bazy danych MongoDB umieszczone na hoście mLab.
Jedna z nich to baza danych dla deweloperów, a druga to baza produkcyjna. Ciągi połączenia dla tych baz danych wyglądają następująco — mLab dostarcza ci dynamiczny URI i dynamiczny port. Jak widać, są różne.
Aby się od tego abstrahować, używamy Kubernetes i łączymy się z bazą danych deweloperów. Możesz stworzyć zewnętrzną nazwę usługi Kubernetes, która dostarczy ci statyczną usługę, która będzie kierować ruch do zewnętrznej usługi.
Ta usługa wykona prostą przekierowanie CNAME na poziomie jądra, co będzie miało minimalny wpływ na wydajność. Dzięki temu możesz używać prostszego ciągu połączenia.
Jednak ponieważ zewnętrzna nazwa używa przekierowania CNAME, nie może ona wykonać przekierowania portów. Dlatego to rozwiązanie jest stosowane tylko dla statycznych portów i nie może być używane z dynamicznymi portami. Jednak darmowy plan mLab Free Tier domyślnie przydziela użytkownikowi dynamiczny numer portu i nie można tego zmienić. Oznacza to, że dla dev i prod potrzebne są różne ciągi poleceń do łączenia. Słabością jest to, że numer portu będzie musiał być zakodowany na sztywno. Jak więc sprawić, by przekierowanie portów działało?
Pierwszym krokiem jest uzyskanie adresu IP z URI. Wykonując polecenie nslookup, hostname lub pingując URI, można uzyskać adres IP bazy danych. Jeśli przy tym usługa zwraca wiele adresów IP, można używać wszystkich tych adresów w punktach końcowych obiektu.
Należy pamiętać, że adresy IP URI mogą się zmieniać bez wcześniejszego powiadomienia, dlatego używanie ich w prod jest dość ryzykowne. Taki adres IP pozwala na połączenie z zdalną bazą danych bez wskazywania portu. W ten sposób usługa Kubernetes dość przejrzyście realizuje przekierowanie portów.
Mapowanie, czyli przypisywanie zasobów zewnętrznych do wewnętrznych, daje możliwość elastycznego wykorzystania tych usług w klastrze w przyszłości przy minimalnym wysiłku związanym z refaktoryzacją. Ułatwia to również zarządzanie i daje zrozumienie, z jakich zewnętrznych usług korzysta twoja firma.
Ciąg dalszy wkrótce…
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
