לפני זמן לא רב עמדתי בפני משימה מאוד לא שגרתית של הגדרת ניתוב עבור MetalLB. הכל יהיה בסדר, כי... בדרך כלל MetalLB לא דורשת פעולות נוספות, אבל במקרה שלנו יש לנו אשכול די גדול עם תצורת רשת פשוטה מאוד.

במאמר זה אספר לך כיצד להגדיר ניתוב מבוסס מקור ומבוסס מדיניות עבור הרשת החיצונית של האשכול שלך.

אני לא אפרט על התקנה והגדרה של MetalLB, מכיוון שאני מניח שכבר יש לך ניסיון. אני מציע ללכת ישר לעניין, כלומר להגדיר ניתוב. אז יש לנו ארבעה מקרים:

מקרה 1: כאשר לא נדרשת תצורה

בואו נסתכל על מקרה פשוט.

תצורת ניתוב נוספת אינה נדרשת כאשר הכתובות שהונפקו על ידי MetalLB נמצאות באותה רשת משנה כמו הכתובות של הצמתים שלך.

לדוגמה, יש לך רשת משנה 192.168.1.0/24, יש לו נתב 192.168.1.1, והצמתים שלך מקבלים כתובות: 192.168.1.10-30, ואז עבור MetalLB אתה יכול להתאים את הטווח 192.168.1.100-120 והיו בטוחים שהם יעבדו ללא כל תצורה נוספת.

למה? מכיוון שלצמתים שלך כבר מוגדרים מסלולים:

# ip route
default via 192.168.1.1 dev eth0 onlink 
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10

וכתובות מאותו טווח יעשו בהן שימוש חוזר ללא פעולות נוספות.

מקרה 2: כאשר נדרשת התאמה אישית נוספת

עליך להגדיר מסלולים נוספים בכל פעם שאין לצמתים שלך כתובת IP מוגדרת או נתיב לרשת המשנה שעבורה MetalLB מנפיקה כתובות.

אני אסביר קצת יותר בפירוט. בכל פעם ש- MetalLB מוציאה כתובת, ניתן להשוות אותה להקצאה פשוטה כמו:

ip addr add 10.9.8.7/32 dev lo

שים לב ל:

• a) הכתובת מוקצית עם קידומת /32 כלומר, מסלול לא יתווסף אוטומטית לרשת המשנה עבורו (זו רק כתובת)
• b) הכתובת מצורפת לכל ממשק צומת (לדוגמה loopback). כדאי להזכיר כאן את התכונות של מחסנית רשת לינוקס. לא משנה לאיזה ממשק תוסיף את הכתובת, הקרנל תמיד יעבד בקשות arp וישלח תגובות arp לכל אחת מהן, התנהגות זו נחשבת לנכונה ויותר מכך, נמצאת בשימוש נרחב למדי בסביבה דינמית כזו כמו Kubernetes.

ניתן להתאים התנהגות זו, למשל על ידי הפעלת arp קפדנית:

echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

במקרה זה, תגובות arp יישלחו רק אם הממשק מכיל במפורש כתובת IP ספציפית. הגדרה זו נדרשת אם אתה מתכנן להשתמש ב-MetalLB וה-kube-proxy שלך פועל במצב IPVS.

עם זאת, MetalLB אינה משתמשת בליבה לעיבוד בקשות arp, אלא עושה זאת בעצמה במרחב המשתמש, כך שהאפשרות הזו לא תשפיע על פעולת MetalLB.

בואו נחזור למשימה שלנו. אם המסלול עבור הכתובות שהונפקו לא קיים בצמתים שלך, הוסף אותו מראש לכל הצמתים:

ip route add 10.9.8.0/24 dev eth1

מקרה 3: כאשר אתה צריך ניתוב מבוסס מקור

תצטרך להגדיר ניתוב מבוסס מקור כאשר אתה מקבל מנות דרך שער נפרד, לא זה שהוגדר כברירת מחדל, לכן גם מנות תגובה צריכות לעבור דרך אותו שער.

לדוגמה, יש לך את אותה רשת משנה 192.168.1.0/24 מוקדש לצמתים שלך, אבל אתה רוצה להנפיק כתובות חיצוניות באמצעות MetalLB. נניח שיש לך מספר כתובות מרשת משנה 1.2.3.0/24 ממוקם ב-VLAN 100 וברצונך להשתמש בהם כדי לגשת לשירותי Kubernetes באופן חיצוני.

בעת יצירת קשר 1.2.3.4 אתה תגיש בקשות מרשת משנה אחרת מאשר 1.2.3.0/24 ומחכה לתשובה. הצומת שהוא כרגע המאסטר עבור הכתובת שהונפקה MetalLB 1.2.3.4, יקבל את החבילה מהנתב 1.2.3.1, אבל התשובה עבורו חייבת ללכת בהכרח באותו מסלול, דרך 1.2.3.1.

מכיוון שלצומת שלנו כבר יש שער ברירת מחדל מוגדר 192.168.1.1, אז כברירת מחדל התגובה תעבור אליו, ולא אל 1.2.3.1, שדרכו קיבלנו את החבילה.

איך להתמודד עם המצב הזה?

במקרה זה, עליך להכין את כל הצמתים שלך בצורה כזו שהם מוכנים לשרת כתובות חיצוניות ללא תצורה נוספת. כלומר, עבור הדוגמה לעיל, אתה צריך ליצור ממשק VLAN על הצומת מראש:

ip link add link eth0 name eth0.100 type vlan id 100
ip link set eth0.100 up

ואז הוסף מסלולים:

ip route add 1.2.3.0/24 dev eth0.100 table 100
ip route add default via 1.2.3.1 table 100

שימו לב שאנו מוסיפים מסלולים לטבלת ניתוב נפרדת 100 הוא יכיל רק שני מסלולים הדרושים לשליחת חבילת תגובה דרך השער 1.2.3.1, הממוקם מאחורי הממשק eth0.100.

כעת עלינו להוסיף כלל פשוט:

ip rule add from 1.2.3.0/24 lookup 100

שאומר במפורש: אם כתובת המקור של החבילה נמצאת 1.2.3.0/24, אז אתה צריך להשתמש בטבלת הניתוב 100. בו כבר תיארנו את המסלול שישלח אותו דרכו 1.2.3.1

מקרה 4: כאשר אתה צריך ניתוב מבוסס מדיניות

טופולוגיית הרשת זהה לזו שבדוגמה הקודמת, אבל נניח שאתה גם רוצה להיות מסוגל לגשת לכתובות מאגר חיצוניות 1.2.3.0/24 מהתרמילים שלך:

המוזרות היא שכאשר ניגשים לכל כתובת ב 1.2.3.0/24, חבילת התגובה פוגעת בצומת ויש לה כתובת מקור בטווח 1.2.3.0/24 יישלח בצייתנות ל eth0.100, אבל אנחנו רוצים ש-Kubernetes יפנה אותו אל הפוד הראשון שלנו, שיצר את הבקשה המקורית.

פתרון בעיה זו התברר כקשה, אך זה הפך אפשרי הודות לניתוב מבוסס מדיניות:

להבנה טובה יותר של התהליך, הנה תרשים בלוקים של netfilter:

ראשית, כמו בדוגמה הקודמת, בואו ניצור טבלת ניתוב נוספת:

ip route add 1.2.3.0/24 dev eth0.100 table 100
ip route add default via 1.2.3.1 table 100

עכשיו בואו נוסיף כמה כללים ל-iptables:

iptables -t mangle -A PREROUTING -i eth0.100 -j CONNMARK --set-mark 0x100
iptables -t mangle -A PREROUTING  -j CONNMARK --restore-mark
iptables -t mangle -A PREROUTING -m mark ! --mark 0 -j RETURN
iptables -t mangle -A POSTROUTING -j CONNMARK --save-mark

כללים אלה יסמנו חיבורים נכנסים לממשק eth0.100, סימון כל החבילות בתג 0x100, גם תגובות בתוך אותו חיבור יסומנו באותו תג.

כעת נוכל להוסיף כלל ניתוב:

ip rule add from 1.2.3.0/24 fwmark 0x100 lookup 100

כלומר, כל החבילות עם כתובת מקור 1.2.3.0/24 ותייגו 0x100 יש לנתב באמצעות טבלה 100.

לפיכך, מנות אחרות המתקבלות בממשק אחר אינן כפופות לכלל זה, מה שיאפשר ניתובן באמצעות כלי Kubernetes סטנדרטיים.

יש עוד דבר אחד, בלינוקס יש מה שנקרא מסנן נתיב הפוך, שמקלקל את כל העניין, הוא מבצע בדיקה פשוטה: עבור כל החבילות הנכנסות, הוא משנה את כתובת המקור של החבילה עם כתובת השולח ובודק אם החבילה יכולה לצאת דרך אותו ממשק שבו היא התקבלה, אם לא, היא תסנן אותה.

הבעיה היא שבמקרה שלנו זה לא יעבוד כמו שצריך, אבל אנחנו יכולים להשבית את זה:

echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth0.100/rp_filter

שים לב שהפקודה הראשונה שולטת בהתנהגות הגלובלית של rp_filter; אם היא לא מושבתת, לפקודה השנייה לא תהיה השפעה. עם זאת, שאר הממשקים יישארו עם rp_filter מופעל.

כדי לא להגביל לחלוטין את פעולת המסנן, נוכל להשתמש ביישום rp_filter עבור netfilter. באמצעות rpfilter כמודול iptables, אתה יכול להגדיר כללים גמישים למדי, למשל:

iptables -t raw -A PREROUTING -i eth0.100 -d 1.2.3.0/24 -j RETURN
iptables -t raw -A PREROUTING -i eth0.100 -m rpfilter --invert -j DROP

הפעל את rp_filter בממשק eth0.100 לכל הכתובות למעט 1.2.3.0/24.

מקור: www.habr.com