‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

Standard

במדריך הזה נסביר איך לפרוס את 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 מ-Container Registry פרטיים, כמו Artifact Registry, כדי לשפר את האבטחה והזמינות של הקונטיינרים
תמיכה בשירות המנוהל של Google Cloud ל-Prometheus לצורך מעקב אחר מסדי נתונים וניראות (observability)
תכונות אבטחה משופרות כמו הצפנה, אמצעי בקרה לגישה ושילוב עם Kubernetes RBAC (בקרת גישה מבוססת-תפקידים)
שיטות אימות מתקדמות, כולל LDAP ומנהלי אישורים של צד שלישי כמו Vault
אפשרות להגדיר גיבויים מתוזמנים

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

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

אשכול Enterprise וההגדרה שלו ב-StatefulSet. האשכול מורכב מצמתי Redis ‏ (Pods) עם חבילות Redis מותקנות. בצמתים האלה פועלים תהליכים כדי לוודא שהצומת הוא חלק מאשכול. כל צומת מספק קונטיינר להפעלת כמה מופעים של מסד נתונים (רסיסים). למרות שבשיטות המומלצות של Kubernetes מצוין ש-Pod צריך לייצג אפליקציה אחת עם קונטיינר אחד, Redis Enterprise פורס כמה מסדי נתונים של Redis לקונטיינר אחד. הגישה הזו מאפשרת שימוש טוב יותר במשאבים, ביצועים טובים יותר וקצב העברת נתונים גבוה יותר ברשת. בנוסף, לכל קונטיינר יש פרוקסי עם אפס זמן אחזור לניתוב ולניהול של תנועת משתמשים לתהליכי מסד נתונים ספציפיים של 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 יש הסכמי SLA לפריסות בכמה אזורים, שמבטיחים רמה מינימלית של זמן פעולה תקינה וזמינות.

עלויות

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

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

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

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

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

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

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

הערה: אם התקנתם את ה-CLI של gcloud, השתמשו בפקודה gcloud components update כדי לבדוק אם הגרסה העדכנית מותקנת.

אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

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

gcloud init

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

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

Select a project: כדי לבחור פרויקט לא צריך תפקיד IAM ספציפי – אפשר לבחור כל פרויקט שקיבלתם בו תפקיד.
יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד "יצירת פרויקטים" (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 .

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

מפעילים את ממשקי ה-API של Compute Engine,‏ IAM,‏ GKE ומנהל המשאבים, אם אחד מהם לא מופעל כבר:

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

כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק Service Usage' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

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

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

הערה: אם התקנתם את ה-CLI של gcloud, השתמשו בפקודה gcloud components update כדי לבדוק אם הגרסה העדכנית מותקנת.

אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

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

gcloud init

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

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

Select a project: כדי לבחור פרויקט לא צריך תפקיד IAM ספציפי – אפשר לבחור כל פרויקט שקיבלתם בו תפקיד.
יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד "יצירת פרויקטים" (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 .

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

מפעילים את ממשקי ה-API של Compute Engine,‏ IAM,‏ GKE ומנהל המשאבים, אם אחד מהם לא מופעל כבר:

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

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

מעניקים תפקידים לחשבון המשתמש. מריצים את הפקודה הבאה לכל אחד מהתפקידים הבאים ב-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
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫PROJECT_ID: מזהה הפרויקט.
- ‫USER_IDENTIFIER: המזהה של חשבון המשתמש . לדוגמה, myemail@example.com.
- ‫ROLE: תפקיד ה-IAM שאתם מקצים לחשבון המשתמש.

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

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

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

מפעילים סשן של Cloud Shell מGoogle Cloud המסוף על ידי לחיצה על Activate Cloud Shell . Google Cloud הפעולה הזו מפעילה סשן בחלונית התחתונה של מסוף Google Cloud .
מגדירים את משתני הסביבה:
```
export PROJECT_ID=PROJECT_ID
export KUBERNETES_CLUSTER_PREFIX=redis
export REGION=us-central1
```
מחליפים את PROJECT_ID: Google Cloud במזהה הפרויקט.

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

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

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

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 באשכול Kubernetes.

יוצרים מרחבי שמות (namespaces) ל-REC ולאפליקציות שלו:
```
kubectl create namespace rec-ns
kubectl create namespace application
```

מוסיפים תוויות למרחבי השמות:

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

מורידים את הגרסה האחרונה של חבילת 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}'`

מתקינים את האופרטור של 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

מחילים את המניפסט על האשכול:
```
kubectl apply -n rec-ns -f manifests/01-basic-cluster/rec.yaml
```
יכול להיות שהפקודה תימשך כמה דקות.

בודקים את סטטוס הפריסה של ה-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.

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

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

מגדירים את בקרת אישור הבקשות ובודקים אם הסוד של TLS לאישור בקשות קיים:
```
kubectl get secret admission-tls -n rec-ns
```

כדי לקבל את האישור:

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

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

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

פורסים את ה-webhook של האימות:
```
sed -i -e 's/CRT/'$CERT'/g' manifests/01-basic-cluster/webhook.yaml
```
בקרת הכניסה מאמתת את תחביר מסד הנתונים במרחבי שמות עם תוויות.

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

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

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

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

יוצרים תפקיד באשכול וקישור תפקידים באשכול במרחב השמות 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

עורכים את ה-ConfigMap של ה-REC כדי להוסיף שליטה במרחב השמות של האפליקציה:
```
kubectl patch ConfigMap/operator-environment-config --type merge -p '{"data": {"REDB_NAMESPACES_LABEL": "connection=redis"}}' -n rec-ns
```
כל מרחב שמות שמסומן כ-ConfigMap עובר תיקון.

בודקים את הסטטוס של המשאבים בתשתית Redis ב-rec-nsnamespace:.

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

יוצרים מסדי נתונים של Redis Enterprise במרחבי השמות של האפליקציה:
```
kubectl apply -f manifests/01-basic-cluster/a-rdb.yaml -n application
```

בודקים את הסטטוס של 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

מוודאים שהשירותים של כל 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

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

kubectl get secrets -n application

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

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

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

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

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

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

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

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

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

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

יוצרים מפתח:
```
SET mykey "Hello World"
```
הפלט אמור להיראות כך:
```
OK
```
מקבלים את המפתח:
```
GET mykey
```
הפלט אמור להיראות כך:
```
"Hello World"
```
יציאה מהמעטפת של Pod
```
exit
```

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

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

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

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

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

יוצרים את פריסת ה-metrics-proxy:
```
kubectl apply -n rec-ns -f manifests/02-prometheus-metrics/metrics-proxy.yaml
```
מכיוון שהאופרטור מספק רק נקודת קצה של HTTPS עם האישור בחתימה עצמית, והמשאב PodMonitoring לא תומך בהשבתת האימות של אישור TLS, משתמשים ב-Pod‏ metrics-proxy כפרוקסי הפוך לנקודת הקצה הזו כדי לחשוף את המדדים ביציאת ה-HTTP.
יוצרים את המשאב PodMonitoring כדי לגרד מדדים באמצעות labelSelector:
```
kubectl apply -n rec-ns -f manifests/02-prometheus-metrics/pod-monitoring.yaml
```
נכנסים לדף GKE Clusters Dashboard במסוף Google Cloud .

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

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

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

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

יוצרים את מרכז הבקרה:

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

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

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

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

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

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

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

פותחים את מרכז הבקרה של Redis Enterprise Cluster.
יוצרים מסד נתונים נוסף של Redis:
```
kubectl apply -n rec-ns -f manifests/02-prometheus-metrics/c-rdb.yaml
```
הערך של Database Count בלוח הבקרה אמור להתעדכן.
יוצרים Pod של לקוח כדי להתחבר למסד הנתונים החדש:
```
kubectl apply -n rec-ns -f manifests/02-prometheus-metrics/client_pod.yaml
```
מתחברים ל-Pod של הלקוח ומכינים משתנים:
```
kubectl exec -it redis-client-c -n rec-ns -- /bin/bash
```

משתמשים בכלי 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

מרעננים את הדף ורואים שהגרפים עודכנו ומציגים את המצב בפועל של מסד הנתונים.
יציאה מהמעטפת של ה-Pod
```
exit
```

הסרת המשאבים

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

זהירות: כשמוחקים פרויקט:

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

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

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

gcloud projects delete PROJECT_ID

מחיקת משאבים ספציפיים

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

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

מריצים את הפקודה 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.

חיפוש כל הדיסקים שלא מחוברים:

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

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

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

מחיקת המאגר ב-GitHub:
```
rm -r ~/kubernetes-engine-samples/
```

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

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

פריסת Redis ב-GKE באמצעות Redis Enterprise קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

מטרות

יתרונות

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

עלויות

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

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

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

התחברות לאוסף

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

פריסת Redis Enterprise Cluster

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

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

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

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

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

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

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

הסרת המשאבים

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

מחיקת משאבים ספציפיים

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

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