Ingress, inaczej mówiąc coś na zasadzie mądrego routera z połączonego z LoadBalancera. Pozwala światu zewnętrznemu na dostęp do zasobów klastra k8s. Dla przykładu każdy naszych deploymentów może mieć serwis typu LoadBalancer która udostępnia adres IP na zewnątrz i zarządza dostępem do podów. Jednak taki LoadBalancer wymaga adresu by się do niego dostać. Weźmy 5-6 takich mikroserwisów z LoadBalancerem i mamy 5-6 adresów API do zarządzania. Nie jest o łatwe, do tego publiczne chmury nie zawsze lubią, jak mamy dużo IPków jak i pewne usługi też nie pozwalają na ściąganie danych z wielu IP.

Interesuje Cię temat konteneryzacji i Kubernetes? Potrzebujesz tej wiedzy w projekcie? Nie czekaj dołącz do kursu Poznaj Kubernetes – Właśnie trwa przedsprzedaż, która kończy się 18 września o godzinie 21:00 – KLINIJ W TEN LINK BY KUPIĆ KURS

Ingress by mógł działać musi podpiąć się pod Endpointy serwisu. Słowo klucz to usługa. Normalnie nasz deployment wystawiamy za pomocą LoadBalancer, jednak tutaj to nie ma sensu (chociaż tutaj pewny nie jestem i chciałbym kogoś mądrego do weryfikacji i rozmowy), więc zamiast LoadBalancer korzystamy po prostu z prostego serwisu tylko po to by nasz Ingress mógł się do niego odwołać:

apiVersion: v1
kind: Service
metadata:
  name: sample-api-svc
  namespace: samples
spec:
  selector:
    app: sample-api-app
  ports:
  - name: http
    port: 8080
    targetPort: 80

Nasz serwis definiuje selector do aplikacji która jest zdeployowana za pomocą deployment i to jest tutaj pominięte.

Mając serwis o nazwie sample-api-svc możemy stworzyć Ingress

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: sample-api-ingress
  namespace: samples 
  annotations:    
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/enable-cors: "true"
spec:
  rules:
    - http:
        paths:
        - path: /sample
          backend:
            serviceName: sample-api-svc
            servicePort: 8080 

TO CO TUTAJ JEST NIESAMOWICIE WAŻNE I CO TO WSZYSTKIE DOKUMENTACJE JAKIE WIDZIAŁEM MAJĄ ŹLE TO:

nginx.ingress.kubernetes.io/rewrite-target: /

A nie:

ingress.kubernetes.io/rewrite-target: /

Chodzi o brakujący pre-fix: nginx.

Ogólnie to powoduje, że nasz URL zostanie przepisany na / czyli jeżeli podamy /sample/api to zostanie to przepisane na /api.

Jeżeli nie korzystamy z rewrite-target to możliwe, że podawanie path z gwiazdką wam zadziała tak jak to opisane jest tutaj. U mnie to nie zadziałało.

Jedyne miejsce w sieci które znalazłem a które wykorzystywało nginx.ingress.kubrenetes.io zamiast ingress.kubrenetes.io to JEDEN dokument na githubie od ingress.

Bez podania poprawnego rewrite-target, zawsze dostawałem:

default backend - 404

Lub

Page Not Found
Page Not Found

Przy obrazku było o tyle fajnie, że wiedziałem, iż redirect działa tylko, że coś jest nie tak z parametrami. I tak o to czytając, przeglądając i zgadując i próbując udało się zrobić tak by działało. I to zupełnym przypadkiem. Takim rzutem na taśmę: a nóż coś zadziała… i zadziałało :)

3 KOMENTARZE

  1. Ja w deweloperskim środowisku to rozwiązywania problemów z rewrite w dockers / kubernetes polecam traefik.io . Podobny problem rozwiązuje się bardzo szybko :). Jednakże na razie jest to zbyt młode rozwiązanie, aby polecić je w wykorzystaniu produkcyjnym.

Comments are closed.