İngress-NGİNX və NGINX Ingress Controller arasında fərqlər

Konfiqurasiya tam düzgün görünürdü. Backend 200 qaytarırdı, service endpoint işlək görünür, controller loglarında xəta yox idi. Amma brauzer 404 xəta kodunu verirdi.

Bu yazı NGINX Inc.-in (F5) kubernetes-ingress controlleri test edən zaman qarşılaşdığım fərqləri addım-addım, real texniki detallarla bölüşür. Ümumi simptom sadə idi: mikroservisin UI-ı açılmırdı və araşdırma səhv annotasiyalardan TLS terminasiyasına qədər bir neçə mərhələyədək uzandı:

Qeyd: host adları və konkret dəyərlər ümumiləşdirilib (app.internal.local, svc-ui və s.). Diaqnostika metodologiyası və texniki səbəblər olduğu kimi saxlanılıb.

Başlanğıc simptom

Brauzerdə tək bir xəta görürdüm:

https://app.internal.local:30002/  → 404 Not Found

Bu 404 iki şeyə eyni anda işarə edirdi: nə TLS düzgün terminasiya edilirdi, nə də sorğu UI servisə çatırdı. Yəni problem bir yerdə deyil, zəncirin bir neçə həlqəsində idi.

1. Annotasiyalar?

İlk baxdığım Ingress annotasiyaları oldu:

metadata:
  annotations:
    nginx.ingress.kubernetes.io/backend-protocol: HTTPS
    nginx.ingress.kubernetes.io/enable-global-auth: "false"
    nginx.ingress.kubernetes.io/service-upstream: "true"

Bu annotasiyalar community ingress-nginx (k8s.io/ingress-nginx) controller-i üçündür. Mənim işlətdiyim controller isə NGINX Inc.-in nginx.org/ingress-controller-i idi — tamam başqa bir məhsul.

Ən çaşdırıcı hissə bu oldu: NGINX Inc. controller-i nginx.ingress.kubernetes.io/* annotasiyalarını səssizcə görməzdən gəlir. Nə xəbərdarlıq, nə xəta — sanki annotasiyalar sadəcə buxarlanmışdı. Heç bir təsir göstərmir, amma səni heç nə ilə xəbərdar da etmir.

Nəticə: backend-protocol: HTTPS işləmirdi, ona görə controller backend-ə HTTP sorğular göndərirdi. Backend isə 8443 (TLS) portunda dinləyirdi.

Aşağıda qeyd elədiyim annotasiyanı əlavə etməklə controllerin backend-e https ilə sorğu göndərməsi təmin edilir:

nginx.org/ssl-services: "svc-ui"

ssl-services əlavə etsəm də hələ də Uİ açılmırdı və loglar digər səbəbləri göstərirdi:

kubectl -n <ingress-ns> logs deploy/<controller> | grep -iE "taken|rejected"

'Rejected' host app.internal.local is taken by another resource
'Rejected' All hosts are taken by other resources

Başqa mikroservis də eyni host-u paylaşıdığından (path-əsaslı marşrutlaşdırma: bir host, hər xidmət öz path-ında) xətalar davam edirdi. Bu memarlıq ingress-nginx ilə problemsiz işləyirdi, çünki:

• Community ingress-nginx eyni host-dakı bir neçə Ingress-i avtomatik birləşdirir.
• NGINX Inc. isə birləşdirmir — eyni host-a sahib çıxan Ingress-lərdən yalnız ən köhnəsi qalır, qalanları isə istifadə edə bilmir.

Həll: Mergeable Ingress (master/minion)

NGINX Inc.-də eyni host-u bir neçə Ingress arasında bölmək üçün mergeable ingress modeli var və qısa olaraq əsas fərqlərini qeyd edirəm:

• Master — Yalnız host-u və host səviyyəli konfiqurasiyanı (TLS) təyin edir. Host üzərində yalnız bir master ola bilər.
• Minion — Hər bir ingress rule üçün təyin edilməlidir. Qısaca olaraq ingress rule-da sadece annotasiya əlavə edilməlidir.

Master annotasiyalı ingress rule:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-host-master
  namespace: app-ns
  annotations:
    nginx.org/mergeable-ingress-type: "master"
spec:
  ingressClassName: <class>
  rules:
  - host: app.internal.local   # PATH YOXDUR

Minion annotasiyalı ingress rule:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: svc-ui
  namespace: app-ns
  annotations:
    nginx.org/mergeable-ingress-type: "minion"
    nginx.org/ssl-services: "svc-ui"
spec:
  ingressClassName: <class>
  rules:
  - host: app.internal.local
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: svc-ui
            port:
              number: 8443

Bir vacib fakt, xüsusən çox namespace-li arxitekturalar üçün: NGINX Inc.-ə görə mergeable ingress resursları eyni və ya müxtəlif namespace-lərdə ola bilər — yəni cross-namespace işləyir. (Cross-namespace configuration | NGINX Documentation)

Master və minion düzgün konfiqurasiya edildikdə loglar:

'Normal' AddedOrUpdated  Configuration for <ns>/app-host-master was added or updated
'Normal' AddedOrUpdated  Configuration for <ns>/svc-ui was added or updated

Və nginx -T çıxışı düzgün blok göstərir:

server {
    server_name app.internal.local;
    location / {
        set $service "svc-ui";
        # location for minion app-ns/svc-ui
        proxy_pass https://<upstream>;   # ssl-services işlədi → https
    }
}

proxy_pass https:// — yəni ssl-services da işə düşdü, backend-ə artıq HTTPS sorğu gedir.

3. TLS terminasiyası

Bir sual qalmışdı: niyə HTTPS (443) işləmir?

TLS-i terminasiya etmək üçün master rule-a spec.tls əlavə etmək gərəklidir: (TLS host səviyyəlidir → master-də konfiqurasiya olunur, minion-da yox)

spec:
  ingressClassName: <class>
  tls:
  - hosts:
    - app.internal.local
    secretName: app.internal.local
  rules:
  - host: app.internal.local

Bundan sonra brauzerdə UI tam işlək oldu.

Yekun: nə öyrəndim?

1. Controller identifikasiyası birinci addımdır. “nginx” adı iki fərqli məhsulu gizlədir. Annotasiya prefiksləri, birləşdirmə davranışı və TLS dəstəyi tamam fərqlidir.

2. Annotasiyalar fərqlidir. Səhv annotasiyalar nə xəta, nə xəbərdarlıq verir — sadəcə işləmir. nginx -T ilə faktiki generasiya olunan konfiqurasiyaya baxmaq bunu tez üzə çıxarır.

3. TLS terminasiyasının harada olduğunu dəqiq bil. L4 balanslaşdırıcı (keepalived, LVS) TLS terminasiya etmir. Terminasiya ya controller-də (spec.tls), ya da L7 proxy-də olmalıdır. Zəncirdə "TLS-i kim terminasiya edir?" sualının aydın cavabı olmalıdır.

Bu yazı məhsulun testi zamanı qarşılaşdığım fərqliliklər əsasında hazırlanıb. Məqsədim diaqnostika metodologiyasını bölüşməkdir.