רישות בין כמה אשכולות הוא כלי חשוב שמאפשר תרחישי שימוש כמו זמינות גבוהה אזורית, קרבה למשתמשים ברחבי העולם כדי להקטין את זמן האחזור, ובידוד ארגוני בין צוותים. Google Kubernetes Engine (GKE) מספק יכולות מובנות של רשתות מרובות אשכולות שאפשר להפעיל ולהשתמש בהן בהיקף נרחב בצי של אשכולות GKE. התכונה הזו מאפשרת גם לשלב או להעביר תשתית שנפרסה בין GKE Standard לבין Autopilot, כדי לענות על הצרכים הארכיטקטוניים של כל אפליקציה.
באשכולות Autopilot של GKE, Google מנהלת את התשתית, כולל מישור הבקרה והצמתים. אם רוצים להגדיר ולנהל את הצמתים, אפשר להשתמש במצב רגיל ב-GKE. מידע נוסף על ההבדלים בין המצבים זמין במאמר בחירת מצב פעולה של אשכול.
בדף הזה מוצגות התכונות האלה באמצעות כמה טופולוגיות פריסה. תלמדו איך לקחת אפליקציה שנפרסה באשכול GKE יחיד ולהעביר אותה לפריסה מרובת אשכולות באשכולות GKE Standard ו-Autopilot. משתמשים בשירותים מרובי אשכולות של GKE לתנועת נתונים מזרח-מערב ובשערים מרובי אשכולות כדי להפעיל רשתות צפון-דרום מרובות אשכולות.
הדף הזה מיועד לארכיטקטים של ענן ולצוותי תפעול שמשתמשים ב-GKE כדי לפרוס שירותים בכמה אשכולות Kubernetes, או מתכננים להשתמש ב-GKE למטרה הזו. לפני שקוראים את הדף הזה, חשוב לוודא שמכירים את Kubernetes.
שירותים מרובי אשכולות ושערים מרובי אשכולות
אפשר להפעיל את Kubernetes באמצעות מישור בקרה יחיד באזורי ענן שונים כדי לספק עמידות וזמינות גבוהה יותר לשירותים שלכם.
ב-GKE יש פתרון מתקדם יותר: שירותים מרובי אשכולות (MCS) שמספקים מנגנון לגילוי שירותים ולהפעלתם באשכולות שונים.
שירותים שמשתמשים בתכונה הזו ניתנים לגילוי ונגישים בכל האשכולות עם כתובת IP וירטואלית, בהתאם להתנהגות של ClusterIPשירותClusterIP שנגיש באשכול. הגישה הזו מאפשרת ליהנות מהיתרונות הבאים:
- אפשר לבצע איזון עומסים בשירותים בכמה אשכולות באותו אזור או באזורים שונים (תעבורה ממזרח למערב).
- אפשר להשיג זמינות גבוהה של שירותים בין אזורים.
- אפשר לפרוס ולנהל עומסי עבודה (workloads) עם שמירת מצב (stateful) ועומסי עבודה ללא שמירת מצב (stateless) באשכולות נפרדים.
- שירותים משותפים זמינים בכל האשכולות.
מידע נוסף על פריסת MCS זמין במאמר הגדרת שירותים מרובי-אשכולות.
GKE מספק הטמעה של Kubernetes Gateway API שמשתמשת ב-GKE Gateway controller. שער מאפשר ל-GKE לפרוס מאזני עומסים כדי לספק ניתוב תעבורה נכנסת (צפון-דרום) לשירותים שנפרסו ב-GKE. Google Cloud פלטפורמת GKE מספקת גם שערים מרובי אשכולות (MCG) שמרחיבים את GKE Gateway Controller כדי להקצות מאזני עומסים שמנתבים תעבורה לשירותים שנפרסו באשכולות GKE שונים.
בתרשים הבא מוצג איך אפשר לשלב בין MCS ו-MCG כדי לנהל את ההיבטים המשלימים של פריסת השירות וניתוב התנועה ממישור בקרה יחיד:
מידע נוסף זמין במאמר בנושא פריסת שערים מרובי-אשכולות.
סקירה כללית על מיגרציה
היכולות של GKE Multi-cluster networking מועילות לעומסי עבודה (workloads) עם פרופילים שונים. לדוגמה, יכול להיות שיש לכם רכיבים בלי שמירת מצב עם תעבורת נתונים לא יציבה שתרצו להעביר ל-Autopilot בגלל מודל העלויות היעיל יותר שלו.
לחלופין, אפשר למקם את ממשקי הקצה של האפליקציה קרוב יותר למשתמשים. הגישה הזו מספקת זמן אחזור נמוך יותר ומטמון שמשפרים את הביצועים של האפליקציה ואת חוויית המשתמש. יחד עם זאת, יכול להיות שיש לכם רכיבים עם מצב (stateful) שהאפליקציה שלכם מסתמכת עליהם, שיכולים להיות רק במיקום אחד. ההגדרה הזו דורשת איזון עומסים צפון-דרום בין כמה אשכולות כדי לשלוח תנועת לקוחות לאשכול הנכון במיקום הזה. צריך גם איזון עומסים בין אשכולות בכיוון מזרח-מערב כדי לשלוח תעבורה בין אשכולות כדי להגיע לרכיבים עם שמירת מצב.
בדף הזה נעשה שימוש באפליקציית ההדגמה של מיקרו-שירותים בענן Online Boutique כדי להדגים דפוס של כמה אשכולות שאפשר להשתמש בו כדי לשפר את הפריסה של ההדגמה באזור יחיד. מתחילים עם גרסה של האפליקציה שפועלת באזור אחד. לאחר מכן מוסיפים רכיבים של זמינות גבוהה וחוסן באמצעות שירותים מרובי-אשכולות ושערים מרובי-אשכולות, ומפחיתים את הטרחה התפעולית באמצעות Autopilot.
פריסה ראשונית של אשכול יחיד
בתרשים הבא, אפליקציית Online Boutique נפרסת בהתחלה באשכול יחיד במצב GKE Standard בשם std-west, והיא נחשפת באמצעות שירות LoadBalancer:
העברה לשירותים מרובי אשכולות
בשלב הביניים הבא, יוצרים עוד שני אשכולות, והשירותים חסרי המצב נפרסים באזורים נוספים. יוצרים שני אשכולות GKE Autopilot בשמות auto-east ו-auto-central בשני אזורים נפרדים, שונים מאשכול GKE Standard היחיד std-west, ורושמים את האשכולות ב-Google Cloud fleet.
Fleets הם Google Cloud קונספט לארגון לוגי של אשכולות ומשאבים אחרים, והם מאפשרים לכם להשתמש ביכולות של ריבוי אשכולות ולנהל אותן, וגם להחיל מדיניות עקבית על המערכות שלכם.
מייצאים את cartservice באשכול std-west במרחב השמות onlineboutique לאשכולות החדשים של צי הרכבים באמצעות ServiceExport.
אתם פורסים את שירות הקצה הקדמי של Online Boutique בכל שלושת האשכולות וחושפים אותו באמצעות שירות ClusterIP. לאחר מכן מייצאים את השירות ל-Fleet באמצעות ServiceExports.
שירותים כמו שכבת הביניים של Online Boutique (לדוגמה, productcatalog, shipping ו-adservice) נפרסים גם הם בכל שלושת האשכולות.
Pod שפועל בכל אשכול ב-Fleet יכול לגשת ל-Service שיוצא על ידי שליחת בקשה למזהה ה-URI ClusterSet של השירות הזה. הבקשה מנותבת לנקודת קצה שמגבה את השירות.
שירות הfrontend יכול לצרוך את שירותי התוכנה (middleware) (כמו productcatalogservice או currencyservice) באופן מקומי באותו אשכול. הארכיטקטורה הזו עוזרת לשמור על הבקשות הנכנסות מקומיות לאזורים שבהם קצה קדמי מגיב לבקשה, וכך נמנעים חיובים מיותרים על תנועה ברשת בין אזורים.
הדיאגרמה הבאה ממחישה את שני השירותים מרובי-האשכולות. שירות הקצה הקדמי חסר המצב (stateless) נפרס בשלושה אשכולות, ושירות העגלה חסר המצב (stateless) נפרס באשכול אחד. בנוסף, הדיאגרמה גם מראה שבשלב הביניים הזה, תעבורה נכנסת לשירות הקצה הקדמי ממשיכה להיות מנותבת לאשכול GKE Standard המקורי ב-us-west1 באמצעות מאזן עומסי רשת חיצוני אזורי להעברת סיגנל ללא שינוי שנוצר על ידי שירות LoadBalancer frontend-external:
העברה אל שער מרובה אשכולות
בשלב האחרון, מנתבים תעבורה נכנסת של שירות הקצה הקדמי מבקשות של לקוחות חיצוניים לשירותים בכמה אשכולות ב-Fleet באמצעות שער מרובה אשכולות.
אשכול רביעי בשם config-central נוסף לצי כדי לארח ולנהל את ההגדרה של משאבי Gateway ו-HTTPRoute שנוצרים כחלק מההגדרה הזו. המשאב HTTPRoute ממפה את הקידומת / לקצה הקדמי של ServiceImport.
תעבורת הנתונים של חזית האתר של Online Boutique נשלחת לנקודת קצה תקינה באחד מהאזורים הזמינים. הגישה הזו מוסיפה לארכיטקטורת האפליקציה Online Boutique רכיבים של זמינות גבוהה.
בתרשים הבא, שער מרובה אשכולות פורס מאזן עומסים גלובלי בענן שמנתב תעבורה חיצונית לשירות frontend חסר מצב (stateless) שנפרס בכל אחד משלושת אשכולות האפליקציות בצי.
במצב הסופי, התבנית הזו ממחישה צימוד רופף בין החלקים שהם stateful (cartservice ו-redis-cart) לבין החלקים שהם stateless באפליקציה (frontend, emailservice, checkoutservice, recommendationservice, paymentservice, productcatalogservice, currencyservice, shippingservice ו-adservice). הגישה הזו לא מתוארת בדף הזה, אבל היא מאפשרת להוסיף בעתיד חוסן וזמינות גבוהה לשכבת השירותים עם שמירת מצב.
מטרות
- יצירה והגדרה של אשכולות GKE Standard ו-Autopilot.
- פריסת Online Boutique לאשכול GKE Standard אזורי.
- ייצוא של
Servicesמרובה אשכולות. - פריסת מניפסטים באשכולות רגילים ובאשכולות של Autopilot.
- הפעלה והגדרה של שערים מרובי אשכולות.
- בודקים את ההתנהגות של אפליקציה במספר אזורים.
עלויות
במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:
כדי להעריך את ההוצאות בהתאם לתחזית השימוש שלכם, אתם יכולים להיעזר במחשבון העלויות.
לפני שמתחילים
יכול להיות שהגבלות אבטחה שהוגדרו בארגון שלכם ימנעו מכם להשלים את השלבים הבאים. מידע לפתרון בעיות זמין במאמר פיתוח אפליקציות בסביבה מוגבלת. Google Cloud
לפני שמתחילים, חשוב לוודא שהדרישות הבאות מתקיימות:
- מומלץ להשתמש בפרויקט חדש כדי לתרגל את המדריך הזה, כי הדרך הכי קלה לנקות את הסביבה היא למחוק את הפרויקט בסיום.
- במדריך הזה אנחנו יוצאים מנקודת הנחה שיש לכם את תפקיד הבעלים ב-IAM בפרויקטGoogle Cloud . בסביבות ייצור או בסביבות אמיתיות, מומלץ להגדיר את ההרשאות כך שיהיו מצומצמות ככל האפשר. מידע נוסף זמין במאמרים שימוש מאובטח ב-IAM ואימות מפורש של כל ניסיון גישה.
- חשוב להכיר את ארכיטקטורת האפליקציה להדגמת מיקרו-שירותים של Online Boutique.
הכנת הסביבה
במדריך הזה משתמשים ב-Cloud Shell כדי להזין פקודות. Cloud Shell מאפשר לכם לגשת לשורת הפקודה בGoogle Cloud מסוף וכולל את Google Cloud SDK וכלים נוספים, כמו Google Cloud CLI. Cloud Shell מופיע כחלון בחלק התחתון של מסוףGoogle Cloud . תהליך האתחול יכול להימשך כמה דקות, אבל החלון מופיע מיד.
במסוף Google Cloud , מפעילים את Cloud Shell.
ב-Cloud Shell, מגדירים את משתני הסביבה שמשמשים במדריך הזה. מחליפים את PROJECT_ID במזהה הפרויקט שלכם:
export PROJECT=PROJECT_ID gcloud config set project ${PROJECT}מפעילים את השירותים שנדרשים לביצוע השלבים בדף הזה:
gcloud services enable \ gkehub.googleapis.com \ multiclusteringress.googleapis.com \ dns.googleapis.com \ trafficdirector.googleapis.com \ cloudresourcemanager.googleapis.com \ multiclusterservicediscovery.googleapis.com \ container.googleapis.com gcloud container fleet multi-cluster-services enableשירות Multi-cluster Services מנהל רכיבים כמו Cloud DNS, כללי חומת אש ו-Cloud Service Mesh, ולכן צריך להפעיל גם את ממשקי ה-API האלה. Google Cloud מידע נוסף זמין בסקירה הכללית על Cloud Service Mesh.
הפלט אמור להיראות כך:
Operation "operations/acf.p2-822685001869-ee4ebe78-6dd8-465e-b0fd-3b0e5f964bad" finished successfully. Waiting for Feature Multi-cluster Services to be created...done.מוודאים שבקטע 'שירותים מרובי-אשכולות' מופיע הסטטוס ACTIVE:
gcloud container fleet multi-cluster-services describeהפלט אמור להיראות כך:
createTime: '2021-11-30T21:59:25.245190894Z' name: projects/PROJECT_ID/locations/global/features/multiclusterservicediscovery resourceState: state: ACTIVE spec: {} updateTime: '2021-11-30T21:59:27.459063070Z'אם הערך של state הוא לא ACTIVE, אפשר לעיין בפרטים לפתרון בעיות בשירותים מרובי אשכולות.
יצירה והגדרה של אשכולות GKE
כדי להדגים את התבנית של כמה אשכולות במדריך הזה, נשתמש בשלושה אשכולות של אפליקציות בשלושה אזורים נפרדים בענן, ובאשכול אחד לאירוח ההגדרה של משאבי Gateway. אתם רושמים את כל האשכולות ב-Fleet שמשויך לפרויקט. לכל פרויקט ב- Google Cloud יכול להיות משויך רק צי אחד של מכונות. פרויקט זה ידוע בשם פרויקט המארח של Fleet.
במסמך הזה, כל אשכולות GKE נפרסים באותו פרויקט. רשת ה-VPC המשותפת נוצרת בפרויקט הזה, שהוא גם הפרויקט של צי המכונות.
יוצרים אשכולות GKE במצבים Standard ו-Autopilot ורושמים את האשכולות ב-Fleet של הפרויקט:
gcloud container clusters create std-west \ --location us-west1-a \ --num-nodes=6 \ --enable-ip-alias \ --release-channel regular \ --workload-pool=${PROJECT}.svc.id.goog \ --gateway-api=standard \ --enable-fleet \ --async \ gcloud container clusters create-auto auto-east \ --location us-east1 \ --release-channel regular \ --enable-fleet \ --async gcloud container clusters create-auto auto-central \ --location us-central1 \ --release-channel regular \ --enable-fleet \ --async gcloud container clusters create config-central \ --location us-central1 \ --num-nodes=1 \ --enable-ip-alias \ --release-channel regular \ --workload-pool=${PROJECT}.svc.id.goog \ --gateway-api=standard \ --enable-fleet \ --asyncאיחוד שירותי אימות הזהות של עומסי עבודה ל-GKE מופעל כברירת מחדל באשכולות GKE Autopilot, כך שלא צריך להשתמש בדגל
--workload-poolכשיוצרים את האשכולות האלה, כמו באשכולות GKE Standard.מחכים שהסטטוס של האשכולות STATUS ישתנה מ-PROVISIONING ל-RUNNING. התהליך הזה יכול להימשך עד 10 דקות. אפשר לעקוב אחרי ההתקדמות באמצעות watch loop:
watch -n 20 --difference=permanent "gcloud container clusters list"הפלט אמור להיראות כך:
NAME: auto-central LOCATION: us-central1 MASTER_VERSION: 1.21.5-gke.1802 MASTER_IP: 107.178.213.138 MACHINE_TYPE: e2-medium NODE_VERSION: 1.21.5-gke.1802 NUM_NODES: 3 STATUS: PROVISIONING NAME: config-central LOCATION: us-central1 MASTER_VERSION: 1.21.5-gke.1802 MASTER_IP: MACHINE_TYPE: e2-medium NODE_VERSION: 1.21.5-gke.1802 NUM_NODES: 9 STATUS: PROVISIONING NAME: auto-east LOCATION: us-east1 MASTER_VERSION: 1.21.5-gke.1802 MASTER_IP: 35.229.88.209 MACHINE_TYPE: e2-medium NODE_VERSION: 1.21.5-gke.1802 NUM_NODES: 3 STATUS: PROVISIONING NAME: std-west LOCATION: us-west1-a MASTER_VERSION: 1.21.5-gke.1802 MASTER_IP: 35.197.93.113 MACHINE_TYPE: e2-medium NODE_VERSION: 1.21.5-gke.1802 NUM_NODES: 6 STATUS: PROVISIONINGאחרי שכל האשכולות נמצאים במצב RUNNING, מקישים על
CTRL-Cכדי להפסיק את הפקודה.מוסיפים קישור למדיניות ניהול זהויות והרשאות גישה (IAM) שמעניק לחשבון השירות של MCS בפרויקט המארח של צי הרכבים את התפקיד Network User בפרויקט שלו:
gcloud projects add-iam-policy-binding ${PROJECT} \ --member "serviceAccount:${PROJECT}.svc.id.goog[gke-mcs/gke-mcs-importer]" \ --role "roles/compute.networkViewer"אתם משתמשים באיחוד שירותי אימות הזהות של עומסי עבודה ב-GKE כדי להעניק לשירות MCS גישת קריאה להגדרות של רשת ה-VPC בפרויקט. לכן, לחשבון השירות של Importer GKE ב-MCS של פרויקט המארח של Fleet נדרש התפקיד הזה.
הפלט אמור להיראות כך:
- members: - serviceAccount:PROJECT_ID.svc.id.goog[gke-mcs/gke-mcs-importer] role: roles/compute.networkViewer [...]יוצרים קישור IAM בפרויקט המארח של הצי שמקצה את התפקיד GKE Service Agent לחשבון השירות של צי GKE בפרויקט:
gcloud projects add-iam-policy-binding ${PROJECT} \ --member "serviceAccount:service-{${PROJECT}}@gcp-sa-gkehub.iam.gserviceaccount.com" \ --role roles/gkehub.serviceAgentיוצרים קישור IAM בפרויקט המארח של Fleet שמקצה את התפקיד של סוכן השירות של MCS לחשבון השירות של MCS בפרויקט:
gcloud projects add-iam-policy-binding ${PROJECT} \ --member "serviceAccount:service-{${PROJECT}}@gcp-sa-mcsd.iam.gserviceaccount.com" \ --role roles/multiclusterservicediscovery.serviceAgentמתחברים לאשכולות ויוצרים רשומות kubeconfig:
gcloud container clusters get-credentials std-west \ --location us-west1-a --project $PROJECT gcloud container clusters get-credentials auto-east \ --location us-east1 --project $PROJECT gcloud container clusters get-credentials auto-central \ --location us-central1 --project $PROJECT gcloud container clusters get-credentials config-central \ --location us-central1 --project $PROJECTהפלט של כל פקודה דומה לדוגמה הבאה:
Fetching cluster endpoint and auth data. kubeconfig entry generated for std-west.כדי שיהיה קל יותר לעבוד עם ההקשרים בהמשך הדף, כדאי לשנות את השם שלהם עבור אשכולות:
kubectl config rename-context \ gke_${PROJECT}_us-west1-a_std-west \ std-west kubectl config rename-context \ gke_${PROJECT}_us-east1_auto-east \ auto-east kubectl config rename-context \ gke_${PROJECT}_us-central1_auto-central \ auto-central kubectl config rename-context \ gke_${PROJECT}_us-central1_config-central \ config-centralבמדריך הזה, ההקשרים נקראים על שם המיקום שלהם. אפשר לספק שמות חלופיים, אבל בשלבים הבאים במדריך הזה נשתמש בשמות שצוינו בשלב הזה.
פריסת Online Boutique ב-GKE Standard
בשלב הראשון של פריסת ההדגמה, פורסים את כל שירותי האפליקציה Online Boutique לאשכול GKE Standard יחיד std-west ב-us-west1.
יוצרים את מרחב השמות onlineboutique ב-std-west:
kubectl create namespace onlineboutique --context std-westהפלט אמור להיראות כך:
namespace/onlineboutique createdמשכפלים את המאגר של Online Boutique ב-GitHub ומגדירים משתנה WORKDIR:
cd ~ git clone --branch release/v0.4.1 \ https://github.com/GoogleCloudPlatform/microservices-demo.git cd microservices-demo/release && export WORKDIR=`pwd`פורסים את Online Boutique ב-std-west. התהליך הזה יוצר את
DeploymentsואתServicesלכל המיקרו-שירותים (microservices) של Online Boutique, וכולל שירות מסוג LoadBalancer שחושף חיצונית את שירות הקצה הקדמי של Online Boutique:cd $WORKDIR kubectl apply -f kubernetes-manifests.yaml \ -n onlineboutique --context=std-westמחכים עד ששירות
LoadBalancerיקבל כתובת IP חיצונית:watch -n 20 --difference=permanent \ "kubectl get svc frontend-external -n onlineboutique --context=std-west"בתחילה, הפלט אמור להיראות כך:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE frontend-external LoadBalancer 10.60.5.62 <pending> 80:30359/TCP 43sכשה-
Serviceמוכן, כתובת ה-IP הציבורית של מאזן העומסים מוצגת בעמודה EXTERNAL-IP.אחרי שמאזן העומסים
Serviceמוכן, מקבלים את כתובת ה-IP החיצונית שלו ומשתמשים ב-curl כדי לוודא שהקצה הקדמי מוכן. אם הפקודה הזו של curl מחזירה שגיאה, כדאי להמתין כמה רגעים לפני שמנסים שוב:curl $(kubectl get svc frontend-external \ -n onlineboutique --context=std-west \ -o=jsonpath="{.status.loadBalancer.ingress[0].ip}") | \ grep -e Cluster -e Zone -e Podהפלט של פקודת curl שבוצעה בהצלחה אמור להיראות כך:
<b>Cluster: </b>std-west<br/> <b>Zone: </b>us-west1-a<br/> <b>Pod: </b>frontend-b7bddcc97-wdjsk
עכשיו פועלת גרסה של Online Boutique עם אזור יחיד ב-us-west1-a.
אפשר גם להשתמש בדפדפן אינטרנט כדי לנווט לכתובת ה-IP החיצונית שהוקצתה לשירות frontend-external LoadBalancer כדי לגשת לאפליקציה ולבחון את ההתנהגות שלה. הפריסה הראשונית היחידה מוצגת בתרשים הבא:
ייצוא של cartservice כשירות מרובת אשכולות
בקטע הזה מתחילים להוסיף רכיבים של זמינות גבוהה לאפליקציה. מייצאים את ה-backend cartservice כשירות מרובה אשכולות לאשכולות GKE Autopilot.
יוצרים את מרחב השמות onlineboutique באשכולות הנותרים:
kubectl create namespace onlineboutique --context auto-east kubectl create namespace onlineboutique --context auto-central kubectl create namespace onlineboutique --context config-centralהפלט של כל פקודה דומה לדוגמה הבאה:
namespace/onlineboutique createdמייצאים את cartservice מהאשכול std-west לכל שאר האשכולות ב-
ClusterSet. האובייקטServiceExportרושם את השירות cartservice, עם שירותים מרובי אשכולות של GKE, לייצוא לכל האשכולות ב-Fleet שיש בהם את מרחב השמות onlineboutique. פרטים נוספים זמינים במאמר בנושא רישום שירות לייצוא.cat <<EOF>> $WORKDIR/cartservice-export.yaml kind: ServiceExport apiVersion: net.gke.io/v1 metadata: namespace: onlineboutique name: cartservice EOF kubectl apply -f $WORKDIR/cartservice-export.yaml \ -n onlineboutique --context=std-west
החלת מניפסטים של אפליקציות לתבנית של כמה אשכולות
בקטע הזה תחילים שני מניפסטים שנבחרו בקפידה כדי לפרוס את התבנית של ריבוי אשכולות. קובצי המניפסט האלה מכילים חלקים נבחרים של הקובץ kubernetes-manifests.yaml שהחלתם בעבר על אשכול std-west:
- המניפסט הראשון משמש לקצה קדמי
Deployment,Serviceו-ServiceExport. - המניפסט השני משמש לפריסת תוכנת הביניים
Services(emailservice, checkoutservice, recommendationservice, paymentservice, productcatalogservice, currencyservice, shippingservice ו-adservice) בכל האזורים שבהם פועל frontend. כדי להימנע מחיובים מיותרים על תעבורת נתונים ברשת בין אזורים, כדאי לשמור על בקשה מקומית לאזור מסוים כמה שיותר זמן.
שירות Pod שפועל בכל אשכול בצי יכול לגשת ל-Service שיוצא על ידי שליחת בקשה למזהה ה-URI ClusterSet של השירות הזה בפורמט SERVICE_NAME.NAMESPACE.svc.clusterset.local. לדוגמה, הקצה הקדמי
Deployments בכל שלושת אשכולות הדוגמה יכול לצרוך את cartservice במרחב השמות onlineboutique על ידי שליחת בקשה אל cartservice.onlineboutique.svc.clusterset.local.
לכן, בכל מניפסט, שם המארח של cartservice עודכן ל-URI של ClusterSet. השלב הזה הוא קריטי. אם שם המארח של השירות הזה לא מתעדכן, שירות הקצה הקדמי יבקש מ-kube-dns את cartservice במקום cartservice.onlineboutique.svc.clusterset.local. התנהגות כזו תגרום לשגיאות HTTP Status 500 באשכולות שבהם גרסה מקומית של cartservice לא זמינה, ותגרום למצב לא תקין של ה-pods של frontend.
מגדירים משתנה סביבה למאגר ב-GitHub שמכיל את קובצי המניפסט:
export MANIFEST_REPO_PATH=https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/master/gateway/docs/cluster-migrationמחילים את המניפסטים כדי לפרוס את שכבת ה-frontend לכל שלושת אשכולות העומס:
kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-frontend-manifests.yaml \ -n onlineboutique --context=std-west kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-frontend-manifests.yaml \ -n onlineboutique --context=auto-east kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-frontend-manifests.yaml \ -n onlineboutique --context=auto-centralמחילים את המניפסטים כדי לפרוס את שכבת התוכנה לניהול תעבורה בכל שלושת אשכולות העומס:
kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-middleware-manifests.yaml \ -n onlineboutique --context=std-west kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-middleware-manifests.yaml \ -n onlineboutique --context=auto-east kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-middleware-manifests.yaml \ -n onlineboutique --context=auto-central
ה-frontend Deployment, Service ו-ServiceExport פעילים עכשיו באשכולות std-west, auto-east ו-auto-central. בנוסף, בכל אשכול פועלים שירותי תוכנת ביניים של Online Boutique באופן מקומי. עם זאת, התנועה החיצונית עדיין מנותבת רק אל Service שפועל באשכול הראשוני ב-us-west1, כפי שמוצג בתרשים הבא:
הפעלה והגדרה של שערים מרובי אשכולות
בקטע הזה, אתם מעבירים תנועה ומאזנים עומסים של תנועה חיצונית בין ממשקי קצה בכל שלושת האשכולות. כדי להשיג את ההגדרה הזו, משתמשים בשערים מרובי אשכולות (MCG). השלבים האלה להגדרת MCG מבוססים על ההנחיות שמתוארות בפירוט במאמר בנושא הפעלת שערים מרובי אשכולות.
בשלבים האלה משתמשים באשכול config-central כדי לארח את ההגדרה של משאבי השער.
מוודאים שכל האשכולות נרשמו בהצלחה ל-Fleet:
gcloud container fleet memberships list --project=$PROJECTבדוגמת הפלט הבאה אפשר לראות שכל האשכולות נרשמו בהצלחה:
NAME: auto-central EXTERNAL_ID: 21537493-32ea-4a41-990d-02be2c1b319f NAME: config-central EXTERNAL_ID: 4369423e-ea7b-482d-a0eb-93b560e67b98 NAME: std-west EXTERNAL_ID: 7fcb048b-c796-476b-9698-001a00f91ab3 NAME: auto-east EXTERNAL_ID: aae2d2ff-b861-4a38-bcaf-612f14810012מתקינים את הגדרת המשאב המותאם אישית של Gateway API באשכול config-central:
kubectl --context=config-central kustomize "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v0.5.0" \ | kubectl apply -f -בשלב הזה מותקנים הגדרות של משאבים מותאמים אישית של Gateway API, כולל המשאבים
GatewayClass,Gatewayו-HTTPRoute. ההגדרות של המשאבים המותאמים אישית מתוחזקות על ידי קבוצת העניין המיוחדת בנושא רשת של Kubernetes. אחרי ההתקנה, אפשר להשתמש בבקר GKE Gateway.אם עדיין לא עשיתם זאת, מפעילים את Multi Cluster Ingress עבור הצי. הפעלת התכונה הזו מפעילה גם את בקר השערים מרובי האשכולות.
gcloud container fleet ingress enable \ --config-membership=config-central \ --project=$PROJECT gcloud container fleet ingress describe --project=$PROJECTהפלט אמור להיראות כך:
createTime: '2021-12-08T23:10:52.505888854Z' name: projects/PROJECT_ID/locations/global/features/multiclusteringress resourceState: state: ACTIVE spec: multiclusteringress: configMembership: projects/zl-mcs-expf61cbd13/locations/global/memberships/config-central state: state: code: OK description: Ready to use updateTime: '2021-12-08T23:11:37.994971649Z' updateTime: '2021-12-08T23:11:38.098244178Z'אם הערך של state הוא לא ACTIVE, אפשר לעיין במאמר פתרון בעיות ופעולות ב-Multi Cluster Ingress.
מוודאים ש-
GatewayClassesזמינים באשכול config-central:kubectl get gatewayclasses --context=config-centralהפלט אמור להיראות כך:
NAME CONTROLLER AGE gke-l7-global-external-managed networking.gke.io/gateway 18s gke-l7-global-external-managed-mc networking.gke.io/gateway 19s gke-l7-regional-external-managed networking.gke.io/gateway 18s gke-l7-regional-external-managed-mc networking.gke.io/gateway 19s gke-l7-gxlb networking.gke.io/gateway 74s gke-l7-gxlb-mc networking.gke.io/gateway 16s gke-l7-rilb networking.gke.io/gateway 74s gke-l7-rilb-mc networking.gke.io/gateway 16sלמשאבים שונים של
GatewayClassיש יכולות שונות. מידע נוסף על מקרים שבהם כדאי להשתמש בכל אחד מהסוגים זמין במאמר יכולות של GatewayClass.פריסת משאב השער
external-httpאלconfig-central:cat <<EOF>> $WORKDIR/external-http-gateway.yaml kind: Gateway apiVersion: gateway.networking.k8s.io/v1 metadata: name: external-http namespace: onlineboutique spec: gatewayClassName: gke-l7-global-external-managed-mc listeners: - protocol: HTTP port: 80 name: http EOF kubectl apply -f external-http-gateway.yaml \ -n onlineboutique --context=config-centralכפי שמצוין בשדה
gatewayClassName, המשאב הזה הוא מסוגGatewayClassgke-l7-global-external-managed-mc, שמנהל את Cloud Load Balancing החיצוני בשכבה 7 וחושף את האפליקציה מרובת האשכולותפורסים את
HTTPRouteבשם public-frontend-route ב-config-central:cat <<EOF>> $WORKDIR/public-frontend-route.yaml kind: HTTPRoute apiVersion: gateway.networking.k8s.io/v1 metadata: name: public-frontend-route namespace: onlineboutique spec: parentRefs: - name: "external-http" hostnames: - "store.example.com" rules: - matches: - path: type: PathPrefix value: / backendRefs: - name: frontend group: net.gke.io kind: ServiceImport port: 80 EOF kubectl apply -f public-frontend-route.yaml \ -n onlineboutique --context=config-centralכשפורסים את משאב
HTTPRoute, נוצר משאב חיצוני של Cloud Load Balancing בשכבה 7, והקצה הקדמי שלServiceImportנחשף. הקצה הקדמי מגובה על ידי שירותי הקצה הקדמי שפועלים באשכולות std-west, auto-east ו-auto-central.בתרשים הבא מוצג איך, אחרי פריסת שער מרובה אשכולות, אפשר לנתב תנועה לכל אחד משירותי הקצה העורפיים מרובי האשכולות בכל אחד משלושת אשכולות האפליקציות:
מחכים עד שמאזן העומסים יהיה מוכן עם כתובת IP חיצונית שהוקצתה לפני שעוברים לשלב הבא. יכול להיות שיחלפו עד 10 דקות עד להקצאת כתובת ה-IP. אפשר לעקוב אחרי ההתקדמות באמצעות לולאת שעון. למאזן העומסים יש שם בדפוס כמו gkemcg-onlineboutique-external-http-k09mfhk74gop:
watch -n 20 --difference=permanent \ "gcloud compute forwarding-rules list \ | grep -A 5 NAME..*external-http"הפלט אמור להיראות כך:
NAME: gkemcg-onlineboutique-external-http-k09mfhk74gop REGION: IP_ADDRESS: 34.149.29.176 IP_PROTOCOL: TCP TARGET: gkemcg-onlineboutique-external-http-k09mfhk74gopאחרי שמאזן העומסים מוכן, מריצים את הפקודה הבאה ב-Cloud Shell כדי לייצא את כתובת ה-IP החיצונית של מאזן העומסים שנוצר באמצעות המניפסטים external-http-gateway.yaml ו-public-frontend-route.yaml:
export EXTERNAL_LB_IP=$(kubectl --context=config-central \ -n onlineboutique get gateway external-http \ -o=jsonpath='{.status.addresses[0].value}')כששולחים בקשה למאזן העומסים עם הכותרות המתאימות, הוא מחזיר את תוכן ה-HTML שמוצג על ידי שירות הקצה הקדמי. לדוגמה, מכיוון שהגדרתם את משאב
HTTPRouteלמיפוי של שם המארחstore.example.comלקצה הקדמיServiceImport, עליכם לספק את הכותרתHOSTכשאתם שולחים את בקשת ה-HTTP. אם הפקודה הבאה של curl מחזירה שגיאה, צריך להמתין כמה דקות ולנסות שוב:curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \ grep -e Cluster -e Zone -e Podהפלט של פקודת curl שבוצעה בהצלחה אמור להיראות כך:
<b>Cluster: </b>auto-central<br/> <b>Zone: </b>us-central1-f<br/> <b>Pod: </b>frontend-7c7d596ddc-jdh8f
בדיקת התנהגות הניתוב של אפליקציה במספר אזורים
אחת מהתכונות המתקדמות שמתקבלות משימוש בשירותים מרובי-אשכולות ובשערי כניסה מרובי-אשכולות היא שבקשות חיצוניות מנותבות לאשכול הקרוב ביותר מבחינה גיאוגרפית.
כדי לבדוק את ההתנהגות של האפליקציה במספר אזורים, צריך ליצור תעבורת נתונים שמגיעה מהאזורים השונים שבהם פרסתם אשכולות. יוצרים שלושה פודים קטנים, אחד בכל אחד מהאשכולות שמשרתים את התנועה (std-west, auto-east ו-auto-central), שאפשר להשתמש בהם כדי לשלוח בקשות HTTP לנקודת הקצה של מאזן העומסים. התוצאות מאפשרות לראות איזה קצה קדמי Pod מגיב.
יוצרים את קבוצות הלקוחות:
kubectl run --context=std-west \ --image=radial/busyboxplus:curl client-west \ -- sh -c 'while sleep 3600; do :; done' kubectl run --context=auto-east \ --image=radial/busyboxplus:curl client-east \ -- sh -c 'while sleep 3600; do :; done' kubectl run --context=auto-central \ --image=radial/busyboxplus:curl client-central \ -- sh -c 'while sleep 3600; do :; done'אחרי שה-pods פועלים, משתמשים בפקודת curl כדי לשלוח בקשה לנקודת הקצה של מאזן העומסים מהלקוח
Podבאשכול std-west, ובודקים את התגובה:kubectl exec -it --context=std-west client-west \ -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \ grep -e Cluster -e Zone -e Podהפלט של פקודת curl שבוצעה בהצלחה אמור להיראות כך:
<b>Cluster: </b>std-west<br/> <b>Zone: </b>us-west1-a<br/> <b>Pod: </b>frontend-7cf48b79cf-trzc4מריצים את אותה בקשת curl מהלקוח
Podבאשכול auto-east, ומסתכלים על התגובה:kubectl exec -it --context=auto-east client-east \ -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \ grep -e Cluster -e Zone -e Podהפלט של פקודת curl שבוצעה בהצלחה אמור להיראות כך:
<b>Cluster: </b>auto-east<br/> <b>Zone: </b>us-east1-d<br/> <b>Pod: </b>frontend-6784b6df98-scdwsמכיוון שמדובר באשכול במצב Autopilot, יכול להיות שיהיה צורך להקצות לאשכול משאבים נוספים כדי לתזמן את
Pod. אם הפלט דומה לדוגמה הבאה, צריך להמתין רגע ולנסות שוב:Error from server (BadRequest): pod client-east does not have a host assignedמריצים את הפקודה curl מהלקוח
Podבאשכול auto-central ובודקים את התגובה:kubectl exec -it --context=auto-central client-central \ -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \ grep -e Cluster -e Zone -e Podהפלט של פקודת curl שבוצעה בהצלחה אמור להיראות כך:
<b>Cluster: </b>auto-central<br/> <b>Zone: </b>us-central1-b<br/> <b>Pod: </b>frontend-6784b6df98-x2fv4התוצאות האלה מאשרות שהתנועה מנותבת אל התאים התואמים במיקומים הקרובים ביותר למקור הבקשה.
בדיקת עמידות של אפליקציה במספר אזורים
בנוסף לניתוב יעיל של תנועת הנתונים, הפעלת השירותים בכמה אזורים מספקת עמידות במקרה הנדיר, אך עדיין אפשרי, של כשל בתשתית.
כדי לבדוק את ההתנהגות, מוחקים את frontend Deployments באשכולות ספציפיים ואז מנסים שוב להריץ את פקודת curl מהלקוח Pod באזורים האלה. שימו לב שהאפליקציה עדיין זמינה, ובדקו את המיקום של Pod שמגיב לבקשה.
מריצים את פקודת curl מהלקוח client-west
Podבאשכול std-west, ורואים שהתוצאה מגיעה מהחלק הקדמי של האתר באזור us-west1:kubectl exec -it --context=std-west client-west \ -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \ grep -e Cluster -e Zone -e Podהפלט של פקודת curl שבוצעה בהצלחה אמור להיראות כך:
<b>Cluster: </b>std-west<br/> <b>Zone: </b>us-west1-a<br/> <b>Pod: </b>frontend-7cf48b79cf-trzc4מוחקים את הקצה הקדמי
Deploymentבאשכול std-west:kubectl delete deploy frontend \ -n onlineboutique --context=std-westהפלט אמור להיראות כך:
deployment.apps "frontend" deletedשולחים בקשה נוספת מ-client-west
Podבאשכול std-west. אמורה להתקבל תגובה מאחד משרתי הקצה הקדמי שנותרוDeploymentsשנמצאים באשכולות auto-east או auto-central:kubectl exec -it --context=std-west client-west \ -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \ grep -e Cluster -e Zone -e Podפלט שדומה לדוגמה הבאה מציין את המיקום של
Podתקין שמגיב לבקשה הזו:<b>Cluster: </b>auto-central<br/> <b>Zone: </b>us-central1-b<br/> <b>Pod: </b>frontend-6784b6df98-x2fv4או
<b>Cluster: </b>auto-east<br/> <b>Zone: </b>us-east1-d<br/> <b>Pod: </b>frontend-6784b6df98-scdwsמריצים את הפקודה כמה פעמים כדי לראות תוצאות מתחלפות.
בפריסה ההדגמתית הזו, הוספתם רכיבים של עמידות ופיזור גיאוגרפי לאפליקציית Online Boutique באמצעות שירותים מרובי אשכולות ושערים מרובי אשכולות. הבקשות מנותבות לאזור הגיאוגרפי הקרוב ביותר, וגם אם יש בעיות בשירותי חזית האפליקציה או בשירותי הביניים באזור מסוים, משתמש הקצה עדיין יכול להשתמש באפליקציה בהצלחה.
הסרת המשאבים
כדי להימנע מחיובים בחשבון Google Cloud בגלל השימוש במשאבים שנעשה במסגרת המדריך הזה, אפשר למחוק את הפרויקט שמכיל את המשאבים, או להשאיר את הפרויקט ולמחוק את המשאבים בנפרד.
- במסוף Google Cloud , נכנסים לדף Manage resources.
- ברשימת הפרויקטים, בוחרים את הפרויקט שרוצים למחוק ולוחצים על Delete.
- כדי למחוק את הפרויקט, כותבים את מזהה הפרויקט בתיבת הדו-שיח ולוחצים על Shut down.
המאמרים הבאים
- Google Cloud מידע נוסף על ניהול צי וניהול של כמה אשכולות
- איך רושמים אשכול, כולל אשכולות GKE, ל- Google Cloud Fleet.
- מידע נוסף על Kubernetes Gateway API ועל GKE Gateway
- כדאי להעמיק את הקריאה ולהכיר דוגמאות לארכיטקטורות, תרשימים ושיטות מומלצות בנושאי Google Cloud. כל אלה זמינים במרכז הארכיטקטורה של Cloud.