вобщем вопрос остаётся. Чем же заменить 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-м порту, то может ли быть это причиной?

еще вопрос: запустил дашборд, не получаетсья авторизоваться. логи с пода 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

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

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

Нет

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

Я спрятал его за nginx-ингресом с сертификатом и всё взлетело

Я спрятал его за nginx-ингресом с сертификатом и всё взлетело

у меня просто за nginx пока

без авторизации - интерфейс отображаеться, но сделать в нет ничего нельзя ?

Привет, кто то использует Ранчер 2.0? Интересует возможность управления нескольких кластеров централизованно

Сходи к нему по https

Даже без ингресс там есть самоподписанные серты

У меня он в респонсе на логин ругался на то, что не секюрно к нему хожу

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

Так сервис не может пинговаться, это правило в iptables. Проверяй телнетом или неткатом на нужный порт

Так сервис не может пинговаться, это правило в iptables. Проверяй телнетом или неткатом на нужный порт

да, правил iptables нет, осталось понять почему

Прокси не работает,, он рулит созданием правил, а прокси в свою очередь на cni завязан, имхо такая связка га любой ноде

ERROR: S client not available

да, только он работает) но как-то спустя рукава

для этого создам правило, для того нет

для этого создам правило, для того нет

Проверь логи прокси, у него возможно прав нету на доступ к эндпоинтам api

а можо его как-то ребутнуть с помощью kubectl ? из последнего вижу только нечто про кэш

https://pastebin.com/jSBz7tp3

https://pastebin.com/jSBz7tp3

это весь лог пода kube-proxy

экспериментирую тут: 1) когда-то пару дней назад возможно криво создал деплоймент с сервисом (сервис без эндпойнта поднялся) с конкретным лэйблом и именем (пусть будет app1) 2) сегодня с таким же ровно конфигом только с другим лэйблом и именем (пусть будет app2) поднимаю деплоймент с сервисом - всё работает 3) пытаюсь по новой со старым лэйблом и именем - не работает, эндпойнт не назначается

где-то засел какой-то злобный кэш, видимо

и вот в kube-proxy, думаю, речь про него

экспериментирую тут: 1) когда-то пару дней назад возможно криво создал деплоймент с сервисом (сервис без эндпойнта поднялся) с конкретным лэйблом и именем (пусть будет app1) 2) сегодня с таким же ровно конфигом только с другим лэйблом и именем (пусть будет app2) поднимаю деплоймент с сервисом - всё работает 3) пытаюсь по новой со старым лэйблом и именем - не работает, эндпойнт не назначается

заметка ко второму пункту: не совсем с таким же ровно конфигом, а чуть подправленным, чтобы сервис нормально поднялся, а третий пункт уже с исправленным конфигом, но со старым именем сервиса и со старым лэйблом

что надо подредактировать, чтобы изменить --service-node-port-range ?

хочется по 443 до кластера стучаться

хочется по 443 до кластера стучаться

Ингресс

можно конкретней?

у меня есть nginx-ingress-controller , у него 443 мэпится на 30541

есть ingress для сервиса, там указан hostname + tls

стучусь к сервису как https://app.hostname.com:30541

Сервисы в режиме NodePort только 3хххх порты юзают, нужно поверх ingress ставить с ssl, чтобы по 443 к сервисам ходить

пытался у nginx-ingress-controller поменять nodePort на 443 - не вышло

А сервис ингресса запущен?

который за ingress'ом лежит? то есть backend для ингреса?

зы: могу тупить, ибо с кубом не так близко знаком

Ingress контроллер ставьте daemonset-ом и ему давайте host network

Буклет слушать на 80 и 443

*будет

сейчас состояние вот такое nginx-ingress-controller LoadBalancer 10.106.253.138 <pending> 80:32445/TCP,443:31374/TCP 5d nginx-ingress-default-backend ClusterIP 10.106.71.165 <none> 80/TCP 5d

спасибо!

попробую

Я короче по этой схеме ставил - https://kubernetes.github.io/ingress-nginx/deploy/#baremetal Взлетело....

гранд мерси

там кроме контроллера и дефолтного бэкенда нужно еще сам инжинкс пустить