התאמה אישית של תוכנית ההעברה למכונות וירטואליות של Linux

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

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

לפני שמתחילים

במאמר הזה אנחנו מניחים שכבר יצרתם תוכנית העברה ויש לכם את קובץ תוכנית ההעברה שנוצר.

עריכת תוכנית ההעברה

אחרי שמעתיקים את מערכת הקבצים ומנתחים אותה, אפשר למצוא את תוכנית ההעברה בספרייה החדשה שנוצרת בנתיב הפלט שצוין: ANALYSIS_OUTPUT_PATH/config.yaml.

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

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

ציון תוכן להחרגה מההעברה

כברירת מחדל, הכלי Migrate to Containers לא כולל תוכן אופייני של מכונות וירטואליות שלא רלוונטי בהקשר של GKE. אפשר להתאים אישית את המסנן הזה.

בערך השדה filters מפורטות נתיבים שצריך להחריג מההעברה, והם לא יהיו חלק מקובץ אימג' של קונטיינר. הערך בשדה מפרט כללי סינון של rsync שמציינים אילו קבצים להעביר ואילו קבצים לדלג עליהם. אם מוסיפים סימן מינוס לפני כל נתיב וקובץ, הפריט ברשימה לא ייכלל בהעברה. הרשימה מעובדת לפי סדר השורות בקובץ ה-YAML, וההחרגות או ההכללות מוערכות בהתאם.

מידע נוסף על כללי סינון של rsync

קבצים שגדולים מדי ואי אפשר לכלול אותם בקובץ אימג' של Docker מפורטים בקובץ YAML. כך תוכלו לסמן קבצים שגדולים מ-1GB כדי לבדוק אותם. תמונות Docker גדולות מדי, או גדולות מ-15GB, עלולות להיכשל במהלך ההעברה.

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

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

באותו אופן, אפשר גם להחריג או להעביר את הקבצים הדלילים שזוהו.

  global:
    # Files and directories to exclude from the migration, in rsync format.
    filters:
      - "- *.swp"
      - "- /etc/fstab"
      - "- /boot/"
      - "- /tmp/*"
      - "- /var/log/*.log*"
      - "- /var/log/*/*.log*"
      - "- /var/cache/*"

    ## The data folders below are too large to be included in the docker image.
    ## Consider uncommenting and placing them under either the global filters
    ## or the data folder section.
      # - '- /a' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)
      # - '- /a/c' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)

    ## Sparse files will fail the run of a docker image. Consider excluding the below
    ## detected files and any other sparse files by uncommenting and placing them in 
    ## the global filters section, or export them to a persistent volume by specifying
    ## them in the data folder section.
      # - '- /a/b' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)
      # - '- /a/d' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)

הגדרת השם של קובץ אימג' של קונטיינר

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

image:
     # Review and set the name for runnable container image.
     name: linux-system

התאמה אישית של רשימת השירותים

כברירת מחדל, הכלי Migrate to Containers משבית שירותים לא נחוצים במכונה וירטואלית כשמעבירים אותה לקונטיינר. לפעמים השירותים האלה גורמים לבעיות במאגר שהועבר, או שלא נדרשים בהקשר של מאגר.

בנוסף לשירותים שמושבתים באופן אוטומטי על ידי Migrate to Containers, אתם יכולים להשבית שירותים אחרים:

  • הכלי Migrate to Containers מגלה באופן אוטומטי שירותים שאפשר להשבית, ומפרט אותם בתוכנית ההעברה. יכול להיות שלא תצטרכו את השירותים האלה, כמו ssh או שרת אינטרנט, בעומס העבודה שהועבר, אבל ההחלטה אם להשתמש בהם או לא היא שלכם. אם צריך, עורכים את תוכנית ההעברה כדי להשבית את השירותים האלה.

  • ב-Migrate to Containers לא מופיעים כל השירותים שפועלים במכונה הווירטואלית של המקור. לדוגמה, היא לא כוללת שירותים שקשורים למערכת ההפעלה. אפשר גם לערוך את תוכנית ההעברה כדי להוסיף רשימה משלכם של שירותים להשבתה במאגר שהועבר.

השדה systemServices מציין את רשימת השירותים שזוהו על ידי Migrate to Containers. לדוגמה:

    systemServices:
    - enabled: true|false
      name: service-name
      probed: true|false
    - enabled: true|false
      name: service-name
      probed: true|false
      ...

כדי להשבית שירות, מגדירים את enabled ל-false.

ב-Migrate to Containers לא מופיעים כל השירותים שפועלים במכונת ה-VM של המקור, כמו שירותים שקשורים למערכת ההפעלה. אפשר גם להוסיף לרשימה שירותים נוספים. לדוגמה, כדי להשבית את service2 ואת השירות cron:

    systemServices:
    - enabled: true
      name: service1
      probed: false
    - enabled: false
      name: service2
      probed: false
    - enabled: false
      name: cron
      probed: false

כשמבצעים מיגרציה כדי ליצור את ארטיפקטי המיגרציה, הכלי Migrate to Containers יוצר את הקובץ blocklist.yaml. בקובץ הזה מפורטים שירותי המכולות שצריך להשבית על סמך ההגדרות בתוכנית ההעברה. לדוגמה:

service_list:
- name: disabled-services
  services:
  # Because you used systemServices above to disabled service2 and cron:
  - service2
  - cron

כדי לשנות בהמשך את רשימת השירותים שהושבתו:

  • עורכים את רשימת השירותים בתוכנית ההעברה.
  • מבצעים את ההעברה כדי ליצור מחדש את פריטי המיגרציה, כולל blocklist.yaml מעודכן.

לחלופין, אחרי שמריצים מיגרציה כדי ליצור את ארטיפקטי המיגרציה, אפשר לערוך את הקובץ blocklist.yaml ישירות, ואז ליצור ולפרוס את קובץ האימג' של הקונטיינר באמצעות Skaffold.

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

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

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

sudo netstat --programs --listening --tcp --udp [--sctp]

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

    endpoints:
    - port: PORT_NUMBER
      protocol: PORT_PROTOCOL
      name: PORT_NAME

כאשר:

  • ‫PORT_NUMBER מציין את מספר היציאה של מאגר התגים שאליו מנותבות הבקשות לשירות.
  • ‫PORT_PROTOCOL מציין את פרוטוקול היציאה, כמו HTTP,‏ HTTPS או TCP. רשימה מלאה של פרוטוקולים מופיעה במאמר בנושא פרוטוקולים נתמכים.
  • ‫PORT_NAME מציין את השם שמשמש לגישה לנקודת הקצה של השירות. הכלי Migrate to Containers יוצר PORT_NAME ייחודי לכל הגדרה של נקודת קצה שנוצרת.

לדוגמה, Migrate to Containers מזהה את נקודות הקצה הבאות:

  endpoints:
    - port: 80
      protocol: HTTP
      name: backend-server-nginx
    - port: 6379
      protocol: TCP
      name: backend-server-redis

כדי להגדיר את הערך של המאפיין name, הכלי Migrate to Containers משלב את שם המכונה הווירטואלית של המקור, backend-server בדוגמה הזו, עם שם התוכנית של השירות. השמות שנוצרו תואמים למוסכמות מתן השמות של Kubernetes, והם ייחודיים בתוכנית ההעברה. לדוגמה, תוכנית ההעברה שלמעלה יוצרת שירות שמכוון ל-Nginx ביציאה 80 באמצעות HTTP.

לכל שם כפול, האפליקציה Migrate to Containers מוסיפה סיומת של מונה. לדוגמה, אם Nginx משויך לשתי יציאות, המערכת מוסיפה את הסיומת -2 ל-name בהגדרה השנייה:

  endpoints:
    - port: 80
      protocol: HTTP
      name: backend-server-nginx
    - port: 8080
      protocol: HTTPS
      name: backend-server-nginx-2
    - port: 6379
      protocol: TCP
      name: backend-server-redis

כשמבצעים העברה כדי ליצור את הארטיפקטים של ההעברה, הכלי Migrate to Containers יוצר הגדרת Service בקובץ deployment_spec.yaml לכל נקודת קצה.

לדוגמה, ההגדרה של Service בקובץ deployment_spec.yaml מוצגת בהמשך:

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  name: backend-server-nginx
spec:
  ports:
  - port: 80
    protocol: HTTP
    targetPort: 80
  selector:
    app: backend-server
status:
  loadBalancer: {}

התאמה אישית של נקודות חיבור NFS

הכלי Migrate to Containers כולל נקודות הרכבה של NFS בתוכנית המיגרציה שנוצרת. המידע הזה נאסף מהקובץ fstab ונכתב למערך nfsMounts בתוכנית ההעברה. אתם יכולים להוסיף או לערוך הגדרות של נקודות חיבור NFS כדי להתאים אישית את תוכנית ההעברה.

כשיוצרים את תוכנית ההעברה, Migrate to Containers:

  • מתעלם מחיבורי NFS ב-/sys וב-/dev.
  • מתעלם מנקודות חיבור של NFS עם סוג שאינו nfs או nfs4.

כל NFS mount בתוכנית ההעברה כולל את כתובת ה-IP של השרת ואת נתיב ה-mount המקומי בפורמט:

    nfsMounts:
    - mountPoint: MOUNT_POINT
      exportedDirectory: DIR_NAME
      nfsServer: IP
      mountOptions:
         - OPTION_1
         - OPTION_2
      enabled: false|true

כאשר:

  • ‫MOUNT_POINT מציין את נקודת הטעינה שהתקבלה מ-fstab.
  • ‫DIR_NAME מציין את השם של הספרייה המשותפת.
  • ‫IP מציין את כתובת ה-IP של השרת שמארח את נקודת הטעינה.
  • ‫OPTION_N מציין את האפשרויות שחולצו מ-fstab לנקודת הטעינה.

לדוגמה, עבור הרשומה הבאה ב-fstab:

<file system>       <mount point>   <type>  <options>   <dump>  <pass>
10.49.232.26:/vol1  /mnt/test       nfs     rw,hard     0       0

הכלי Migrate to Containers יוצר את הרשומה הבאה בתוכנית ההעברה:

    nfsMounts:
    - mountPoint: /mnt/test
      exportedDirectory: /vol1
      nfsServer: 10.49.232.26
      mountOptions:
         - rw
         - hard
      enabled: false

כדי להגדיר את Migrate to Containers לעיבוד רשומות במערך nfsMounts, צריך להגדיר את enabled לערך true עבור הרשומה mountPoint. אתם יכולים להפעיל רשומה אחת, כמה רשומות או את כל הרשומות mountPoints, לערוך את הרשומות או להוסיף רשומות משלכם.

כשמבצעים העברה כדי ליצור את ארטיפקטי ההעברה, Migrate to Containers יוצר הגדרה של volumes ו-volumeMounts והגדרה של PersistentVolume ו-PersistentVolumeClaim בקובץ deployment_spec.yaml לכל טעינת NFS מופעלת.

לדוגמה, ההגדרה של volumeMounts בקובץ deployment_spec.yaml מוצגת בהמשך:

    spec:
      containers:
          - image: gcr.io/myimage-1/image-name
            name: some-app
            volumeMounts:
                   - mountPath: /sys/fs/cgroup
                     name: cgroups
                   - mountPath: /mnt/test
                     name: nfs-pv

כאשר הערך של name הוא מזהה ייחודי שנוצר על ידי Migrate to Containers.

בהמשך מוצגות דוגמאות להגדרות של PersistentVolumeClaim וPersistentVolume בקובץ deployment_spec.yaml:

apiVersion: v1
kind: PersistentVolumeClaim
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Mi
  storageClassName: ""
  volumeName: nfs-pv

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  mountOptions:
    - rw
    - hard
  nfs:
    path: /vol1
    server: 10.49.232.26

התאמה אישית של נתוני היומן שנכתבים ב-Cloud Logging

בדרך כלל, מכונה וירטואלית של מקור כותבת מידע לקובץ יומן אחד או יותר. במסגרת העברת המכונה הווירטואלית, אפשר להגדיר את עומס העבודה שהועבר כך שיכתוב את פרטי היומן האלה ל-Cloud Logging.

כשיוצרים את תוכנית המיגרציה, הכלי Migrate to Containers מחפש באופן אוטומטי קבצים של יעד יומן במכונה הווירטואלית של המקור. ‫Migrate to Containers כותב מידע על הקבצים האלה שאותרו באזור logPaths של תוכנית ההעברה:

deployment:
    ...
    logPaths:
    - appName: APP_NAME
      globs:
      - LOG_PATH

לדוגמה:

deployment:
    ...
    logPaths:
    - appName: tomcat
      globs:
      - /var/log/tomcat*/catalina.out

כשיוצרים את ארטיפקטי המיגרציה, הכלי Migrate to Containers יוצר את הקובץ logs.yaml מתוכנית המיגרציה. הקובץ הזה מכיל את רשימת קובצי היומן שאותרו במכונה הווירטואלית של המקור. לדוגמה, מההגדרה של logsPath שלמעלה, logs.yaml מכיל:

logs:
  tomcat:
  - /var/log/tomcat*/catalina.out

בדוגמה הזו, כשפורסים את עומס העבודה שהועבר, פרטי היומן שנכתבו אל catalina.out נכתבים אוטומטית אל Cloud Logging.

כל רשומה מופיעה בשורה ביומן בצורה הבאה:

DATE TIME APP_NAME LOG_OUTPUT

בדוגמה הבאה מוצג הטופס עם רשומה מ-Tomcat:

2019-09-22 12:43:08.681193976 +0000 UTC tomcat log-output

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

  • עורכים את תוכנית ההעברה לפני שיוצרים את ארטיפקטי ההעברה כדי להוסיף, להסיר או לערוך רשומות של logPaths. כשיוצרים את הארטיפקטים של המיגרציה, העריכות האלה משתקפות בקובץ logs.yaml.

  • אחרי שיוצרים את ארטיפקטי ההעברה, אפשר לערוך את logs.yaml כדי להוסיף, להסיר או לערוך רשומות של logs.

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

הגדרת בדיקות תקינות של v2kServiceManager ב-Linux

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

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

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

מידע נוסף על בדיקות kubelet זמין במאמר Configure Liveness, Readiness and Startup Probes (הגדרת בדיקות פעילות, מוכנות והפעלה) במסמכי התיעוד של Kubernetes.

יש שני סוגים של בדיקות שאפשר להגדיר. שתי הבדיקות הן probe-v1-core, שמוגדרות בהפניה ל-probe-v1-core, ושתיהן חולקות את אותה פונקציה כמו השדות התואמים של container-v1-core

  • בקשה לבדיקת תקינות מצב פעילות (liveness probe) – בקשות לבדיקת תקינות מצב פעילות (liveness probe) משמשות כדי לדעת מתי להפעיל מחדש קונטיינר.

  • בקשה לבדיקת תקינות (probe) מוכנות – בקשות לבדיקת תקינות (probe) מוכנות משמשות כדי לדעת מתי קונטיינר מוכן להתחיל לקבל תנועה. כדי להתחיל לשלוח תנועה ל-Pod רק כשבדיקת המוכנות מצליחה, צריך לציין בדיקת מוכנות. בדיקת מוכנות עשויה לפעול באופן דומה לבדיקת פעילות, אבל בדיקת מוכנות במפרטים מציינת ש-Pod יתחיל בלי לקבל תנועה, ויתחיל לקבל תנועה רק אחרי שהבדיקה תצליח.

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

deployment:
  probes:
    livenessProbe:
      exec:
        command:
        - /ko-app/service-manager-runtime
        - /probe

    readinessProbe:
      exec:
        command:
        - gamma
        - /probe
      initialDelaySeconds: 60
      periodSeconds: 5

image:
  # Disable system services that do not need to be executed at the migrated workload containers.
  # Enable the 'probed' property to include system services in the container health checks.
  systemServices:
  - enabled: true
    name: apache2
    probed: true
  - enabled: true
    name: atd
    probed: false

כברירת מחדל, כל הבדיקות של השירותים מושבתות. צריך להגדיר אילו שירותים ייכללו במעקב.

יש ארבע דרכים מוגדרות מראש לבדיקת מאגר תגים באמצעות בקשה לבדיקת תקינות (probe). כל בדיקה חייבת להגדיר בדיוק אחד מארבעת המנגנונים האלה:

  • ‫exec – מריץ פקודה שצוינה בתוך הקונטיינר. הביצוע נחשב מוצלח אם קוד סטטוס היציאה הוא 0.
  • ‫grpc – מבצע קריאה לשירות מרוחק באמצעות gRPC. בדיקות gRPC הן תכונת אלפא.
  • httpGet – ביצוע בקשת GET מול כתובת ה-IP של ה-Pod ביציאה ובנתיב שצוינו. הבקשה נחשבת מוצלחת אם קוד הסטטוס גדול מ-200 או שווה לו וקטן מ-400.
  • ‫tcpSocket – מבצע בדיקת TCP מול כתובת ה-IP של ה-Pod ביציאה שצוינה. האבחון נחשב מוצלח אם הניוד פתוח.

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

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

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