Menyesuaikan paket migrasi untuk VM Linux

Sebelum menjalankan rencana migrasi, Anda harus meninjau dan menyesuaikannya secara opsional. Detail rencana migrasi Anda digunakan untuk mengekstrak artefak penampung workload dari VM sumber, dan juga untuk membuat file deployment Kubernetes yang dapat Anda gunakan untuk men-deploy image penampung 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 rencana migrasi

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

Edit rencana migrasi sesuai kebutuhan dan simpan perubahan.

Tinjau detail rencana migrasi dan komentar panduan untuk menambahkan informasi sesuai kebutuhan. Secara khusus, pertimbangkan pengeditan di sekitar bagian berikut.

Menentukan konten yang akan dikecualikan dari migrasi

Secara default, Migrate to Containers mengecualikan konten VM standar yang tidak relevan dalam 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 mana yang akan ditransfer dan file mana yang akan dilewati. Mendahului setiap jalur dan file dengan tanda minus menentukan bahwa item dalam daftar harus dikecualikan dari migrasi. Daftar diproses sesuai dengan urutan baris dalam YAML, dan pengecualian/penyertaan dievaluasi sebagaimana mestinya.

Pelajari lebih lanjut aturan filter rsync.

File yang terlalu besar untuk disertakan dalam image Docker dicantumkan dalam file YAML. Tindakan ini akan menandai file yang lebih besar dari 1 GB untuk pertimbangan Anda. Image Docker yang 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, yang menyertakan contoh pengecualian, serta notifikasi untuk file besar dan jarang. Ikuti panduan inline untuk melakukan salah satu tindakan berikut:

• Kecualikan folder yang terdeteksi dengan menghapus 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 jarang 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 lain.

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 di VM saat Anda memigrasikannya ke penampung. Layanan ini terkadang dapat menyebabkan masalah pada penampung yang dimigrasikan, atau tidak diperlukan dalam konteks penampung.

Selain layanan yang dinonaktifkan secara otomatis oleh Migrate to Containers, Anda dapat menonaktifkan layanan lain secara opsional:

• Migrate to Containers akan 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 yang memutuskannya. Jika perlu, edit rencana migrasi untuk menonaktifkan layanan ini.

• Migrate to Containers tidak mencantumkan semua layanan yang berjalan di VM sumber. Misalnya, layanan terkait sistem operasi dihilangkan. Secara opsional, 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. 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 nanti:

• Edit daftar layanan dalam rencana migrasi.
• Jalankan migrasi untuk membuat ulang artefak migrasi, termasuk blocklist.yaml yang diperbarui.

Atau, setelah menjalankan migrasi untuk membuat 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 workload yang dimigrasikan. Anda dapat menambahkan, mengedit, atau menghapus definisi endpoint untuk menyesuaikan rencana migrasi.

Untuk mengambil port endpoint, periksa program yang sedang memproses port:

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

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

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

Dengan keterangan:

• PORT_NUMBER menentukan nomor port penampung tempat permintaan ke layanan dirutekan.
• PORT_PROTOCOL menentukan protokol port, seperti HTTP, HTTPS, atau TCP. Lihat Protokol yang didukung untuk mengetahui 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 dihasilkan.

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 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 dalam 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 Layanan dalam file deployment_spec.yaml untuk setiap endpoint.

Misalnya, yang ditampilkan di bawah 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: {}

Menyesuaikan pemasangan NFS

Migrate to Containers menyertakan pemasangan NFS dalam rencana migrasi yang dihasilkan. 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 pemasangan NFS untuk /sys dan /dev.
• Mengabaikan pemasangan NFS dengan jenis selain nfs atau nfs4.

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

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

Dengan keterangan:

• MOUNT_POINT menentukan titik pemasangan yang diperoleh dari fstab.
• DIR_NAME menentukan nama direktori bersama.
• IP menentukan alamat IP server yang menghosting titik 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 guna 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 membuat artefak migrasi, Migrasi ke Penampung akan membuat definisi volume dan volumeMounts serta definisi PersistentVolume dan PersistentVolumeClaim dalam file deployment_spec.yaml untuk setiap pemasangan NFS yang diaktifkan.

Catatan: Migrate to Containers mengharuskan server NFS dapat diakses dari cluster deployment yang menghosting workload penampung 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 tersebut. Lihat Mengakses instance Filestore dengan driver CSI Filestore untuk mengetahui informasi selengkapnya.

Misalnya, yang ditampilkan di bawah 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 Migrasi ke Penampung.

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 di cluster workload 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 kemudian 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 di baris dalam log dalam bentuk 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, pengeditan ini akan tercermin dalam file logs.yaml.

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

Keuntungan mengedit rencana migrasi adalah hasil edit Anda akan 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 ulang hasil edit ke logs.yaml.

Menetapkan pemeriksaan kesehatan v2kServiceManager Linux

Anda dapat memantau periode nonaktif dan status siap penampung terkelola dengan menentukan probe di rencana migrasi server web Tomcat. Pemantauan probe 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 kehilangan data. Tanpa pemeriksaan kondisi, kubelet hanya dapat mengasumsikan kondisi container dan dapat mengirim traffic ke instance container yang belum siap. Hal ini dapat menyebabkan hilangnya traffic. Kubelet mungkin juga tidak mendeteksi penampung yang dalam status beku dan tidak akan memulai ulang penampung tersebut.

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

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

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

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

Setelah penemuan, konfigurasi probe ditambahkan ke rencana migrasi. Probe dapat digunakan dalam konfigurasi defaultnya seperti yang ditunjukkan di bawah. Untuk menonaktifkan probe, 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 penampung gagal dimulai.

Ada empat cara standar untuk memeriksa penampung menggunakan probe. Setiap probe harus menentukan salah satu dari empat mekanisme ini secara tepat:

• exec - Menjalankan perintah yang ditentukan di dalam penampung. 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 HTTP GET 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 di port yang ditentukan. Diagnostik dianggap berhasil jika port terbuka.

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

Untuk menambahkan dependensi eksternal untuk probe kesiapan, saat menggunakan probe keaktifan default, tentukan probe kesiapan exec dan skrip yang menerapkan logika.

Langkah selanjutnya

• Pelajari cara menjalankan migrasi.