סקירה כללית על חיבורים למערכות לניהול קונטיינרים

בוחרים גרסת תיעוד:

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

  • רשתות: איך מגדירים אשכולות של מסדי נתונים ב-AlloyDB Omni לגישה פנימית באמצעות שירות ClusterIP של Kubernetes או לגישה חיצונית באמצעות LoadBalancer, כולל איך להגביל את תעבורת הנתונים החיצונית באמצעות טווחי Classless Inter-Domain Routing ‏ (CIDR) של המקור.
  • איגום חיבורים: אפשר להשתמש בPgBouncer Custom Resource כדי להטמיע איגום חיבורים לניהול יעיל של חיבורים ולהפחתת העומס על מופעי מסד הנתונים.
  • אימות והרשאה: גישה מאובטחת באמצעות שיטות נתמכות כמו אימות מבוסס-סיסמה ושילוב של Active Directory ו-Kerberos, לצד אמצעי בקרה מדויקים שמיושמים באמצעות מדיניות רשת ב-Kubernetes ותפקידים ב-PostgreSQL.

Networking

אתם יכולים להגדיר אשכולות של מסדי נתונים ב-AlloyDB Omni, שמנוהלים על ידי המשאב בהתאמה אישית DBCluster, לגישה פנימית או חיצונית.

למידע נוסף על אפשרויות הרשת של DBCluster, עיינו בחומר העזר בנושא DBCluster CRD.

קישוריות פנימית

כברירת מחדל, מופעלת חשיפה של מופעי AlloyDB Omni באמצעות ClusterIP Service של Kubernetes. כך אפשר לוודא שהגישה למכונות תהיה רק לאפליקציות אחרות שפועלות באותו אשכול Kubernetes. אפשר למצוא את נקודת הקצה של המכונה הראשית בסטטוס DBCluster.

קישוריות חיצונית

כדי לאפשר חיבורים מחוץ לאשכול Kubernetes, מעדכנים את המפרט של DBCluster:

  • הפעלת תנועה חיצונית: מגדירים את spec.allowExternalIncomingTraffic: true, שבדרך כלל מקצה שירות LoadBalancer.
  • הטמעת אמצעי בקרה פרטניים: שימוש ב-spec.primarySpec.dbLoadBalancerOptions. לדוגמה, ב-Google Cloud, מגדירים את gcp.loadBalancerType: "External" כדי לקבל כתובת IP שאפשר לגשת אליה מהאינטרנט הציבורי.

הגבלת הגישה

כדי לאבטח חיבורים חיצוניים, משתמשים ב-spec.primarySpec.sourceCidrRanges כדי להגדיר רשימה של טווחי CIDR מותרים. המערכת חוסמת חיבורים שמקורם בכתובות IP מחוץ לטווחים האלה.

מאגר חיבורים עם PgBouncer

כדי לנהל את החיבורים בצורה יעילה ולהפחית את עומס המופע, כדאי להשתמש ב-PgBouncer. אופרטור AlloyDB Omni מספק PgBouncer משאב בהתאמה אישית (CR) כדי לפשט את הפעולה הזו.

פרטים מקיפים על הגדרת PgBouncer זמינים במאמר PgBouncer CRD Reference.

פריסה והגדרה

יוצרים משאב PgBouncer ומפנים לאשכול מסד הנתונים ב-spec.dbclusterRef. הפרמטרים העיקריים ב-spec.parameters כוללים את הפרמטרים הבאים:

  • ‫pool_mode: קובע מתי נעשה שימוש חוזר בחיבורים (session, ‏transaction או statement).
  • default_pool_size: חיבורי שרת לכל משתמש ומסד נתונים.
  • ‫max_client_conn: המספר המקסימלי של חיבורי לקוחות שמותרים.
  • ‫max_db_connections: מספר החיבורים המקסימלי שנפתחו למכונה של AlloyDB Omni.

חשיפת PgBouncer

משתמשים ב-spec.serviceOptions.type כדי לשלוט בחשיפה.

  • ‫ClusterIP: גישה פנימית לאשכול בלבד.
  • ‫LoadBalancer: גישה חיצונית. אפשר להגביל את זה באמצעות spec.serviceOptions.loadBalancerSourceRanges באמצעות בלוקים של CIDR.

אימות והרשאה

‫AlloyDB Omni תומך בכמה שיטות לאימות זהויות ולשליטה בגישה.

שיטות אימות

  • מבוסס-סיסמה: אימות רגיל של שם משתמש וסיסמה ב-PostgreSQL. בדרך כלל סיסמת האדמין מסופקת באמצעות Kubernetes Secret, כמו שמוצג בדוגמה המלאה של DBCluster.

  • ‫Active Directory ו-Kerberos: מנוהלים באמצעות UserDefinedAuthentication CR. הוא תומך בסנכרון של קבוצות GSSAPI ו-LDAP באמצעות:

    • ‫spec.keytabSecretRef: לקובצי keytab של Kerberos.
    • ‫spec.ldapConfiguration: למיפוי קבוצות ולהגדרות LDAP.
    • ‫spec.pgHbaEntries: להגדרת כללי pg_hba.conf – לדוגמה, gss או ldap.

    מידע נוסף זמין במאמר UserDefinedAuthentication CRD Reference.

  • מבוסס-אישור (מתוכנן): תמיכה באימות אישור TLS ללא סיסמה מתוכננת לגרסה עתידית.

הרשאה ובקרת גישה

  • מדיניות רשת ב-Kubernetes: הגדרת כללים ברמת ה-Pod לאבטחת תעבורת נתונים בין אפליקציות לבין AlloyDB Omni או PgBouncer Pods.
  • טווחי CIDR של המקור: הגבלת התנועה ברמת LoadBalancer.
  • תפקידים ב-PostgreSQL: משתמשים בתפקידים ובהרשאות סטנדרטיים במסד הנתונים כדי לנהל את הרשאות המשתמשים אחרי שהם מאומתים.

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