N
в дефолтной спеке ингресса такого не видел
Size: a a a
2020 November 02
ᴅ
N
ингресс все таки не http by-default (хоть его в это и тащат)
(все еще жду mq-ингрессов и прочих application протоколов)
(все еще жду mq-ингрессов и прочих application протоколов)
L
Всем привет. Раскуриваю кубер, поэтому есть пару вопросов, у кого есть время был бы рад если бы ответили. Есть схема. Нжинкс два контейнера с nodejs и база. Описал для каждого имейджа деплоймент и сервис. Поднял кластер. Какие еще ресурсы нужно поднять, чтобы нжинкс видел сервисы nodejs ? может есть какой бест практис или какой нибудь мануал пошаговый? А то у меня пока нжинкс ругается что не видит апстрим cas
upstream сas {
server cas-service:8001 ;
keepalive 1024 ;
}
upstream сas {
server cas-service:8001 ;
keepalive 1024 ;
}
cервис типа clusterip тебе надо
но лучше nginx и нодежс запускать как два контейнера в одном поде. чтобы nginx Через 127.0.0.1 в ноджс ходил
но лучше nginx и нодежс запускать как два контейнера в одном поде. чтобы nginx Через 127.0.0.1 в ноджс ходил
АФ
всем салют, подскажите можно ли через ingres разрулить трафик в зависимости от хидера?
по идее можно через server-snippet: https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/nginx-configuration/annotations.md#server-snippet
SP
SP
хотелось бы раздель один под, один контейнер, ибо количество контенейров будет расти
DS
Ребят вопрос к использующим cilium.
Не могу понять эта баг или фича.
Накатил свою обычную сетевую потилтику для kube-system: https://pastebin.com/ZJqF0FHq
А у меня вся сеть отвалилась для запросов внутри kube-system. cilium агенты начинают перезапускаться по livenessProbe, так как не могут подключиться к etcd. Начал смотреть хаблом, вижу такое
Не нахожу pod'ов c таким ip адресом (10
Далее захожу в pod cilium агент'а который висит на том же хосте что и co
делаю трассировку политики для 6 => 932616
получаю denied.
Окей. Добавляю политику CiliumNetworkPolicy для label'а
Все заработало.
Но меня смущают два момента:
1) Что network policy куба которое работало на других cni, в cilium теперь не работает. А чтобы оно работало пришлось добавить дополнитульную политику CiliumNetworkPolicy. В которой к тому же я не очень уверен
2) Меня смущает мое правило в CiliumNetworkPolicy. Я разрешил по сути с внутреннего адреса всех нод подключаться к подам из kube-system. Вроде ничего страшного, из других namespace доступ к kube-system не проходит. Но возможно тут могут быть какие-то проблемы и под reserved: remote-host попадет не то чему следует - может быть это паранойя.
И второй вопрос. Можно ли в hubble выводить identi
Не могу понять эта баг или фича.
Накатил свою обычную сетевую потилтику для kube-system: https://pastebin.com/ZJqF0FHq
А у меня вся сеть отвалилась для запросов внутри kube-system. cilium агенты начинают перезапускаться по livenessProbe, так как не могут подключиться к etcd. Начал смотреть хаблом, вижу такое
10.245.2.79:8920 -> kube-system/coredns-f9fd979d6-4x7fq:53 Policy denied DROPPED (TCP Flags: SYN)
Не нахожу pod'ов c таким ip адресом (10
.245.2.79) . Но затем нахожу такой ip адрес на ноде в аннотациях: io.cilium.network.ipv4-cilium-host: 10.245.2.79. Cilium работает в режиме туннелинга vxlan. Удивляюсь что внутренний ip ноды выдается из podCIDR ну да ладно. Пусть будет так.Далее захожу в pod cilium агент'а который висит на том же хосте что и co
redns-f9fd979d6-4x7fq. И в cilium monitor наблюдаю:xx drop (Policy denied) flow 0x0 to endpoint 311, identity 6->9326168: 10.245.2.79:8920 -> 10.245.0.145:53 tcp SYN
identity 6 это reserved: remote-host
делаю трассировку политики для 6 => 932616
8 (https://pastebin.com/RLrKdAmQ)получаю denied.
Окей. Добавляю политику CiliumNetworkPolicy для label'а
reserved: remote-host : https://pastebin.com/jpKmrNNtВсе заработало.
Но меня смущают два момента:
1) Что network policy куба которое работало на других cni, в cilium теперь не работает. А чтобы оно работало пришлось добавить дополнитульную политику CiliumNetworkPolicy. В которой к тому же я не очень уверен
2) Меня смущает мое правило в CiliumNetworkPolicy. Я разрешил по сути с внутреннего адреса всех нод подключаться к подам из kube-system. Вроде ничего страшного, из других namespace доступ к kube-system не проходит. Но возможно тут могут быть какие-то проблемы и под reserved: remote-host попадет не то чему следует - может быть это паранойя.
И второй вопрос. Можно ли в hubble выводить identi
ty, чтобы потом смотреть по ним трассировки policy? А то получается сейчас я вижу например дропы пакетов в hubble. Но непонятно по какому правилу. И приходится потом идти в конкретный cilium агент на ноде и там через cilium monitor грепать ip адреса которые я словил в hubble и извлекать их identity для трасировки - как-то муторно
L
хотелось бы раздель один под, один контейнер, ибо количество контенейров будет расти
ну и зря
SP
ну и зря
а почему? разве не надо переобновлять под будет, если мне надо только один контейнер обновить?
L
а почему? разве не надо переобновлять под будет, если мне надо только один контейнер обновить?
конечно надо - но это не страшно. это хорошо. задоно и тег latest перестанешь использовать.
а ты прикинь что будет - пришел запрос на под с nginx, и nginx отправил его на под с нодежс. а этот под внезапно может оказаться на другом узле. и ты начнешь спрашивать про podAffinity, externalTrafficPolicy и прочие страшные вещи, чтобы убрать лишние сетевые задержки
а ты прикинь что будет - пришел запрос на под с nginx, и nginx отправил его на под с нодежс. а этот под внезапно может оказаться на другом узле. и ты начнешь спрашивать про podAffinity, externalTrafficPolicy и прочие страшные вещи, чтобы убрать лишние сетевые задержки
R
Самое трешовое название книги, которое я когда либо видел.Можно купить книгу онлайн или это рофл? Страшно представить что там внутри...
SP
конечно надо - но это не страшно. это хорошо. задоно и тег latest перестанешь использовать.
а ты прикинь что будет - пришел запрос на под с nginx, и nginx отправил его на под с нодежс. а этот под внезапно может оказаться на другом узле. и ты начнешь спрашивать про podAffinity, externalTrafficPolicy и прочие страшные вещи, чтобы убрать лишние сетевые задержки
а ты прикинь что будет - пришел запрос на под с nginx, и nginx отправил его на под с нодежс. а этот под внезапно может оказаться на другом узле. и ты начнешь спрашивать про podAffinity, externalTrafficPolicy и прочие страшные вещи, чтобы убрать лишние сетевые задержки
уффф, окей спасибо
DS
Всем привет. Раскуриваю кубер, поэтому есть пару вопросов, у кого есть время был бы рад если бы ответили. Есть схема. Нжинкс два контейнера с nodejs и база. Описал для каждого имейджа деплоймент и сервис. Поднял кластер. Какие еще ресурсы нужно поднять, чтобы нжинкс видел сервисы nodejs ? может есть какой бест практис или какой нибудь мануал пошаговый? А то у меня пока нжинкс ругается что не видит апстрим cas
upstream сas {
server cas-service:8001 ;
keepalive 1024 ;
}
upstream сas {
server cas-service:8001 ;
keepalive 1024 ;
}
а какую задачу в этой связке решает nginx?
SP
а какую задачу в этой связке решает nginx?
условно если запрос /api то жинкс отправлять на api контейнер, если /cas то на cas контейнер и так далее
DS
условно если запрос /api то жинкс отправлять на api контейнер, если /cas то на cas контейнер и так далее
эту задачу решает ingress-controller в гораздо более удобной форме
SP
эту задачу решает ingress-controller в гораздо более удобной форме
а можно пример? т.е. по факту нжинкс не нужен и хватит ingress-nginx?
SP
и как с сертификатами SSL в таком случае лучше разруливать
DS
а можно пример? т.е. по факту нжинкс не нужен и хватит ingress-nginx?
kind: Ingress
...
spec:
http:
paths:
- backend:
serviceName: api
servicePort: 3000
path: /api
- backend:
serviceName: cas
servicePort: 3000
path: /cas
DS
и как с сертификатами SSL в таком случае лучше разруливать
kind: Ingress
...
spec:
...
tls:
- hosts:
- example.com
secretName: tls-secret