FAQ OpenShift Azure Red Hat

Untuk informasi harga, lihat Harga Azure Red Hat OpenShift.

Untuk informasi Perjanjian Tingkat Layanan (SLA), lihat Perjanjian Tingkat Layanan untuk layanan online.

Untuk daftar wilayah yang didukung untuk Azure Red Hat OpenShift 4.x, lihat Wilayah yang tersedia.

Untuk daftar ukuran komputer virtual yang didukung untuk Azure Red Hat OpenShift 4, lihat Sumber daya yang didukung untuk Azure Red Hat OpenShift 4.

Jumlah pod yang didukung sebenarnya bergantung pada memori, CPU, dan persyaratan penyimpanan aplikasi.

Azure Red Hat OpenShift 4.x memiliki batas 250 pod per node dan batas 60 node komputasi. Batas ini membatasi jumlah maksimum pod yang didukung dalam kluster hingga 250×60 = 15.000. Untuk kluster privat tanpa IP publik apa pun (misalnya, dibuat dengan menggunakan User Defined Routing (UDR) dan menjalankan versi 4.11 atau lebih tinggi), batasnya adalah 120 simpul komputasi dan 30.000 pod.

Tidak. Semua node dalam kluster Azure Red Hat OpenShift harus berasal dari wilayah Azure yang sama.

Ya. Kluster dapat disebarkan di beberapa zona ketersediaan secara otomatis jika kluster Anda disebarkan ke wilayah Azure yang mendukung zona ketersediaan. Untuk informasi selengkapnya, lihat Zona ketersediaan.

Tidak. Semua sumber daya, termasuk node sarana kontrol kluster, berjalan di langganan pelanggan Anda. Jenis sumber daya ini dimasukkan ke dalam grup sumber daya hanya-baca.

Aplikasi Terkelola Azure berada di Grup Sumber Daya yang terkunci dengan langganan pelanggan. Pelanggan dapat melihat objek dalam grup sumber daya tersebut tetapi tidak dapat mengubahnya.

Setiap kluster Azure Red Hat OpenShift didedikasikan untuk pelanggan tertentu dan tinggal dalam langganan pelanggan.

Ya, ARO memungkinkan Anda menggunakan set mesin infrastruktur untuk membuat komputer yang hanya menghosting komponen infrastruktur, seperti router default, registri kontainer terintegrasi, dan komponen untuk metrik dan pemantauan kluster. Lihat Menyebarkan simpul infrastruktur dalam kluster ARO untuk mempelajari selengkapnya.

Bagaimana cara menangani peningkatan kluster?

Untuk informasi tentang peningkatan versi, pemeliharaan, dan versi yang didukung, lihat panduan siklus hidup dukungan.

Sistem operasi host dan perangkat lunak OpenShift diperbarui saat Azure Red Hat OpenShift menggunakan versi rilis minor dan patch dari OpenShift Container Platform upstream.

Node di-boot ulang sebagai bagian dari peningkatan.

Prometheus sudah diinstal sebelumnya dan dikonfigurasi untuk kluster Azure Red Hat OpenShift 4.x. Baca selengkapnya tentang pemantauan kluster.

Di Azure Red Hat OpenShift 4.x: Ya.

Log dari VM yang mendasarinya ditangani oleh layanan terkelola dan tidak diekspos ke pelanggan.

Untuk kluster Azure Red Hat OpenShift 4.x, konsol web OpenShift berisi semua metrik di tingkat node. Untuk informasi selengkapnya, lihat dokumentasi Red Hat tentang melihat informasi kluster.

Secara default ada lima domain kesalahan saat menggunakan Virtual Machine Scale Sets di Azure. Setiap instans komputer virtual dalam set skala akan ditempatkan ke salah satu domain kesalahan ini. Ini memastikan bahwa aplikasi yang disebarkan ke node komputasi dalam sebuah kluster akan ditempatkan di domain kesalahan yang terpisah.

Untuk informasi selengkapnya, lihat Memilih jumlah domain kesalahan yang tepat untuk Virtual Machine Scale Set.

Pelanggan memiliki kemampuan untuk mendapatkan node dan melihat label sebagai admin pelanggan. Ini akan memberikan cara untuk menargetkan VM apa pun dalam kumpulan skala.

Perhatian harus digunakan saat menggunakan label tertentu:

• Nama host tidak boleh digunakan. Nama host sering diputar dengan peningkatan dan pembaruan dan dijamin akan berubah.
• Jika pelanggan memiliki permintaan untuk label tertentu atau strategi penyebaran, hal ini dapat dicapai. Namun, itu akan membutuhkan upaya rekayasa, dan tidak didukung saat ini.

Untuk informasi selengkapnya, lihat Mengontrol penempatan pod.

Untuk kluster 4.x, Anda perlu mengekspos registri yang aman dan mengonfigurasi autentikasi. Untuk informasi selengkapnya, lihat dokumentasi Red Hat berikut:

• Mengekspos registri
• Mengakses registri

Memindahkan kluster ARO Anda antar penyewa saat ini tidak didukung.

Memindahkan kluster ARO Anda dan sumber daya terkait antar langganan tidak didukung.

Memindahkan atau mengganti nama kluster ARO Anda dan sumber daya terkait tidak didukung.

Dalam kluster 4.x, Anda dapat menyebarkan kluster ke dalam VNet yang sudah ada.

Pelanggan dan admin proyek individu dapat menyesuaikan jaringan lintas-namespace (termasuk menolaknya) pada basis per proyek menggunakan objek NetworkPolicy.

Pada langganan yang memiliki jaringan virtual, pastikan untuk mendaftarkan penyedia Microsoft.ContainerService dengan perintah berikut: az provider register -n Microsoft.ContainerService --wait

Dalam kluster 4.x, Anda dapat menentukan rentang IP Anda sendiri.

Jaringan yang Ditentukan Perangkat Lunak adalah openshift-ovs-networkpolicy dan tidak dapat dikonfigurasi.

Azure Red Hat OpenShift menggunakan Azure Load Balancer Standar, dan tidak dapat dikonfigurasi.

Ya. Administrator Azure Red Hat OpenShift dapat mengelola pengguna dan kuota selain mengakses semua proyek yang dibuat pengguna.

Ya. Anda dapat membatasi pengguna Microsoft Entra mana yang dapat masuk ke kluster dengan mengonfigurasi Aplikasi Microsoft Entra. Untuk detailnya, lihat Cara: Membatasi aplikasi Anda untuk sekelompok pengguna.

Ya. Masuk ke kluster Anda sebagai administrator dan jalankan perintah ini:

oc adm policy \
    remove-cluster-role-from-group self-provisioner \
    system:authenticated:oauth

Untuk informasi selengkapnya, lihat dokumentasi OpenShift tentang menonaktifkan provisi mandiri untuk versi kluster Anda:

• Menonaktifkan penyediaan mandiri di kluster 4.6

Akses node tersedia melalui peran cluster-admin. Untuk informasi selengkapnya, lihat Ringkasan Kubernetes RBAC.

Peran cluster-admin tersedia. Untuk informasi selengkapnya, lihat Ringkasan Kubernetes RBAC.

Anda mengonfigurasi penyedia identitas Anda sendiri. Untuk informasi selengkapnya, lihat dokumentasi Red Hat tentang mengonfigurasi penyedia identitas.

Secara default, data dienkripsi saat tidak aktif. Platform Azure Storage secara otomatis mengenkripsi data Anda sebelum menyimpannya, dan mendekripsi data sebelum diambil. Untuk informasi selengkapnya, lihat Enkripsi Layanan Penyimpanan Azure untuk data tidak aktif.

Akun penyimpanan diatur ke akses privat saja.

Akun penyimpanan dienkripsi (hanya kluster baru). Kluster yang ada perlu dibuat ulang.

Akun penyimpanan dibuat dengan tujuan umum v2 untuk kluster baru.

Akun penyimpanan v2 tujuan umum mendukung fitur Azure Storage terbaru dan menggabungkan semua fungsionalitas akun penyimpanan v1 dan Blob tujuan umum.

Akses akun penyimpanan dibatasi dengan aturan firewall melalui grup keamanan jaringan Azure (NSG), yang memfilter lalu lintas jaringan ke dan dari akun penyimpanan Anda. Untuk informasi selengkapnya, lihat Gambaran umum grup keamanan jaringan Azure.

Protokol Keamanan Lapisan Transportasi (TLS) versi 1.2 menyediakan komunikasi, privasi data, dan integritas data yang aman.

Data tidak dienkripsi secara default, tetapi Anda memiliki opsi untuk mengaktifkan enkripsi. Untuk informasi lebih lanjut, lihat panduan tentang mengenkripsi etcd.

Azure Disk (Premium_LRS) dikonfigurasi sebagai kelas penyimpanan default. Untuk penyedia penyimpanan tambahan, dan untuk detail konfigurasi (termasuk Azure File), lihat dokumentasi Red Hat tentang penyimpanan persisten.

Apakah ARO menyimpan data pelanggan di luar wilayah kluster?

Tidak. Semua data yang dibuat dalam kluster ARO dipertahankan dalam wilayah kluster.