כיצד לחבר אשכולות Kubernetes במרכזי נתונים שונים

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

המומחה של היום הוא דניאל פולנצ'יק (דניאל פולנצ'יץ'). דניאל עובד כמדריך ומפתח תוכנה ב Learnk8s.

אם אתה רוצה לענות על השאלה שלך בפוסט הבא, פנה אלינו במייל או טוויטר: @learnk8s.

פספסתם פוסטים קודמים? מצא אותם כאן.

כיצד לחבר אשכולות Kubernetes במרכזי נתונים שונים?

בקצרה: Kubefed v2 בקרוב, ואני גם ממליץ לקרוא על השולח и פרויקט מתזמן רב אשכולות.

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

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

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

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

ניתן לארח את האשכולות שלך בעננים שונים ובמקום.

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

אשכול מנהיגות אחד

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

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

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

ובאותו הזמן יש לך טבלאות ניתוב ישנות (kube-proxy לא יכול להוריד חדשים) וללא פודים נוספים (kubelet לא יכול לבקש עדכונים).

כדי להחמיר את המצב, אם Kubernetes לא רואה צומת, הוא מסמן אותו כיתום ומפיץ את התרמילים החסרים לצמתים קיימים.

כתוצאה מכך, יש לך פי שניים יותר תרמילים.

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

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

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

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

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

etcd כל כך רגיש לאחביון התיעוד הרשמי ממליץ להשתמש בכונני SSD במקום בכוננים קשיחים רגילים.

כרגע אין דוגמאות טובות לרשת גדולה לאשכול בודד.

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

אפשרות 1: פדרציית אשכולות עם kubefed

תגובה רשמית מאת SIG-cluster - kubefed2, גרסה חדשה של הלקוח והמפעיל המקורי של הפדרציה של kube.

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

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

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

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

זה היה בלגן מוחלט.

SIG-cluster עשה עבודה רבה לאחר kubefed v1 והחליט לגשת לבעיה מזווית אחרת.

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

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

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

הנה דוגמה למסירה משולבת עם קטעי מיקום ועקיפה.

apiVersion: types.federation.k8s.io/v1alpha1
kind: FederatedDeployment
metadata:
  name: test-deployment
  namespace: test-namespace
spec:
  template:
    metadata:
      labels:
        app: nginx
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
            - image: nginx
              name: nginx
  placement:
    clusterNames:
      - cluster2
      - cluster1
  overrides:
    - clusterName: cluster2
      clusterOverrides:
        - path: spec.replicas
          value: 5

כפי שאתה יכול לראות, ההיצע מתחלק על פני שני אשכולות: cluster1 и cluster2.

האשכול הראשון מספק שלושה העתקים, והשני מוגדר ל-5.

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

apiVersion: scheduling.federation.k8s.io/v1alpha1
kind: ReplicaSchedulingPreference
metadata:
  name: test-deployment
  namespace: test-ns
spec:
  targetKind: FederatedDeployment
  totalReplicas: 9
  clusters:
    A:
      weight: 1
    B:
      weight: 2

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

שימו עין על kubefed2, אבל זכרו שהוא עדיין לא מתאים לייצור.

למידע נוסף על kubefed2 מאת מאמר רשמי על kubefed2 בבלוג על Kubernetes וב מאגר רשמי של פרויקט kubefed.

אפשרות 2: שילוב אשכולות בסגנון Booking.com

המפתחים של Booking.com לא עבדו על kubefed v2, אבל הם הגיעו עם Shipper - מפעיל למסירה במספר אשכולות, במספר אזורים ובכמה עננים.

השולח דומה במקצת ל-kubefed2.

שני הכלים מאפשרים לך להתאים אישית את אסטרטגיית הפריסה מרובת אשכולות שלך (באיזה אשכולות משתמשים וכמה העתקים יש להם).

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

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

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

כמו כן, השולח מוגבל מאוד.

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

במקום מסירה רגילה, עליך ליצור משאב יישומים הכולל תרשים הגה:

apiVersion: shipper.booking.com/v1alpha1
kind: Application
metadata:
  name: super-server
spec:
  revisionHistoryLimit: 3
  template:
    chart:
      name: nginx
      repoUrl: https://storage.googleapis.com/shipper-demo
      version: 0.0.1
    clusterRequirements:
      regions:
        - name: local
    strategy:
      steps:
        - capacity:
            contender: 1
            incumbent: 100
          name: staging
          traffic:
            contender: 0
            incumbent: 100
        - capacity:
            contender: 100
            incumbent: 0
          name: full on
          traffic:
            contender: 100
            incumbent: 0
    values:
      replicaCount: 3

Shipper היא אפשרות טובה לניהול אשכולות מרובים, אבל הקשר הקרוב שלו עם Helm רק מפריע.

מה אם כולנו נעבור מהלם ל להסתכל או קפיטן?

למידע נוסף על Shipper והפילוסופיה שלו בכתובת הודעה רשמית לעיתונות זו.

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

אפשרות 3: מיזוג אשכולות "קסם".

Kubefed v2 ו-Shipper עובדים עם פדרציית אשכולות, ומספקים משאבים חדשים לאשכולות באמצעות הגדרת משאבים מותאמת אישית.

אבל מה אם אתה לא רוצה לשכתב את כל המשלוחים, StatefulSets, DaemonSets וכו' כדי להתמזג?

כיצד לכלול אשכול קיים בפדרציה מבלי לשנות את YAML?

multi-cluster-scheduler הוא פרויקט אדמירליות, העוסק בתזמון עומסי עבודה באשכולות.

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

כל תרמיל שנוצר מוחלף מיד בדמה.

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

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

לבסוף, התרמיל מועבר לאשכול היעד.

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

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

כל משאב שיוצר פוד מוכן אוטומטית למיזוג.

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

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

אין לו מנגנון משלוח הדרגתי מתקדם.

ניתן למצוא עוד על מתזמן רב אשכולות בכתובת דף המאגר הרשמי.

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

כלים ופתרונות אחרים

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

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

• צוללת מאת רנצ'ר הוא כלי המחבר בין רשתות שכבת-על של אשכולות Kubernetes שונים.
• רשת קמעונאית מטרה שימושים Unimatrix בשילוב עם Spinnaker כדי לתזמר פריסה על פני אשכולות מרובים.
• נסה להשתמש ב-IPV6 ו רשת אחת במספר אזורים.
• אתה יכול להשתמש ברשת שירות, למשל Istio לחיבור מספר אשכולות.
• Cilium, תוסף ממשק רשת קונטיינר, מציע פונקציית רשת אשכול, המאפשר לשלב מספר אשכולות

זה הכל להיום

תודה שקראת עד הסוף!

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

נוסיף את השיטה שלך לקישורים.

תודה מיוחדת לכריס נסביט-סמית' (כריס נסביט-סמית') ו וינסנט דה סמה (וינסנט דה סמט) (מהנדס אמינות ב swatmobile.io) לקריאת המאמר ושיתוף מידע שימושי על אופן פעולת הפדרציה.

מקור: www.habr.com