Ingress giúp bạn dễ dàng xác định các quy tắc định tuyến, đường dẫn, lưu trữ ảo dựa trên tên, tên miền hoặc tên miền con và hàng tấn chức năng khác để tự động truy cập các ứng dụng của bạn. Nhưng làm thế nào để bạn theo dõi tất cả các rule này và điều gì sẽ xảy ra khi bạn sửa đổi ingress resource hoặc thêm rule mới? Đó là nơi ingress controller chịu trách nghiệm.

Ingress controller có nhiệm vụ liên tục theo dõi tất cả các ingress rule được xác định trong cụm của bạn, quản lý tất cả các điều hướng và xác định nơi lưu lượng truy cập dựa trên các rule được xác định trong ingress controller. Bộ điều khiển Ingress không được cài đặt trong cụm Kubernetes theo mặc định, vì vậy bạn phải tự thiết lập một bộ điều khiển. Có một số cách cài đặt của ingress controller có sẵn ngày hôm nay; Bạn có thể kiểm tra chúng ở đây.

Trong bài viết này, chúng ta sẽ tìm hiểu về nginx ingress controller và các tùy chọn config hữu ích mà bạn có thể thêm vào để làm cho ứng dụng của bạn linh động hơn.

Đánh giá các config của nginx ingress

Có một số loại tùy chọn cấu hình có thể được áp dụng trên ingress controller của Kubernetes thông qua Annotations hoặc ConfigMaps. Danh sách config này được biên soạn dựa trên các tùy chọn được sử dụng thường xuyên trong các hệ thống production, thu thập thông tin trực tuyến chi tiết về ingress controller và xem xét một số vấn đề mà người dùng phải đối mặt trên Stack Overflow khi thiết lập và cấu hình tài nguyên và ingress controller. Mặc dù bài viết này chỉ tập trung vào vài tùy chọn cấu hình, bạn có thể xem lại các tùy chọn khác ở đây.

Ingress Controller Configuration Categories

Ingress controller NGINX có các tùy chọn cấu hình bổ sung có thể được tùy chỉnh và config để tạo ra một ứng dụng linh động hơn. Về cơ bản, điều này có thể được thực hiện theo hai cách:

• Annotations: tùy chọn này có thể được sử dụng nếu bạn muốn có một cấu hình cụ thể cho một ingress rule.
• ConfigMap: tùy chọn này có thể được sử dụng khi bạn cần thiết lập cấu hình cho toàn bộ ingress rule NGINX.

Lưu ý: Annotations được ưu tiên hơn ConfigMap.

Config hữu ích

Bây giờ, hãy xem xét các tùy chọn cấu hình sau đây để sử dụng trong ứng dụng của bạn.

Giảm thiểu downtime với proxy_next_upstream

Có một config rất hay của nginx có thể giúp bạn giảm downtime hệ thống khi bị lỗi đó là proxy_next_upstream. Khi request vào nginx ingress, nó sẽ điều hướng đến 1 trong các pod ( khi bạn đang để service-upstream là true hoặc không cấu hình – đọc thêm về service-upstream bên dưới ), khi response từ pod trả về lỗi, có thể chúng ra cần retry lại sang pod khác nếu chúng ta có nhiều hơn 1 pod. Khi đó chúng ta sẽ cần đến config proxy_next_upstream. Thêm các cấu hình sau vào configmap của ingress controller:

proxy-stream-next-upstream: true
proxy-next-upstream: error timeout http_502 http_503
proxy-next-upstream-timeout: "600s"
proxy-stream-next-upstream-tries: 3

Trong đó:

• proxy-stream-next-upstream: true : Để enable tính năng này (mặc định là true).
• proxy-next-upstream: error timeout http_502 http_503: retry khi gặp lỗi nào (tham khảo mã lỗi tại đây).
• proxy-next-upstream-timeout: “600s” : thời gian timeout của upstream tiếp theo (mặc định là 600s).
• proxy-stream-next-upstream-tries: 3 : số lần thử lại khi bị lỗi (mặc định là 3).

Service Upstream

Theo mặc định, nginx ingress controller sử dụng danh sách tất cả các ip của pod trong cấu hình upstream.

Annotation sau vô hiệu hóa hành vi đó và thay vào đó sử dụng một upstream duy nhất là service ip.

nginx.ingress.kubernetes.io/service-upstream: false

Điều này có thể được mong muốn cho những thứ như triển khai không downtime . Xem issue #257.

Các vấn đề bạn sẽ gặp phải:

Nếu annotation service-upstream được chỉ định, những điều sau đây bạn nên xem xét:

• Sticky Sessions sẽ không hoạt động vì chỉ có cân bằng tải tròn được hỗ trợ.
• Annotation proxy_next_upstream sẽ không hoạt động là lỗi mà yêu cầu sẽ không được gửi đến một upstream khác.

WWW Redirects

Có một loạt các tình huống mà bạn có thể muốn chuyển hướng từ domain.com đến www.domain.com hoặc ngược lại. Để bật tính năng này, hãy thêm annotations sau:

nginx.ingress.kubernetes.io/from-to-www-redirect: "true"

Ingress sẽ trông như thế này:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: minimal-ingress
  annotations:
    nginx.ingress.kubernetes.io/from-to-www-redirect: "true"
spec:
  rules:
  - host: domain.com
    http:
      paths:
      - backend:
          serviceName: service-www-redirect
          servicePort: 4000

Khi sử dụng www-redirect , lưu ý như sau:

• Nếu một ingress mới được tạo ra với host bằng với cái ở trên, annotations sẽ bị bỏ qua.
• Đối với chuyển hướng HTTPS sang HTTPS, bắt buộc phải xác định Chứng chỉ SSL trong Bí mật và thêm phần TLS của sự xâm nhập.

Đọc thêm về www-redirects tại đây.

Tự động redirect từ http sang https

SSL redirect config rất cần cho việc chuyển hướng lưu lượng truy cập từ HTTP sang HTTPS. Nếu quy tắc này được thêm vào phần TLS của ingress, ingress controller NGINX sẽ chuyển hướng (301) sang HTTPS. Bạn có thể vô hiệu hóa rule này bằng cách thêm dòng sau vào ingress của bạn:

nginx.ingress.kubernetes.io/ssl-redirect: "false"

Mặt khác, bạn có thể thực thi chuyển hướng đến HTTPS ngay cả khi không có chứng chỉ TLS nào có sẵn trong trường hợp tắt tải SSL. Điều này có thể được thực hiện bằng cách sử dụng những config sau đây:

nginx.ingress.kubernetes.io/force-ssl-redirect: "true"

Bạn cũng có thể sử dụng dấu gạch chéo trong URI với ssl-redirect. Đây là một ví dụ:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: test-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/preserve-trailing-slash: "true"
spec:
  rules:
  - http:
      paths:
      - path: /testpath
        backend:
          serviceName: test
          servicePort: 80

Timeout Setting

Ngoài ra còn có một số cài đặt Timeout Setting bạn có thể cấu hình trong ingress bằng cách sử dụng Annotations:

• proxy-connect-timeout: điều này xác định thời gian chờ để thiết lập kết nối với máy chủ gần. Giá trị mặc định là 60 giây và thời gian chờ thường không được vượt quá 75 giây. Kiểm tra tại đây để biết thêm thông tin.
• proxy-send-timeout: điều này sẽ đặt thời gian chờ để truyền request đến máy chủ. Thời gian chờ chỉ được đặt giữa hai thao tác ghi liên tiếp, không phải để truyền toàn bộ request. Theo tài liệu ingress NGINX, nếu máy chủ không nhận được bất cứ request điều gì trong thời gian này, kết nối sẽ bị đóng.

Ví dụ: bạn có thể thêm cài đặt thời gian chờ vào ingress của mình, như sau:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: cafe-ingress-with-annotations
  annotations:
    nginx.org/proxy-connect-timeout: "30s"
    nginx.org/proxy-read-timeout: "20s"
spec:
  rules:
  - host: hocdevops.com
    http:
      paths:
      - path: /tea
        backend:
          serviceName: tea-svc
          servicePort: 80
      - path: /coffee
        backend:
          serviceName: coffee-svc
          servicePort: 80

Đọc thêm về timeout tại đây.

CORS

You can also enable cross-origin resource sharing (CORS) in an ingress rule. This allows you to control the methods, headers, origins of requests, and other elements that are allowed to make requests to your cluster. There are several options that can also be activated when CORS is enabled on the ingress resource; for example, the origin of request, the exposed headers, and so forth. To activate CORS on ingress, add the annotation on the ingress. Here’s an example:enable-cors

nginx.ingress.kubernetes.io/enable-cors: "true"

There are other annotations you can use to control the CORS behavior:

nginx.ingress.kubernetes.io/cors-allow-methods # controls method accepted
nginx.ingress.kubernetes.io/cors-allow-headers # controls allowed headers

Đây là một ví dụ:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: test-ingress
  annotations:
    nginx.ingress.kubernetes.io/enable-cors: "true"
    nginx.ingress.kubernetes.io/cors-allow-methods: "PUT, GET, POST, OPTIONS"
    nginx.ingress.kubernetes.io/cors-allow-headers: "X-Forwarded-For, X-app123-XPTO"
    nginx.ingress.kubernetes.io/cors-expose-headers: "*, X-CustomResponseHeader"
    nginx.ingress.kubernetes.io/cors-max-age: 600
    nginx.ingress.kubernetes.io/cors-allow-credentials: "false"
spec:
  rules:
  - http:
      paths:
      - path: /testpath
        backend:
          serviceName: test
          servicePort: 80

Bạn có thể đọc thêm về cách kiểm soát chức năng CORS tại đây.

Rate Limit

Rate Limit rất hữu ích để xác định giới hạn về kết nối và tốc độ truyền. Chúng có thể rất hữu ích để giảm thiểu các cuộc tấn công DDoS.

• nginx.ingress.kubernetes.io/limit-connections: điều này xác định số lượng kết nối đồng thời được phép từ một địa chỉ IP.
• nginx.ingress.kubernetes.io/limit-rps: rps là viết tắt của “request per second”, và nó được sử dụng để xác định số lượng kết nối có thể được chấp nhận từ IP mỗi giây.

Đây là một ví dụ:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: test-ingress
  annotations:
    nginx.ingress.kubernetes.io/limit-rps: "5"
    nginx.ingress.kubernetes.io/limit-rpm: "300"
    nginx.ingress.kubernetes.io/limit-connections: "10"
spec:
  rules:
  - http:
      paths:
      - path: /testpath
        backend:
          serviceName: test
          servicePort: 80

Lưu ý: khi bạn chỉ định cả Annotations trong một ingress, rule đầu tiên được ưu tiên. Đọc thêm về rate-limiting ingress resource tại đây.

Chỉnh Max Body Size

Quy tắc này có thể được sử dụng để đặt kích thước tối đa của body trong một request. Nếu body vượt quá kích thước tối đa, NGINX sẽ trả lại lỗi 413 cho client.

Body request có thể được cấu hình bằng cách sử dụng như sau:

nginx.ingress.kubernetes.io/proxy-body-size: 8m

Đây là một ví dụ:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: test-ingress
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: 8m
spec:
  rules:
  - http:
      paths:
      - path: /testpath
        backend:
          serviceName: test

Whitelist Source Range

Chúng ta cũng có thể whitelist IP được phép từ client. Điều này có nghĩa là bạn có thể cấu hình ingress controller để chỉ cho phép request từ một địa chỉ IP cụ thể. Tính năng này có thể ngăn chặn các request không xác định hoặc trái phép đến cụm của bạn.

Để xác định phạm vi nguồn whitelist IP, hãy dùng Annotations bên dưới:

nginx.ingress.kubernetes.io/whitelist-source-range

Đây là một ví dụ:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: test-ingress
  annotations:
     ingress.kubernetes.io/whitelist-source-range: "10.0.0.0/24,172.10.0.1"
spec:
  rules:
  - http:
      paths:
      - path: /testpath
        backend:
          serviceName: test

Lưu ý: bạn có thể gặp sự cố mà IP không thể truy cập tài nguyên. Trong trường hợp này, bạn có thể cần phải bật externalTrafficPolicy trong annotation của bạn. Xem lại câu trả lời này trên Stack Overflow để biết thêm thông tin.

Default Backend

Default Backend được sử dụng để xử lý một yêu cầu không xác định hoặc một yêu cầu không được ánh xạ đến bất kỳ đường dẫn hoặc máy chủ nào trong tài nguyên hệ thống. Nếu bạn không xác định dịch vụ này và nhập đường dẫn không được ánh xạ, nó sẽ trả về lỗi HTTP 404 (trang không tìm thấy). Để khắc phục sự cố này, hãy tạo một dịch vụ và ánh xạ nó đến Default Backend. Điều này có thể được sử dụng để hiển thị tùy chỉnh 404 trang và thông báo lỗi.

Để cấu hình quy tắc này, hãy thêm config:

nginx.ingress.kubernetes.io/default-backend: <svc name>

Đây là một ví dụ:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: test-ingress
  annotations:
     nginx.ingress.kubernetes.io/default-backend: <svc name>
spec:
  rules:
  - http:
      paths:
      - path: /testpath
        backend:
          serviceName: test

Enable Access Log

Access Logcho phép bạn xem thông tin về request của client. NGINX ghi log vào file sau khi request đã được xử lý. Chúng được kích hoạt theo mặc định trong NGINX, nhưng chúng có thể cần phải bị vô hiệu hóa cho một số ingress nhất định. Để làm điều này, hãy sử dụng annotation này:

nginx.ingress.kubernetes.io/enable-access-log: "false"

Đây là một ví dụ:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: test-ingress
  annotations:
     nginx.ingress.kubernetes.io/enable-access-log: "false"
spec:
  rules:
  - http:
      paths:
      - path: /testpath
        backend:
          serviceName: test

Giao thức Phụ trợ

Bạn có thể sử dụng giao thức phụ trợ để chỉ định cách NGINX nên giao tiếp với dịch vụ phụ trợ. Các giá trị hợp lệ bao gồm HTTP, HTTPS, GRPC, GRPCS, AJP và FCGI. Theo mặc định, NGINX sử dụng HTTP.

Đây là một ví dụ:

nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"

Kết thúc

Ingress controller NGINX giúp dễ dàng cấu hình các rule và thiết lập một ứng dụng linh động hơn để xử lý các request và response từ client. Điều này làm cho NGINX trở thành một lựa chọn tuyệt vời cho ingress controller với số lượng config và cài đặt có sẵn có thể được áp dụng cho ingress rule. Trong bài viết này, bạn đã học được ingress là gì, vai trò của ingress controller là gì và làm thế nào bạn có thể cấu hình các ingress rule của mình để linh động hơn. Tìm hiểu thêm về các config khác tại đây.