שימוש ב-PgBouncer כמנהל חיבורים

בוחרים גרסה של מאמר העזרה:

בדף הזה מוסבר איך להפעיל את PgBouncer, כלי לניהול מאגר חיבורים, ב-AlloyDB Omni באמצעות AlloyDB Omni Kubernetes operator.

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

יצירת שירות PgBouncer

האופרטור AlloyDB Omni Kubernetes מאפשר ליצור שירות PgBouncer ייעודי למסד הנתונים. אחרי כן תוכלו לגשת למסד הנתונים דרך שירות PgBouncer כדי ליהנות מאיגום חיבורים.

יש הגדרת משאב מותאם אישית (CRD) ייעודית להגדרת שירות PgBouncer לפי הצורך.

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

  1. יוצרים PgBouncer משאב בהתאמה אישית באשכול Kubernetes באופן הבא:

    apiVersion: alloydbomni.dbadmin.goog/v1
kind: PgBouncer
metadata:
  name: PGBOUNCER_NAME
spec:
  dbclusterRef: DB_CLUSTER_NAME
  allowSuperUserAccess: true
  podSpec:
    resources:
      memory: 1Gi
      cpu: 1
    image: "gcr.io/alloydb-omni/operator/g-pgbouncer:1.4.0"
  parameters:
    pool_mode: POOL_MODE
    ignore_startup_parameters: IGNORE_STARTUP_PARAMETERS
    default_pool_size: "DEFAULT_POOL_SIZE"
    max_client_conn: "MAXIMUM_CLIENT_CONNECTIONS"
    max_db_connections: "MAXIMUM_DATABASE_CONNECTIONS"
  serviceOptions:
    type: "ClusterIP"

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

    • ‫PGBOUNCER_NAME: השם של המשאב המותאם אישית של PgBouncer.
    • DB_CLUSTER_NAME: השם של אשכול מסד הנתונים שלכם ב-AlloyDB Omni. זהו אותו שם של אשכול מסדי הנתונים שהצהרתם עליו כשיצרתם אותו.
    • ‫POOL_MODE: מציין מתי לקוחות אחרים יכולים לעשות שימוש חוזר בחיבור למסד נתונים. מגדירים את הפרמטר לאחת מהאפשרויות הבאות:
      • ‫session: החיבור למסד הנתונים משוחרר בחזרה למאגר אחרי שהלקוח מתנתק. האפשרות הזו מסומנת כברירת מחדל.
      • ‫transaction: החיבור למסד הנתונים משוחרר בחזרה למאגר אחרי שהעסקה מסתיימת.
      • ‫statement: החיבור למסד הנתונים משוחרר בחזרה למאגר אחרי שהשאילתה מסתיימת. אסור להשתמש במצב הזה בעסקאות שכוללות כמה הצהרות.
    • ‫IGNORE_STARTUP_PARAMETERS: מציין פרמטרים ש-PgBouncer לא מאפשר, כדי שהמערכת תתעלם מהם במהלך ההפעלה. לדוגמה: extra_float_digits. מידע נוסף זמין במאמר בנושא הגדרת PgBouncer.
    • ‫DEFAULT_POOL_SIZE: מספר החיבורים למסד הנתונים שיוגדרו לכל צמד של משתמש ומסד נתונים. לדוגמה, 8.
    • ‫MAXIMUM_CLIENT_CONNECTIONS: המספר המקסימלי של חיבורי לקוח, לדוגמה 800.
    • ‫MAXIMUM_DATABASE_CONNECTIONS: המספר המקסימלי של חיבורים למסד הנתונים, לדוגמה 160.

  2. החלת המניפסט:

    kubectl apply -f PATH_TO_MANIFEST -n NAMESPACE

    מחליפים את PATH_TO_MANIFEST בנתיב לקובץ המניפסט, לדוגמה, /fleet/config/pgbouncer.yaml.

  3. כדי לוודא שאובייקט PgBouncer שיצרתם מוכן, מריצים את השאילתה הבאה:

    kubectl get pgbouncers.alloydbomni.dbadmin.goog PGBOUNCER_NAME  -n NAMESPACE -w

    מחליפים את NAMESPACE בשם של מרחב השמות של Kubernetes לאובייקט PgBouncer.

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

    NAMESPACE   NAME          ENDPOINT        STATE
dbv2        mypgbouncer
dbv2        mypgbouncer
dbv2        mypgbouncer
dbv2        mypgbouncer                   WaitingForDeploymentReady
dbv2        mypgbouncer                   Acquiring IP
dbv2        mypgbouncer   10.138.15.231   Ready

חיבור לנקודת הקצה של מאגר החיבורים

אפשר להתחבר למאגר החיבורים של PgBouncer מתוך אשכול Kubernetes או מחוצה לו.

התחברות מתוך אשכול Kubernetes

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

  1. כדי ליצור Pod:

    apiVersion: v1
kind: Pod
metadata:
  name: postgres
spec:
  containers:
  - image: "docker.io/library/postgres:latest"
    command:
     - "sleep"
     - "604800"
    name: db-client

  2. החלת המניפסט:

    kubectl apply -f PATH_TO_MANIFEST -n NAMESPACE

  3. מתחברים לאפליקציה בקונטיינר:

    kubectl exec -it postgres -n NAMESPACE -- bash

  4. מאמתים את חיבור ה-SSL לנקודת הקצה של PgBouncer באמצעות לקוח psql:

    export PGSSLMODE="require"; psql -h HOST -d postgres -U postgres -p PORT

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

    • ‫HOST: נקודת הקצה של מאגר החיבורים שמתקבלת באמצעות הפקודה kubectl get pgbouncers.alloydbomni.dbadmin.goog -n NAMESPACE. אם PgBouncer לא נחשף כשירות, צריך להשתמש בכתובת ה-IP שלו.
    • ‫PORT: היציאה ש-PgBouncer מאזין לה.

    בחלון הטרמינל מוצג טקסט של התחברות psql שמסתיים בהנחיה postgres=#.

חיבור מחוץ לאשכול Kubernetes

כדי לגשת למאגר החיבורים של PgBouncer מחוץ לאשכול Kubernetes, צריך להגדיר את השדה type במאפיין serviceOptions לערך LoadBalancer, וכך ליצור שירות loadbalancer.

  1. יוצרים PgBouncer משאב בהתאמה אישית באשכול Kubernetes באופן הבא:

    apiVersion: alloydbomni.dbadmin.goog/v1
kind: PgBouncer
metadata:
name: PGBOUNCER_NAME
spec:
dbclusterRef: DB_CLUSTER_NAME
allowSuperUserAccess: true
replicaCount: 2
parameters:
  pool_mode: POOL_MODE
  ignore_startup_parameters: IGNORE_STARTUP_PARAMETERS
  default_pool_size: "DEFAULT_POOL_SIZE"
  max_client_conn: "MAXIMUM_CLIENT_CONNECTIONS"
  max_db_connections: "MAXIMUM_DATABASE_CONNECTIONS"
podSpec:
  resources:
    memory: 1Gi
    cpu: 1
  image: "gcr.io/alloydb-omni/operator/g-pgbouncer:1.4.0"
serviceOptions:
  type: "LoadBalancer"

  2. החלת המניפסט:

    kubectl apply -f PATH_TO_MANIFEST

  3. כדי לוודא שאובייקט PgBouncer שיצרתם מוכן, מריצים את השאילתה הבאה:

    kubectl get pgbouncers.alloydbomni.dbadmin.goog PGBOUNCER_NAME  -n NAMESPACE -w

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

    NAME          ENDPOINT       STATE
mypgbouncer   10.138.15.207   Ready

קביעת ההגדרות של PgBouncer

משתמשים בפרמטרים הבאים כדי להגדיר את ההגדרות של PGBouncer:

פרמטר תיאור ערך ברירת המחדל
pool_mode מגדירה מתי לקוחות אחרים יכולים לעשות שימוש חוזר בחיבור למסד נתונים.
הערכים המותרים הם:
  • ‫session: החיבור למסד הנתונים משוחרר בחזרה למאגר אחרי שהלקוח מתנתק.
  • ‫transaction: החיבור למסד הנתונים משוחרר בחזרה למאגר אחרי שהעסקה מסתיימת.
  • ‫statement: החיבור למסד הנתונים משוחרר בחזרה למאגר אחרי שהשאילתה מסתיימת.
    אסור להשתמש במצב הזה בעסקאות שכוללות כמה הצהרות.
 session
ignore_startup_parameters מציינים פרמטרים שאסור להשתמש בהם ב-PgBouncer כדי שהמערכת תתעלם מהם בזמן ההפעלה.
default_pool_size מספר החיבורים למסד הנתונים שיוגדרו לכל צמד של משתמש ומסד נתונים. 20
max_client_conn מספר החיבורים המקסימלי של הלקוח. 100
max_db_connections המספר המקסימלי של חיבורים למסד הנתונים. 0

התאמה אישית של הפריסה של PgBouncer

‫AlloyDB Omni משתמש במשאבים בהתאמה אישית כדי לנהל את הרכיבים שלו. כדי להתאים אישית את הפריסה של PgBouncer ב-AlloyDB Omni ב-Kubernetes, משנים את המשאב המותאם אישית PgBouncer באופן הבא:

  1. מפרטים את המשאבים המותאמים אישית של PgBouncer:

    kubectl get pgbouncers -n NAMESPACE

    מחליפים את NAMESPACE במרחב השמות שבו פרסתם את AlloyDB Omni.

  2. כדי לשנות את המשאב, פותחים את קובץ ההצהרה של המשאב PgBouncer בעורך ברירת המחדל:

    kubectl edit pgbouncers PGBOUNCER_NAME -n NAMESPACE

  3. בקובץ ההצהרה, מחפשים את הקטע podSpec שכולל את ההגדרה ומשנים את השדות הבאים לפי הצורך:

    • ‫resources: cpu ו-memory שהוגדרו לקונטיינר:

      apiVersion: alloydbomni.dbadmin.goog/v1
kind: PgBouncer
metadata:
  name: PGBOUNCER_NAME
spec:
  dbclusterRef: DB_CLUSTER_NAME
  replicaCount: 2
  parameters:
    pool_mode: POOL_MODE
    ignore_startup_parameters: IGNORE_STARTUP_PARAMETERS
    default_pool_size: "DEFAULT_POOL_SIZE"
    max_client_conn: "MAXIMUM_CLIENT_CONNECTIONS"
    max_db_connections: "MAXIMUM_DATABASE_CONNECTIONS"
  podSpec:
    resources:
      memory: 1Gi
      cpu: 1
...

    • ‫image: הנתיב לתג התמונה של PgBouncer:

      ...
  podSpec:
    resources:
      memory: 1Gi
      cpu: 1
    image: IMAGE
...

    • ‫schedulingconfig: כוללים את הקטע nodeaffinity כדי לקבוע איפה יתוזמנו ה-Pods של PgBouncer:

      ...
  podSpec:
    resources:
      memory: 1Gi
      cpu: 1
    image: IMAGE
    schedulingconfig:
      nodeaffinity:
        NODE_AFFINITY_TYPE:
          nodeSelectorTerms:
          - matchExpressions:
            - key: LABEL_KEY
              operator: OPERATOR_VALUE
              values:
              - pgbouncer
...

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

      • ‫NODE_AFFINITY_TYPE: מגדירים את הפרמטר לאחת מהאפשרויות הבאות:
        • ‫requiredDuringSchedulingIgnoredDuringExecution: Kubernetes מתזמן את ה-Pod בדיוק על סמך הכללים המוגדרים.
        • ‫preferredDuringSchedulingIgnoredDuringExecution: מתזמן Kubernetes מנסה למצוא צומת שעומד בכלל שהוגדר לתזמון. עם זאת, אם אין צומת כזה, Kubernetes מתזמן לצומת אחר באשכול.
      • ‫LABEL_KEY: התווית של הצומת למפתח שמשמש כאינדיקטור מיקום ומאפשר חלוקה שווה של ה-Pods בכל האשכול – לדוגמה, nodetype.
      • ‫OPERATOR_VALUE: מייצג את הקשר של מפתח לקבוצת ערכים. מגדירים את הפרמטר לאחת מהאפשרויות הבאות:
        • ‫In: המערך של הערכים לא יכול להיות ריק.
        • ‫NotIn: המערך של הערכים לא יכול להיות ריק.
        • ‫Exists: מערך הערכים חייב להיות ריק.
        • ‫DoesNotExist: מערך הערכים חייב להיות ריק.
        • ‫Gt: מערך הערכים חייב להכיל רכיב יחיד, שמתפרש כמספר שלם.
        • ‫Lt: מערך הערכים חייב להכיל רכיב יחיד, שמתפרש כמספר שלם.

  4. אחרי שמבצעים את השינויים, שומרים את קובץ ההצהרה. האופרטור AlloyDB Omni Kubernetes מחיל את השינויים באופן אוטומטי על הפריסה של PgBouncer.

תזמון עם זיקה לצומת

אתם יכולים להשתמש בnode affinity כדי לשלוט במיקום של תרמילי PgBouncer, וכך לקבל מיקום מדויק יותר מאשר תזמון רגיל. Node affinity מבטיח שתרמילי PgBouncer ימוקמו בצמתים שעומדים בקריטריונים ספציפיים, כמו תוויות מסוימות.

כדי לציין את הקרבה של הצמתים ל-pods של PgBouncer, משנים את המשאב המותאם אישית PgBouncer כדי להוסיף את הקטע schedulingconfig לקטע podSpec:

apiVersion: alloydbomni.dbadmin.goog/v1
kind: PgBouncer
metadata:
  name: PGBOUNCER_NAME
spec:
  # ... other PgBouncer configuration ...
  podSpec:
    # ... other podSpec settings ...
    schedulingconfig:
      nodeaffinity:
        NODE_AFFINITY_TYPE:
          nodeSelectorTerms:
          - matchExpressions:
            - key: LABEL_KEY
              operator: OPERATOR_VALUE
              values:
              - pgbouncer

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

  • ‫NODE_AFFINITY_TYPE: מגדירים את הפרמטר לאחת מהאפשרויות הבאות:
    • ‫requiredDuringSchedulingIgnoredDuringExecution: Kubernetes מתזמן את ה-Pod בדיוק על סמך הכללים המוגדרים.
    • ‫preferredDuringSchedulingIgnoredDuringExecution: מתזמן Kubernetes מנסה למצוא צומת שעומד בכלל המוגדר לתזמון. עם זאת, אם אין צומת כזה, Kubernetes מתזמן לצומת אחר באשכול.
  • ‫LABEL_KEY: מפתח התווית של הצומת. לדוגמה, disktype=ssd.
  • ‫OPERATOR_VALUE: מייצג את הקשר של מפתח לקבוצת ערכים. מגדירים את הפרמטר לאחת מהאפשרויות הבאות:
    • ‫In: ערך התווית של הצומת חייב להיות זהה לערך במערך values.
    • ‫NotIn: ערך התווית של הצומת לא יכול להיות זהה לאף ערך במערך values.
    • ‫Exists: התווית LABEL_KEY חייבת להיות קיימת בצומת. המערך values צריך להיות ריק.
    • ‫DoesNotExist: התווית LABEL_KEY לא יכולה להיות קיימת בצומת. המערך values צריך להיות ריק.
    • ‫Gt: הערך של התווית של הצומת חייב להיות גדול מהערך הבודד במערך values, שמתפרש כמספר שלם.
    • ‫Lt: הערך של תווית הצומת צריך להיות קטן מהערך היחיד במערך values, שמתפרש כמספר שלם.

בדוגמה הבאה אפשר לראות איך מתזמנים פודים של PgBouncer בצמתים עם התווית nodetype=pgbouncer:

apiVersion: alloydbomni.dbadmin.goog/v1
kind: PgBouncer
metadata:
  name: mypgbouncer
spec:
  # ... other PgBouncer configuration ...
  podSpec:
    # ... other podSpec settings ...
    schedulingconfig:
      nodeaffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: nodetype
              operator: In
              values:
              - pgbouncer

בדוגמה הזו, ההגדרה requiredDuringSchedulingIgnoredDuringExecution מבטיחה שתרמילי PgBouncer יתוזמנו רק בצמתים עם התווית nodetype=pgbouncer.

מחיקת משאב PgBouncer

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

kubectl delete pgbouncers.alloydbomni.dbadmin.goog PGBOUNCER_NAME -n NAMESPACE

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

pgbouncer.alloydbomni.dbadmin.goog "mypgbouncer" deleted

צפייה ביומנים של PgBouncer

כדי לראות ולנתח יומנים של כל מופע משוכפל של PgBouncer בפריסת AlloyDB Omni ב-Kubernetes, פועלים לפי השלבים הבאים:

  1. כדי לקבל רשימה של כל ה-Pods של PgBouncer במרחב השמות:

    kubectl get pods -n NAMESPACE

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

    NAME                                          READY   STATUS    RESTARTS   AGE
al-092d-dbcluster-sample-0                    3/3     Running   0          3d1h
mypgbouncer-pgb-deployment-659869f95c-4kbgv   1/1     Running   0          27m

  2. כדי לראות את היומנים של Pod מסוים:

    kubectl logs -f POD_NAME -n NAMESPACE

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

    2025-01-21 06:57:39.549 UTC [7] LOG kernel file descriptor limit: 1048576 (hard: 1048576); max_client_conn: 800, max expected fd use: 812
2025-01-21 06:57:39.550 UTC [7] LOG listening on 0.0.0.0:6432
2025-01-21 06:57:39.550 UTC [7] LOG listening on [::]:6432
2025-01-21 06:57:39.550 UTC [7] LOG listening on unix:/tmp/.s.PGSQL.6432
2025-01-21 06:57:39.550 UTC [7] LOG process up: PgBouncer 1.23.0, libevent 2.1.12-stable (epoll), adns: evdns2, tls: OpenSSL 3.0.13 30 Jan 2024
2025-01-21 06:58:17.012 UTC [7] LOG C-0x55f2b1b322a0: (nodb)/(nouser)@10.138.15.215:48682 registered new auto-database: alloydbadmin
2025-01-21 06:58:17.012 UTC [7] LOG S-0x55f2b1b4ecb0: alloydbadmin/alloydbpgbouncer@10.138.0.48:5432 new connection to server (from 10.12.1.113:53156)
2025-01-21 06:58:17.042 UTC [7] LOG S-0x55f2b1b4ecb0: alloydbadmin/alloydbpgbouncer@10.138.0.48:5432 SSL established: TLSv1.3/TLS_AES_256_GCM_SHA384/ECDH=prime256v1
2025-01-21 06:58:17.052 UTC [7] LOG C-0x55f2b1b322a0: pgbouncer/statsuser@10.138.15.215:48682 login attempt: db=pgbouncer user=statsuser tls=TLSv1.3/TLS_AES_256_GCM_SHA384 replication=no
2025-01-21 06:58:19.526 UTC [7] LOG C-0x55f2b1b322a0: pgbouncer/statsuser@10.138.15.215:48682 closing because: client close request (age=2s)
2025-01-21 06:58:20.344 UTC [7] LOG C-0x55f2b1b322a0: pgbouncer/statsuser@10.138.15.215:46796 login attempt: db=pgbouncer user=statsuser tls=TLSv1.3/TLS_AES_256_GCM_SHA384 replication=no

מעקב אחרי הביצועים והפעילות של PgBouncer

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

  1. מתחברים ל-AlloyDB Omni בתור משתמש-על או משתמש עם הרשאת CREATE ROLE באמצעות לקוח psql:

    export PGPASSWORD="ChangeMe123"; export PGSSLMODE="require"; psql -h HOST -d postgres -U postgres -p PORT

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

    psql (16.6 (Ubuntu 16.6-0ubuntu0.24.04.1), server 15.7)
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off)
Type "help" for help.

  2. יוצרים את statsuser ב-AlloyDB Omni:

    postgres=# CREATE USER "statsuser" WITH PASSWORD 'tester';

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

    CREATE ROLE

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

    export PGPASSWORD="ChangeMe123"; export PGSSLMODE="require"; psql -h HOST -d pgbouncer -U statsuser -p PORT

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

    psql (16.6 (Ubuntu 16.6-0ubuntu0.24.04.1), server 1.23.0/bouncer)
WARNING: psql major version 16, server major version 1.23.
Some psql features might not work.
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off)
Type "help" for help.

  4. מריצים את הפקודה SHOW STATS כדי לראות את הביצועים של PgBouncer ולזהות בעיות פוטנציאליות:

    pgbouncer=# SHOW STATS;

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

         database   | total_server_assignment_count | total_xact_count | total_query_count | total_received | total_sent | total_xact_time | total_query_time | total_wait_time | avg_server_assignment_count | avg_xact_count | avg_query_count | avg_recv | avg_sent | avg_xact_time | avg_query_time | avg_wait_time
   -------------+-------------------------------+------------------+-------------------+----------------+------------+-----------------+------------------+-----------------+-----------------------------+----------------+-----------------+----------+----------+---------------+----------------+---------------
   alloydbadmin |                             1 |                0 |                 0 |              0 |        330 |               0 |                0 |           41730 |                           0 |              0 |               0 |        0 |        2 |             0 |              0 |         41730
   pgbouncer    |                             0 |                5 |                 5 |              0 |          0 |               0 |                0 |               0 |                           0 |              0 |               0 |        0 |        0 |             0 |              0 |             0
   (2 rows)

הגדרת גישה לרשת למופע AlloyDB Omni

כדי להבטיח את האבטחה של פריסת AlloyDB Omni ב-Kubernetes, אתם יכולים להגביל את הגישה לרשת למאגר החיבורים של PgBouncer על ידי הגדרת טווחים ספציפיים של כתובות IP באמצעות סימון CIDR (Classless Inter-Domain Routing).

סימון CIDR משלב כתובת IP עם אורך קידומת. לדוגמה, בלוק ה-CIDR‏ 192.168.1.0/24 מציין 192.168.1.0 לכתובת ו-24 לאורך הקידומת. אורך הקידומת מציין את מספר הביטים בכתובת ה-IP שמשמשים לחלק של הרשת, ומגדיר את מסכה של רשת משנה.

בקובץ ההצהרה של הפריסה, מאתרים את הקטע serviceOptions ומוסיפים או משנים את ההגדרה loadBalancerSourceRanges:

  serviceOptions:
    type: "LoadBalancer"
    loadBalancerSourceRanges:
    - "CIDR_BLOCK"

מחליפים את CIDR_BLOCK במחרוזת CIDR שמציינת את טווחי כתובות ה-IP שמורשים לחיבורים נכנסים לשירות LoadBalancer. ההגדרה loadBalancerSourceRanges מסננת את התנועה הנכנסת ברשת וקובעת אילו לקוחות יכולים לגשת למופע של מסד הנתונים.

כדי לוודא שההגדרה של loadBalancerSourceRanges הוחלה בצורה נכונה, משתמשים בפקודה הבאה כדי לבדוק את כתובת ה-IP החיצונית שהוקצתה לשירות LoadBalancer:

kubectl get svc -n NAMESPACE -w

מחליפים את NAMESPACE במרחב השמות שבו נמצאת הפריסה של AlloyDB Omni.

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

NAME                     TYPE           CLUSTER_IP      EXTERNAL_IP   PORT(S)         AGE
al-mypgbouncer-pgb-svc   LoadBalancer   34.118.230.149  10.138.0.26   6432:31367/TCP  3m39s

אחרי ש-LoadBalancer מוכן, העמודה EXTERNAL_IP מתמלאת בכתובת ה-IP החיצונית שהוקצתה לשירות LoadBalancer. החיבורים לכתובת ה-IP החיצונית הזו מסוננים על סמך ההגדרה loadBalancerSourceRanges.

אחרי אימות כתובת ה-IP החיצונית, בודקים את החיבורים מאפליקציות בטווחים המותרים של CIDR כדי לוודא שהן יכולות להתחבר.

השבתת מאגר החיבורים של PgBouncer

אם אתם צריכים להשבית את מאגר החיבורים של PgBouncer או לבטל את השינויים שבוצעו בו, אתם יכולים לפעול לפי השלבים הבאים:

  1. בודקים את הסטטוס של מאגר החיבורים:

    kubectl get deployment fleet-controller-manager --namespace alloydb-omni-system  -o json | jq '.spec.template.spec.containers[0].args'

    הפקודה הזו מציגה את מניפסט הפריסה של הבקר הראשי לניהול צי AlloyDB Omni. מחפשים את האפשרות --enable-pgbouncer בקטע args במערך containers:

    ...
 spec:
  containers:
  - name: fleet-controller-manager
    image:...
    args:
    --health-probe-bind-address=:8081",
    --metrics-bind-address=127.0.0.1:8080",
    --leader-elect",
    --image-registry=gcr.io",
    --data-plane-image-repository=alloydb-omni-staging",
    --control-plane-agents-image-repository=aedi-gbox",
    --control-plane-agents-tag=jan19v3",
    --additional-db-versions-for-test-only=latest",
    --enable-multiple-backup-solutions=true",
    --enable-pgbouncer=true

  2. עורכים את ההגדרה של פריסת הבקר כדי להשבית את מאגר החיבורים:

    kubectl edit deployment fleet-controller-manager --namespace alloydb-omni-system

  3. במניפסט הפריסה, משנים את הערך של האפשרות --enable-pgbouncer מ-true ל-false:

    ...
--enable-pgbouncer=false

  4. שומרים את הקובץ ויוצאים מכלי העריכה. השינוי יוחל אוטומטית על ידי kubectl.

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