שימוש ב-PgBouncer connection pooler

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

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

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

יצירת שירות PgBouncer

אופרטור Kubernetes של AlloyDB Omni מאפשר ליצור שירות ייעודי של 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: התווית של הצומת עבור המפתח שמשמש כאינדיקטור מיקום ומאפשר חלוקה שווה של ה-Pod על פני האשכול – לדוגמה, nodetype.
      • ‫OPERATOR_VALUE: מייצג את הקשר של מפתח לקבוצת ערכים. מגדירים את הפרמטר לאחת מהאפשרויות הבאות:
        • ‫In: המערך של הערכים לא יכול להיות ריק.
        • ‫NotIn: המערך של הערכים לא יכול להיות ריק.
        • ‫Exists: מערך הערכים חייב להיות ריק.
        • ‫DoesNotExist: מערך הערכים חייב להיות ריק.
        • ‫Gt: למערך הערכים צריך להיות רכיב יחיד, שמפורש כמספר שלם.
        • ‫Lt: למערך הערכים צריך להיות רכיב יחיד, שמפורש כמספר שלם.

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

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

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

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

כדי להבטיח את האבטחה של Deployment (פריסה) של 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 יחיל את השינוי באופן אוטומטי.

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