כיצד להפעיל את Istio באמצעות Kubernetes בייצור. חלק 1

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

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

עיקרון הפעולה

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

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

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

מישור הנתונים מיושם באמצעות מיכלי פרוקסי צדדיים. נעשה שימוש בעוצמה כברירת מחדל. פרוקסי שליח. ניתן להחליף אותו ביישום אחר, כגון nginx (nginmesh).

על מנת שאיסטיו תעבוד בשקיפות מוחלטת ליישומים, קיימת מערכת הזרקה אוטומטית. המימוש העדכני ביותר מתאים לגרסאות Kubernetes 1.9+ (מוטציוני admission webhook). עבור Kubernetes גרסאות 1.7, 1.8 אפשר להשתמש ב-Initializer.

מיכלי Sidecar מחוברים ל-Pilot באמצעות פרוטוקול GRPC, המאפשר לך לייעל את מודל הדחיפה לשינויים המתרחשים באשכול. GRPC נמצא בשימוש ב-Envoy מאז גרסה 1.6, ב-Istio הוא נמצא בשימוש מאז גרסה 0.8 והוא פיילוט-סוכן - עוטף גולאנג מעל שליח שמגדיר אפשרויות השקה.

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

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

1. פריסת גרסה חדשה של השירות.
2. בהתאם לגישת הזרקת מיכל הצד, מיכל istio-init ומיכל istio-agent (שליח) מתווספים בשלב החלת התצורה, או שניתן כבר להכניס אותם ידנית לתיאור של הישות Kubernetes Pod.
3. מיכל istio-init הוא סקריפט שמחיל את כללי iptables על הפוד. ישנן שתי אפשרויות להגדרת תעבורה שתהיה עטופה במיכל istio-agent: השתמש בכללי הפנייה מחדש של iptables, או TPROXY. בזמן הכתיבה, גישת ברירת המחדל היא עם כללי הפניה מחדש. ב-istio-init, ניתן להגדיר איזו תעבורה יש ליירט ולשלוח ל- istio-agent. לדוגמה, כדי ליירט את כל התעבורה הנכנסת ואת כל התנועה היוצאת, עליך להגדיר את הפרמטרים -i и -b לתוך משמעות *. אתה יכול לציין יציאות ספציפיות ליירט. כדי לא ליירט תת-רשת ספציפית, ניתן לציין אותה באמצעות הדגל -x.
4. לאחר ביצוע מיכלי ה-init, מופעלים העיקריים שבהם, כולל הטייס-סוכן (השליח). הוא מתחבר לטייס שכבר נפרס באמצעות GRPC ומקבל מידע על כל השירותים ומדיניות הניתוב הקיימים באשכול. לפי הנתונים שהתקבלו, הוא מגדיר את האשכולות ומקצה אותם ישירות לנקודות הקצה של האפליקציות שלנו באשכול Kubernetes. כמו כן, יש לשים לב לנקודה חשובה: שליח מגדיר באופן דינמי את המאזינים (IP, זוגות יציאות) שהוא מתחיל להאזין להם. לכן, כאשר בקשות נכנסות לתרמיל, מנותבות מחדש באמצעות כללי iptables להפניה מחדש ב-sidecar, ה-envoy כבר יכול לעבד את החיבורים הללו בהצלחה ולהבין היכן להמשיך להעביר את התעבורה. גם בשלב זה נשלח מידע למיקסר, עליו נבחן בהמשך, ונשלחים טווחי מעקב.

כתוצאה מכך, אנו מקבלים רשת שלמה של שרתי פרוקסי של שליחים שאנו יכולים להגדיר מנקודה אחת (Pilot). כל הבקשות הנכנסות והיוצאות עוברות דרך השליח. יתרה מכך, רק תעבורת TCP מיירטת. המשמעות היא ש-IP שירות Kubernetes נפתר באמצעות kube-dns על UDP מבלי לשנות. לאחר מכן, לאחר ההחלטה, הבקשה היוצאת מיירטת ומעובדת על ידי השליח, שכבר מחליט לאיזו נקודת קצה יש לשלוח את הבקשה (או לא לשלוח, במקרה של מדיניות גישה או מפסק החשמל של האלגוריתם).

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

מיקסר בצורתו הנוכחית מורכב משני רכיבים: istio-telemetry, istio-policy (לפני גרסה 0.8 זה היה רכיב istio-mixer אחד). שניהם מיקסרים שכל אחד מהם אחראי על המשימה שלו. טלמטריית Istio מקבלת מידע על מי הולך לאן ועם אילו פרמטרים ממכולות דיווח צדדיות דרך GRPC. Istio-policy מקבל בקשות צ'ק כדי לוודא שכללי המדיניות מתקיימים. בדיקות מדיניות לא מבוצעות, כמובן, עבור כל בקשה, אלא מאוחסנות במטמון של הלקוח (במכונית הצד) למשך זמן מסוים. בדיקות דיווח נשלחות כבקשות אצווה. בואו נראה כיצד להגדיר ואיזה פרמטרים יש לשלוח מעט מאוחר יותר.

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

לסיכום, הסכימה לעבודה עם istio-telemetry היא כדלקמן.

1. שירות 1 שולח בקשה לשירות 2.
2. ביציאה משירות 1 הבקשה עטופה בקרון צד משלה.
3. שליח Sidecar עוקב אחר אופן הפנייה של הבקשה לשירות 2 ומכין את המידע הדרוש.
4. לאחר מכן שולח אותו ל- istio-telemetry באמצעות בקשת דיווח.
5. Istio-telemetry קובעת אם יש לשלוח את הדוח הזה אל הקצה האחורי, לאילו ואיזה נתונים יש לשלוח.
6. Istio-telemetry שולח נתוני דו"ח ל-backend במידת הצורך.

כעת נראה כיצד ניתן לפרוס את Istio במערכת, המורכבת רק מהרכיבים העיקריים (פיילוט ו-sidecar envoy).

ראשית, בואו נסתכל על התצורה הראשית (רשת) שהפיילוט קורא:

apiVersion: v1
kind: ConfigMap
metadata:
  name: istio
  namespace: istio-system
  labels:
    app: istio
    service: istio
data:
  mesh: |-

    # пока что не включаем отправку tracing информации (pilot настроит envoy’и таким образом, что отправка не будет происходить)
    enableTracing: false

    # пока что не указываем mixer endpoint’ы, чтобы sidecar контейнеры не отправляли информацию туда
    #mixerCheckServer: istio-policy.istio-system:15004
    #mixerReportServer: istio-telemetry.istio-system:15004

    # ставим временной промежуток, с которым будет envoy переспрашивать Pilot (это для старой версии envoy proxy)
    rdsRefreshDelay: 5s

    # default конфигурация для envoy sidecar
    defaultConfig:
      # аналогично как rdsRefreshDelay
      discoveryRefreshDelay: 5s

      # оставляем по умолчанию (путь к конфигурации и бинарю envoy)
      configPath: "/etc/istio/proxy"
      binaryPath: "/usr/local/bin/envoy"

      # дефолтное имя запущенного sidecar контейнера (используется, например, в именах сервиса при отправке tracing span’ов)
      serviceCluster: istio-proxy

      # время, которое будет ждать envoy до того, как он принудительно завершит все установленные соединения
      drainDuration: 45s
      parentShutdownDuration: 1m0s

      # по умолчанию используются REDIRECT правила iptables. Можно изменить на TPROXY.
      #interceptionMode: REDIRECT

      # Порт, на котором будет запущена admin панель каждого sidecar контейнера (envoy)
      proxyAdminPort: 15000

      # адрес, по которому будут отправляться trace’ы по zipkin протоколу (в начале мы отключили саму отправку, поэтому это поле сейчас не будет использоваться)
      zipkinAddress: tracing-collector.tracing:9411

      # statsd адрес для отправки метрик envoy контейнеров (отключаем)
      # statsdUdpAddress: aggregator:8126

      # выключаем поддержку опции Mutual TLS
      controlPlaneAuthPolicy: NONE

      # адрес, на котором будет слушать istio-pilot для того, чтобы сообщать информацию о service discovery всем sidecar контейнерам
      discoveryAddress: istio-pilot.istio-system:15007

כל רכיבי הבקרה העיקריים (מישור הבקרה) ימוקמו ב-namespace istio-system ב-Kubernetes.

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

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

מיכל Init:

initContainers:
 - name: istio-init
   args:
   - -p
   - "15001"
   - -u
   - "1337"
   - -m
   - REDIRECT
   - -i
   - '*'
   - -b
   - '*'
   - -d
   - ""
   image: istio/proxy_init:1.0.0
   imagePullPolicy: IfNotPresent
   resources:
     limits:
       memory: 128Mi
   securityContext:
     capabilities:
       add:
       - NET_ADMIN

וקרונית צד:

       name: istio-proxy
       args:
         - "bash"
         - "-c"
         - |
           exec /usr/local/bin/pilot-agent proxy sidecar 
           --configPath 
           /etc/istio/proxy 
           --binaryPath 
           /usr/local/bin/envoy 
           --serviceCluster 
           service-name 
           --drainDuration 
           45s 
           --parentShutdownDuration 
           1m0s 
           --discoveryAddress 
           istio-pilot.istio-system:15007 
           --discoveryRefreshDelay 
           1s 
           --connectTimeout 
           10s 
           --proxyAdminPort 
           "15000" 
           --controlPlaneAuthPolicy 
           NONE
         env:
         - name: POD_NAME
           valueFrom:
             fieldRef:
               fieldPath: metadata.name
         - name: POD_NAMESPACE
           valueFrom:
             fieldRef:
               fieldPath: metadata.namespace
         - name: INSTANCE_IP
           valueFrom:
             fieldRef:
               fieldPath: status.podIP
         - name: ISTIO_META_POD_NAME
           valueFrom:
             fieldRef:
               fieldPath: metadata.name
         - name: ISTIO_META_INTERCEPTION_MODE
           value: REDIRECT
         image: istio/proxyv2:1.0.0
         imagePullPolicy: IfNotPresent
         resources:
           requests:
             cpu: 100m
             memory: 128Mi
           limits:
             memory: 2048Mi
         securityContext:
           privileged: false
           readOnlyRootFilesystem: true
           runAsUser: 1337
         volumeMounts:
         - mountPath: /etc/istio/proxy
           name: istio-envoy

כדי שהכל יתחיל בהצלחה, עליך ליצור ServiceAccount, ClusterRole, ClusterRoleBinding, CRD for Pilot, שאת התיאורים שלו ניתן למצוא כאן.

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

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

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

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

1. Pod CIDR ו-Service CIDR חייבים להיות ייחודיים בכל האשכולות ואסור להם לחפוף.
2. כל ה-CIDR Pods חייבים להיות נגישים מכל CIDR Pods בין אשכולות.
3. כל שרתי ה-API של Kubernetes חייבים להיות נגישים זה לזה.

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

מקור: www.habr.com