כיצד פוד Kubernetes מקבל כתובת IP?

הערה. תרגום: מאמר זה, שנכתב על ידי מהנדס SRE מ-LinkedIn, מפרט את הקסם הפנימי ב-Kubernetes - ליתר דיוק, האינטראקציה של CRI, CNI ו-kube-apiserver - שקורה כאשר לפוד הבא צריך להקצות כתובת IP.

אחת הדרישות הבסיסיות דגם רשת Kubernetes הוא שלכל פוד חייב להיות כתובת IP משלו וכל פוד אחר באשכול חייב להיות מסוגל ליצור איתו קשר בכתובת זו. ישנם "ספקי" רשת רבים (Flannel, Calico, Canal וכו') שעוזרים ליישם מודל רשת זה.

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

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

כמה מושגי יסוד

קונטיינרים והרשת: סקירה קצרה

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

מיכלים על מארח אחד

דרך אחת לארגן תקשורת באמצעות כתובות IP בין קונטיינרים הפועלים על אותו מארח כוללת יצירת גשר לינוקס. לשם כך, מכשירים וירטואליים נוצרים ב-Kubernetes (ו- Docker) veth (אתרנט וירטואלי). קצה אחד של מכשיר ה-Veth מתחבר למרחב השמות של הרשת של המכולה, הקצה השני ל גשר לינוקס ברשת המארחת.

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

מיכלים על מארחים שונים

Encapsulation של מנות היא שיטה אחת המאפשרת למיכלים בצמתים שונים לתקשר זה עם זה באמצעות כתובות IP. ב-Flannel, הטכנולוגיה אחראית להזדמנות זו. vxlan, אשר "אורזת" את החבילה המקורית לתוך חבילת UDP ולאחר מכן שולחת אותה ליעדה.

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

הערה: זוהי רק דרך אחת לארגן תקשורת רשת בין קונטיינרים.

מה זה CRI?

CRI (ממשק זמן ריצה של מיכל) הוא תוסף המאפשר ל-kubelet להשתמש בסביבות זמן ריצה שונות של מיכל. ה-CRI API מובנה בזמני ריצה שונים, כך שמשתמשים יכולים לבחור את זמן הריצה לפי בחירתם.

מה זה CNI?

פרויקט CNI הוא מִפרָט לארגן פתרון רשת אוניברסלי עבור מיכלי לינוקס. בנוסף, הוא כולל תוספים, אחראי על פונקציות שונות בעת הקמת רשת פודים. הפלאגין CNI הוא קובץ הפעלה התואם את המפרט (נדון בכמה תוספים בהמשך).

הקצאת רשתות משנה לצמתים להקצאת כתובות IP לתרמילים

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

בקר IPAM של צומת

כאשר nodeipam הועבר כפרמטר דגל --controllers kube-בקר-מנהל, הוא מקצה תת-רשת נפרדת (podCIDR) לכל צומת מ-Cluster CIDR (כלומר, טווח כתובות ה-IP עבור רשת האשכול). מכיוון ש-podCIDRs אלה אינם חופפים, ניתן יהיה להקצות לכל פוד כתובת IP ייחודית.

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

$ kubectl get no <nodeName> -o json | jq '.spec.podCIDR'
10.244.0.0/24

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

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

תזמון פוד לצומת מסוים מפעיל את שרשרת האירועים הבאה:

עזרה: ארכיטקטורה של תוספי Containerd CRI.

אינטראקציה בין זמן ריצה של מיכל ותוספי CNI

לכל ספק רשת יש תוסף CNI משלו. זמן הריצה של המכולה מריץ אותו כדי להגדיר את הרשת עבור הפוד עם הפעלתו. במקרה של containerd, תוסף CNI מופעל על ידי הפלאגין Containerd CRI.

יתרה מכך, לכל ספק יש סוכן משלו. הוא מותקן בכל הצמתים של Kubernetes והוא אחראי על תצורת הרשת של הפודים. סוכן זה כלול בתצורת ה-CNI או יוצר אותו באופן עצמאי בצומת. התצורה עוזרת לפלאגין CRI להגדיר לאיזה תוסף CNI להתקשר.

ניתן להתאים אישית את המיקום של תצורת ה-CNI; כברירת מחדל הוא נמצא ב /etc/cni/net.d/<config-file>. מנהלי אשכולות אחראים גם להתקנת תוספי CNI בכל צומת אשכול. גם מיקומם ניתן להתאמה אישית; ספריית ברירת מחדל - /opt/cni/bin.

בעת שימוש ב-containerd, ניתן להגדיר את הנתיבים עבור תצורת הפלאגין והקבצים הבינאריים בקטע [plugins.«io.containerd.grpc.v1.cri».cni] в קובץ התצורה של containerd.

מכיוון שאנו משתמשים ב-Flannel כספק הרשת שלנו, בואו נדבר קצת על ההגדרה:

• פלאנלד (הדמון של פלנל) מותקן בדרך כלל באשכול כ-DaemonSet עם install-cni כמו מיכל init.
• Install-cni יוצר קובץ תצורה של CNI (/etc/cni/net.d/10-flannel.conflist) בכל צומת.
• פלנלד יוצר התקן vxlan, מאחזר מטא-נתונים של הרשת משרת ה-API ומנטר עדכוני תרמילים. כשהם נוצרים, הוא מפיץ מסלולים לכל התרמילים ברחבי האשכול.
• מסלולים אלו מאפשרים לתרמילים לתקשר זה עם זה באמצעות כתובות IP.

למידע מפורט יותר על עבודתו של פלנל, אני ממליץ להשתמש בקישורים בסוף המאמר.

להלן תרשים של האינטראקציה בין תוסף Containerd CRI לתוספי CNI:

כפי שניתן לראות לעיל, ה-kubelet קורא לפלאגין Containerd CRI כדי ליצור את הפוד, ולאחר מכן קורא לפלאגין CNI כדי להגדיר את הרשת של הפוד. תוך כדי כך, תוסף ה-CNI של ספק הרשת קורא לתוספי CNI ליבה אחרים כדי להגדיר היבטים שונים של הרשת.

אינטראקציה בין תוספים של CNI

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

פלאנל תוסף CNI

כאשר משתמשים ב-Flannel כספק רשת, רכיב ה-CRI של Containerd מתקשר פלאנל תוסף CNIבאמצעות קובץ התצורה של CNI /etc/cni/net.d/10-flannel.conflist.

$ cat /etc/cni/net.d/10-flannel.conflist
{
  "name": "cni0",
  "plugins": [
    {
      "type": "flannel",
      "delegate": {
         "ipMasq": false,
        "hairpinMode": true,
        "isDefaultGateway": true
      }
    }
  ]
}

התוסף Flanell CNI עובד בשילוב עם Flanelleld. במהלך האתחול, פלנלד מאחזר podCIDR ופרטים אחרים הקשורים לרשת משרת ה-API ושומר אותם בקובץ /run/flannel/subnet.env.

FLANNEL_NETWORK=10.244.0.0/16 
FLANNEL_SUBNET=10.244.0.1/24
FLANNEL_MTU=1450 
FLANNEL_IPMASQ=false

הפלנל CNI משתמש בנתונים מ /run/flannel/subnet.env כדי להגדיר ולהתקשר לפלאגין גשר CNI.

CNI plugin Bridge

תוסף זה נקרא עם התצורה הבאה:

{
  "name": "cni0",
  "type": "bridge",
  "mtu": 1450,
  "ipMasq": false,
  "isGateway": true,
  "ipam": {
    "type": "host-local",
    "subnet": "10.244.0.0/24"
  }
}

כאשר קוראים לו בפעם הראשונה, הוא יוצר גשר לינוקס עם «name»: «cni0», שמצוין בתצורה. לאחר מכן נוצר זוג וות' עבור כל תרמיל. קצה אחד שלו מחובר למרחב השמות של הרשת של המכולה, הקצה השני כלול בגשר לינוקס ברשת המארחת. CNI plugin Bridge מחבר את כל הקונטיינרים המארח לגשר לינוקס ברשת המארחת.

לאחר שסיים להגדיר את צמד ה-Veth, תוסף Bridge קורא לפלאגין IPAM CNI המקומי המארח. ניתן להגדיר את סוג הפלאגין של IPAM בתצורת ה-CNI שבה משתמש הפלאגין של ה-CRI כדי לקרוא לפלאנל CNI.

תוספים IPAM CNI מקומיים מארח

גשר שיחות CNI תוסף IPAM CNI מקומי מארח עם התצורה הבאה:

{
  "name": "cni0",
  "ipam": {
    "type": "host-local",
    "subnet": "10.244.0.0/24",
    "dataDir": "/var/lib/cni/networks"
  }
}

תוסף IPAM מקומי מארח (IP Address Management - ניהול כתובות IP) מחזירה את כתובת ה-IP עבור הקונטיינר מרשת המשנה ומאחסנת את ה-IP המוקצה על המארח בספרייה המצוינת בסעיף dataDir - /var/lib/cni/networks/<network-name=cni0>/<ip>. קובץ זה מכיל את המזהה של המכולה שאליו מוקצית כתובת ה-IP הזו.

בעת קריאה לפלאגין IPAM המקומי המארח, הוא מחזיר את הנתונים הבאים:

{
  "ip4": {
    "ip": "10.244.4.2",
    "gateway": "10.244.4.3"
  },
  "dns": {}
}

תקציר

Kube-controller-manager מקצה podCIDR לכל צומת. הפודים של כל צומת מקבלים כתובות IP ממרחב הכתובות בטווח ה-podCIDR המוקצה. מכיוון שה-podCIDRs של הצמתים אינם חופפים, כל הפודים מקבלים כתובות IP ייחודיות.

מנהל האשכול של Kubernetes מגדיר ומתקין את kubelet, זמן הריצה של קונטיינר, סוכן ספק הרשת, ומעתיק את התוספים של CNI לכל צומת. במהלך ההפעלה, סוכן ספק הרשת יוצר תצורת CNI. כאשר פוד מתוזמן לצומת, הקובלט קורא לפלאגין CRI כדי ליצור אותו. לאחר מכן, אם נעשה שימוש ב-containerd, הפלאגין Containerd CRI קורא לפלאגין CNI שצוין בתצורת ה-CNI כדי להגדיר את הרשת של הפוד. כתוצאה מכך, הפוד מקבל כתובת IP.

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

תזכור

מכולות ורשת

• סקירה כללית של רשת קונטיינרים
• ביטול המסתורין של רשת קונטיינרים

איך פלנל עובד?

• Flanell Networking Demystify
• Kubernetes With Flanell - הבנת הרשת

CRI ו-CNI

• ארכיטקטורת תוסף CRI
• מפרט CNI
• תוספים של CNI

נ.ב מהמתרגם

קרא גם בבלוג שלנו:

• «Calico לנטוורקינג ב-Kubernetes: היכרות וקצת ניסיון";
• "מדריך מאויר לרשת ב-Kubernetes": חלקים 1 ו-2 (דגם רשת, רשתות שכבת על), חלק 3 (שירותים ועיבוד תעבורה);
• «Container Networking Interface (CNI) - ממשק רשת ותקן לקונטיינרים של לינוקס".

מקור: www.habr.com