Share via

Pertimbangan manajemen operasi untuk Azure Kubernetes Service

  • Artikel

Kubernetes adalah teknologi yang relatif baru, berkembang pesat dengan ekosistem yang mengesankan. Dengan demikian, mungkin sulit untuk mengelola dan melindunginya.

Garis besar operasi untuk AKS

Anda dapat bekerja menuju keunggulan operasional dan keberhasilan pelanggan dengan merancang solusi Azure Kubernetes Service (AKS) Anda dengan tepat dengan mempertimbangkan manajemen dan pemantauan.

Mempertimbangkan rancangan

Pertimbangkan faktor berikut:

  • Ketahui batas AKS. Gunakan beberapa instans AKS untuk menskalakan melampaui batas tersebut.
  • Ketahui cara mengisolasi beban kerja secara logis dalam kluster dan secara fisik dalam kluster terpisah.
  • Ketahui cara mengontrol penggunaan sumber daya berdasarkan beban kerja.
  • Ketahui cara membantu Kubernetes memahami kesehatan beban kerja Anda.
  • Waspadai berbagai ukuran komputer virtual dan dampak penggunaan satu atau yang lain. VM yang lebih besar dapat menangani lebih banyak beban. VM yang lebih kecil dapat lebih mudah digantikan oleh VM lain saat tidak tersedia untuk pemeliharaan yang direncanakan dan tidak direncanakan. Selain itu, waspadai kumpulan simpul dan VM dalam set skala, memungkinkan komputer virtual dengan ukuran yang berbeda dalam kluster yang sama. VM yang lebih besar lebih optimal karena AKS mencadangkan persentase sumber daya yang lebih kecil, membuat lebih banyak sumber dayanya tersedia untuk beban kerja Anda.
  • Ketahui cara memantau dan mencatat AKS. Kubernetes terdiri dari berbagai komponen, dan pemantauan dan pengelogan harus memberikan wawasan tentang kesehatan, tren, dan potensi masalahnya.
  • Dibangun pada pemantauan dan pengelogan, mungkin ada banyak peristiwa yang dihasilkan oleh Kubernetes atau aplikasi yang berjalan di atas. Peringatan dapat membantu membedakan antara entri log untuk tujuan historis dan yang memerlukan tindakan segera.
  • Ketahui pembaruan dan peningkatan yang harus Anda lakukan. Pada tingkat Kubernetes, ada versi utama, minor, dan patch. Pelanggan harus menerapkan pembaruan ini untuk tetap didukung sesuai dengan kebijakan di Kubernetes upstram. Di tingkat host pekerja, patch kernel OS mungkin memerlukan boot ulang, yang harus dilakukan pelanggan, dan meningkatkan ke versi OS baru. Selain meningkatkan kluster secara manual, Anda dapat mengatur saluran peningkatan otomatis di kluster Anda.
  • Waspadai keterbatasan sumber daya kluster dan beban kerja individual.
  • Ketahui perbedaan antara autoscaler pod horizontal dan autoscaler kluster
  • Pertimbangkan untuk mengamankan lalu lintas antarpod menggunakan kebijakan jaringan dan plug-in kebijakan Azure
  • Untuk membantu memecahkan masalah aplikasi dan layanan yang berjalan di AKS, Anda mungkin perlu melihat log yang dihasilkan oleh komponen sarana kontrol. Anda mungkin ingin mengaktifkan log sumber daya untuk AKS karena pengelogan tidak diaktifkan secara default.

Rekomendasi

  • Memahami batas AKS:

  • Gunakan isolasi logis di tingkat namespace layanan untuk memisahkan aplikasi, tim, lingkungan, dan unit bisnis. Isolasi multipenyewaan dan kluster. Selain itu, kumpulan simpul dapat membantu pada simpul dengan spesifikasi simpul yang berbeda, dan pemeliharaan seperti Kubernetes meningkatkan beberapa kumpulan simpul

  • Rencanakan dan terapkan kuota sumber daya di tingkat namespace. Jika pod tidak menentukan permintaan dan batasan sumber daya, tolak penyebaran menggunakan kebijakan, dan sebagainya. Ini tidak berlaku untuk pod kube-system karena tidak semua pod kube-system memiliki permintaan dan batasan. Pantau penggunaan sumber daya dan sesuaikan kuota sesuai kebutuhan. Fitur penjadwal dasar

  • Tambahkan probe kesehatan ke pod Anda. Pastikan pod berisi livenessProbe, readinessProbe, dan startupProbeprobe kesehatan AKS.

  • Gunakan ukuran VM yang cukup besar untuk berisi beberapa instans kontainer, sehingga Anda mendapatkan manfaat dari kepadatan yang ditingkatkan, tetapi tidak begitu besar sehingga kluster Anda tidak dapat menangani beban kerja simpul yang gagal.

  • Gunakan solusi pemantauan. Wawasan kontainer Azure Monitor disiapkan secara default dan memberikan akses mudah ke banyak wawasan. Anda dapat menggunakan integrasi Prometheus jika ingin mendalami atau memiliki pengalaman menggunakan Prometheus. Jika juga ingin menjalankan aplikasi pemantauan di AKS, Anda harus menggunakan Azure Monitor untuk memantau aplikasi tersebut.

  • Gunakan pemberitahuan metrik wawasan kontainer Azure Monitor untuk memberikan pemberitahuan saat hal-hal memerlukan tindakan langsung.

  • Gunakan fitur penskalaan kumpulan node otomatis bersama dengan autoscaler pod horizontal guna memenuhi permintaan aplikasi dan mengurangi beban jam sibuk.

  • Gunakan Azure Advisor untuk mendapatkan rekomendasi praktik terbaik tentang biaya, keamanan, keandalan, keunggulan operasional, dan performa. Selain itu, gunakan Microsoft Defender untuk Cloud untuk mencegah dan mendeteksi ancaman seperti kerentanan gambar.

  • Gunakan Kubernetes yang didukung Azure Arc untuk mengelola kluster Kubernetes non-AKS di Azure menggunakan Azure Policy, Defender for Cloud, GitOps, dan sebagainya.

  • Gunakan permintaan dan batasan pod untuk mengelola sumber daya komputasi dalam kluster AKS. Permintaan dan batasan Pod menginformasikan penjadwal Kubernetes tentang sumber daya komputasi mana yang akan ditetapkan ke pod.

Kelangsungan bisnis/pemulihan bencana untuk melindungi dan memulihkan AKS

Organisasi Anda perlu merancang kemampuan tingkat platform Azure Kubernetes Service (AKS) yang sesuai untuk memenuhi persyaratan spesifiknya. Layanan aplikasi ini memiliki persyaratan terkait tujuan waktu pemulihan (RTO) dan tujuan titik pemulihan (RPO). Ada beberapa pertimbangan untuk mengatasi pemulihan bencana AKS. Langkah pertama Anda adalah menentukan perjanjian tingkat layanan (SLA) untuk infrastruktur dan aplikasi Anda. Pelajari tentang SLA untuk Azure Kubernetes Service (AKS). Lihat bagian Detail SLA untuk informasi tentang perhitungan waktu aktif bulanan.

Mempertimbangkan rancangan

Pertimbangkan faktor berikut:

  • Kluster AKS harus menggunakan beberapa node dalam kumpulan node untuk memberikan tingkat ketersediaan minimum untuk aplikasi Anda.

  • Tetapkan Permintaan dan batas pod. Menetapkan batas ini memungkinkan Kubernetes:

    • Secara efisien memberikan sumber daya CPU dan memori ke pod.
    • Memiliki kepadatan kontainer yang lebih tinggi pada node.

    Batas juga dapat meningkatkan keandalan melalui pengurangan biaya karena penggunaan perangkat keras yang lebih baik.

  • Kesesuaian AKS untuk Zona Ketersediaan atau set ketersediaan.

    • Pilih wilayah yang mendukung Zona Ketersediaan.
    • Zona Ketersediaan hanya dapat diatur saat kumpulan node dibuat dan tidak dapat diubah nanti. Dukungan multizona hanya berlaku untuk kumpulan node.
    • Untuk manfaat zonal lengkap, semua dependensi layanan juga harus mendukung zona. Jika layanan dependen tidak mendukung zona, kegagalan zona dapat menyebabkan layanan tersebut gagal.
    • Jalankan beberapa kluster AKS di wilayah berpasangan yang berbeda untuk ketersediaan yang lebih tinggi di luar apa yang dapat dicapai Zona Ketersediaan. Jika sumber daya Azure mendukung geo-redundansi, berikan lokasi di mana layanan redundan memiliki wilayah sekundernya.

  • Anda harus mengetahui panduan pemulihan bencana di AKS. Kemudian pertimbangkan apakah hal ini berlaku untuk kluster AKS yang Anda gunakan untuk Azure Dev Spaces.

  • Secara konsisten buat cadangan untuk aplikasi dan data.

    • Layanan tidak berstatus (non-stateful) dapat direplikasi secara efisien.
    • Jika Anda perlu menyimpan status dalam kluster, seringlah mencadangkan data di wilayah yang dipasangkan. Salah satu pertimbangannya adalah bahwa menyimpan status dalam kluster dengan benar dapat menjadi rumit.

  • Pembaruan dan pemeliharaan kluster.

    • Selalu perbarui kluster Anda.
    • Waspadai proses perilisan dan penghentian.
    • Rencanakan pembaruan dan pemeliharaan Anda.

  • Konektivitas jaringan jika failover terjadi.

    • Pilih router lalu lintas yang dapat mendistribusikan lalu lintas di seluruh zona atau wilayah, tergantung pada kebutuhan Anda. Arsitektur ini menyebarkan Azure Load Balancer karena dapat mendistribusikan lalu lintas non-web di seluruh zona.
    • Jika Anda perlu mendistribusikan lalu lintas di lintas wilayah, pertimbangkan untuk menggunakan Azure Front Door.

  • Failover yang direncanakan dan tidak direncanakan.

    • Saat menyiapkan setiap layanan Azure, pilih fitur yang mendukung pemulihan bencana. Misalnya, arsitektur ini memungkinkan Azure Container Registry untuk replikasi geografis. Anda masih dapat menarik gambar dari wilayah yang direplikasi jika suatu wilayah tidak berfungsi.

  • Pertahankan kemampuan DevOps rekayasa untuk mencapai tujuan tingkat layanan.

  • Tentukan apakah Anda memerlukan SLA yang didukung secara finansial untuk titik akhir server API Kubernetes Anda.

Rekomendasi desain

Berikut ini adalah praktik terbaik untuk desain Anda:

  • Gunakan tiga node untuk kumpulan node sistem. Untuk kumpulan node pengguna, mulailah dengan minimal dua node. Jika Anda membutuhkan ketersediaan yang lebih tinggi, siapkan lebih banyak node.

  • Isolasi aplikasi Anda dari layanan sistem dengan menempatkannya di kumpulan node terpisah. Dengan cara ini, layanan Kubernetes berjalan pada node khusus dan tidak bersaing dengan layanan lain. Gunakan tag, label, dan taint untuk mengidentifikasi kumpulan node untuk menjadwalkan beban kerja Anda.

  • Secara rutin, peliharalah kluster Anda, misalnya, melakukan pembaruan tepat waktu, sangat penting untuk keandalan. Perhatikan jendela dukungan untuk versi Kubernetes di AKS dan rencanakan pembaruan Anda. Selain itu, memantau kesehatan pod melalui probe dianjurkan.

  • Jika memungkinkan, hapus status layanan dari dalam kontainer. Sebagai gantinya, gunakan platform Azure sebagai layanan (PaaS) yang mendukung replikasi multi-wilayah.

  • Pastikan sumber daya pod. Sangat disarankan agar penyebaran menentukan persyaratan sumber daya pod. Penjadwal kemudian dapat menjadwalkan pod dengan tepat. Keandalan terdepresiasi ketika pod tidak dijadwalkan.

  • Siapkan beberapa replika dalam penyebaran untuk menangani gangguan seperti kegagalan perangkat keras. Untuk peristiwa yang direncanakan seperti pembaruan dan peningkatan, anggaran gangguan dapat memastikan jumlah replika pod yang diperlukan ada untuk menangani beban aplikasi yang diharapkan.

  • Aplikasi Anda dapat menggunakan Azure Storage untuk datanya. Karena aplikasi Anda tersebar di beberapa kluster AKS di berbagai wilayah, Anda harus menjaga penyimpanan tetap sinkron. Berikut adalah dua cara umum untuk mereplikasi penyimpanan:

    • Replikasi asinkron berbasis infrastruktur
    • Replikasi asinkron berbasis aplikasi

  • Perkirakan batas pod. Uji dan tetapkan garis besar. Mulailah dengan nilai yang sama untuk permintaan dan batas. Kemudian, secara bertahap atur nilai-nilai tersebut sampai Anda menetapkan ambang yang dapat menyebabkan ketidakstabilan dalam kluster. Batas pod dapat ditentukan dalam manifes penyebaran Anda.

    Fitur bawaan memberikan solusi untuk tugas yang kompleks dalam menangani kegagalan dan gangguan dalam arsitektur layanan. Konfigurasi ini membantu menyederhanakan otomatisasi desain dan penyebaran. Jika sebuah organisasi telah menetapkan standar untuk SLA, RTO, dan RPO, organisasi tersebut dapat menggunakan layanan bawaan pada Kubernetes dan Azure untuk mencapai tujuan bisnisnya.

  • Tetapkan anggaran gangguan pod. Pengaturan ini memeriksa seberapa banyak replika dalam penyebaran yang dapat Anda turunkan fungsinya selama peristiwa pembaruan atau peningkatan.

  • Terapkan kuota sumber daya di namespace layanan. Kuota sumber daya pada namespace memastikan permintaan dan batas pod diatur dengan benar pada penyebaran.

    • Mengatur kuota sumber daya di tingkat kluster dapat menyebabkan masalah saat menyebarkan layanan mitra yang tidak memiliki permintaan dan batas yang tepat.

  • Simpan gambar kontainer Anda di Azure Container Registry dan lakukan replikasi geo pada registri ke setiap wilayah AKS.

  • Gunakan SLA Waktu Aktif untuk mengaktifkan SLA yang didukung secara finansial dan lebih tinggi untuk semua kluster yang menghosting beban kerja produksi. Waktu aktif SLA menjamin ketersediaan 99,95% titik akhir server API Kubernetes untuk kluster yang menggunakan Zona Ketersediaan dan 99,9% ketersediaan untuk kluster yang tidak menggunakan Zona Ketersediaan. Simpul, kumpulan simpul, dan sumber daya lainnya Anda tercakup dalam SLA mereka. AKS menawarkan tingkat gratis dengan tujuan tingkat layanan (SLO) 99,5% untuk komponen sarana kontrolnya. Kluster tanpa SLA Waktu Aktif diaktifkan tidak boleh digunakan untuk beban kerja produksi.

  • Gunakan beberapa wilayah dan lokasi peering untuk konektivitas Azure ExpressRoute.

    Jika pemadaman yang memengaruhi wilayah Azure atau lokasi penyedia peering terjadi, arsitektur jaringan hibrid yang redundan dapat membantu memastikan konektivitas lintas lokasi tanpa gangguan.

  • Hubungkan wilayah dengan peering jaringan virtual global. Jika kluster perlu berkomunikasi dengan satu sama lain, menghubungkan kedua jaringan virtual ke satu sama lain dapat dicapai melalui peering jaringan virtual. Teknologi ini saling menghubungkan jaringan virtual satu sama lain, menyediakan bandwidth tinggi di seluruh jaringan backbone Microsoft, bahkan di berbagai wilayah geografis.

  • Menggunakan protokol anycast berbasis TCP terpisah, Azure Front Door Service segera menyambungkan pengguna akhir Anda ke Front Door point of presence terdekat. Fitur lainnya pada Azure Front Door Service meliputi:

    • Penghentian TLS
    • Domain kustom
    • Web Application Firewall
    • Penulisan ulang URL
    • Afinitas sesi

    Tinjau kebutuhan lalu lintas aplikasi Anda untuk mempelajari solusi mana yang paling cocok.