Sesuaikan rencana migrasi untuk VM Linux

Sebelum menjalankan rencana migrasi, Anda harus meninjau dan menyesuaikannya secara opsional. Detail rencana migrasi Anda digunakan untuk mengekstrak artefak container beban kerja dari VM sumber, dan juga untuk menghasilkan file deployment Kubernetes yang dapat digunakan untuk men-deploy image container ke cluster lain, seperti cluster produksi.

Halaman ini menjelaskan konten rencana migrasi dan jenis penyesuaian yang dapat Anda pertimbangkan sebelum menjalankan migrasi dan membuat artefak deployment.

Sebelum memulai

Topik ini mengasumsikan bahwa Anda telah membuat rencana migrasi dan memiliki file rencana migrasi yang dihasilkan.

Mengedit paket migrasi

Setelah menyalin sistem file dan menganalisisnya, Anda dapat menemukan paket migrasi di direktori baru yang dibuat di jalur output yang ditentukan: ANALYSIS_OUTPUT_PATH/config.yaml.

Edit rencana migrasi seperlunya dan simpan perubahannya.

Tinjau detail paket migrasi dan panduan komentar untuk menambahkan informasi sesuai kebutuhan. Secara khusus, pertimbangkan untuk mengedit bagian berikut.

Tentukan konten yang akan dikecualikan dari migrasi

Secara default, Migrate to Containers mengecualikan konten VM standar yang tidak relevan dengan konteks GKE. Anda dapat menyesuaikan filter tersebut.

Nilai kolom filters mencantumkan jalur yang harus dikecualikan dari migrasi dan tidak akan menjadi bagian dari image penampung. Nilai kolom mencantumkan aturan filter rsync yang menentukan file yang akan ditransfer dan file yang akan dilewati. Mendahului setiap jalur dan file dengan tanda minus menentukan bahwa item dalam daftar harus dikecualikan dari migrasi. Daftar ini diproses sesuai dengan urutan baris dalam YAML, dan pengecualian/penyertaan dievaluasi sebagaimana mestinya.

Pelajari aturan filter rsync lebih lanjut.

File yang berukuran terlalu besar untuk disertakan dalam image Docker akan dicantumkan dalam file YAML. Tindakan ini akan menandai file yang berukuran lebih besar dari 1 GB untuk dipertimbangkan. Image Docker yang berukuran terlalu besar atau lebih dari 15 GB berisiko gagal selama migrasi.

Anda dapat mengedit daftar YAML untuk menambahkan atau menghapus jalur. Lihat contoh YAML di bawah ini, yang mencakup contoh pengecualian, serta notifikasi untuk file berukuran besar dan sparse. Ikuti panduan inline untuk melakukan salah satu tindakan berikut:

• Kecualikan folder yang terdeteksi dengan menghapus tanda komentar dan menempatkannya di bagian filter global.
• Pindahkan folder yang terdeteksi ke volume persisten dengan menghapus tanda komentar dan menempatkannya di bagian folder data.

Anda juga dapat mengecualikan atau memindahkan file sparse yang terdeteksi dengan cara yang sama.

  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)

Menetapkan nama image container

Nilai kolom name di bagian image menentukan nama image yang dibuat dari VM yang dimigrasikan yang digunakan untuk penampung. Anda dapat mengubah nilai ini jika lebih suka menggunakan nama yang berbeda.

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

Menyesuaikan daftar layanan

Secara default, Migrate to Containers menonaktifkan layanan yang tidak diperlukan pada VM saat Anda memigrasikannya ke container. Layanan ini terkadang dapat menyebabkan masalah dengan penampung yang dimigrasikan, atau tidak diperlukan dalam konteks penampung.

Bersama dengan layanan yang dinonaktifkan secara otomatis oleh Migrate to Containers, Anda dapat menonaktifkan layanan lainnya secara opsional:

• Migrate to Containers secara otomatis menemukan layanan yang dapat Anda nonaktifkan secara opsional, dan mencantumkannya dalam rencana migrasi. Layanan ini, seperti ssh atau server web, mungkin tidak diperlukan dalam beban kerja yang dimigrasikan, tetapi Anda bebas membuat keputusan tersebut. Jika perlu, edit rencana migrasi untuk menonaktifkan layanan ini.

• Migrate to Containers tidak mencantumkan semua layanan yang berjalan di VM sumber. Misalnya, kebijakan ini menghilangkan layanan terkait sistem operasi. Jika ingin, Anda dapat mengedit rencana migrasi untuk menambahkan daftar layanan Anda sendiri yang akan dinonaktifkan di penampung yang dimigrasikan.

Kolom systemServices menentukan daftar layanan yang ditemukan oleh Migrate to Containers. Contoh:

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

Untuk menonaktifkan layanan, tetapkan enabled ke false.

Migrate to Containers tidak mencantumkan semua layanan yang berjalan di VM sumber, seperti layanan terkait sistem operasi. Anda juga dapat menambahkan layanan tambahan ke daftar tersebut. Misalnya, untuk menonaktifkan service2 dan layanan cron:

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

Saat Anda menjalankan migrasi untuk membuat artefak migrasi, Migrate to Containers akan membuat file blocklist.yaml. File ini mencantumkan layanan penampung yang akan dinonaktifkan berdasarkan setelan Anda dalam rencana migrasi. Contoh:

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

Untuk mengubah daftar layanan yang dinonaktifkan di lain waktu:

• Edit daftar layanan di paket migrasi.
• Jalankan migrasi untuk membuat ulang artefak migrasi, termasuk blocklist.yaml yang telah diupdate.

Atau, setelah menjalankan migrasi untuk menghasilkan artefak migrasi, Anda dapat mengedit file blocklist.yaml secara langsung, lalu mem-build dan men-deploy image container menggunakan Skaffold.

Menyesuaikan endpoint layanan

Rencana migrasi mencakup array endpoints yang menentukan port dan protokol yang digunakan untuk membuat Layanan Kubernetes yang disediakan oleh beban kerja yang dimigrasikan. Anda dapat menambahkan, mengedit, atau menghapus definisi endpoint untuk menyesuaikan rencana migrasi.

Untuk mengambil port endpoint, periksa program yang memproses port:

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

Untuk setiap endpoint Layanan, tambahkan definisi berikut ke paket migrasi:

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

Dengan keterangan:

• PORT_NUMBER menentukan nomor port container yang menjadi tujuan perutean permintaan ke layanan.
• PORT_PROTOCOL menentukan protokol port, seperti HTTP, HTTPS, atau TCP. Lihat Protokol yang didukung untuk daftar lengkap protokol.
• PORT_NAME menentukan nama yang digunakan untuk mengakses endpoint Layanan. Migrate to Containers menghasilkan PORT_NAME unik untuk setiap definisi endpoint yang dibuat.

Misalnya, Migrate to Containers mendeteksi endpoint berikut:

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

Untuk menetapkan nilai properti name, Migrate to Containers menggabungkan nama VM sumber, backend-server dalam contoh ini, dengan nama program Layanan. Nama yang dihasilkan kompatibel dengan konvensi penamaan Kubernetes, dan bersifat unik dalam rencana migrasi. Misalnya, rencana migrasi di atas membuat Layanan yang menargetkan Nginx di port 80 melalui HTTP.

Untuk nama duplikat, Migrate to Containers akan menambahkan akhiran penghitung. Misalnya, jika Nginx dikaitkan dengan dua port, Nginx akan menambahkan akhiran -2 ke name pada definisi kedua:

  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

Saat Anda menjalankan migrasi untuk membuat artefak migrasi, Migrate to Containers akan membuat definisi Service di file deployment_spec.yaml untuk setiap endpoint.

Misalnya, yang ditampilkan di bawah ini adalah definisi Service dalam file 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: {}

Sesuaikan dudukan NFS

Migrate to Containers menyertakan pemasangan NFS dalam rencana migrasi yang dibuat. Informasi ini dikumpulkan dari file fstab dan ditulis ke array nfsMounts dalam rencana migrasi. Anda dapat menambahkan atau mengedit definisi titik pemasangan NFS untuk menyesuaikan rencana migrasi.

Catatan: Entri dalam array nfsMounts dinonaktifkan secara default. Anda harus mengaktifkannya jika ingin Migrate to Containers membuat entri dalam file deployment_spec.yaml untuk setiap pemasangan NFS.

Saat membuat rencana migrasi, Migrate to Containers:

• Mengabaikan mount NFS untuk /sys dan /dev.
• Mengabaikan mount NFS dengan jenis selain nfs atau nfs4.

Setiap pemasangan NFS dalam rencana migrasi menyertakan alamat IP server dan jalur pemasangan lokal dalam format:

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

Dengan keterangan:

• MOUNT_POINT menentukan direktori pemasangan yang diperoleh dari fstab.
• DIR_NAME menentukan nama direktori bersama.
• IP menentukan alamat IP server yang menghosting direktori pemasangan.
• OPTION_N menentukan opsi apa pun yang diekstrak dari fstab untuk titik pemasangan.

Misalnya, untuk entri berikut di fstab:

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

Migrate to Containers menghasilkan entri berikut dalam rencana migrasi:

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

Untuk mengonfigurasi Migrate to Containers agar dapat memproses entri dalam array nfsMounts, tetapkan enabled ke true untuk entri mountPoint. Anda dapat mengaktifkan satu, beberapa, atau semua entri mountPoints, mengedit entri, atau menambahkan entri Anda sendiri.

Saat Anda menjalankan migrasi untuk menghasilkan artefak migrasi, Migrate to Containers akan membuat definisi volumes dan volumeMounts serta definisi PersistentVolume dan PersistentVolumeClaim di file deployment_spec.yaml untuk setiap pemasangan NFS yang diaktifkan.

Catatan: Migrate to Containers mengharuskan server NFS dapat diakses dari cluster deployment yang menghosting beban kerja container yang dimigrasikan. Namun, Migrate to Containers tidak memvalidasi konektivitas tersebut. Penampung yang dimigrasikan dengan masalah konektivitas tidak dapat dimulai dan Anda mungkin harus mengedit file deployment_spec.yaml untuk memperbaiki masalah. Lihat Mengakses instance Filestore dengan driver Filestore CSI untuk informasi selengkapnya.

Misalnya, yang ditampilkan di bawah ini adalah definisi volumeMounts dalam file 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

Dengan nilai name adalah ID unik yang dihasilkan oleh Migrate to Containers.

Berikut adalah contoh definisi PersistentVolumeClaim dan PersistentVolume dalam file 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

Menyesuaikan data log yang ditulis ke Cloud Logging

Biasanya, VM sumber menulis informasi ke satu atau beberapa file log. Sebagai bagian dari migrasi VM, Anda dapat mengonfigurasi beban kerja yang dimigrasikan untuk menulis informasi log tersebut ke Cloud Logging.

Catatan: Rilis Migrate to Containers sebelumnya mendukung penyesuaian logging menggunakan ConfigMap pada cluster beban kerja target Anda, seperti yang dijelaskan dalam Mengonfigurasi logging ke Cloud Logging. Bagian ini menjelaskan cara menggunakan file logs.yaml untuk mengonfigurasi logging. Jika file logs.yaml ada, setelan logging yang ditentukan oleh ConfigMap akan diabaikan.

Saat Anda membuat rencana migrasi, Migrate to Containers akan otomatis menelusuri file tujuan log di VM sumber. Migrate to Containers lalu menulis informasi tentang file yang terdeteksi tersebut ke area logPaths dalam rencana migrasi:

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

Contoh:

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

Saat Anda membuat artefak migrasi, Migrate to Containers akan membuat file logs.yaml dari rencana migrasi. File ini berisi daftar file log yang terdeteksi di VM sumber. Misalnya, dari definisi logsPath di atas, logs.yaml berisi:

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

Dalam contoh ini, saat Anda men-deploy beban kerja yang dimigrasikan, informasi log yang ditulis ke catalina.out akan otomatis ditulis ke Cloud Logging.

Setiap entri muncul pada baris dalam log dengan format berikut:

DATE TIME APP_NAME LOG_OUTPUT

Contoh berikut mengilustrasikan formulir dengan entri dari Tomcat:

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

Untuk mengonfigurasi logging, Anda dapat:

• Edit rencana migrasi sebelum Anda membuat artefak migrasi untuk menambahkan, menghapus, atau mengedit entri logPaths. Saat Anda membuat artefak migrasi, hasil edit ini akan tercermin dalam file logs.yaml.

• Edit logs.yaml setelah Anda membuat artefak migrasi untuk menambahkan, menghapus, atau mengedit entri logs.

Keuntungan dari mengedit rencana migrasi adalah hasil edit Anda tercermin dalam logs.yaml setiap kali Anda membuat artefak. Jika Anda mengedit logs.yaml secara langsung, lalu membuat ulang artefak karena alasan tertentu, Anda harus menerapkan kembali hasil edit ke logs.yaml.

Menyetel pemeriksaan kesehatan v2kServiceManager Linux

Anda dapat memantau periode nonaktif dan status siap container terkelola dengan menentukan pemeriksaan dalam rencana migrasi server web Tomcat Anda. Pemantauan pemeriksaan kesehatan dapat membantu mengurangi periode nonaktif container yang dimigrasikan dan memberikan pemantauan yang lebih baik.

Status kesehatan yang tidak diketahui dapat menyebabkan penurunan ketersediaan, pemantauan ketersediaan positif palsu, dan potensi hilangnya data. Tanpa pemeriksaan kesehatan, kubelet hanya dapat mengasumsikan kondisi container dan dapat mengirim traffic ke instance container yang belum siap. Tindakan ini dapat menyebabkan kehilangan traffic. Kubelet mungkin juga tidak mendeteksi container yang berada dalam status frozen dan tidak akan memulai ulang container.

Pemeriksaan kesehatan berfungsi dengan menjalankan pernyataan berskrip kecil saat penampung dimulai. Skrip akan memeriksa kondisi yang berhasil, yang ditentukan oleh jenis pemeriksaan yang digunakan, setiap periode. Periode ditentukan dalam rencana migrasi oleh kolom periodSeconds. Anda dapat menjalankan atau menentukan skrip ini secara manual.

Untuk mempelajari lebih lanjut pemeriksaan kubelet, lihat Mengonfigurasi Pemeriksaan Keaktifan, Kesiapan, dan Startup dalam dokumentasi Kubernetes.

Ada dua jenis probe yang dapat dikonfigurasi, kedua probe adalah probe-v1-core yang ditentukan dalam referensi probe-v1-core dan memiliki fungsi yang sama dengan kolom container-v1-core yang sesuai

• Pemeriksaan kehidupan - Pemeriksaan keaktifan digunakan untuk mengetahui kapan harus memulai ulang penampung.
  Catatan: Jika proses dalam penampung Anda dapat error dengan sendirinya saat mengalami masalah, atau menjadi tidak responsif, Anda tidak memerlukan pemeriksaan keaktifan. Kubelet akan otomatis melakukan tindakan yang benar sesuai dengan restartPolicy Pod.
• Pemeriksaan kesiapan - Pemeriksaan kesiapan digunakan untuk mengetahui kapan container siap untuk mulai menerima traffic. Untuk mulai mengirim traffic ke Pod hanya ketika pemeriksaan berhasil, tentukan kesiapan. Pemeriksaan kesiapan mungkin berfungsi mirip dengan pemeriksaan keaktifan, tetapi pemeriksaan kesiapan dalam spesifikasi menunjukkan bahwa Pod akan dimulai tanpa menerima traffic dan hanya mulai menerima traffic setelah pemeriksaan berhasil.

Setelah ditemukan, konfigurasi pemeriksaan ditambahkan ke paket migrasi. Probe ini dapat digunakan dalam konfigurasi default seperti yang ditunjukkan di bawah ini. Untuk menonaktifkan pemeriksaan, hapus bagian probes dari 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

Secara default, semua pemeriksaan layanan dinonaktifkan. Anda harus menentukan subset layanan mana yang akan dipantau.

Catatan: Tidak semua layanan mendukung pemeriksaan dan dapat menyebabkan container gagal dimulai.

Ada empat cara yang telah ditentukan untuk memeriksa container menggunakan probe. Setiap pemeriksaan harus menentukan dengan tepat salah satu dari empat mekanisme ini:

• exec - Menjalankan perintah yang ditentukan di dalam container. Eksekusi dianggap berhasil jika kode status keluar adalah 0.
• grpc - Melakukan panggilan prosedur jarak jauh menggunakan `gRPC`. Pemeriksaan `gRPC` adalah fitur alfa.
• httpGet - Melakukan permintaan GET HTTP terhadap alamat IP Pod di port dan jalur yang ditentukan. Permintaan dianggap berhasil jika kode status lebih besar dari atau sama dengan 200 dan kurang dari 400.
• tcpSocket - Melakukan pemeriksaan TCP terhadap alamat IP Pod pada port yang ditentukan. Diagnostik dianggap berhasil jika port terbuka.

Secara default, rencana migrasi mengaktifkan metode pemeriksaan exec. Gunakan konfigurasi manual untuk paket migrasi Anda guna mengaktifkan metode lain.

Guna menambahkan dependensi eksternal untuk pemeriksaan kesiapan, saat menggunakan pemeriksaan keaktifan default, tentukan pemeriksaan kesiapan eksekutif dan skrip yang menerapkan logika.

Langkah selanjutnya

• Pelajari cara menjalankan migrasi.