Wpis z mikrobloga

#linux #kubernetes
Mam klaster Kubernetesa w własnej infrastrukturze. Chciałbym móc kontrolować ruch wychodzący z POD'ów na zewnątrz klastra, w taki sposób aby każdy z nich miał swój indywidualny adres IP. Normalnie wszystko na zewnątrz wychodzi z adresem Noda. W chmurach Googla. AWS, itp, są do tego narzędzia. Ja szukam czegoś do własnej infrastruktury. Znalazłem jeden projekt, w wersji Alpha, ale nie działa w Kubernetesie w wersjach 1.16+:

https://github.com/nirmata/kube-static-egress-ip
  • 12
  • Odpowiedz
w taki sposób aby każdy z nich miał swój indywidualny adres IP.


@tyu38: Ruch wychodzi z jednego adresu a ty chcesz automagicznie zrobic, zeby kazdy kontener mial swoj wlasny IP widoczny na zewnatrz?
  • Odpowiedz
via Android
  • 0
@less_is_more Normalnie wychodzi z adresem zewnętrznym noda. Ale chcę żeby był robiony snat z innego adresu, który sobie wybiorę. Np tworzy wirtualny adres na hoście i on jest przypisany do poda. Jak w tym projekcie. Tam dokładnie jest to zagadnienie wyjaśnione. Po co i dlaczego
  • Odpowiedz
@tyu38: A ok, myslalem, ze nie ogarniasz, ze jak masz jeden zew adres to nagle ich nie rozmnożysz. Nie korzystan z kuber, w tej sytuacji dostrzegam wieksza wartosc w surowych kontenerach lxc albo full virt.
  • Odpowiedz
@tyu38: kolego, z poda ruch wychodzi z adresem IP poda. Dopiero plugin sieciowy natuje ci go, już w namespace sieciowym noda. Użyj kubenet zamiast pluginu sieciowego którego używasz teraz, zestaw routing między interfejsem cbr0 między nodami żeby wgl klaster działał i nie będziesz miał żadnego natowania, a pod jak będzie wysyłał coś na zewnątrz to w source ip pakietu będziesz miał dokładnie IP poda. Dalej zrobisz z tym co chcesz.
  • Odpowiedz
@sz__po: Do tej pory używałem jako pluginu sieciowego Calcio oraz Weave Net. Rozumiem, że zamiast nich mam użyć kubenet. Wtedy wszystko na zewnątrz klastra będzie wychodzić z adresem poda z sieci Cluster IP. Oczywiście muszę dla każdego poda przydzielić stały ip, żeby na zewnątrz móc tworzyć whitelisty (na start w klastrze będę miał ponad 300 aplikacji, a każda będzie się łączyć do 5 innych miejsc). Jeszcze kwestia Network Policy. Czy
  • Odpowiedz
@tyu38: niestety, network policy jest implementowane przez plugin sieciowy, a kubenet to dokładnie bardzo prosty plugin sieciowy który robi tyle, ze dopina veth do cbr0 (to klasyczny linuksowy bridge). W tym wypadku samemu musiałbyś zadbać i zaimplementować rozwiązanie które zaktualizuje Ci firewall w systemie zgodnie z network policy (to dosyć proste) i zrobi snat na określony adres IP z podow które oczekujesz. Nie musisz przydzielać stałego IP dla podow, bo
  • Odpowiedz
@tyu38: zastanawiam się jeszcze nas twoim problemem. Rozumiem ze potrzebujesz znać IP poda, ponieważ po drugiej stronie masz acl i musisz wiedzieć co wpuścić?
  • Odpowiedz
@sz__po: No tak. Ciężko na firewallach pośredniczących, albo hostach serwujących aplikacje/bazy danych rozróżnić ruch kilkuset aplikacji komunikujących się z kilku adresów ip... Kubernetes pod tym kątem jest bardzo słaby.
  • Odpowiedz
@tyu38: to prawda, z k8s na własnej infrze ciężko trochę. GKE ma egress gateway który to potrafi. Mimo wszystko siła k8s to jego serwer api. Co do fw, Ty nie musisz ręcznie zarządzać firewalem w tym scenariuszu, tylko zrobić zapytanie do api i wygenerować reguły. Trochę to druciarnia, ale ogólnie k8s na swoim metalu to druciarnia. Masz gołego k8s, docker ee, czy openshifta?
  • Odpowiedz
@sz__po: Nie do końca rozumiem co masz na myśli pisząc "Co do fw, Ty nie musisz ręcznie zarządzać firewalem w tym scenariuszu, tylko zrobić zapytanie do api i wygenerować reguły." Te reguły mam ręcznie pisać na każdym Nodzie w iptables? API to masz na myśli "Service" jak przy Load Balancerze w drugą stronę?

Ogólnie to mam własne, gołe środowisko dockerowe (wspomagane przez docker-compose). Cała komunikacja między dockerami i środowiskiem zewnętrznym robiona jest ręcznie, bez żadnych NAT'ów. Docker engine uruchamiany jest z flagą iptables=false. Teraz chcę zebrać wszystkie dockery z różnych maszyn i przenieść je na gołego Kubernetesa. I tak sobie eksperymentuję, buduję środowisko odkrywając problemy, których nie mogę odpuścić.

Np puszcza mnie niemiłosiernie przy budowaniu firewall, czyli Network Policy. Jak miałem odpowiedzialny plugin za sieć w postaci Weave, to raz działało, raz nie. Raz wystarczyło zrestartować POD'a i wszystkie reguły zachowywały się losowo. Zmieniłem na Calico i wszystkie reguły wcześniej napisane działają tak jak powinny i żadnych problemów z nimi niema. A były to te same pliki konfiguracyjne! Matrix
  • Odpowiedz