Apa saja praktik terbaik untuk NGINX Ingress controller? - Container Service for Kubernetes

Topik ini menjelaskan praktik terbaik untuk mengonfigurasi NGINX Ingress controller guna mencapai kinerja optimal dalam berbagai skenario.

Dalam topik ini

Tingkatkan kinerja dan stabilitas NGINX Ingress controller
Tingkatkan observabilitas NGINX Ingress controller
Fitur lanjutan NGINX Ingress controller
Referensi

Kinerja dan stabilitas NGINX Ingress controller

Replika dan batas resource yang sesuai

Secara default, NGINX Ingress controller yang diinstal saat pembuatan kluster atau melalui halaman Add-ons memiliki dua replika. Anda dapat menyesuaikan jumlah ini sesuai kebutuhan bisnis. Pastikan Pod NGINX Ingress controller didistribusikan di node yang berbeda untuk mencegah konflik sumber daya dan titik kegagalan tunggal. Anda juga dapat menetapkan node eksklusif untuk menjamin kinerja dan stabilitas. Untuk informasi selengkapnya, lihat Gunakan node eksklusif untuk meningkatkan kinerja dan stabilitas NGINX Ingress. Untuk menghindari gangguan lalu lintas akibat event kehabisan memori (OOM), jangan tetapkan batas resource untuk NGINX Ingress controller. Jika Anda harus menetapkan batas, atur batas CPU minimal 1.000 millicores dan batas memori minimal 2 GiB.

Gunakan node eksklusif

Untuk persyaratan stabilitas tinggi, tetapkan node eksklusif untuk controller Ingress guna mencegah konflik sumber daya. Untuk informasi selengkapnya, lihat Deploy NGINX Ingress controller dengan ketersediaan tinggi.
Untuk skenario beban tinggi, Anda juga dapat mengonfigurasi controller Ingress agar mendukung aplikasi dengan lalu lintas tinggi. Untuk informasi selengkapnya, lihat Konfigurasikan NGINX Ingress controller untuk skenario beban tinggi.

Optimalkan kinerja NGINX Ingress

Tuning kinerja NGINX Ingress controller mencakup dua area utama: tuning parameter sistem dan tuning parameter NGINX.

Tuning parameter sistem: Sistem operasi Alibaba Cloud telah menyertakan optimasi default untuk parameter umum. Parameter sistem lain yang mungkin perlu Anda sesuaikan termasuk backlog sistem maksimum dan rentang port yang tersedia. Tuning parameter sistem membantu memastikan NGINX dapat menangani konkurensi tinggi serta mencegah kegagalan koneksi ke backend akibat kehabisan port.
Tuning parameter NGINX:
- Menyesuaikan jumlah koneksi maksimum per proses worker memastikan NGINX Ingress controller dapat menangani konkurensi tinggi.
- Tingkatkan timeout koneksi: Berbeda dari perilaku default NGINX, NGINX Ingress controller menggunakan koneksi keep-alive untuk mengirimkan permintaan ke Pod backend. Oleh karena itu, tingkatkan timeout koneksi agar satu koneksi dapat menangani lebih banyak permintaan, sehingga mengurangi overhead pembuatan koneksi baru.
- Tetapkan timeout keep-alive: Atur timeout keep-alive untuk layanan backend agar sama dengan atau lebih besar dari timeout koneksi NGINX Ingress controller, yang secara default bernilai 900 detik di kluster ACK.

Komponen NGINX Ingress mencakup parameter tuning default yang memberikan kinerja optimal di sebagian besar skenario. Jika Anda memiliki kebutuhan khusus, Anda dapat lebih lanjut mengoptimalkan parameter sistem dan NGINX dengan menggunakan bidang terkait dalam ConfigMap. Untuk informasi selengkapnya tentang ConfigMap, lihat ConfigMaps.

Auto scaling dengan HPA

Pada sebagian besar kasus, NGINX Ingress controller dapat menangani lonjakan lalu lintas mendadak. Jika kapasitas default tidak mencukupi untuk skenario beban tinggi Anda, konfigurasikan Horizontal Pod Autoscaler (HPA) untuk melakukan auto scaling pada NGINX Ingress controller. Untuk informasi selengkapnya, lihat Gunakan Horizontal Pod Autoscaler (HPA).

Penting

Event scaling Pod dapat mengganggu koneksi yang sedang berlangsung secara sementara. Konfigurasikan fitur ini dengan hati-hati.

Berikut adalah contoh konfigurasi YAML:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-ingress-controller-hpa
  namespace: kube-system
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-ingress-controller
  minReplicas: 2
  maxReplicas: 5
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

Konfigurasikan preStop hook

Saat pembaruan bergulir (rolling update) layanan backend, NGINX Ingress controller menghapus titik akhir Pod yang sedang dihentikan sambil tetap mempertahankan koneksi untuk permintaan yang sedang berlangsung. Jika Pod layanan backend langsung keluar setelah menerima sinyal terminasi, permintaan yang sedang berlangsung dapat gagal. Karena masalah waktu, sebagian lalu lintas baru mungkin masih diarahkan ke Pod yang telah dihentikan, sehingga menyebabkan kehilangan lalu lintas.

Untuk mencegah kehilangan lalu lintas selama pembaruan bergulir, konfigurasikan preStop hook pada Pod layanan backend Anda. Hook ini memungkinkan Pod untuk terus memproses permintaan yang sedang berlangsung setelah titik akhirnya dihapus, sehingga mencegah gangguan layanan.

Tambahkan kode berikut ke konfigurasi kontainer dalam templat Pod:

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
      - name: app
        lifecycle:
          # Konfigurasikan preStop hook untuk menunggu selama 30 detik sebelum keluar.
          # Perintah sleep harus tersedia di dalam kontainer.
          preStop:
            exec:
              command:
              - sleep
              - "30"

Observabilitas NGINX Ingress controller

Log Service dan Managed Service for Prometheus

NGINX Ingress controller menyediakan dasbor pemantauan berbasis log Log Service (SLS) dan Prometheus untuk membantu Anda lebih memahami lalu lintas layanan Anda.

Log Service (SLS) log:
- Jika Anda memilih Enable Log Service dan Create Ingress Dashboard saat membuat kluster, Anda dapat membuka Konsol ACK, pilih Network > Ingresses, lalu lihat dasbor berbasis Log Service pada halaman NGINX Ingress Overview. Anda juga dapat membuka Operations > Log Center untuk melihat log yang dihasilkan oleh NGINX Ingress controller. Untuk informasi selengkapnya, lihat Kumpulkan dan analisis log akses NGINX Ingress.
- Jika Anda tidak mengaktifkan opsi ini saat pembuatan kluster, Anda dapat mengonfigurasi komponen dan aturan pengumpulan log secara manual. Untuk informasi selengkapnya, lihat Kumpulkan dan analisis log akses NGINX Ingress. Untuk informasi selengkapnya tentang pemantauan, lihat Pemantauan dasbor Ingress.
Pemantauan Managed Service for Prometheus: Anda dapat memilih untuk menginstal pemantauan Managed Service for Prometheus saat membuat kluster. Atau, setelah kluster dibuat, Anda dapat menginstal atau melihatnya dengan memilih Operations > Prometheus Monitoring. Untuk informasi selengkapnya, lihat Hubungkan dan konfigurasikan Managed Service for Prometheus.

Catatan
Saat menggunakan Managed Service for Prometheus, tambahkan bidang host ke resource Ingress dalam kluster. Jika tidak, beberapa metrik untuk Ingress akan hilang secara default. Alternatifnya, tambahkan argumen startup --metrics-per-host=false ke controller dalam Deployment NGINX Ingress controller.

Fitur lanjutan NGINX Ingress controller

Gunakan beberapa NGINX Ingress controller

Anda mungkin perlu menerapkan beberapa NGINX Ingress controller dalam satu kluster, misalnya untuk mengisolasi lalu lintas internal dan eksternal. Untuk informasi selengkapnya, lihat Deploy beberapa controller Ingress untuk isolasi lalu lintas.

Akses intra-kluster

Dalam sebuah kluster, lalu lintas ke titik akhir eksternal Layanan LoadBalancer (Alamat IP publik NGINX Ingress controller) biasanya dicegat dan diteruskan oleh iptables atau IPVS. Ketika externalTrafficPolicy diatur ke Local dan tidak ada Pod NGINX Ingress yang berjalan di suatu node, terjadi masalah konektivitas jaringan. Secara default, NGINX Ingress controller di kluster ACK menggunakan Layanan LoadBalancer dalam mode Local. Akibatnya, Anda mungkin mengalami masalah konektivitas saat mengakses alamat Classic Load Balancer (CLB) terkait dari dalam kluster. Oleh karena itu, untuk akses intra-kluster, gunakan ClusterIP Layanan atau nama domain internal (nginx-ingress-lb.kube-system). Hindari juga skenario di mana NGINX Ingress controller mencoba mengakses dirinya sendiri, yang dapat menyebabkan kegagalan jaringan akibat masalah hairpinning. Untuk informasi selengkapnya tentang cara mengatasi masalah ini, lihat Tidak dapat mengakses instans SLB Layanan LoadBalancer dari dalam kluster Kubernetes.

Gunakan WAF

Untuk memblokir permintaan serangan, Anda dapat mengaktifkan Web Application Firewall (WAF) untuk Classic Load Balancer (CLB) yang digunakan oleh NGINX Ingress controller kluster Anda. Saat Anda mengaktifkan WAF pada port HTTPS, Anda juga harus mengonfigurasi sertifikat yang diperlukan di konsol WAF. Hal ini dapat menyebabkan masalah berikut:

Permintaan TLS diakhiri di lapisan WAF. Oleh karena itu, sertifikat yang dikonfigurasi dalam Secret Kubernetes tidak akan digunakan untuk titik akhir publik.
Saat Anda mengakses port 443 dari dalam kluster menggunakan alamat IP CLB atau ClusterIP Layanan, lalu lintas mungkin tidak melewati WAF, sehingga menyebabkan error sertifikat.
Dengan WAF diaktifkan, NGINX Ingress controller tidak dapat memperoleh alamat IP klien asli secara default. Tambahkan konten berikut ke ConfigMap (secara default, nginx-configuration di namespace kube-system untuk NGINX Ingress controller yang diinstal melalui manajemen komponen) untuk mengaktifkan modul Realip NGINX dan menggunakan header X-Forwarded-For guna memperoleh alamat IP klien asli.
```
use-forwarded-headers: "true" # Gunakan opsi ini untuk NGINX Ingress controller versi 0.30.0 dan sebelumnya.
enable-real-ip: "true" # Gunakan opsi ini untuk NGINX Ingress controller versi 0.44.0 dan seterusnya.
proxy-real-ip-cidr: <Blok CIDR back-to-origin yang Anda peroleh dari WAF>
```

Penyebaran biru-hijau atau rilis canary

Anda dapat menerapkan rilis canary dengan NGINX Ingress controller menggunakan fitur di Konsol ACK atau dengan menambahkan anotasi secara manual. Untuk informasi selengkapnya, lihat Gunakan NGINX Ingress untuk menerapkan rilis canary dan penyebaran biru-hijau.

Penting

Layanan asli dan canary hanya boleh direferensikan oleh Ingress canary. Jika tidak, konflik aturan canary dapat terjadi dan menyebabkan kesalahan pengarahan lalu lintas.

Proxy permintaan non-HTTP

Secara default, NGINX Ingress controller terhubung ke Layanan backend menggunakan protokol HTTP. Namun, controller ini juga mendukung berbagai protokol backend, dengan WebSocket, HTTPS, dan gRPC sebagai yang paling umum. Untuk daftar lengkap protokol backend yang didukung, lihat Backend Protocol.

WebSocket: NGINX Ingress controller menyediakan dukungan native untuk WebSocket. Tidak diperlukan konfigurasi tambahan untuk meneruskan koneksi WebSocket. Jika Anda memiliki koneksi WebSocket berdurasi panjang, Anda dapat menggunakan anotasi untuk menyesuaikan timeout koneksi backend guna mencegah pemutusan akibat timeout. Untuk informasi selengkapnya tentang cara melakukan penyesuaian, lihat Custom timeouts.
HTTPS: Untuk Layanan backend yang menggunakan HTTPS, Anda dapat menambahkan anotasi nginx.ingress.kubernetes.io/backend-protocol:"HTTPS" ke Ingress untuk beralih ke koneksi HTTPS.
gRPC: gRPC hanya dapat diakses melalui port TLS. Oleh karena itu, pastikan Anda menggunakan port TLS terenkripsi saat aplikasi Anda mengakses layanan gRPC melalui NGINX Ingress controller. Untuk informasi selengkapnya tentang cara mengonfigurasi gRPC, lihat Konfigurasikan layanan gRPC untuk NGINX Ingress.