מבוא קצר ל-Kustomize

הערה. תרגום: המאמר נכתב על ידי Scott Lowe, מהנדס בעל ניסיון רב ב-IT, שהוא המחבר/השותף של שבעה ספרים מודפסים (בעיקר ב-VMware vSphere). כעת הוא עובד בחברת הבת שלה VMware Heptio (נרכשה ב-2016), המתמחה במחשוב ענן וב-Kubernetes. הטקסט עצמו משמש כהקדמה תמציתית וקל להבנה לניהול תצורה עבור Kubernetes באמצעות טכנולוגיה התאמה אישית, שהפך לאחרונה לחלק מ-K8s.

Kustomize הוא כלי המאפשר למשתמשים "להתאים אישית קבצי YAML פשוטים ללא תבניות למטרות שונות, ולהשאיר את YAML המקורי שלם ושמיש" (תיאור מושאל ישירות מ kustomize מאגר ב- GitHub). ניתן להפעיל את Kustomize ישירות או, החל מ-Kubernetes 1.14, להשתמש בו kubectl -k כדי לגשת לפונקציונליות שלו (אם כי נכון ל-Kubernetes 1.15, הבינארי הנפרד חדש יותר מהיכולות המובנות ב-kubectl). (הערה. תרגום: ועם השחרור האחרון קוברנטס 1.16 להסתכל נתמך על ידי גם בכלי השירות kubeadm.) בפוסט זה, אני רוצה להציג לקוראים את היסודות של kustomize.

בצורה/אפליקציה הפשוטה ביותר שלה, kustomize הוא פשוט אוסף של משאבים (קבצי YAML המגדירים אובייקטים של Kubernetes: Deployments, Services וכו') בתוספת רשימה של הוראות לשינויים שיש לבצע במשאבים אלה. בדיוק כפי ש-make משתמש בערכת ההוראות הכלולה ב Makefile, ו-Docker בונה את הקונטיינר בהתבסס על הוראות מ Dockerfile, התאמה אישית של שימושים kustomization.yaml לאחסן הוראות לגבי השינויים שהמשתמש רוצה לבצע בקבוצת משאבים.

הנה קובץ לדוגמה kustomization.yaml:

resources:
- deployment.yaml
- service.yaml
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

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

• שדה resources מציין מה (אילו משאבים) kustomize ישתנה. במקרה זה, הוא יחפש משאבים בקבצים deployment.yaml и service.yaml בספרייה שלך (תוכל לציין נתיבים מלאים או יחסיים במידת הצורך).
• שדה namePrefix מורה ל-kustomize להוסיף קידומת מסוימת (במקרה זה - dev-) לייחס name כל המשאבים המוגדרים בשטח resources. לפיכך, אם לפריסה יש name עם משמעות nginx-deployment, התאמה אישית תעשה את זה dev-nginx-deployment.
• שדה namespace מורה ל-kustomize להוסיף את מרחב השמות הנתון לכל המשאבים. במקרה זה, פריסה ושירות ייכנסו למרחב השמות development.
• סוף סוף השדה commonLabels מכיל קבוצה של תוויות שיתווספו לכל המשאבים. בדוגמה שלנו, kustomize תקצה תווית למשאבים עם השם environment ומשמעות development.

אם המשתמש עושה זאת kustomize build . בספרייה עם הקובץ kustomization.yaml והמשאבים הדרושים (כלומר קבצים deployment.yaml и service.yaml), ואז בפלט הוא יקבל טקסט עם השינויים שצוינו ב kustomization.yaml.

הערה. תרגום: איור מתיעוד הפרויקט על השימוש ה"פשוט" ב-kustomize

ניתן להפנות את הפלט אם יש צורך לבצע שינויים:

kustomize build . > custom-config.yaml

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

kustomize build . | kubectl apply -f -

ניתן לגשת לתכונות kustomize גם באמצעות kubectl -k (מאז גרסה 1.14 של Kubernetes). עם זאת, זכור כי חבילת kustomize העצמאית מתעדכנת מהר יותר מחבילת kubectl המשולבת (לפחות זה המקרה עם המהדורה Kubernetes 1.15).

הקוראים עשויים לשאול: "למה כל המורכבות הזו אם אתה יכול לערוך את הקבצים ישירות?" שאלה מצוינת. בדוגמה שלנו, אכן אחד יכול לשנות קבצים deployment.yaml и service.yaml ישירות, אבל מה אם הם מזלג של פרויקט של מישהו אחר? שינוי קבצים ישירות מקשה (אם לא בלתי אפשרי) לבצע בסיס מחדש של מזלג כאשר מתבצעים שינויים במקור/מקור. שימוש ב-kustomize מאפשר לרכז את השינויים הללו בקובץ kustomization.yaml, משאירים את הקבצים המקוריים שלמים ובכך מקלים על בסיס מחדש של הקבצים המקוריים במידת הצורך.

היתרונות של kustomize מתגלים במקרים שימוש מורכבים יותר. בדוגמה לעיל kustomization.yaml והמשאבים נמצאים באותה ספרייה. עם זאת, kustomize תומך במקרים שבהם יש תצורת בסיס וגרסאות רבות שלה, הידוע גם בשם שכבות-על. לדוגמה, משתמש רצה לקחת Deployment and Service עבור nginx, שהשתמשתי בו כדוגמה, וליצור גרסאות פיתוח, היערכות והפקה (או גרסאות) של הקבצים הללו. לשם כך הוא יזדקק לשכבות האמורות לעיל ולמעשה למשאבים הבסיסיים עצמם.

כדי להמחיש את הרעיון של שכבות-על ומשאבים בסיסיים (משאבי בסיס), נניח שלספריות יש את המבנה הבא:

- base
  - deployment.yaml
  - service.yaml
  - kustomization.yaml
- overlays
  - dev
    - kustomization.yaml
  - staging
    - kustomization.yaml
  - prod
    - kustomization.yaml

בקובץ base/kustomization.yaml משתמשים המשתמשים בשדה resources פשוט הכריז על המשאבים ש-kustomize צריך לכלול.

בכל אחד מהקבצים overlays/{dev,staging,prod}/kustomization.yaml משתמשים מתייחסים לתצורת הבסיס בשדה resources, ולאחר מכן ציין שינויים ספציפיים עבור סביבה נתונה. למשל, קובץ overlays/dev/kustomization.yaml עשוי להיראות כמו הדוגמה שניתנה קודם לכן:

resources:
- ../../base
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

במקרה זה הקובץ overlays/prod/kustomization.yaml יכול להיות שונה לגמרי:

resources:
- ../../base
namePrefix: prod-
namespace: production
commonLabels:
  environment: production
  sre-team: blue

כאשר המשתמש רץ kustomize build . בקטלוג overlays/dev, kustomize תייצר את אפשרות הפיתוח. אם אתה רץ kustomize build . בקטלוג overlays/prod - אתה מקבל את אפשרות הייצור. וכל זה - מבלי לבצע שינויים במקור (בסיס) קבצים, הכל בצורה הצהרתית ודטרמיניסטית. אתה יכול לבצע את התצורה הבסיסית ואת ספריות שכבת העל ישירות לבקרת גרסאות, בידיעה שבהתבסס על קבצים אלה אתה יכול לשחזר את התצורה הרצויה בכל עת.

הערה. תרגום: איור מתיעוד הפרויקט על שימוש בשכבות-על ב-kustomize

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

משאבים נוספים

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

• שנה את תצורת הבסיס של YAML עבור סביבות שונות צור/בדוק באמצעות Kustomize;
• Kustomize - הדרך הנכונה לעשות תבנית ב- Kubernetes;
• ניהול הצהרתי של אובייקטי Kubernetes באמצעות התאמה אישית;
• התאמה אישית של תרשימי ההגה במעלה הזרם עם התאמה אישית.

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

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

נ.ב מהמתרגם

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

• «כלים למפתחי אפליקציות הפועלות על Kubernetes";
• «Kubernetes 1.14: סקירה כללית של החידושים העיקריים";
• «חמש תוצאות עיקריות של Helm Summit 2019 באמסטרדם";
• «היכרות מעשית למנהל החבילות של Kubernetes - Helm".

מקור: www.habr.com