Konsep jaringan untuk menyebarkan simpul AKS
Berlaku untuk: AKS di Azure Stack HCI 22H2, AKS di Windows Server
Anda dapat memilih antara dua model penetapan alamat IP untuk arsitektur jaringan Anda untuk AKS yang diaktifkan oleh Azure Arc. AKS mendukung beberapa opsi penyebaran untuk Azure Kubernetes Service (AKS).
- Jaringan IP statis: jaringan virtual mengalokasikan alamat IP statis ke server API kluster Kube, node Kubernetes, VM yang mendasari, load balancer, dan layanan Kubernetes apa pun yang berjalan di atas kluster.
- Jaringan DHCP: jaringan virtual mengalokasikan alamat IP dinamis ke simpul Kube, VM yang mendasar, dan load balancer menggunakan server DHCP. Server API kluster Kubernetes, dan semua layanan Kubernetes yang Anda jalankan di atas kluster Anda, masih dialokasikan alamat IP statik.
Catatan
Arsitektur jaringan virtual yang ditentukan di sini untuk AKS Arc mungkin berbeda dari arsitektur jaringan fisik yang mendasar di pusat data.
Kumpulan IP virtual
Kumpulan IP Virtual (VIP) adalah sekumpulan alamat IP yang wajib untuk penyebaran apa pun di AKS Arc. Kumpulan VIP adalah berbagai alamat IP khusus yang digunakan untuk mengalokasikan alamat IP ke server API kluster Kubernetes. Ia menjamin bahwa aplikasi Anda selalu dapat dijangkau pada layanan Kubernetes. Terlepas dari model jaringan virtual serta model penetapan alamat yang Anda pilih, Anda harus menyediakan kumpulan VIP untuk penerapan host AKS Anda.
Jumlah alamat IP di kumpulan VIP bergantung pada jumlah kluster beban kerja dan layanan Kubernetes yang direncanakan untuk penerapan Anda.
Bergantung pada model jaringan Anda, definisi kumpulan VIP berbeda dengan cara berikut:
- IP statis: jika Anda menggunakan IP statis, pastikan alamat IP virtual Anda berasal dari subnet yang sama yang disediakan.
- DHCP: jika jaringan Anda dikonfigurasi dengan DHCP, bekerja samalah dengan administrator jaringan Anda untuk mengecualikan rentang IP kumpulan VIP dari cakupan DHCP yang digunakan untuk penyebaran AKS pada Azure Stack HCI.
Kumpulan IP mesin virtual node Kubernetes
Simpul Kubernetes disebarkan sebagai komputer virtual khusus di AKS Arc. AKS mengalokasikan alamat IP ke komputer virtual ini untuk memungkinkan komunikasi antara simpul Kubernetes.
- IP statis: Anda harus menentukan rentang kumpulan IP VM simpul Kubernetes. Jumlah alamat IP dalam rentang ini bergantung pada jumlah total simpul Kubernetes yang direncanakan untuk disebar di seluruh host AKS dan beban kerja kluster Kubernetes. Perlu diingat bahwa pembaruan menggunakan satu hingga tiga alamat IP tambahan selama pembaruan.
- DHCP: Anda tidak perlu menentukan kumpulan VM simpul Kubernetes, karena alamat IP ke simpul Kube dialokasikan secara dinamis oleh server DHCP di jaringan Anda.
Jaringan virtual dengan jaringan IP statik (disarankan)
Model jaringan ini menciptakan jaringan virtual yang mengalokasikan alamat IP dari kumpulan alamat yang didefinisikan secara statik ke semua objek dalam penyebaran Anda. Manfaat tambahan menggunakan jaringan IP statik adalah penyebaran jangka panjang dan beban kerja aplikasi dijamin selalu dapat dijangkau.
Tentukan parameter berikut saat mendefinisikan jaringan virtual dengan konfigurasi IP statik:
Penting
Versi AKS ini tidak mengizinkan perubahan konfigurasi jaringan setelah host AKS atau kluster beban kerja disebarkan. Untuk mengubah pengaturan jaringan, Anda harus mulai dari awal dengan menghapus kluster beban kerja dan menghapus instalan AKS.
Nama: Nama jaringan virtual Anda.
Alamat awalan: Awalan alamat IP yang akan digunakan untuk subnet Anda.
Gateway: Alamat IP gateway default untuk subnet.
Server DNS: Larik alamat IP yang menunjuk ke server DNS yang akan digunakan untuk subnet. Minimal satu dan maksimal tiga server dapat disediakan.
Kumpulan mesin virtual node Kubernetes: Rentang alamat IP berkelanjutan yang akan digunakan untuk mesin virtual node Kubernetes Anda.
Kumpulan IP virtual: Rentang alamat IP berkelanjutan yang akan digunakan untuk server API kluster Kubernetes dan layanan Kubernetes Anda.
Catatan
Kumpulan VIP harus menjadi bagian dari subnet yang sama dengan kumpulan mesin virtual node Kubernetes.
vLAN ID: ID vLAN untuk jaringan virtual. Jika dihilangkan, jaringan virtual tidak ditandai.
Jaringan virtual dengan jaringan DHCP
Model jaringan ini menciptakan jaringan virtual yang mengalokasikan alamat IP menggunakan DHCP ke semua objek dalam penyebaran.
Anda harus menentukan parameter berikut saat mendefinisikan jaringan virtual dengan konfigurasi IP statik:
Penting
Dalam versi AKS ini, tidak dimungkinkan untuk mengubah konfigurasi jaringan setelah host AKS atau kluster beban kerja disebarkan. Satu-satunya cara untuk mengubah pengaturan jaringan adalah dengan memulai dari awal dengan menghapus kluster beban kerja dan menghapus instalan AKS.
Nama: Nama jaringan virtual Anda.
Kumpulan IP virtual: Rentang alamat IP berkelanjutan yang akan digunakan untuk server API kluster Kubernetes dan layanan Kubernetes Anda.
Catatan
Alamat kumpulan VIP harus berada dalam subnet yang sama dengan cakupan DHCP, dan harus dikeluarkan dari cakupan DHCP guna menghindari konflik alamat.
ID vLAN: ID vLAN untuk jaringan virtual. Jika dihilangkan, jaringan virtual tidak ditandai.
Layanan Cloud Microsoft Lokal
Microsoft On-premises Cloud (MOC) merupakan tumpukan manajemen yang memungkinkan pengelolaan mesin virtual di Azure Stack HCI dan SDDC berbasis Windows Server. MOC terdiri dari:
- Sebuah instans tunggal dari layanan
cloud agentyang sangat tersedia yang disebarkan di kluster. Agen ini berjalan di salah satu node di kluster Azure Stack HCI atau Windows Server dan dikonfigurasi untuk melakukan failover ke node lain. node agentberjalan di setiap node fisik Azure Stack HCI.
Untuk mengaktifkan komunikasi dengan MOC, Anda harus menyediakan CIDR alamat IP yang akan digunakan untuk layanan. -cloudserviceCIDR adalah parameter dalam perintah Set-AksHciConfig yang digunakan untuk menetapkan alamat IP ke layanan agen cloud dan mengaktifkan ketersediaan tinggi layanan agen cloud.
Pilihan alamat IP untuk layanan MOC tergantung pada model jaringan yang mendasar yang digunakan oleh penyebaran kluster Anda di Azure Stack HCI atau Windows Server.
Catatan
Alokasi alamat IP untuk layanan MOC tidak tergantung pada model jaringan virtual Kubernetes Anda. Alokasi alamat IP bergantung pada jaringan fisik yang mendasar, dan alamat IP yang dikonfigurasi untuk node kluster Azure Stack HCI atau Windows Server di pusat data Anda.
Node kluster Azure Stack HCI dan Windows Server dengan mode alokasi alamat IP berbasis DHCP: Jika simpul Azure Stack HCI Anda diberi alamat IP dari server DHCP yang ada di jaringan fisik, maka Anda tidak perlu secara eksplisit memberikan alamat IP ke layanan MOC, karena layanan MOC juga menerima alamat IP dari server DHCP.
Node kluster Azure Stack HCI dan Windows Server dengan model alokasi IP statik: Jika node kluster Anda diberi alamat IP statik, maka Anda harus secara eksplisit memberikan alamat IP untuk layanan cloud MOC. Alamat IP untuk layanan MOC harus dalam subnet yang sama dengan alamat IP node kluster Azure Stack HCI dan Windows Server. Untuk menetapkan alamat IP secara eksplisit untuk layanan MOC, gunakan
-cloudserviceCIDRparameter dalamSet-AksHciConfigperintah. Pastikan Anda memasukkan alamat IP dalam format CIDR, misalnya: "10.11.23.45/16".
Bandingkan model jaringan
DHCP dan IP Statis menyediakan konektivitas jaringan pada AKS Anda pada penyebaran Azure Stack HCI dan Windows Server. Namun, ada kelebihan dan kekurangan masing-masing. Pada tingkat tinggi, pertimbangan berikut berlaku:
DHCP - Tidak menjamin alamat IP berumur panjang untuk beberapa jenis sumber daya dalam penyebaran AKS. - Mendukung perluasan alamat IP DHCP yang dicadangkan jika penyebaran Anda menjadi lebih besar dari yang Anda perkirakan sebelumnya.
IP Statis - Menjamin alamat IP berumur panjang untuk semua sumber daya dalam penyebaran AKS. - Karena perluasan otomatis kumpulan IP node Kubernetes tidak didukung, Anda mungkin tidak dapat membuat kluster baru jika kumpulan IP node Kubernetes telah habis.
Tabel berikut membandingkan alokasi alamat IP untuk sumber daya antara model jaringan IP dan DHCP statik:
| Kemampuan | IP statis | DHCP |
|---|---|---|
| Kubernetes kluster API server | Ditetapkan secara statis menggunakan kumpulan VIP. | Ditetapkan secara statis menggunakan kumpulan VIP. |
| Node Kubernetes (pada mesin virtual) | Ditetapkan menggunakan kumpulan IP simpul Kubernetes. | Ditetapkan secara dinamis. |
| Layanan Kubernetes | Ditetapkan secara statis menggunakan kumpulan VIP. | Ditetapkan secara statis menggunakan kumpulan VIP. |
| HAProxy penyeimbang beban mesin virtual | Ditetapkan menggunakan kumpulan IP simpul Kubernetes. | Ditetapkan secara dinamis. |
| Microsoft On-Premises Cloud Service | Tergantung pada konfigurasi jaringan fisik untuk node kluster Azure Stack HCI dan Windows Server. | Tergantung pada konfigurasi jaringan fisik untuk node kluster Azure Stack HCI dan Windows Server. |
| Kumpulan VIP | Wajib | Wajib |
| Kumpulan IP mesin virtual node Kubernetes | Wajib | Tidak Didukung |
Reservasi alamat IP minimum untuk penyebaran AKS
Terlepas dari model penyebaran Anda, jumlah alamat IP yang dipesan akan tetap sama. Bagian ini menjelaskan jumlah alamat IP yang perlu Anda pesan berdasarkan model penyebaran AKS Arc Anda.
Reservasi alamat IP minimum
Minimal, Anda harus memesan jumlah alamat IP berikut untuk penyebaran Anda:
| Jenis kluster | Node sarana kontrol | Simpul pekerja | Untuk operasi perbarui | Load balancer |
|---|---|---|---|---|
| Host AKS | Satu IP | NA | Dua IP | NA |
| kluster beban kerja | Satu IP per simpul | Satu IP per simpul | 5 IP | Satu IP |
Selain itu, Anda harus memesan nomor alamat IP berikut untuk kumpulan VIP Anda:
| Jenis Sumber Daya | Jumlah alamat IP |
|---|---|
| Server API kluster | 1 per kluster |
| Layanan Kubernetes | 1 per layanan |
| Layanan Aplikasi | 1 per layanan yang direncanakan |
Seperti yang Anda lihat, jumlah alamat IP yang diperlukan bervariasi tergantung pada arsitektur penyebaran AKS Anda, dan jumlah layanan yang Anda jalankan pada kluster Kubernetes Anda. Kami menyarankan untuk memesan minimal 256 alamat IP (/24 subnet) untuk penyebaran Anda.
Membahas contoh penyebaran
Jane adalah administrator TI yang baru saja dimulai dengan AKS yang diaktifkan oleh Azure Arc. Dia ingin menyebarkan dua kluster Kubernetes: kluster Kubernetes A dan kluster Kubernetes B pada kluster Azure Stack HCI-nya. Dia juga ingin menjalankan aplikasi voting di atas klusternya. Aplikasi ini memiliki tiga instans dari UI front-end yang berjalan di dua kluster dan satu instans dari database backend.
- Kluster Kubernetes A memiliki 3 simpul sarana kontrol dan 5 simpul pekerja.
- Kluster Kubernetes B memiliki 1 simpul sarana kontrol dan 3 simpul pekerja.
- 3 instans UI front-end (port 443).
- 1 instans database backend (port 80).
Berdasarkan tabel sebelumnya, dia harus memesan:
- 3 alamat IP untuk host AKS (satu IP untuk simpul sarana kontrol dan dua IP untuk menjalankan operasi pembaruan).
- 3 alamat IP untuk simpul sarana kontrol di kluster A (satu IP per simpul sarana kontrol).
- 5 alamat IP untuk simpul pekerja di kluster A (satu IP per simpul pekerja).
- 6 alamat IP selain untuk kluster A (lima IP untuk menjalankan operasi pembaruan dan 1 IP untuk load balancer).
- 1 alamat IP untuk node sarana kontrol di kluster B (satu IP per node sarana kontrol).
- 3 alamat IP untuk simpul pekerja di kluster B (satu IP per simpul pekerja).
- 6 alamat IP selain untuk kluster B (lima IP untuk menjalankan operasi pembaruan dan 1 IP untuk load balancer).
- 2 alamat IP untuk server API kluster Kubernetes (satu IP per kluster Kubernetes).
- 3 alamat IP untuk layanan Kubernetes (satu alamat IP per instans UI front-end, karena semuanya menggunakan port yang sama. Database backend dapat menggunakan salah satu dari tiga alamat IP selama akan menggunakan port yang berbeda).
Seperti yang dijelaskan sebelumnya, Jane membutuhkan total 32 alamat IP untuk menyebarkan kluster. Oleh karena itu Jane harus memesan subnet / 26 untuk jaringan virtualnya.
Pemisahan alamat IP yang dipesan berdasarkan model jaringan IP statik
Sementara jumlah total alamat IP yang dipesan tetap sama, model penyebaran menentukan bagaimana alamat IP ini dibagi di antara kelompok IP. Model jaringan IP statik memiliki dua kumpulan IP:
- Kumpulan IP VM simpul Kubernetes: untuk VM simpul Kubernetes dan VM load balancer. Kumpulan IP ini juga menyertakan alamat IP yang diperlukan untuk menjalankan operasi pembaruan.
- Kumpulan IP virtual: untuk server API Kubernetes dan layanan Kubernetes.
Bekerja dengan contoh ini, Jane harus membagi alamat IP ini lebih lanjut di seluruh kumpulan VIP dan kumpulan IP simpul Kube:
- 5 (dua untuk server API cluster Kubernetes dan tiga untuk layanan Kubernetes) dari 32 alamat IP untuk kumpulan VIP-nya.
- 27 (semua alamat IP untuk node Kubernetes dan VM yang mendasarinya, VM penyeimbang beban, dan operasi pembaruan) untuk kumpulan IP node Kubernetes miliknya.
Pemisahan alamat IP yang dipesan berdasarkan model jaringan DHCP
Sementara jumlah total alamat IP yang dipesan tetap sama, model penyebaran menentukan bagaimana alamat IP ini dibagi di antara grup IP. Seperti yang dibahas sebelumnya, model jaringan DHCP mempunyai satu cakupan IP:
- Kumpulan IP virtual: untuk server API Kubernetes dan layanan Kubernetes
Bekerja dengan contoh sebelumnya:
- Jane harus memesan total 32 alamat IP atau subnet / 26 di server DHCP-nya.
- Dia harus mengecualikan 5 (dua untuk server API kluster Kubernetes dan tiga untuk layanan Kubernetes) dari cakupan DHCP dari 32 alamat IP untuk kumpulan VIP-nya.
Pengontrol ingress
Selama penerapan kluster target, HAProxy-sumber daya penyeimbang beban berbasis dibuat. Load Balancer dikonfigurasi untuk mendistribusikan lalu lintas ke pod di layanan Anda pada port tertentu. Load balancer hanya berfungsi pada lapisan 4, yang menunjukkan bahwa layanan tidak menyadari aplikasi aktual; yaitu, tidak dapat membuat pertimbangan perutean tambahan.
Pengontrol ingress bekerja pada lapisan 7, dan dapat menggunakan aturan yang lebih cerdas untuk mendistribusikan lalu lintas aplikasi. Penggunaan umum pengontrol ingress adalah merutekan lalu lintas HTTP ke aplikasi yang berbeda berdasarkan URL masuk.
Langkah berikutnya
Artikel ini mencakup beberapa konsep jaringan untuk menyebarkan node AKS di Azure Stack HCI. Untuk informasi lebih lanjut, baca artikel berikut:
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk