Sesuaikan rencana migrasi untuk VM Linux

Sebelum menjalankan rencana migrasi, Anda harus meninjau dan menyesuaikannya secara opsional. Detail rencana migrasi 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.

Bagian 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 migrasi dan memiliki file rencana migrasi yang dihasilkan.

Mengedit paket migrasi

Anda dapat mengedit rencana migrasi menggunakan alat migctl atau konsol Google Cloud.

migctl

Anda harus mendownload paket migrasi sebelum dapat mengeditnya:

Download paket migrasi. Rencana migrasi workload Linux diwakili oleh LinuxMigrationCommonSpec:
```
migctl migration get my-migration
```
Edit paket migrasi yang didownload, my-migration.yaml, di editor teks.
Setelah pengeditan selesai, simpan dan upload rencana migrasi yang direvisi:
```
migctl migration update my-migration --main-config my-migration.yaml
```
Ulangi langkah-langkah ini jika perlu pengeditan lainnya.

Konsol

Edit rencana migrasi di Konsol Google Cloud menggunakan editor YAML. Rencana migrasi beban kerja Linux diwakili oleh CRD LinuxMigrationCommonSpec:

Buka halaman Migrate to Containers di Konsol Google Cloud.

Buka halaman Migrate to Containers.
Klik tab Migrasi untuk menampilkan tabel yang berisi migrasi yang tersedia.
Di baris untuk migrasi yang Anda inginkan, pilih Name migrasi untuk membuka tab Details.
Pilih tab YAML.

Catatan: Anda juga dapat memilih Download Rencana Migrasi untuk mendownload salinan lokal.
Edit paket migrasi seperlunya.
Setelah selesai mengedit, Anda dapat:
1. Simpan rencana migrasi. Anda kemudian harus menjalankan migrasi secara manual untuk membuat artefak migrasi. Gunakan prosedur yang ditampilkan di Menjalankan migrasi.
2. Simpan dan buat artefak. Jalankan migrasi menggunakan hasil edit Anda untuk membuat artefak migrasi. Prosesnya sama seperti yang dijelaskan dalam Menjalankan migrasi. Kemudian, Anda dapat memantau migrasi seperti yang dijelaskan di Memantau migrasi.

CRD

Anda harus mendownload rencana migrasi, mengeditnya, lalu menerapkannya. Rencana migrasi beban kerja Linux diwakili oleh CRD LinuxMigrationCommonSpec:

Dapatkan nama AppXGenerateArtifactsFlow:

kubectl get migrations.anthos-migrate.cloud.google.com -n v2k-system -o jsonpath={.status.migrationPlanRef.name} my-migration

Pola penamaan ditampilkan dalam bentuk appx-generateartifactsflow-id.

Dapatkan paket migrasi berdasarkan nama dan tulis ke file bernama my-plan.yaml:

kubectl -n v2k-system get appxgenerateartifactsflows.anthos-migrate.cloud.google.com -o jsonpath={.spec.appXGenerateArtifactsConfig} appx-generateartifactsflow-id > my-plan.yaml

Edit paket migrasi seperlunya.

Terapkan file:

kubectl patch appxgenerateartifactsflows.anthos-migrate.cloud.google.com --type merge -n v2k-system --patch '{"spec": {"appXGenerateArtifactsConfig": '"$(jq -n --rawfile plan my-plan.yaml '$plan')"'}}' appx-generateartifactsflow-id

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.

Untuk informasi selengkapnya, lihat bagian SERTAKAN/KECUALIKAN ATURAN POLA di halaman manual rsync

File yang 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 Anda pertimbangkan. 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 ini, yang mencakup contoh pengecualian serta notifikasi untuk file berukuran besar dan sparse. Ikuti panduan inline untuk:

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 mempertimbangkan untuk 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 image menentukan nama dan lokasi dua gambar yang dibuat dari VM yang dimigrasikan. Anda dapat mengubah nilai ini jika ingin menggunakan nama lain.

Selama migrasi, Migrate to Containers menyalin file dan direktori yang mewakili beban kerja migrasi Anda ke (secara default) Container Registry untuk digunakan selama migrasi. Proses migrasi menyesuaikan workload yang diekstrak ke image yang dapat dijalankan di GKE.

Migrate to Containers menyimpan file dan direktori dari VM asli (di jalur base) dalam registry. Image ini berfungsi sebagai lapisan dasar yang tidak dapat dijalankan dan mencakup file beban kerja yang diekstrak, yang kemudian digabungkan dengan lapisan software runtime Migrate to Containers untuk mem-build image container yang dapat dieksekusi.

Penggunaan lapisan terpisah menyederhanakan update berikutnya pada image container dengan mengizinkan update terpisah pada lapisan dasar atau pada lapisan software Migrate to Containers, sesuai kebutuhan.

Image ini tidak dapat dijalankan, tetapi memungkinkan Migrate to Containers mengupdate container dari versi asli saat Anda mengupgrade Migrate ke Containers.

Nilai kolom base dan name menentukan gambar yang dibuat di registry.

base -- Nama image yang dibuat dari file dan direktori VM yang disalin dari platform sumber. Image ini tidak dapat dijalankan di GKE karena belum diadaptasi untuk deployment di sana.
name -- Nama image yang dapat dijalankan yang digunakan untuk container. Gambar ini berisi konten dari VM sumber dan runtime Migrate to Containers yang memungkinkannya untuk dijalankan.

        image:
          # Review and set the name for extracted non-runnable base image,
          # if an image tag is not specified, a random tag is auto-generated when the image is built.
          base: "centos-mini-non-runnable-base"

          # Review and set the name for runnable container image,
          # if an image tag is not specified, a random tag is auto-generated when the image is built.
          name: "centos-mini"

Secara default, tag yang sesuai dengan stempel waktu migrasi otomatis diterapkan ke nilai ini. Tag ini berbentuk:

MM-DD-YYYY--hh:mm:ss

Untuk menerapkan tag Anda sendiri, ganti tag default, edit CRD dan tambahkan seperti yang ditunjukkan di bawah:

        image:
          # Review and set the name for extracted non-runnable base image,
          # if an image tag is not specified, a random tag is auto-generated when the image is built.
          base: "centos-mini-non-runnable-base:tag"

          # Review and set the name for runnable container image,
          # if an image tag is not specified, a random tag is auto-generated when the image is built.
          name: "centos-mini:tag"

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 file blocklist.yaml, file deployment_spec.yaml, dan Dockerfile yang telah diupdate.

Atau, setelah menjalankan migrasi untuk membuat artefak migrasi, Anda dapat mengedit file blocklist.yaml secara langsung, lalu mem-build ulang dan mengirim sendiri image penampung. Contoh:

Perbarui file blocklist.yaml.
Build ulang dan kirim image container.

Cara Anda membangun ulang dan mengirim image container bergantung pada lingkungan build Anda. Anda dapat menggunakan:
1. gcloud untuk mem-build ulang image dan mengirimnya ke Container Registry seperti yang dijelaskan dalam Panduan Memulai: Build.
2. docker build seperti yang dijelaskan pada Membuat dan menjalankan image Anda.
Setelah mem-build ulang dan mengirim gambar baru, buka file deployment_spec.yaml di editor untuk memperbarui lokasi gambar:
```
spec:
 containers:
   - image: new-image-location
```
Misalnya, new-image-location dapat menjadi my-new-image:v1.0 jika Anda menggunakan gcloud untuk mem-build ulang image dan mengirimnya ke Container Registry.

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 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.

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.

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.

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.

v2kServiceManager: true
deployment:
  probes:
    livenessProbe:
      exec:
        command:
        - gamma
        - /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.

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.