Arsitektur jaringan untuk AKS di Azure Stack HCI

Azure Stack HCI

Windows Server

Skenario ini menggambarkan cara merancang dan mengimplementasikan konsep jaringan untuk menyebarkan simpul Azure Kubernetes Service (AKS) pada kluster AKS.

Artikel ini mencakup rekomendasi untuk desain jaringan untuk node Kubernetes dan kontainer Kubernetes. Ini adalah bagian dari seperangkat panduan garis besar arsitektur dari dua artikel. Lihat rekomendasi arsitektur garis besar di sini.

Penting

Informasi dalam artikel ini berlaku untuk AKS di Azure Stack HCI versi 22H2, dan AKS-HCI di Windows Server. Versi terbaru AKS berjalan di Azure Stack HCI 23H2. Untuk informasi selengkapnya tentang versi terbaru, lihat dokumentasi AKS di Azure Stack HCI versi 23H2.

Sistem

Gambar berikut menunjukkan arsitektur jaringan untuk Azure Kubernetes Service di kluster pusat data Azure Stack HCI atau Windows Server 2019/2022:

Unduh file Visio arsitektur ini.

Skenario ini terdiri dari komponen dan kemampuan berikut:

Azure Stack HCI (22H2) adalah solusi kluster infrastruktur hyperconverged (HCI) yang menghosting beban kerja Windows dan Linux virtual dan penyimpanannya di lingkungan lokal hibrid. Kluster Azure Stack HCI diimplementasikan sebagai kluster node 2-4.
Kluster failover pusat data Windows Server 2019/2022 adalah sekelompok komputer independen yang bekerja sama untuk meningkatkan ketersediaan dan skalabilitas peran berkluster.
Azure Kubernetes Service di Azure Stack HCI adalah implementasi lokal dari Azure Kubernetes Service (AKS), yang mengotomatiskan menjalankan aplikasi kontainer dalam skala besar.
Active Directory Domain Services adalah struktur hierarkis yang menyimpan informasi tentang objek di jaringan. Ini menyediakan solusi identitas dan akses untuk identitas yang terkait dengan pengguna, komputer, aplikasi, atau sumber daya lain yang disertakan dalam batas keamanan.
Kluster manajemen juga dikenal sebagai host AKS bertanggung jawab untuk menyebarkan dan mengelola beberapa kluster beban kerja. Kluster manajemen menggunakan 1 alamat IP dari kumpulan simpul, tetapi Anda harus memesan 2 IP lain untuk operasi pembaruan. Kluster manajemen juga menggunakan satu IP dari kumpulan VIP.
Kluster Beban Kerja adalah penyebaran Kubernetes yang sangat tersedia menggunakan VM Linux untuk menjalankan komponen sarana kontrol Kube dan simpul pekerja Linux dan/atau Windows.
- Sarana kontrol. Berjalan pada distribusi Linux dan berisi komponen server API untuk interaksi dengan API Kubernetes dan penyimpanan nilai kunci terdistribusi, dlld, untuk menyimpan semua konfigurasi dan data kluster. Ini mengonsumsi satu IP dari kumpulan simpul dan satu IP dari kumpulan VIP.
- Penyeimbang beban. Berjalan pada VM Linux dan menyediakan layanan seimbang beban untuk kluster beban kerja. Ini mengonsumsi satu IP dari kumpulan simpul dan satu IP dari kumpulan VIP.
- Simpul pekerja. Jalankan pada sistem operasi Windows atau Linux yang menghosting aplikasi kontainer. Ini menggunakan alamat IP dari kumpulan Node, tetapi Anda harus merencanakan setidaknya 3 alamat IP lagi untuk operasi pembaruan.
- Sumber daya Kubernetes. Pod mewakili satu instans aplikasi Anda, yang biasanya memiliki pemetaan 1:1 dengan kontainer, tetapi pod tertentu dapat berisi beberapa kontainer. Penyebaran mewakili satu atau beberapa pod yang identik. Pod dan penyebaran secara logis dikelompokkan ke dalam namespace layanan yang mengontrol akses ke manajemen sumber daya. Mereka mengonsumsi 1 IP per pod dari kumpulan VIP.
Azure Arc adalah layanan berbasis cloud yang memperluas model manajemen berbasis Azure Resource Manager ke sumber daya non-Azure termasuk komputer virtual (VM), kluster Kubernetes, dan database kontainer.
Azure Policy adalah layanan berbasis cloud yang mengevaluasi Azure dan sumber daya lokal melalui integrasi dengan Azure Arc dengan membandingkan properti dengan aturan bisnis yang dapat disesuaikan.
Azure Monitor adalah layanan berbasis cloud yang memaksimalkan ketersediaan dan performa aplikasi dan layanan Anda dengan memberikan solusi komprehensif untuk mengumpulkan, menganalisis, dan bertindak berdasarkan telemetri dari lingkungan cloud dan lokal Anda.
Microsoft Defender untuk Cloud adalah sistem manajemen keamanan infrastruktur terpadu yang memperkuat postur keamanan pusat data Anda dan memberikan perlindungan ancaman tingkat lanjut di seluruh beban kerja hibrid Anda di cloud dan lokal.

Komponen

Detail skenario

Kasus penggunaan untuk skenario ini dijelaskan dalam artikel pertama seri, arsitektur Garis Besar.

Jaringan simpul Kubernetes

Pertimbangan utama dalam desain jaringan untuk AKS di Azure Stack HCI adalah memilih model jaringan yang menyediakan alamat IP yang cukup. AKS di Azure Stack HCI menggunakan jaringan virtual untuk mengalokasikan alamat IP ke sumber daya simpul Kubernetes. Anda dapat menggunakan dua model penetapan alamat IP:

Jaringan IP statis lebih dapat diprediksi tetapi menambahkan upaya ekstra untuk konfigurasi awal.
Jaringan Dynamic Host Configuration Protocol (DHCP) menggunakan alokasi dinamis alamat IP dan lebih sedikit upaya, tetapi Anda perlu berhati-hati untuk tidak menghabiskan kumpulan IP yang tersedia. Anda juga perlu mengelola reservasi dan rentang pengecualian untuk kumpulan IP virtual dan sumber daya luas kluster tertentu seperti layanan agen cloud.

Kedua model penugasan harus merencanakan alamat IP untuk:

Kumpulan IP virtual
Kumpulan IP mesin virtual node Kubernetes

Kumpulan IP virtual

Kumpulan IP virtual adalah sekumpulan alamat IP yang wajib untuk setiap penyebaran AKS di Azure Stack HCI. Rencanakan jumlah alamat IP di kumpulan IP virtual berdasarkan jumlah kluster beban kerja dan layanan Kubernetes. Kumpulan IP virtual menyediakan alamat IP untuk jenis sumber daya berikut:

Agen cloud memerlukan alamat IP mengambang dari kumpulan IP virtual.
Komponen server API yang berjalan di dalam komputer virtual Kubernetes Virtual Appliance (KVA) (kluster manajemen) menggunakan alamat IP dari kumpulan IP virtual. Server API adalah komponen dari sarana kontrol Kubernetes yang mengekspos API Kubernetes. Server API adalah ujung depan untuk bidang kontrol Kubernetes. KVA adalah komputer virtual yang menjalankan Mariner Linux dan menghosting kluster Kubernetes. Alamat IP mengambang dan juga digunakan untuk VM KVA lainnya yang Anda sebarkan di AKS di Azure Stack HCI. Komputer virtual KVA juga menghosting layanan load-balancer IP virtual Kubernetes.
Rencanakan alamat IP untuk jumlah VM sarana kontrol yang disebarkan di server target, karena mereka juga menggunakan lebih banyak alamat IP dari kumpulan IP virtual. Pertimbangan dijelaskan di bagian berikutnya.
Kluster target berisi VM load balancer, yaitu HAProxy dan memiliki Kumpulan IP virtual untuk kluster target. VM ini mengekspos semua layanan Kubernetes melalui Kumpulan IP virtual.
Aplikasi yang berjalan di pod Kubernetes menggunakan alamat IP dari kumpulan IP virtual.
Penyeimbang beban HAProxy disebarkan sebagai komputer virtual khusus dan dapat digunakan untuk memuat permintaan masuk keseimbangan di beberapa titik akhir. Mereka menggunakan alamat IP dari kumpulan IP virtual, dan Anda perlu merencanakan alamat IP untuk setiap kluster beban kerja.

Kumpulan IP mesin virtual node Kubernetes

Simpul Kubernetes disebarkan sebagai komputer virtual dalam AKS pada penyebaran Azure Stack HCI. Pastikan Anda merencanakan jumlah alamat IP sesuai dengan jumlah total simpul Kubernetes dan sertakan setidaknya tiga alamat IP lagi yang digunakan selama proses peningkatan. Untuk konfigurasi alamat IP statis, Anda perlu menentukan rentang kumpulan IP VM simpul Kubernetes, ini tidak diperlukan untuk alokasi DHCP. Rencanakan alamat IP tambahan untuk:

VM KVA juga menggunakan lebih banyak alamat IP untuk Kubernetes dari kumpulan IP VM simpul Kubernetes. Rencanakan untuk menambahkan alamat IP selama proses pembaruan, karena VM KVA menggunakan IP virtual yang sama untuk layanan API tetapi memerlukan IP terpisah dari kumpulan IP VM simpul Kubernetes.
Komputer virtual Sarana Kontrol mengonsumsi satu IP dari kumpulan IP VM simpul Kubernetes untuk layanan server API. Komputer virtual ini juga menghosting agen Azure ARC yang terhubung ke portal Azure untuk tujuan manajemen.
Simpul dalam kumpulan Simpul (Linux atau Windows) akan menggunakan alamat IP dari kumpulan IP yang dialokasikan untuk VM simpul Kubernetes.

Layanan cloud lokal Microsoft

Rencanakan rentang alamat IP untuk cloud lokal Microsoft (MOC), yang memungkinkan tumpukan manajemen sehingga VM di Azure Stack HCI dikelola di cloud. Alokasi alamat IP untuk layanan MOC ada di jaringan fisik yang mendasar, dan alamat IP yang dikonfigurasi untuk node kluster Azure Stack HCI ada di pusat data Anda. Anda dapat mengonfigurasi alamat IP untuk simpul fisik Azure Stack HCI Anda di salah satu hal berikut:

Node kluster Azure Stack HCI dengan mode alokasi alamat IP berbasis DHCP. Layanan MOC mendapatkan alamat IP dari layanan DHCP yang disajikan di jaringan fisik.
Simpul kluster Azure Stack HCI dengan model alokasi IP statis. Alamat IP untuk layanan cloud MOC harus secara eksplisit ditentukan sebagai rentang IP dalam format Classless Inter-Domain Routing (CIDR) dan harus berada di subnet yang sama dengan alamat IP node kluster Azure Stack HCI.

Load balancer di AKS di Azure Stack HCI

Untuk penyebaran kecil, Anda dapat menggunakan load balancer bawaan, yang disebarkan sebagai VM Linux yang menggunakan HAProxy + KeepAlive untuk mengirim lalu lintas ke layanan aplikasi yang disebarkan sebagai bagian dari kluster AKS. Load balancer HAProxy mengonfigurasi pod sebagai titik akhir di load balancer. Ini memuat permintaan keseimbangan ke server API Kubernetes dan mengelola lalu lintas ke layanan aplikasi.

Anda juga dapat menggunakan load balancer kustom untuk mengelola lalu lintas ke layanan Anda. Penyeimbang beban kustom memberikan fleksibilitas tambahan pada penyebaran dan memastikan bahwa AKS di Azure Stack HCI berfungsi bersama penyebaran yang ada seperti penyebaran Software Defined Network (SDN) yang menggunakan load balancer. Untuk penyeimbang beban kustom, IP kube-virtual menyediakan kluster Kubernetes dengan IP virtual dan load balancer untuk sarana kontrol dan Layanan Kube jenis LoadBalancer. Layanan IP kube-virtual secara otomatis disebarkan pada setiap simpul pekerja.

AKS di Azure Stack HCI juga mendukung penggunaan MetalLB atau load balancer berbasis OSS Kubernetes lainnya untuk menyeimbangkan lalu lintas yang ditujukan untuk layanan dalam kluster beban kerja. MetalLB adalah implementasi load-balancer untuk kluster Kubernetes bare metal, menggunakan protokol perutean standar, seperti protokol Border Gateway BGP. Ini dapat bekerja dengan add-on jaringan, Calico dan Flannel, tetapi Anda perlu memastikan bahwa rentang alamat IP virtual yang disediakan selama penginstalan AKS di Azure Stack HCI tidak tumpang tindih dengan rentang alamat IP yang direncanakan untuk load balancer kustom.

Menyebarkan skenario ini

Menyebarkan pengontrol ingress

Pertimbangkan untuk menerapkan pengontrol ingress untuk penghentian TLS, proksi yang dapat dibalik, atau perutean lalu lintas yang dapat dikonfigurasi. Pengontrol Ingress bekerja di Lapisan 7 dan dapat menggunakan aturan cerdas untuk mendistribusikan lalu lintas aplikasi. Sumber daya ingress Kubernetes digunakan untuk mengonfigurasi aturan dan rute ingress untuk masing-masing layanan Kubernetes. Saat Anda menentukan pengontrol ingress, Anda mengonsolidasikan aturan perutean lalu lintas menjadi satu sumber daya yang berjalan sebagai bagian dari kluster Anda.

Gunakan pengontrol ingress untuk mengekspos layanan melalui URL yang dapat dijangkau secara eksternal. Ingress mengekspos rute HTTP dan HTTPS dari luar kluster ke layanan dalam kluster. Perutean lalu lintas dikontrol oleh aturan yang ditentukan pada sumber daya ingress. Aturan HTTP ingress berisi informasi berikut:

Host opsional. Jika Anda tidak memberikan informasi host, aturan diterapkan ke semua lalu lintas HTTP masuk.
Daftar jalur yang memiliki backend terkait yang ditentukan dengan service.name dan service.port.name atau service.port.number.
Backend yang menyediakan kombinasi nama layanan dan port.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello-world
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    kubernetes.io/ingress.class: "nginx"
spec:
  rules:
  - host: test.example.com
     http:
       paths:
       - path: /hello-world
          pathType: Prefix
          backend:
            service:
              name: hello-world
              port:
                 number: 8080

Gunakan pengontrol ingress untuk menyeimbangkan lalu lintas antara backend aplikasi yang berbeda. Lalu lintas dibagi dan dikirim ke titik akhir dan penyebaran layanan yang berbeda, berdasarkan informasi jalur.

Untuk merutekan lalu lintas HTTP ke beberapa nama host pada alamat IP yang sama, Anda dapat menggunakan sumber daya ingress yang berbeda untuk setiap host. Lalu lintas yang datang melalui alamat IP load balancer dirutekan berdasarkan nama host dan jalur yang disediakan dalam aturan ingress.

Konsep jaringan kontainer di Azure Kubernetes Service (AKS) di Azure Stack HCI

Kubernetes menyediakan lapisan abstraksi ke jaringan virtual, sehingga aplikasi berbasis kontainer dapat berkomunikasi secara internal atau eksternal. Komponen kube-proxy berjalan pada setiap simpul dan dapat menyediakan akses langsung ke layanan, mendistribusikan lalu lintas menggunakan keseimbangan beban, atau menggunakan pengontrol ingress untuk perutean aplikasi yang lebih kompleks. Kubernetes menggunakan layanan untuk mengelompokkan satu set pod secara logis dan menyediakan konektivitas jaringan. Layanan Kubernetes berikut tersedia:

IP Kluster: Layanan ini membuat alamat IP internal untuk aplikasi internal saja.
NodePort: Layanan ini membuat pemetaan port pada simpul yang mendasar, yang membuat aplikasi dapat diakses langsung dengan alamat IP node dan port.
LoadBalancer: Anda dapat mengekspos layanan Kubernetes secara eksternal menggunakan aturan load-balancer atau pengontrol ingress.
ExternalName:. Layanan ini menggunakan entri DNS tertentu untuk aplikasi Kubernetes.

Jaringan Kubernetes

Di AKS di Azure Stack HCI, kluster dapat disebarkan menggunakan salah satu model jaringan berikut:

Jaringan Project Calico. Ini adalah model jaringan default untuk AKS di Azure Stack HCI dan didasarkan pada jaringan sumber terbuka yang menyediakan keamanan jaringan untuk kontainer, komputer virtual, dan beban kerja berbasis host asli. Kebijakan jaringan Calico dapat diterapkan pada segala jenis titik akhir seperti pod, kontainer, VM, atau antarmuka host. Setiap kebijakan terdiri dari aturan yang mengontrol lalu lintas masuk dan keluar dengan menggunakan tindakan yang dapat, baik mengizinkan, menolak, mencatat, atau melewati lalu lintas antara titik akhir sumber dan tujuan. Calico dapat menggunakan Linux extended Berkeley Packet Filter (eBPF) atau alur jaringan kernel Linux untuk pengiriman lalu lintas. Calico juga didukung pada Windows menggunakan Host Networking Service (HNS) untuk membuat namespace jaringan per titik akhir kontainer. Dalam model jaringan Kubernetes, setiap pod mendapatkan alamat IP sendiri yang dibagikan antara kontainer dalam pod tersebut. Pod berkomunikasi di jaringan menggunakan alamat IP Pod dan isolasi ditentukan menggunakan kebijakan jaringan. Calico menggunakan plugin CNI (Container Network Interface) untuk menambahkan atau menghapus pod ke dan dari jaringan pod Kubernetes dan plugin CNI IPAM (IP Address Management) untuk mengalokasikan dan merilis alamat IP.
Jaringan overlay flanel. Flanel membuat lapisan jaringan virtual yang melapisi jaringan host. Jaringan overlay menggunakan enkapulasi paket jaringan melalui jaringan fisik yang ada. Flanel menyederhanakan IP Address Management (IPAM), mendukung penggunaan ulang IP antara aplikasi dan namespace layanan yang berbeda, dan menyediakan pemisahan logis jaringan kontainer dari jaringan underlay yang digunakan oleh simpul Kube. Isolasi jaringan dicapai menggunakan Virtual eXtensible Local Area Network (VXLAN), protokol enkapulasi yang menyediakan konektivitas pusat data menggunakan penerowongan untuk meregangkan koneksi Lapisan 2 melalui jaringan Lapisan 3 yang mendasarinya. Flanel didukung baik oleh kontainer Linux menggunakan kontainer DaemonSet dan Windows menggunakan plugin Flanel CNI.

Desain jaringan Azure Stack HCI

Desain jaringan keseluruhan mencakup aktivitas perencanaan untuk Azure Stack HCI.

Pertama, mulailah dengan merencanakan perangkat keras dan penginstalan Azure Stack HCI. Anda dapat membeli sistem terintegrasi dari mitra perangkat keras Microsoft dengan sistem operasi Azure Stack HCI yang telah diinstal sebelumnya, atau Anda dapat membeli simpul yang divalidasi dan menginstal sistem operasi sendiri. Azure Stack HCI dimaksudkan sebagai host virtualisasi, sehingga peran server Kubernetes harus berjalan di dalam VM.

Persyaratan jaringan fisik untuk Azure Stack HCI

Microsoft tidak mensertifikasi sakelar jaringan, tetapi memiliki persyaratan tertentu yang harus dipenuhi vendor peralatan:

Standar: IEEE 802.1Q yang menentukan jaringan area lokal virtual (VLAN).
Standar: IEEE 802.1Qbb yang menentukan Priority Flow Control (PFC).
Standar: IEEE 802.1Qaz yang mendefinisikan Enhanced Transmission Selection (ETS).
Standar: IEEE 802.1AB yang menentukan protokol Link Layer Topology Discovery (LLTD).

Persyaratan jaringan host untuk Azure Stack HCI

Pertimbangkan untuk menggunakan adaptor jaringan yang telah mencapai sertifikasi Windows Server Software Defined Data Center (SDDC) dengan Kualifikasi Tambahan (AQ) Standar atau Premium.

Pastikan adaptor jaringan mendukung:

Dynamic Virtual Machine Multi-Queue (Dynamic VMMQ atau d.VMMQ) adalah teknologi sisi penerima yang cerdas untuk penyetelan otomatis pemrosesan lalu lintas jaringan ke inti CPU.
Remote Direct Memory Access (RDMA) adalah offload tumpukan jaringan ke adaptor jaringan. Dengan RDMA, lalu lintas penyimpanan SMB dapat melewati sistem operasi untuk diproses.
Dengan RDMA tamu, beban kerja SMB untuk VM bisa mendapatkan manfaat yang sama dengan menggunakan RDMA pada host.
Switch Embedded Teaming (SET) adalah teknologi tim berbasis perangkat lunak.

Pertimbangkan untuk menggunakan Network ATC, yang menyediakan kontrol berbasis niat untuk menyederhanakan konfigurasi jaringan host.

AKS pada Azure Stack HCI memerlukan koneksi jaringan bandwidth tinggi dan latensi rendah yang andal antara setiap simpul server. Pastikan setidaknya satu adaptor jaringan tersedia dan didedikasikan untuk manajemen kluster. Verifikasi juga bahwa sakelar fisik di jaringan Anda dikonfigurasi untuk memungkinkan lalu lintas pada VLAN apa pun yang akan Anda gunakan.

Sakelar virtual

Azure Stack HCI menyederhanakan desain jaringan dengan mengonfigurasi sakelar virtual yang dapat digunakan untuk klasifikasi jaringan. Kartu antarmuka jaringan virtual (vNIC) dapat ditempatkan di VLAN yang berbeda bagi host untuk menyediakan arus lalu lintas yang berbeda untuk jaringan berikut:

Jaringan manajemen. Jaringan manajemen adalah bagian dari jaringan utara-selatan dan digunakan untuk komunikasi host.
Jaringan komputasi. Jaringan komputasi adalah bagian dari jaringan utara-selatan dan digunakan untuk lalu lintas komputer virtual. Gunakan Kualitas Layanan (QOS), virtualisasi I/O akar tunggal (SR-IOV), dan Akses Memori Langsung Jarak Jauh (vRDMA) virtual untuk menyetel performa jaringan berdasarkan permintaan.
Jaringan penyimpanan. Jaringan penyimpanan adalah bagian dari jaringan timur-barat dan memerlukan RDMA dengan throughput yang direkomendasikan 10GB+. Ini digunakan untuk migrasi langsung VM.
Jaringan tamu VM.

Keuntungan lalu lintas Timur-Barat dari lalu lintas RDMA

Lalu lintas jaringan Timur-Barat mewakili komunikasi antara host, dan tidak mengekspos akses eksternal apa pun. Lalu lintas tetap berada dalam sakelar Top of Rack (ToR) dan batas Layer-2. Ini termasuk jenis lalu lintas berikut:

Heartbeat kluster dan komunikasi antar-simpul
[SMB] Lapisan Bus Penyimpanan
[SMB] Volume Bersama Kluster
[SMB] Pembangunan Ulang Penyimpanan

Lalu lintas Utara-Selatan

Lalu lintas Utara-Selatan adalah lalu lintas eksternal yang mencapai AKS pada kluster Azure Stack HCI. Anda dapat merencanakan lalu lintas untuk rentang layanan Azure yang memungkinkan pemantauan, penagihan, dan manajemen keamanan melalui integrasi Azure ARC. Lalu lintas utara-selatan memiliki karakteristik berikut:

Lalu lintas mengalir keluar dari sakelar ToR ke tulang belakang atau masuk dari tulang belakang ke sakelar ToR.
Lalu lintas meninggalkan rak fisik atau melewati batas Lapisan-3 (IP).
Lalu lintas mencakup manajemen (PowerShell, Pusat Admin Windows), komputasi (VM), dan lalu lintas kluster yang direntangkan antar situs.
Menggunakan sakelar Ethernet untuk konektivitas ke jaringan fisik.

AKS di Azure Stack HCI dapat menggunakan beberapa opsi penyebaran jaringan kluster:

Jaringan Terkonvergensi Menggabungkan Beberapa Niat Jaringan (MGMT, Komputasi, Penyimpanan). Ini adalah penyebaran yang direkomendasikan untuk lebih dari tiga simpul fisik dan mengharuskan semua adaptor jaringan fisik terhubung ke sakelar ToR yang sama. ROCEv2 sangat disarankan.
Penyebaran tanpa switch menggunakan komunikasi Utara-Selatan sebagai tim jaringan dengan menggabungkan jaringan komputasi dan manajemen.
Penyebaran hibrid sebagai kombinasi dari kedua penyebaran.

Rekomendasi

Rekomendasi berikut berlaku untuk sebagian besar skenario. Ikuti rekomendasi kecuali Anda memiliki persyaratan khusus yang menimpanya.

Rekomendasi jaringan

Perhatian utama dalam desain jaringan untuk AKS di Azure Stack HCI adalah memilih model jaringan yang menyediakan alamat IP yang cukup untuk kluster Kubernetes Anda, serta layanan dan aplikasinya.

Pertimbangkan untuk menerapkan alamat IP statis untuk memungkinkan AKS di Azure Stack HCI mengontrol penetapan alamat IP.
Dimensi dengan benar rentang alamat IP sehingga Anda memiliki cukup alamat IP gratis untuk kumpulan simpul Kubernetes dan untuk kumpulan IP virtual. Pastikan bahwa kumpulan IP virtual Anda cukup besar sehingga setiap kali Anda meningkatkan, Anda dapat menggunakan peningkatan bergulir, yang memerlukan lebih banyak alamat IP. Anda dapat merencanakan hal berikut:
- Alamat/nama host untuk pengaturan Proksi
- Alamat IP untuk sarana kontrol kluster target
- Alamat IP untuk Azure ARC
- Alamat IP untuk penskalaan horizontal simpul pekerja dan sarana kontrol dalam kluster target
Kumpulan IP virtual Anda harus cukup besar untuk mendukung penyebaran layanan aplikasi yang memerlukan konektivitas ke router eksternal.
Terapkan Calico CNI untuk memberikan kebijakan jaringan yang ditingkatkan untuk mengontrol pod dan komunikasi aplikasi.
Pastikan bahwa node kluster fisik (HCI atau Windows Server) terletak di rak yang sama dan terhubung ke sakelar ToR yang sama.
Nonaktifkan IPv6 pada semua adaptor jaringan.
Pastikan bahwa sakelar virtual yang ada dan namanya sama di semua node kluster.
Verifikasi bahwa semua subnet yang Anda tentukan untuk kluster Anda dapat dirutekan satu sama lain dan ke Internet.
Pastikan ada konektivitas jaringan antara host Azure Stack HCI dan VM penyewa.
Aktifkan pembaruan DNS dinamis di lingkungan DNS Anda untuk memungkinkan AKS di Azure Stack HCI mendaftarkan nama kluster generik agen cloud di sistem DNS untuk penemuan.
Pertimbangkan untuk menerapkan klasifikasi lalu lintas jaringan berdasarkan arahnya:
- Lalu lintas Utara-Selatan adalah lalu lintas dari Azure Stack HCI dan jaringan lainnya,
  - Manajemen
  - Compute
  - Lalu lintas kluster yang direntangkan antar situs
- Lalu lintas Timur-Barat dalam Azure Stack HCI:
  - Lalu lintas penyimpanan termasuk migrasi langsung antar simpul dalam kluster yang sama.
  - Sakelar Ethernet atau koneksi langsung.

Model lalu lintas penyimpanan

Gunakan beberapa subnet dan VLAN untuk memisahkan lalu lintas penyimpanan di Azure Stack HCI.
Pertimbangkan untuk menerapkan alokasi bandwidth lalu lintas dari berbagai jenis lalu lintas.

Pertimbangan

Microsoft Azure Well-Architected Framework adalah sekumpulan tenet panduan yang diikuti dalam skenario ini. Pertimbangan berikut disusun dalam konteks prinsip ini.

Keandalan

Ketahanan bawaan, yang melekat pada komputasi yang ditentukan perangkat lunak Microsoft (kluster failover simpul Hyper-V), penyimpanan (ketahanan berlapis Ruang Penyimpanan Langsung), dan jaringan (Jaringan yang Ditentukan Perangkat Lunak).
Pertimbangkan untuk memilih sakelar jaringan yang mendukung standar industri dan memastikan komunikasi yang andal antar simpul. Standar berikut meliputi:
- Standar: IEEE 802.1Q
- IEEE Standar 802.1Qbb
- Qas IEEE 802.1 Standar
- Standar IEEE 802.1 AB
Pertimbangkan untuk menerapkan beberapa host di kluster manajemen dan di kluster Kubernetes untuk memenuhi tingkat ketersediaan minimum untuk beban kerja.
AKS di Azure Stack HCI menggunakan pengklusteran failover dan migrasi langsung untuk ketersediaan tinggi dan toleransi kesalahan. Migrasi langsung adalah fitur Hyper-V yang memungkinkan Anda memindahkan mesin virtual secara transparan dari satu host Hyper-V ke host lain tanpa waktu henti yang dirasakan.
Anda harus memastikan bahwa layanan yang dirujuk di bagian Arsitektur didukung di wilayah tempat Azure Arc disebarkan.

Keamanan

Amankan lalu lintas antar pod menggunakan kebijakan jaringan di AKS di Azure Stack HCI.
Server API di AKS di Azure Stack HCI berisi Otoritas Sertifikat yang menandatangani sertifikat untuk komunikasi dari server API Kubernetes ke kubelet.
Gunakan akses menyeluruh (SSO) Microsoft Entra untuk membuat koneksi aman ke server API Kubernetes.
Anda dapat menggunakan Azure RBAC untuk mengelola akses ke Kubernetes dengan dukungan Azure Arc di seluruh Azure dan lingkungan lokal menggunakan identitas Microsoft Entra. Untuk informasi selengkapnya, lihat Menggunakan Azure RBAC untuk Otorisasi Kubernetes.

Pengoptimalan biaya

Gunakan harga Azure untuk memperkirakan biaya layanan yang digunakan dalam arsitektur. Praktik terbaik lainnya dijelaskan di bagian pengoptimalan biaya di Microsoft Azure Well-Architected Framework.
Pertimbangkan untuk menerapkan hyper-threading di komputer fisik Anda, untuk mengoptimalkan biaya, karena AKS pada unit penagihan Azure Stack HCI adalah inti virtual.
Fungsionalitas sarana kontrol Azure Arc disediakan tanpa biaya tambahan. Ini termasuk dukungan untuk organisasi sumber daya melalui grup dan tag manajemen Azure, dan kontrol akses melalui Azure RBAC. Layanan Azure yang digunakan bersama dengan server berkemampuan Azure Arc dikenakan biaya sesuai dengan penggunaannya.
Untuk efektivitas biaya, Anda dapat menggunakan sedikitnya dua node kluster dengan hanya empat disk dan 64 gigabyte (GB) memori per node. Agar lebih meminimalkan biaya, Anda dapat menggunakan interkoneksi switchless antar node, sehingga menghilangkan pentingnya perangkat switch yang redundan.

Keunggulan operasional

Manajemen yang disederhanakan menggunakan Pusat Admin Windows. Windows Admin Center adalah antarmuka pengguna untuk membuat serta mengelola AKS di Azure Stack HCI. Ini dapat diinstal pada Windows 10/11 atau Windows Server VM yang perlu didaftarkan di Azure dan berada di domain yang sama dengan kluster Azure Stack HCI atau Windows Server Datacenter.
Integrasi dengan Azure Arc atau berbagai layanan Azure yang menyediakan lebih banyak kemampuan manajemen, pemeliharaan, dan ketahanan (Azure Monitor, Azure Backup).
Jika kluster Kubernetes Anda dilampirkan ke Azure Arc, Anda dapat mengelola kluster Kubernetes menggunakan GitOps. Untuk meninjau praktik terbaik untuk menghubungkan kluster Kubernetes hibrid ke Azure Arc, lihat skenario manajemen dan penyebaran hibrid Azure Arc untuk kluster Kubernetes.
Platform Azure Stack HCI juga membantu menyederhanakan jaringan virtual untuk AKS pada kluster Azure Stack HCI dengan menyediakan jaringan "mendasar" dengan cara yang sangat tersedia.

Efisiensi kinerja

Gunakan perangkat keras bersertifikat Azure Stack HCI untuk meningkatkan waktu aktif dan performa aplikasi, manajemen dan operasi yang disederhanakan, dan menurunkan total biaya kepemilikan.
Penyimpanan: Ruang Penyimpanan Langsung
- Konfigurasi volume (cermin dua arah berlapis versus paritas yang dipercepat cermin berlapis)
- Konfigurasi disk (penembolokan, tingkatan)
Pastikan bahwa node kluster secara fisik terletak di rak yang sama dan terhubung ke sakelar ToR yang sama.
Rencanakan reservasi alamat IP untuk mengonfigurasi host AKS, kluster beban kerja, server API Kluster, Layanan Kubernetes, dan layanan aplikasi. Microsoft merekomendasikan untuk mengirimkan minimal 256 alamat IP untuk penyebaran AKS di Azure Stack HCI.
Pertimbangkan untuk menerapkan pengontrol ingress yang berfungsi pada lapisan 7 dan menggunakan aturan yang lebih cerdas untuk mendistribusikan lalu lintas aplikasi.
Gunakan akselerasi unit pemrosesan grafis (GPU) untuk beban kerja yang luas.

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

Lisa DenBeste | Manajer Program Manajemen Proyek
Kenny Lebih Keras | Manajer Proyek
Mike Kostersitz | Prospek Manajer Program Utama
Meg Olsen | Kepala sekolah
Perairan Nate | Manajer Pemasaran Produk

Kontributor lain:

Walter Oliver | Manajer Program Senior

Langkah berikutnya

Gambaran umum AKS

Arsitektur garis besar untuk AKS di Azure Stack HCI

Bagikan melalui

Arsitektur jaringan untuk AKS di Azure Stack HCI

Sistem

Komponen

Detail skenario

Jaringan simpul Kubernetes

Kumpulan IP virtual

Kumpulan IP mesin virtual node Kubernetes

Layanan cloud lokal Microsoft

Load balancer di AKS di Azure Stack HCI

Menyebarkan skenario ini

Menyebarkan pengontrol ingress

Konsep jaringan kontainer di Azure Kubernetes Service (AKS) di Azure Stack HCI

Jaringan Kubernetes

Desain jaringan Azure Stack HCI

Persyaratan jaringan fisik untuk Azure Stack HCI

Persyaratan jaringan host untuk Azure Stack HCI

Sakelar virtual

Keuntungan lalu lintas Timur-Barat dari lalu lintas RDMA

Lalu lintas Utara-Selatan

Rekomendasi

Rekomendasi jaringan

Model lalu lintas penyimpanan

Pertimbangan

Keandalan

Keamanan

Pengoptimalan biaya

Keunggulan operasional

Efisiensi kinerja

Kontributor

Langkah berikutnya

Saran dan Komentar

Sumber Daya Tambahan:

Bagikan melalui

Arsitektur jaringan untuk AKS di Azure Stack HCI

Sistem

Komponen

Detail skenario

Jaringan simpul Kubernetes

Kumpulan IP virtual

Kumpulan IP mesin virtual node Kubernetes

Layanan cloud lokal Microsoft

Load balancer di AKS di Azure Stack HCI

Menyebarkan skenario ini

Menyebarkan pengontrol ingress

Konsep jaringan kontainer di Azure Kubernetes Service (AKS) di Azure Stack HCI

Jaringan Kubernetes

Desain jaringan Azure Stack HCI

Persyaratan jaringan fisik untuk Azure Stack HCI

Persyaratan jaringan host untuk Azure Stack HCI

Sakelar virtual

Keuntungan lalu lintas Timur-Barat dari lalu lintas RDMA

Lalu lintas Utara-Selatan

Rekomendasi

Rekomendasi jaringan

Model lalu lintas penyimpanan

Pertimbangan

Keandalan

Keamanan

Pengoptimalan biaya

Keunggulan operasional

Efisiensi kinerja

Kontributor

Langkah berikutnya

Sumber daya terkait

Saran dan Komentar

Sumber Daya Tambahan: