Panduan garis besar operasi untuk Azure Red Hat OpenShift

  • Artikel

Azure Red Hat OpenShift menyediakan kluster OpenShift yang sangat dapat diskalakan dan dikelola sepenuhnya sesuai permintaan. Dengan merancang solusi Anda dengan mempertimbangkan manajemen dan pemantauan dengan benar, Anda dapat bekerja menuju keunggulan operasional dan keberhasilan pelanggan.

Mempertimbangkan rancangan

Pertimbangkan faktor-faktor berikut:

  • Tinjau matriks tanggung jawab Azure Red Hat OpenShift untuk memahami bagaimana tanggung jawab untuk kluster dibagikan antara Microsoft, Red Hat, dan pelanggan.
  • Waspadai batas komputer virtual Azure dan wilayah yang didukung. Pastikan ada kapasitas yang tersedia untuk menyebarkan sumber daya.
  • Ketahui cara mengisolasi beban kerja secara logis dalam kluster dan secara fisik dalam kluster terpisah.
  • Ketahui cara membantu Kubernetes memahami kesehatan beban kerja Anda.
  • Waspadai berbagai ukuran komputer virtual dan efek menggunakan satu atau yang lain.
  • Perhatikan cara-cara untuk memantau dan mencatat Azure Red Hat OpenShift untuk mendapatkan wawasan tentang kesehatan sumber daya Anda dan untuk memperkirakan potensi masalah. Baik kluster maupun aplikasi yang berjalan di atas dapat menghasilkan banyak peristiwa. Gunakan pemberitahuan untuk membantu membedakan antara entri log untuk tujuan historis dan entri yang memerlukan tindakan segera.
  • Waspadai pembaruan dan peningkatan sistem penting. Pembaruan patch penting diterapkan ke kluster secara otomatis oleh teknisi keandalan situs (SRE) Azure Red Hat OpenShift. Pelanggan yang ingin menginstal pembaruan patch terlebih dahulu bebas untuk melakukannya.
  • Waspadai keterbatasan sumber daya kluster dan beban kerja individual.
  • Perhatikan perbedaan antara autoscaler pod horizontal dan penskalaan otomatis kluster.
  • Tinjau siklus hidup dukungan dan pahami kebijakan dukungan versi. Azure Red Hat OpenShift hanya mendukung rilis minor Platform Kontainer Red Hat OpenShift saat ini dan sebelumnya yang tersedia secara umum . Permintaan dukungan mengharuskan kluster berada dalam versi yang didukung.
  • Tinjau persyaratan konfigurasi kluster untuk menjaga dukungan kluster.
  • Tinjau jaringan lintas namespace layanan untuk mengamankan lalu lintas dalam kluster menggunakan kebijakan jaringan.

Rekomendasi desain

  • Azure Red Hat OpenShift memiliki ekosistem operator yang kaya dan harus digunakan untuk melakukan dan mengotomatiskan aktivitas operasional dengan efisiensi dan akurasi.
  • Tambahkan pemeriksaan kesehatan ke pod Anda untuk memantau kesehatan aplikasi. Pastikan pod berisi livenessProbe dan readinessProbe. Gunakan pemeriksaan Startup untuk menentukan titik di mana aplikasi telah dimulai.
  • Gunakan ukuran komputer virtual yang cukup besar untuk berisi beberapa instans kontainer sehingga Anda mendapatkan manfaat dari peningkatan kepadatan, tetapi tidak begitu besar sehingga kluster Anda tidak dapat menangani beban kerja simpul yang gagal.
  • Mengatur fungsi kluster menggunakan plug-in penerimaan, yang umumnya digunakan untuk menegakkan kebijakan keamanan, batasan sumber daya, atau persyaratan konfigurasi.
  • Gunakan permintaan dan batasan pod untuk mengelola sumber daya komputasi dalam kluster. Permintaan dan batasan Pod menginformasikan penjadwal Kubernetes, yang menetapkan sumber daya komputasi ke pod. Batasi konsumsi sumber daya dalam proyek menggunakan rentang batas.
  • Optimalkan nilai permintaan CPU dan memori, dan maksimalkan efisiensi sumber daya kluster menggunakan autoscaler pod vertikal.
  • Konsol web OpenShift berisi semua metrik di tingkat simpul. Buat proses pemantauan menggunakan integrasi Prometheus atau Container Insights bawaan.
    • Prometheus sudah diinstal sebelumnya dan dikonfigurasi untuk kluster Azure Red Hat OpenShift 4.x.
    • Container Insights dapat diaktifkan dengan onboarding kluster ke Kubernetes dengan dukungan Azure Arc.
    • Pengelogan OpenShift menyebarkan komponen agregator log, penyimpanan, dan visualisasi.
  • Otomatiskan proses pengiriman aplikasi melalui praktik DevOps dan solusi CI/CD, seperti Pipelines/GitOps yang disediakan oleh OpenShift Container Platform.
  • Tentukan ClusterAutoScaler dan MachineAutoScaler untuk menskalakan komputer saat kluster Anda kehabisan sumber daya untuk mendukung lebih banyak penyebaran.
  • Sebarkan pemeriksaan kesehatan mesin untuk memperbaiki komputer yang rusak secara otomatis di kumpulan komputer.
  • Skalakan pod untuk memenuhi permintaan menggunakan autoscaler pod horizontal.
  • Gunakan sistem peringatan untuk memberikan pemberitahuan saat hal-hal memerlukan tindakan langsung: Pemberitahuan metrik Wawasan Kontainer atau UI Pemberitahuan bawaan.

Keberlangsungan Bisnis dan Pemulihan Bencana (BCDR)

Organisasi Anda perlu merancang kemampuan tingkat platform Azure Red Hat OpenShift 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. Langkah pertama Anda adalah menentukan perjanjian tingkat layanan (SLA) untuk infrastruktur dan aplikasi Anda. Pelajari tentang SLA untuk Azure Red Hat OpenShift. Lihat bagian Detail SLA untuk informasi tentang perhitungan waktu aktif bulanan.

Pertimbangan desain untuk BCDR

Pertimbangkan faktor-faktor berikut:

  • Kluster Azure Red Hat OpenShift harus menggunakan beberapa set komputer untuk memberikan tingkat ketersediaan minimum untuk aplikasi Anda.
  • Tetapkan Permintaan dan batas pod. Menetapkan batas ini memungkinkan Kubernetes:
    • Tetapkan sumber daya CPU dan memori secara efisien ke pod.
    • Memiliki kepadatan kontainer yang lebih tinggi pada node.
    • Tingkatkan keandalan dengan pengurangan biaya karena penggunaan perangkat keras yang lebih baik.
  • Sebarkan simpul di semua zona yang tersedia untuk ketersediaan yang lebih tinggi.
    • Pilih wilayah yang mendukung Zona Ketersediaan.
    • Untuk manfaat zonal lengkap, semua dependensi layanan juga harus mendukung zona. Jika layanan dependen tidak mendukung zona, ada kemungkinan kegagalan zona dapat menyebabkan layanan tersebut gagal. Tinjau jenis disk yang digunakan saat menyebarkan beban kerja di seluruh zona.
    • Untuk ketersediaan yang lebih tinggi di luar apa yang dapat dicapai Zona Ketersediaan, jalankan beberapa kluster di wilayah berpasangan yang berbeda. Jika sumber daya Azure mendukung redundansi geografis, berikan lokasi layanan yang redundan akan memiliki wilayah sekundernya.
  • 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.
  • Tingkatkan dan pertahankan kluster Anda.
  • Untuk konektivitas jaringan jika terjadi failover:
    • Jika Anda perlu mendistribusikan lalu lintas di lintas wilayah, pertimbangkan untuk menggunakan Azure Front Door.
  • Untuk failover yang direncanakan dan tidak direncanakan:
    • Saat menyiapkan setiap layanan Azure, pilih fitur yang mendukung pemulihan bencana. Misalnya, jika Azure Container Registry dipilih, aktifkan untuk replikasi geografis. Jika suatu wilayah tidak berfungsi, Anda masih dapat menarik gambar dari wilayah yang direplikasi.
  • Pertahankan kemampuan DevOps rekayasa untuk mencapai tujuan tingkat layanan.

Rekomendasi desain untuk BCDR

Berikut ini adalah praktik terbaik untuk desain Anda:

  • Kluster Azure Red Hat OpenShift disediakan dengan tiga simpul sarana kontrol dan tiga simpul pekerja atau lebih. Pastikan bahwa kluster dibuat di wilayah yang mendukung Zona Ketersediaan sehingga simpul tersebar di seluruh zona.
  • Untuk ketersediaan tinggi, sebarkan simpul ini ke Zona Ketersediaan yang berbeda. Karena Anda memerlukan set komputer yang berbeda untuk setiap Zona Ketersediaan, buat setidaknya tiga set komputer.
  • Jangan menjalankan beban kerja tambahan pada simpul sarana kontrol. Meskipun dapat dijadwalkan pada simpul sarana kontrol, itu akan menyebabkan masalah penggunaan sumber daya tambahan dan stabilitas yang dapat memengaruhi seluruh kluster.
  • Buat set komputer infrastruktur untuk menyimpan komponen infrastruktur. Terapkan label Kubernetes tertentu ke komputer ini lalu perbarui komponen infrastruktur untuk hanya berjalan pada komputer tersebut.
  • Jika memungkinkan, hapus status layanan dari dalam kontainer. Sebagai gantinya, gunakan platform Azure sebagai layanan (PaaS) yang mendukung replikasi multi-wilayah.
  • Penyebaran harus menentukan persyaratan sumber daya pod. Penjadwal kemudian dapat menjadwalkan pod dengan tepat. Keandalan terdepresiasi secara signifikan 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.
  • Gunakan batasan topologi pod untuk menjadwalkan pod secara otomatis pada simpul di seluruh kluster.
  • Aplikasi Anda mungkin menggunakan penyimpanan untuk data mereka dan harus memastikan ketersediaan di seluruh wilayah jika diperlukan:
  • Buat cadangan aplikasi dan rencanakan untuk pemulihan:
  • Memperkirakan batas sumber daya 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. Autoscaler pod vertikal mengoptimalkan nilai permintaan CPU dan memori dan dapat memaksimalkan efisiensi sumber daya kluster.
    • Fitur bawaan dapat menangani kegagalan dan gangguan dalam arsitektur layanan. Konfigurasi ini membantu menyederhanakan otomatisasi desain dan penyebaran. Ketika organisasi mendefinisikan standar untuk SLA, RTO, dan RPO, organisasi dapat menggunakan layanan yang disertakan dalam Kubernetes dan Azure untuk mencapai tujuan bisnis.
  • Pertimbangkan strategi biru/hijau atau kenari untuk menyebarkan rilis aplikasi baru.
  • Atur anggaran gangguan pod/prioritas pod untuk membatasi jumlah replika pod yang diizinkan untuk diturunkan kluster untuk operasi pemeliharaan, sehingga memastikan ketersediaan.
  • Menerapkan kuota sumber daya pada namespace layanan. Kuota sumber daya pada namespace akan memastikan permintaan dan batas pod diatur dengan benar pada penyebaran.
    • Menetapkan kuota sumber daya di tingkat kluster dapat menyebabkan masalah saat menyebarkan layanan mitra yang tidak memiliki permintaan dan batasan yang tepat.
  • Simpan gambar kontainer Anda di Azure Container Registry dan replikasi geografis registri ke setiap wilayah.
  • 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 untuk menyediakan bandwidth tinggi di seluruh jaringan backbone Microsoft, bahkan di berbagai wilayah geografis.
  • Gunakan protokol anycast berbasis TCP terpisah, Azure Front Door, untuk segera menghubungkan pengguna akhir Anda ke FRONT Door POP (titik kehadiran) terdekat. Lebih banyak fitur Azure Front Door meliputi:
    • Penghentian TLS
    • Domain kustom
    • Web Application Firewall
    • Penulisan ulang URL
    • Afinitas sesi

Langkah berikutnya

Pelajari tentang pertimbangan desain dan rekomendasi untuk otomatisasi platform dan DevOps di zona pendaratan Azure Anda.