רישות מרובה אשכולות הוא כלי חשוב שמאפשר תרחישי שימוש כמו זמינות גבוהה אזורית, קרבה למשתמשים ברחבי העולם לזמני אחזור נמוכים ובידוד ארגוני בין צוותים. Google Kubernetes Engine (GKE) מספק יכולות מובנות של רשתות מרובות אשכולות שאפשר להפעיל ולהשתמש בהן בהיקף נרחב בצי של אשכולות GKE. התכונה הזו מאפשרת גם לשלב או להעביר תשתית שנפרסה בין GKE Standard לבין Autopilot, כדי לענות על הצרכים הארכיטקטוניים של כל אפליקציה.
באשכולות GKE Autopilot, Google מנהלת את התשתית, כולל מישור הבקרה והצמתים. אם רוצים להגדיר ולנהל את הצמתים, אפשר להשתמש במצב רגיל ב-GKE. מידע נוסף על ההבדלים בין המצבים זמין במאמר בנושא בחירת מצב פעולה של אשכול.
בדף הזה מוצגות התכונות האלה באמצעות כמה טופולוגיות פריסה. תלמדו איך לקחת אפליקציה שנפרסה באשכול GKE יחיד ולהעביר אותה לפריסה מרובת אשכולות באשכולות GKE Standard ו-Autopilot. משתמשים בשירותים מרובי אשכולות של GKE לתנועת נתונים מזרח-מערב ובשערים מרובי אשכולות כדי להפעיל רישות צפון-דרום מרובה אשכולות.
הדף הזה מיועד לארכיטקטים של ענן ולצוותי תפעול שמשתמשים ב-GKE כדי לפרוס שירותים בכמה אשכולות Kubernetes, או מתכננים להשתמש בו. לפני שקוראים את הדף הזה, חשוב לוודא שמכירים את Kubernetes.
שירותים מרובי אשכולות ושערים מרובי אשכולות
אפשר להפעיל את Kubernetes באמצעות רמת בקרה אחת באזורי ענן שונים כדי לספק עמידות וזמינות גבוהה יותר לשירותים שלכם.
ב-GKE, התהליך הזה מתקדם עוד שלב אחד קדימה, ומוצעים שירותים מרובי אשכולות (MCS) של GKE, שמספקים מנגנון לגילוי שירותים ולהפעלתם באשכולות שונים.
שירותים שמשתמשים בתכונה הזו ניתנים לגילוי ולגישה בכל האשכולות עם כתובת IP וירטואלית, בהתאם להתנהגות של ClusterIPשירות שניתן לגשת אליו באשכול. הגישה הזו מאפשרת ליהנות מהיתרונות הבאים:
- אפשר לבצע איזון עומסים בשירותים בכמה אשכולות באותו אזור או באזורים שונים (תעבורה ממזרח למערב).
- אפשר להשיג זמינות גבוהה של שירותים בין אזורים.
- אפשר לפרוס ולנהל עומסי עבודה (workloads) עם שמירת מצב (stateful) ועומסי עבודה ללא שמירת מצב (stateless) באשכולות נפרדים.
- שירותים משותפים זמינים בכל האשכולות.
מידע נוסף על פריסת MCS זמין במאמר הגדרת שירותים מרובי-אשכולות.
GKE מספק הטמעה של Kubernetes Gateway API שמשתמשת ב-GKE Gateway controller. שער מאפשר ל-GKE לפרוס מאזני עומסים כדי לספק ניתוב תעבורה נכנסת (צפון-דרום) לשירותים שנפרסו ב-GKE. Google Cloud פלטפורמת GKE מספקת גם שערים מרובי אשכולות (MCG) שמרחיבים את בקר השערים של GKE כדי להקצות מאזני עומסים שמנתבים את תעבורת הנתונים לשירותים שנפרסו באשכולות GKE שונים.
בתרשים הבא מוצג איך, כשמשלבים בין MCS ו-MCG, אפשר לנהל את ההיבטים המשלימים של Deployment (פריסת) שירות וניתוב תנועה ממישור בקרה יחיד:
מידע נוסף זמין במאמר בנושא פריסת שערים מרובי-אשכולות.
סקירה כללית על מיגרציה
היכולות של GKE Multi-cluster networking מועילות לעומסי עבודה (workloads) בפרופילים שונים. לדוגמה, יכול להיות שיש לכם רכיבים בלי שמירת מצב עם תנועה לא סדירה שתרצו להעביר ל-Autopilot בגלל מודל העלויות היעיל יותר שלו.
לחלופין, יכול להיות שתרצו למקם את ממשקי הקצה של האפליקציה קרוב יותר למשתמשים. הגישה הזו מספקת זמן אחזור נמוך יותר ומטמון שמשפרים את הביצועים של האפליקציה ואת חוויית המשתמש. יחד עם זאת, יכול להיות שיש לכם רכיבים עם מצב (stateful) שהאפליקציה שלכם מסתמכת עליהם, שיכולים להיות רק במיקום אחד. ההגדרה הזו דורשת איזון עומסים צפון-דרום בין כמה אשכולות כדי לשלוח תנועת לקוחות לאשכול הנכון במיקום הזה. צריך גם איזון עומסים בין אשכולות (east-west) כדי לשלוח תעבורה בין אשכולות ולהגיע לרכיבים עם שמירת מצב.
בדף הזה נעשה שימוש באפליקציית ההדגמה של מיקרו-שירותים בענן Online Boutique כדי להדגים דפוס רב-אשכולי שאפשר להשתמש בו כדי לשפר את הפריסה של ההדגמה באזור יחיד. מתחילים עם גרסה של האפליקציה שפועלת באזור אחד. לאחר מכן מוסיפים רכיבים של זמינות גבוהה וחוסן באמצעות שירותים מרובי-אשכולות ושערים מרובי-אשכולות, ומפחיתים את הטרחה התפעולית באמצעות Autopilot.
פריסה ראשונית של אשכול יחיד
בתרשים הבא, האפליקציה Online Boutique נפרסת בהתחלה באשכול יחיד במצב GKE Standard בשם std-west, והיא נחשפת באמצעות LoadBalancer Service:
העברה לשירותים מרובי אשכולות
בשלב הביניים הבא, יוצרים עוד שני אשכולות, והשירותים חסרי המצב נפרסים באזורים נוספים. יוצרים שני אשכולות GKE Autopilot בשמות auto-east ו-auto-central בשני אזורים נפרדים, שונים מאשכול GKE Standard היחיד std-west, ורושמים את האשכולות ב-Google Cloud fleet.
Fleets הם Google Cloud קונספט לארגון לוגי של אשכולות ומשאבים אחרים, והם מאפשרים לכם להשתמש ביכולות של ריבוי אשכולות ולנהל אותן, וגם להחיל מדיניות עקבית על המערכות שלכם.
מייצאים את cartservice באשכול std-west במרחב השמות onlineboutique לאשכולות החדשים של צי הרכבים באמצעות ServiceExport.
אתם פורסים את שירות הקצה הקדמי של Online Boutique בכל שלושת האשכולות, וחושפים אותו באמצעות שירות ClusterIP. לאחר מכן מייצאים את השירות לצי באמצעות ServiceExports.
שירותים כמו שכבת הביניים של Online Boutique (למשל productcatalog, shipping ו-adservice) נפרסים גם הם בכל שלושת האשכולות.
Pod שפועל בכל אשכול בצי יכול לגשת ל-Service שיוצא על ידי שליחת בקשה למזהה ה-URI של השירות ClusterSet. הבקשה מנותבת לנקודת קצה שמגבה את השירות.
שירות הקצה הקדמי יכול לצרוך את שירותי התוכנה (כמו productcatalogservice או currencyservice) באופן מקומי באותו אשכול. הארכיטקטורה הזו עוזרת לשמור על הבקשות הנכנסות מקומיות לאזורים שבהם קצה קדמי מגיב לבקשה, וכך נמנעים חיובים מיותרים על תנועה ברשת בין אזורים.
התרשים הבא ממחיש את שני השירותים מרובי האשכולות. שירות הקצה הקדמי בלי שמירת מצב נפרס בשלושה אשכולות, ושירות העגלה של הבק-אנד עם שמירת מצב נפרס באשכול אחד. בנוסף, בתרשים אפשר לראות שבשלב הביניים הזה, התנועה הנכנסת לשירות הקצה הקדמי ממשיכה להיות מנותבת לאשכול GKE Standard המקורי ב-us-west1 באמצעות מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי שנוצר על ידי שירות LoadBalancer frontend-external:
העברה אל שער מרובה אשכולות
בשלב האחרון, מנתבים תעבורה נכנסת של שירות הקצה הקדמי מבקשות של לקוחות חיצוניים לשירותים בכמה אשכולות בצי באמצעות שער מרובה אשכולות.
אשכול רביעי בשם config-central נוסף לצי כדי לארח ולנהל את ההגדרה של משאבי Gateway ו-HTTPRoute שנוצרים כחלק מההגדרה הזו. המשאב HTTPRoute ממפה את הקידומת / לקצה הקדמי של ServiceImport.
תעבורת הנתונים של חזית האתר של Online Boutique נשלחת לנקודת קצה תקינה באחד מהאזורים הזמינים. הגישה הזו מוסיפה לארכיטקטורת האפליקציה Online Boutique רכיבים של זמינות גבוהה.
בתרשים הבא, שער מרובה אשכולות פורס מאזן עומסים גלובלי בענן שמנתב תעבורה חיצונית לשירות frontend חסר מצב (stateless) שנפרס בכל אחד משלושת אשכולות האפליקציות בצי.
במצב הסופי, התבנית הזו מדגימה צימוד חלש בין החלקים עם שמירת מצב (cartservice ו-redis-cart) לבין החלקים ללא שמירת מצב של האפליקציה (frontend, emailservice, checkoutservice, recommendationservice, paymentservice, productcatalogservice, currencyservice, shippingservice ו-adservice). הגישה הזו לא מתוארת בדף הזה, אבל היא מאפשרת להוסיף בעתיד חוסן וזמינות גבוהה לשכבת השירותים עם שמירת מצב.
מטרות
- יצירה והגדרה של אשכולות GKE Standard ו-Autopilot.
- פריסת Online Boutique לאשכול GKE Standard אזורי.
- ייצוא של כמה אשכולות
Services. - פריסת מניפסטים באשכולות רגילים ובאשכולות עם טייס אוטומטי.
- הפעלה והגדרה של שערים מרובי אשכולות.
- בודקים את ההתנהגות של אפליקציה במספר אזורים.
עלויות
במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:
כדי להעריך את ההוצאות בהתאם לתחזית השימוש שלכם, אתם יכולים להיעזר במחשבון העלויות.
לפני שמתחילים
יכול להיות שהגבלות אבטחה שהוגדרו בארגון שלכם ימנעו מכם להשלים את השלבים הבאים. מידע לפתרון בעיות זמין במאמר פיתוח אפליקציות בסביבה מוגבלת. Google Cloud
לפני שמתחילים, חשוב לוודא שהדרישות הבאות מתקיימות:
- מומלץ להשתמש בפרויקט חדש כדי לתרגל את המדריך הזה, כי הדרך הכי קלה לנקות את הפרויקט היא למחוק אותו בסיום.
- במדריך הזה אנחנו יוצאים מנקודת הנחה שיש לכם את תפקיד ה-Owner IAM בפרויקטGoogle Cloud . בסביבות ייצור או בסביבות אמיתיות, מומלץ להגדיר את ההרשאות כך שיהיו הרשאות מינימליות. מידע נוסף זמין במאמרים שימוש מאובטח ב-IAM ואימות מפורש של כל ניסיון גישה.
- מומלץ לעיין בארכיטקטורה של אפליקציית ההדגמה של מיקרו-שירותים Online Boutique.
הכנת הסביבה
במדריך הזה משתמשים ב-Cloud Shell כדי להזין פקודות. Cloud Shell מאפשר לכם לגשת לשורת הפקודה בGoogle Cloud מסוף וכולל את Google Cloud SDK וכלים אחרים, כמו Google Cloud CLI. Cloud Shell מופיע כחלון בחלק התחתון של מסוףGoogle Cloud . תהליך האתחול יכול להימשך כמה דקות, אבל החלון מופיע מיד.
In the Google Cloud console, activate 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שירותים מרובי אשכולות מנהלים רכיבים כמו 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 במצבים Standard ו-Autopilot:
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 \ --async gcloud container clusters create-auto auto-east \ --location us-east1 \ --release-channel regular \ --async gcloud container clusters create-auto auto-central \ --location us-central1 \ --release-channel regular \ --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 \ --asyncאיחוד שירותי אימות הזהות של עומסי עבודה ל-GKE מופעל כברירת מחדל באשכולות GKE Autopilot, כך שלא צריך להשתמש בדגל
--workload-poolכשיוצרים את האשכולות האלה, כמו באשכולות GKE Standard.מחכים שהסטטוס של האשכולות ישתנה מהקצאת משאבים לפועל. התהליך הזה יכול להימשך עד 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 בפרויקט המארח של הצי צריך להיות התפקיד הזה.
הפלט אמור להיראות כך:
- members: - serviceAccount:PROJECT_ID.svc.id.goog[gke-mcs/gke-mcs-importer] role: roles/compute.networkViewer [...]רושמים את אשכולות GKE Standard ו-Autopilot לצי של הפרויקט. פרטים נוספים זמינים במאמר בנושא רישום של אשכול. השלב הזה יכול להימשך עד 5 דקות:
gcloud container fleet memberships register std-west \ --gke-cluster us-west1-a/std-west \ --enable-workload-identity \ --project=${PROJECT} gcloud container fleet memberships register auto-east \ --gke-cluster us-east1/auto-east \ --enable-workload-identity \ --project=${PROJECT} gcloud container fleet memberships register auto-central \ --gke-cluster us-central1/auto-central \ --enable-workload-identity \ --project=${PROJECT} gcloud container fleet memberships register config-central \ --gke-cluster us-central1/config-central \ --enable-workload-identity \ --project=${PROJECT}הפלט של כל פקודה אמור להיראות כמו בדוגמה הבאה:
Waiting for membership to be created...done. Created a new membership [projects/PROJECT_ID/locations/global/memberships/std-west] for the cluster [std-west] Generating the Connect Agent manifest... Deploying the Connect Agent on cluster [std-west] in namespace [gke-connect]... Deployed the Connect Agent on cluster [std-west] in namespace [gke-connect]. Finished registering the cluster [std-west] with the Hub.מתחברים לאשכולות ויוצרים רשומות 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במדריך הזה, ההקשרים נקראים על שם המיקום שלהם. אפשר לספק שמות חלופיים, אבל בשלבים הבאים במדריך הזה נעשה שימוש בשמות שבהם השתמשתם בשלב הזה.
יוצרים את מרחב השמות 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לכל המיקרו-שירותים של 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יוצרים את מרחב השמות 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 multi-cluster Services, לייצוא לכל האשכולות ב-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- המניפסט הראשון משמש לקצה קדמי
Deployment,Serviceו-ServiceExport. - המניפסט השני משמש לפריסת תוכנת הביניים
Services(emailservice, checkoutservice, recommendationservice, paymentservice, productcatalogservice, currencyservice, shippingservice ו-adservice) בכל האזורים שבהם פועל 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מוודאים שכל האשכולות נרשמו בהצלחה לצי:
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 בשכבה 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יוצרים את תאי הלקוח:
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התוצאות האלה מאשרות שהתנועה מנותבת אל התאים המתאימים במיקומים הקרובים ביותר למקור הבקשה.
מריצים את פקודת ה-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בקטגוריות בחירה אוטומטית-מזרח או בחירה אוטומטית-מרכז: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מריצים את הפקודה כמה פעמים כדי לראות תוצאות מתחלפות.
יצירה והגדרה של אשכולות GKE
כדי להדגים את התבנית של כמה אשכולות במדריך הזה, משתמשים בשלושה אשכולות של אפליקציות בשלושה אזורים נפרדים בענן, ובאשכול אחד לאירוח ההגדרה של משאבי שער. אתם רושמים את כל האשכולות ב-Fleet שמשויך לפרויקט. לכל פרויקט ב- Google Cloud יכול להיות משויך רק צי אחד של מכונות. הפרויקט הזה נקרא פרויקט המארח של הצי.
פריסת Online Boutique ב-GKE Standard
בשלב הראשון של פריסת ההדגמה, פורסים את כל שירותי האפליקציה Online Boutique לאשכול GKE Standard יחיד, std-west, ב-us-west1.
עכשיו פועלת גרסה של Online Boutique עם אזור יחיד ב-us-west1-a.
אפשר גם להשתמש בדפדפן אינטרנט כדי לנווט לכתובת ה-IP החיצונית שהוקצתה לשירות frontend-external LoadBalancer כדי לגשת לאפליקציה ולבחון את ההתנהגות שלה. הפריסה הראשונית היחידה הזו מוצגת בתרשים הבא:
ייצוא של cartservice כשירות מרובה אשכולות
בקטע הזה מתחילים להוסיף רכיבים של זמינות גבוהה לאפליקציה. מייצאים את ה-backend cartservice כשירות מרובה אשכולות לאשכולות GKE Autopilot.
החלת מניפסטים של אפליקציות לתבנית של כמה אשכולות
בקטע הזה תחיל שני מניפסטים שנבחרו בקפידה כדי לפרוס את התבנית של כמה אשכולות. קובצי המניפסט האלה מכילים חלקים נבחרים מתוך kubernetes-manifests.yaml שהחלתם קודם על אשכול std-west:
שירות 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 לא זמינה, ותגרום למצב לא תקין של הפודים של frontend.
עכשיו יש לך את הקצה הקדמי Deployment, Service ו-ServiceExport פעילים באשכולות std-west, auto-east ו-auto-central. בכל אשכול יש גם שירותי תוכנת ביניים של Online Boutique שפועלים באופן מקומי. עם זאת, תנועה חיצונית עדיין מנותבת רק אל Service שפועל באשכול הראשוני ב-us-west1, כפי שמוצג בתרשים הבא:
הפעלה והגדרה של שערים מרובי אשכולות
בקטע הזה, אתם מנתבים תנועה ומאזנים עומסים של תנועה חיצונית בין חזיתות קצה בכל שלושת האשכולות. כדי להשיג את ההגדרה הזו, משתמשים בשערים מרובי אשכולות (MCG). השלבים האלה להגדרת MCG מבוססים על ההנחיות שמתוארות בפירוט במאמר בנושא הפעלת שערים מרובי אשכולות.
בשלבים האלה משתמשים באשכול config-central כדי לארח את ההגדרה של משאבי השער.
בדיקת התנהגות הניתוב של אפליקציה במספר אזורים
אחת מהתכונות המתקדמות שמתקבלות באמצעות שימוש בשירותים מרובי-אשכולות ובשערי כניסה מרובי-אשכולות היא שבקשות חיצוניות מנותבות לאשכול הקרוב ביותר מבחינה גיאוגרפית.
כדי לבדוק את ההתנהגות של אפליקציה במספר אזורים, צריך ליצור תעבורת נתונים שמגיעה מהאזורים השונים שבהם פרסתם אשכולות. יוצרים שלושה פודים קטנים, אחד בכל אחד מהאשכולות שמשרתים את התנועה (std-west, auto-east ו-auto-central), שאפשר להשתמש בהם כדי לשלוח בקשות HTTP לנקודת הקצה של מאזן העומסים. התוצאות מאפשרות לראות איזה קצה קדמי Pod מגיב.
בדיקת עמידות של אפליקציה במספר אזורים
בנוסף לניתוב יעיל של התנועה, הפעלת השירותים בכמה אזורים מספקת עמידות במקרה הנדיר, אך עדיין אפשרי, של כשל בתשתית.
כדי לבדוק את ההתנהגות, מוחקים את קצה קדמי Deployments באשכולות ספציפיים ואז מנסים שוב להריץ את פקודת curl מהלקוח Pod באזורים האלה. שימו לב שהאפליקציה עדיין זמינה, ובדקו את המיקום של Pod שמגיב לבקשה.
בפריסת ההדגמה הזו, הוספתם רכיבים של גמישות ושל חלוקה גיאוגרפית לאפליקציית Online Boutique באמצעות שירותים מרובי אשכולות ושערים מרובי אשכולות. הבקשות מנותבות לאזור הגיאוגרפי הקרוב ביותר, וגם אם יש בעיות בשירותי חזית האפליקציה או בשירותי הביניים באזור מסוים, משתמש הקצה עדיין יכול להשתמש באפליקציה בהצלחה.
הסרת המשאבים
כדי לא לצבור חיובים לחשבון Google Cloud על המשאבים שבהם השתמשתם במדריך הזה, אתם יכולים למחוק את הפרויקט שמכיל את המשאבים או להשאיר את הפרויקט ולמחוק את המשאבים בנפרד.
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
המאמרים הבאים
- Google Cloud מידע נוסף על ניהול של צי מכונות ושל כמה אשכולות
- איך רושמים אשכול, כולל אשכולות GKE, ל- Google Cloud fleet.
- מידע נוסף על Kubernetes Gateway API ועל GKE Gateway
- כדאי להעמיק את הקריאה ולהכיר דוגמאות לארכיטקטורות, תרשימים ושיטות מומלצות בנושאי Google Cloud. כל אלה זמינים במרכז הארכיטקטורה של Cloud.