Настройка заголовков кэша для контроллера входа nginx на кубернетах GKE

54
5

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

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

По большей части все работает, но если я попытаюсь установить связанные с кешем параметры с помощью аннотации 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 файлы и т.д.).

Любые мысли о том, почему это происходит?

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

спросил(а) 2018-10-09T01:50:00+03:00 1 год, 8 месяцев назад
1
Решение
86

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

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

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

ответил(а) 2018-10-09T02:33:00+03:00 1 год, 8 месяцев назад
Ваш ответ
Введите минимум 50 символов
Чтобы , пожалуйста,
Выберите тему жалобы:

Другая проблема