פריסת Redis ב-GKE באמצעות Redis Enterprise

במדריך הזה נסביר איך לפרוס את Redis Enterprise באשכולות של Google Kubernetes Engine ‏ (GKE).

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

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

יש תמחור שונה לכל אפשרות פריסה של Redis Enterprise, כולל: תוכנה, ענן או ענן היברידי וענן מרובה.

המדריך הזה מיועד לאדמינים של פלטפורמות, למומחי Cloud Architect ולמומחי תפעול שרוצים לפרוס את Redis Enterprise ב-Google Kubernetes Engine ‏ (GKE).

מטרות

  • תכנון ופריסה של תשתית GKE ל-Redis
  • פריסת Redis Enterprise Operator
  • פריסת אשכול Redis Enterprise
  • יצירת מסד נתונים של Redis Enterprise
  • הדגמה של אימות מסד נתונים

יתרונות

היתרונות של Redis Enterprise:

  • דרך מקורית ל-Kubernetes לניהול מחזור החיים של Redis Enterprise Cluster ‏ (REC) ושל Redis Enterprise Databases ‏ (REDBs)
  • ניצול משאבים באמצעות מיקום משותף של כמה מסדי נתונים של Redis ב-Pod יחיד של Kubernetes
  • צמצום התקורה התפעולית באמצעות טיפול במשימות תחזוקה שגרתיות כמו תיקון באגים ושדרוגים
  • תמיכה בקובצי אימג' של תוכנת Redis ממאגרי קונטיינרים פרטיים, כמו Artifact Registry, כדי לשפר את האבטחה והזמינות של קונטיינרים
  • תמיכה בשירות המנוהל של Google Cloud ל-Prometheus לצורך מעקב אחר מסדי נתונים וניראות (observability)
  • תכונות אבטחה משופרות כמו הצפנה, אמצעי בקרה לגישה ושילוב עם Kubernetes RBAC (בקרת גישה מבוססת-תפקידים)
  • שיטות אימות מתקדמות, כולל LDAP ומנהלי אישורים של צד שלישי כמו Vault
  • יכולת להגדיר גיבויים מתוזמנים

ארכיטקטורת פריסה

‫Redis Enterprise מנהל את המשאבים הבאים ב-Kubernetes:

  • האשכול Enterprise וההגדרה שלו ב-StatefulSet. האשכול מורכב מצמתים (Pods) של Redis עם חבילות Redis מותקנות. בצמתים האלה פועלים תהליכים כדי לוודא שהצומת הוא חלק מאשכול. כל צומת מספק קונטיינר להפעלת כמה מופעים של מסד נתונים (רסיסים). למרות שבשיטות המומלצות של Kubernetes מצוין ש-Pod צריך לייצג אפליקציה אחת עם קונטיינר אחד, Redis Enterprise פורס כמה מסדי נתונים של Redis לקונטיינר אחד. הגישה הזו מאפשרת שימוש טוב יותר במשאבים, ביצועים טובים יותר וקצב העברת נתונים טוב יותר ברשת. בכל מאגר יש גם שרת proxy עם אפס זמן אחזור לניתוב תנועה ולניהול שלה לתהליכים ספציפיים של מסד נתונים של Redis בתוך מאגר.
  • משאב מותאם אישית RedisEnterpriseDatabase (REDBs) שמייצג את מופעי מסד הנתונים של Redis שנוצרו בתוך ה-REC
  • שירותי Kubernetes שמשרתים מופעי REDB כנקודות קצה של מסד נתונים
  • ‫Pod של בקר בשם Service Rigger שיוצר ומוחק נקודות קצה של מסד נתונים כשמסד נתונים נוצר או נמחק

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

בתרשים הבא מתוארים הרכיבים של Redis Enterprise והקשר ביניהם:

תרשים שמציג דוגמה לארכיטקטורת Redis Enterprise.
איור 1: דוגמה לארכיטקטורה של Redis Enterprise.

במדריך הזה תלמדו איך להגדיר את Redis Enterprise Cluster כך שתהיה לו זמינות גבוהה. כדי לעשות זאת, ה-REC צריך מספר אי-זוגי של צמתים, ולפחות שלושה צמתים. אתם גם מגדירים כללי שיוך, כללים למניעת שיוך וכתמי צומת, כדי לוודא שכל צומת Redis ממוקם בצומת Kubernetes אחר, ושהצמתים של Redis מפוזרים באופן שווה באשכול Kubernetes.

שימוש בכמה צמתים ותחומים הוא חיוני כדי להשיג אשכול GKE עם זמינות גבוהה, מהסיבות הבאות:

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

עלויות

במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

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

משתמשים חדשים של Google Cloud ? יכול להיות שאתם זכאים לתקופת ניסיון בחינם.

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

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

  1. התקינו את ה-CLI של Google Cloud.

  2. הגדירו שה-CLI של gcloud ישתמש בזהות המאוחדת שלכם.

    איך נכנסים ל-CLI של gcloud באמצעות הזהות המאוחדת?

  3. כדי לאתחל את ה-CLI של gcloud, הריצו את הפקודה הבאה: 

    gcloud init

  4. יוצרים או בוחרים Google Cloud פרויקט.

    תפקידים שנדרשים כדי לבחור או ליצור פרויקט

    • Select a project: כדי לבחור פרויקט לא צריך תפקיד IAM ספציפי – אפשר לבחור כל פרויקט שקיבלתם בו תפקיד.
    • יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד Project Creator (יצירת פרויקטים) (roles/resourcemanager.projectCreator), שכולל את ההרשאה resourcemanager.projects.create. איך מקצים תפקידים

    • יוצרים Google Cloud פרויקט:

      gcloud projects create PROJECT_ID

      מחליפים את PROJECT_ID בשם של פרויקט Google Cloud שיוצרים.

    • בוחרים את הפרויקט שיצרתם: Google Cloud 

      gcloud config set project PROJECT_ID

      מחליפים את PROJECT_ID בשם הפרויקט ב- Google Cloud .

  5. מוודאים שהחיוב מופעל בפרויקט Google Cloud .

  6. מפעילים את ממשקי ה-API של Compute Engine,‏ IAM,‏ GKE ומנהל המשאבים:

    תפקידים שנדרשים להפעלת ממשקי API

    כדי להפעיל ממשקי API, צריך את תפקיד ה-IAM 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים 

    gcloud services enable compute.googleapis.com iam.googleapis.com container.googleapis.com cloudresourcemanager.googleapis.com

  7. מעניקים תפקידים לחשבון המשתמש. מריצים את הפקודה הבאה לכל אחד מהתפקידים הבאים ב-IAM: roles/compute.securityAdmin, roles/compute.viewer, roles/container.clusterAdmin, roles/container.admin, roles/iam.serviceAccountAdmin, roles/iam.serviceAccountUser 

    gcloud projects add-iam-policy-binding PROJECT_ID --member="user:USER_IDENTIFIER" --role=ROLE

    מחליפים את מה שכתוב בשדות הבאים:

מגדירים את הסביבה

במדריך הזה משתמשים ב-Cloud Shell כדי לנהל משאבים שמתארחים ב-Google Cloud. ב-Cloud Shell מותקנת מראש התוכנה שצריך למדריך הזה, כולל kubectl,‏ ה-CLI של gcloud ו-Terraform.

כדי להגדיר את הסביבה באמצעות Cloud Shell:

  1. מפעילים סשן של Cloud Shell מGoogle Cloud המסוף על ידי לחיצה על Activate Cloud Shell סמל ההפעלה של Cloud Shell. Google Cloud ייפתח סשן בחלונית התחתונה של מסוף Google Cloud .

  2. הגדרת משתני סביבה:

    export PROJECT_ID=PROJECT_ID
export KUBERNETES_CLUSTER_PREFIX=redis
export REGION=us-central1

    מחליפים את PROJECT_ID: your Google Cloud במזהה הפרויקט.

  3. משכפלים את המאגר ב-GitHub:

    git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples

  4. עוברים לספריית העבודה:

    cd kubernetes-engine-samples/databases/redis-enterprise-operator

יצירת תשתית האשכול

בקטע הזה מריצים סקריפט של Terraform כדי ליצור אשכול GKE פרטי, זמין מאוד ואזורי, ו-VPC.

בתרשים הבא מוצג אשכול GKE פרטי אזורי מסוג Standard שנפרס בשלושה אזורים שונים:

כדי לפרוס את התשתית הזו, מריצים את הפקודות הבאות מ-Cloud Shell:

  cd terraform/gke-standard
  export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token)
  terraform init
  terraform apply -var project_id=${PROJECT_ID}   \
    -var region=${REGION}  \
    -var cluster_prefix=${KUBERNETES_CLUSTER_PREFIX}

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

‫Terraform יוצר את המשאבים הבאים:

  • רשת VPC ותת-רשת פרטית לצמתים של Kubernetes
  • נתב לגישה לאינטרנט דרך NAT
  • אשכול GKE פרטי באזור us-central1
  • מאגר צמתים אחד עם הפעלה של התאמה אוטומטית לעומס (צומת אחד עד שני צמתים לכל אזור, צומת אחד לכל אזור לכל הפחות)

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

...
Apply complete! Resources: 14 added, 0 changed, 0 destroyed.
...

התחברות לאשכול

באמצעות Cloud Shell, מגדירים את kubectl לתקשורת עם האשכול:

gcloud container clusters get-credentials ${KUBERNETES_CLUSTER_PREFIX}-cluster --location ${REGION}

פריסת האופרטור Redis Enterprise באשכול

בקטע הזה פורסים את Redis Enterprise operator באשכול Kubernetes.

  1. יוצרים מרחבי שמות עבור ה-REC והאפליקציות שלו:

    kubectl create namespace rec-ns
kubectl create namespace application

  2. נותנים שמות למרחבי השמות:

    kubectl label namespace rec-ns connection=redis
kubectl label namespace application connection=redis

  3. מורידים את הגרסה האחרונה של חבילת Redis Enterprise Operator:

    VERSION=`curl --silent https://api.github.com/repos/RedisLabs/redis-enterprise-k8s-docs/releases/latest | grep tag_name | awk -F'"' '{print $4}'`

  4. מתקינים את האופרטור של Redis Enterprise:

    kubectl apply -n rec-ns -f https://raw.githubusercontent.com/RedisLabs/redis-enterprise-k8s-docs/$VERSION/bundle.yaml

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

    role.rbac.authorization.k8s.io/redis-enterprise-operator created
rolebinding.rbac.authorization.k8s.io/redis-enterprise-operator created
serviceaccount/redis-enterprise-operator created
service/admission created
customresourcedefinition.apiextensions.k8s.io/redisenterpriseclusters.app.redislabs.com created
customresourcedefinition.apiextensions.k8s.io/redisenterprisedatabases.app.redislabs.com created
customresourcedefinition.apiextensions.k8s.io/redisenterpriseremoteclusters.app.redislabs.com created
customresourcedefinition.apiextensions.k8s.io/redisenterpriseactiveactivedatabases.app.redislabs.com created
deployment.apps/redis-enterprise-operator created

פריסת Redis Enterprise Cluster

  1. מחילים את המניפסט על האשכול:

    kubectl apply -n rec-ns -f manifests/01-basic-cluster/rec.yaml

    יכול להיות שיעברו כמה דקות עד שהפקודה תושלם.

  2. בודקים את הסטטוס של פריסת ה-REC:

    kubectl get rec -n rec-ns

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

    NAME      NODES   VERSION    STATE     SPEC STATUS   LICENSE STATE   SHARDS LIMIT   LICENSE EXPIRATION DATE   AGE
gke-rec   3       7.2.4-52   Running   Valid         Valid           4              2023-09-29T20:15:32Z      4m7s

    האשכול מוכן כש-STATE הוא RUNNING.

אופציונלי: הגדרת בקרת הכניסה

אופציונלי: אתם יכולים להגדיר תשתית לאימות מסד הנתונים במהלך הפריסה.

  1. מגדירים את בקרת הכניסה ובודקים אם יש סוד TLS של אישור בקשות:

    kubectl get secret admission-tls -n rec-ns

  2. קבלת האישור:

    export CERT=$(kubectl get secret admission-tls -n rec-ns -o jsonpath='{.data.cert}')

  3. מעתיקים את האישור לקובץ webhook.yaml:

    sed -i -e 's/CRT/'$CERT'/g' manifests/01-basic-cluster/webhook.yaml

  4. פורסים את ה-Webhook של האימות:

    sed -i -e 's/CRT/'$CERT'/g' manifests/01-basic-cluster/webhook.yaml

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

  5. כדי לאמת את בקרת הכניסה, יוצרים מסד נתונים לא תקין:

    kubectl apply -n rec-ns -f - << EOF
apiVersion: app.redislabs.com/v1alpha1
kind: RedisEnterpriseDatabase
metadata:
  name: redis-enterprise-database
spec:
  evictionPolicy: illegal
EOF

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

    Error from server: error when creating "STDIN": admission webhook "redisenterprise.admission.redislabs" denied the request: 'illegal' is an invalid value for 'eviction_policy'. Possible values are ['volatile-lru', 'volatile-ttl', 'volatile-random', 'allkeys-lru', 'allkeys-random', 'noeviction', 'volatile-lfu', 'allkeys-lfu']

יצירת מרחבי שמות

כברירת מחדל, לאופרטור של Redis Enterprise אין הרשאות לבצע פעולות מחוץ למרחב השמות שלו. כדי לאפשר ל-Redis Enterprise Operator ליצור נקודות קצה של REDB ומסדי נתונים במרחבי שמות אחרים, צריך להגדיר RBAC.

  1. מחילים את התפקיד המתאים ואת קישור התפקיד במרחב השמות של האפליקציה:

    kubectl apply -f manifests/01-basic-cluster/role.yaml -n application
kubectl apply -f manifests/01-basic-cluster/role-binding.yaml -n application

  2. יוצרים תפקיד באשכול וקישור תפקיד באשכול במרחב השמות rec-ns:

    kubectl apply -n rec-ns -f manifests/01-basic-cluster/cluster_role.yaml
kubectl apply -n rec-ns -f manifests/01-basic-cluster/cluster_role_binding.yaml

  3. עורכים את ה-ConfigMap של ה-REC כדי להוסיף שליטה במרחב השמות של האפליקציה:

    kubectl patch ConfigMap/operator-environment-config --type merge -p '{"data": {"REDB_NAMESPACES_LABEL": "connection=redis"}}' -n rec-ns

    כל מרחב שמות שמסומן כ-ConfigMap עובר תיקון.

  4. בודקים את הסטטוס של המשאבים בתשתית Redis ב-namespace:‏ rec-ns.

    kubectl get pod,deploy,svc,rec,statefulset,cm,secrets -n rec-ns

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

    NAME                                             READY   STATUS    RESTARTS        AGE
pod/gke-rec-0                                    2/2     Running   0               172m
pod/gke-rec-1                                    2/2     Running   0               171m
pod/gke-rec-2                                    2/2     Running   0               168m
pod/gke-rec-services-rigger-5f885f59dc-gc79g     1/1     Running   0               172m
pod/redis-enterprise-operator-6668ccd8dc-kx29z   2/2     Running   2 (5m58s ago)   5h

NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/gke-rec-services-rigger     1/1     1            1           172m
deployment.apps/redis-enterprise-operator   1/1     1            1           5h

NAME                   TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)             AGE
service/admission      ClusterIP   10.52.11.13   <none>        443/TCP             5h
service/gke-rec        ClusterIP   10.52.5.44    <none>        9443/TCP,8001/TCP   172m
service/gke-rec-prom   ClusterIP   None          <none>        8070/TCP            172m
service/gke-rec-ui     ClusterIP   10.52.3.29    <none>        8443/TCP            172m

NAME                                               NODES   VERSION    STATE     SPEC STATUS   LICENSE STATE   SHARDS LIMIT   LICENSE EXPIRATION DATE   AGE
redisenterprisecluster.app.redislabs.com/gke-rec   3       7.2.4-52   Running   Valid         Valid           4              2023-10-05T11:07:20Z      172m

NAME                       READY   AGE
statefulset.apps/gke-rec   3/3     172m

NAME                                    DATA   AGE
configmap/gke-rec-bulletin-board        1      172m
configmap/gke-rec-health-check          5      172m
configmap/kube-root-ca.crt              1      5h2m
configmap/operator-environment-config   1      5h

NAME                   TYPE     DATA   AGE
secret/admission-tls   Opaque   2      5h
secret/gke-rec         Opaque   2      172m

פריסת מסדי נתונים של Redis Enterprise

  1. יצירת מסדי נתונים של Redis Enterprise במרחבי השמות של האפליקציה:

    kubectl apply -f manifests/01-basic-cluster/a-rdb.yaml -n application

  2. בודקים את הסטטוס של REDB:

    kubectl get redb --all-namespaces

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

    NAMESPACE       NAME       VERSION   PORT    CLUSTER   SHARDS   STATUS   SPEC STATUS   AGE
application   app-db   7.2.0     12999   gke-rec   1        active   Valid         15s

  3. מוודאים שהשירותים של כל REDB פועלים:

    kubectl get svc --all-namespaces

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

    NAMESPACE      NAME      TYPE          CLUSTER-IP   EXTERNAL-IP                           PORT(S)    AGE
application  app-db  ExternalName  <none>       redis-12999.rec-ns.svc.cluster.local  12999/TCP  72m

  4. מוודאים שהסוד נוצר:

    kubectl get secrets -n application

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

    NAME            TYPE     DATA   AGE
redb-app-db   Opaque   3      96m

אימות באמצעות סיסמאות

אפשר להתחבר ל-REDB באמצעות Pod עם redis-cli במרחב השמות של האפליקציה. ה-Pod של הלקוח משתמש בסודות שזמינים במרחב השמות של האפליקציה (REDB) כדי ליצור חיבור.

מסדי נתונים שנוצרו באמצעות REDB של משאב בהתאמה אישית תומכים רק באימות באמצעות סיסמה ללא ACL.

  1. יוצרים את ה-Pod של הלקוח:

    kubectl apply -n application -f manifests/03-auth/client_pod.yaml

  2. מתחברים ל-Pod של הלקוח:

    kubectl exec -n application -i -t redis-client -c redis-client -- /bin/sh

  3. מתחברים למסד הנתונים:

    redis-cli -h $SERVICE -p $PORT --pass $PASS

  4. יוצרים מפתח:

    SET mykey "Hello World"

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

    OK

  5. מקבלים את המפתח:

    GET mykey

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

    "Hello World"

  6. יציאה מהמעטפת של ה-Pod

    exit

הסבר על אופן איסוף המדדים על ידי Prometheus עבור אשכול Redis

בתרשים הבא אפשר לראות איך מתבצע איסוף מדדים של Prometheus:

בתרשים, אשכול פרטי של GKE מכיל:

  • ‫Redis Pod שאוסף מדדים בנתיב / ובפורט 8070
  • אוספי נתונים מבוססי Prometheus שמעבדים את המדדים מ-Redis Pod
  • משאב PodMonitoring ששולח מדדים ל-Cloud Monitoring

האופרטור Redis Enterprise חושף מדדי אשכול בפורמט Prometheus.

  1. יוצרים את פריסת ה-metrics-proxy:

    kubectl apply -n rec-ns -f manifests/02-prometheus-metrics/metrics-proxy.yaml

    מכיוון שהאופרטור מספק רק נקודת קצה של HTTPS עם אישור בחתימה עצמית, והמשאב PodMonitoring לא תומך בהשבתת אימות אישור TLS, משתמשים ב-Pod‏ metrics-proxy כשרת proxy הפוך לנקודת הקצה הזו כדי לחשוף את המדדים ביציאת HTTP.

  2. יוצרים את המשאב PodMonitoring כדי לגרד מדדים באמצעות labelSelector:

    kubectl apply -n rec-ns -f manifests/02-prometheus-metrics/pod-monitoring.yaml

  3. נכנסים לדף GKE Clusters Dashboard במסוף Google Cloud .

    כניסה ללוח הבקרה של GKE Clusters

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

יצירת מרכז בקרה

כדי לראות את המדדים, צריך ליצור מרכז בקרה.

  1. יוצרים את לוח הבקרה:

    gcloud --project "${PROJECT_ID}" monitoring dashboards create --config-from-file monitoring/dashboard.json

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

    Created [f4efbe4e-2605-46b4-9910-54b13d29b3be].

  2. נכנסים לדף Dashboards במסוף Google Cloud .

    מעבר למרכזי השליטה

  3. פותחים את לוח הבקרה של Redis Enterprise Cluster. יכול להיות שיחלפו כמה דקות עד שהלוח יוקצה אוטומטית.

אימות המדדים שיוצאו

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

  1. פותחים את לוח הבקרה של Redis Enterprise Cluster.

  2. יוצרים מסד נתונים נוסף של Redis:

    kubectl apply -n rec-ns -f manifests/02-prometheus-metrics/c-rdb.yaml

    הערך Database Count (מספר מסדי הנתונים) בלוח הבקרה אמור להתעדכן.

  3. יוצרים Pod של לקוח כדי להתחבר למסד הנתונים החדש:

    kubectl apply -n rec-ns -f manifests/02-prometheus-metrics/client_pod.yaml

  4. מתחברים ל-Pod של הלקוח ומכינים את המשתנים:

    kubectl exec -it redis-client-c -n rec-ns -- /bin/bash

  5. משתמשים בכלי redis-cli כדי ליצור מפתחות חדשים:

    for i in {1..50}; do \
  redis-cli -h $SERVICE -p $PORT -a $PASS \
  --no-auth-warning SET mykey-$i "myvalue-$i"; \
done

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

  7. יציאה מהמעטפת של ה-Pod

    exit

הסרת המשאבים

מחיקת הפרויקט

    כדי למחוק Google Cloud פרויקט:

    gcloud projects delete PROJECT_ID

מחיקת משאבים בודדים

  1. מגדירים משתני סביבה.

    export PROJECT_ID=${PROJECT_ID}
export KUBERNETES_CLUSTER_PREFIX=redis
export REGION=us-central1

  2. מריצים את הפקודה terraform destroy:

    export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token)
cd terraform/gke-standard
terraform destroy -var project_id=${PROJECT_ID}   \
  -var region=${REGION}  \
  -var cluster_prefix=${KUBERNETES_CLUSTER_PREFIX}

    כשמופיעה בקשה, כותבים yes.

  3. חיפוש כל הדיסקים שלא צורפו:

    export disk_list=$(gcloud compute disks list --filter="-users:* AND labels.name=${KUBERNETES_CLUSTER_PREFIX}-cluster" --format "value[separator=|](name,zone)")

  4. מוחקים את הדיסקים:

    for i in $disk_list; do
  disk_name=$(echo $i| cut -d'|' -f1)
  disk_zone=$(echo $i| cut -d'|' -f2|sed 's|.*/||')
  echo "Deleting $disk_name"
  gcloud compute disks delete $disk_name --zone $disk_zone --quiet
done

  5. מחיקת המאגר ב-GitHub:

    rm -r ~/kubernetes-engine-samples/

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

  • כדאי להעמיק את הקריאה ולהכיר דוגמאות לארכיטקטורות, תרשימים ושיטות מומלצות בנושאי Google Cloud. כל אלה זמינים במרכז הארכיטקטורה של Cloud.