Установка заголовков контроля кеша для входного контроллера nginx на kubernetes GKE

Question

У меня есть контроллер ingress-nginx, обрабатывающий трафик к моему кластеру Kubernetes, размещенному на GKE.Я установил его, используя инструкции по установке helm из документов:

Документы здесь

По большей части все работает, но если я пытаюсь установить параметры, связанные с кешем, черезserver-snippet аннотация, весь обслуживаемый контент, который должен получить заголовки управления кэшем, возвращается как 404.

Вот мой ingress-service.yaml файл:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-service
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/proxy-read-timeout: "4000"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "4000"
    nginx.ingress.kubernetes.io/server-snippet: |
      location ~* \.(js|css|gif|jpe?g|png)$ {
        expires 1M;
        add_header Cache-Control "public";
      }
spec:
  tls:
    - hosts:
        - example.com
      secretName: example-com
  rules:
    - host: example.com
      http:
       paths:
        - path: /
          backend:
            serviceName: client-cluster-ip-service
            servicePort: 5000
        - path: /api/
          backend:
            serviceName: server-cluster-ip-service
            servicePort: 4000

Опять же,это только те ресурсы, которым регулярное выражение соответствует 404 (все .js файлы, .css файлы и т. д.).

Есть мысли о том, почему это могло бы произойти?

Любая помощь приветствуется!

Answer 1

Эти location блоки имеют последнее и / или самое длинное совпадение, выигрывает , и поскольку входной сам не обслуживает никакого такого контента, nginx полагается на proxy_pass директива , указывающая на вышестоящий сервер.Таким образом, если вы получаете 404 с, это очень вероятно, потому что ваш location совпадает, что мешает proxy_pass.Есть довольно хороший шанс, что вы на самом деле захотите вместо этого configuration-snippet:, вероятно, в сочетании с if ($request_uri ~* ...) { для добавления заголовка.

Можно попробовать это локальнос простым триггером nginx.conf, указывающим на python3 -m http.server 9090 или на любую поддельную восходящую цель.

Отдельно, для устранения проблем входа nginx, часто неоценимо консультироваться с его фактической nginx.conf, которую можно получить из любоговходных модулей и / или просмотр журналов входных модулей, где nginx будет выдавать полезный текст для отладки.