ניהול השירותים של Google

‫Distributed Cloud במודל מחובר תומך בפריסה של מספר שירותים של Google Cloud . עומסי העבודה של השירותים האלה פועלים בקונטיינרים של Kubernetes באשכולות המחוברים שלכם ב-Distributed Cloud.

שירותים נתמכים Google Cloud

‫Google Distributed Cloud במודל מחובר תומך בפריסה של השירותים הבאים שלGoogle Cloud :

סוג השירות	כלול בעלויות של GDC במודל מחובר	חיוב נפרד
Compute	Google Distributed Cloud רק תוכנה VM Runtime ב-Google Distributed Cloud	מערכות הפעלה של אורחים (צריך להשיג רישיונות משלכם)
אחסון	ממשק אחסון לקונטיינרים (CSI) אחסון היברידי	אחסון מוגדר תוכנה (SDS), כמו Symcloud Storage (צריך להשיג רישיונות משלכם)
Networking	‫Edge Network API תמיכה ב-VLAN תוספים של GKE Custom Network Interface‏ (CNI) מאזן עומסים L4 שצורף ל-GKE	לא רלוונטי
AI/ML	פריסת מודלים של AutoML בקונטיינרים	לא רלוונטי
מסד נתונים	ללא	‫AlloyDB Omni (גרסת Preview) פתרונות מסדי נתונים של צד שלישי, כמו MongoDB (צריך לקבל רישיונות משלכם)
ניראות (observability)	‫Cloud Logging ‫Cloud Monitoring ‫Cloud Logging API ‫GDCc logs and metrics	‫Prometheus לניטור נתונים במצב לא מקוון מדדים ויומנים מותאמים אישית ברמת האפליקציה
ניהול הגדרות	‫סנכרון תצורות שימוש בחבילות Fleet ב-Distributed Cloud connected חבילות Fleet (תצוגה מקדימה)	לא רלוונטי
ניהול	לוח הבקרה של Google Kubernetes Engine ב Google Cloud מסוף שער החיבור kubectlהכלי המקומי שדרוגים של תוכנות שמחוברות ל-Distributed Cloud	לא רלוונטי
אבטחה	שילוב עם Cloud Key Management Service כונני Self-Encrypting Disk (SED) Fleet Workload Identity רישום ביומני ביקורת	לא רלוונטי

דרישות מוקדמות

לפני שפורסים Google Cloud שירותים ב-Distributed Cloud Connected, צריך לעמוד בדרישות המוקדמות שמפורטות בקטע הזה.

קבלת פרטי כניסה לאשכול

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

 gcloud container hub memberships get-credentials CLUSTER_ID \
       --project="PROJECT_ID"

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

• ‫CLUSTER_ID: השם של אשכול היעד.
• ‫PROJECT_ID: המזהה של Google Cloud פרויקט היעד.

יצירה או בחירה של אשכול

אם עדיין לא עשיתם זאת, יוצרים אשכול שמחובר ל-Distributed Cloud, כמו שמתואר במאמר יצירת אשכול. כשיוצרים את האשכול, צריך לציין לפחות 8 כתובות IP וירטואליות (VIP). כתובות ה-IP הווירטואליות האלה ישמשו את קונטיינרי Kubernetes שמריצים את עומסי העבודה של שירות Google Cloud .

אם אתם משתמשים באשכול קיים, אתם יכולים להשתמש בפקודה הבאה כדי לוודא שיש מספיק כתובות VIP באשכול:

 kubectl get cluster --all-namespaces -o jsonpath="{.items[0].spec.loadBalancer.addressPools}"

הפקודה מחזירה פלט שדומה לזה:

[
  {
    "addresses": [
      "10.200.11.188-10.200.11.196"
    ],
    "name": "loadBalancerAddressPool-1"
  }
]

אם לא הוקצו מספיק כתובות VIP באשכול, תופיע השגיאה הבאה, כאשר n הוא מספר כתובות ה-VIP הנדרש, ו-m הוא מספר כתובות ה-VIP שזוהו באשכול:

Cluster has less than n external IPs, got m.

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

הגדרת תת-הדומיין של שירות Google Cloud

לפני שמפעילים את השירות הראשון באזור מחובר של Distributed Cloud, אפשר להתאים אישית את שם הדומיין המשני שבו כל השירותים שמופעלים באזור הזה יאזינו לחיבורים. Google Cloud Google Cloud אי אפשר לשנות את הסאבדומיין הזה אחרי שפורסים לפחות שירות אחד באזור הזה של Distributed Cloud.

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

kubectl -n dns-system get celldns cell-dns -o yaml

הפקודה מחזירה פלט שדומה לזה:

apiVersion: system.private.gdc.goog/v1alpha1
kind: CellDNS
metadata:
  name: cell-dns
  namespace: dns-system
spec:
  delegatedSubdomain: private.goog

משתמשים בפקודה הבאה כדי לשנות את ההגדרה של תת-הדומיין:

kubectl -n dns-system edit celldns cell-dns

פריסת שירות ב-Distributed Cloud במודל מחובר Google Cloud

כדי לפרוס שירות Google Cloud ב-Distributed Cloud במערכת מחוברת, פועלים לפי שלבי הפריסה שמתוארים במסמכי השירות.

הגדרת Google Cloud השירות שנפרס

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

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

כשפורסים שירות Google Cloud באשכול שמחובר ל-Distributed Cloud, נפרס באשכול שרת DNS ייעודי לשירות הזה. מומלץ להעביר שאילתות DNS עבור תחום המשנה של השירות לשרת ה-DNS החדש שנוצר באשכול.

1. כדי לקבל את שם הדומיין המשני של האשכול, משתמשים בפקודות הבאות:

   CLUSTER_SUBDOMAIN=$(kubectl get configmap -n \
       $(kubectl get clusters -A -o jsonpath="{.items[0].metadata.namespace}") \
       dns-prefix -o jsonpath="{.data.dnsPrefix}")
   DELEGATED_SUBDOMAIN=$(kubectl get celldns -n dns-system cell-dns -o \
     jsonpath="{.spec.delegatedSubdomain}")
   CLUSTER_FQDN="${CLUSTER_SUBDOMAIN?}.${DELEGATED_SUBDOMAIN?}"
   echo "${CLUSTER_FQDN?}"
   

   הפקודה האחרונה מחזירה פלט שדומה לזה:

   my-zone.google.private.goog
   

2. כדי לקבל את כתובת ה-VIP של שרת ה-DNS באשכול, משתמשים בפקודה הבאה:

   DNS_EXT_IP=$(k -n dns-system get service gpc-coredns-external-tcp -o "jsonpath={.status.loadBalancer.ingress[0].ip}")
   

3. מגדירים את שרת ה-DNS הפנימי להעברת שאילתות DNS עבור שירות Google Cloud שנפרס אל כתובת ה-VIP שקיבלתם בשלב הקודם. לדוגמה:

   • עבור dnsmasq, צריך להוסיף את הפרטים הבאים אל /etc/dnsmasq.conf:

     server=/${CLUSTER_FQDN?}/${DNS_EXT_IP?}
     

   • ב-CoreDNS, מוסיפים את הטקסט הבא ל-Corefile:

     ${CLUSTER_FQDN?}:53 {
       errors
       cache 30
       forward . ${DNS_EXT_IP?} {
         max_concurrent 1000
       }
     }
     

בדיקה של פענוח DNS

משתמשים בפקודה dig הבאה כדי לבדוק אם הדומיין נפתר בצורה תקינה. חשוב לשים לב במיוחד לANSWER SECTION:

 dig "ais-core.${CLUSTER_FQDN?}"

הפקודה מחזירה פלט שדומה לזה:

...
;; ANSWER SECTION:
ais-core.my-zone.google.private.goog. 300 IN A 10.200.0.0
...

אחזור האישור בחתימה עצמית עבור שירות Google Cloud שנפרס

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

כדי לקבל את האישור הזה בפורמט PEM, משתמשים בפקודה הבאה:

 kubectl get secret -n cert-manager-cluster-resources web-ca-cert -o jsonpath="{.data.ca\.crt}" | base64 -d

‫Distributed Cloud connected יוצר מספר חבילות של אישורי אמון בכל האשכול. חבילות האישורים האלה מאוחסנות כ-ConfigMaps בכל מרחב שמות באשכול. הם:

• ‫trust-store-internal-only. מכיל רשויות אישורים (CA) לשירותים פנימיים של Distributed Cloud במודל מחובר.
• ‫trust-store-root-ext. מכיל את כל רשויות האישורים ב-trust-store-root-ext, בנוסף לרשות האישורים שחתמה על האישור בחתימה עצמית של שירות היעדGoogle Cloud . אם אתם צריכים ש-Pod מסוים יוכל לגשת לשירות היעד Google Cloud , אתם צריכים לטעון את חבילת האישורים הזו ב-Pod.
• ‫trust-store-user-ext. מכיל את כל רשויות האישורים ב-trust-store-root-ext, וגם רשויות אישורים שהוספתם באופן ידני. אם אתם צריכים ש-Pod מסוים יוכל לגשת גם לשירות היעד Google Cloud וגם למשאבים פנימיים שמשתמשים באישורים שנחתמו על ידי רשויות האישורים שהוספתם באופן ידני, אתם צריכים להוסיף את חבילת האישורים הזו ל-Pod.

כדי להציג את ConfigMap של היעד, משתמשים בפקודה הבאה:

 kubectl -n default get configmap trust-store-user-root-ext -o yaml

בדוגמה הבאה של פלט אפשר לראות משאב ConfigMap אופייני של trust-store-user-root-ext:

apiVersion: v1
binaryData:
  ca.jks: WW91IGFyZSBhd2Vzb21lIQo=
data:
  ca.crt: |-
    -----BEGIN CERTIFICATE-----
    WW91IGFyZSBncmVhdCEK
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    WW91IGFyZSBmYW50YXN0aWMhCg==
    -----END CERTIFICATE-----
kind: ConfigMap
metadata:
  labels:
    trust.cert-manager.io/bundle: trust-store-user-root-ext
  name: trust-store-user-root-ext
  namespace: default

הגדרה של שירות Google Cloud שנפרס כך שיסמוך על האישורים שלכם

אפשר ליצור סוד TLS באשכול המחובר ל-Distributed Cloud ולהוסיף לו את ההערה security.private.gdc.goog/bundles=trust-store-user-root-ext במרחב השמות cert-manager-cluster-resources. כך השירות שפרסתם Google Cloud יכול לסמוך על שירותי צד שלישי פנימיים כדי להקל על חילופי הנתונים ביניהם.

כשמחילים את הסוד הזה על האשכול, השירות שנפרס Google Cloud בוטח באישור CA שמאוחסן בקובץ ca.crt שאליו יש הפניה בסוד. לדוגמה:

apiVersion: v1
data:
  ca.crt: base64EncodedCaCert
  tls.crt: base64EncodedCert
  tls.key: base64EncodedKey
kind: Secret
metadata:
  annotations:
    security.private.gdc.goog/bundles: trust-store-user-root-ext
  name: my-corporate-cert
  namespace: cert-manager-cluster-resources
type: kubernetes.io/tls

הגדרת ספק אימות

אתם יכולים להגדיר ספק אימות כדי להקל על הכניסה באמצעות ממשק המשתמש של שירותGoogle Cloud שנפרס. בדוגמה הבאה מוצגת הגדרה של ספק OpenID Connect:

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
  name: default
  namespace: kube-public
spec:
  authentication:
  - name: "google-oidc"
    oidc:
      clientID: "my-supersecret-client-id.apps.googleusercontent.com"
      clientSecret: "my-supersecret-secret"
      issuerURI: "https://accounts.google.com"
      scopes: "email"
      userClaim: "email"
  name: "default"

מידע נוסף זמין במאמר בנושא הגדרת GKE Identity Service לאשכולות נפרדים.

שימוש בשירות Google Cloud שהופעל

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

הסרה של שירות Google Cloud שנפרס

כדי להסיר שירות שפריסתו בוצעה Google Cloud מהאשכול המחובר של Distributed Cloud, פועלים לפי השלבים שמפורטים במסמכים של השירות הזה. אם השלמתם את אחד מהשלבים האופציונליים אחרי הפריסה שמתוארים בדף הזה, צריך גם:

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