שליטה בתקשורת בין Pods ושירותים באמצעות מדיניות רשת

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

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

מידע על אכיפת מדיניות הרשת ב-GKE

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

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

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

תוספים של NetworkPolicy ב-GKE

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

• ‫GKE Dataplane V2, שמבוסס על Cilium.‫ GKE Dataplane V2 הוא פלאגין הרשת המומלץ לכל האשכולות, והוא ברירת המחדל לאשכולות Autopilot.
• תוסף מדיניות הרשת Calico, שזמין רק באשכולות רגילים.

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

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

לפני שמתחילים

לפני שמתחילים, חשוב לוודא שביצעתם את הפעולות הבאות:

• מפעילים את ממשק Google Kubernetes Engine API.
הפעלת Google Kubernetes Engine API
• אם רוצים להשתמש ב-Google Cloud CLI למשימה הזו, צריך להתקין ואז לאתחל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, תוכלו להריץ את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות במסמך הזה.

דרישות ומגבלות

הדרישות והמגבלות הבאות חלות על אשכולות Autopilot ועל אשכולות רגילים:

• אתם צריכים לאפשר יציאה לשרת המטא-נתונים.
• מידע נוסף על מגבלות של אשכולות GKE Dataplane V2 זמין בדף הבעיות הידועות של GKE Dataplane V2.

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

• אם משתמשים במדיניות רשת עם איחוד זהויות של עומסי עבודה ל-GKE, צריך לאפשר יציאה לשרת המטא-נתונים.
• הפעלת האכיפה של מדיניות הרשת מגדילה את הזיכרון שבשימוש של התהליך kube-system בכ-128MB, ודורשת כ-300 מילי-ליבות של מעבד. המשמעות היא שאם מפעילים מדיניות רשת עבור אשכול קיים, יכול להיות שיהיה צורך להגדיל את גודל האשכול כדי להמשיך להפעיל את עומסי העבודה המתוזמנים.
• כדי להפעיל את האכיפה של מדיניות הרשת, צריך ליצור מחדש את הצמתים. אם באשכול שלכם יש חלון זמן לתחזוקה פעיל, הצמתים לא נוצרים מחדש באופן אוטומטי עד לחלון זמן לתחזוקה הבא. אם אתם מעדיפים, אתם יכולים לשדרג את האשכול באופן ידני מתי שתרצו.
• גודל האשכול המינימלי הנדרש להפעלת אכיפה של מדיניות רשת הוא שלוש מכונות e2-medium או מכונה אחת מסוג מכונה עם יותר מ-vCPU אחד ניתן להקצאה. פרטים נוספים זמינים במאמר בעיות ידועות ב-GKE.
• מדיניות רשת לא נתמכת באשכולות שהצמתים שלהם הם מופעי f1-micro או g1-small, כי דרישות המשאבים גבוהות מדי.
• ‫GKE Dataplane V2 ו-Calico לא אוכפים מדיניות רשת עבור Pods שמשתמשים בהגדרה spec.hostNetwork: true.

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

הפעלת אכיפה של מדיניות רשת

אם אתם משתמשים ב-GKE Dataplane V2 באשכול, דלגו אל יצירת מדיניות רשת.

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

לפני שממשיכים: מדיניות הרשת תיאכף כשיוצרים מחדש את הצמתים.

השבתת האכיפה של מדיניות הרשת באשכול רגיל

אפשר להשבית את האכיפה של מדיניות הרשת באמצעות ה-CLI של gcloud,‏ Cloud de Confiance המסוף או GKE API. אי אפשר להשבית את האכיפה של מדיניות הרשת באשכולות Autopilot או באשכולות שמשתמשים ב-GKE Dataplane V2.

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

יצירת מדיניות רשת

אפשר ליצור מדיניות רשת באמצעות Kubernetes Network Policy API.

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

• סקירה כללית של מדיניות הרשת
• הצהרה על מדיניות הרשת

מדיניות רשת ואיחוד זהויות של עומסי עבודה ל-GKE

אם אתם משתמשים במדיניות רשת עם איחוד זהויות של עומסי עבודה ל-GKE, אתם צריכים לאפשר תעבורת נתונים יוצאת (egress) לכתובות ה-IP הבאות כדי שה-Pods יוכלו לתקשר עם שרת המטא-נתונים של GKE.

• באשכולות שמריצים GKE בגרסה 1.21.0-gke.1000 ואילך, צריך לאפשר יציאה אל 169.254.169.252/32 ביציאות 988 ו-987.
• באשכולות שמריצים גרסאות GKE מוקדמות מ-1.21.0-gke.1000, צריך לאפשר יציאה אל 127.0.0.1/32 ביציאות 988 ו-987.
• באשכולות שמופעל בהם GKE Dataplane V2, צריך לאפשר תעבורת נתונים יוצאת אל 169.254.169.254/32 ביציאות 80 ו-8080.

אם לא תאפשרו תעבורת נתונים יוצאת (egress) לכתובות ה-IP ולפורטים האלה, יכול להיות שתיתקלו בשיבושים במהלך שדרוגים אוטומטיים.

מעבר מ-Calico ל-GKE Dataplane V2

אם אתם מעבירים את מדיניות הרשת מ-Calico ל-GKE Dataplane V2, כדאי לשים לב למגבלות הבאות:

• אי אפשר להשתמש בכתובת IP של Pod או של שירות בשדה ipBlock.cidr של מניפסט NetworkPolicy. צריך להפנות לעומסי עבודה באמצעות תוויות. לדוגמה, ההגדרה הבאה לא תקינה:

  - ipBlock:
      cidr: 10.8.0.6/32
  

• אי אפשר לציין שדה ports.port ריק במניפסט NetworkPolicy. אם מציינים פרוטוקול, צריך לציין גם יציאה. לדוגמה, ההגדרה הבאה לא חוקית:

  ingress:
  - ports:
    - protocol: TCP
  

עבודה עם מאזני עומסים של אפליקציות

כשמחילים Ingress על Service כדי ליצור מאזן עומסים מסוג HTTP(S), צריך לוודא שמדיניות הרשת מאפשרת תנועה מ טווח כתובות ה-IP של בדיקות תקינות של מאזן עומסים של אפליקציות מסוג HTTP(S).

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

איזון עומסים שמקורו בקונטיינר, שמופעל כברירת מחדל בכל אשכולות GKE, מנתב את תעבורת הנתונים ישירות לנקודות הקצה של ה-Pod. כדי לעשות את זה, שירותי GKE מקבלים באופן אוטומטי את ההערה cloud.google.com/neg: '{"ingress": true}'. עם זאת, הפעלת מדיניות הרשת של GKE היא אחד מהתנאים הספציפיים שמונעים את ההפעלה של איזון עומסים מבוסס-קונטיינרים כברירת מחדל. כדי לשמור על היתרונות של איזון עומסים מובנה ב-container כשמשתמשים במדיניות רשת, צריך להחיל באופן ידני את ההערה הבאה על מניפסטים של שירותים:

kind: Service
...
  annotations:
    cloud.google.com/neg: '{"ingress": true}'
...

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

הכללה של טווחי כתובות IP של Pod בכללי ipBlock

כדי לשלוט בתנועה של פודים ספציפיים, תמיד צריך לבחור פודים לפי מרחב השמות שלהם או תוויות של פודים באמצעות השדות namespaceSelector ו-podSelector בכללי הכניסה או היציאה של NetworkPolicy. לא מומלץ להשתמש בשדה ipBlock.cidr כדי לבחור בכוונה טווחי כתובות IP של Pod, שהן ארעיות. פרויקט Kubernetes לא מגדיר במפורש את ההתנהגות של השדה ipBlock.cidr כשהוא כולל טווחי כתובות IP של Pod. ציון טווחי CIDR רחבים בשדה הזה, כמו 0.0.0.0/0 (שכוללים את טווחי כתובות ה-IP של ה-Pod), עלול להוביל לתוצאות לא צפויות בהטמעות שונות של NetworkPolicy.

בקטעים הבאים מוסבר איך יישומי NetworkPolicy שונים ב-GKE מעריכים את טווחי כתובות ה-IP שאתם מציינים בשדה ipBlock.cidr, ואיך זה עשוי להשפיע על טווחי כתובות ה-IP של ה-Pods שנכללים באופן מובנה בטווחי CIDR רחבים. הבנת ההבדלים בהתנהגות בין ההטמעות השונות תעזור לכם להתכונן לתוצאות שתקבלו כשmigrate להטמעה אחרת.

התנהגות של ipBlock ב-GKE Dataplane V2

ביישום GKE Dataplane V2 של NetworkPolicy, תעבורת הנתונים של ה-Pod אף פעם לא מכוסה על ידי כלל ipBlock. לכן, גם אם תגדירו כלל רחב כמו cidr: '0.0.0.0/0', הוא לא יכלול תנועה של Pod. האפשרות הזו שימושית כי היא מאפשרת, למשל, לקבוצות Pod במרחב שמות לקבל תעבורת נתונים מהאינטרנט, בלי לאפשר גם תעבורת נתונים מקבוצות Pod. כדי לכלול גם תנועה של Pod, צריך לבחור Pod באופן מפורש באמצעות עוד Pod או בורר של מרחב שמות בהגדרות של כללי הכניסה או היציאה של NetworkPolicy.

ההתנהגות של ipBlock ב-Calico

ביישום Calico של NetworkPolicy, הכללים ipBlock מכסים תעבורת נתונים של Pod. ביישום הזה, כדי להגדיר טווח CIDR רחב בלי לאפשר תעבורת נתונים של Pod, צריך להחריג באופן מפורש את טווח ה-CIDR של ה-Pod באשכול, כמו בדוגמה הבאה:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-non-pod-traffic
spec:
  ingress:
  - from:
    - ipBlock:
      cidr: '0.0.0.0/0'
      except: ['POD_IP_RANGE']

בדוגמה הזו, POD_IP_RANGE הוא טווח כתובות ה-IPv4 של ה-Pod באשכול, למשל 10.95.0.0/17. אם יש לכם כמה טווחי כתובות IP, אפשר לכלול אותם בנפרד במערך, למשל ['10.95.0.0/17', '10.108.128.0/17'].

שליטה בהתנהגות של מדיניות הרשת באמצעות externalTrafficPolicy

ההגדרה externalTrafficPolicy של השירות משפיעה על האופן שבו Kubernetes מחיל מדיניות רשת. ההגדרה הזו קובעת את כתובת ה-IP של המקור שה-Pods רואים בתנועה הנכנסת, והיא יכולה להשפיע על האופן שבו Kubernetes מעריך את הכללים של NetworkPolicy.

‫externalTrafficPolicy יכול לקבל שני ערכים:

• ‫Cluster: כשערך המאפיין externalTrafficPolicy מוגדר כ-Cluster, יעד ה-Pod רואה את כתובת ה-IP של המקור ככתובת ה-IP של הצומת שבו התנועה מתקבלת בהתחלה. אם יש לכם NetworkPolicy שחוסם תנועה על סמך כתובות IP של לקוחות, אבל לא כולל את כתובות ה-IP של הצומת המרוחק, יכול להיות שהוא יחסום בטעות תנועה חיצונית מהלקוחות החיצוניים שצוינו בכללי המדיניות. כדי למנוע את זה, צריך ליצור מדיניות שמאפשרת תנועה מכל הצמתים באשכול. עם זאת, המדיניות הזו תאפשר תנועה מכל לקוח חיצוני.

• ‫Local: כשמגדירים את externalTrafficPolicy לערך Local, ה-Pod רואה את כתובת ה-IP של המקור ככתובת ה-IP המקורית של הלקוח. כך אפשר לקבל שליטה מפורטת יותר באמצעות מדיניות רשת, כי אפשר להגדיר כללים על סמך כתובות ה-IP של הלקוחות בפועל.

פתרון בעיות

אין אפשרות ליצור תקשורת בין ה-Pods לבין מישור הבקרה באשכולות שמשתמשים ב-Private Service Connect

יכול להיות שיהיה פודים באשכולות GKE שמשתמשים ב-Private Service Connect שיתקלו בבעיה בתקשורת עם מישור הבקרה אם היציאה של הפוד לכתובת ה-IP הפנימית של מישור הבקרה מוגבלת במדיניות היציאה מהרשת.

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

1. מוודאים שהאשכול משתמש ב-Private Service Connect. באשכולות שמשתמשים ב-Private Service Connect, אם משתמשים בדגל master-ipv4-cidr כשיוצרים את רשת המשנה, GKE מקצה לכל מישור בקרה כתובת IP פנימית מהערכים שהגדרתם ב-master-ipv4-cidr. אחרת, GKE משתמש ברשת המשנה של צומת האשכול כדי להקצות לכל מישור בקרה כתובת IP פנימית.

2. מגדירים את מדיניות היציאה של האשכול כך שתאפשר תעבורת נתונים לכתובת ה-IP הפנימית של מישור הבקרה.

   כדי למצוא את כתובת ה-IP הפנימית של מישור הבקרה:

   gcloud

   כדי לחפש את privateEndpoint, מריצים את הפקודה הבאה:

   gcloud container clusters describe CLUSTER_NAME
   

   מחליפים את CLUSTER_NAME בשם האשכול.

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

   המסוף

   1. נכנסים לדף Google Kubernetes Engine במסוף Cloud de Confiance .

      מעבר אל Google Kubernetes Engine

   2. בחלונית הניווט, בקטע Clusters, לוחצים על האשכול שרוצים למצוא את כתובת ה-IP הפנימית שלו.

   3. בקטע Cluster basics (מידע בסיסי על אשכול), עוברים אל Internal endpoint, שבו מופיעה כתובת ה-IP הפנימית.

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

העדכון של האשכול מתבצע לאט

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

אפשר לשדרג מאגר צמתים באופן ידני על ידי הגדרת הדגל --cluster-version לאותה גרסת GKE שמופעלת במישור הבקרה. כדי לבצע את הפעולה הזו, צריך להשתמש ב-Google Cloud CLI. מידע נוסף מופיע במאמר בנושא הערות לגבי חלונות תחזוקה.

פריסת Pods באופן ידני ללא תזמון

כשמפעילים אכיפה של מדיניות רשת במישור הבקרה של אשכול קיים, מערכת GKE מבטלת את התזמון של כל ה-Pods של ip-masquerade-agent או של calico node שפרסתם באופן ידני.

מערכת GKE לא מתזמנת מחדש את ה-Pods האלה עד שהאכיפה של מדיניות הרשת מופעלת בצמתי האשכול ועד שהצמתים נוצרים מחדש.

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

כדי למזער את משך השיבוש הזה, אפשר להקצות ידנית את התוויות הבאות לצמתי האשכול:

• node.kubernetes.io/masq-agent-ds-ready=true
• projectcalico.org/ds-ready=true

מדיניות הרשת לא נכנסת לתוקף

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

1. מוודאים שהאכיפה של מדיניות הרשת מופעלת. הפקודה שבה משתמשים תלויה בשאלה אם GKE Dataplane V2 מופעל באשכול.

   אם הפעלתם את GKE Dataplane V2 באשכול, מריצים את הפקודה הבאה:

   kubectl -n kube-system get pods -l k8s-app=cilium
   

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

   אם לא מופעל ב-cluster שלכם GKE Dataplane V2, מריצים את הפקודה הבאה:

   kubectl get nodes -l projectcalico.org/ds-ready=true
   

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

2. בודקים את התוויות של ה-Pod:

   kubectl describe pod POD_NAME
   

   מחליפים את POD_NAME בשם של ה-Pod.

   הפלט אמור להיראות כך:

   Labels:        app=store
                  pod-template-hash=64d9d4f554
                  version=v1
   

3. מוודאים שהתוויות במדיניות זהות לתוויות ב-Pod:

   kubectl describe networkpolicy
   

   הפלט אמור להיראות כך:

   PodSelector: app=store
   

   בפלט הזה, התוויות app=store זהות לתוויות app=store מהשלב הקודם.

4. בודקים אם יש מדיניות רשת שבוחרת את עומסי העבודה:

   kubectl get networkpolicy
   

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

   kubectl describe networkpolicy
   

   הפלט אמור להיראות כך:

   ...
   PodSelector:     app=nginx
   Allowing ingress traffic:
      To Port: <any> (traffic allowed to all ports)
      From:
         PodSelector: app=store
   Not affecting egress traffic
   Policy Types: Ingress
   

בעיות מוכרות

רצף המודעות תקוע במצב containerCreating

יכול להיות תרחיש שבו באשכולות GKE עם מדיניות רשת Calico מופעלת, יכולה להיות בעיה שבה תרמילי Pod נתקעים במצב containerCreating.

בכרטיסייה אירועים של הפוד, תופיע הודעה דומה לזו שבהמשך:

plugin type="calico" failed (add): ipAddrs is not compatible with
configured IPAM: host-local

כדי לפתור את הבעיה, צריך להשתמש ב-IPAM מקומי למארח עבור Calico במקום ב-calico-ipam באשכולות GKE.

503 Calico readiness probe failures in large clusters

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

כדי לשנות את הערכים, עורכים את calico-node-vertical-autoscaler ConfigMap כך שייעשה שימוש באותם ערכי פרמטרים בשדות base ו-max. הגישה הזו משביתה בקשות דינמיות למשאבי CPU, ומפסיקה בקשות משתנות של CPU עם תחלופת צמתים:

kind: ConfigMap
apiVersion: v1
metadata:
  name: calico-node-vertical-autoscaler
  namespace: kube-system
  labels:
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: EnsureExists
data:
  node-autoscaler: |-
    {
      "calico-node": {
        "requests": {
          "cpu": {
            "base": "200m",
            "step": "100m",
            "nodesPerStep": 50,
            "max": "200m"
          }
        }
      }
    }

הגדרת הערך של השדה base (200m) כגבוה יותר מהערך של השדה step (100m) עוזרת להבטיח של-Pods של calico-node יהיו מספיק משאבי מעבד (CPU) לאשכולות של עד 60 צמתים, בהתאם לנוסחה של Autoscaler, כי מעבד ה-CPU המבוקש כבר לא יותאם למספר הצמתים.

המאמרים הבאים

• לפעול לפי המדריך בנושא מדיניות הרשת.

• מידע נוסף על מדיניות רשת ב-Kubernetes

• יישום גישות נפוצות להגבלת התנועה באמצעות כללי מדיניות לרשת.

• שימוש ברישום ביומן של מדיניות הרשת.

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