Halaman ini diterjemahkan oleh Cloud Translation API.

Memigrasikan node ke containerd 2

Autopilot Standard

Cluster Google Kubernetes Engine (GKE) menggunakan image node containerd dengan semua node pekerja yang menjalankan versi 1.24 dan yang lebih baru. Node pekerja menggunakan versi containerd tertentu, berdasarkan versi GKE:

Node yang menjalankan GKE 1.32 atau yang lebih lama, dengan image node containerd, menggunakan containerd 1.7 atau versi sebelumnya.
Node yang menjalankan GKE 1.33 menggunakan containerd 2.0.

Saat node GKE diupgrade dari 1.32 ke 1.33, node akan bermigrasi dari penggunaan containerd 1.7 ke versi utama baru, containerd 2.0. Anda tidak dapat mengubah versi containerd yang digunakan versi GKE.

Anda dapat melewati halaman ini jika mengetahui bahwa workload Anda berjalan seperti yang diharapkan di containerd 2.

Cara GKE melakukan transisi ke containerd 2

Tinjau linimasa berikut untuk memahami cara GKE mentransisikan cluster yang ada untuk menggunakan containerd 2:

Dengan versi minor 1.32, GKE menggunakan containerd 1.7. containerd 1.7 tidak lagi menggunakan image Docker Schema 1 dan Container Runtime Interface (CRI) v1alpha2 API. Untuk mempelajari fitur lain yang tidak digunakan lagi di versi sebelumnya, lihat Properti konfigurasi yang tidak digunakan lagi.
Dengan versi minor 1.33, GKE menggunakan containerd 2.0, yang menghapus dukungan untuk image Docker Schema 1 dan CRI v1alpha2 API.
Properti konfigurasi containerd berikut di plugin CRI tidak digunakan lagi dan akan dihapus di containerd 2.1, dengan versi GKE yang belum diumumkan: registry.auths, registry.configs, registry.mirrors.

Untuk perkiraan waktu upgrade otomatis ke versi minor yang lebih baru seperti 1.33, lihat Perkiraan jadwal untuk saluran rilis.

Dampak transisi ke containerd 2

Baca bagian berikut untuk memahami dampak transisi ini ke containerd 2.

Upgrade otomatis dijeda

GKE menjeda upgrade otomatis ke 1.33 saat mendeteksi bahwa cluster menggunakan fitur yang tidak digunakan lagi. Namun, jika node cluster Anda menggunakan fitur ini, sebaiknya buat pengecualian pemeliharaan untuk mencegah upgrade node. Pengecualian pemeliharaan memastikan bahwa node Anda tidak diupgrade jika GKE tidak mendeteksi penggunaan.

Setelah Anda bermigrasi dari penggunaan fitur ini, jika 1.33 adalah target upgrade otomatis untuk node cluster Anda dan tidak ada faktor lain yang memblokir upgrade otomatis, GKE akan melanjutkan upgrade minor otomatis ke 1.33. Untuk node pool cluster Standard, Anda juga dapat mengupgrade node pool secara manual.

Akhir dukungan dan dampak dari kegagalan dalam menyiapkan migrasi

GKE menjeda upgrade otomatis hingga akhir dukungan standar. Jika cluster Anda terdaftar di saluran Extended, node Anda dapat tetap menggunakan versi tersebut hingga akhir dukungan extended. Untuk mengetahui detail selengkapnya tentang upgrade node otomatis di akhir dukungan, lihat Upgrade otomatis di akhir dukungan.

Jika tidak bermigrasi dari fitur ini, saat 1.32 mencapai akhir dukungan, dan node cluster Anda otomatis diupgrade ke 1.33, Anda dapat mengalami masalah berikut pada cluster:

Workload yang menggunakan image Docker Schema 1 gagal.
Aplikasi yang memanggil CRI v1alpha2 API mengalami kegagalan saat memanggil API.

Mengidentifikasi cluster yang terpengaruh

GKE memantau cluster Anda dan menggunakan layanan Recommender untuk memberikan panduan melalui insight dan rekomendasi untuk mengidentifikasi node cluster yang menggunakan fitur yang tidak digunakan lagi ini.

Persyaratan versi

Cluster menerima insight dan rekomendasi ini jika menjalankan versi berikut atau yang lebih baru:

1.28.15-gke.1159000
1.29.9-gke.1541000
1.30.5-gke.1355000
1.31.1-gke.1621000

Mendapatkan insight dan rekomendasi

Ikuti petunjuk untuk melihat insight dan rekomendasi. Anda bisa mendapatkan insight menggunakan konsol Google Cloud. Anda juga dapat menggunakan Google Cloud CLI atau Recommender API, dengan memfilter menggunakan subjenis berikut:

DEPRECATION_CONTAINERD_V1_SCHEMA_IMAGES: Image Docker Schema 1

Bermigrasi dari fitur yang tidak digunakan lagi

Tinjau konten berikut untuk memahami cara bermigrasi dari fitur yang tidak digunakan lagi dengan containerd 2.

Bermigrasi dari image Docker Schema 1

Identifikasi workload menggunakan image yang harus dimigrasikan, lalu migrasikan workload tersebut.

Menemukan gambar yang akan dimigrasikan

Anda dapat menggunakan berbagai alat untuk menemukan gambar yang harus dimigrasikan.

Menggunakan insight dan rekomendasi atau Cloud Logging

Seperti yang dijelaskan di bagian Mengidentifikasi cluster yang terpengaruh, Anda dapat menggunakan insight dan rekomendasi untuk menemukan cluster yang menggunakan image Docker Schema 1 jika cluster Anda menjalankan versi minimum atau yang lebih baru. Selain itu, Anda dapat menggunakan kueri berikut di Cloud Logging untuk memeriksa log containerd guna menemukan image Docker Schema 1 di cluster Anda:

jsonPayload.SYSLOG_IDENTIFIER="containerd"
"conversion from schema 1 images is deprecated"

Jika lebih dari 30 hari telah berlalu sejak gambar diambil, Anda mungkin tidak melihat log untuk gambar.

Menggunakan perintah `ctr` langsung di node

Untuk membuat kueri node tertentu guna menampilkan semua image yang tidak dihapus yang diambil sebagai Skema 1, jalankan perintah berikut di node:

  ctr --namespace k8s.io images list 'labels."io.containerd.image/converted-docker-schema1"'

Perintah ini dapat berguna jika, misalnya, Anda memecahkan masalah node tertentu dan tidak melihat entri log di Cloud Logging karena sudah lebih dari 30 hari sejak gambar diambil.

Menggunakan alat open source `crane`

Anda juga dapat menggunakan alat open source seperti crane untuk memeriksa gambar.

Jalankan perintah crane berikut untuk memeriksa versi skema untuk image:

crane manifest $tagged_image | jq .schemaVersion

Menyiapkan workload

Untuk menyiapkan workload yang menjalankan image Docker Schema 1, Anda harus memigrasikan workload tersebut ke image Docker Schema 2, atau image Open Container Initiative (OCI). Pertimbangkan opsi berikut untuk melakukan migrasi:

Menemukan image pengganti: Anda mungkin dapat menemukan image open source atau image yang disediakan vendor yang tersedia secara publik.
Konversi gambar yang ada: jika tidak dapat menemukan gambar pengganti, Anda dapat mengonversi image Docker Schema 1 yang ada menjadi image OCI dengan langkah-langkah berikut:
1. Ambil image Docker ke containerd, yang akan otomatis mengonversinya menjadi image OCI.
2. Kirim image OCI baru ke registry Anda.

Bermigrasi dari CRI v1alpha2 API

CRI v1alpha2 API dihapus di Kubernetes 1.26. Anda harus mengidentifikasi workload yang mengakses soket containerd dan mengupdate aplikasi ini untuk menggunakan API v1.

Mengidentifikasi workload

Anda dapat menggunakan berbagai teknik untuk mengidentifikasi beban kerja yang harus dimigrasikan.

Menggunakan kubectl

Perintah berikut membantu Anda menemukan beban kerja yang mengakses socket containerd. Perintah ini menampilkan beban kerja yang memasang direktori hostPath yang menyertakan soket. Kueri ini dapat menyebabkan positif palsu karena beberapa beban kerja memasang direktori ini atau direktori turunan lainnya, tetapi tidak mengakses soket containerd.

Jalankan perintah berikut:

kubectl get pods --all-namespaces -o json |
jq -r '.items[] |
  select(.spec.volumes[]?.hostPath.path as $p |
    ["/", "/var", "/var/","/var/run", "/var/run/",
     "/var/run/containerd", "/var/run/containerd/",
     "/var/run/containerd/containerd.sock",
     "/run", "/run/", "/run/containerd", "/run/containerd/",
     "/run/containerd/containerd.sock"] | index($p)) |
  .metadata.namespace + "/" + .metadata.name'

Memeriksa kode aplikasi

Anda dapat memeriksa kode aplikasi untuk melihat apakah kode tersebut mengimpor library klien API CRI v1alpha2.

Misalnya, lihat kode golang berikut:

  package main

  import (
    ...

    runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"
  )

  func foo() {
    ...

    client := runtimeapi.NewRuntimeServiceClient(conn)
    version, err := client.Version(ctx, &runtimeapi.VersionRequest{})

    ...
  }

Di sini, aplikasi mengimpor library v1alpha2 dan menggunakannya untuk menerbitkan RPC. Jika RPC menggunakan koneksi ke soket containerd, aplikasi ini akan menyebabkan GKE menjeda upgrade otomatis untuk cluster.

Lakukan langkah-langkah berikut untuk menelusuri dan memperbarui kode aplikasi Anda:

Identifikasi aplikasi golang yang bermasalah dengan menjalankan perintah berikut untuk menelusuri jalur impor v1alpha2:
```
  grep -r "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"
```
Jika output perintah ini menunjukkan bahwa library v1alpha2 digunakan dalam file, Anda harus mengupdate file tersebut.

Misalnya, ganti kode aplikasi berikut:
```
  runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"
```

Perbarui kode untuk menggunakan v1:

  runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1"