← Quay lại blog
RUENZHESARPTDEFRJAKOITTRIDVIFAHI

Proxy cho Kubernetes Ingress Controller: Hướng dẫn cấu hình đầy đủ trong cụm K8s với ví dụ cấu hình

Phân tích cách cấu hình đúng proxy server trong Kubernetes Ingress Controller - từ cấu hình cơ bản NGINX đến xoay vòng IP cư trú để vượt qua các lệnh cấm.

📅10 tháng 8, 2026
```html

Nếu cụm K8s của bạn thực hiện các yêu cầu bên ngoài — đến API của đối tác, đến các chợ điện tử, đến các nền tảng quảng cáo — sớm hay muộn bạn sẽ gặp phải việc chặn theo IP. Ingress Controller tự quản lý lưu lượng truy cập đến, nhưng để thực hiện các yêu cầu ra ngoài qua các pod cần một sơ đồ riêng với proxy. Trong bài viết này, chúng ta sẽ phân tích cách cấu hình điều này đúng cách: từ việc chọn loại proxy đến các cấu hình YAML cụ thể cho NGINX Ingress và Traefik.

Tại sao cần proxy trong Kubernetes: các kịch bản thực tế

Kubernetes là một trình điều phối, và hầu hết các bài viết về nó nói về lưu lượng truy cập đến: cách cấu hình Ingress, cách phát hành chứng chỉ TLS, cách định tuyến các yêu cầu đến các dịch vụ. Nhưng có một khía cạnh khác: lưu lượng truy cập ra từ các pod. Chính tại đây xảy ra các vấn đề với việc chặn, giới hạn địa lý và giới hạn theo IP.

Hãy xem xét các nhiệm vụ cụ thể, nơi mà proxy trong cụm K8s trở thành một điều cần thiết:

  • Phân tích và giám sát giá cả. Cụm của bạn chạy CronJob mỗi 15 phút và thu thập dữ liệu từ Wildberries, Ozon, Amazon. Nếu không có xoay vòng IP, sau 2–3 giờ bạn sẽ bị cấm trên toàn bộ dải IP của nhà cung cấp đám mây của bạn.
  • Thao tác với API quảng cáo. Facebook Marketing API, TikTok Ads API, Google Ads API — tất cả đều theo dõi nguồn gốc của các yêu cầu. Nếu hàng chục pod gửi yêu cầu từ một IP của trung tâm dữ liệu, đó là một tín hiệu để tự động chặn.
  • Kiểm tra địa lý. Dịch vụ của bạn cần hiển thị nội dung khác nhau cho người dùng từ các quốc gia khác nhau. Qua proxy, các pod có thể giả lập các yêu cầu từ các khu vực cần thiết cho các bài kiểm tra tự động.
  • Vượt qua các hạn chế của công ty. Trong một số hạ tầng, toàn bộ lưu lượng ra phải đi qua proxy của công ty — đây là yêu cầu tuân thủ.
  • Thao tác với API đối tác có danh sách trắng IP. Khi đối tác chỉ cho phép các yêu cầu từ các IP cụ thể, và cụm của bạn mở rộng và thay đổi địa chỉ — proxy với các IP tĩnh giải quyết vấn đề.

Quan trọng là phải hiểu sự phân chia kiến trúc: Ingress Controller quản lý lưu lượng truy cập đến (từ người dùng đến các dịch vụ của bạn), trong khi proxy cho các yêu cầu ra ngoài — là một nhiệm vụ riêng biệt. Tuy nhiên, chúng có liên quan: cấu hình proxy thường được đặt ở cấp độ của cùng một Ingress Controller hoặc thông qua các chú thích mà nó đọc.

💡 Phân định quan trọng

Trong bài viết này, chúng ta sẽ phân tích hai kịch bản: (1) cấu hình Ingress Controller như một proxy ngược cho các máy chủ upstream bên ngoài, và (2) định tuyến lưu lượng ra từ các pod qua một máy chủ proxy bên ngoài. Cả hai kịch bản đều xuất hiện trong sản xuất.

Loại proxy nào nên chọn cho cụm K8s

Việc chọn loại proxy ảnh hưởng trực tiếp đến thời gian mà cụm của bạn có thể hoạt động mà không bị chặn. IP của trung tâm dữ liệu — là rẻ nhất, nhưng dễ dàng bị xác định và chặn. IP cư trú và di động — đắt hơn, nhưng đáng tin cậy hơn nhiều cho các nhiệm vụ mà việc giả lập người dùng thực là quan trọng.

Loại proxy Tốc độ Rủi ro bị chặn Kịch bản tốt nhất trong K8s
Trung tâm dữ liệu Cao Cao API nội bộ, tuân thủ doanh nghiệp, tích hợp đối tác với danh sách trắng IP
Cư trú Trung bình Thấp Phân tích chợ điện tử, thao tác với API quảng cáo, kiểm tra địa lý
Di động Trung bình Tối thiểu Facebook Ads API, TikTok API, các nhiệm vụ có tải cao với rủi ro bị cấm

Đối với hầu hết các nhiệm vụ trong cụm K8s liên quan đến phân tích hoặc thao tác với các nền tảng quảng cáo, lựa chọn tối ưu là proxy cư trú với xoay vòng. Chúng cung cấp các IP thực của người dùng gia đình, và các thuật toán bảo vệ trang web coi các yêu cầu như lưu lượng truy cập trình duyệt thông thường.

Về mặt giao thức cho K8s, HTTP/HTTPS-proxy là phổ biến nhất — nó được hỗ trợ bởi tất cả các HTTP-client phổ biến trong bất kỳ ngôn ngữ lập trình nào thông qua các biến môi trường tiêu chuẩn HTTP_PROXY và HTTPS_PROXY. SOCKS5 chỉ cần thiết cho các giao thức không tiêu chuẩn hoặc khi cần proxy không chỉ HTTP.

Cấu hình proxy qua NGINX Ingress Controller

NGINX Ingress Controller là lựa chọn phổ biến nhất trong K8s. Hãy xem xét hai kịch bản: cấu hình NGINX như một proxy ngược đến upstream bên ngoài qua máy chủ proxy, và cấu hình toàn cầu cho proxy ra ngoài cho chính controller.

Chú thích cho việc proxy các yêu cầu đến upstream

NGINX Ingress hỗ trợ các chú thích để quản lý hành vi của proxy. Nếu bạn cần Ingress chuyển tiếp các yêu cầu đến dịch vụ bên ngoài qua một proxy trung gian, hãy sử dụng ConfigMap với cấu hình tùy chỉnh: 

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-ingress-controller
  namespace: ingress-nginx
data:
  # Proxy HTTP toàn cầu cho các yêu cầu ra ngoài của NGINX
  http-snippet: |
    proxy_connect_timeout 10s;
    proxy_read_timeout 30s;
    proxy_send_timeout 30s;
  # Cấu hình upstream qua proxy
  use-proxy-protocol: "false"
  proxy-real-ip-cidr: "0.0.0.0/0"

Tài nguyên Ingress với các chú thích cho proxy

Đối với một tài nguyên Ingress riêng biệt, bạn có thể đặt các tham số proxy qua các chú thích. Điều này hữu ích khi các dịch vụ khác nhau yêu cầu các thời gian chờ và cấu hình khác nhau: 

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-service-ingress
  namespace: production
  annotations:
    kubernetes.io/ingress.class: "nginx"
    # Thời gian chờ của proxy
    nginx.ingress.kubernetes.io/proxy-connect-timeout: "10"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "60"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "60"
    # Kích thước bộ đệm
    nginx.ingress.kubernetes.io/proxy-buffer-size: "16k"
    nginx.ingress.kubernetes.io/proxy-buffers-number: "8"
    # Chuyển tiếp IP thực của khách hàng
    nginx.ingress.kubernetes.io/use-forwarded-headers: "true"
    nginx.ingress.kubernetes.io/forwarded-for-header: "X-Forwarded-For"
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-service
            port:
              number: 80

Cấu hình proxy bên ngoài cho các yêu cầu ra ngoài của pod NGINX

Nếu chính NGINX Ingress Controller cần thực hiện các yêu cầu ra ngoài qua một proxy bên ngoài (ví dụ, để kiểm tra sức khỏe các điểm cuối bên ngoài), cần đặt các biến môi trường trong Deployment của controller: 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
spec:
  template:
    spec:
      containers:
      - name: controller
        image: registry.k8s.io/ingress-nginx/controller:v1.9.4
        env:
        - name: HTTP_PROXY
          valueFrom:
            secretKeyRef:
              name: proxy-credentials
              key: http-proxy-url
        - name: HTTPS_PROXY
          valueFrom:
            secretKeyRef:
              name: proxy-credentials
              key: https-proxy-url
        - name: NO_PROXY
          value: "localhost,127.0.0.1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.cluster.local"

Lưu ý đến biến NO_PROXY — nó rất quan trọng. Nếu không có nó, toàn bộ lưu lượng nội bộ trong cụm cũng sẽ đi qua proxy bên ngoài, điều này sẽ làm hỏng sự tương tác giữa các dịch vụ. Trong NO_PROXY, luôn bao gồm các dải RFC-1918 và hậu tố .cluster.local.

Cấu hình proxy trong Traefik Ingress Controller

Traefik là một lựa chọn phổ biến thay thế cho NGINX Ingress, đặc biệt là khi kết hợp với Helm và trong các cụm quản lý (k3s, Docker Swarm, Nomad). Traefik có hệ thống cấu hình riêng thông qua CRD (Custom Resource Definitions) và các cấu hình tĩnh/động.

Cấu hình tĩnh Traefik với proxy

apiVersion: v1
kind: ConfigMap
metadata:
  name: traefik-config
  namespace: traefik
data:
  traefik.yaml: |
    # Cấu hình tĩnh Traefik
    entryPoints:
      web:
        address: ":80"
      websecure:
        address: ":443"
    
    # Cài đặt để hoạt động qua proxy
    serversTransport:
      insecureSkipVerify: false
      maxIdleConnsPerHost: 200
      dialTimeout: 10s
      responseHeaderTimeout: 30s
    
    # Ghi log cho chẩn đoán proxy
    log:
      level: INFO
    
    accessLog:
      fields:
        headers:
          defaultMode: keep
          names:
            X-Forwarded-For: keep
            X-Real-IP: keep

Middleware để thêm các tiêu đề proxy

Trong Traefik, bạn có thể tạo Middleware, sẽ thêm hoặc sửa đổi các tiêu đề khi chuyển tiếp các yêu cầu. Điều này hữu ích để truyền tải chính xác IP thực của khách hàng qua chuỗi proxy: 

apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
  name: proxy-headers
  namespace: production
spec:
  headers:
    customRequestHeaders:
      X-Forwarded-Proto: "https"
    # Xóa các tiêu đề có thể tiết lộ hạ tầng
    customResponseHeaders:
      X-Powered-By: ""
      Server: ""
---
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: my-app-route
  namespace: production
spec:
  entryPoints:
    - websecure
  routes:
  - match: Host(`myapp.example.com`)
    kind: Rule
    middlewares:
    - name: proxy-headers
    services:
    - name: my-service
      port: 80

Biến môi trường cho Traefik Deployment

Tương tự như NGINX, đối với Traefik, chúng ta đặt các biến môi trường thông qua giá trị Helm hoặc trực tiếp trong Deployment. Khi sử dụng Helm chart, điều này được thực hiện thông qua values.yaml: 

# values.yaml cho Traefik Helm chart
deployment:
  enabled: true
  kind: Deployment
  
env:
  - name: HTTP_PROXY
    valueFrom:
      secretKeyRef:
        name: proxy-credentials
        key: http-proxy-url
  - name: HTTPS_PROXY
    valueFrom:
      secretKeyRef:
        name: proxy-credentials
        key: https-proxy-url
  - name: NO_PROXY
    value: "localhost,127.0.0.1,10.96.0.0/12,10.244.0.0/16,.cluster.local,.svc"

Proxy qua biến môi trường trong các pod

Cách phổ biến nhất để cấu hình proxy ra ngoài cho bất kỳ pod nào là qua các biến môi trường tiêu chuẩn. Phương pháp này hoạt động độc lập với ngôn ngữ lập trình và framework: Python requests, Go net/http, Node.js axios, Java HttpClient — tất cả đều tự động đọc HTTP_PROXY và HTTPS_PROXY.

Tùy chọn 1: Trực tiếp trong Pod Spec

apiVersion: v1
kind: Pod
metadata:
  name: scraper-pod
  namespace: production
spec:
  containers:
  - name: scraper
    image: mycompany/scraper:latest
    env:
    - name: HTTP_PROXY
      value: "http://username:[email protected]:8080"
    - name: HTTPS_PROXY
      value: "http://username:[email protected]:8080"
    - name: NO_PROXY
      value: "localhost,127.0.0.1,10.0.0.0/8,.cluster.local"
    resources:
      requests:
        memory: "128Mi"
        cpu: "100m"
      limits:
        memory: "256Mi"
        cpu: "500m"

⚠️ Đừng lưu trữ thông tin xác thực ở dạng rõ ràng!

Ví dụ trên được trình bày để minh họa. Trong sản xuất, thông tin xác thực proxy luôn phải được lưu trữ trong Kubernetes Secret và được truyền qua secretKeyRef. Chi tiết hơn — trong phần về Secrets bên dưới.

Tùy chọn 2: Qua ConfigMap cho nhiều pod

Nếu proxy được sử dụng bởi nhiều Deployment, tiện lợi hơn khi đưa các cài đặt vào ConfigMap và kết nối nó qua envFrom: 

apiVersion: v1
kind: ConfigMap
metadata:
  name: proxy-config
  namespace: production
data:
  NO_PROXY: "localhost,127.0.0.1,10.0.0.0/8,172.16.0.0/12,.cluster.local,.svc.cluster.local"
  PROXY_TIMEOUT: "30"
  PROXY_MAX_RETRIES: "3"
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: price-monitor
  namespace: production
spec:
  replicas: 5
  selector:
    matchLabels:
      app: price-monitor
  template:
    metadata:
      labels:
        app: price-monitor
    spec:
      containers:
      - name: monitor
        image: mycompany/price-monitor:v2.1
        envFrom:
        - configMapRef:
            name: proxy-config
        - secretRef:
            name: proxy-credentials
        ports:
        - containerPort: 8080

Tùy chọn 3: Mút hóa WebhookAdmissionController

Đối với các cụm doanh nghiệp, nơi tất cả các pod đều phải sử dụng proxy, có thể cấu hình một webhook admission mút hóa, tự động thêm các biến môi trường proxy vào tất cả các pod được tạo ra. Giải pháp này được sử dụng trong các hạ tầng doanh nghiệp, nơi tuân thủ yêu cầu rằng toàn bộ lưu lượng ra phải đi qua proxy của công ty. Việc triển khai một webhook như vậy nằm ngoài phạm vi của bài viết này, nhưng cần biết về sự tồn tại của nó.

Xoay vòng IP và quản lý hồ bơi proxy trong K8s

Proxy tĩnh — là tốt cho tuân thủ doanh nghiệp, nhưng không tốt cho các nhiệm vụ cần tránh việc chặn. Nếu 50 pod của bạn gửi yêu cầu qua cùng một IP, IP đó sẽ bị chặn rất nhanh. Giải pháp — xoay vòng proxy.

Sơ đồ với Proxy Sidecar

Một trong những mẫu — chạy một tác nhân proxy như một container sidecar bên cạnh ứng dụng chính. Sidecar nhận các yêu cầu trên localhost:8080 và chuyển tiếp chúng qua một hồ bơi proxy bên ngoài đang xoay vòng: 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: scraper-with-proxy-sidecar
  namespace: production
spec:
  replicas: 10
  selector:
    matchLabels:
      app: scraper
  template:
    metadata:
      labels:
        app: scraper
    spec:
      containers:
      # Ứng dụng chính
      - name: scraper
        image: mycompany/scraper:latest
        env:
        - name: HTTP_PROXY
          value: "http://localhost:8080"
        - name: HTTPS_PROXY
          value: "http://localhost:8080"
        - name: NO_PROXY
          value: "localhost,127.0.0.1,.cluster.local"
      
      # Sidecar: tác nhân proxy cục bộ với xoay vòng
      - name: proxy-rotator
        image: mycompany/proxy-rotator:latest
        ports:
        - containerPort: 8080
        env:
        - name: PROXY_LIST_URL
          valueFrom:
            secretKeyRef:
              name: proxy-credentials
              key: api-endpoint
        - name: ROTATION_INTERVAL
          value: "60"  # xoay vòng mỗi 60 giây
        resources:
          requests:
            memory: "64Mi"
            cpu: "50m"
          limits:
            memory: "128Mi"
            cpu: "200m"

Sơ đồ với Proxy Service trung tâm

Một cách tiếp cận thay thế — một Proxy Service duy nhất bên trong cụm, mà tất cả các pod đều truy cập. Điều này dễ quản lý hơn: chỉ cần cập nhật một Secret với thông tin xác thực proxy, và tất cả các pod sẽ tự động bắt đầu sử dụng dữ liệu mới. 

apiVersion: v1
kind: Service
metadata:
  name: proxy-gateway
  namespace: proxy-system
spec:
  selector:
    app: proxy-gateway
  ports:
  - name: http
    port: 8080
    targetPort: 8080
  - name: socks5
    port: 1080
    targetPort: 1080
  type: ClusterIP
---
# Các pod sử dụng proxy qua DNS nội bộ
# HTTP_PROXY=http://proxy-gateway.proxy-system.svc.cluster.local:8080

Đối với các nhiệm vụ mà tính ẩn danh và rủi ro bị chặn tối thiểu là rất quan trọng (ví dụ, phân tích chợ điện tử hoặc thao tác với API quảng cáo), chúng tôi khuyên bạn nên sử dụng proxy cư trú với xoay vòng — chúng cung cấp các IP thực của người dùng gia đình, điều này làm cho lưu lượng truy cập từ cụm của bạn không thể phân biệt với lưu lượng truy cập trình duyệt thông thường.

Lưu trữ thông tin xác thực proxy trong Kubernetes Secrets

Việc lưu trữ thông tin xác thực một cách an toàn là yêu cầu bắt buộc cho bất kỳ cụm sản xuất nào. Không bao giờ chèn tên đăng nhập/mật khẩu proxy trực tiếp vào các manifest YAML được lưu trữ trong kho Git.

Tạo Secret cho proxy

# Tạo qua kubectl (các giá trị được mã hóa base64 tự động)
kubectl create secret generic proxy-credentials \
  --namespace=production \
  --from-literal=http-proxy-url='http://user:[email protected]:8080' \
  --from-literal=https-proxy-url='http://user:[email protected]:8080' \
  --from-literal=socks5-proxy-url='socks5://user:[email protected]:1080'

# Kiểm tra Secret đã tạo
kubectl get secret proxy-credentials -n production -o yaml

Manifest YAML của Secret

apiVersion: v1
kind: Secret
metadata:
  name: proxy-credentials
  namespace: production
  labels:
    app: proxy-config
    managed-by: ops-team
type: Opaque
# Các giá trị được mã hóa base64
# echo -n 'http://user:pass@proxy:8080' | base64
stringData:
  # stringData cho phép chỉ định các giá trị ở dạng rõ ràng
  # Kubernetes tự động mã hóa chúng thành base64
  http-proxy-url: "http://user:[email protected]:8080"
  https-proxy-url: "http://user:[email protected]:8080"
  proxy-host: "gate.proxycove.com"
  proxy-port: "8080"
  proxy-username: "user"
  proxy-password: "password"

Sử dụng Secret trong Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-worker
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api-worker
  template:
    metadata:
      labels:
        app: api-worker
    spec:
      containers:
      - name: worker
        image: mycompany/api-worker:latest
        env:
        - name: HTTP_PROXY
          valueFrom:
            secretKeyRef:
              name: proxy-credentials
              key: http-proxy-url
        - name: HTTPS_PROXY
          valueFrom:
            secretKeyRef:
              name: proxy-credentials
              key: https-proxy-url
        - name: NO_PROXY
          value: "localhost,127.0.0.1,10.0.0.0/8,.cluster.local"
        # Đối với các ứng dụng đọc host/port riêng biệt
        - name: PROXY_HOST
          valueFrom:
            secretKeyRef:
              name: proxy-credentials
              key: proxy-host
        - name: PROXY_PORT
          valueFrom:
            secretKeyRef:
              name: proxy-credentials
              key: proxy-port

Tích hợp với các kho lưu trữ bí mật bên ngoài

Trong môi trường doanh nghiệp, nên sử dụng External Secrets Operator để đồng bộ hóa các bí mật từ HashiCorp Vault, AWS Secrets Manager hoặc Azure Key Vault. Điều này cho phép tự động cập nhật thông tin xác thực proxy mà không cần can thiệp thủ công và khởi động lại các pod: 

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: proxy-credentials-ext
  namespace: production
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: proxy-credentials
    creationPolicy: Owner
  data:
  - secretKey: http-proxy-url
    remoteRef:
      key: secret/proxy/proxycove
      property: http_proxy_url
  - secretKey: https-proxy-url
    remoteRef:
      key: secret/proxy/proxycove
      property: https_proxy_url

Chẩn đoán và các lỗi thường gặp khi cấu hình proxy trong K8s

Ngay cả khi cấu hình đúng, có thể xảy ra vấn đề. Chúng ta sẽ phân tích những vấn đề phổ biến nhất và cách chẩn đoán.

Vấn đề 1: Lưu lượng nội bộ trong cụm đi qua proxy

Triệu chứng: các pod không thể nhìn thấy nhau, phân giải DNS bên trong cụm bị hỏng, các dịch vụ không phản hồi. Nguyên nhân — biến NO_PROXY không được cấu hình.

Giá trị tối thiểu cần thiết cho NO_PROXY cho cụm K8s tiêu chuẩn: 

NO_PROXY=localhost,127.0.0.1,::1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.cluster.local,.svc,.svc.cluster.local,kubernetes.default.svc

Vấn đề 2: Proxy không được áp dụng cho một pod cụ thể

Chẩn đoán: vào pod và kiểm tra các biến môi trường: 

# Kiểm tra các biến môi trường trong pod
kubectl exec -it <pod-name> -n production -- env | grep -i proxy

# Kiểm tra kết nối qua proxy từ pod
kubectl exec -it <pod-name> -n production -- curl -v --proxy http://proxy:8080 https://httpbin.org/ip

# Kiểm tra rằng Secret được gắn đúng cách
kubectl exec -it <pod-name> -n production -- env | grep PROXY

Vấn đề 3: Lỗi TLS khi sử dụng HTTPS-proxy

Nếu proxy sử dụng chứng chỉ tự ký hoặc CA doanh nghiệp, các ứng dụng sẽ nhận được lỗi xác thực TLS. Giải pháp — thêm chứng chỉ CA của proxy vào danh sách tin cậy: 

# Tạo ConfigMap với chứng chỉ CA
kubectl create configmap proxy-ca-cert \
  --from-file=proxy-ca.crt=./proxy-ca.crt \
  -n production

# Gắn vào pod
spec:
  containers:
  - name: app
    volumeMounts:
    - name: proxy-ca
      mountPath: /etc/ssl/certs/proxy-ca.crt
      subPath: proxy-ca.crt
  volumes:
  - name: proxy-ca
    configMap:
      name: proxy-ca-cert

Vấn đề 4: Các yêu cầu chậm qua proxy

Nếu các yêu cầu qua proxy chậm hơn đáng kể so với các yêu cầu trực tiếp — hãy kiểm tra:

  • Phân giải DNS: đảm bảo rằng các yêu cầu DNS không đi qua proxy (thêm vào NO_PROXY)
  • Kết nối Keep-alive: cấu hình hồ bơi kết nối đến máy chủ proxy
  • Vị trí địa lý: máy chủ proxy phải gần về mặt vật lý với tài nguyên mục tiêu
  • Loại proxy: cho các nhiệm vụ có tốc độ cao, hãy xem xét proxy trung tâm dữ liệu — chúng cung cấp độ trễ tối thiểu

Các lệnh hữu ích cho chẩn đoán

# Kiểm tra log của Ingress Controller
kubectl logs -n ingress-nginx -l app.kubernetes.io/name=ingress-nginx --tail=100

# Kiểm tra sự kiện của pod
kubectl describe pod <pod-name> -n production

# Kiểm tra kết nối proxy từ pod
kubectl run test-proxy --image=curlimages/curl --rm -it --restart=Never -- \
  curl -x http://user:pass@proxy:8080 -v https://httpbin.org/ip

# Kiểm tra rằng Secret tồn tại và chứa các khóa cần thiết
kubectl get secret proxy-credentials -n production -o jsonpath='{.data}' | python3 -c "
import sys, json, base64
data = json.load(sys.stdin)
for k, v in data.items():
    print(f'{k}: {base64.b64decode(v).decode()[:20]}...')
"

Kết luận và khuyến nghị

Cấu hình proxy trong Kubernetes không phải là một nhiệm vụ đơn lẻ, mà là một phần của kiến trúc an ninh mạng của cụm. Hãy tóm tắt:

  • Đối với NGINX Ingress Controller — sử dụng các chú thích để cấu hình các tham số proxy ở cấp độ các tài nguyên Ingress riêng biệt, và các biến môi trường trong Deployment cho các cài đặt toàn cầu của lưu lượng ra.
  • Đối với Traefik — kết hợp cấu hình tĩnh qua ConfigMap với Middleware để quản lý các tiêu đề.
  • Đối với các pod — các biến tiêu chuẩn HTTP_PROXY / HTTPS_PROXY qua Secrets — là cách tiếp cận phổ biến và an toàn nhất.
  • Luôn luôn cấu hình NO_PROXY — nếu không, lưu lượng nội bộ trong cụm sẽ bị hỏng.
  • Không bao giờ lưu trữ thông tin xác thực proxy ở dạng rõ ràng trong các manifest hoặc trong Git.
  • Đối với sản xuất — sử dụng External Secrets Operator để tự động xoay vòng thông tin xác thực.

Nếu cụm K8s của bạn thực hiện các nhiệm vụ mà tính ổn định của IP và rủi ro bị chặn tối thiểu là rất quan trọng — phân tích, thao tác với API quảng cáo, kiểm tra địa lý — chúng tôi khuyên bạn nên sử dụng proxy cư trú. Chúng cung cấp các IP thực của người dùng gia đình, mà các thuật toán bảo vệ coi là lưu lượng hợp pháp. Đối với các nhiệm vụ có yêu cầu cao về tốc độ và rủi ro tối thiểu từ các nền tảng di động, proxy di động sẽ là lựa chọn tuyệt vời — chúng hoạt động qua các mạng 4G/5G thực tế của các nhà mạng.

```