Bagikan melalui

Menggunakan load balancer standar publik di Azure Kubernetes Service (AKS)

  • Artikel

Azure Load Balancer beroperasi pada lapisan 4 model Open Systems Interconnection (OSI) yang mendukung skenario masuk dan keluar. Ini mendistribusikan alur masuk yang tiba di ujung depan penyeimbang beban ke instans kumpulan ujung belakang.

Load balancer publik yang terintegrasi dengan AKS melayani dua tujuan:

  1. Untuk menyediakan koneksi keluar ke node kluster di dalam jaringan virtual AKS dengan menerjemahkan alamat IP privat ke bagian alamat IP publik dari Kumpulan Keluarnya.
  2. Untuk menyediakan akses ke aplikasi melalui layanan Kubernetes jenis LoadBalancer, memungkinkan Anda untuk dengan mudah menskalakan aplikasi Anda dan membuat layanan yang sangat tersedia.

Load balancer internal (atau privat) digunakan ketika hanya IP privat yang diizinkan sebagai frontend. Load balancer internal digunakan untuk memuat lalu lintas keseimbangan di dalam jaringan virtual. Load balancer frontend dapat diakses dari jaringan lokal dalam skenario hibrid.

Artikel ini membahas integrasi dengan load balancer publik di AKS. Untuk integrasi load balancer internal, lihat Menggunakan load balancer internal di AKS.

Sebelum Anda mulai

  • Azure Load Balancer tersedia dalam dua SKU: Dasar dan Standar. SKU Standar digunakan secara default saat Anda membuat kluster AKS. SKU Standar memberi Anda akses ke fungsionalitas tambahan, seperti kumpulan backend yang lebih besar, beberapa kumpulan node, Zona Ketersediaan, dan secara default aman. Ini adalah SKU load balancer yang direkomendasikan untuk AKS. Untuk informasi selengkapnya tentang SKU Dasar dan Standar , lihat Perbandingan SKU Azure Load Balancer.
  • Untuk daftar lengkap anotasi yang didukung untuk layanan Kubernetes dengan jenis LoadBalancer, lihat Anotasi LoadBalancer.
  • Artikel ini mengasumsikan Anda memiliki kluster AKS dengan Azure Load Balancer SKU Standar . Jika Anda memerlukan kluster AKS, Anda dapat membuatnya menggunakan Azure CLI, Azure PowerShell, atau portal Azure.
  • AKS mengelola siklus hidup dan operasi simpul agen. Memodifikasi sumber daya IaaS yang terkait dengan simpul agen tidak didukung. Contoh operasi yang tidak didukung adalah membuat perubahan manual pada grup sumber daya load balancer.

Penting

Jika Anda lebih suka menggunakan gateway, firewall, atau proksi Anda sendiri untuk menyediakan koneksi keluar, Anda dapat melewati pembuatan kumpulan keluar load balancer dan IP frontend masing-masing dengan menggunakan jenis keluar sebagai UserDefinedRouting (UDR). Jenis keluar mendefinisikan metode keluar untuk kluster dan default untuk mengetik LoadBalancer.

Membuat load balancer standar publik

Setelah Anda membuat kluster AKS dengan jenis LoadBalancer keluar (default), kluster Anda siap menggunakan load balancer untuk mengekspos layanan.

Buat manifes layanan bernama public-svc.yaml, yang membuat layanan publik jenis LoadBalancer.

apiVersion: v1
kind: Service
metadata:
  name: public-svc
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: public-app

Tentukan alamat IP load balancer

Jika Anda ingin menggunakan alamat IP tertentu dengan load balancer, ada dua cara:

Penting

Menambahkan properti LoadBalancerIP ke manifes YAML load balancer tidak digunakan lagi setelah Kubernetes upstream. Meskipun penggunaan saat ini tetap sama dan layanan yang ada diharapkan berfungsi tanpa modifikasi, kami sangat menyarankan pengaturan anotasi layanan sebagai gantinya.

  • Atur anotasi layanan: Gunakan service.beta.kubernetes.io/azure-load-balancer-ipv4 untuk alamat IPv4 dan service.beta.kubernetes.io/azure-load-balancer-ipv6 untuk alamat IPv6.
  • Tambahkan properti LoadBalancerIP ke manifes YAML load balancer: Tambahkan properti Service.Spec.LoadBalancerIP ke manifes YAML load balancer. Bidang ini tidak digunakan lagi mengikuti Kubernetes upstream, dan tidak dapat mendukung dual-stack. Penggunaan saat ini tetap sama dan layanan yang ada diharapkan berfungsi tanpa modifikasi.

Menyebarkan manifes layanan

Sebarkan manifes layanan publik menggunakan kubectl apply dan tentukan nama manifes YAML Anda.

kubectl apply -f public-svc.yaml

Azure Load Balancer dikonfigurasi dengan IP publik baru yang berada di depan layanan baru. Karena Azure Load Balancer dapat memiliki beberapa IP frontend, setiap layanan baru yang Anda sebarkan mendapatkan IP frontend khusus baru untuk diakses secara unik.

Konfirmasikan layanan Anda dibuat dan load balancer dikonfigurasi menggunakan perintah berikut.

kubectl get service public-svc

NAMESPACE     NAME          TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)         AGE
default       public-svc    LoadBalancer   10.0.39.110    203.0.113.187   80:32068/TCP    52s

Saat Anda melihat detail layanan, alamat IP publik yang dibuat untuk layanan ini pada load balancer ditampilkan pada kolom EXTERNAL-IP. Mungkin perlu beberapa menit agar alamat IP berubah dari <tertunda> ke alamat IP publik yang sebenarnya.

Untuk informasi lebih rinci tentang layanan Anda, gunakan perintah berikut.

kubectl describe service public-svc

Contoh output berikut adalah versi output yang ringkas setelah Anda menjalankan kubectl describe service. LoadBalancer Ingress menunjukkan alamat IP eksternal yang diekspos oleh layanan Anda. IP menunjukkan alamat internal.

Name:                        public-svc
Namespace:                   default
Labels:                      <none>
Annotations:                 <none>
Selector:                    app=public-app
...
IP:                          10.0.39.110
...
LoadBalancer Ingress:        203.0.113.187
...
TargetPort:                  80/TCP
NodePort:                    32068/TCP
...
Session Affinity:            None
External Traffic Policy:     Cluster
...

Mengonfigurasi load balancer standar publik

Anda dapat menyesuaikan pengaturan yang berbeda untuk load balancer publik standar Anda pada waktu pembuatan kluster atau dengan memperbarui kluster. Opsi penyesuaian ini memungkinkan Anda membuat load balancer yang memenuhi kebutuhan beban kerja Anda. Dengan load balancer standar, Anda dapat:

  • Atur atau skalakan jumlah IP keluar terkelola.
  • Bawa IP keluar kustom Anda sendiri atau awalan IP keluar.
  • Sesuaikan jumlah port keluar yang dialokasikan ke setiap simpul pada kluster.
  • Konfigurasikan pengaturan batas waktu untuk koneksi diam.

Penting

Hanya satu opsi IP keluar (IP terkelola, bawa IP Anda sendiri, atau awalan IP) yang dapat digunakan pada waktu tertentu.

Mengubah jenis kumpulan masuk

Simpul AKS dapat dirujuk di kumpulan backend load balancer dengan konfigurasi IP mereka (keanggotaan berbasis Azure Virtual Machine Scale Sets) atau hanya dengan alamat IP mereka. Memanfaatkan keanggotaan kumpulan backend berbasis alamat IP memberikan efisiensi yang lebih tinggi saat memperbarui layanan dan menyediakan load balancer, terutama pada jumlah simpul yang tinggi. Provisi kluster baru dengan kumpulan backend berbasis IP dan mengonversi kluster yang ada sekarang didukung. Ketika dikombinasikan dengan NAT Gateway atau jenis keluar perutean yang ditentukan pengguna, provisi simpul dan layanan baru lebih berkinerja.

Tersedia dua jenis keanggotaan kumpulan yang berbeda:

  • nodeIPConfiguration - jenis keanggotaan kumpulan berbasis konfigurasi IP Set Skala Komputer Virtual warisan
  • nodeIP - Jenis keanggotaan berbasis IP

Persyaratan

  • Kluster AKS harus versi 1.23 atau yang lebih baru.
  • Kluster AKS harus menggunakan load balancer standar dan set skala komputer virtual.

Membuat kluster AKS baru dengan keanggotaan kumpulan masuk berbasis IP

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-backend-pool-type=nodeIP \
    --generate-ssh-keys

Memperbarui kluster AKS yang ada untuk menggunakan keanggotaan kumpulan masuk berbasis IP

Peringatan

Operasi ini menyebabkan gangguan sementara pada lalu lintas layanan masuk di kluster. Waktu dampak meningkat dengan kluster yang lebih besar yang memiliki banyak simpul.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-backend-pool-type=nodeIP

Menskalakan jumlah IP publik keluar yang dikelola

Azure Load Balancer menyediakan konektivitas keluar dan masuk dari jaringan virtual. Aturan keluar memudahkan untuk mengonfigurasi terjemahan alamat jaringan untuk load balancer standar publik.

Aturan keluar mengikuti sintaks yang sama dengan penyeimbangan beban dan aturan NAT masuk:

IP frontend + parameter + kumpulan backend

Aturan keluar mengonfigurasi NAT keluar untuk semua komputer virtual yang diidentifikasi oleh kumpulan backend untuk diterjemahkan ke frontend. Parameter memberikan kontrol lebih atas algoritma NAT keluar.

Meskipun Anda dapat menggunakan aturan keluar dengan satu alamat IP publik, aturan keluar sangat bagus untuk menskalakan NAT keluar karena meringankan beban konfigurasi. Anda dapat menggunakan beberapa alamat IP untuk merencanakan skenario skala besar dan aturan keluar untuk mengurangi pola rawan kelelahan SNAT. Setiap alamat IP yang disediakan oleh frontend menyediakan port sementara 64k agar load balancer dapat digunakan sebagai port SNAT.

Saat menggunakan load balancer SKU Standar dengan IP publik keluar terkelola (yang dibuat secara default), Anda dapat menskalakan jumlah IP publik keluar terkelola menggunakan --load-balancer-managed-outbound-ip-count parameter .

Gunakan perintah berikut untuk memperbarui kluster yang ada. Anda juga dapat mengatur parameter ini agar memiliki beberapa IP publik keluar terkelola.

Penting

Kami tidak menyarankan penggunaan portal Azure untuk membuat perubahan aturan keluar. Saat membuat perubahan ini, Anda harus melalui kluster AKS dan tidak langsung pada sumber daya Load Balancer.

Perubahan aturan keluar yang dilakukan langsung pada sumber daya Load Balancer dihapus setiap kali kluster direkonsiliasi, seperti ketika dihentikan, dimulai, ditingkatkan, atau diskalakan.

Gunakan Azure CLI, seperti yang ditunjukkan dalam contoh. Perubahan aturan keluar yang dibuat menggunakan az aks perintah CLI bersifat permanen di seluruh waktu henti kluster.

Untuk informasi selengkapnya, lihat Aturan keluar Azure Load Balancer.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-managed-outbound-ip-count 2

Contoh di atas menetapkan jumlah IP publik keluar yang dikelola menjadi 2 untuk kluster myAKSCluster di myResourceGroup.

Pada waktu pembuatan kluster, Anda juga dapat mengatur jumlah awal IP publik keluar terkelola dengan menambahkan --load-balancer-managed-outbound-ip-count parameter dan mengaturnya ke nilai yang Anda inginkan. Jumlah default IP publik keluar terkelola adalah 1.

Menyediakan IP publik keluar atau awalan Anda sendiri

Saat Anda menggunakan load balancer SKU Standar , kluster AKS secara otomatis membuat IP publik di grup sumber daya infrastruktur yang dikelola AKS dan menetapkannya ke kumpulan keluar load balancer secara default.

IP publik yang dibuat oleh AKS adalah sumber daya yang dikelola AKS, yang berarti AKS mengelola siklus hidup IP publik tersebut dan tidak memerlukan tindakan pengguna langsung pada sumber daya IP publik. Atau, Anda dapat menetapkan IP publik kustom Anda sendiri atau awalan IP publik pada waktu pembuatan kluster. IP kustom Anda juga dapat diperbarui pada properti penyeimbang muatan kluster yang ada.

Persyaratan untuk menggunakan IP publik atau awalan Anda sendiri meliputi:

  • Pengguna harus membuat dan memiliki alamat IP publik kustom. Alamat IP publik terkelola yang dibuat oleh AKS tidak dapat digunakan kembali sebagai "bawa IP kustom Anda sendiri" karena dapat menyebabkan konflik manajemen.
  • Anda harus memastikan identitas kluster AKS (Perwakilan Layanan atau Identitas Terkelola) memiliki izin untuk mengakses IP keluar, sesuai daftar izin IP publik yang diperlukan.
  • Pastikan Anda memenuhi prasyarat dan batasan yang diperlukan untuk mengonfigurasi IP keluar atau awalan IP keluar.

Perbarui kluster dengan IP publik keluar Anda sendiri

az network public-ip show Gunakan perintah untuk mencantumkan ID IP publik Anda.

az network public-ip show --resource-group myResourceGroup --name myPublicIP --query id -o tsv

Perintah di atas menunjukkan ID untuk IP publik myPublicIP di grup sumber daya myResourceGroup.

Gunakan perintah az aks update dengan parameter untuk memperbarui kluster Anda dengan IP publik load-balancer-outbound-ips Anda.

Contoh berikut menggunakan load-balancer-outbound-ips parameter dengan ID dari perintah sebelumnya.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-outbound-ips <publicIpId1>,<publicIpId2>

Perbarui kluster dengan awalan IP publik keluar Anda sendiri

Anda juga dapat menggunakan awalan IP publik untuk keluar dengan load balancer Standar SKU Anda. Contoh berikut menggunakan perintah az network public-ip prefix show untuk mencantumkan ID awalan IP publik Anda.

az network public-ip prefix show --resource-group myResourceGroup --name myPublicIPPrefix --query id -o tsv

Perintah di atas menunjukkan ID untuk awalan IP publik myPublicIPPrefix di grup sumber daya myResourceGroup.

Contoh berikut menggunakan parameter load-balancer-outbound-ip-prefixes dengan ID dari perintah sebelumnya.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-outbound-ip-prefixes <publicIpPrefixId1>,<publicIpPrefixId2>

Buat kluster dengan IP publik atau awalan Anda sendiri

Saat membuat kluster, Anda dapat membawa alamat IP atau awalan IP Anda sendiri untuk keluar untuk mendukung skenario seperti menambahkan titik akhir keluar ke daftar yang diizinkan. Untuk menentukan IP publik dan prefiks IP Anda sendiri pada waktu pembuatan kluster, Anda menambahkan parameter yang sama yang ditunjukkan pada perintah sebelumnya.

az aks create Gunakan perintah dengan load-balancer-outbound-ips parameter untuk membuat kluster baru dengan IP publik Anda sendiri.

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-outbound-ips <publicIpId1>,<publicIpId2> \
    --generate-ssh-keys

az aks create Gunakan perintah dengan load-balancer-outbound-ip-prefixes parameter untuk membuat kluster baru dengan awalan IP publik Anda sendiri.

az aks create \
    --resource-group myResourceGroup \
    --load-balancer-outbound-ip-prefixes <publicIpPrefixId1>,<publicIpPrefixId2> \
    --generate-ssh-keys

Mengonfigurasi port keluar yang dialokasikan

Penting

Jika Anda memiliki aplikasi di kluster yang dapat membuat sejumlah besar koneksi ke serangkaian tujuan kecil pada alamat IP publik, seperti banyak instans aplikasi frontend yang terhubung ke database, Anda mungkin memiliki skenario yang rentan mengalami kelelahan port SNAT. Port SNAT habis terjadi ketika aplikasi tidak memiliki port keluar yang dapat digunakan untuk melakukan koneksi ke aplikasi atau host lain. Jika Anda memiliki skenario yang rentan mengalami kelelahan port SNAT, kami sangat menyarankan Anda meningkatkan port keluar yang dialokasikan dan IP frontend keluar pada load balancer.

Untuk informasi selengkapnya tentang SNAT, lihat Menggunakan SNAT untuk koneksi keluar.

Secara default, AKS menetapkan AllocatedOutboundPorts pada penyeimbang muatan ke 0, yang memungkinkan penetapan port keluar otomatis berdasarkan ukuran kumpulan backend ketika membuat kluster. Misalnya, jika kluster memiliki 50 node atau kurang, 1024 port akan dialokasikan ke setiap node. Nilai ini memungkinkan penskalaan ke jumlah node maksimum kluster tanpa memerlukan konfigurasi ulang jaringan, tetapi dapat membuat kelelahan port SNAT lebih umum karena lebih banyak simpul ditambahkan. Ketika jumlah simpul dalam kluster meningkat, lebih sedikit port yang tersedia per simpul. Meningkatkan jumlah simpul di seluruh batas dalam bagan (misalnya, dari 50 ke 51 simpul atau 100 hingga 101) mungkin mengganggu konektivitas karena port SNAT yang dialokasikan ke simpul yang ada dikurangi untuk memungkinkan lebih banyak simpul. Menggunakan nilai eksplisit untuk AllocatedOutboundPorts, seperti yang ditunjukkan di bawah ini, disarankan.

Untuk memperlihatkan nilai AllocatedOutboundPorts untuk penyeimbang muatan kluster AKS, gunakan az network lb outbound-rule list.

NODE_RG=$(az aks show --resource-group myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv)
az network lb outbound-rule list --resource-group $NODE_RG --lb-name kubernetes -o table

Contoh output berikut menunjukkan bahwa penetapan port keluar otomatis berdasarkan ukuran kumpulan backend diaktifkan untuk kluster.

AllocatedOutboundPorts    EnableTcpReset    IdleTimeoutInMinutes    Name             Protocol    ProvisioningState    ResourceGroup
------------------------  ----------------  ----------------------  ---------------  ----------  -------------------  -------------
0                         True              30                      aksOutboundRule  All         Succeeded            MC_myResourceGroup_myAKSCluster_eastus

Untuk mengonfigurasi nilai tertentu untuk AllocatedOutboundPorts dan alamat IP keluar saat membuat atau memperbarui klaster, gunakan load-balancer-outbound-ports dan load-balancer-managed-outbound-ip-count, load-balancer-outbound-ips, atau load-balancer-outbound-ip-prefixes. Sebelum mengatur nilai tertentu atau meningkatkan nilai yang ada untuk port keluar atau alamat IP keluar, Anda harus menghitung jumlah port keluar dan alamat IP yang sesuai. Gunakan persamaan berikut untuk penghitungan yang dibulatkan ke bilangan bulat terdekat ini: 64,000 ports per IP / <outbound ports per node> * <number of outbound IPs> = <maximum number of nodes in the cluster>.

Penting

Menambahkan lebih banyak alamat IP keluar ke kluster tidak akan menyediakan lebih banyak port SNAT yang tersedia untuk simpul kecuali nilai bukan nol untuk AllocatedOutboundPorts diatur. Jika AllocatedOutboundPorts dibiarkan pada nilai 0default , port SNAT untuk simpul masih akan diatur per tabel dalam dokumentasi Load Balancer dan port tambahan dari IP tambahan tidak akan digunakan.

Saat menghitung jumlah port dan IP keluar dan mengatur nilai, ingatlah informasi berikut:

  • Jumlah port keluar per simpul diperbaiki berdasarkan nilai yang Anda tetapkan.
  • Nilai untuk port keluar harus berupa kelipatan 8.
  • Menambahkan lebih banyak IP tidak menambahkan lebih banyak port ke simpul apa pun, tetapi menyediakan kapasitas untuk lebih banyak simpul dalam kluster.
  • Anda harus memperhitungkan simpul yang mungkin ditambahkan sebagai bagian dari peningkatan, termasuk jumlah simpul yang ditentukan melalui nilai maxSurge.

Contoh berikut menunjukkan bagaimana nilai yang Anda tetapkan memengaruhi jumlah port keluar dan alamat IP:

  • Jika nilai default digunakan dan kluster memiliki 48 simpul, setiap simpul memiliki 1024 port yang tersedia.
  • Jika nilai default digunakan dan kluster diskalakan dari 48 hingga 52 simpul, setiap simpul diperbarui dari 1024 port yang tersedia untuk 512 port yang tersedia.
  • Jika jumlah port keluar diatur ke 1.000 dan jumlah IP keluar diatur ke 2, maka kluster dapat mendukung maksimum 128 simpul: 64,000 ports per IP / 1,000 ports per node * 2 IPs = 128 nodes.
  • Jika jumlah port keluar diatur ke 1.000 dan jumlah IP keluar diatur ke 7, maka kluster dapat mendukung maksimum 448 simpul: 64,000 ports per IP / 1,000 ports per node * 7 IPs = 448 nodes.
  • Jika jumlah port keluar diatur ke 4.000 dan jumlah IP keluar diatur ke 2, maka kluster dapat mendukung maksimum 32 simpul: 64,000 ports per IP / 4,000 ports per node * 2 IPs = 32 nodes.
  • Jika jumlah port keluar diatur ke 4.000 dan jumlah IP keluar diatur ke 7, maka kluster dapat mendukung maksimum 112 simpul: 64,000 ports per IP / 4,000 ports per node * 7 IPs = 112 nodes.

Penting

Setelah menghitung jumlah port dan IP keluar, pastikan Anda memiliki kapasitas port keluar tambahan untuk menangani lonjakan node selama peningkatan. Sangat penting untuk mengalokasikan port berlebih yang memadai untuk simpul tambahan yang diperlukan untuk peningkatan dan operasi lainnya. Default AKS ke satu node buffer untuk operasi peningkatan. Jika menggunakan nilai maxSurge, kalikan jumlah port keluar per node dengan nilai maxSurge untuk menentukan jumlah port yang diperlukan. Misalnya, jika Anda menghitung bahwa Anda memerlukan 4000 port per simpul dengan 7 alamat IP pada kluster dengan maksimum 100 simpul dan lonjakan maksimum 2:

  • 2 node lonjakan * 4000 port per node = 8000 port yang diperlukan untuk lonjakan node selama peningkatan.
  • 100 node * 4000 port per node = 400.000 port yang diperlukan untuk kluster Anda.
  • 7 IP * 64000 port per IP = 448.000 port tersedia untuk kluster Anda.

Contoh di atas menunjukkan kluster memiliki kelebihan kapasitas sejumlah 48.000 port, yang cukup untuk menangani 8000 port yang diperlukan untuk lonjakan node selama peningkatan.

Setelah nilai dihitung dan diverifikasi, Anda dapat menerapkan nilai-nilai tersebut menggunakan load-balancer-outbound-ports, dan load-balancer-managed-outbound-ip-count, load-balancer-outbound-ips, atau load-balancer-outbound-ip-prefixes saat membuat atau memperbarui kluster.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-managed-outbound-ip-count 7 \
    --load-balancer-outbound-ports 4000

Mengonfigurasi batas waktu diam load balancer

Ketika sumber daya port SNAT habis, aliran keluar gagal sampai aliran saat ini melepaskan port SNAT. Load balancer mengklaim kembali port SNAT saat alur ditutup, dan load balancer yang dikonfigurasi AKS menggunakan batas waktu menganggur 30 menit untuk mengklaim kembali port SNAT dari aliran diam.

Anda juga dapat menggunakan transportasi (misalnya, TCP keepalives atau application-layer keepalives) untuk menyegarkan aliran diam dan mengatur ulang batas waktu diam ini jika perlu. Anda dapat mengonfigurasi batas waktu ini dengan mengikuti contoh di bawah ini.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-idle-timeout 4

Jika Anda berharap memiliki banyak koneksi berumur pendek dan tidak ada koneksi berumur panjang yang mungkin memiliki waktu diam yang lama, seperti menggunakan kubectl proxy atau kubectl port-forward, pertimbangkan untuk menggunakan nilai batas waktu rendah seperti 4 menit. Saat menggunakan TCP keepalive, cukup untuk mengaktifkannya di satu sisi koneksi. Misalnya, cukup untuk mengaktifkannya di sisi server hanya untuk mengatur ulang timer menganggur alur. Kedua belah pihak tidak perlu memulai keepalives TCP. Konsep serupa ada untuk lapisan aplikasi, termasuk konfigurasi database klien-server. Periksa sisi server untuk opsi apa yang ada untuk keepalives khusus aplikasi.

Penting

AKS memungkinkan Reset TCP saat diam secara default. Kami sarankan Anda menyimpan konfigurasi ini dan memanfaatkannya untuk perilaku aplikasi yang lebih dapat diprediksi pada skenario Anda.

Reset TCP hanya dikirim selama sambungan TCP dalam status TERSAMBUNG. Baca selengkapnya mengenai ini di sini.

Saat mengatur IdleTimeoutInMinutes ke nilai yang berbeda dari default 30 menit, pertimbangkan berapa lama beban kerja Anda memerlukan koneksi keluar. Pertimbangkan juga bahwa nilai batas waktu default untuk load balancer SKU Standar yang digunakan di luar AKS adalah 4 menit. Nilai IdleTimeoutInMinutes yang lebih akurat mencerminkan bahwa beban kerja AKS spesifik dapat membantu mengurangi kelelahan SNAT yang disebabkan oleh menyambungkan koneksi yang tidak lagi digunakan.

Peringatan

Mengubah nilai untuk AllocatedOutboundPorts dan IdleTimeoutInMinutes mungkin secara signifikan mengubah perilaku aturan keluar untuk load balancer Anda dan tidak boleh dilakukan dengan ringan. Periksa bagian Pemecahan Masalah SNAT dan tinjau aturan keluar Load Balancer dan koneksi keluar di Azure sebelum memperbarui nilai-nilai ini untuk sepenuhnya memahami dampak perubahan Anda.

Membatasi lalu lintas masuk ke rentang IP tertentu

Manifes berikut menggunakan loadBalancerSourceRanges untuk menentukan rentang IP baru untuk lalu lintas eksternal masuk.

apiVersion: v1
kind: Service
metadata:
  name: azure-vote-front
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: azure-vote-front
  loadBalancerSourceRanges:
  - MY_EXTERNAL_IP_RANGE

Contoh ini memperbarui aturan untuk mengizinkan lalu lintas eksternal masuk hanya dari rentang MY_EXTERNAL_IP_RANGE. Jika Anda mengganti MY_EXTERNAL_IP_RANGE dengan alamat IP subnet internal, lalu lintas dibatasi hanya untuk pengklusteran IP internal. Jika lalu lintas dibatasi untuk mengkluster IP internal, klien di luar kluster Kubernetes Anda tidak dapat mengakses load balancer.

Catatan

  • Arus lalu lintas eksternal masuk dari load balancer ke jaringan virtual untuk kluster AKS Anda. Jaringan virtual memiliki kelompok keamanan jaringan (NSG) yang memungkinkan semua lalu lintas masuk dari load balancer. NSG ini menggunakan tag layanan tipe LoadBalancer untuk memungkinkan adanya lalu lintas load balancer.
  • Pod CIDR harus ditambahkan ke loadBalancerSourceRanges jika ada Pod yang perlu mengakses IP LoadBalancer layanan untuk kluster dengan versi v1.25 atau lebih tinggi.

Pertahankan IP klien pada sambungan masuk

Secara default, layanan jenis LoadBalancer di Kubernetes dan di AKS tidak mempertahankan alamat IP klien pada koneksi ke pod. IP sumber pada paket yang dikirimkan ke pod menjadi IP privat simpul. Untuk mempertahankan alamat IP klien, Anda harus mengatur service.spec.externalTrafficPolicy ke local dalam definisi layanan. Manifes berikut menunjukkan contoh.

apiVersion: v1
kind: Service
metadata:
  name: azure-vote-front
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local
  ports:
  - port: 80
  selector:
    app: azure-vote-front

Kustomisasi melalui Anotasi Kubernetes

Anotasi berikut didukung untuk layanan Kubernetes dengan jenis LoadBalancer, dan hanya berlaku untuk alur MASUK .

Anotasi Nilai Deskripsi
service.beta.kubernetes.io/azure-load-balancer-internal true atau false Tentukan apakah load balancer harus internal. Jika tidak diatur, defaultnya ke publik.
service.beta.kubernetes.io/azure-load-balancer-internal-subnet Nama subnet Tentukan subnet mana yang harus terikat dengan load balancer internal. Jika tidak diatur, ini default ke subnet yang dikonfigurasi dalam file konfigurasi cloud.
service.beta.kubernetes.io/azure-dns-label-name Nama label DNS di IP Publik Tentukan nama label DNS untuk layanan publik. Jika diatur ke string kosong, entri DNS di IP Publik tidak digunakan.
service.beta.kubernetes.io/azure-shared-securityrule true atau false Tentukan mengekspos layanan melalui aturan keamanan Azure yang berpotensi dibagikan untuk meningkatkan paparan layanan, menggunakan Aturan Keamanan Azure Augmented di grup Keamanan Jaringan.
service.beta.kubernetes.io/azure-load-balancer-resource-group Nama grup sumber daya Tentukan grup sumber daya IP publik load balancer yang tidak berada dalam grup sumber daya yang sama dengan infrastruktur kluster (grup sumber daya node).
service.beta.kubernetes.io/azure-allowed-service-tags Daftar tag layanan yang diperbolehkan Tentukan daftar tag layanan yang diizinkan yang dipisahkan oleh koma.
service.beta.kubernetes.io/azure-load-balancer-tcp-idle-timeout Waktu diam TCP habis dalam menit Tentukan waktu dalam menit agar batas waktu diam koneksi TCP terjadi pada load balancer. Nilai default dan minimum adalah 4. Nilai maksimum adalah 30. Nilai harus berupa bilangan bulat.
service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset true atau false Tentukan apakah load balancer harus menonaktifkan reset TCP pada batas waktu diam.
service.beta.kubernetes.io/azure-load-balancer-ipv4 Alamat IPv4 Tentukan alamat IPv4 yang akan ditetapkan ke load balancer.
service.beta.kubernetes.io/azure-load-balancer-ipv6 Alamat IPv6 Tentukan alamat IPv6 yang akan ditetapkan ke load balancer.

Menyesuaikan pemeriksaan kesehatan load balancer

Anotasi Nilai Deskripsi
service.beta.kubernetes.io/azure-load-balancer-health-probe-interval Interval pemeriksaan kesehatan
service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe Jumlah minimum respons tidak sehat dari pemeriksaan kesehatan
service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path Jalur permintaan pemeriksaan kesehatan
service.beta.kubernetes.io/port_{port}_no_lb_rule benar/salah {port} adalah nomor port layanan. Ketika diatur ke true, tidak ada aturan lb atau aturan pemeriksaan kesehatan untuk port ini yang dihasilkan. Layanan pemeriksaan kesehatan tidak boleh terekspos ke internet publik (misalnya layanan pemeriksaan kesehatan istio/utusan)
service.beta.kubernetes.io/port_{port}_no_probe_rule benar/salah {port} adalah nomor port layanan. Ketika diatur ke true, tidak ada aturan pemeriksaan kesehatan untuk port ini yang dihasilkan.
service.beta.kubernetes.io/port_{port}_health-probe_protocol Protokol pemeriksaan kesehatan {port} adalah nomor port layanan. Protokol eksplisit untuk pemeriksaan kesehatan untuk port layanan {port}, menimpa port.appProtocol jika diatur.
service.beta.kubernetes.io/port_{port}_health-probe_port nomor port atau nama port dalam manifes layanan {port} adalah nomor port layanan. Port eksplisit untuk pemeriksaan kesehatan untuk port layanan {port}, menggantikan nilai default.
service.beta.kubernetes.io/port_{port}_health-probe_interval Interval pemeriksaan kesehatan {port} adalah nomor port layanan.
service.beta.kubernetes.io/port_{port}_health-probe_num-of-probe Jumlah minimum respons tidak sehat dari pemeriksaan kesehatan {port} adalah nomor port layanan.
service.beta.kubernetes.io/port_{port}_health-probe_request-path Jalur permintaan pemeriksaan kesehatan {port} adalah nomor port layanan.

Seperti yang didokumenkan di sini, Tcp, Http dan Https adalah tiga protokol yang didukung oleh layanan load balancer.

Saat ini, protokol default pemeriksaan kesehatan bervariasi di antara layanan dengan protokol transportasi, protokol aplikasi, anotasi, dan kebijakan lalu lintas eksternal yang berbeda.

  1. untuk layanan lokal, HTTP dan /healthz akan digunakan. Pemeriksaan kesehatan akan mengkueri NodeHealthPort daripada layanan backend aktual
  2. untuk layanan TCP kluster, TCP akan digunakan.
  3. untuk layanan UDP kluster, tidak ada pemeriksaan kesehatan.

Catatan

Untuk layanan lokal dengan integrasi PLS dan protokol proksi PLS diaktifkan, pemeriksaan kesehatan HTTP+/healthz default tidak berfungsi. Dengan demikian pemeriksaan kesehatan dapat disesuaikan dengan cara yang sama seperti layanan kluster untuk mendukung skenario ini.

Sejak v1.20, anotasi service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path layanan diperkenalkan untuk menentukan perilaku pemeriksaan kesehatan.

  • Untuk kluster <=1.23, spec.ports.appProtocol hanya akan digunakan sebagai protokol pemeriksaan ketika service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path juga diatur.
  • Untuk kluster >1.24, spec.ports.appProtocol akan digunakan sebagai protokol pemeriksaan dan / akan digunakan sebagai jalur permintaan pemeriksaan default (service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path dapat digunakan untuk mengubah ke jalur permintaan yang berbeda).

Perhatikan bahwa jalur permintaan akan diabaikan saat menggunakan TCP atau spec.ports.appProtocol kosong. Lebih spesifik:

loadbalancer sku externalTrafficPolicy spec.ports.Protocol spec.ports.AppProtocol service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path Protokol Pemeriksaan LB Jalur Permintaan Pemeriksaan LB
standar Lokal any any any http /healthz
standar klaster Udp any any null null
standar klaster tcp (diabaikan) tcp nihil
standar klaster tcp tcp (diabaikan) tcp nihil
standar klaster tcp http/https TCP(<=1.23) atau http/https(>=1.24) null(<=1.23) atau /(>=1.24)
standar klaster tcp http/https /custom-path http/https /custom-path
standar klaster tcp protokol yang tidak didukung /custom-path tcp nihil
dasar Lokal any any any http /healthz
dasar klaster tcp (diabaikan) tcp nihil
dasar klaster tcp tcp (diabaikan) tcp nihil
dasar klaster tcp http TCP(<=1.23) atau http/https(>=1.24) null(<=1.23) atau /(>=1.24)
dasar klaster tcp http /custom-path http /custom-path
dasar klaster tcp protokol yang tidak didukung /custom-path tcp nihil

Sejak v1.21, dua anotasi service.beta.kubernetes.io/azure-load-balancer-health-probe-interval layanan dan load-balancer-health-probe-num-of-probe diperkenalkan, yang menyesuaikan konfigurasi pemeriksaan kesehatan. Jika service.beta.kubernetes.io/azure-load-balancer-health-probe-interval tidak diatur, Nilai default 5 diterapkan. Jika load-balancer-health-probe-num-of-probe tidak diatur, Nilai default 2 diterapkan. Dan total pemeriksaan harus kurang dari 120 detik.

Pemeriksaan kesehatan Load Balancer kustom untuk port

Port yang berbeda dalam layanan dapat memerlukan konfigurasi pemeriksaan kesehatan yang berbeda. Ini bisa disebabkan oleh desain layanan (seperti titik akhir kesehatan tunggal yang mengontrol beberapa port), atau fitur Kubernetes seperti MixedProtocolLBService.

Anotasi berikut dapat digunakan untuk menyesuaikan konfigurasi pemeriksaan per port layanan.

anotasi spesifik port anotasi probe global Penggunaan
service.beta.kubernetes.io/port_{port}_no_lb_rule N/A (tidak ada yang setara secara global) jika diatur true, tidak ada aturan lb dan aturan pemeriksaan yang akan dihasilkan
service.beta.kubernetes.io/port_{port}_no_probe_rule N/A (tidak ada yang setara secara global) jika diatur true, tidak ada aturan pemeriksaan yang akan dihasilkan
service.beta.kubernetes.io/port_{port}_health-probe_protocol N/A (tidak ada yang setara secara global) Atur protokol pemeriksaan kesehatan untuk port layanan ini (misalnya Http, Https, Tcp)
service.beta.kubernetes.io/port_{port}_health-probe_port N/A (tidak ada yang setara secara global) Mengatur port pemeriksaan kesehatan untuk port layanan ini (misalnya 15021)
service.beta.kubernetes.io/port_{port}jalur _health-probe_request service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path Untuk Http atau Https, atur jalur permintaan pemeriksaan kesehatan. Default ke /
service.beta.kubernetes.io/port_{port}_health-probe_num-of-probe service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe Jumlah kegagalan pemeriksaan berturut-turut sebelum port dianggap tidak sehat
service.beta.kubernetes.io/port_{port}_health-probe_interval service.beta.kubernetes.io/azure-load-balancer-health-probe-interval Jumlah waktu antara upaya pemeriksaan

Untuk manifes berikut, aturan pemeriksaan untuk httpsserver port berbeda dari yang untuk httpserver karena anotasi untuk httpsserver port ditentukan.

apiVersion: v1
kind: Service
metadata:
  name: appservice
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe: "5"
    service.beta.kubernetes.io/port_443_health-probe_num-of-probe: "4"
spec:
  type: LoadBalancer
  selector:
    app: server
  ports:
    - name: httpserver
      protocol: TCP
      port: 80
      targetPort: 30102
    - name: httpsserver
      protocol: TCP
      appProtocol: HTTPS
      port: 443
      targetPort: 30104

Dalam manifes ini, port https menggunakan port node yang berbeda, pemeriksaan kesiapan HTTP di port 10256 pada /healthz(titik akhir healthz kube-proxy).

apiVersion: v1
kind: Service
metadata:
  name: istio
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
    service.beta.kubernetes.io/port_443_health-probe_protocol: "http"
    service.beta.kubernetes.io/port_443_health-probe_port: "10256"
    service.beta.kubernetes.io/port_443_health-probe_request-path: "/healthz"
spec:
  ports:
    - name: https
      protocol: TCP
      port: 443
      targetPort: 8443
      nodePort: 30104
      appProtocol: https
  selector:
    app: istio-ingressgateway
    gateway: istio-ingressgateway
    istio: ingressgateway
  type: LoadBalancer
  sessionAffinity: None
  externalTrafficPolicy: Local
  ipFamilies:
    - IPv4
  ipFamilyPolicy: SingleStack
  allocateLoadBalancerNodePorts: true
  internalTrafficPolicy: Cluster

Dalam manifes ini, port https menggunakan titik akhir pemeriksaan kesehatan yang berbeda, pemeriksaan kesiapan HTTP di port 30000 pada /healthz/ready.

apiVersion: v1
kind: Service
metadata:
  name: istio
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
    service.beta.kubernetes.io/port_443_health-probe_protocol: "http"
    service.beta.kubernetes.io/port_443_health-probe_port: "30000"
    service.beta.kubernetes.io/port_443_health-probe_request-path: "/healthz/ready"
spec:
  ports:
    - name: https
      protocol: TCP
      port: 443
      targetPort: 8443
      appProtocol: https
  selector:
    app: istio-ingressgateway
    gateway: istio-ingressgateway
    istio: ingressgateway
  type: LoadBalancer
  sessionAffinity: None
  externalTrafficPolicy: Local
  ipFamilies:
    - IPv4
  ipFamilyPolicy: SingleStack
  allocateLoadBalancerNodePorts: true
  internalTrafficPolicy: Cluster

Pemecahan Masalah untuk SNAT

Jika Anda tahu bahwa Anda memulai banyak koneksi TCP atau UDP keluar ke alamat IP dan port tujuan yang sama, dan Anda mengamati koneksi keluar atau dukungan yang gagal memberi tahu Anda bahwa Anda menghabiskan port SNAT (port ephemeral yang telah dialokasikan sebelumnya yang digunakan oleh PAT), Anda memiliki beberapa opsi mitigasi umum. Tinjau opsi ini dan putuskan apa yang terbaik untuk skenario Anda. Ada kemungkinan bahwa satu atau beberapa dapat membantu mengelola skenario Anda. Untuk informasi terperinci, tinjau panduan pemecahan masalah koneksi keluar.

Akar penyebab kelelahan SNAT sering menjadi anti-pola tentang bagaimana konektivitas keluar dibuat, dikelola, atau dikonfigurasi timer berubah dari nilai defaultnya. Tinjau bagian ini dengan cermat.

Langkah-langkah

  1. Periksa apakah koneksi Anda tetap diam untuk waktu yang lama dan gunakan batas waktu diam default untuk melepaskan port tersebut. Jika demikian, batas waktu default 30 menit mungkin perlu dikurangi untuk skenario Anda.
  2. Selidiki bagaimana aplikasi Anda membuat konektivitas keluar (misalnya, tinjauan kode atau pengambilan paket).
  3. Tentukan apakah aktivitas ini adalah perilaku yang terprediksi atau apakah aplikasinya berperilaku tidak normal. Gunakan metrik dan log dalam Azure Monitor untuk membuktikan temuan Anda. Misalnya, gunakan kategori "Gagal" untuk metrik koneksi SNAT.
  4. Evaluasi apakah sudah mengikuti pola yang sesuai.
  5. Evaluasi apakah kelelahan port SNAT harus dimitigasi dengan lebih banyak alamat IP keluar + port keluar yang lebih dialokasikan.

Pola desain

Manfaatkan penggunaan kembali koneksi dan pengumpulan koneksi jika memungkinkan. Pola-pola ini membantu Anda menghindari masalah kelelahan sumber daya dan mengakibatkan perilaku yang dapat diprediksi. Primitif untuk pola tersebut dapat ditemukan di banyak kerangka kerja dan pustaka pengembangan.

  • Permintaan atomik (satu permintaan per koneksi) umumnya bukan pilihan desain yang baik. Anti-pola tersebut membatasi skala, mengurangi performa, dan mengurangi keandalan. Sebagai gantinya, gunakan kembali koneksi HTTP/S untuk mengurangi jumlah koneksi dan port SNAT terkait. Skala aplikasi meningkat dan performa meningkat karena berkurangnya biaya jabat tangan, overhead, dan operasi kriptografi saat menggunakan TLS.
  • Jika Anda menggunakan DNS kluster/kustom, atau server hulu kustom di coreDNS, perlu diingat bahwa DNS dapat memperkenalkan banyak alur individual dalam volume saat klien tidak menyimpan cache hasil pemecah masalah DNS. Pastikan untuk menyesuaikan coreDNS terlebih dahulu alih-alih menggunakan server DNS kustom dan untuk menentukan nilai penembolokan yang baik.
  • Alur UDP (misalnya, pencarian DNS) mengalokasikan port SNAT selama batas waktu diam. Semakin lama batas waktu diam, semakin tinggi tekanan pada port SNAT. Gunakan batas waktu diam singkat (misalnya, 4 menit).
  • Gunakan kumpulan koneksi untuk membentuk volume koneksi Anda.
  • Jangan pernah diam-diam meninggalkan alur TCP dan mengandalkan timer TCP untuk membersihkan alur. Jika Anda tidak membiarkan TCP secara eksplisit menutup koneksi, status tetap dialokasikan pada sistem perantara dan titik akhir, dan itu membuat port SNAT tidak tersedia untuk koneksi lain. Pola ini dapat memicu kegagalan aplikasi dan kelelahan SNAT.
  • Jangan ubah nilai timer terkait TCP tingkat OS tanpa pengetahuan ahli atas dampaknya. Meskipun tumpukan TCP pulih, performa aplikasi Anda dapat terpengaruh secara negatif ketika titik akhir koneksi memiliki ekspektasi yang tidak cocok. Keinginan untuk mengganti timer biasanya merupakan tanda masalah desain yang mendasar. Tinjau rekomendasi berikut.

Berpindah dari load balancer SKU Dasar ke SKU Standar

Jika Anda memiliki kluster yang ada dengan load balancer SKU Dasar , ada perbedaan perilaku penting yang perlu diperhatikan saat bermigrasi ke load balancer SKU Standar .

Misalnya, membuat penyebaran biru/hijau untuk memigrasikan kluster adalah praktik umum yang diberikan load-balancer-sku jenis kluster dan hanya dapat didefinisikan pada waktu pembuatan kluster. Namun, load balancer SKU Dasar menggunakan alamat IP SKU Dasar , yang tidak kompatibel dengan load balancer SKU Standar . Load balancer SKU standar memerlukan alamat IP SKU Standar . Saat memigrasikan kluster untuk meningkatkan SKU load balancer, alamat IP baru dengan SKU alamat IP yang kompatibel diperlukan.

Untuk pertimbangan lebih lanjut tentang cara memigrasikan kluster, kunjungi dokumentasi kami tentang pertimbangan migrasi.

Batasan

Batasan berikut berlaku saat Anda membuat dan mengelola kluster AKS yang mendukung load balancer dengan SKU Standar:

  • Setidaknya satu awalan IP atau IP publik diperlukan untuk memungkinkan lalu lintas keluar dari kluster AKS. Awalan IP atau IP publik juga diperlukan untuk menjaga konektivitas antara sarana kontrol dan node agen dan untuk mempertahankan kompatibilitas dengan versi AKS sebelumnya. Anda memiliki opsi berikut untuk menentukan IP publik atau awalan IP dengan load balancer SKU Standar :
    • Berikan IP publik Anda sendiri.
    • Berikan awalan IP publik Anda sendiri.
    • Tentukan angka hingga 100 untuk memungkinkan kluster AKS membuat IP publik SKU Standar sebanyak itu dalam grup sumber daya yang sama dengan kluster AKS. Grup sumber daya ini biasanya dinamai dengan MC_ di awal. AKS menetapkan IP publik ke load balancer SKU Standar. Secara default, satu IP publik secara otomatis dibuat dalam grup sumber daya yang sama dengan kluster AKS jika tidak ada IP publik, awalan IP publik, atau jumlah IP yang ditentukan. Anda juga harus mengizinkan alamat publik dan menghindari pembuatan kebijakan Azure apa pun yang melarang pembuatan IP.
  • IP publik yang dibuat oleh AKS tidak dapat digunakan kembali sebagai alamat IP publik bawa sendiri kustom. Pengguna harus membuat dan mengelola semua alamat IP kustom.
  • Menentukan SKU load balancer hanya dapat dilakukan saat Anda membuat kluster AKS. Anda tidak dapat mengubah SKU penyeimbang beban setelah kluster AKS dibuat.
  • Anda hanya dapat menggunakan satu jenis SKU load balancer (Dasar atau Standar) dalam satu kluster.
  • Load balancer SKU standar hanya mendukung alamat IP SKU Standar .

Langkah berikutnya

Pelajari lebih lanjut tentang layanan Kubernetes di dokumen layanan Kubernetes.

Untuk mempelajari selengkapnya tentang menggunakan load balancer internal untuk lalu lintas masuk, lihat dokumentasi load balancer internal AKS.