похоже, что сразу

печаль

как оверлейная сеть может быть проще чем не-оверлейная сеть?

я так понимаю flannel в kubeadm по дефолту, и скорее всего по причине простоты/простаты кому как нравится )))

а не калико?

хз, никогда не юзал kubeadm

я так понимаю flannel в kubeadm по дефолту, и скорее всего по причине простоты/простаты кому как нравится )))

я ставил калико-) в адм я вообще фланнел не увидел, и я против всякого kubeadm

в кубадм вообще нет дефолта, он не ставит сеть

calico 👍

в кубадм вообще нет дефолта, он не ставит сеть

ага Set /proc/sys/net/bridge/bridge-nf-call-iptables to 1 by running sysctl net.bridge.bridge-nf-call-iptables=1 to pass bridged IPv4 traffic to iptables’ chains. This is a requirement for some CNI plugins to work, for more information please see here. @alchazov вот это запилил?

ага Set /proc/sys/net/bridge/bridge-nf-call-iptables to 1 by running sysctl net.bridge.bridge-nf-call-iptables=1 to pass bridged IPv4 traffic to iptables’ chains. This is a requirement for some CNI plugins to work, for more information please see here. @alchazov вот это запилил?

Да. 1 в параметрах

нужен совет по обновлению деплоя. Текущий пайплайн реализован так: 1. Обновляем образ: kubectl set image deploy/app app=appimage:newtag 2. Ждём статуса kubectl rollout status deploy/app 3. Если статус Completed - завершаемся 4. Если статус Failed - kubectl rollout undo deploy/app Теперь мне надо вставить в пайплайн миграции, которые могут быть несовместимы с текущей версией. Соответственно я предполагал сделать так: 1. Выключаем деплой масштабированием в 0: kubectl scale deploy/app —replicas=0 2. Делаем бэкап базы 3. Делаем миграции 4. Обновляем образ: kubectl set image deploy/app app=appimage:newtag 5. Включаем деплой масштабированием в 1 (далее hpa поднимет выше, если надо): kubectl scale deploy/app —replicas=1 6. Проверяем статус ???? 7. Если всё хорошо, завершаемся 8. Если всё плохо, проворачиваем назад Вопрос возникает на шаге 6: я уже не могу использовать rollout status, потому что при количестве реплик 0 он сразу возвращает Completed

но ведь это же с даунтаймом?

да, даунтайм приемлем

и если ты сделаешь руками scale 0 то HPA тебе вернёт обратно до минимального

нет

у меня возвращал

кубер 1.8

а у меня не возвращает

https://github.com/kubernetes/kubernetes/pull/29212/commits/c5e82a01b15136141801ba93de810fdf3165086b

прикольно тебе

вообще не возвращает или какое-то время?

вообще

это новая фича hpa

хм

написано в 2016 замёржено

у вас наверное уже тоже не возвращает - легко проверить

я минут 5 назад проверил

kubectl describe hpa ... ... ScalingActive False ScalingDisabled scaling is disabled since the replica count of the target is zero

вобщем вопрос остаётся. Чем же заменить rollout status? Ну или как делать scale+set image атомарно, чтоб rollout начался по честному

как вариант, можно один под вне деплоя запустить, с restart=Never, наверное, и посмотреть, как оно

чёт я теряюсь

Да. 1 в параметрах

видимо какая то хрень с iptables после сброса правил - все завелось только сейчас вопрос: как правильно настроить правила в фаерволе 🙁 systemctl stop kubelet systemctl stop docker iptables --flush iptables -tnat --flush systemctl start kubelet systemctl start docker

вобщем вопрос остаётся. Чем же заменить rollout status? Ну или как делать scale+set image атомарно, чтоб rollout начался по честному

кажется, нашёл решение. через patch можно сделать атомарно replicas=1 и image=new

А почему сначала кубелет, а потом докер запускаешь?

Выглядит мегакостыльно, может лучше сразу научить девелоперов делать 3 step migrations?

Бекап базы, рестор, даунтайм вот это всё

А если ошибка при ресторе базы то что делать? И ещё куча подобных вопросов

господа, а как использование дисков конкретными подами мониторить? с местом разобрался, а вот IOPS не знаю, как получить

Выглядит мегакостыльно, может лучше сразу научить девелоперов делать 3 step migrations?

нет. даунтайм дешевле. А ошибки в любом случае обрабатывать надо.

А если ошибка при ресторе базы то что делать? И ещё куча подобных вопросов

маловероятно с правильным подходом

опять же, ошибки надо обрабатывать

помогите советом: есть два деплоймента (postgresql, httpd) и сервисы под оба деплоймента, для postgresql (port 5432) назначается endpoint, для httpd (port 80) - нет. куда копать?

селекторы проверь у сервиса

кофиги идентичны, только name и label отличаются

еще вопрос: запустил дашборд, не получаетсья авторизоваться. логи с пода 2018/07/13 15:07:25 [2018-07-13T15:07:25Z] Outcoming response to 10.244.0.1:56022 with 200 status code 2018/07/13 15:07:25 [2018-07-13T15:07:25Z] Incoming HTTP/1.0 GET /api/v1/login/status request from 10.244.0.1:56028: {} 2018/07/13 15:07:25 [2018-07-13T15:07:25Z] Outcoming response to 10.244.0.1:56028 with 200 status code 2018/07/13 15:07:25 [2018-07-13T15:07:25Z] Incoming HTTP/1.0 GET /api/v1/csrftoken/login request from 10.244.0.1:56030: {} 2018/07/13 15:07:25 [2018-07-13T15:07:25Z] Outcoming response to 10.244.0.1:56030 with 200 status code 2018/07/13 15:07:25 [2018-07-13T15:07:25Z] Incoming HTTP/1.0 POST /api/v1/login request from 10.244.0.1:56036: { "kubeConfig": "", "password": "", "token": "...", "username": "" } 2018/07/13 15:07:25 [2018-07-13T15:07:25Z] Outcoming response to 10.244.0.1:56036 with 200 status code 2018/07/13 15:07:26 [2018-07-13T15:07:26Z] Incoming HTTP/1.0 GET /api/v1/login/status request from 10.24

селекторы проверь у сервиса

ну и селекторы тоже

a readiness probe под проходит?

то есть успевает ли у pod наступить статус Ready=true ?

a readiness probe под проходит?

почитал доки, надо попробовать, спасибо за наводку

Если readiness probe не наступает, в какую сторону дальше копать? Сам сервер внутри пода работает, если что: wget http://localhost/test_file отдаёт файлик

Если readiness probe не наступает, в какую сторону дальше копать? Сам сервер внутри пода работает, если что: wget http://localhost/test_file отдаёт файлик

Может, порт на локалхост у него биндится

Извне его помучай, из другого пода там

Так postgresql точно так же поднял - работает

Извне его помучай, из другого пода там

Не пингуется

Но nslookup выдаёт инфу по хостнэйму

Ты запрос на сервак сам извне сделай

Из другого пода ничего не увидишь если он нот реди

Попробуй тот же контейнер запусти локально и извне контейнера дернуть урл

Ты запрос на сервак сам извне сделай

Не запрашивается, в том то и дело, ибо endpoint пустой

Из другого пода ничего не увидишь если он нот реди

Дык это, вроде же имена подов тоже резолвятся

Я это имел ввиду

А причина непонятна

Или по ip его, не суть важно

Или по ip его, не суть важно

ClusterIP ?

Да

Не пингует)

Вгетом запрос

То же самое

Вооо

причина?)

Кривая конфигурация сервера, который слушает на loopback-интерфейсе

Хм

То есть смотреть в сам докер-образ?

В конфиг сервака, с которого ты получаешь файло

создал под на основе другого образа (nginx) - поведение такое же. НО: из другого пода мой таргет-под пингуется по IP пода (192.168.77.52), по ClusterIP (10.101.201.233) пинга нет, nslookup резолвит сервис по имени и даёт ClusterIP

ClusterIP - это адрес сервиса

Бери адрес пода

теперь задача: есть сервисА, и ему надо видеть nginx по хостнейму, для этого поднимаю service для nginx-пода, но пинга нет

или мне сервис не нужен для этих целей?

вопрос: а если ужо есть системный (kube-system) сервис на 80-м порту, то может ли быть это причиной?