Mengatur solusi platform aplikasi modern

  • Artikel

Cloud Adoption Framework menyediakan metodologi untuk secara sistematis dan bertahap meningkatkan tata kelola portofolio cloud Anda. Artikel ini menunjukkan cara Anda dapat memperluas pendekatan tata kelola ke kluster Kubernetes yang disebarkan ke Azure atau cloud publik atau pribadi lainnya.

Dasar tata kelola awal

Tata kelola dimulai dengan dasar tata kelola awal yang sering disebut sebagai MVP tata kelola. Dasar ini menyebarkan produk dasar Azure yang diperlukan untuk memberikan tata kelola di seluruh lingkungan {i>cloud

Dasar tata kelola awal berfokus pada aspek-aspek tata kelola berikut:

  • Konektivitas dan jaringan hibrida dasar.
  • Kontrol akses berbasis peran Azure (RBAC) untuk kontrol identitas dan akses.
  • Standar penamaan dan {i>tag
  • Organisasi sumber daya yang menggunakan grup sumber daya, langganan, dan grup manajemen.
  • Azure Policy dan Azure Blueprints untuk menegakkan kebijakan tata kelola.

Fitur-fitur dari dasar tata kelola awal ini dapat digunakan untuk mengatur instans solusi platform aplikasi modern. Namun pertama-tama, Anda harus menambahkan beberapa komponen ke dasar awal untuk menerapkan Azure Policy ke kontainer Anda. Setelah dikonfigurasi, Anda dapat menggunakan Azure Policy dan dasar tata kelola awal Anda untuk mengatur jenis kontainer berikut:

Memperluas disiplin tata kelola

Landasan tata kelola awal dapat digunakan untuk memperluas berbagai disiplin tata kelola untuk memastikan pendekatan penyebaran yang konsisten dan stabil di semua instans Kubernetes Anda.

Tata kelola kluster Kubernetes dapat dilihat dengan lima perspektif berbeda.

Tata kelola sumber daya Azure

Yang pertama adalah perspektif sumber daya Azure. Memastikan bahwa semua kluster mematuhi persyaratan organisasi Anda. Ini termasuk konsep seperti topologi jaringan, kluster privat, peran Azure RBAC untuk tim SRE, pengaturan diagnostik, ketersediaan wilayah, pertimbangan kumpulan node, tata kelola Azure Container Registry, opsi Azure Load Balancer, add-on AKS, pengaturan diagnostik, dan sebagainya. Tata kelola ini memastikan konsistensi dalam "tampilan dan nuansa" dan "topologi" kluster di organisasi Anda. Ini juga harus meluas ke pasca bootstrap penyebaran kluster, seperti agen keamanan apa yang harus dipasang dan bagaimana konfigurasinya.

Kluster Snowflake sulit diatur dalam kapasitas pusat mana pun. Minimalkan perbedaan antarkluster sehingga kebijakan dapat menerapkan kluster secara seragam dan kluster anomali tidak disarankan dan terdeteksi. Ini mungkin juga termasuk teknologi yang digunakan untuk menyebarkan kluster, seperti ARM, Bicep, atau Terraform.

Azure Policy yang diterapkan di tingkat grup/langganan manajemen dapat membantu menyampaikan banyak pertimbangan ini, namun tidak semuanya.

Tata kelola beban kerja Kubernetes

Karena Kubernetes itu sendiri adalah platform, yang kedua adalah tata kelola terhadap apa yang terjadi dalam sebuah kluster. Ini akan mencakup hal-hal seperti panduan namespace, kebijakan jaringan, RBAC Kubernetes, batas, dan kuota. Ini akan menjadi tata kelola yang diterapkan pada beban kerja, lebih sedikit pada kluster. Setiap beban kerja akan menjadi unik, karena semuanya memecahkan masalah bisnis yang berbeda dan akan diterapkan dalam berbagai cara dengan berbagai teknologi. Mungkin tidak ada banyak praktik tata kelola "satu ukuran cocok untuk semua", namun Anda harus mempertimbangkan tata kelola di sekitar pembuatan/konsumsi artefak OCI, persyaratan rantai pasokan, penggunaan registri kontainer publik, proses karantina gambar, tata kelola alur penyebaran.

Pertimbangkan standardisasi seputar perkakas dan pola umum juga, jika memungkinkan untuk dilakukan. Ajukan rekomendasi tentang teknologi seperti Helm, mesh layanan, pengontrol ingress, operator GitOps, volume persisten, dan sebagainya. Termasuk di sini juga akan menjadi tata kelola seputar penggunaan identitas terkelola pod dan rahasia sumber dari Key Vault.

Mendorong harapan yang kuat seputar akses ke telemetri, untuk memastikan pemilik beban kerja memiliki akses yang tepat ke metrik dan data yang dibutuhkan untuk meningkatkan produknya, sementara juga memastikan operator kluster memiliki akses ke telemetri sistem untuk meningkatkan penawaran layanannya. Data kerap perlu berkorelasi silang antara keduanya, pastikan kebijakan tata kelola ada untuk memastikan akses yang tepat bila diperlukan.

Azure Policy for AKS yang diterapkan di tingkat kluster dapat membantu menyampaikan beberapa di antaranya, namun tidak semua.

Peran operator kluster (Azure DevOps, SRE)

Yang ketiga adalah tata kelola seputar peran operator kluster. Bagaimana cara tim SRE berinteraksi dengan kluster? Apa hubungan antara tim tersebut dan tim beban kerja. Apakah keduanya sama? Operator kluster harus memiliki playbook yang jelas untuk aktivitas triase kluster, seperti bagaimana mereka mengakses kluster, dari mana mereka mengakses kluster, dan izin apa yang dimiliki pada kluster, dan kapan izin tersebut ditetapkan. Pastikan setiap perbedaan dibuat dalam dokumentasi tata kelola, kebijakan, dan materi pelatihan seputar operator beban kerja vs operator kluster dalam konteks ini. Tergantung pada organisasi Anda, mereka mungkin sama.

Kluster per beban kerja atau banyak beban kerja per kluster

Keempat adalah tata kelola multipenyewaan. Artinya jika kluster berisi "pengelompokan seperti" aplikasi yang dimiliki, menurut definisi, semua oleh tim beban kerja yang sama dan mewakili satu set komponen beban kerja terkait. Atau jika kluster, berdasarkan desainnya, bersifat multipenyewa dengan beberapa beban kerja dan pemilik beban kerja yang berbeda; berjalan dan diatur seperti penawaran layanan terkelola dalam organisasi. Strategi tata kelola sangat berbeda masing-masingnya, dan dengan demikian Anda harus mengatur agar strategi yang Anda pilih diberlakukan. Jika Anda harus mendukung kedua model, pastikan rencana tata kelola Anda didefinisikan dengan jelas untuk kebijakan mana yang berlaku untuk jenis kluster mana.

Pilihan ini seharusnya dibuat selama fase Strategi karena memiliki dampak signifikan terhadap kepegawaian, penganggaran, dan inovasi.

Upaya tetap terkini

Yang kelima adalah seputar operasi, seperti kesegaran gambar node (patching) dan penerapan versi Kubernetes. Siapa yang bertanggung jawab atas peningkatan gambar node, melacak patch yang diterapkan, melacak dan menyusun rencana remediasi untuk kerentanan dan paparan umum Kubernetes dan AKS? Tim beban kerja perlu dilibatkan dalam memvalidasi pekerjaan solusinya pada peningkatan kluster, dan jika kluster Anda tidak dalam versi terkini, mereka akan keluar dari Dukungan Azure. Memiliki tata kelola yang kuat di sekitar upaya "tetap terkini" sangat penting dalam AKS, terlebih lagi sebagian besar platform lain di Azure. Ini akan memerlukan hubungan kerja yang sangat erat dengan tim aplikasi dan waktu khusus oleh mereka, setidaknya setiap bulan, untuk validasi beban kerja guna memastikan kluster tetap terkini. Pastikan semua tim yang bergantung pada Kubernetes memahami persyaratan dan biaya upaya berkelanjutan ini, yang akan berlangsung selama mereka berada di platform.

Dasar keamanan

Praktik terbaik berikut dapat ditambahkan ke garis besar keamanan Anda, untuk memperhitungkan keamanan kluster AKS Anda:

Identitas

Ada banyak praktik terbaik yang dapat Anda terapkan pada garis besar identitas Anda untuk memastikan identitas dan manajemen akses yang konsisten di seluruh kluster Kubernetes Anda:

Langkah berikutnya: Mengelola solusi platform aplikasi modern

Artikel berikut akan membawa Anda ke panduan pada titik-titik tertentu dalam perjalanan adopsi cloud untuk membantu Anda berhasil dalam skenario adopsi cloud.