מרחבי שמות וקבוצות שרת בלינוקס: הבסיס האמיתי של קונטיינרים

אינפורמטק דיגיטל » Recursos » מרחבי שמות וקבוצות שרת בלינוקס: הבסיס האמיתי של קונטיינרים

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

לאורך מאמר זה נסקור ברוגע אך מבלי להיכנס לפרטים רבים מדי כיצד הם פועלים מרחבי שמות (מה שתהליך יכול לראות) וקבוצות שרת (מה שתהליך יכול להשתמש בו)כיצד Docker ו-Kubernetes מנצלים אותם; כיצד ניתן להתעסק איתם ברמה נמוכה באמצעות פקודות כמו unshare, ip netns או כתיבה ישירה ב /sys/fs/cgroupואילו טריקים שימושיים לביצועים, אבטחה ופתרון בעיות בסביבות ייצור.

מה בעצם עושה קונטיינר בלינוקס?

כשאתה מפעיל משהו כמו docker runמכונה וירטואלית קסומה לא נוצרת; מה שאתה מקבל הוא תהליך לינוקס (או קבוצת תהליכים) עם בידוד חזק ומשאבים מוגבלים.ה"טריק" מבוסס על ארבעה מנגנוני ליבה:

• שמותהם שולטים במה שהתהליך רואה (PID, רשת, מערכת קבצים, שם מארח וכו').
• Cgroupsהם שולטים בכמות האנרגיה שהתהליך יכול להשתמש בה (מעבד, זיכרון RAM, קלט/פלט, PID...).
• מבודד Chroot / rootfsהם נותנים לתהליך מערכת קבצים משלו.
• תהליכי לינוקס רגיליםבסופו של דבר, הכל מסתכם ב-PIDs של מארחים המנוהלים על ידי הליבה.

במילים אחרות, קונטיינר הוא פשוט תהליך הפועל עם קבוצה של מרחבי שמות חדשים, מקוננים בתוך קבוצת קבצים אחת או יותר, ועם מערכת קבצים מותאמת אישית . השאר מטופל על ידי הכלי (Docker, containerd, runc וכו') באמצעות אוטומציה וממשקי API ידידותיים למשתמש.

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

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

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

סוגים עיקריים של מרחבי שמות

כל סוג של מרחב שמות מבודד ממד שונה. מקובל להשתמש בכמה מהם בו זמנית במכולה "רצינית". אלו הם החשובים ביותר:

• מרחב השמות PIDמבודד את מרחב מזהה התהליך. בתוך המכולה, התהליך העיקרי הוא בדרך כלל PID 1אפילו אם למארח יש מספר שונה. תהליכים ממרחבי שמות שונים יכולים להיות בעלי אותו PID מבלי להפריע זה לזה, והם אינם יכולים לשלוח אותות זה לזה אלא אם כן המארח מותר במפורש.
• מרחב השמות של רשת (NET)יוצר מחסנית רשת עצמאית, עם ממשקים, נתיבים, כללי חומת אש, שקעים וכו' משלו. לכל קונטיינר יש לולאה חוזרת משלו, כתובות IP משלו וניתוב משלובדרך זו, ניתן לעשות שימוש חוזר באותה כתובת IP במרחבי שמות שונים ללא התנגשות ולהחיל כללי iptables מבודדים.
• מרחב השמות של הר (MNT): מפריד בין הנוף לנקודות ההרכבה. תהליכים רואים רק את היררכיית הקבצים של מרחב השמות שלהם.למרות שיש מתחת ל-bind mounts, כרכים משותפים, שכבות-על וכו'. זה מה שמאפשר למכולה להיראות כאילו יש לה "/" משלה מבלי לגעת בשורש האמיתי של המארח.
• מרחב השמות UTS: שולט בשם המארח ובדומיין NIS. בתוך מרחב שמות UTS, ניתן לשנות את שם המארח מבלי להשפיע על מערכת המארחשימושי מאוד להבחנה בין מכולות או סימולציה של צמתים בסביבות בדיקה.
• מרחב השמות של IPCמבודד תורי הודעות, סמפורות וזיכרון משותף של System V. מניעת הפרעה של תהליכי קונטיינרים שונים ל-IPC עקב תאונה או תכנון לקוי.
• מרחב שמות משתמשכנראה העדין ביותר. זה מאפשר מיפוי UID ו-GID פנימיים של מרחבי שמות למזהי מארח אחריםזה מאפשר למפות את ה"שורש" בתוך המכולה למשתמש לא מורשה במארח, מה שמפחית מאוד את הסיכון להסלמת הרשאות ומשפר את... אבטחת מכולות.
• מרחב השמות Cgroupמספק תצוגה וירטואלית של /proc/self/cgroup והיררכיה של קבוצות ה-c. מתוך המכולה, רק הקבוצות שלה נראות.זה מסתיר את המבנה האמיתי של המארח ומחזק את הבידוד.
• מרחב שמות זמןמאפשר הצעה תפיסות זמן שונות (שעונים כמו CLOCK_MONOTONIC או CLOCK_BOOTTIME) עבור קבוצות תהליכים שונות. זה שימושי לבדיקת תרחישים או לבידוד עדין מאוד.

כל מרחבי השמות הללו חשופים ב /proc/<pid>/ns/וניתן ליצור או לשלב אותם עם כלים כגון unshare y nsenterכאשר התהליך האחרון השייך למרחב שמות מת, מרחב השמות הזה נהרס אוטומטית.

ניסוי עם מרחבי שמות משורת הפקודה

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

unshare --pid --fork --mount-proc bash
ps aux
echo $$

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

מרחבי שמות רשת בפירוט

היבט הרשת הוא אחד המגוונים ביותר. בעת יצירת מרחב שמות של NET עם ip netns addאתה מקבל מחסנית ריקה מלבד מחסנית הלולאה החוזרת. משם אתה יכול:

• חבר את מרחב השמות הזה למארח עם זוג veth (שני ממשקים וירטואליים המחוברים באמצעות כבל לוגי).
• צור גשרים סוג br0 ולחבר מספר מרחבי שמות לגשר זה כדי שיוכלו לראות זה את זה באמצעות כתובות IP פרטיות.
• NAT והעברה לתת גישה לאינטרנט לאותם "קונטיינרים ביתיים" עם iptables ו- /proc/sys/net/ipv4/ip_forward.

זה נכון, ברמה נמוכה מאוד, זה מה שדוקר עושה עם הגשר docker0 ורשתות ברירת המחדל שלהן: זה מגדיר מרחבי שמות של רשת, עמיתים של veth, גשרים וכללי NAT. כדי שהמיכלים יוכלו לדבר אחד עם השני ולצאת החוצה.

מרחבי שמות של משתמשים והרכבה עבור rootfs ואבטחה

בעזרת `mount namespace` ניתן להתנסות ביצירת מערכת קבצים של קונטיינר מבלי להשתמש ב-Docker. הדפוס האופייני הוא:

• כדי להרכיב או להכין rootfs מינימלי (לדוגמה, minirootfs של Alpine שהורד על ידי wget וחולץ לספרייה).
• צור מרחב שמות של הרכבה ובצע pivot_root o chroot לספרייה הזו.
• לרכוב /proc, /sys ומערכות פסאודו אחרות בתוך השורש החדש.

עם זאת, המעטפת שלך תראה רק את מערכת הקבצים הזו, אבל אתה נשאר תהליך מארח רגיל, עם ה-PID האמיתי שלך וניתן לשליטה על ידי מנהל המערכת.אם אתה משתמש גם במרחב שמות משתמש עם --map-root-userיכול להיות לך "root" בפנים שנמצא מחוץ למשתמש ללא הרשאות.

Cgroups: כמה משאבים כל תהליך יכול להשקיע

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

ברמה מושגית, קבוצה קבוצתית היא ספרייה בתוך /sys/fs/cgroup עם קבצים המתארים מגבלות, סדרי עדיפויות ומדדיםכאשר מוסיפים PID לקובץ המתאים (לדוגמה, cgroup.procs), תהליך זה כפוף לכללים אלה.

בקרי משאבים בקבוצות קבוצתיות

קבוצות C מורכבות מבקרים (תת-מערכות) הפועלים על משאבים ספציפיים. בין הנפוצים ביותר הם:

• CPU: שולט בזמן המוקצה למעבד. עם מניות מגדיר עדיפות יחסית; עם מכסה מגבלות קשות (למשל, פסק זמן של 50 אלפיות שנייה למעבד לכל פרק זמן של 100 אלפיות שנייה); עם ערכות מעבדים אתה מתקן תהליכים לליבות ספציפיות.
• זכרוןמגביל את זיכרון ה-RAM ואת ה-swap. מאפשר מגבלות קשות ורכות, הגדרות OOM Killer, סטטיסטיקות ועומס זיכרוןשימושי מאוד למניעת שימוש בשירות כולו בשרת.
• בלוק קלט/פלט (blkio / io)מגביל רוחב פס ו-IOPS לכל מכשיר. אתה יכול הקצאת משקל פרופורציונלי או קביעת מגבלות מדויקות ב-bights/s ops/s.
• רשתקיימים מנגנונים להגבלת רוחב פס וחבילות, אם כי התמיכה פחות בוגרת ובדרך כלל משולבת עם tc ו-QoS.
• PIDs: לסמן את מספר מקסימלי של תהליכים/הליכים אשר יכול ליצור קבוצה, ובכך להפחית שגיאות קוד (fork bombs) שמפעילות שרשורים (threads).

הרעיון המעשי הוא פשוט מאוד: אתם ממקמים את האפליקציה שלכם ב-cgroup ומציינים את המעבד, הזיכרון, הקלט/פלט וה-PID המרביים . משם, הליבה דואגת לאכיפת הכללים.

cgroups v1 לעומת cgroups v2

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

• cgroup v1לכל בקר יש היררכיה עצמאית משלו. יש לך נתיבים כמו /sys/fs/cgroup/cpu/..., /sys/fs/cgroup/memory/..., וכו ' זה גמיש אך מסובך לניהול בקנה מידה גדול.הפצות ופלטפורמות קלאסיות רבות עדיין משתמשות בו או תומכות בו לצורך תאימות.
• cgroup v2מקבץ הכל תחת אחד היררכיה מאוחדת en /sys/fs/cgroupהמגבלות מוגדרות באמצעות קבצים כגון cpu.max, memory.max, io.max ו דומה. זה מפשט את הניהול ומשפר את כוונון המשאביםהפצות מודרניות נוטות להשתמש בגרסה 2 כברירת מחדל, לפעמים עם מצב היברידי.

En /proc/cgroups ניתן לראות אילו בקרים מופעלים, כמה cgroups פעילות יש, והאם אתם נמצאים בגרסה 1 או גרסה 2 (בגרסה 2 תראו היררכיה מאוחדת עם מזהה 0). הפקודה mount | grep cgroup זה גם אומר לך את סוג מערכת הקבצים (cgroup2fs מרמז על v2, tmpfs (בדרך כלל מצביע על גרסה 1).

יצירה ידנית של קבוצות גישה ומגבלות אופייניות

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

• צור ספריית cgroup.
• הגדרת קבצי הגבלה/עדיפות (מעבד, זיכרון, קלט/פלט, PID...).
• הוסף PID לקבוצת ה-c על ידי הקלדת cgroup.procs o tasks (בגרסה 1).

לדוגמה, ב-cgroups גרסה 2, יכול להיות משהו כזה עבור המעבד והזיכרון:

mkdir /sys/fs/cgroup/test_app
echo "+cpu +memory +io +pids" > /sys/fs/cgroup/cgroup.subtree_control
echo "50000 100000" > /sys/fs/cgroup/test_app/cpu.max
echo "512M" > /sys/fs/cgroup/test_app/memory.max
echo $$ > /sys/fs/cgroup/test_app/cgroup.procs

בכך, התהליך הנוכחי מוגבל ל 50% מהליבה ו-512 מגה-בייט של זיכרון RAMאם אתה מתחיל משהו אינטנסיבי (א dd ל-/dev/null, לדוגמה), תראו שהמערכת לא משתגעת. ב-cgroups גרסה 1, הסכימה דומה אבל עם קבצים כמו cpu.shares, cpu.cfs_quota_us, memory.limit_in_bytesוכו', כל אחד בהיררכיה משלו.

כיצד Docker, Kubernetes והליבה מתערבבים

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

"מחסנית" המכולות הטיפוסית כיום נראית כך:

• שכבת התזמורKubernetes, Docker Swarm, Nomad... הם מטפלים במחזור החיים של הפוד/שירות, תזמון, קנה מידה ותמיכה. ארכיטקטורות מיקרו-שירותים.
• זמן ריצה של מכולה ברמה גבוההמנוע Docker, מבוסס קונטיינר, CRI-O. הם מקבלים את הוראות התזמור והופכים אותן לפעולות קונקרטיות. (הורדת תמונות, יצירת קונטיינרים, ניהול תמונות מצב וכו').
• זמן ריצה של OCI ברמה נמוכהכלי Runc, Crun וכלים דומים מיישמים את מפרט OCI ואחראים ישירות על יישומו. הם מתקשרים clone(), unshare(), mount() וחברה כדי לממש את המכולה.
• ליבת לינוקסהוא מספק מרחבי שמות, קבוצות משתמש, OverlayFS וכל שאר הפרימיטיבים. כאן קורה ה"קסם" האמיתי.

כשאתה זורק docker runהנתיב הוא: client CLI → dockerd → containerd → runc → kernel calls. לאורך נתיב זה נוצרים מרחבי שמות, מוקצים cgroups, קובץ ה-rootfs מורכב עם אמצעי האחסון OverlayFS plus, וממשקי הרשת והגשר מחוברים. מה שאתה רואה כ"מיכל" הוא, עבור הליבה, קומץ תהליכים עם דגלים מסוימים ונתיבים מיוחדים.

דרישות ובדיקות מוקדמות במערכת

לפני שאתם מתחילים להתעסק עם מרחבי שמות וקבוצות שרת (cgroups) בשרת, מומלץ לוודא שהחומרה והליבה עומדים בדרישות מינימום סבירות , במיוחד אם אתם מתכננים להקים משהו דומה לסביבת ייצור.

כנקודת התייחסות, בדרך כלל מומלצים לפחות 2 מעבדים לוגיים, 4 ג'יגה-בייט של זיכרון RAM (עדיף 8 ג'יגה-בייט או יותר) , כ-20 ג'יגה-בייט של שטח דיסק פנוי, וליבה 3.10 ומעלה (רצוי 4.x או 5.x כדי לקבל את כל התכונות של cgroups v2 ותכונות מודרניות).

כדי לוודא שהגרעין תומך במרחבי שמות ובקבוצות משתמש (cgroups), פשוט בדוק את קובץ התצורה של הגרסה שבשימוש:

grep -E "CONFIG_.*_NS" /boot/config-$(uname -r)
grep -E "CONFIG_CGROUP" /boot/config-$(uname -r)

אפשרויות כאלה אמורות להופיע שם CONFIG_NAMESPACES, CONFIG_PID_NS, CONFIG_NET_NS, CONFIG_CGROUPS, CONFIG_MEMCG, CONFIG_CGROUP_SCHED מסומן כ =yבלי זה, לא יהיה לך הרבה משחק.

פרט מעשי נוסף הוא האם המערכת מאפשרת צור מרחבי שמות של משתמשים מבלי להיות rootזה מאוד שימושי לבדיקות ולכמה כלים. זה נשלט באמצעות sysctl. kernel.unprivileged_userns_cloneאם זה ב-0, תצטרכו להפעיל אותו (או להשתמש בזיעה שלכם בכל מקום).

חקר קבוצות שרת ומרחבי שמות במכונות "אמיתיות"

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

• ls /proc/self/ns/ זה מראה לך את מרחבי השמות שאליהם שייך המעטפת הנוכחית שלך (cgroup, ipc, mnt, net, pid, user, uts…).
• systemd-cgtop זה מראה את השימוש במעבד, בזיכרון ובקלט/פלט לפי cgroup, בדומה מאוד ל- top אך מקובצים לפי שירותים ומכולות.
• En /sys/fs/cgroup ניתן לאתר את קבוצות ה-cgroup ש-Docker או Podman יוצרים עבור כל קונטיינר, בדרך כלל באמצעות מזהה הקונטיינר בנתיב. בפנים, cgroup.procs רשום את ה-PIDs הקשורים.
• /proc/<pid>/cgroup זה אומר לך לאילו קבוצות ניהול (cgroups) מוקצה תהליך מסוים, מושלם למעקב אחר אפליקציה בעייתית.

תראו שמכולות הן פשוט עוד ענף בהיררכיית cgroups, עם מגבלות המעבד, הזיכרון, ה-blkio ומגבלות אחרות שלהן, בדיוק כפי שניתן ליצור אותן באופן ידני . היופי של Docker הוא שהוא עושה זאת באופן אוטומטי ועם API ידידותי למשתמש.

אסטרטגיות ביצועים, NUMA וזיקה

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

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

mkdir /sys/fs/cgroup/cpuset/dedicated_cpus
echo "4-7" > /sys/fs/cgroup/cpuset/dedicated_cpus/cpuset.cpus
echo "0" > /sys/fs/cgroup/cpuset/dedicated_cpus/cpuset.mems
echo 1 > /sys/fs/cgroup/cpuset/dedicated_cpus/cpuset.cpu_exclusive

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

ברמת הזיכרון, שילוב של numactl עם cgroups (או שימוש ישיר בלחצני NUMA של בקר הזיכרון כאשר זמינים) מסייע לשמור נתונים בצומת הפיזי הקרוב ביותר לליבות המשתמשות בו. זה מורגש ביישומים רגישים להשהייה.

ניטור ותצפית של קבוצות שרת ומרחבי שמות

קביעת מגבלות משאבים זה בסדר, אבל אם לא תמדדו מה קורה, אתם עלולים לירות לעצמכם ברגל מבלי אפילו לשים לב.cgroup v2 עצמו מציע לא מעט מדדים שימושיים ביומנים. *.stat, *.events y *.pressure.

כמה דוגמאות מעשיות:

• cpu.stat זה אומר לך כמה זמן CPU הקבוצה השתמשה בו, כמה פעמים היא הופרדה וכו'.
• memory.current y memory.max הם מציגים את צריכת הזרם ואת המגבלה המוגדרת.
• memory.events הוא רושם OOMs, גבולות רכים שהושגו ופחדים אחרים.
• io.stat צובר קריאות/כתיבות לכל מכשיר.

לסקירה מהירה, systemd-cgtop זה מאוד פרקטי, ואם אתם רוצים משהו יותר תעשייתי, כלים כמו cAdvisor הם מייצאים מדדי Docker/containerd cgroup ל-Prometheus, מה שמאפשר לך לבנות לוחות מחוונים שלמים ב-Grafana ללא יותר מדי מאמץ, אידיאלי עבור צג מערכת מתקדם.

בעת ניפוי באגים בבעיות במרחב השמות, סקריפטים פשוטים שחוצים /proc/<pid>/ns/ ולהשוות את הקישורים הסמליים המסייעים ל כדי לדעת אילו תהליכים חולקים בדיוק את אותו מרחב שמות, או לאתר מרחב שמות רשת "אבוד" שנתקע.

שימוש ב- systemd כמנהל קבוצות קבוצתיות

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

שירות המוצהר עם הנחיות כגון:

CPUQuota=50%
CPUWeight=500
MemoryMax=512M
IOReadBandwidthMax=/dev/sda 10M

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

עבור צוותים המשלבים שירותים מסורתיים עם קונטיינרים (נפוץ מאוד), הסתמכות על systemd לקביעת מגבלות על דמונים קריטיים היא דרך אלגנטית למנוע הריגת משאבים על ידי הפודים בסביבה המקונטיינרית.

בסביבות עם עומסי עבודה מרובים, החל ממסדי נתונים ועד סוכני ניטור ויישומים מותאמים אישית, שליטה במרחבי שמות וקבוצות ניהול (cgroups) מאפשרת לך להגדיר מדיניות בידוד חזקה, להתאים את איכות השירות ולהבטיח שלכל רכיב יש הקצאה מבוקרת היטב של CPU וזיכרון . הבנת האופן שבו Docker, Kubernetes ו-systemd ממנפים את יכולות הליבה הללו מציידת אותך בתכנון תשתיות מרובות-דיירים מאובטחות יותר, ניפוי שגיאות בבעיות מורכבות (מ-OOMs ועד צווארי בקבוק של קלט/פלט) ולהפיק את המרב מהחומרה שלך מבלי להתפשר על יציבות.