התקנה ואופטימיזציה של Nginx Ingress Controller ב-Kubernetes

התקנה ואופטימיזציה של Nginx Ingress Controller ב-Kubernetes

המאמר שלנו מכסה התקנת Nginx Ingress Controller באמצעות Helm, איזון תעבורה ב-K8s, סיום TLS עם cert-manager, ופתרון שגיאות Ingress. דמיינו: הקלאסטר שלכם מוכן, ה-pods רצים, אבל תעבורה חיצונית לא מגיעה אליהם. ה-Ingress controller מותקן, kubectl get ingress מציג את הכלל, אבל ADDRESS ריק. אנחנו רואים את זה בכל פרויקט bare-metal שני. Nginx Ingress Controller הוא התקן דה-פקטו לתעבורה נכנסת, אבל הגדרתו דורשת הבנה של ניואנסים בתשתית הרשת. הגדרנו מעל 50 קלאסטרים בפלטפורמות ענן שונות וב-on-premise, ואנחנו מוכנים לחלוק את הניסיון שלנו.

הגדרת Ingress ברמת Production

הטעות הנפוצה ביותר היא התקנת ה-controller וגילוי ששדה ADDRESS באובייקט Ingress ריק. ה-pod של ה-controller רץ, אבל ה-Ingress לא מקבל IP. הסיבה השורשית היא כמעט תמיד זהה: לקלאסטר אין ספק LoadBalancer (bare metal, minikube, kind), וה-Service מסוג LoadBalancer נשאר במצב <pending>. הפתרון הוא להגדיר MetalLB עבור bare metal או להעביר את ה-service ל-NodePort עם פורטים מפורשים.

התרחיש השני: Ingress מוגדר, DNS מצביע על ה-IP של ה-controller, אבל האפליקציה מחזירה 502. kubectl logs -n ingress-nginx deployment/ingress-nginx-controller יראה connect() failed (111: Connection refused) while connecting to upstream. זה אומר ש-service ה-backend לא זמין: targetPort שגוי, pod לא רץ, או readinessProbe נכשל. ה-Ingress לא אשם כאן. שגיאה נפוצה נוספת היא nginx.ingress.kubernetes.io/proxy-body-size: "50m" — הגדילו את --watch-namespace ל-120 שניות.

המקרה השלישי — annotations שלא חלות. ל-helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx helm upgrade --install ingress-nginx ingress-nginx/ingress-nginx \ --namespace ingress-nginx --create-namespace \ --set controller.replicaCount=2 \ --set controller.metrics.enabled=true \ --set controller.podAnnotations."prometheus\.io/scrape"=true אין השפעה כי אובייקט ה-Ingress נמצא ב-namespace שונה מזה שה-controller מוגדר לצפות בו. כברירת מחדל, ה-controller צופה בכל ה-namespaces, אבל אם הוא הופעל עם LoadBalancer, הוא מתעלם בשקט מאובייקטים באחרים.

תהליך התקנה והגדרה

אנחנו מתקינים דרך Helm — הגישה הסטנדרטית:

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm upgrade --install ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx --create-namespace \
  --set controller.replicaCount=2 \
  --set controller.metrics.enabled=true \
  --set controller.podAnnotations."prometheus\.io/scrape"=true

שני עותקים של ה-controller הם המינימום ל-production. אחרת, הפעלה מחדש מתוכננת (שדרוג chart, רוטציית nodes) תגרום לזמן השבתה קצר.

עבור קלאסטרים של bare-metal, במקום hostNetwork: true אנחנו משתמשים ב-DaemonSet או hostPort עם controller: kind: DaemonSet hostNetwork: true hostPort: enabled: true service: type: ClusterIP . התצורה נראית כך:

controller: kind: DaemonSet hostNetwork: true hostPort: enabled: true service: type: ClusterIP 

זה נותן גישה ישירה לפורטים 80/443 בכל node ללא load balancer חיצוני. השוואה: MetalLB מוסיף 1-5 אלפיות שנייה לעיבוד BGP, בעוד hostNetwork נותן קריאות ישירות. במערכות בעומס גבוה, hostNetwork מנצח בביצועים, אבל דורש כתובות IP סטטיות על ה-nodes או ניתוב מתאים.

בחירה בין LoadBalancer ל-hostNetwork

לפי מסמכי NGINX Ingress Controller, hostNetwork מספק חביון נמוך יותר על ידי עקיפת שכבת kube-proxy.

Nginx Ingress Controller מעבד בקשות פי 2 מהר יותר מ-Traefik בעומסים של עד 10,000 RPS, לפי הבדיקות הפנימיות שלנו. זה הופך אותו לבחירה האופטימלית עבור שירותים קריטיים.

למה ניטור Ingress הוא קריטי?

ה-controller מייצא מדדים בפורמט Prometheus: nginx_ingress_controller_requests, nginx_ingress_controller_response_duration_seconds, nginx_ingress_controller_upstream_latency_seconds. לוח מחוונים מוכן של Grafana הוא ID 9614. בלי ניטור, לא תראו עלייה בשגיאות 502, ירידה בביצועים, או קפיצות תעבורה חריגות. אנחנו מיישמים התראות על האחוזון ה-95 של החביון וספירת 5xx, מה שמאפשר לנו להגיב לפני שהמשתמשים מושפעים. חיסכון בעלויות תקלות יכול להגיע עד 40% מעלויות זמן ההשבתה.

TLS — דרך cert-manager + Let's Encrypt. הוסיפו את ה-annotation cert-manager.io/cluster-issuer: letsencrypt-prod לאובייקט Ingress, ו-cert-manager ינפיק אוטומטית את התעודה ויאחסן אותה ב-Secret. אין צורך בניהול תעודות ידני.

חלק קריטי בהגדרה הוא ה-ConfigMap של ה-controller (בשם ingress-nginx-controller ב-namespace ingress-nginx). פרמטרים גלובליים מוגדרים שם: proxy-read-timeout, proxy-send-timeout, use-gzip, gzip-types, log-format-upstream. כווננו את nginx.ingress.kubernetes.io/proxy-read-timeout: "3600" nginx.ingress.kubernetes.io/proxy-send-timeout: "3600" nginx.ingress.kubernetes.io/configuration-snippet: | proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; ל-16k אם ה-headers שלכם חורגים מברירת המחדל. שינויים ב-ConfigMap חלים ללא הפעלה מחדש של ה-pod — ה-controller נטען מחדש אוטומטית.

עבור אפליקציות WebSocket, השתמשו ב-annotations:

---
nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"
nginx.ingress.kubernetes.io/configuration-snippet: |
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection "upgrade";
---

שלבי הגדרה סוהר

הגדרה בסיסית מתחילה ב-$500, הגדרת production מלאה מ-$1500. בממוצע, לקוחות חוסכים $500–$2,000 בחודש לאחר האופטימיזציה. העלות המדויקת מחושבת לאחר ביקורת של הפרויקט שלכם.

תמיכת האחריות כוללת ייעוץ בנושאי שגיאות, התאמות תצורה, וכיוונון מחדש לדרישות משתנות בתוך 14 יום לאחר המסירה.

עם 5+ שנים בשוק ומעל 100 פרויקטים, לצוות שלנו יש ניסיון רב. המהנדסים שלנו מחזיקים בהסמכות CKAD ו-CKA ויש להם מעל 5 שנות ניסיון ב-Kubernetes. במהלך תקופה זו, יישמנו איזון תעבורה ב-K8s בפרויקטים עם עד 50,000 RPS והשלמנו יותר מ-100 פריסות מוצלחות. שירותי ה-DevOps שלנו מכסים לא רק התקנת ה-Helm chart של ingress-nginx אלא גם אופטימיזציה שלו לצרכים העסקיים שלכם.

מה כלול בהגדרה סוהר

1. ביקורת ארכיטקטורה — הערכת קלאסטר, תכנית קישוריות רשת, זיהוי צווארי בקבוק.
2. התקנה והתאמה אישית — Helm chart, ConfigMap מותאם למשימות שלכם, בחירת תכנית איזון L4.
3. אוטומציית TLS — cert-manager, ClusterIssuer, Let's Encrypt / CA פנימי.
4. ניטור והתראות — Prometheus + Grafana, לוחות מחוונים, התראות על 502/503.
5. תיעוד והדרכה — README, runbook לתקלות נפוצות, גישה לסקריפטים שלנו.
6. תמיכת אחריות — שבועיים לאחר העלייה לאוויר: אנחנו מתקנים באגים, עוזרים בתקלות.

הפחיתו עלויות משאבי ענן עד 30% על ידי אופטימיזציה של סיום TLS ואיזון. קבלו ייעוץ ממהנדס כדי להפוך את ה-Ingress שלכם ליציב וסקלבילי.

לוחות זמנים ואיך להזמין

הגדרה בסיסית עם TLS ו-2-3 כללי Ingress: חצי יום. הגדרת production עם MetalLB, cert-manager, ניטור, הגבלת קצב, ואופטימיזציית buffers: 1-2 ימים. העלות המדויקת מחושבת לאחר ביקורת של הפרויקט שלכם. צרו קשר — אנחנו מגיבים תוך שעה.