סקירה קצרה של מפעילי PostgreSQL עבור Kubernetes, הבחירה והניסיון שלנו

יותר ויותר, לקוחות מקבלים את הבקשות הבאות: "אנחנו רוצים את זה כמו Amazon RDS, אבל זול יותר"; "אנחנו רוצים את זה כמו RDS, אבל בכל מקום, בכל תשתית." כדי ליישם פתרון מנוהל כזה על Kubernetes, בדקנו את המצב הנוכחי של המפעילים הפופולריים ביותר עבור PostgreSQL (Solon, מפעילים מ-Crunchy Data ו-Zalando) ובחרנו.

מאמר זה הוא הניסיון שצברנו הן מנקודת מבט תיאורטית (סקירת פתרונות) והן מהצד המעשי (מה נבחר ומה יצא מזה). אבל ראשית, בואו נקבע מהן הדרישות הכלליות לתחליף פוטנציאלי ל-RDS...

מה זה RDS

כשאנשים מדברים על RDS, מניסיוננו, הם מתכוונים לשירות DBMS מנוהל ש:

1. קל להגדרה;
2. יש את היכולת לעבוד עם צילומי מצב ולהתאושש מהם (רצוי עם תמיכה PITR);
3. מאפשר לך ליצור טופולוגיות מאסטר-עבד;
4. יש רשימה עשירה של הרחבות;
5. מספק ביקורת וניהול משתמשים/גישה.

באופן כללי, הגישות ליישום המשימה שעל הפרק עשויות להיות שונות מאוד, אבל הדרך עם Ansible מותנית אינה קרובה אלינו. (עמיתים מ-2GIS הגיעו למסקנה דומה כתוצאה מכך הניסיון שלו צור "כלי לפריסה מהירה של אשכול כשל מבוסס Postgres."

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

NB: כדי ליצור במהירות אופרטורים פשוטים, אנו ממליצים לשים לב לכלי השירות שלנו בקוד פתוח מפעיל מעטפת. באמצעותו תוכלו לעשות זאת ללא ידיעת Go, אך בדרכים המוכרות יותר למנהלי מערכת: ב-Bash, Python וכו'.

ישנם מספר מפעילי K8s פופולריים עבור PostgreSQL:

• סטולון;
• אופרטור PostgreSQL נתונים פריכים;
• מפעיל Zalando Postgres.

בואו נסתכל עליהם יותר מקרוב.

בחירת המפעיל

בנוסף לתכונות החשובות שכבר צוינו לעיל, אנו - כמהנדסי תפעול תשתיות Kubernetes - ציפינו גם מהמפעילים הבאים:

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

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

כעת נעבור לאופרטורים של PostgreSQL עצמם.

1. סטולון

סטולון מחברת Sorint.lab האיטלקית ב דוח שכבר הוזכר נחשב כסוג של תקן בקרב מפעילי DBMS. זהו פרויקט ישן למדי: ההוצאה הפומבית הראשונה שלו התרחשה בנובמבר 2015(!), ומאגר GitHub מתגאה בכמעט 3000 כוכבים ובמעל 40 תורמים.

ואכן, סטולון הוא דוגמה מצוינת לארכיטקטורה מהורהרת:

ניתן למצוא את המכשיר של מפעיל זה בפירוט בדוח או תיעוד הפרויקט. באופן כללי, די אם נאמר שהוא יכול לעשות את כל מה שתואר: failover, פרוקסי לגישה שקופה ללקוח, גיבויים... יתרה מכך, פרוקסי מספקים גישה דרך שירות נקודת קצה אחד - בניגוד לשני הפתרונות האחרים הנידונים להלן (לכל אחד יש שני שירותים עבור בסיס גישה).

עם זאת, סטולון אין משאבים מותאמים אישית, וזו הסיבה שלא ניתן לפרוס אותו בצורה כזו שיהיה קל ומהיר - "כמו לחמניות חמות" - ליצור מופעי DBMS ב-Kubernetes. הניהול מתבצע באמצעות השירות stolonctl, הפריסה נעשית באמצעות תרשים Helm, ואלה מותאמים אישית מוגדרים ומצוינים ב-ConfigMap.

מצד אחד, מסתבר שהמפעיל הוא לא באמת אופרטור (הרי הוא לא משתמש ב-CRD). אבל מצד שני, זו מערכת גמישה שמאפשרת לך להגדיר משאבים ב-K8s כראות עיניך.

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

2. מפעיל נתונים פריך PostgreSQL

מפעיל מבית Crunchy Data, סטארטאפ אמריקאי צעיר, נראה כמו אלטרנטיבה הגיונית. ההיסטוריה הציבורית שלו מתחילה במהדורה הראשונה במרץ 2017, מאז מאגר GitHub קיבל קצת פחות מ-1300 כוכבים ו-50+ תורמים. המהדורה האחרונה מספטמבר נבדקה לעבוד עם Kubernetes 1.15-1.18, OpenShift 3.11+ ו-4.4+, GKE ו-VMware Enterprise PKS 1.3+.

הארכיטקטורה של Crunchy Data PostgreSQL Operator עומדת גם בדרישות המוצהרות:

הניהול מתרחש באמצעות כלי השירות pgoעם זאת, זה בתורו מייצר משאבים מותאמים אישית עבור Kubernetes. לכן, המפעיל שימח אותנו כמשתמשים פוטנציאליים:

• יש שליטה באמצעות CRD;
• ניהול נוח של משתמשים (גם באמצעות CRD);
• אינטגרציה עם רכיבים אחרים חבילת מיכל נתונים פריך - אוסף מיוחד של תמונות מיכל עבור PostgreSQL וכלי עזר לעבודה איתה (כולל pgBackRest, pgAudit, הרחבות מ-contrib וכו').

עם זאת, ניסיונות להתחיל להשתמש במפעיל מ-Crunchy Data חשפו מספר בעיות:

• לא הייתה אפשרות לסבולות - רק nodeSelector מסופק.
• התרמילים שנוצרו היו חלק מ-Deployment, למרות העובדה שפרסנו יישום סטטיסטי. שלא כמו StatefulSets, Deployments לא יכול ליצור דיסקים.

החיסרון האחרון מוביל לרגעים מצחיקים: בסביבת הבדיקה הצלחנו להריץ 3 העתקים עם דיסק אחד אחסון מקומי, מה שגורם למפעיל לדווח ש-3 העתקים פועלים (למרות שלא היו).

תכונה נוספת של מפעיל זה היא השילוב המוכן שלו עם מערכות עזר שונות. לדוגמה, קל להתקין את pgAdmin ו-pgBounce, וכן ב תיעוד Grafana ו-Prometheus מוגדרים מראש נחשבים. לאחרונה גרסה 4.5.0-beta1 שילוב משופר עם הפרויקט מצוין בנפרד pgMonitor, שבזכותו המפעיל מציע הדמיה ברורה של מדדי PgSQL מחוץ לקופסה.

עם זאת, הבחירה המוזרה של משאבים שנוצרו על ידי Kubernetes הובילה אותנו לצורך למצוא פתרון אחר.

3. מפעיל Zalando Postgres

אנחנו מכירים את מוצרי Zalando כבר זמן רב: יש לנו ניסיון בשימוש ב-Zelenium וכמובן שניסינו פטרוני הוא פתרון ה-HA הפופולרי שלהם עבור PostgreSQL. על גישת החברה ליצירה מפעיל Postgres אחד ממחבריו, אלכסיי קליוקין, אמר בשידור פוסט גרס-שלישי מס' 5, ואהבנו את זה.

זהו הפתרון הצעיר ביותר שנדון במאמר: השחרור הראשון התרחש באוגוסט 2018. עם זאת, למרות המספר הקטן של מהדורות רשמיות, הפרויקט עבר כברת דרך, וכבר עבר בפופולריות את הפתרון של Crunchy Data עם 1300+ כוכבים ב- GitHub ומספר התורמים המקסימלי (70+).

"מתחת למכסה המנוע" מפעיל זה משתמש בפתרונות שנבדקו בזמן:

• פטרוני ו ספילו לנהיגה,
• WAL-E - לגיבויים,
• PgBouncer - כבריכת חיבור.

כך מוצגת ארכיטקטורת המפעיל מ- Zalando:

המפעיל מנוהל במלואו באמצעות משאבים מותאמים אישית, יוצר אוטומטית StatefulSet ממכולות, שאותו ניתן להתאים אישית על ידי הוספת קרונות צד שונים לתרמיל. כל זה מהווה יתרון משמעותי בהשוואה למפעיל מבית Crunchy Data.

מכיוון שבחרנו בפתרון של Zalando בין 3 האפשרויות הנבדקות, תיאור נוסף של יכולותיו יוצג להלן, מיד יחד עם תרגול היישום.

תרגול עם Postgres Operator מ- Zalando

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

לאחר ההתקנה, אתה צריך לדאוג לגבי ההגדרה אחסון עבור יומנים וגיבויים. זה נעשה באמצעות ConfigMap postgres-operator במרחב השמות שבו התקנת את המפעיל. לאחר הגדרת המאגרים, תוכל לפרוס את אשכול PostgreSQL הראשון שלך.

לדוגמה, הפריסה הסטנדרטית שלנו נראית כך:

apiVersion: acid.zalan.do/v1
kind: postgresql
metadata:
 name: staging-db
spec:
 numberOfInstances: 3
 patroni:
   synchronous_mode: true
 postgresql:
   version: "12"
 resources:
   limits:
     cpu: 100m
     memory: 1Gi
   requests:
     cpu: 100m
     memory: 1Gi
 sidecars:
 - env:
   - name: DATA_SOURCE_URI
     value: 127.0.0.1:5432
   - name: DATA_SOURCE_PASS
     valueFrom:
       secretKeyRef:
         key: password
         name: postgres.staging-db.credentials
   - name: DATA_SOURCE_USER
     value: postgres
   image: wrouesnel/postgres_exporter
   name: prometheus-exporter
   resources:
     limits:
       cpu: 500m
       memory: 100Mi
     requests:
       cpu: 100m
       memory: 100Mi
 teamId: staging
 volume:
   size: 2Gi

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

כדאי לשים לב אליו פאנל ניהול אינטרנט - postgres-operator-ui. זה מגיע עם המפעיל ומאפשר ליצור ולמחוק אשכולות, כמו גם לעבוד עם גיבויים שנעשו על ידי המפעיל.

רשימה של אשכולות PostgreSQL

ניהול גיבויים

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

בעיות ופתרונות

עם זאת, השימוש במפעיל חשף במהרה כמה חסרונות משמעותיים:

1. היעדר תמיכה ב-nodeSelector;
2. חוסר יכולת להשבית גיבויים;
3. בעת שימוש בפונקציית יצירת מסד הנתונים, הרשאות ברירת המחדל אינן מופיעות;
4. לפעמים תיעוד חסר או לא מעודכן.

למרבה המזל, רבים מהם ניתנים לפתרון. נתחיל מהסוף - בעיות עם תיעוד.

סביר להניח שתתקלו בעובדה שלא תמיד ברור כיצד לרשום גיבוי וכיצד לחבר את דלי הגיבוי ל-Operator UI. התיעוד מדבר על כך בטעות, אבל התיאור האמיתי נמצא בפנים PR:

1. צריך לעשות סוד;
2. להעביר אותו למפעיל כפרמטר pod_environment_secret_name ב-CRD עם הגדרות מפעיל או ב-ConfigMap (תלוי איך תחליט להתקין את המפעיל).

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

אם תעביר את הפרמטרים לגיבוי למפעיל, כלומר - wal_s3_bucket ומפתחות גישה ב-AWS S3, ואז זה יגבה הכל: לא רק בסיסים בהפקה, אלא גם בימוי. זה לא התאים לנו.

בתיאור הפרמטרים של Spilo, שהוא ה-Docker Wrapper הבסיסי עבור PgSQL בעת שימוש באופרטור, התברר: ניתן להעביר פרמטר WAL_S3_BUCKET ריק, ובכך משבית גיבויים. יתר על כן, לשמחה רבה, מצאתי יחסי ציבור מוכנים, שאותה קיבלנו מיד למזלגנו. עכשיו רק צריך להוסיף enableWALArchiving: false למשאב אשכול PostgreSQL.

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

אוקי, למדנו כיצד להעביר גישה לבסיסי הנתונים עבור S3 והגיבויים החלו להיכנס לאחסון. כיצד לגרום לדפי גיבוי לעבוד בממשק המשתמש של המפעיל?

תצטרך להוסיף 3 משתנים לממשק המשתמש של המפעיל:

• SPILO_S3_BACKUP_BUCKET
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY

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

יתרון נוסף היה העבודה עם ה-API של Teams והזדמנויות רבות ליצירת מסדי נתונים ותפקידים באמצעות כלי מפעיל. עם זאת, נוצר לתפקידים לא היו זכויות כברירת מחדל. בהתאם לכך, משתמש בעל זכויות קריאה לא יכול היה לקרוא טבלאות חדשות.

למה? למרות העובדה שבקוד יש הכרחי GRANT, לא תמיד משתמשים בהם. יש 2 שיטות: syncPreparedDatabases и syncDatabases. בתוך syncPreparedDatabases - למרות העובדה שבסעיף preparedDatabases יש יש תנאי defaultRoles и defaultUsers כדי ליצור תפקידים, זכויות ברירת מחדל אינן מוחלות. אנו נמצאים בתהליך של הכנת תיקון כך שהזכויות הללו יחולו אוטומטית.

והנקודה האחרונה בשיפורים הרלוונטיים לנו - תיקון, שמוסיף Node Affinity ל-StatefulSet שנוצר. הלקוחות שלנו מעדיפים לעתים קרובות להפחית עלויות על ידי שימוש במופעים נקודתיים, וברור שהם לא שווים לארח שירותי מסד נתונים. ניתן לפתור בעיה זו באמצעות סובלנות, אך הנוכחות של Node Affinity מעניקה ביטחון רב יותר.

מה קרה?

בהתבסס על התוצאות של פתרון הבעיות לעיל, חילקנו את Postgres Operator מ- Zalando המאגר שלך, שם הוא נאסף עם טלאים שימושיים כאלה. וליתר נוחות, גם אספנו תמונת דוקר.

רשימת אנשי יחסי הציבור שהתקבלו למזלג:

• בניית תמונה קלת משקל מאובטחת למפעיל ב-Docker;
• השבתת גיבויים;
• עדכון גרסאות משאבים עבור גרסאות נוכחיות של k8s;
• יישום של Node Affinity.

זה יהיה נהדר אם הקהילה תתמוך ב-PRs אלה כדי שיגיעו במעלה הזרם עם הגרסה הבאה של המפעיל (1.6).

מַעֲנָק! סיפור הצלחה של העברת ייצור

אם אתה משתמש בפטרוני, ניתן להעביר ייצור חי למפעיל עם זמן השבתה מינימלי.

Spilo מאפשר לך ליצור אשכולות המתנה באמצעות אחסון S3 עם וול-אי, כאשר היומן הבינארי של PgSQL מאוחסן לראשונה ב-S3 ולאחר מכן נשאב החוצה על ידי העתק. אבל מה לעשות אם יש לך לא בשימוש על ידי Wal-E על תשתית ישנה? הפתרון לבעיה זו כבר זה הוצע על הרכזת.

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

העובדה היא שבבסיס הנתונים היו כמה טבלאות טעונות עם מיליוני שורות, אשר יתר על כן, התחדשו ונמחקו כל הזמן. מנוי פשוט с copy_data, כאשר העתק החדש מעתיק את כל התוכן מהמאסטר, הוא פשוט לא יכול לעמוד בקצב של המאסטר. העתקת התוכן עבדה במשך שבוע, אך מעולם לא הדביקה את המאסטר. בסופו של דבר, זה עזר לי לפתור את הבעיה מאמר עמיתים מ-Avito: אתה יכול להעביר נתונים באמצעות pg_dump. אני אתאר את הגרסה (השתונתה מעט) של האלגוריתם הזה.

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

פקודות עוקבות המתארות את תהליך ההגירה ישתמשו בתווי המארחים הבאים:

1. אב - שרת מקור;
2. העתק 1 - העתק סטרימינג על ההפקה הישנה;
3. העתק 2 - העתק לוגי חדש.

תוכנית הגירה

1. צור מנוי במאסטר עבור כל הטבלאות בסכימה public בסיסים dbname:

psql -h master -d dbname -c "CREATE PUBLICATION dbname FOR ALL TABLES;"

2. צור חריץ שכפול במאסטר:

psql -h master -c "select pg_create_logical_replication_slot('repl', 'pgoutput');"

3. הפסק את השכפול על העתק הישן:

psql -h replica1 -c "select pg_wal_replay_pause();"

4. קבל את מספר העסקה מהמאסטר:

psql -h master -c "select replay_lsn from pg_stat_replication where client_addr = 'replica1';"

5. הסר את המזבלה מהעותק הישן. נעשה זאת במספר שרשורים, שיעזרו להאיץ את התהליך:

pg_dump -h replica1 --no-publications --no-subscriptions -O -C -F d -j 8 -f dump/ dbname

6. העלה את ה-dump לשרת החדש:

pg_restore -h replica2 -F d -j 8 -d dbname dump/

7. לאחר הורדת ה-dump, אתה יכול להתחיל רפליקציה על העתק הסטרימינג:

psql -h replica1 -c "select pg_wal_replay_resume();"

7. בואו ניצור מנוי על עותק לוגי חדש:

psql -h replica2 -c "create subscription oldprod connection 'host=replica1 port=5432 user=postgres password=secret dbname=dbname' publication dbname with (enabled = false, create_slot = false, copy_data = false, slot_name='repl');"

8. בואו נקבל oid מנויים:

psql -h replica2 -d dbname -c "select oid, * from pg_subscription;"

9. נניח שזה התקבל oid=1000. בואו נחיל את מספר העסקה על המנוי:

psql -h replica2 -d dbname -c "select pg_replication_origin_advance('pg_1000', 'AA/AAAAAAAA');"

10. בואו נתחיל שכפול:

psql -h replica2 -d dbname -c "alter subscription oldprod enable;"

11. בדוק את מצב המנוי, שכפול אמור לעבוד:

psql -h replica2 -d dbname -c "select * from pg_replication_origin_status;"
psql -h master -d dbname -c "select slot_name, restart_lsn, confirmed_flush_lsn from pg_replication_slots;"

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

13. לאחר השבתת השכפול, עליך לתקן את הרצפים. זה מתואר היטב במאמר ב-wiki.postgresql.org.

הודות לתוכנית זו, המעבר התרחש בעיכובים מינימליים.

מסקנה

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

לאחר שקלטנו את שלושת המפעילים הפופולריים ביותר של Kubernetes עבור PostgreSQL, בחרנו בפרויקט מ- Zalando. והיינו צריכים להתגבר על קשיים מסוימים עם זה, אבל התוצאה הייתה ממש מענגת, אז אנחנו מתכננים להרחיב את החוויה הזו לכמה התקנות PgSQL אחרות. אם יש לך ניסיון בשימוש בפתרונות דומים, נשמח לראות את הפרטים בהערות!

נ.ב.

קרא גם בבלוג שלנו:

• «מסדי נתונים ו-Kubernetes (סקירה ודוח וידאו)";
• «Postgres יום שלישי מס' 5: PostgreSQL ו-Kubernetes. CI/CD. בדיקת אוטומציה";
• «סיפור אחד עם מפעיל Redis ב-K8s ומיני סקירה של כלי עזר לניתוח נתונים ממסד נתונים זה".

מקור: www.habr.com