שַׁגְרִיר. 1. הקדמה

ברכות! זהו מאמר קצר שעונה על השאלות: "מהו שליח?", "למה זה נחוץ?" ו"מאיפה להתחיל?".

מה זה

Envoy הוא מאזן L4-L7 שנכתב ב-C++, המתמקד בביצועים גבוהים וזמינות. מצד אחד, זה בדרך כלשהי אנלוגי של nginx והפרוקסי, הדומה בביצועים אליהם. מצד שני, הוא מכוון יותר לארכיטקטורת מיקרו-שירותים ויש לו פונקציונליות לא גרועה יותר ממאזני java ו-go, כגון zuul או traefik.

טבלת השוואה של האפרוקסי/nginx/שליח, היא לא מתיימרת להיות האמת המוחלטת, אבל נותנת תמונה כללית.

nginx
הפרוקסי
שלח
טראפיק

כוכבים ב-github
11.2k/מראה
1.1k/מראה
12.4k
27.6k

כתוב ב
C
C
C + +
go

API
לא
שקע בלבד/דחיפה
מטוס נתונים/משיכה
למשוך

בדיקת בריאות פעילה
לא
כן
כן
כן

פתח מעקב
תוסף חיצוני
לא
כן
כן

Jwt
תוסף חיצוני
לא
כן
לא

הארכה
Lua/C
Lua/C
Lua/C++
לא

בשביל מה

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

• רתיעה סטטית.

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

לעת עתה, השתמש ב-nginx עבור סטטיקה.

• תצורה סטטית.

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

בעת עריכת התצורה ב-yaml, אתה תטעה, תנזוף במפתחים על מילוליות ותחשוב שתצורות nginx/haproxy, למרות שהן פחות מובנות, הן תמציתיות יותר. זו הנקודה. התצורה של Nginx ו-Haproxy נוצרה לעריכה ביד, ו שלח להפקה מקוד. כל התצורה מתוארת ב פרוטובוף, יצירת אותו מקבצי פרוטו היא הרבה יותר קשה לטעות.

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

משימות שהשליח חיוני להן:

• איזון תנועה במערכות מורכבות ודינמיות. זה כולל את רשת השירות, אבל היא לא בהכרח היחידה.
• הצורך בפונקציונליות מעקב מבוזרת, הרשאות מורכבות או פונקציונליות אחרת הזמינה ב שלח מחוץ לקופסה או מיושם בצורה נוחה, אבל ב-nginx/haproxy אתה צריך להיות מוקף ב-lua ותוספים מפוקפקים.

שניהם, במידת הצורך, מספקים ביצועים גבוהים.

אֵיך מַפעִילִים אֶת זֶה

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

תצורה סטטית של envoy.yaml

static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address:
        protocol: TCP
        address: 0.0.0.0
        port_value: 10000
    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.config.filter.network.http_connection_manager.v2.HttpConnectionManager
          stat_prefix: ingress_http
          route_config:
            name: local_route
            virtual_hosts:
            - name: local_service
              domains: ["*"]
              routes:
              - match:
                  prefix: "/"
                route:
                  host_rewrite: www.google.com
                  cluster: service_google
          http_filters:
          - name: envoy.router
  clusters:
  - name: service_google
    connect_timeout: 0.25s
    type: LOGICAL_DNS
    # Comment out the following line to test on v6 networks
    dns_lookup_family: V4_ONLY
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: service_google
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: www.google.com
                port_value: 443
    transport_socket:
      name: envoy.transport_sockets.tls
      typed_config:
        "@type": type.googleapis.com/envoy.api.v2.auth.UpstreamTlsContext
        sni: www.google.com

תצורה דינמית

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

• אימות תצורה.

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

• קשרים ארוכים.

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

• בדיקות בריאות אקטיביות.

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

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

תְצוּרָה שלח (מהקובץ למעלה) יש את הישויות הבאות:

• מאזין - מאזין תלוי ב-ip/יציאה ספציפיים
• מארח וירטואלי - - - מארח וירטואלי לפי שם דומיין
• מַסלוּל - כלל איזון
• אשכול - קבוצה של עליות עם פרמטרי איזון
• נקודת סיום - כתובת מופע במעלה הזרם

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

השירותים נקראים בהתאמה: LDS, VHDS, RDS, CDS ו-EDS. אתה יכול לשלב תצורה סטטית ודינמית, עם המגבלה שלא ניתן לציין משאב דינמי בתצורה סטטית.

עבור רוב המשימות, מספיק ליישם את שלושת השירותים האחרונים, הם נקראים ADS (שירות גילוי מצטבר), עבור תאווה ועבור לשם יש יישום מוכן של gRPC dataplane שבו אתה רק צריך למלא את האובייקטים מהמקור שלך.

התצורה לובשת את הצורה הבאה:

תצורה דינמית של envoy.yaml

dynamic_resources:
  ads_config:
    api_type: GRPC
    grpc_services:
      envoy_grpc:
        cluster_name: xds_clr
  cds_config:
    ads: {}
static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address:
        protocol: TCP
        address: 0.0.0.0
        port_value: 10000
    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.config.filter.network.http_connection_manager.v2.HttpConnectionManager
          stat_prefix: ingress_http
          rds:
            route_config_name: local_route
            config_source:
              ads: {}
          http_filters:
          - name: envoy.router
  clusters:
  - name: xds_clr
    connect_timeout: 0.25s
    type: LOGICAL_DNS
    dns_lookup_family: V4_ONLY
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: xds_clr
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: xds
                port_value: 6565

כשאתה רץ שלח עם התצורה הזו, הוא יתחבר למישור הבקרה וינסה לבקש את תצורת RDS, CDS ו-EDS. מתואר כיצד תהליך האינטראקציה מתרחש כאן.

בקצרה, שלח שולח בקשה המציינת את סוג המשאב המבוקש, הגרסה והפרמטרים של הצומת. בתגובה, הוא מקבל משאב וגרסה; אם הגרסה במישור הבקרה לא השתנתה, היא לא מגיבה.
ישנן 4 אפשרויות אינטראקציה:

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

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

הדוגמה שלנו משתמשת ב-ADS - זרם אחד עבור RDS, CDS, EDS ומצב לא מצטבר. כדי להפעיל מצב אינקרמנטלי, עליך לציין api_type: DELTA_GRPC

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

חימום

על שלח בעת האתחול או בעת קבלת תצורה חדשה ממטוס בקרה, תהליך חימום המשאב יוצא לדרך. זה מחולק לחימום מאזינים וחימום אשכול. הראשון מופעל כאשר יש שינויים ב-RDS/LDS, השני כאשר CDS/EDS. משמעות הדבר היא שאם רק במעלה הזרמים משתנים, המאזין לא נוצר מחדש.

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

אם המאזין נוצר מחדש, הישן עובר למצב DRAIN ויימחק לאחר סגירת כל החיבורים או פג תוקף הזמן הקצוב --drain-time-s, ברירת מחדל 10 דקות.

המשך.

מקור: www.habr.com