Calico לנטוורקינג ב-Kubernetes: היכרות וקצת ניסיון

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

מבוא מהיר למכשיר הרשת של Kubernetes

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

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

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

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

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

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

זה הגיוני שיש 2 סוגי תעבורה: כניסה לפוד (Ingress) ויציאה ממנו (Egress).

למעשה, הפוליטיקה מחולקת ל-2 הקטגוריות הללו על סמך כיוון התנועה.

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

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

  podSelector: {}
  ingress: []
  policyTypes:
  - Ingress

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

  podSelector: {}
  ingress:
  - {}
  policyTypes:
  - Ingress

באופן דומה עבור יוצאים:

  podSelector: {}
  policyTypes:
  - Egress

- כדי לכבות אותו. והנה מה שצריך לכלול:

  podSelector: {}
  egress:
  - {}
  policyTypes:
  - Egress

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

היכרות עם Calico: תיאוריה

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

אילו הזדמנויות מספק השימוש בפתרון ה"קופסא" של K8s ובערכת ה-API של Calico?

הנה מה שמובנה ב-NetworkPolicy:

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

כך מרחיבה Calico את הפונקציות הללו:

• ניתן להחיל מדיניות על כל אובייקט: פוד, מיכל, מכונה וירטואלית או ממשק;
• כללים יכולים להכיל פעולה ספציפית (איסור, הרשאה, רישום);
• היעד או מקור הכללים יכולים להיות יציאה, מגוון יציאות, פרוטוקולים, תכונות HTTP או ICMP, IP או רשת משנה (דור 4 או 6), כל בורר (צמתים, מארחים, סביבות);
• בנוסף, אתה יכול לווסת את מעבר התעבורה באמצעות הגדרות DNAT ומדיניות העברת תעבורה.

ההתחייבויות הראשונות ב-GitHub במאגר Calico מתוארכות ליולי 2016, ושנה לאחר מכן תפס הפרויקט עמדה מובילה בארגון קישוריות רשת Kubernetes - על כך מעידים, למשל, תוצאות הסקר, בניצוחו של The New Stack:

הרבה פתרונות מנוהלים גדולים עם K8s, כגון אמזון EKS, תכלת AKS, גוגל GKE ואחרים החלו להמליץ ​​עליו לשימוש.

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

הפרויקט מתפתח מהר מאוד, הוא תומך בעבודה בפתרונות פופולריים מנוהלים K8s, OpenShift, OpenStack, אפשר להשתמש ב-Calico בעת פריסת אשכול באמצעות בְּעִיטָה, ישנן התייחסויות לבניית רשתות Service Mesh (הנה דוגמה בשימוש בשילוב עם Istio).

תתאמן עם Calico

במקרה הכללי של שימוש ב- Vanilla Kubernetes, התקנת CNI מסתכמת בשימוש בקובץ calico.yaml, הורדה מהאתר הרשמי, על ידי שימוש ב kubectl apply -f.

ככלל, הגרסה הנוכחית של התוסף תואמת ל-2-3 הגרסאות האחרונות של Kubernetes: הפעולה בגרסאות ישנות יותר אינה נבדקת ואינה מובטחת. לדברי המפתחים, Calico פועל על גרעיני לינוקס מעל 3.10 עם CentOS 7, Ubuntu 16 או Debian 8, על גבי iptables או IPVS.

בידוד בתוך הסביבה

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

ישנם 2 יישומי אינטרנט פרוסים באשכול: ב-Node.js וב-PHP, אחד מהם משתמש ב-Redis. כדי לחסום גישה ל-Redis מ-PHP, תוך שמירה על קישוריות עם Node.js, פשוט החל את המדיניות הבאה:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-redis-nodejs
spec:
  podSelector:
    matchLabels:
      service: redis
  ingress:
  - from:
    - podSelector:
        matchLabels:
          service: nodejs
    ports:
    - protocol: TCP
      port: 6379

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

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

apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  name: allow-redis-nodejs
spec:
  selector: service == 'redis'
  ingress:
  - action: Allow
    protocol: TCP
    source:
      selector: service == 'nodejs'
    destination:
      ports:
      - 6379

המבנים שהוזכרו לעיל לאפשר או דחיית כל תעבורה דרך ה-API הרגיל של NetworkPolicy מכילים מבנים עם סוגריים שקשה להבין ולזכור. במקרה של Calico, כדי לשנות את ההיגיון של כלל חומת אש להיפך, פשוט שנה action: Allow על action: Deny.

בידוד על ידי סביבה

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

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

apiVersion: v1
kind: Namespace
metadata:
  labels:
    module: prometheus
  name: kube-prometheus

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

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-metrics-prom
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          module: prometheus
    ports:
    - protocol: TCP
      port: 9100

ואם אתה משתמש במדיניות Calico, התחביר יהיה כך:

apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  name: allow-metrics-prom
spec:
  ingress:
  - action: Allow
    protocol: TCP
    source:
      namespaceSelector: module == 'prometheus'
    destination:
      ports:
      - 9100

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

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

שימוש בחפצי Calico נוספים

הרשו לי להזכיר לכם שבאמצעות הסט המורחב של ממשקי API של Calico תוכלו לווסת את הזמינות של צמתים, לא מוגבל לתרמילים. בדוגמה הבאה באמצעות GlobalNetworkPolicy היכולת להעביר בקשות ICMP באשכול סגורה (לדוגמה, פינגים מפוד לצומת, בין תרמילים או מצומת לתרמיל IP):

apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: block-icmp
spec:
  order: 200
  selector: all()
  types:
  - Ingress
  - Egress
  ingress:
  - action: Deny
    protocol: ICMP
  egress:
  - action: Deny
    protocol: ICMP

במקרה שלעיל, עדיין ניתן לצמתי אשכול "להגיע" זה לזה באמצעות ICMP. והנושא הזה נפתר באמצעים GlobalNetworkPolicy, מוחל על ישות HostEndpoint:

apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: deny-icmp-kube-02
spec:
  selector: "role == 'k8s-node'"
  order: 0
  ingress:
  - action: Allow
    protocol: ICMP
  egress:
  - action: Allow
    protocol: ICMP
---
apiVersion: crd.projectcalico.org/v1
kind: HostEndpoint
metadata:
  name: kube-02-eth0
  labels:
    role: k8s-node
spec:
  interfaceName: eth0
  node: kube-02
  expectedIPs: ["192.168.2.2"]

מקרה ה-VPN

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

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

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

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

1. פודים עם VPN מתוכננים לכל צומת פנימה hostNetwork, כלומר, ל-IP בפועל.
2. השירות מוצב בחוץ דרך ClusterIP. פורט מותקן פיזית על הצומת, הנגיש מבחוץ עם הסתייגויות קלות (נוכחות מותנית של כתובת IP אמיתית).
3. קביעת הצומת שעליו עלה התרמיל היא מעבר לתחום הסיפור שלנו. אני רק אגיד שאתה יכול "למסמר" היטב את השירות לצומת או לכתוב שירות צדדי קטן שינטר את כתובת ה-IP הנוכחית של שירות ה-VPN ויערוך את רשומות ה-DNS הרשומות אצל לקוחות - למי שיש לו מספיק דמיון.

מנקודת מבט של ניתוב, אנו יכולים לזהות באופן ייחודי לקוח VPN לפי כתובת ה-IP שלו שהונפקה על ידי שרת ה-VPN. להלן דוגמה פרימיטיבית להגבלת הגישה של לקוח כזה לשירותים, המומחשת על Redis הנ"ל:

apiVersion: crd.projectcalico.org/v1
kind: HostEndpoint
metadata:
  name: vpnclient-eth0
  labels:
    role: vpnclient
    environment: production
spec:
  interfaceName: "*"
  node: kube-02
  expectedIPs: ["172.176.176.2"]
---
apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: vpn-rules
spec:
  selector: "role == 'vpnclient'"
  order: 0
  applyOnForward: true
  preDNAT: true
  ingress:
  - action: Deny
    protocol: TCP
    destination:
      ports: [6379]
  - action: Allow
    protocol: UDP
    destination:
      ports: [53, 67]

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

תוצאות של

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

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

נ.ב.

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

• «מבוא למדיניות הרשת של Kubernetes לאנשי אבטחה";
• "מדריך מאויר לרשת ב-Kubernetes": חלקים 1 ו-2 (דגם רשת, רשתות שכבת על), חלק 3 (שירותים ועיבוד תעבורה);
• «Container Networking Interface (CNI) - ממשק רשת ותקן לקונטיינרים של לינוקס".

מקור: www.habr.com