Konsep Deployment Workload Kubernetes & Masalah Umum - ACK

Topik ini menjelaskan masalah umum dan solusinya untuk men-deploy workload di kluster ACK.

Bagaimana cara men-deploy aplikasi terkontainerisasi di kluster ACK?

Anda dapat men-deploy kode aplikasi secara on-premises atau di cloud. Kode yang ditulis dalam bahasa apa pun dapat dikontainerisasi untuk deployment, delivery, dan operasional. Proses menjalankan aplikasi terkontainerisasi melibatkan empat fase utama.

Tulis kode bisnis.
Gunakan Dockerfile untuk membangun container image.
Perluas untuk melihat konsep terkait
- Dockerfile: File teks yang berisi instruksi yang diperlukan untuk mengemas kode ke dalam image. Untuk informasi selengkapnya, lihat Build, Package, and Run Images Using a Dockerfile.
- Image: Paket distribusi perangkat lunak. Dibandingkan dengan paket tradisional seperti file JAR, WAR, dan RPM, sebuah image mencakup dependensi aplikasi (semua file yang diperlukan untuk runtime kontainer) selain kode itu sendiri. Anda dapat menggunakan image untuk membuat kontainer secara cepat, yaitu aplikasi yang sedang berjalan.
- Kontainer: Sekumpulan proses terisolasi dengan isolasi tampilan, batasan resource, dan sistem file independen. ACK mengelola seluruh siklus hidup semua aplikasi terkontainerisasi secara efisien. Misalnya, Anda dapat menjadwalkan Pod tertentu ke node yang ditentukan atau melakukan scaling out saat beban bisnis meningkat.
Unggah image ke repository image. Anda dapat menggunakan Container Registry (ACR) untuk menyimpan, mengelola, mendistribusikan, dan menarik image.

ACR menyediakan Edisi Personal untuk pengembang individu dan Edisi Perusahaan untuk pelanggan enterprise. Untuk informasi selengkapnya, lihat Apa itu Container Registry ACR.
Deploy workload di kluster ACK untuk menjalankan aplikasi terkontainerisasi dan gunakan berbagai kemampuan manajemen aplikasi yang disediakan oleh ACK. Untuk informasi selengkapnya, lihat Workload.

Mengapa proses pull image terlalu lama atau gagal?

Gejala

Kontainer memerlukan waktu yang sangat lama untuk menarik image atau gagal menariknya.

Penyebab

Masalah ini dapat disebabkan oleh alasan berikut:

Saat Anda menarik image melalui jaringan publik, kluster mungkin tidak memiliki akses jaringan publik, atau bandwidth IP publik terlalu rendah.
Saat Anda menarik image dari ACR, secret image mungkin salah, atau komponen tanpa password salah dikonfigurasi.

Solusi

Untuk menarik image melalui jaringan publik, baik kluster maupun repository image harus memiliki akses jaringan publik. Untuk informasi selengkapnya, lihat Aktifkan akses jaringan publik untuk kluster. Untuk contoh ACR, lihat Konfigurasikan kontrol akses jaringan publik untuk ACR.
Untuk informasi tentang cara mengonfigurasi komponen tanpa kata sandi, lihat Menarik Image dari Akun yang Sama dan Menarik Image Lintas Akun.
Untuk informasi lebih lanjut tentang cara menggunakan image pull secret, lihat Bagaimana cara menggunakan imagePullSecrets?.

Bagaimana cara memecahkan masalah aplikasi di ACK?

Kegagalan aplikasi di ACK terutama disebabkan oleh masalah pada Pod, controller (seperti Deployment, StatefulSet, atau DaemonSet), dan Service. Anda dapat memeriksa jenis masalah berikut.

Periksa Pod

Untuk informasi lebih lanjut tentang cara memecahkan masalah anomali Pod, lihat Troubleshoot pod anomalies.

Periksa Penyebaran

Masalah Pod dapat muncul saat Anda membuat controller seperti Deployments, DaemonSets, StatefulSets, dan Jobs. Untuk informasi selengkapnya, lihat Troubleshoot pod anomalies.
Anda dapat mengidentifikasi masalah dengan memeriksa event dan log terkait Deployment:

Topik ini menggunakan Deployment sebagai contoh. Proses melihat event dan log di DaemonSets, StatefulSets, atau Jobs serupa.
1. Masuk ke ACK console. Di panel navigasi kiri, klik Clusters.
2. Pada halaman Clusters, temukan kluster yang ingin Anda kelola dan klik namanya. Di panel navigasi kiri, pilih Workloads > Deployments.
3. Pada halaman Deployments, klik nama Deployment yang dituju. Lalu, klik Events atau Logs untuk mengidentifikasi masalah berdasarkan informasi pengecualian.

Periksa Layanan

Service menyediakan load balancing untuk sekelompok Pod. Bagian berikut menjelaskan cara mengidentifikasi masalah umum terkait Service:

Periksa Endpoint Service.
Dapatkan file kubeconfig kluster dan gunakan kubectl untuk terhubung ke kluster.
Jalankan perintah berikut untuk melihat Endpoint Service.

Pada perintah berikut, ganti <service_name> dengan nama Service yang dituju.
```
kubectl get endpoints <service_name>
```
Pastikan jumlah alamat dalam nilai ENDPOINTS sesuai dengan jumlah Pod yang diharapkan untuk Service tersebut. Misalnya, jika Deployment memiliki tiga replika, nilai ENDPOINTS harus berisi tiga alamat.

Endpoint Service Hilang

Jika Service tidak memiliki alamat Endpoint, Anda dapat mengkueri selector Service untuk memeriksa apakah Service tersebut terkait dengan Pod. Untuk melakukannya, ikuti langkah-langkah berikut:

Asumsikan bahwa file YAML Service berisi informasi berikut:
Ganti <app> dan <namespace> dalam perintah berikut dan pastikan output perintah berisi Pod yang terkait dengan Service tersebut.
```
kubectl get pods -l app=<app> -n <namespace>
```
Catatan
- <app> adalah nilai label app pada Pod.
- <namespace> adalah namespace tempat Service berada. Jika Service berada di namespace default, Anda tidak perlu menentukannya.
Jika output perintah berisi Pod terkait tetapi Pod tersebut tidak memiliki alamat Endpoint, Service mungkin memiliki port yang salah. Jika Pod tidak mendengarkan pada port yang ditentukan di Service, Pod tersebut tidak akan ditambahkan ke daftar ENDPOINTS. Oleh karena itu, Anda harus memastikan bahwa port kontainer yang ditentukan oleh Service dapat diakses di dalam Pod. Untuk melakukannya, ikuti langkah-langkah berikut:
```
curl <ip>:<port>
```
Catatan
- <ip> adalah clusterIP yang ditentukan dalam file YAML pada Langkah 1.
- <port> adalah nilai port dalam file YAML pada Langkah 1.
- Metode pengujian spesifik tergantung pada lingkungan Anda.

Masalah forwarding jaringan

Jika client dapat terhubung ke Service dan alamat Endpoint benar, tetapi koneksi langsung terputus, traffic mungkin tidak diteruskan ke Pod. Dalam kasus ini, lakukan pemeriksaan berikut:

Apakah Pod berfungsi dengan benar?

Anda dapat mengidentifikasi masalah Pod. Untuk informasi selengkapnya, lihat Troubleshoot pod anomalies.
Apakah alamat Pod dapat diakses?
1. Jalankan perintah berikut untuk mendapatkan alamat IP Pod.
```
kubectl get pods -o wide
```
2. Masuk ke node mana pun dan jalankan perintah ping untuk menguji alamat IP Pod dan konfirmasi konektivitas jaringan.
Apakah aplikasi mendengarkan pada port dengan benar?

Jika aplikasi Anda mendengarkan pada port 80, Anda harus menentukan port kontainer sebagai 80 di Service. Pada node mana pun, jalankan perintah curl <ip>:<Port> untuk memeriksa apakah port kontainer di Pod berfungsi sebagaimana mestinya.

Bagaimana cara memperbarui Helm secara manual?

Komponen sisi server Helm v2 Tiller memiliki masalah keamanan yang diketahui yang memungkinkan penyerang menggunakan Tiller untuk menginstal aplikasi yang tidak sah di kluster. Kami menyarankan Anda untuk melakukan upgrade ke Helm v3. Untuk informasi selengkapnya, lihat Upgrading from Helm v2 to Helm v3.

Bagaimana cara menarik image dari instans Container Registry Enterprise Edition yang dideploy di wilayah dalam Tiongkok daratan ke kluster ACK yang dideploy di wilayah luar Tiongkok daratan?

Dalam skenario ini, Anda harus membeli instans Container Registry Enterprise Edition Jenis Penyimpanan Standar atau Premium di wilayah dalam Tiongkok daratan dan instans Container Registry Enterprise Edition Basic di wilayah luar Tiongkok daratan.

Setelah pembelian selesai, Anda dapat menggunakan instans sinkronisasi untuk menyinkronkan image dari wilayah dalam Tiongkok daratan ke wilayah luar Tiongkok daratan. Untuk informasi selengkapnya, lihat Instans sinkronisasi akun yang sama. Kemudian, dapatkan alamat registri dari instans Container Registry Enterprise Edition di wilayah luar Tiongkok daratan dan gunakan alamat ini untuk membuat aplikasi di kluster ACK.

Catatan

Edisi Personal ACR menyediakan sinkronisasi yang lebih lambat. Untuk repository yang dikelola sendiri, Anda harus membeli GA untuk mempercepat proses pull image. Baik repository yang dikelola sendiri maupun GA lebih mahal. Oleh karena itu, kami menyarankan Anda menggunakan Container Registry Enterprise Edition. Untuk informasi penagihan, lihat Informasi Penagihan.

Bagaimana cara melakukan rolling update aplikasi tanpa gangguan layanan?

Saat aplikasi lama dihapus dan yang baru dibuat, error akses 5XX temporary mungkin terjadi. Hal ini disebabkan oleh penundaan beberapa detik saat perubahan Pod disinkronkan ke instans CLB. Anda dapat mengatasi masalah ini dan mencapai rolling update Kubernetes tanpa downtime dengan mengonfigurasi shutdown yang mulus. Untuk informasi selengkapnya, lihat Cara mengimplementasikan rolling update K8s tanpa downtime.

Bagaimana cara mendapatkan container image?

Untuk informasi tentang persiapan dan tindakan pencegahan saat menarik container image untuk workload, lihat Pull image.

Bagaimana cara me-restart kontainer?

Anda tidak dapat me-restart kontainer individual secara langsung. Namun, Anda dapat mencapai efek yang sama menggunakan metode berikut:

Jalankan perintah berikut untuk melihat status kontainer dan mengidentifikasi kontainer yang ingin Anda restart.
```
kubectl get pods
```
Hapus Pod: Menghapus Pod akan memicu controller, seperti Deployment atau DaemonSet, untuk membuat Pod baru. Ini secara efektif me-restart kontainer. Untuk menghapus satu Pod, jalankan perintah berikut:
```
kubectl delete pod <pod-name>
```
Setelah Anda menghapus Pod, Kubernetes secara otomatis membuat Pod baru untuk menggantinya berdasarkan controller yang sesuai.

Catatan
Di lingkungan produksi, kami menyarankan agar Anda tidak memanipulasi Pod secara manual. Sebaliknya, Anda dapat mengelola dan memperbarui kontainer menggunakan objek seperti ReplicaSets dan Deployments untuk memastikan konsistensi status kluster.
Jalankan perintah berikut untuk memverifikasi status kontainer. Pastikan kontainer berada dalam status Running setelah direstart.
```
kubectl get pods
```

Bagaimana cara mengubah namespace Deployment?

Jika Anda ingin memindahkan Service dari satu namespace ke namespace lain, Anda harus mengubah namespace yang ditetapkan. Saat Anda mengubah namespace, Anda juga harus mengubah namespace resource dependen secara manual, seperti persistent volume claims (PVCs), ConfigMaps, dan secrets, untuk memastikan Service dapat berfungsi sebagaimana mestinya.

Jalankan perintah kubectl get untuk mengekspor konfigurasi resource dalam format YAML.
```
kubectl get deploy <deployment-name> -n <old-namespace> -o yaml > deployment.yaml
```

Edit file deployment.yaml dengan mengganti nilai parameter namespace dengan namespace baru. Lalu, simpan perubahan dan keluar dari file.

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
  generation: 1
  labels:
    app: nginx
  name: nginx-deployment
  namespace: new-namespace # Tentukan namespace baru.
  ... ...

Jalankan perintah kubectl apply untuk memperbarui Service ke namespace baru.
```
kubectl apply -f deployment.yaml 
```
Jalankan perintah kubectl get untuk mencantumkan service di namespace baru.
```
kubectl get deploy -n new-namespace
```

Bagaimana cara mengekspos informasi Pod ke kontainer yang sedang berjalan?

ACK konsisten dengan Kubernetes native dan mengikuti spesifikasi komunitas. Anda dapat mengekspos informasi Pod ke kontainer dengan dua cara berikut:

Variabel lingkungan: Anda dapat meneruskan informasi Pod ke kontainer dengan mengatur variabel lingkungan.
File: Anda dapat menyediakan informasi Pod ke kontainer sebagai file dengan melakukan mount file tersebut.

Bagaimana cara menggunakan imagePullSecrets?

Instans ACR Edisi Personal yang dibuat pada atau setelah 9 September 2024 tidak mendukung aliyun-acr-credential-helper. Saat Anda menggunakan instans ACR Edisi Personal yang baru dibuat, kami menyarankan Anda menyimpan username dan kata sandi logon dalam Secret dan mereferensikan Secret tersebut di field imagePullSecrets.

Penting

Komponen tanpa password tidak mendukung penentuan manual field imagePullSecrets.
Secret harus berada di namespace yang sama dengan workload.

Jalankan perintah berikut dan ganti parameter sesuai permintaan untuk membuat Secret yang berisi username dan password.
```
kubectl create secret docker-registry image-secret \
  --docker-server=<ACR-registry> \
  --docker-username=<username> \
  --docker-password=<password> \
  --docker-email=<email@example.com>
```
- docker-server: Masukkan endpoint instans ACR, yang harus sesuai dengan jenis jaringan Alamat Registri (alamat jaringan internal atau publik).
- docker-username: username kredensial akses ACR.
- docker-password: password kredensial akses ACR.
- docker-email: Opsional.

Setelah membuat Secret, Anda dapat mengonfigurasi field imagePullSecrets di ServiceAccount atau workload untuk menggunakan username dan password tersebut.

Gunakan Service Account

Tambahkan field imagePullSecrets ke ServiceAccount. Misalnya, Anda dapat menggunakan ServiceAccount default bernama default di namespace default:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: default
  namespace: default
imagePullSecrets:
- name: image-secret # Masukkan Secret ACR

Jika workload menggunakan ServiceAccount ini, workload tersebut dapat menarik image.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-test
  namespace: default
  labels:
    app: nginx
spec:
  serviceAccountName: default # Jika menggunakan Service Account default untuk namespace, Anda tidak perlu menentukannya.
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: <acrID>.cr.aliyuncs.com/<repo>/nginx:latest  # Ganti dengan tautan instans ACR

Gunakan Langsung di Workload

Tentukan field imagePullSecrets di workload untuk menggunakan kunci tersebut.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-test
  namespace: default
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      imagePullSecrets:
      - name: image-secret  # Gunakan Secret yang dibuat pada langkah sebelumnya
      containers:
      - name: nginx
        image: <acrID>.cr.aliyuncs.com/<repo>/nginx:latest  # Ganti dengan Alamat Registri repository ACR

Mengapa proses pull tetap gagal setelah mengonfigurasi komponen tanpa password?

Salah satu kemungkinan penyebabnya adalah konfigurasi komponen tanpa password salah. Misalnya:

Informasi instans dalam komponen tanpa password tidak sesuai dengan instans ACR.
Alamat image yang digunakan untuk menarik image tidak sesuai dengan nama domain dalam informasi instans komponen tanpa password.

Ikuti langkah-langkah dalam Pull Image dalam Akun yang Sama untuk memecahkan masalah tersebut.

Jika proses pull image tetap gagal setelah komponen dikonfigurasi dengan benar, field imagePullSecrets yang Anda tentukan secara manual di file YAML workload mungkin bertentangan dengan komponen tanpa password. Untuk mengatasi masalah ini, hapus secara manual field imagePullSecrets, lalu hapus dan buat ulang Pod tersebut.

Mengapa kontainer gagal dimulai di node baru setelah mengaktifkan akselerasi image kelompok node?

Setelah Anda mengaktifkan Container Image Acceleration untuk kelompok node, kontainer gagal dimulai dan pesan error berikut dikembalikan:

failed to create containerd container: failed to attach and mount for snapshot 46: failed to enable target for /sys/kernel/config/target/core/user_99999/dev_46, failed:failed to open remote file as tar file xxxx

Masalah ini terjadi karena setelah Anda mengaktifkan Container Image Acceleration, Anda harus menginstal komponen aliyun-acr-acceleration-suite dan mengonfigurasi kredensial pull untuk menarik image privat. Untuk informasi selengkapnya, lihat Konfigurasikan Kredensial Pull Image Kontainer.

Penting

Jika masalah tetap berlanjut setelah Anda menginstal komponen tersebut, kami menyarankan agar Anda terlebih dahulu menonaktifkan container image acceleration untuk memulihkan layanan Anda, lalu coba konfigurasi ulang.