Aplikasi rute dan HTTP Lalu lintas dengan Application Load Balancers - Amazon EKS
(Opsional) Deploy aplikasi sampel

Bantu tingkatkan halaman ini

Ingin berkontribusi pada panduan pengguna ini? Gulir ke bagian bawah halaman ini dan pilih Edit halaman ini GitHub. Kontribusi Anda akan membantu membuat panduan pengguna kami lebih baik untuk semua orang.

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Aplikasi rute dan HTTP Lalu lintas dengan Application Load Balancers

Saat Anda membuat Kubernetes ingress, AWS Application Load Balancer (ALB) disediakan yang memuat saldo lalu lintas aplikasi. Untuk mempelajari lebih lanjut, lihat Apa itu Application Load Balancer? dalam Panduan Pengguna Application Load Balancers dan Ingress di Kubernetes dokumentasi. ALBsdapat digunakan dengan Pods yang digunakan ke node atau ke AWS Fargate. Anda dapat menyebarkan subnet ALB ke publik atau pribadi.

Lalu lintas aplikasi seimbang L7 pada OSI model. Untuk memuat lalu lintas jaringan keseimbangan diL4, Anda menerapkan Kubernetes servicedari LoadBalancer jenis. Jenis ini menyediakan AWS Network Load Balancer. Untuk informasi selengkapnya, lihat Rute TCP and UDP Lalu lintas dengan Network Load Balancers. Untuk mempelajari selengkapnya tentang perbedaan antara kedua jenis penyeimbangan beban, lihat fitur-fitur Elastic Load Balancing pada situs web AWS .

Prasyarat

Sebelum Anda dapat menyeimbangkan beban lalu lintas aplikasi ke suatu aplikasi, Anda harus memenuhi persyaratan berikut.

  • Memiliki klaster yang ada. Jika Anda tidak memiliki klaster yang ada, lihat Memulai dengan Amazon EKS. Jika Anda perlu memperbarui versi klaster yang ada, lihat Perbarui klaster yang ada ke versi Kubernetes baru.

  • Memiliki AWS Load Balancer Controller diterapkan di cluster Anda. Untuk informasi selengkapnya, lihat Rute lalu lintas internet dengan AWS Load Balancer Controller. Kami merekomendasikan versi 2.7.2 atau yang lebih baru.

  • Setidaknya dua subnet harus berada di Availability Zone yang berbeda. Bagian AWS Load Balancer Controller memilih satu subnet dari setiap Availability Zone. Ketika beberapa subnet yang diberi tag ditemukan di Availability Zone, controller memilih subnet yang subnetnya ID didahulukan secara leksikografis. Setiap subnet harus memiliki setidaknya delapan alamat IP yang tersedia.

    Jika Anda menggunakan beberapa grup keamanan yang dilampirkan ke node pekerja, tepat satu grup keamanan harus diberi tag sebagai berikut. Ganti my-cluster dengan nama klaster Anda.

    • Kunci – kubernetes.io/cluster/my-cluster

    • Nilai – shared atau owned

  • Jika Anda menggunakan AWS Load Balancer Controller versi 2.1.1 atau sebelumnya, subnet harus ditandai dalam format berikut. Jika Anda menggunakan versi 2.1.2 atau yang lebih baru, penandaan bersifat opsional. Namun, kami menyarankan Anda menandai subnet jika salah satu dari yang berikut ini terjadi. Anda memiliki beberapa cluster yang berjalan dalam hal yang samaVPC, atau memiliki beberapa AWS layanan yang berbagi subnet dalam file. VPC Atau, Anda ingin lebih banyak kontrol di mana penyeimbang beban disediakan untuk setiap cluster. Ganti my-cluster dengan nama klaster Anda.

    • Kunci – kubernetes.io/cluster/my-cluster

    • Nilai – shared atau owned

  • Subnet publik dan pribadi Anda harus memenuhi persyaratan berikut. Ini kecuali Anda secara eksplisit menentukan subnet IDs sebagai anotasi pada layanan atau objek ingress. Misalnya Anda menyediakan penyeimbang beban dengan secara eksplisit menentukan subnet IDs sebagai anotasi pada objek layanan atau ingress. Dalam situasi ini, Kubernetes dan pengontrol penyeimbang AWS beban menggunakan subnet tersebut secara langsung untuk membuat penyeimbang beban dan tag berikut tidak diperlukan.

    • Subnet pribadi — Harus ditandai dalam format berikut. Ini agar Kubernetes dan pengontrol penyeimbang AWS beban tahu bahwa subnet dapat digunakan untuk penyeimbang beban internal. Jika Anda menggunakan eksctl atau EKS AWS CloudFormation templat Amazon untuk membuat VPC setelah 26 Maret 2020, subnet diberi tag dengan tepat saat dibuat. Untuk informasi selengkapnya tentang EKS AWS CloudFormation VPC template Amazon, lihatBuat Amazon VPC untuk EKS klaster Amazon Anda.

      • Kunci – kubernetes.io/role/internal-elb

      • Nilai – 1

    • Subnet publik — Harus ditandai dalam format berikut. Ini agar Kubernetes tahu hanya menggunakan subnet yang ditentukan untuk penyeimbang beban eksternal. Dengan cara ini, Kubernetes tidak memilih subnet publik di setiap Availability Zone (secara leksikografis berdasarkan ID subnet mereka). Jika Anda menggunakan eksctl atau EKS AWS CloudFormation templat Amazon untuk membuat VPC setelah 26 Maret 2020, subnet diberi tag dengan tepat saat dibuat. Untuk informasi selengkapnya tentang EKS AWS CloudFormation VPC template Amazon, lihatBuat Amazon VPC untuk EKS klaster Amazon Anda.

      • Kunci – kubernetes.io/role/elb

      • Nilai – 1

    Jika tag peran subnet tidak ditambahkan secara eksplisit, maka Kubernetes service controller memeriksa tabel rute VPC subnet cluster Anda. Ini untuk menentukan apakah subnet bersifat pribadi atau publik. Kami menyarankan Anda untuk tidak bergantung pada perilaku ini. Sebaliknya, tambahkan tag peran pribadi atau publik secara eksplisit. Bagian AWS Load Balancer Controller tidak memeriksa tabel rute. Ini juga membutuhkan tag pribadi dan publik untuk hadir untuk penemuan auto yang sukses.

Pertimbangan

  • AWS Load Balancer Controller menciptakan ALBs dan AWS sumber daya pendukung yang diperlukan kapan pun Kubernetes sumber daya ingress dibuat di cluster dengan kubernetes.io/ingress.class: alb anotasi. Sumber daya ingress mengonfigurasi rute ALB ke HTTP atau HTTPS lalu lintas ke yang berbeda Pods di dalam cluster. Untuk memastikan bahwa objek masuk Anda menggunakan AWS Load Balancer Controller, tambahkan anotasi berikut ke Kubernetes spesifikasi masuknya. Untuk informasi selengkapnya, lihat spesifikasi Ingress di GitHub.

    annotations:
    kubernetes.io/ingress.class: alb
    catatan

    Jika Anda menyeimbangkan beban ke IPv6 Pods, tambahkan anotasi berikut ke spesifikasi ingress Anda. Anda hanya dapat memuat saldo IPv6 ke target IP, bukan target instance. Tanpa anotasi ini, load balancing selesai. IPv4

    alb.ingress.kubernetes.io/ip-address-type: dualstack

  • Bagian AWS Load Balancer Controller mendukung mode lalu lintas berikut:

    • Instance — Mendaftarkan node dalam cluster Anda sebagai target untuk. ALB Lalu lintas yang mencapai ALB dialihkan ke NodePort layanan Anda dan kemudian diproksi ke layanan Anda Pods. Ini adalah mode lalu lintas default. Anda juga dapat secara eksplisit menentukannya dengan anotasi alb.ingress.kubernetes.io/target-type: instance.

      catatan

      Klaster Kubernetes layanan harus menentukan NodePort atau LoadBalancer "jenis untuk menggunakan mode lalu lintas ini.

    • IP - Register Pods sebagai target untukALB. Lalu lintas ALB yang mencapai langsung diarahkan ke Pods untuk layanan Anda. Anda harus menentukan anotasi alb.ingress.kubernetes.io/target-type: ip untuk menggunakan mode lalu lintas ini. Jenis target IP diperlukan saat target Pods Mereka berjalan di Fargate.

  • Untuk tag yang ALBs dibuat oleh controller, tambahkan anotasi berikut ke controller:alb.ingress.kubernetes.io/tags. Untuk daftar semua anotasi yang tersedia yang didukung oleh AWS Load Balancer Controller, lihat anotasi Ingress di GitHub.

  • Memutakhirkan atau menurunkan versi ALB pengontrol dapat memperkenalkan perubahan yang melanggar untuk fitur yang mengandalkannya. Untuk informasi selengkapnya tentang perubahan yang melanggar yang diperkenalkan di setiap rilis, lihat catatan rilis ALB pengontrol di GitHub.

Untuk berbagi penyeimbang beban aplikasi di beberapa sumber daya layanan menggunakan IngressGroups

Untuk menggabungkan ingress ke grup, tambahkan anotasi berikut ke Kubernetes spesifikasi sumber daya masuk. 

alb.ingress.kubernetes.io/group.name: my-group

Nama grup harus:

  • Panjangnya 63 atau lebih sedikit karakter.

  • Terdiri dari huruf kecil, angka-, dan .

  • Dimulai dan diakhiri dengan huruf atau angka.

Pengontrol secara otomatis menggabungkan aturan masuk untuk semua ingress dalam grup ingress yang sama. Ini mendukung mereka dengan satuALB. Sebagian besar anotasi yang didefinisikan pada ingress hanya berlaku untuk jalur yang ditentukan oleh ingress tersebut. Secara default, sumber daya ingress bukan milik grup ingress mana pun.

Awas

Potensi risiko keamanan: Tentukan grup masuk untuk masuknya hanya jika semua Kubernetes pengguna yang memiliki RBAC izin untuk membuat atau memodifikasi sumber daya masuk berada dalam batas kepercayaan yang sama. Jika Anda menambahkan anotasi dengan nama grup, lainnya Kubernetes pengguna dapat membuat atau memodifikasi ingresses mereka untuk menjadi milik grup ingress yang sama. Melakukan hal tersebut dapat menyebabkan perilaku yang tidak diinginkan, seperti menimpa aturan yang ada dengan aturan prioritas yang lebih tinggi.

Anda dapat menambahkan nomor pesanan sumber daya masuk Anda.

alb.ingress.kubernetes.io/group.order: '10'

Jumlahnya bisa 1-1000. Angka terendah untuk semua ingress dalam kelompok ingress yang sama dievaluasi terlebih dahulu. Semua masuknya tanpa anotasi ini dievaluasi dengan nilai nol. Aturan duplikat angka yang lebih tinggi dapat menimpa aturan dengan angka yang lebih rendah. Secara default, urutan aturan antara ingress dalam grup ingress yang sama ditentukan namespace dan nama berbasis leksikografis.

penting

Pastikan bahwa setiap ingress dalam grup ingress yang sama memiliki nomor prioritas yang unik. Anda tidak dapat memiliki nomor urutan duplikat di seluruh ingresses.

(Opsional) Deploy aplikasi sampel

Prasyarat
Untuk menggunakan aplikasi sampel

Anda dapat menjalankan aplikasi sampel pada cluster yang memiliki EC2 node Amazon, Fargate Pods, atau keduanya.

  1. Jika Anda tidak menerapkan ke Fargate, lewati langkah ini. Jika Anda men-deploy ke Fargate, buat profil Fargate. Anda dapat membuat profil dengan menjalankan perintah berikut atau AWS Management Consolemenggunakan nilai yang sama untuk name dan namespace yang ada di perintah. Ganti example values dengan milik Anda sendiri.

    eksctl create fargateprofile \
    --cluster my-cluster \
    --region region-code \
    --name alb-sample-app \
    --namespace game-2048

  2. Menyebarkan game 2048 sebagai contoh aplikasi untuk memverifikasi bahwa AWS Load Balancer Controller menciptakan AWS ALB sebagai hasil dari objek ingress. Selesaikan langkah-langkah untuk jenis subnet yang Anda gunakan.

    1. Jika Anda menerapkan ke Pods di cluster yang Anda buat bersama IPv6 keluarga, lompat ke langkah berikutnya.

      • Publik

        kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.7.2/docs/examples/2048/2048_full.yaml

      • Pribadi

        1. Unduh manifes.

          curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.7.2/docs/examples/2048/2048_full.yaml

        2. Edit file dan temukan baris yang bertuliskanalb.ingress.kubernetes.io/scheme: internet-facing.

        3. Ubah internet-facing ke internal dan simpan file.

        4. Menerapkan manifes ke klaster Anda.

          kubectl apply -f 2048_full.yaml

    2. Jika Anda menerapkan ke Pods di cluster yang Anda buat bersama IPv6keluarga, selesaikan langkah-langkah berikut.

      1. Unduh manifes.

        curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.7.2/docs/examples/2048/2048_full.yaml

      2. Buka file di editor dan tambahkan baris berikut ke anotasi dalam spesifikasi ingress.

        alb.ingress.kubernetes.io/ip-address-type: dualstack

      3. Jika Anda menyeimbangkan beban ke internal Pods, ketimbang menghadapi internet Pods, ubah baris yang mengatakan alb.ingress.kubernetes.io/scheme: internet-facing alb.ingress.kubernetes.io/scheme: internal

      4. Simpan file tersebut.

      5. Menerapkan manifes ke klaster Anda.

        kubectl apply -f 2048_full.yaml

  3. Setelah beberapa menit, verifikasi bahwa sumber daya ingress dibuat dengan perintah berikut.

    kubectl get ingress/ingress-2048 -n game-2048

    Contoh output adalah sebagai berikut.

    NAME           CLASS    HOSTS   ADDRESS                                                                   PORTS   AGE
ingress-2048   <none>   *       k8s-game2048-ingress2-xxxxxxxxxx-yyyyyyyyyy.region-code.elb.amazonaws.com   80      2m32s
    catatan

    Jika Anda membuat penyeimbang beban di subnet pribadi, nilai ADDRESS di bawah output sebelumnya diawali dengan. internal-

    Jika ingress Anda tidak berhasil dibuat setelah beberapa menit, jalankan perintah berikut untuk melihat AWS Load Balancer Controller log. Log ini mungkin berisi pesan kesalahan yang dapat Anda gunakan untuk mendiagnosis masalah dengan penerapan Anda.

    kubectl logs -f -n kube-system -l app.kubernetes.io/instance=aws-load-balancer-controller

  4. Jika Anda di-deploy ke subnet publik, buka browser dan navigasikan ke ADDRESS URL dari output perintah sebelumnya untuk melihat contoh aplikasi. Jika Anda tidak melihat apa pun, segarkan browser Anda dan coba lagi. Jika Anda menerapkan ke subnet pribadi, maka Anda harus melihat halaman dari perangkat di dalam AndaVPC, seperti host bastion. Untuk informasi selengkapnya, silakan lihat Linux Tuan Rumah Bastion di AWS.

    Aplikasi sampel 2048

  5. Ketika Anda selesai bereksperimen dengan aplikasi sampel Anda, hapus dengan menjalankan salah satu perintah berikut.

    • Jika Anda menerapkan manifes, daripada menerapkan salinan yang Anda unduh, gunakan perintah berikut.

      kubectl delete -f https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.7.2/docs/examples/2048/2048_full.yaml

    • Jika Anda mengunduh dan mengedit manifes, gunakan perintah berikut.

      kubectl delete -f 2048_full.yaml