Konfigurasi yang direkomendasikan untuk workload kluster ACK - Container Service for Kubernetes

Saat mengonfigurasi beban kerja seperti Deployment, StatefulSet, DaemonSet, Job, dan CronJob di kluster ACK, pertimbangkan berbagai faktor untuk memastikan stabilitas dan keandalan aplikasi.

Deklarasikan requests dan limits untuk setiap Pod

Menjadwalkan terlalu banyak Pod pada satu node di kluster Kubernetes dapat menyebabkan beban tinggi dan mengganggu fungsi layanan. Saat mengonfigurasi Pod, deklarasikan requests dan limits sumber daya yang dibutuhkan. Hal ini memungkinkan kluster menemukan node yang sesuai berdasarkan kebutuhan sumber daya selama penjadwalan Pod.

Pada contoh berikut, Pod Nginx dikonfigurasi dengan sumber daya sebagai berikut:

Request CPU sebesar 1 core dan request memori sebesar 1024 Mi
Limit CPU sebesar 2 core dan limit memori sebesar 4096 Mi

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
    resources: # Deklarasi sumber daya
      requests:
        memory: "1024Mi"
        cpu: "1000m"
      limits:
        memory: "4096Mi"
        cpu: "2000m"

Kubernetes menggunakan mekanisme penjadwalan sumber daya statis. Sisa sumber daya pada suatu node dihitung menggunakan rumus berikut: Sisa sumber daya node = Total sumber daya node - Sumber daya yang dialokasikan. Saat Anda menjalankan program yang intensif sumber daya secara manual, Kubernetes tidak dapat mendeteksi penggunaan sumber daya aktualnya karena rumus tersebut didasarkan pada sumber daya yang dialokasikan, bukan penggunaan aktual.

Selain itu, semua Pod harus mendeklarasikan resources. Jika suatu Pod tidak mendeklarasikan resources, Kubernetes tidak akan mencadangkan sumber daya untuk Pod tersebut setelah dijadwalkan ke suatu node. Hal ini dapat menyebabkan terlalu banyak Pod pada satu node, sehingga menimbulkan konflik sumber daya.

Anda dapat menggunakan fitur resource profile di ACK. Fitur ini memberikan rekomendasi sumber daya tingkat kontainer berdasarkan data penggunaan historis, sehingga menyederhanakan konfigurasi requests dan limits kontainer.

Tunggu layanan downstream saat startup dan jangan langsung keluar

Beberapa aplikasi memiliki dependensi eksternal, seperti database (DB) atau API layanan lain. Saat startup, dependensi tersebut mungkin belum siap. Dalam operasi dan pemeliharaan (O&M) manual tradisional, pendekatan fail-fast sering digunakan—aplikasi langsung keluar jika dependensinya tidak tersedia. Namun, di Kubernetes, sebagian besar operasi O&M bersifat otomatis: sistem secara otomatis memilih node dan menjalankan aplikasi selama penerapan, merestart aplikasi jika gagal, serta melakukan penskalaan otomatis melalui Horizontal Pod Autoscaler (HPA) saat beban meningkat.

Sebagai contoh, pertimbangkan dua aplikasi A dan B, di mana A bergantung pada B dan keduanya berjalan pada node yang sama. Jika node tersebut restart, A mungkin mulai lebih dulu daripada B. Dalam kasus ini, dependensi A belum tersedia. Jika A langsung keluar seperti dalam lingkungan tradisional, aplikasi tersebut tidak akan pulih secara otomatis meskipun B sudah berjalan, sehingga memerlukan intervensi manual.

Di kluster Kubernetes, aplikasi harus memeriksa dependensinya saat startup. Jika dependensi belum tersedia, aplikasi harus menunggu dan melakukan polling terhadap dependensi tersebut alih-alih langsung keluar. Perilaku ini dapat diterapkan menggunakan Init Container.

Konfigurasikan kebijakan restart

Saat Pod sedang berjalan, proses di dalamnya dapat berhenti karena berbagai alasan, seperti bug dalam kode atau penggunaan memori yang tinggi. Anda dapat mengonfigurasi restartPolicy agar Pod secara otomatis merestart setelah berhenti.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-test
spec:
  restartPolicy: OnFailure 
  containers:
  - name: nginx
    image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6

restartPolicy dapat diatur ke salah satu nilai berikut:

Always: Secara otomatis merestart kontainer.
OnFailure: Secara otomatis merestart kontainer hanya jika keluar dengan kode status non-nol.
Never: Tidak merestart kontainer.

Konfigurasikan probe pemeriksaan kesehatan

Anda dapat mengonfigurasi probe untuk menangani masalah seperti deadlock aplikasi, startup yang lambat, atau kegagalan layanan. Probe memberikan kemampuan pemulihan kesalahan otomatis dan shaping traffic kepada Kubernetes, sehingga memungkinkan sistem secara otomatis merestart kontainer yang bermasalah dan hanya mengirim permintaan ke instans yang siap. Ini merupakan mekanisme utama untuk memastikan ketersediaan tinggi dan stabilitas layanan.

startupProbe (Startup probe): Memeriksa apakah aplikasi telah selesai melakukan startup. Probe ini berguna untuk aplikasi yang membutuhkan waktu lama untuk startup, seperti aplikasi Java. Probe readiness dan liveness tidak dijalankan hingga startup probe berhasil, sehingga mencegah kubelet salah mengartikan aplikasi yang startup-nya lambat sebagai aplikasi yang gagal dan merestart-nya.
readinessProbe (Readiness probe): Digunakan untuk mengontrol shaping traffic. Alamat IP Pod ditambahkan ke daftar Endpoints layanan hanya setelah probe ini berhasil, sehingga memastikan permintaan eksternal hanya dikirim ke kontainer yang siap memprosesnya.
livenessProbe (Liveness probe): Memantau kesehatan kontainer. Jika probe mendeteksi deadlock atau crash, kubelet memicu restart otomatis untuk memfasilitasi pemulihan kesalahan.

Contoh berikut menunjukkan cara mengonfigurasi probe pemeriksaan kesehatan untuk penerapan Nginx tanpa status.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment-demo
spec:
  replicas: 1                 # Untuk lingkungan produksi, atur nilai ini menjadi 2 atau lebih untuk memastikan ketersediaan tinggi
  selector:
    matchLabels:
      app: nginx-demo
  template:
    metadata:
      labels:
        app: nginx-demo 
    spec:
      containers:
      - name: nginx
        image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 500m
            memory: 1Gi
          limits:
            cpu: 500m
        # --- Probe pemeriksaan kesehatan ---
        # Startup Probe: Memastikan aplikasi di dalam kontainer telah dimulai.
        startupProbe:
          httpGet:
            path: / # Mengakses path root default Nginx menandakan startup berhasil.
            port: 80
          # Berikan waktu yang cukup bagi aplikasi untuk startup. Total timeout = failureThreshold × periodSeconds, yaitu 30 × 10 = 300 detik.
          failureThreshold: 30
          periodSeconds: 10
        # Readiness Probe: Menentukan apakah kontainer siap menerima traffic.
        readinessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 5  # Mulai probing 5 detik setelah kontainer dimulai.
          periodSeconds: 5        # Melakukan probing setiap 5 detik.
          timeoutSeconds: 2       # Timeout probing.
          successThreshold: 1     # 1 keberhasilan menandakan siap.
          failureThreshold: 3     # 3 kegagalan berturut-turut menandakan tidak siap.
        # Liveness Probe: Menentukan apakah kontainer "hidup" untuk pemulihan kesalahan otomatis.
        # Konfigurasi ini harus lebih longgar daripada readinessProbe untuk menghindari restart yang tidak perlu akibat jitter sementara.
        livenessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 15 # Melakukan probing pertama 15 detik setelah kontainer dimulai, memberi waktu bagi aplikasi untuk inisialisasi dan stabilisasi.
          periodSeconds: 10       # Frekuensi probing lebih rendah daripada readinessProbe untuk mengurangi konsumsi sumber daya sistem.
          timeoutSeconds: 3       # Timeout bisa sedikit lebih lama daripada readinessProbe.
          successThreshold: 1     # 1 keberhasilan menandakan hidup.
          failureThreshold: 3     # Setelah 3 kegagalan berturut-turut (3 × 10 = 30 detik), kubelet merestart kontainer.

Untuk informasi lebih lanjut tentang cara mengonfigurasi penyebaran bergulir tanpa downtime di lingkungan produksi, lihat Implementasikan penyebaran bergulir tanpa downtime.

Satu proses per kontainer

Beberapa pengembang memperlakukan kontainer seolah-olah itu adalah mesin virtual (VM), dengan menjalankan beberapa proses—seperti proses pemantauan, logging, sshd, atau bahkan Systemd lengkap—dalam satu kontainer. Praktik ini menyebabkan masalah berikut:

Lebih kompleks untuk menentukan penggunaan sumber daya keseluruhan Pod dan lebih sulit untuk mengonfigurasi requests dan limits secara tepat.
Jika sebuah kontainer hanya menjalankan satu proses, engine kontainer eksternal dapat langsung mendeteksi kegagalan proses tersebut dan merestart kontainer. Namun, jika sebuah kontainer menjalankan beberapa proses, engine kontainer eksternal tidak dapat mendeteksi kegagalan salah satu proses, sehingga kontainer mungkin berhenti berfungsi dengan benar.

Kubernetes mendukung beberapa proses yang bekerja sama. Misalnya, Nginx dan PHP-FPM dapat berkomunikasi melalui Unix Domain Socket. Untuk mencapai hal ini, Anda dapat membuat Pod yang berisi dua kontainer dan menyimpan Unix Domain Socket di volume yang dibagikan antar kontainer.

Hindari single point of failure

Jika suatu aplikasi hanya memiliki satu instans, kegagalan instans tersebut pasti menyebabkan gangguan layanan singkat, bahkan jika Kubernetes dapat secara otomatis merestart-nya. Gangguan serupa juga dapat terjadi saat memperbarui aplikasi atau merilis versi baru.

Di Kubernetes, hindari pengelolaan Pod secara langsung. Sebaliknya, gunakan Deployment atau StatefulSet untuk mengelolanya, dan pastikan aplikasi menjalankan setidaknya dua instans Pod. Pendekatan ini meningkatkan ketersediaan tinggi sistem serta mencegah gangguan layanan akibat kegagalan instans tunggal.

Referensi

ACK dapat menerapkan strategi rilis seperti rilis bertahap, penyebaran biru-hijau, dan lainnya untuk aplikasi. Untuk informasi lebih lanjut, lihat Penerapan dan rilis.
Untuk informasi lebih lanjut tentang praktik terbaik manajemen aplikasi, lihat Praktik terbaik workload.
Jika suatu Pod mengalami anomali, Anda dapat melakukan pemeriksaan mandiri dengan merujuk ke Pemecahan masalah anomali Pod dan FAQ Workload.