Pertimbangan topologi dan konektivitas jaringan untuk Azure Red Hat OpenShift

  • Artikel

Tinjau pertimbangan dan rekomendasi desain untuk topologi dan konektivitas jaringan saat Anda menggunakan akselerator zona pendaratan Azure Red Hat OpenShift.

Pertimbangan Desain

  • Azure Red Hat OpenShift memerlukan subnet utama dan subnet sekunder.

    • Gunakan subnet utama untuk menyebarkan simpul master kluster.
    • Gunakan subnet sekunder untuk menyebarkan simpul pekerja kluster.
    • Subnet sekunder dan subnet utama keduanya harus menjadi rute minimum /27 .
    • Anda tidak dapat mengubah subnet sekunder atau subnet utama setelah menyebarkan kluster.
    • Subnet utama dan subnet sekunder tidak dapat memiliki grup keamanan jaringan yang terkait dengannya. Kluster Azure Red Hat OpenShift secara otomatis membuat dan mengelola grup keamanan jaringan.
    • Subnet sekunder dan subnet utama tidak dapat tumpang tindih dengan jaringan lokal atau dengan jaringan lain di Azure.

  • Rencanakan alamat IP dengan hati-hati dan ukuran subnet jaringan virtual untuk mendukung penskalaan kluster. Anda mungkin perlu menambahkan simpul.

  • Anda dapat mengekspos layanan dan rute Azure Red Hat OpenShift dengan menggunakan load balancer publik atau internal. Siapkan load balancer internal di subnet yang sama dengan simpul sekunder. Dalam kluster keluar terbatas, Anda tidak dapat menggunakan load balancer publik karena perutean asimetris.

  • Azure Red Hat OpenShift menggunakan CoreDNS untuk memberikan resolusi nama ke pod yang berjalan di kluster.

    • CoreDNS secara langsung menyelesaikan domain internal kluster.
    • Azure Red Hat OpenShift juga mendukung server DNS kustom di jaringan virtual.
    • Domain lain diteruskan ke server DNS yang Anda konfigurasi di Azure Virtual Network. Server DNS akan menjadi pemecah masalah Azure DNS default atau server DNS kustom apa pun yang Anda konfigurasikan di tingkat jaringan virtual.
    • Anda dapat menyesuaikan penerusan DNS di Azure Red Hat OpenShift CoreDNS.
    • Jika tidak ada server DNS kustom yang dikonfigurasi di jaringan virtual, Azure Red Hat OpenShift menggunakan pemecah masalah Azure DNS default.

    Untuk informasi selengkapnya tentang DNS, lihat Konfigurasi DNS Titik Akhir Privat Azure.

  • Anda dapat mengirim lalu lintas jaringan keluar (keluar) melalui Azure Firewall atau melalui kluster appliance virtual jaringan.

  • Secara default, semua pod dalam kluster Azure Red Hat OpenShift dapat mengirim dan menerima lalu lintas tanpa batasan. Semua pod dalam proyek dapat diakses dari pod lain dan titik akhir jaringan. Untuk mengisolasi satu atau beberapa pod dalam proyek, Anda dapat membuat NetworkPolicy objek dalam proyek untuk menunjukkan koneksi masuk yang diizinkan. Jaringan yang ditentukan perangkat lunak (SDN) Red Hat OpenShift mendukung penggunaan kebijakan jaringan dalam mode isolasi jaringan defaultnya.

  • Jala layanan memiliki berbagai kemampuan seperti manajemen lalu lintas, ketahanan, kebijakan, keamanan, identitas yang kuat, dan observabilitas. Untuk informasi selengkapnya tentang Red Hat OpenShift Service Mesh, lihat Perbedaan Service Mesh dan Istio.

  • Mekanisme penyeimbangan beban global seperti Azure Traffic Manager dan Azure Front Door meningkatkan ketahanan dengan merutekan lalu lintas di beberapa kluster, berpotensi di wilayah Azure yang berbeda.

Kluster privat

Alamat IP kluster Azure Red Hat OpenShift API dapat bersifat publik atau privat. Kluster privat mengekspos Azure Red Hat OpenShift API melalui alamat IP privat tetapi tidak melalui yang publik. Azure Red Hat OpenShift API tidak boleh diakses melalui alamat IP-nya. Sebagai gantinya, akses Azure Red Hat OpenShift API melalui nama domain yang sepenuhnya memenuhi syarat (FQDN). Azure DNS menyelesaikan Azure Red Hat OpenShift API FQDN ke alamat IP-nya.

Sejalan dengan praktik zona pendaratan Azure yang terbukti, resolusi DNS untuk beban kerja Azure ditawarkan oleh server DNS terpusat yang disebarkan dalam langganan konektivitas. Server Azure DNS berada di jaringan virtual hub atau di jaringan virtual layanan bersama yang terhubung ke instans Azure Virtual WAN. Server DNS secara kondisional menyelesaikan nama khusus Azure dan publik dengan menggunakan Azure DNS (alamat 168.63.129.16IP ). Server menyelesaikan nama privat dengan menggunakan server DNS perusahaan. Model konektivitas ini umum, dan penting untuk mengizinkan akses privat ke sumber daya Azure lainnya jika Anda menggunakan titik akhir privat.

Diagram that shows a network for a private cluster.

Lalu lintas dari pengguna aplikasi ke kluster

Gunakan pengontrol masuk (ingress) untuk mengekspos aplikasi yang berjalan di kluster Azure Red Hat OpenShift.

  • Pengontrol Ingress menyediakan perutean tingkat aplikasi hanya dengan sedikit peningkatan kompleksitas.
  • Azure Red Hat OpenShift membuat entri DNS generik yang menyederhanakan akses ke aplikasi yang terekspos dalam kluster. Contoh entri DNS adalah *.apps.<cluster-ID>.<region>.aroapp.io. Ini berguna bagi kluster privat untuk merutekan lalu lintas untuk aplikasi.
  • Azure Red Hat OpenShift menawarkan pengontrol dan rute Ingress bawaan.
  • Anda dapat menggunakan ingress Azure Red Hat OpenShift dengan Azure Front Door.
  • Sejajarkan konfigurasi Anda dengan desain pemfilteran keluar untuk menghindari perutean asimetris. UDR berpotensi menyebabkan perutean asimetris.
  • Jika skenario Anda memerlukan penghentian TLS, pertimbangkan bagaimana Anda akan mengelola sertifikat TLS.

Penting

Jika Anda menggunakan Azure Firewall untuk membatasi lalu lintas keluar dan membuat UDR untuk memaksa semua lalu lintas keluar, pastikan Anda membuat aturan Destination Network Address Translation (DNAT) yang sesuai di Azure Firewall untuk mengizinkan lalu lintas masuk dengan benar. Menggunakan Azure Firewall dengan UDR melanggar pengaturan masuk karena perutean asimetris. Masalah ini terjadi jika subnet Azure Red Hat OpenShift memiliki rute default yang masuk ke alamat IP privat firewall, tetapi Anda menggunakan load balancer publik (ingress atau layanan Kubernetes jenis Load Balancer). Pada kasus ini, lalu lintas penyeimbang beban yang masuk diterima melalui alamat IP publiknya, tetapi jalur kembalinya melewati alamat IP privat firewall. Karena firewall bersifat stateful, firewall menghilangkan paket yang dikembalikan karena firewall tidak mendeteksi sesi yang dibuat. Untuk mempelajari cara mengintegrasikan Azure Firewall dengan ingress atau load balancer layanan Anda, lihat Mengintegrasikan Azure Firewall dengan Azure Standard Load Balancer.

Langkah-langkah berikut menjelaskan alur jika Anda menggunakan Azure Front Door dengan kluster privat Azure Red Hat OpenShift dan pengontrol ingress:

  1. Klien dari internet publik menyelesaikan nama DNS untuk aplikasi yang menunjuk ke Azure Front Door.
  2. Azure Front Door menggunakan layanan Azure Private Link untuk mengakses alamat IP privat penyeimbang beban jaringan internal Azure dan mengakses aplikasi di pengontrol ingress OpenShift Azure Red Hat.

Langkah-langkah ini menjelaskan alur untuk aplikasi non-web yang mengakses kluster privat Azure Red Hat OpenShift:

  1. Klien dari internet publik menyelesaikan nama DNS untuk aplikasi yang menunjuk ke alamat IP publik Azure Firewall atau appliance virtual jaringan.
  2. Azure Firewall atau appliance virtual jaringan meneruskan lalu lintas (DNAT) ke kluster privat Azure Red Hat OpenShift dengan menggunakan alamat IP privat penyeimbang beban jaringan internal Azure untuk mengakses aplikasi di pengontrol ingress OpenShift Azure Red Hat.

Lalu lintas dari pod Azure Red Hat OpenShift ke layanan back-end

Pod yang berjalan di dalam kluster Azure Red Hat OpenShift mungkin perlu mengakses layanan back-end seperti Azure Storage, Azure Key Vault, Azure SQL Database, dan Azure Cosmos DB. Anda dapat menggunakan titik akhir layanan jaringan virtual dan Azure Private Link untuk mengamankan konektivitas ke layanan yang dikelola Azure ini.

Jika Anda menggunakan titik akhir privat Azure untuk lalu lintas back-end, Anda dapat menggunakan zona DNS Privat Azure untuk resolusi DNS untuk layanan Azure. Karena pemecah masalah DNS untuk seluruh lingkungan berada di jaringan virtual hub (atau di jaringan virtual layanan bersama, jika Anda menggunakan model konektivitas Virtual WAN), buat zona privat ini di langganan konektivitas. Untuk membuat catatan A yang diperlukan untuk menyelesaikan FQDN layanan privat, Anda dapat mengaitkan zona DNS privat dalam langganan konektivitas dengan titik akhir privat dalam langganan aplikasi. Operasi ini memerlukan izin khusus dalam langganan tersebut.

Anda dapat membuat catatan A secara manual, tetapi mengaitkan zona DNS privat dengan titik akhir privat menghasilkan penyiapan yang kurang rentan terhadap kesalahan konfigurasi.

Konektivitas back-end dari pod Azure Red Hat OpenShift ke layanan platform as a service (PaaS) Azure yang diekspos melalui titik akhir privat mengikuti urutan ini:

  1. Pod Azure Red Hat OpenShift menyelesaikan FQDN Azure PaaS dengan menggunakan server DNS pusat dalam langganan konektivitas, yang didefinisikan sebagai server DNS kustom di jaringan virtual Azure Red Hat OpenShift.
  2. Alamat IP yang diselesaikan adalah alamat IP privat dari titik akhir privat, yang diakses langsung dari pod Azure Red Hat OpenShift.

Lalu lintas antara pod Azure Red Hat OpenShift dan titik akhir privat secara default tidak melalui instans Azure Firewall di jaringan virtual hub (atau hub virtual aman, jika Anda menggunakan Virtual WAN), bahkan jika kluster Azure Red Hat OpenShift dikonfigurasi untuk pemfilteran keluar dengan Azure Firewall. Titik akhir privat membuat /32 rute di subnet jaringan virtual aplikasi tempat Azure Red Hat OpenShift disebarkan.

Rekomendasi desain

  • Jika kebijakan keamanan mengharuskan Anda menggunakan alamat IP privat untuk Azure Red Hat OpenShift API, sebarkan kluster Azure Red Hat OpenShift privat.
  • Gunakan Azure DDoS Protection untuk melindungi jaringan virtual yang Anda gunakan untuk kluster Azure Red Hat OpenShift kecuali Anda menggunakan Azure Firewall atau Web Application Firewall dalam langganan terpusat.
  • Gunakan konfigurasi DNS yang ditautkan ke penyiapan jaringan keseluruhan dengan Azure Virtual WAN atau arsitektur hub dan spoke, zona Azure DNS, dan infrastruktur DNS Anda sendiri.
  • Gunakan Azure Private Link untuk mengamankan koneksi jaringan, dan menggunakan konektivitas berbasis IP privat ke layanan Azure terkelola lainnya yang mendukung Private Link, seperti Azure Storage, Azure Container Registry, Azure SQL Database, dan Azure Key Vault.
  • Gunakan pengontrol ingress untuk menyediakan perutean dan keamanan HTTP tingkat lanjut dan untuk menawarkan satu titik akhir untuk aplikasi.
  • Semua aplikasi web yang Anda konfigurasi untuk menggunakan ingress harus menggunakan enkripsi TLS dan tidak boleh mengizinkan akses melalui HTTP yang tidak terenkripsi.
  • Gunakan Azure Front Door dengan Web Application Firewall untuk menerbitkan aplikasi Azure Red Hat OpenShift dengan aman ke internet.
  • Jika kebijakan keamanan Mengharuskan Anda memeriksa semua lalu lintas internet keluar yang dihasilkan di kluster Azure Red Hat OpenShift, mengamankan lalu lintas jaringan keluar dengan menggunakan Azure Firewall atau appliance virtual jaringan pihak ketiga yang disebarkan di jaringan virtual hub terkelola. Untuk informasi selengkapnya, lihat Mengontrol lalu lintas keluar ke kluster Azure Red Hat OpenShift.
  • Gunakan tingkat Azure Load Balancer Standard alih-alih tingkat Dasar untuk aplikasi non-web.

Langkah berikutnya