Я просто смотрю в релизах. Там последняя версия kubespray 2.6.0 и в Component Versions обозначен Kubernetes 1.10.4

берите master, всегда так делаю (с)

берите master, всегда так делаю (с)

Опасно же :)

Опасно же :)

из мастера не деплоить, в продакшн не ходить (с)

ну обычно пинится git commit, клонится, собирается контейнер с определенным лейблом, проходит CI, промоутится и из него идет деплой на продакшн

ну в теории можно конечно ... env: - name: foobar value: | some crazy shit ...

А енв фром файл можно делать? А там тянуть значения с сикретов

какая разница, переменные окружения могут быть только строками

Как обычная строка сможет вытянуть с сикретов?

что?

Вытянуть переменнные коннекта к бд

а приложение - твоё приложене или какое-то готовое?

Я пулю официальный образ

кого?

Призму

?

Лунная призма дай мне сил.

Хотя я же могу задать енвы следующим образом Env - name Prisma_config.databases.default - value

?

?

А как еще?)

- name: name value: value

Env: Env

- name: name value: value

Ну, да, я это имел в виду. Только значение name будет в одну строку без какого-либа читабельного формата (как в докер компоузе)

да сделай в читабельном, это всё равно будет строка

А кто может напомнить куда мне пойти, если я хочу перед деплоем проверять что в манифесте не больше N replicas, лимиты выставлены, в аннотациях нужные записи и т.д.

Я помню что это можно делать на стороне кубера

Я помню что это можно делать на стороне кубера

не пропускать такой комит через code review ?

А кто может напомнить куда мне пойти, если я хочу перед деплоем проверять что в манифесте не больше N replicas, лимиты выставлены, в аннотациях нужные записи и т.д.

kubetest?

А кто может напомнить куда мне пойти, если я хочу перед деплоем проверять что в манифесте не больше N replicas, лимиты выставлены, в аннотациях нужные записи и т.д.

https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/

Привет. А есть какой-либо способ протестировать перед запуском пода, что конфиг не просто валидный, а обозначенные в конфиге ресурсы реально присутствуют, например что получится подмонтировать волюм?

не пропускать такой комит через code review ?

У меня 300 разрабов, хочу чтобы что-то катали сами, но страдать по их вине не хочу :)

kubetest?

Посмотрю что за зверь. Спасибо

https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/

Похоже да. Спасибо!

Теперь боты по трое ходят?

я не бот

на всякий )

100% должен быть же "adwords" для telegram на основе таких ботов. Кто-то сталкивался?

я не бот

главное не предлагай зарабатывать по $100 в день =)

Ребят, все еще разбираюсь с зависаниями при запросах через ingress. Сейчас вот такая ситуация: Дергаю курлом с мастера поды по их IP и по IP сервиса отвечают. Параллельно дергаю через ingress, таймаут 504. Повторяется не всегда, но часто. Что может быть? куда смотреть? Сеть calico, kubernetes 1.11.2

Ребят, все еще разбираюсь с зависаниями при запросах через ingress. Сейчас вот такая ситуация: Дергаю курлом с мастера поды по их IP и по IP сервиса отвечают. Параллельно дергаю через ingress, таймаут 504. Повторяется не всегда, но часто. Что может быть? куда смотреть? Сеть calico, kubernetes 1.11.2

сбоит только одна из нод, проверяй по ip подов в репликасете

я не бот

Точно бот

сбоит только одна из нод, проверяй по ip подов в репликасете

Если говорить о подах приложения, то я дергаю оба пода по их IP + IP сервиса.

и с обоих подов приходит 504 ?

и с обоих подов приходит 504 ?

Если дергаю курлом то отвечают оба. Ошибка 504 не постоянная, просто время от вермени, но воспроизвести ее не сложно. 504 бывает как с одного так и с другого пода

А у вас ингресс смотрит в поды или в сервис?

А у вас ингресс смотрит в поды или в сервис?

в сервис

Т.е включена аннотация сервисе-апстрим?

В ингрессе

Сейчас сделал следующее. Запустил в контейнере ингресса команду: "watch -n 1 "curl 10.233.100.91:1000 && curl 10.233.110.241:1000 && curl 10.233.47.52:80"" первые 2 это IP подов, третий это IP сервиса. И параллельно дернул запрос курлом с мастера. Курл с мастера повис, а курлы в контейнере ингресса работали как часики. Я кажется схожу с ума)

Т.е включена аннотация сервисе-апстрим?

spec: rules: - host: %myhost% http: paths: - path: /images/ backend: serviceName: images-service servicePort: 80

Вот так у меня в ингрессе

А кто может напомнить куда мне пойти, если я хочу перед деплоем проверять что в манифесте не больше N replicas, лимиты выставлены, в аннотациях нужные записи и т.д.

Официально validating admission plugin (можно вебхук, например в open policy agent). Но я у себя все на стороне CI добавляю/проверяю (через jsonnet)

Вот так у меня в ингрессе

https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/nginx-configuration/annotations.md#service-upstream

Привет. А есть какой-либо способ протестировать перед запуском пода, что конфиг не просто валидный, а обозначенные в конфиге ресурсы реально присутствуют, например что получится подмонтировать волюм?

Это как проверять, что есть файл перед открытием. Вроде логично, но лучше так не делать ,ибо гарантий все равно нет , пока необходимое действие не сделаешь, все равно до конца не знаешь, получится ли

https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/nginx-configuration/annotations.md#service-upstream

Добавил аннотацию: nginx.ingress.kubernetes.io/service-upstream: true сейчас буду тестить

https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/nginx-configuration/annotations.md#service-upstream

Перестал работать rewrite. Они несовместимы?

у меня стоит там: nginx.ingress.kubernetes.io/rewrite-target: /

Это как проверять, что есть файл перед открытием. Вроде логично, но лучше так не делать ,ибо гарантий все равно нет , пока необходимое действие не сделаешь, все равно до конца не знаешь, получится ли

Допустим, девелоперы на стейджинге проверяют, триггеря джобу. Но при выкатке на прод триггерить джобу раньше установленного времени нежелательно, остается только ждать что оно успешно отработает в какое-то назначеное время. Может быть, такие проблемы предотвращать надо иначе?

https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/nginx-configuration/annotations.md#service-upstream

Получилось, в итоге заюзать и эту пропертю. Но без эффекта(

Решил поснимать tcpdump на tunl0 и нашел странное. В том случае когда случается таймаут, на самом деле ответ приходит, только битый. Без HTTP заголовков и вообще без начала ответа. В случае когда таймаута не случилось, они соответственно есть. Причем когда случается таймаут, в tcp дампе на ноде с подом, я вижу что из пода вышли все нужные пакеты, а вот в дампе этого же запроса, но уже на ноде с ingress, я вижу что дошли не все и куска от начала ответа нет. Господа, посоветуйте, чего хоть делать? Кластер деплоил с нуля через kubespray. Сеть calico. Почти все настройки kubespray по дефолту, уж что касается сети, точно по дефолту. На самих серверах никаких изменений не вносилось ни в настройки сети, ни в iptables правила.

Снял еще tcpdump с eth0 интерфейса на ноде с подом. С пода через tunl0 ответ выходит нормальный, а вот через eth0 идет уже битый. Т.е теряется где то между tunl0 и eth0.

сама-то tcp сессия нормальная?

мож перетюнили или недотюнии, tcp_reuse какой-нить есть...

ну или на сетевом оборудовании что...

Допустим, девелоперы на стейджинге проверяют, триггеря джобу. Но при выкатке на прод триггерить джобу раньше установленного времени нежелательно, остается только ждать что оно успешно отработает в какое-то назначеное время. Может быть, такие проблемы предотвращать надо иначе?

Можно допилить в джобу --dry-run ,чтобы оно все отработало, но результат не записало никуда

мож перетюнили или недотюнии, tcp_reuse какой-нить есть...

Вообще все настройки системы по дефолту, сверху kubespray свои накатывал. Причём проблема проявляется как на версии кубера 1.10.х так и на 1.11.х. Только вчера пересетапил. В оборудовании проблема врядли может быть, у меня пакеты получается теряются между tunl0 и eth0 в рамках одного сервера. Т.е с пода выходит ответ нормальный, я его вижу на tunl0, а уже в сеть на eth0 идёт обрубок без начала ответа.

мб, глупость скажу, но, мб, проблемы с mtu на интерфейсах?

Вообще все настройки системы по дефолту, сверху kubespray свои накатывал. Причём проблема проявляется как на версии кубера 1.10.х так и на 1.11.х. Только вчера пересетапил. В оборудовании проблема врядли может быть, у меня пакеты получается теряются между tunl0 и eth0 в рамках одного сервера. Т.е с пода выходит ответ нормальный, я его вижу на tunl0, а уже в сеть на eth0 идёт обрубок без начала ответа.

у меня с calico была хрень при ipip включенном и мисматче mtu - терялось все при передаче из физической карты в tunl

у меня с calico была хрень при ipip включенном и мисматче mtu - терялось все при передаче из физической карты в tunl

У меня похоже обратная ситуация, из tunl0 в физическую. А может проблема с MTU так проявляться вообще? У меня бьется примерно каждый 20й запрос, если дергать постоянно. А если оставить в покое минут на 10 например, то первый запрос 100% будет битый.

https://docs.projectcalico.org/v2.5/usage/configuration/mtu

у меня проявлялась проблема с mtu в связке kubernetes (flannel) + gitlab-omnibus + gitlab-runner (докер в докере). необходимо было выставлять всем контейнерам mtu 1450 потому что flannel режет до 1450

проблема была при закачке по https и просто при обращении по https

проблема была при закачке по https и просто при обращении по https

А проблема была постоянная? или плавающая?

постоянная

по идее, откинув все, там где есть туннели, там всегда меняется mtu

и надо выставлять ниже

netstat -i , собственно

ну то, что mtu разное - видно (:

у меня после мытарств вот такая картина

но лучше про calico еще почитать что там и как

https://docs.projectcalico.org/v2.5/usage/configuration/mtu

уже кидали эту ссыль

если ipip не используешь, у тебя mtu в calico должен быть тот же что и на интерфейсе

непонятно почему на eth0 он маленький

непонятно почему на eth0 он маленький

так устанавливает хостер при создании машины. У меня вирты.

У calico, вроде, была крутилка для mtu для интерфейсов.

Кстати, если на eth0 1450 - на туннельном должно быть что-то типа 1390