תיקון חורים באשכול Kubernetes. דוח ותמלול מ-DevOpsConf

Pavel Selivanov, ארכיטקט פתרונות Southbridge ומורה ל-Slurm, נשא מצגת ב-DevOpsConf 2019. הרצאה זו היא חלק מאחד הנושאים של הקורס המעמיק על Kubernetes "Slurm Mega".

Slurm Basic: מבוא ל-Kubernetes מתקיים במוסקבה ב-18-20 בנובמבר.
Slurm Mega: מסתכל מתחת למכסה המנוע של Kubernetes - מוסקבה, 22-24 בנובמבר.
Slurm Online: שני קורסי Kubernetes תמיד זמין.

מתחת לחיתוך יש תמליל של הדו"ח.

צהריים טובים, עמיתים ומי שמזדהה איתם. היום אדבר על בטיחות.

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

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

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

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

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

אני אספר לך עם דוגמאות איך עשיתי את זה ואיך להגן על עצמך מפני זה.

אבל ראשית, הרשו לי להציג את עצמי. שמי פאבל סליוונוב. אני אדריכל בסאות'ברידג'. אני מבין Kubernetes, DevOps וכל מיני דברים מפוארים. מהנדסי סאות'ברידג' ואני בונים את כל זה, ואני מתייעץ.

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

על מה אדבר היום? נושא הדוח ברור - על אבטחת אשכול Kubernetes. אבל אני רוצה לומר מיד שהנושא הזה גדול מאוד - ולכן אני רוצה להבהיר מיד על מה אני בהחלט לא אדבר. אני לא אדבר על מונחים פרוצים שכבר נעשה בהם שימוש מאה פעמים באינטרנט. כל מיני RBAC ותעודות.

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

יש ממש שלוש נקודות שעליהן אדבר היום:

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

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

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

באשכול זה יהיה לי Kubernetes v1.14.5. כל אשכול ה-Cube, אותו נשקול, מחולק למרחבי שמות, כל מרחב שמות שייך לצוות נפרד, ולחברים בצוות זה יש גישה לכל מרחב שמות. הם לא יכולים ללכת למרחבי שמות שונים, רק למרחבי השמות שלהם. אבל יש חשבון אדמין מסוים שיש לו זכויות לכל האשכול.

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

kubectl apply -f pod.yaml

התרמיל הזה יגיע לאחד המאסטרים של אשכול Kubernetes. ואחרי זה האשכול יחזיר לנו בשמחה קובץ בשם admin.conf. ב-Cube, קובץ זה מאחסן את כל אישורי המנהל, ובו זמנית מגדיר את ה-API של האשכול. כך קל לקבל גישת מנהל ל-98%, לדעתי, מאשכולות Kubernetes.

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

ועכשיו על תרמיל שהוכן במיוחד. אנחנו מריצים את זה על כל תמונה. ניקח את debian:jessie כדוגמה.

יש לנו את הדבר הזה:

tolerations:
-   effect: NoSchedule 
    operator: Exists 
nodeSelector: 
    node-role.kubernetes.io/master: "" 

מהי סובלנות? מאסטרים באשכול Kubernetes מסומנים בדרך כלל במשהו שנקרא Taint. ומהות ה"זיהום" הזה היא שהוא אומר שלא ניתן להקצות תרמילים לצמתי מאסטר. אבל אף אחד לא טורח לציין בשום תרמיל שהוא סובלני ל"זיהום". סעיף הסובלנות רק אומר שאם לצומת כלשהו יש NoSchedule, אז הצומת שלנו סובלני לזיהום כזה - ואין בעיות.

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

עם שני הקטעים האלה הוא בהחלט יגיע למאסטר. ויורשה לו לגור שם.

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

hostNetwork: true 
hostPID: true 

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

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

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

volumeMounts:
- mountPath: /host 
  name: host 
volumes:
- hostPath: 
    path: / 
    type: Directory 
  name: host 

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

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

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

לאחר מכן כל המשימה היא לעבור לתת ספריית /host /etc/kubernetes/pki, אם אני לא טועה, אסוף שם את כל תעודות המאסטר של האשכול ובהתאם לכך, הפוך למנהל האשכול.

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

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

האהוב עלי הוא משתמש Root. ול-Kubernetes יש את האפשרות Run As Non-Root. זהו סוג של הגנה מפני האקר. האם אתה יודע מה זה "הנגיף המולדבי"? אם אתה פתאום האקר ומגיע לאשכול ה-Kubernetes שלי, אז אנחנו, מנהלים גרועים, מבקשים: "נא לציין בפודים שלך איתם תפרוץ לאשכול שלי, תרוץ כבלתי שורש. אחרת, יקרה שתפעיל את התהליך בפוד שלך מתחת לשורש, ויהיה לך קל מאוד לפרוץ לי. נא להגן על עצמך מעצמך".

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

אבל מה לעשות עם כל זה?

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

זהו אובייקט yaml - אנחנו יכולים ליצור אותו באשכול Kubernetes - השולט בהיבטי אבטחה ספציפית בתיאור הפודים. כלומר, למעשה, הוא שולט בזכויות השימוש בכל hostNetwork, hostPID, סוגי אמצעי אחסון מסוימים שנמצאים ב-pods בעת ההפעלה. בעזרת Pod Security Policy, ניתן לתאר את כל זה.

הדבר המעניין ביותר במדיניות האבטחה של Pod הוא שבאשכול Kubernetes, כל מתקיני ה-PSP לא פשוט לא מתוארים בשום צורה, הם פשוט מושבתים כברירת מחדל. Pod Security Policy מופעלת באמצעות תוסף הקבלה.

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

ונראה שהכל בסדר איתנו. ואי אפשר לפרוץ לאשכול Kubernetes שלנו תוך שתי דקות.

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

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

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

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

$ curl http://prometheus-kube-state-metrics.monitoring 

prometheus-kube-state-metrics היא אחת מיצואניות Prometheus שאוספת מדדים מ-Kubernetes API עצמו. יש שם הרבה נתונים, מה פועל באשכול שלך, מה זה, אילו בעיות יש לך איתו.

כדוגמה פשוטה:

kube_pod_container_info{namespace=“kube-system”,pod=”kube-apiserver-k8s- 1″,container=”kube-apiserver”,image=

"gcr.io/google-containers/kube-apiserver:v1.14.5"

,image_id=»docker-pullable://gcr.io/google-containers/kube- apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a96 38ee634989″,container_id=»docker://7cbe7b1fea33f811fdd8f7e0e079191110268f2 853397d7daf08e72c22d3cf8b»} 1

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

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

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

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

יש דבר כזה - מדיניות רשת.

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

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

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

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

מה לעשות?

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

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

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

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

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

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

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

אז אני אראה במהירות שתי דרכים כיצד ניתן להרוס אשכול Kubernetes.

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

שיטה ראשונה. דלדול משאבים.

בואו נשיק עוד פוד מיוחד. יהיה לו קטע כזה.

resources: 
    requests: 
        cpu: 4 
        memory: 4Gi 

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

אם אני מריץ פוד כזה, אז אני אפעיל את הפקודה:

$ kubectl scale special-pod --replicas=...

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

אם נסתכל שוב על התיעוד של Kubernetes, נראה את הדבר הזה שנקרא Limit Range. הוא מגדיר משאבים עבור אובייקטי אשכול. אתה יכול לכתוב אובייקט Limit Range ב-yaml, להחיל אותו על מרחבי שמות מסוימים - ואז במרחב השמות הזה אתה יכול לומר שיש לך משאבים ברירת מחדל, מקסימום ומינימום עבור הפודים.

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

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

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

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

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

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

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

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

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

אם אתה מפעיל מיליארד פודים, למשל, ואז משתמש בסקריפט כדי לאלץ את Kubernetis ליצור שירותים חדשים:

for i in {1..1111111}; do
    kubectl expose deployment test --port 80  
        --overrides="{"apiVersion": "v1", 
           "metadata": {"name": "nginx$i"}}"; 
done 

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

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

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

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

מכסת משאבים + טווח הגבלה + RBAC
• צור מרחב שמות
• צור טווח מוגבל בפנים
• צור בתוך מכסת משאבים
• צור חשבון שירות עבור CI
• יצירת תפקידים עבור CI ומשתמשים
• אופציונלי הפעל את תרמילי השירות הדרושים

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

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

קצת מה שהופך את כל התהליך המורכב הזה לקל יותר.

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

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

LimitRange/ResourceQuota - הגיע הזמן להשתמש בו. התחלנו להשתמש בזה מזמן, והרבה זמן הייתי בטוח שכולם משתמשים בזה. התברר שזה נדיר.

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

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

כאן יש הוראות איך לשחזר את כל מה שאמרתי לך. ישנם קבצים עם דוגמאות ייצור של איך נראים ResourceQuota ו-Pod Security Policy. ואתה יכול לגעת בכל זה.

תודה לכולכם.

מקור: www.habr.com