Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Menjalankan aplikasi yang sangat tersedia

Pelanggan Anda mengharapkan aplikasi Anda selalu tersedia, termasuk saat Anda membuat perubahan dan terutama selama lonjakan lalu lintas. Arsitektur yang dapat diskalakan dan tangguh membuat aplikasi dan layanan Anda berjalan tanpa gangguan, yang membuat pengguna Anda senang. Infrastruktur yang dapat diskalakan tumbuh dan menyusut berdasarkan kebutuhan bisnis. Menghilangkan satu titik kegagalan adalah langkah penting untuk meningkatkan ketersediaan aplikasi dan membuatnya tangguh.

Dengan Kubernetes, Anda dapat mengoperasikan aplikasi Anda dan menjalankannya dengan cara yang sangat tersedia dan tangguh. Manajemen deklaratifnya memastikan bahwa setelah Anda mengatur aplikasi, Kubernetes akan terus mencoba untuk men cocokkan status saat ini dengan status yang diinginkan.

Rekomendasi

Konfigurasikan Anggaran Gangguan Pod

Anggaran Gangguan Pod digunakan untuk membatasi jumlah gangguan bersamaan yang akan dialami aplikasi. Mereka harus dikonfigurasi untuk beban kerja jika penting untuk selalu memiliki sebagian dari beban kerja yang tersedia. EKS Auto Mode, Karpenter, dan Cluster Autoscaler mengetahui dan mematuhi Anggaran Gangguan Pod yang dikonfigurasi saat menurunkan skala. EKS Auto Mode, Karpenter, dan Grup Node Terkelola juga mematuhi Anggaran Gangguan Pod saat memperbarui Node

Hindari menjalankan Singleton Pod

Jika seluruh aplikasi Anda berjalan dalam satu Pod, maka aplikasi Anda tidak akan tersedia jika Pod tersebut dihentikan. Alih-alih menerapkan aplikasi menggunakan pod individual, buat Deployments. Jika Pod yang dibuat oleh Deployment gagal atau dihentikan, peng ontrol Deployment akan memulai pod baru untuk memastikan jumlah Pod replika yang ditentukan selalu berjalan.

Jalankan beberapa replika

Menjalankan beberapa replika Pod aplikasi menggunakan Deployment membantunya berjalan dengan cara yang sangat tersedia. Jika satu replika gagal, replika yang tersisa akan tetap berfungsi, meskipun pada kapasitas yang berkurang sampai Kubernetes membuat Pod lain untuk menebus kerugian. Selanjutnya, Anda dapat menggunakan Horizon tal Pod Autoscaler untuk menskalakan replika secara otomatis berdasarkan permintaan beban kerja.

Jadwalkan replika di seluruh node

Menjalankan beberapa replika tidak akan sangat berguna jika semua replika berjalan pada node yang sama, dan node menjadi tidak tersedia. Pertimbangkan untuk menggunakan batasan penyebaran anti-afinitas atau topologi pod untuk menyebarkan replika Deployment di beberapa node pekerja.

Anda dapat lebih meningkatkan keandalan aplikasi biasa dengan menjalankannya di beberapa AZ.

Menggunakan aturan anti-afinitas Pod

Manifes di bawah ini memberitahu penjadwal Kubernetes untuk memilih menempatkan pod pada node dan AZ terpisah. Itu tidak memerlukan node atau AZ yang berbeda karena jika ya, maka Kubernetes tidak akan dapat menjadwalkan pod apa pun setelah ada pod yang berjalan di setiap AZ. Jika aplikasi Anda hanya memerlukan tiga replika, Anda dapat menggunakan requiredDuringSchedulingIgnoredDuringExecution untuktopologyKey: topology.kubernetes.io/zone, dan penjadwal Kubernetes tidak akan menjadwalkan dua pod di AZ yang sama.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: spread-host-az
  labels:
    app: web-server
spec:
  replicas: 4
  selector:
    matchLabels:
      app: web-server
  template:
    metadata:
      labels:
        app: web-server
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - web-server
              topologyKey: topology.kubernetes.io/zone
            weight: 100
          - podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - web-server
              topologyKey: kubernetes.io/hostname
            weight: 99
      containers:
      - name: web-app
        image: nginx:1.16-alpine

Menggunakan batasan penyebaran topologi Pod

Mirip dengan aturan anti-afinitas pod, batasan penyebaran topologi pod memungkinkan Anda membuat aplikasi tersedia di berbagai domain kegagalan (atau topologi) seperti host atau AZ. Pendekatan ini bekerja dengan sangat baik ketika Anda mencoba memastikan toleransi kesalahan serta ketersediaan dengan memiliki beberapa replika di masing-masing domain topologi yang berbeda. Aturan anti-afinitas pod, di sisi lain, dapat dengan mudah menghasilkan hasil di mana Anda memiliki replika tunggal dalam domain topologi karena pod dengan anti-afinitas satu sama lain memiliki efek tolak. Dalam kasus seperti itu, replika tunggal pada node khusus tidak ideal untuk toleransi kesalahan juga bukan penggunaan sumber daya yang baik. Dengan batasan penyebaran topologi, Anda memiliki kontrol lebih besar atas penyebaran atau distribusi yang harus coba diterapkan oleh penjadwal di seluruh domain topologi. Berikut adalah beberapa properti penting untuk digunakan dalam pendekatan ini:

Selain di atas, ada bidang lain yang dapat Anda baca lebih lanjut dalam dokumentasi Kubernetes.

Kendala penyebaran topologi pod di 3 AZ

apiVersion: apps/v1
kind: Deployment
metadata:
  name: spread-host-az
  labels:
    app: web-server
spec:
  replicas: 10
  selector:
    matchLabels:
      app: web-server
  template:
    metadata:
      labels:
        app: web-server
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: "topology.kubernetes.io/zone"
        whenUnsatisfiable: ScheduleAnyway
        labelSelector:
          matchLabels:
            app: express-test
      containers:
      - name: web-app
        image: nginx:1.16-alpine

Jalankan Server Metrik Kubernetes

Instal server metrik Kubernetes untuk membantu menskalakan aplikasi Anda. Pengaya autoscaler Kubernetes seperti HPA dan VPA perlu melacak metrik aplikasi untuk menskalakannya. Metrics-server mengumpulkan metrik sumber daya yang dapat digunakan untuk membuat keputusan penskalaan. Metrik dikumpulkan dari kubelet dan disajikan dalam format Metrics API.

Server metrik tidak menyimpan data apa pun, dan ini bukan solusi pemantauan. Tujuannya adalah untuk mengekspos metrik penggunaan CPU dan memori ke sistem lain. Jika Anda ingin melacak status aplikasi Anda dari waktu ke waktu, Anda memerlukan alat pemantauan seperti Prometheus atau Amazon. CloudWatch

Ikuti dokumentasi EKS untuk menginstal metrics-server di cluster EKS Anda.

Autoscaler Pod Horizontal (HPA)

HPA dapat secara otomatis menskalakan aplikasi Anda dalam menanggapi permintaan dan membantu Anda menghindari dampak pelanggan Anda selama lalu lintas puncak. Ini diimplementasikan sebagai loop kontrol di Kubernetes yang secara berkala menanyakan metrik dari API yang menyediakan metrik sumber daya.

HPA dapat mengambil metrik dari API berikut: 1. metrics.k8s.iojuga dikenal sebagai Resource Metrics API - Menyediakan penggunaan CPU dan memori untuk pod 2. custom.metrics.k8s.io — Menyediakan metrik dari kolektor metrik lain seperti Prometheus; metrik ini bersifat internal ke cluster Kubernetes Anda. 3. external.metrics.k8s.io — Menyediakan metrik yang berada di luar cluster Kubernetes Anda (E.g., Kedalaman Antrian SQS, latensi ELB).

Anda harus menggunakan salah satu dari tiga API ini untuk menyediakan metrik untuk menskalakan aplikasi Anda.

Aplikasi penskalaan berdasarkan metrik khusus atau eksternal

Anda dapat menggunakan metrik khusus atau eksternal untuk menskalakan aplikasi Anda pada metrik selain CPU atau pemanfaatan memori. Server Custom Metrics API menyediakan custom-metrics.k8s.io API yang dapat digunakan HPA untuk menskalakan aplikasi secara otomatis.

Anda dapat menggunakan Prometheus Adapter for Kubernetes Metrics API untuk mengumpulkan metrik dari Prometheus dan menggunakannya dengan HPA. Dalam hal ini, adaptor Prometheus akan mengekspos metrik Prometheus dalam format Metrics API. https://github.com/kubernetes/metrics/blob/master/pkg/apis/metrics/types.go

Setelah menerapkan Adaptor Prometheus, Anda dapat menanyakan metrik khusus menggunakan kubectl. kubectl get —raw /apis/custom.metrics.k8s.io/v1beta1/

Metrik eksternal, seperti namanya, memberikan Horizontal Pod Autoscaler kemampuan untuk menskalakan penerapan menggunakan metrik yang berada di luar cluster Kubernetes. Misalnya, dalam beban kerja pemrosesan batch, adalah umum untuk menskalakan jumlah replika berdasarkan jumlah pekerjaan dalam penerbangan dalam antrian SQS.

Untuk menskalakan beban kerja Kubernetes secara otomatis, Anda dapat menggunakan KEDA (Kubernetes Event-driven Autoscaling), proyek sumber terbuka yang dapat mendorong penskalaan kontainer berdasarkan sejumlah peristiwa khusus. Blog AWS ini menguraikan cara menggunakan Amazon Managed Service for Prometheus untuk penskalaan otomatis beban kerja Kubernetes.

Autoscaler Pod Vertikal (VPA)

VPA secara otomatis menyesuaikan reservasi CPU dan memori untuk Pod Anda untuk membantu Anda “mengukur dengan tepat” aplikasi Anda. Untuk aplikasi yang perlu diskalakan secara vertikal - yang dilakukan dengan meningkatkan alokasi sumber daya - Anda dapat menggunakan VPA untuk menskalakan replika Pod secara otomatis atau memberikan rekomendasi penskalaan.

Aplikasi Anda mungkin menjadi tidak tersedia sementara jika VPA perlu menskalakannya karena implementasi VPA saat ini tidak melakukan penyesuaian di tempat pada Pod; sebagai gantinya, aplikasi akan membuat ulang Pod yang perlu diskalakan.

Dokumentasi EKS mencakup panduan untuk menyiapkan VPA.

https://github.com/FairwindsOps/goldilocks/Proyek Fairwinds Goldilocks menyediakan dasbor untuk memvisualisasikan rekomendasi VPA untuk permintaan dan batas CPU dan memori. Mode pembaruan VPA-nya memungkinkan Anda untuk menskalakan Pod secara otomatis berdasarkan rekomendasi VPA.

Memperbarui aplikasi

Aplikasi modern membutuhkan inovasi cepat dengan tingkat stabilitas dan ketersediaan yang tinggi. Kubernetes memberi Anda alat untuk memperbarui aplikasi Anda secara terus menerus tanpa mengganggu pelanggan Anda.

Mari kita lihat beberapa praktik terbaik yang memungkinkan penerapan perubahan dengan cepat tanpa mengorbankan ketersediaan.

Memiliki mekanisme untuk melakukan rollback

Memiliki tombol undo dapat menghindari bencana. Ini adalah praktik terbaik untuk menguji penerapan di lingkungan bawah yang terpisah (lingkungan pengujian atau pengembangan) sebelum memperbarui cluster produksi. Menggunakan CI/CD pipeline dapat membantu Anda mengotomatiskan dan menguji penerapan. Dengan pipeline penerapan berkelanjutan, Anda dapat dengan cepat kembali ke versi yang lebih lama jika pemutakhiran rusak.

Anda dapat menggunakan Deployments untuk memperbarui aplikasi yang sedang berjalan. Ini biasanya dilakukan dengan memperbarui gambar kontainer. Anda dapat menggunakan kubectl untuk memperbarui Deployment seperti ini:

kubectl --record deployment.apps/nginx-deployment set image nginx-deployment nginx=nginx:1.16.1

--recordArgumen merekam perubahan pada Deployment dan membantu Anda jika Anda perlu melakukan rollback. kubectl rollout history deploymentmenunjukkan kepada Anda perubahan yang direkam pada Deployments di cluster Anda. Anda dapat mengembalikan perubahan menggunakankubectl rollout undo deployment <DEPLOYMENT_NAME>.

Secara default, saat Anda memperbarui Deployment yang memerlukan pembuatan ulang pod, Deployment akan melakukan pembaruan ber gulir. Dengan kata lain, Kubernetes hanya akan memperbarui sebagian pod yang sedang berjalan dalam Deployment dan tidak semua Pod sekaligus. Anda dapat mengontrol bagaimana Kubernetes melakukan pembaruan bergulir melalui properti. RollingUpdateStrategy

Saat melakukan pembaruan bergulir dari Deployment, Anda dapat menggunakan Max Unavailable properti untuk menentukan jumlah maksimum Pod yang mungkin tidak tersedia selama pembaruan. Pro Max Surge perti Deployment memungkinkan Anda mengatur jumlah maksimum Pod yang dapat dibuat di atas jumlah Pod yang diinginkan.

Pertimbangkan max unavailable untuk menyesuaikan untuk memastikan bahwa peluncuran tidak mengganggu pelanggan Anda. Misalnya, Kubernetes menetapkan 25% secara max unavailable default, yang berarti jika Anda memiliki 100 Pod, Anda mungkin hanya memiliki 75 Pod yang aktif bekerja selama peluncuran. Jika aplikasi Anda membutuhkan minimal 80 Pod, peluncuran ini dapat mengganggu. Sebagai gantinya, Anda dapat mengatur max unavailable ke 20% untuk memastikan bahwa ada setidaknya 80 Pod fungsional selama peluncuran.

Gunakan pener blue/green apan

Perubahan pada dasarnya berisiko, tetapi perubahan yang tidak dapat dibatalkan dapat berpotensi menjadi bencana besar. Ubah prosedur yang memungkinkan Anda mengembalikan waktu secara efektif melalui rollback membuat peningkatan dan eksperimen lebih aman. Blue/green penerapan memberi Anda metode untuk menarik kembali perubahan dengan cepat jika terjadi kesalahan. Dalam strategi penerapan ini, Anda membuat lingkungan untuk versi baru. Lingkungan ini identik dengan versi aplikasi saat ini yang sedang diperbarui. Setelah lingkungan baru disediakan, lalu lintas dialihkan ke lingkungan baru. Jika versi baru menghasilkan hasil yang diinginkan tanpa menghasilkan kesalahan, lingkungan lama dihentikan. Jika tidak, lalu lintas dikembalikan ke versi lama.

Anda dapat melakukan pener blue/green apan di Kubernetes dengan membuat Deployment baru yang identik dengan Deployment versi yang ada. Setelah memverifikasi bahwa Pod di Deployment baru berjalan tanpa kesalahan, Anda dapat mulai mengirim lalu lintas ke Deployment baru dengan mengubah selector spesifikasi di Layanan yang merutekan lalu lintas ke Pod aplikasi Anda.

Banyak alat integrasi berkelanjutan seperti Flux, Jenkins, dan Spinnaker memungkinkan Anda mengotomatiskan penerapan. blue/green Blog AWS Containers menyertakan panduan menggunakan AWS Load Balancer Controller: Menggunakan AWS Load Balancer Controller untuk blue/green penyebaran, penyebaran, dan pengujian canary A/B

Gunakan penerapan Canary

Penerapan Canary adalah varian penerapan blue/green yang secara signifikan dapat menghilangkan risiko dari perubahan. Dalam strategi penerapan ini, Anda membuat Deployment baru dengan Pod yang lebih sedikit di samping Deployment lama Anda, dan mengalihkan sebagian kecil lalu lintas ke Deployment baru. Jika metrik menunjukkan bahwa versi baru berkinerja baik atau lebih baik daripada versi yang ada, Anda secara progresif meningkatkan lalu lintas ke Deployment baru sambil menskalakannya hingga semua lalu lintas dialihkan ke Deployment baru. Jika ada masalah, Anda dapat merutekan semua lalu lintas ke Deployment lama dan berhenti mengirim lalu lintas ke Deployment baru.

Meskipun Kubernetes tidak menawarkan cara asli untuk melakukan penerapan kenari, Anda dapat menggunakan alat seperti Flagger dengan Istio. https://github.com/weaveworks/flagger https://docs.flagger.app/tutorials/istio-progressive-delivery

Pemeriksaan kesehatan dan penyembuhan diri

Tidak ada perangkat lunak yang bebas bug, tetapi Kubernetes dapat membantu Anda meminimalkan dampak kegagalan perangkat lunak. Di masa lalu, jika aplikasi mogok, seseorang harus memperbaiki situasi dengan memulai ulang aplikasi secara manual. Kubernetes memberi Anda kemampuan untuk mendeteksi kegagalan perangkat lunak di Pod Anda dan secara otomatis menggantinya dengan replika baru. Dengan Kubernetes Anda dapat memantau kesehatan aplikasi Anda dan secara otomatis mengganti instans yang tidak sehat.

Kubernetes mendukung tiga jenis pemeriksaan kesehatan: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

Kubelet, agen Kubernetes, bertanggung jawab untuk menjalankan semua pemeriksaan yang disebutkan di atas. Kubelet dapat memeriksa kesehatan Pod dengan tiga cara: kubelet dapat menjalankan perintah shell di dalam wadah Pod, mengirim permintaan GET HTTP ke wadahnya, atau membuka soket TCP pada port tertentu.

Jika Anda memilih probe exec berbasis, yang menjalankan skrip shell di dalam wadah, pastikan perintah shell keluar sebelum timeoutSeconds nilai kedalu warsa. Jika tidak, node Anda akan memiliki <defunct> proses, yang menyebabkan kegagalan node.

Rekomendasi

Gunakan Liveness Probe untuk menghapus pod yang tidak sehat

Probe Liveness dapat mendeteksi kondisi kebuntuan di mana proses terus berjalan, tetapi aplikasi menjadi tidak responsif. Misalnya, jika Anda menjalankan layanan web yang mendengarkan pada port 80, Anda dapat mengonfigurasi probe Liveness untuk mengirim permintaan HTTP GET pada port 80 Pod. Kubelet akan secara berkala mengirim permintaan GET ke Pod dan mengharapkan respons; jika Pod merespons antara 200-399 maka kubelet menganggap Pod sehat; jika tidak, Pod akan ditandai sebagai tidak sehat. Jika Pod gagal melakukan pemeriksaan kesehatan secara terus menerus, kubelet akan menghentikannya.

Anda dapat menggunakan initialDelaySeconds untuk menunda probe pertama.

Saat menggunakan Liveness Probe, pastikan aplikasi Anda tidak mengalami situasi di mana semua Pod secara bersamaan gagal dalam Liveness Probe karena Kubernetes akan mencoba mengganti semua Pod Anda, yang akan membuat aplikasi Anda offline. Selanjutnya, Kubernetes akan terus membuat Pod baru yang juga akan gagal dalam Liveness Probe, menempatkan ketegangan yang tidak perlu pada bidang kontrol. Hindari mengonfigurasi Probe Kehidupan untuk bergantung pada faktor yang berada di luar Pod Anda, misalnya, database eksternal. Dengan kata lain, database External-to-Your-POD yang tidak responsif seharusnya tidak membuat Pod Anda gagal dalam Probe Kehidupan mereka.

Postingan Sandor Szücs PROBES LIVENESS ARE DANGEROUS menjelaskan masalah yang dapat disebabkan oleh probe yang salah konfigurasi.

Gunakan Startup Probe untuk aplikasi yang membutuhkan waktu lebih lama untuk memulai

Ketika aplikasi Anda membutuhkan waktu tambahan untuk memulai, Anda dapat menggunakan Probe Startup untuk menunda Probe Kehidupan dan Kesiapan. Misalnya, aplikasi Java yang perlu menghidrasi cache dari database mungkin memerlukan hingga dua menit sebelum berfungsi penuh. Probe Kehidupan atau Kesiapan apa pun sampai berfungsi penuh mungkin gagal. Mengkonfigurasi Startup Probe akan memungkinkan aplikasi Java menjadi sehat sebelum Liveness atau Readiness Probe dijalankan.

Sampai Startup Probe berhasil, semua Probe lainnya dinonaktifkan. Anda dapat menentukan waktu maksimum Kubernetes harus menunggu startup aplikasi. Jika, setelah waktu maksimum yang dikonfigurasi, Pod masih gagal Startup Probe, itu akan dihentikan, dan Pod baru akan dibuat.

Probe Startup mirip dengan Liveness Probe — jika gagal, Pod dibuat ulang. Seperti yang dijelaskan Ricardo A. dalam postingnya Fantastic Probes And How To Configure Them, Startup Probe harus digunakan ketika waktu startup aplikasi tidak dapat diprediksi. Jika Anda tahu aplikasi Anda membutuhkan sepuluh detik untuk memulai, Anda harus menggunakan Liveness/Readiness Probe sebagai initialDelaySeconds gantinya.

Gunakan Readiness Probe untuk mendeteksi ketidaktersediaan sebagian

Sementara probe Liveness mendeteksi kegagalan dalam aplikasi yang diselesaikan dengan mengakhiri Pod (karenanya, memulai ulang aplikasi), Probe Kesiapan mendeteksi kondisi di mana aplikasi mungkin tidak tersedia sementara. Dalam situasi ini, aplikasi mungkin menjadi tidak responsif sementara; Namun, diharapkan menjadi sehat kembali setelah operasi ini selesai.

Misalnya, selama I/O operasi disk yang intens, aplikasi mungkin sementara tidak tersedia untuk menangani permintaan. Di sini, menghentikan Pod aplikasi bukanlah solusi; pada saat yang sama, permintaan tambahan yang dikirim ke Pod dapat gagal.

Anda dapat menggunakan Probe Kesiapan untuk mendeteksi ketidaktersediaan sementara di aplikasi Anda dan berhenti mengirim permintaan ke Pod-nya hingga berfungsi kembali. Tidak seperti Liveness Probe, di mana kegagalan akan mengakibatkan rekreasi Pod, Probe Kesiapan yang gagal berarti Pod tidak akan menerima lalu lintas apa pun dari Layanan Kubernetes. Ketika Probe Kesiapan berhasil, Pod akan melanjutkan penerimaan lalu lintas dari Layanan.

Sama seperti Liveness Probe, hindari mengonfigurasi Probe Kesiapan yang bergantung pada sumber daya yang berada di luar Pod (seperti database). Berikut adalah skenario di mana Kesiapan yang dikonfigurasi dengan buruk dapat membuat aplikasi tidak berfungsi - jika Probe Kesiapan Pod gagal ketika database aplikasi tidak dapat dijangkau, replika Pod lain juga akan gagal secara bersamaan karena mereka memiliki kriteria pemeriksaan kesehatan yang sama. Menyetel probe dengan cara ini akan memastikan bahwa setiap kali database tidak tersedia, Probe Kesiapan Pod akan gagal, dan Kubernetes akan berhenti mengirim lalu lintas ke semua Pod.

Efek samping menggunakan Probe Kesiapan adalah mereka dapat meningkatkan waktu yang diperlukan untuk memperbarui Deployments. Replika baru tidak akan menerima lalu lintas kecuali Probe Kesiapan berhasil; sampai saat itu, replika lama akan terus menerima lalu lintas.

Mengatasi gangguan

Pod memiliki masa pakai yang terbatas - bahkan jika Anda memiliki Pod yang berjalan lama, sebaiknya pastikan Pod berakhir dengan benar ketika saatnya tiba. Tergantung pada strategi peningkatan Anda, peningkatan cluster Kubernetes mungkin mengharuskan Anda membuat node pekerja baru, yang mengharuskan semua Pod dibuat ulang pada node yang lebih baru. Penanganan penghentian yang tepat dan Anggaran Gangguan Pod dapat membantu Anda menghindari gangguan layanan karena Pod dihapus dari node yang lebih lama dan dibuat ulang pada node yang lebih baru.

Cara yang lebih disukai untuk meningkatkan node pekerja adalah dengan membuat node pekerja baru dan menghentikan yang lama. Sebelum mengakhiri node pekerja, Anda harus drain melakukannya. Ketika node pekerja dikeringkan, semua polongnya diu sir dengan aman. Aman adalah kata kunci di sini; ketika pod pada pekerja diusir, mereka tidak hanya dikirim sinyalSIGKILL. Sebagai gantinya, SIGTERM sinyal dikirim ke proses utama (PID 1) dari setiap wadah di Pod yang diusir. Setelah SIGTERM sinyal dikirim, Kubernetes akan memberikan proses beberapa waktu (tenggang waktu) sebelum SIGKILL sinyal dikirim. Masa tenggang ini adalah 30 detik secara default; Anda dapat mengganti default dengan menggunakan grace-period flag di kubectl atau mendeklarasikan terminationGracePeriodSeconds di Podspec Anda.

kubectl delete pod <pod name> —grace-period=<seconds>

Adalah umum untuk memiliki wadah di mana proses utama tidak memiliki PID 1. Pertimbangkan wadah Python-based sampel ini:

$ kubectl exec python-app -it ps
 PID USER TIME COMMAND
 1   root 0:00 {script.sh} /bin/sh ./script.sh
 5   root 0:00 python app.py

Dalam contoh ini, skrip shell menerimaSIGTERM, proses utama, yang kebetulan merupakan aplikasi Python dalam contoh ini, tidak mendapatkan SIGTERM sinyal. Ketika Pod dihentikan, aplikasi Python akan mati secara tiba-tiba. Ini dapat diatasi dengan mengubah ENTRYPOINT wadah untuk meluncurkan aplikasi Python. Atau, Anda dapat menggunakan alat seperti dumb-init untuk memastikan bahwa aplikasi Anda dapat menangani sinyal.

Anda juga dapat menggunakan kait Container untuk mengeksekusi skrip atau permintaan HTTP saat kontainer mulai atau berhenti. T PreStop indakan kait berjalan sebelum wadah menerima SIGTERM sinyal dan harus selesai sebelum sinyal ini dikirim. terminationGracePeriodSecondsNilai berlaku dari saat tindakan PreStop hook mulai dieksekusi, bukan saat SIGTERM sinyal dikirim.

Rekomendasi

Lindungi beban kerja kritis dengan Pod Disruption Anggaran

Pod Disruption Budget atau PDB dapat menghentikan sementara proses penggusuran jika jumlah replika aplikasi turun di bawah ambang batas yang dinyatakan. Proses penggusuran akan berlanjut setelah jumlah replika yang tersedia melebihi ambang batas. Anda dapat menggunakan PDB untuk mendeklarasikan minAvailable dan maxUnavailable jumlah replika. Misalnya, jika Anda ingin setidaknya tiga salinan aplikasi Anda tersedia, Anda dapat membuat PDB.

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: my-svc-pdb
spec:
  minAvailable: 3
  selector:
    matchLabels:
      app: my-svc

Kebijakan PDB di atas memberitahu Kubernetes untuk menghentikan proses penggusuran sampai tiga atau lebih replika tersedia. Penghormatan pengeringan simpulPodDisruptionBudgets. Selama peningkatan grup node yang dikelola EKS, node dikuras dengan batas waktu lima belas menit. Setelah lima belas menit, jika pembaruan tidak dipaksakan (opsi ini disebut Pembaruan bergulir di konsol EKS), pembaruan gagal. Jika pembaruan dipaksa, pod dihapus.

Untuk node yang dikelola sendiri, Anda juga dapat menggunakan alat seperti AWS Node Termination Handler, yang memastikan bahwa bidang kontrol Kubernetes merespons dengan tepat peristiwa yang dapat menyebabkan instans EC2 Anda menjadi tidak tersedia, seperti peristiwa pemeliharaan EC2 dan interupsi EC2 Spot. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html Ini menggunakan API Kubernetes untuk mengikat node untuk memastikan tidak ada Pod baru yang dijadwalkan, kemudian mengurasnya, menghentikan Pod yang sedang berjalan.

Anda dapat menggunakan Pod anti-afinitas untuk menjadwalkan Pod Deployment pada node yang berbeda dan menghindari penundaan terkait PDB selama peningkatan node.

Berlatih rekayasa kekacauan

Chaos Engineering adalah disiplin eksperimen pada sistem terdistribusi untuk membangun kepercayaan pada kemampuan sistem untuk menahan kondisi turbulen dalam produksi.

Dalam blognya, Dominik Tornow menjelaskan bahwa Kubernetes adalah sistem deklaratif di mana "pengguna memas ok representasi dari keadaan sistem yang diinginkan ke sistem. Sistem kemudian mempertimbangkan keadaan saat ini dan keadaan yang diinginkan untuk menentukan urutan perintah untuk transisi dari keadaan saat ini ke keadaan yang diinginkan. ” Ini berarti Kubernetes selalu menyimpan status yang diinginkan dan jika sistem menyimpang, Kubernetes akan mengambil tindakan untuk memulihkan status. Misalnya, jika node pekerja menjadi tidak tersedia, Kubernetes akan menjadwal ulang Pod ke node pekerja lain. Demikian pula, jika replica crash, Deployment Contoller akan membuat yang baru. replica Dengan cara ini, pengontrol Kubernetes secara otomatis memperbaiki kegagalan.

Alat rekayasa kekacauan seperti Gremlin membantu Anda menguji ketahanan cluster Kubernetes Anda dan mengidentifikasi titik kegagalan tunggal. Alat yang memperkenalkan kekacauan buatan di cluster Anda (dan seterusnya) dapat mengungkap kelemahan sistemik, menghadirkan peluang untuk mengidentifikasi kemacetan dan kesalahan konfigurasi, dan memperbaiki masalah di lingkungan yang terkendali. Filosofi Chaos Engineering menganjurkan pemecahan sesuatu dengan sengaja dan infrastruktur pengujian stres untuk meminimalkan waktu henti yang tidak terduga.

Gunakan Service Mesh

Anda dapat menggunakan jaring layanan untuk meningkatkan ketahanan aplikasi Anda. Jaring layanan memungkinkan komunikasi layanan-ke-layanan dan meningkatkan pengamatan jaringan layanan mikro Anda. Sebagian besar produk mesh layanan bekerja dengan menjalankan proxy jaringan kecil di samping setiap layanan yang mencegat dan memeriksa lalu lintas jaringan aplikasi. Anda dapat menempatkan aplikasi Anda di mesh tanpa memodifikasi aplikasi Anda. Menggunakan fitur bawaan proxy layanan, Anda dapat membuatnya menghasilkan statistik jaringan, membuat log akses, dan menambahkan header HTTP ke permintaan keluar untuk pelacakan terdistribusi.

Jaring layanan dapat membantu Anda membuat layanan mikro Anda lebih tangguh dengan fitur-fitur seperti percobaan ulang permintaan otomatis, batas waktu, pemutusan sirkuit, dan pembatasan kecepatan.

Jika Anda mengoperasikan beberapa cluster, Anda dapat menggunakan mesh layanan untuk mengaktifkan komunikasi layanan-ke-layanan lintas-cluster.

Jaring Layanan

Observabilitas

Observabilitas adalah istilah umum yang mencakup pemantauan, pencatatan, dan penelusuran. Aplikasi berbasis layanan mikro didistribusikan secara alami. Tidak seperti aplikasi monolitik di mana pemantauan sistem tunggal sudah cukup, dalam arsitektur aplikasi terdistribusi, Anda perlu memantau kinerja setiap komponen. Anda dapat menggunakan sistem pemantauan tingkat cluster, logging, dan pelacakan terdistribusi untuk mengidentifikasi masalah di cluster Anda sebelum mengganggu pelanggan Anda.

Alat bawaan Kubernetes untuk pemecahan masalah dan pemantauan terbatas. Metrics-server mengumpulkan metrik sumber daya dan menyimpannya dalam memori tetapi tidak mempertahankannya. Anda dapat melihat log Pod menggunakan kubectl, tetapi Kubernetes tidak menyimpan log secara otomatis. Dan implementasi pelacakan terdistribusi dilakukan baik pada tingkat kode aplikasi atau menggunakan mesh layanan.

Ekstensibilitas Kubernetes bersinar di sini. Kubernetes memungkinkan Anda menghadirkan solusi pemantauan, pencatatan, dan pelacakan terpusat pilihan Anda.

Rekomendasi

Pantau aplikasi Anda

Jumlah metrik yang perlu Anda pantau dalam aplikasi modern terus bertambah. Ini membantu jika Anda memiliki cara otomatis untuk melacak aplikasi Anda sehingga Anda dapat fokus memecahkan tantangan pelanggan Anda. Cluster-wide alat pemantauan seperti Prometheus atau CloudWatch Container Insights dapat memantau cluster dan beban kerja Anda dan memberi Anda sinyal kapan, atau sebaiknya, sebelum terjadi kesalahan.

Alat pemantauan memungkinkan Anda membuat peringatan yang dapat berlangganan oleh tim operasi Anda. Pertimbangkan aturan untuk mengaktifkan alarm untuk peristiwa yang dapat, jika diperburuk, menyebabkan pemadaman atau berdampak pada kinerja aplikasi.

Jika Anda tidak jelas tentang metrik mana yang harus Anda pantau, Anda dapat mengambil inspirasi dari metode ini:

Posting Sysdig Prakti k terbaik untuk peringatan di Kubernetes mencakup daftar lengkap komponen yang dapat memengaruhi ketersediaan aplikasi Anda.

Gunakan pustaka klien Prometheus untuk mengekspos metrik aplikasi

Selain memantau status aplikasi dan menggabungkan metrik standar, Anda juga dapat menggunakan pustaka klien Prometheus untuk mengekspos metrik khusus aplikasi khusus untuk meningkatkan pengamatan aplikasi.

Gunakan alat pencatatan terpusat untuk mengumpulkan dan menyimpan log

Login EKS termasuk dalam dua kategori: log pesawat kontrol dan log aplikasi. EKS control plane logging menyediakan log audit dan diagnostik langsung dari bidang kontrol ke CloudWatch Log di akun Anda. Log aplikasi adalah log yang dihasilkan oleh Pod yang berjalan di dalam cluster Anda. Log aplikasi termasuk log yang dihasilkan oleh Pod yang menjalankan aplikasi logika bisnis dan komponen sistem Kubernetes seperti CoreDNS, Cluster Autoscaler, Prometheus, dll.

EKS menyediakan lima jenis log pesawat kontrol:

Manajer pengontrol dan log penjadwal dapat membantu mendiagnosis masalah bidang kontrol seperti kemacetan dan kesalahan. Secara default, log pesawat kontrol EKS tidak dikirim ke CloudWatch Log. Anda dapat mengaktifkan pencatatan bidang kontrol dan memilih jenis log pesawat kontrol EKS yang ingin Anda tangkap untuk setiap cluster di akun Anda

Mengumpulkan log aplikasi memerlukan pemasangan alat agregator log seperti Flu ent Bit, Fluentd, atau Con CloudWatch tainer Insights di cluster Anda.

Alat agregator log Kubernetes berjalan sebagai DaemonSets dan mengikis log kontainer dari node. Log aplikasi kemudian dikirim ke tujuan terpusat untuk penyimpanan. Misalnya, Con CloudWatch tainer Insights dapat menggunakan Fluent Bit atau Fluentd untuk mengumpulkan log dan mengirimkannya ke CloudWatch Log untuk disimpan. Fluent Bit dan Fluentd mendukung banyak sistem analisis log populer seperti Elasticsearch dan InfluxDB yang memberi Anda kemampuan untuk mengubah backend penyimpanan untuk log Anda dengan memodifikasi Fluent bit atau konfigurasi log Fluentd.

Gunakan sistem pelacakan terdistribusi untuk mengidentifikasi hambatan

Aplikasi modern yang khas memiliki komponen yang didistribusikan melalui jaringan, dan keandalannya tergantung pada berfungsinya masing-masing komponen yang membentuk aplikasi. Anda dapat menggunakan solusi pelacakan terdistribusi untuk memahami bagaimana permintaan mengalir dan bagaimana sistem berkomunikasi. Jejak dapat menunjukkan kepada Anda di mana hambatan ada di jaringan aplikasi Anda dan mencegah masalah yang dapat menyebabkan kegagalan bertingkat.

Anda memiliki dua opsi untuk mengimplementasikan pelacakan dalam aplikasi Anda: Anda dapat menerapkan penelusuran terdistribusi pada tingkat kode menggunakan pustaka bersama atau menggunakan mesh layanan.

Menerapkan pelacakan pada tingkat kode dapat merugikan. Dalam metode ini, Anda harus membuat perubahan pada kode Anda. Ini lebih rumit jika Anda memiliki aplikasi poliglot. Anda juga bertanggung jawab untuk memelihara perpustakaan lain, di seluruh layanan Anda.

Service Meshes seperti LinkerD dan Istio dapat digunakan untuk mengimplementasikan pelacakan terdistribusi dalam aplikasi Anda dengan sedikit perubahan pada kode aplikasi. Anda dapat menggunakan service mesh untuk menstandarkan pembuatan, pencatatan, dan pelacakan metrik.

Alat pelacakan seperti AWS X-Ray, Jaeger mendukung implementasi perpustakaan bersama dan layanan mesh.

Pertimbangkan untuk menggunakan alat pelacakan seperti AWS X-Ray atau Jaeger yang mendukung implementasi (perpustakaan bersama dan mesh layanan) sehingga Anda tidak perlu beralih alat jika nanti Anda mengadopsi service mesh.