Komponen Application Gateway untuk Kontainer

  • Artikel

Artikel ini menyediakan deskripsi dan persyaratan terperinci untuk komponen Application Gateway untuk Kontainer. Informasi tentang bagaimana Application Gateway untuk Kontainer menerima permintaan masuk dan merutekannya ke target backend disediakan. Untuk gambaran umum Application Gateway untuk Kontainer, lihat Apa itu Application Gateway untuk Kontainer.

Komponen inti

  • Sumber daya Application Gateway for Containers adalah sumber daya induk Azure yang menyebarkan sarana kontrol.
  • Sarana kontrol bertanggung jawab untuk mengatur konfigurasi proksi berdasarkan niat pelanggan.
  • Application Gateway untuk Kontainer memiliki dua sumber daya anak; asosiasi dan ujung depan.
    • Sumber daya anak hanya eksklusif untuk Application Gateway induk mereka untuk Kontainer dan mungkin tidak dirujuk oleh Application Gateway lain untuk sumber daya Kontainer.

Application Gateway untuk frontend Kontainer

  • Sumber daya frontend Application Gateway untuk Kontainer adalah sumber daya anak Azure dari Application Gateway untuk sumber daya induk Kontainer.
  • Frontend Application Gateway for Containers menentukan lalu lintas klien titik masuk harus diterima oleh Application Gateway untuk Kontainer tertentu.
    • Frontend tidak dapat dikaitkan dengan beberapa Application Gateway untuk Kontainer.
    • Setiap frontend menyediakan FQDN unik yang dapat direferensikan oleh data CNAME pelanggan.
    • Alamat IP privat saat ini tidak didukung.
  • Satu Application Gateway untuk Kontainer dapat mendukung beberapa frontend.

Application Gateway untuk asosiasi Kontainer

  • Sumber daya asosiasi Application Gateway untuk Kontainer adalah sumber daya anak Azure dari Application Gateway untuk sumber daya induk Kontainer.
  • Asosiasi Application Gateway for Containers mendefinisikan titik koneksi ke jaringan virtual. Asosiasi adalah pemetaan 1:1 dari sumber daya asosiasi ke Azure Subnet yang telah didelegasikan.
  • Application Gateway untuk Kontainer dirancang untuk memungkinkan beberapa asosiasi.
    • Saat ini, jumlah asosiasi saat ini dibatasi hingga 1.
  • Selama pembuatan asosiasi, bidang data yang mendasar disediakan dan terhubung ke subnet dalam subnet jaringan virtual yang ditentukan.
  • Setiap asosiasi harus mengasumsikan setidaknya 256 alamat tersedia di subnet pada saat provisi.
    • Masker subnet minimum /24 untuk setiap penyebaran (dengan asumsi tidak ada sumber daya yang sebelumnya telah disediakan di subnet).
      • Jika n jumlah Application Gateway untuk Kontainer disediakan, dengan asumsi setiap Application Gateway untuk Kontainer berisi satu asosiasi, dan niatnya adalah untuk berbagi subnet yang sama, alamat yang diperlukan yang tersedia harus n*256.
    • Semua sumber daya asosiasi Application Gateway untuk Kontainer harus cocok dengan wilayah yang sama dengan Application Gateway untuk sumber daya induk Kontainer.

Application Gateway untuk Pengontrol ALB Kontainer

  • Application Gateway untuk Containers ALB Controller adalah penyebaran Kubernetes yang mengatur konfigurasi dan penyebaran Application Gateway untuk Kontainer dengan menonton Kubernetes baik Sumber Daya Kustom maupun konfigurasi Sumber Daya, seperti, tetapi tidak terbatas pada, Ingress, Gateway, dan ApplicationLoadBalancer. Ini menggunakan ARM / Application Gateway untuk API konfigurasi Kontainer untuk menyebarluaskan konfigurasi ke Application Gateway untuk penyebaran Azure Kontainer.
  • Pengontrol ALB disebarkan / diinstal melalui Helm.
  • Pengontrol ALB terdiri dari dua pod yang sedang berjalan.
    • pod alb-controller bertanggung jawab untuk mengatur niat pelanggan ke Application Gateway untuk konfigurasi penyeimbangan beban Kontainer.
    • pod alb-controller-bootstrap bertanggung jawab atas manajemen CRD.

Konsep Azure / umum

Alamat IP privat

  • Alamat IP privat tidak secara eksplisit didefinisikan sebagai sumber daya Azure Resource Manager. Alamat IP privat akan merujuk ke alamat host tertentu dalam subnet jaringan virtual tertentu.

Delegasi subnet

  • Microsoft.ServiceNetworking/trafficControllers adalah namespace layanan yang diadopsi oleh Application Gateway untuk Kontainer dan dapat didelegasikan ke subnet jaringan virtual.
  • Ketika delegasi terjadi, provisi application Gateway untuk sumber daya Kontainer tidak terjadi, juga tidak ada pemetaan eksklusif ke sumber daya asosiasi Application Gateway for Containers.
  • Sejumlah subnet dapat memiliki delegasi subnet yang sama atau berbeda dengan Application Gateway untuk Kontainer. Setelah ditentukan, tidak ada sumber daya lain, selain layanan yang ditentukan, yang dapat disediakan ke dalam subnet kecuali ditentukan secara eksplisit oleh implementasi layanan.

Identitas terkelola yang ditetapkan pengguna

  • Identitas terkelola untuk sumber daya Azure menghilangkan kebutuhan untuk mengelola kredensial dalam kode.
  • Identitas Terkelola Pengguna diperlukan untuk setiap Pengontrol Azure Load Balancer untuk membuat perubahan pada Application Gateway untuk Kontainer.
  • AppGw untuk Containers Configuration Manager adalah peran RBAC bawaan yang memungkinkan Pengontrol ALB mengakses dan mengonfigurasi Application Gateway untuk sumber daya Kontainer.

Catatan

Peran AppGw untuk Containers Configuration Manager memiliki izin tindakan data yang tidak dimiliki peran Pemilik dan Kontributor. Izin yang tepat sangat penting didelegasikan untuk mencegah masalah dengan Pengontrol ALB yang membuat perubahan pada layanan Application Gateway for Containers.

Cara Application Gateway untuk Kontainer menerima permintaan

Setiap frontend Application Gateway for Containers menyediakan Nama Domain yang Sepenuhnya Memenuhi Syarat yang dihasilkan yang dikelola oleh Azure. FQDN dapat digunakan apa adanya atau pelanggan dapat memilih untuk menutupi FQDN dengan catatan CNAME.

Sebelum klien mengirim permintaan ke Application Gateway untuk Kontainer, klien menyelesaikan CNAME yang menunjuk ke FQDN frontend; atau klien dapat langsung menyelesaikan FQDN yang disediakan oleh Application Gateway untuk Kontainer dengan menggunakan server DNS.

Pemecah masalah DNS menerjemahkan catatan DNS ke alamat IP.

Ketika klien memulai permintaan, nama DNS yang ditentukan diteruskan sebagai header host ke Application Gateway untuk Kontainer pada frontend yang ditentukan.

Sekumpulan aturan perutean mengevaluasi bagaimana permintaan untuk nama host tersebut harus dimulai ke target backend yang ditentukan.

Cara Application Gateway untuk Kontainer merutekan permintaan

Permintaan HTTP/2

Application Gateway untuk Kontainer sepenuhnya mendukung protokol HTTP/2 untuk komunikasi dari klien ke frontend. Komunikasi dari Application Gateway untuk Kontainer ke target backend menggunakan protokol HTTP/1.1. Pengaturan HTTP/2 selalu diaktifkan dan tidak dapat diubah. Jika klien lebih suka menggunakan HTTP/1.1 untuk komunikasi mereka ke frontend Application Gateway untuk Kontainer, mereka dapat terus bernegosiasi.

Modifikasi pada permintaan

Application Gateway untuk Kontainer menyisipkan tiga header tambahan ke semua permintaan sebelum permintaan dimulai dari Application Gateway untuk Kontainer ke target backend:

  • x-forwarded-for
  • x-forwarded-proto
  • x-request-id

x-forwarded-for adalah alamat IP klien pemohon asli. Jika permintaan masuk melalui proksi, nilai header menambahkan alamat yang diterima, dibatasi koma. Dalam contoh: 1.2.3.4,5.6.7.8; di mana 1.2.3.4 adalah alamat IP klien ke proksi di depan Application Gateway untuk Kontainer, dan 5.6.7.8 adalah alamat lalu lintas penerusan proksi ke Application Gateway untuk Kontainer.

x-forwarded-proto mengembalikan protokol yang diterima oleh Application Gateway untuk Kontainer dari klien. Nilainya adalah http atau https.

x-request-id adalah guid unik yang dihasilkan oleh Application Gateway untuk Kontainer untuk setiap permintaan klien dan disajikan dalam permintaan yang diteruskan ke target backend. Guid terdiri dari 32 karakter alfanumerik, dipisahkan oleh tanda hubung (misalnya: d23387ab-e629-458a-9c93-6108d374bc75). Guid ini dapat digunakan untuk menghubungkan permintaan yang diterima oleh Application Gateway untuk Kontainer dan dimulai ke target backend seperti yang didefinisikan dalam log akses.

Batas waktu permintaan

Application Gateway untuk Kontainer memberlakukan batas waktu berikut karena permintaan dimulai dan dikelola antara klien, AGC, dan backend.

Waktu habis Durasi Deskripsi
Waktu permintaan habis 60 detik waktu di mana AGC menunggu respons target backend.
Batas Waktu Diam HTTP 5 menit batas waktu menganggur sebelum menutup koneksi HTTP.
Batas Waktu Diam Streaming 5 menit batas waktu menganggur sebelum menutup aliran individual yang dibawa oleh koneksi HTTP.
Batas Waktu Koneksi Upstram 5 detik waktu untuk membuat koneksi ke target backend.