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

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

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

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

Networking

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

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

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

כברירת מחדל, מכונות AlloyDB Omni נחשפות באמצעות שירות ClusterIP של 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.

פריסה והגדרות אישיות

יוצרים משאב 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.

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

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

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

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