Остальное честно говоря я не понял
Очень жаль
George
Rainbow
Просто этот чел уже реально за* - эта группа по решению проблем или не понимания - не все такие спецы как не крути)
Я написал. cronjob и deployment разные вещи, никак не связанные.
Rainbow
Вопрос звучит так как будто ты в crontab на обычном linux засунул systemd start myservice и удивляешься, что он постоянно пытается запускаться.
"не пойму в чем разница между crontab и systemd"
Puma
да надо в crontab @reboot засовывать )))
Alex
это чятик про поболтать, тебе никто не обязан решать твои проблемы, если ты сам не пытаешься разобраться
я разве заставляю какой либо решать мои проблемы - не хочешь не пиши/не трать на это время и т/д/ - добровольно - для кого то это очевидно/для меня нет - поможешь советом - респект, не поможешь и на том спасибо
Andor
Andor
тебе как бы сразу намекнули что cronjob и deployment это разные штуки
Andor
с разными контроллерами
Vadim
народ а среду для тестирования и разработки принято в кластере прода делать отдельными неймспейсами, или лучше отдельно вообще?
Andor
как ты на проде будешь тестировать обновление кубера?
Vadim
точняк
Vadim
тогда 2 кластера? прод и кластер для тестирования и разработки приложений?
Andor
но точно отделить прод от не-прода
Vadim
1 прод, 1 тестирование кубера, 1 тестирование\разработка приложений, 1 при необходимости нагрузочный
Denis
Vadim
а bare-metal стоит вообще использовать?
Puma
Зависит от количества денег и нужных ресурсов
Solyar
У нас тест, стейдж, стейбл, прод
Solyar
4 кластера
George
Зависит от задач и возможностей
George
Нам проще было на вм
Vadim
по сути если нужны ноды с мощностью всего физического сервера то можно bare-metal ?
Andor
Никто не говорит что барметал не нужен
Andor
Вопрос в задачах и ресурсах
Andor
При разных
Andor
У тебя-то какие?
Vadim
думаю 2 дмз зоны, 1 внутренняя, в каждой зоне по 1 мастеру и 2 воркер нодам, в дмз зонах адаптеры к внешним системам, во внутренней весь бизнес функционал.
Vadim
о применении bare-metal кроме контекста необходимой мощности каждой ноды не знаю причин их использовать, типо если все равно надо все ресурсы под ноду отдавать то нет смысла промежуточный слой городить
Vadim
но мне мощность всей физической тачки под ноду не нужна значит и bare-metal не подходит
Denis
думаю 2 дмз зоны, 1 внутренняя, в каждой зоне по 1 мастеру и 2 воркер нодам, в дмз зонах адаптеры к внешним системам, во внутренней весь бизнес функционал.
У вас какие-то свои площадки с цодами?
Отделение Bereke Bank
о применении bare-metal кроме контекста необходимой мощности каждой ноды не знаю причин их использовать, типо если все равно надо все ресурсы под ноду отдавать то нет смысла промежуточный слой городить
Виртуалки проще мигрировать. Поэтому в любом случае лучше резать физику на виртуалки
Vadim
Ilya
Привет. Может кто-то прояснить следующий вопрос, сделал readinessprobe readinessProbe:
httpGet:
path: /template/info/1
port: 8080
httpHeaders:
- name: Custom-Header
value: Awesome
initialDelaySeconds: 10
periodSeconds: 3
в выводе kubectl describe pod выдает unhealthy, но если посылаю запрос извне на сервис через nodeport, то выдает нужный мне результат,
и еще вопрос, разве если проба не срабатыват должен ли сервис на неё подавать трафик? у меня получается так, что под unhealthy но могу обращаться к сервису через nodePort извне
Andor
Виртуалки проще мигрировать. Поэтому в любом случае лучше резать физику на виртуалки
А ещё можно не мигрировать, тогда вирталки не приносят пользу
George
Виртуалки проще мигрировать. Поэтому в любом случае лучше резать физику на виртуалки
Воркеры мигрировать смысла нет
George
Мастера - да
Anonymous
Выбор в пользу бм скорее возникает изза необходимости объединения непосредственно локальных площадок, когда невыгодно/нельзя гнать траффик через облако и когда требуется развертывание какогото «тяжелого» по на месте.
Anonymous
Ведь скоп решаемых задач не только веб и цепочки CI
Anonymous
К примеру я лет н назад очень радбыбыл Куберу вместо VMware esx
Vadim
Виртуалки проще мигрировать. Поэтому в любом случае лучше резать физику на виртуалки
что достойный дон собрался мигрировать на мастерах\воркерах?
Andor
что достойный дон собрался мигрировать на мастерах\воркерах?
ну контейнеры же лайв миграция между хостов
чо, кубер не умеет это что ли?
Andor
нет пусть оно само
Warrax
ну контейнеры же лайв миграция между хостов
чо, кубер не умеет это что ли?
оно не лайв, контейнер убьют в одном месте и запустят в другом
Отделение Bereke Bank
что достойный дон собрался мигрировать на мастерах\воркерах?
я имел ввиду не только мастера/воркеры. В целом виртуалку со всем ее содержимым в случае чего мигрировать проще чем физ сервер
George
я имел ввиду не только мастера/воркеры. В целом виртуалку со всем ее содержимым в случае чего мигрировать проще чем физ сервер
Только зачем это, если кубер сам за это отвечает ?
George
Это примерно как опенвпн тсп внутри опенвнп тсп гонять
Vadim
я имел ввиду не только мастера/воркеры. В целом виртуалку со всем ее содержимым в случае чего мигрировать проще чем физ сервер
если ты собрался просто так двигать виртуалки то сразу почитай как сертификаты перевыпускать
Anonymous
Кстати кто-то делал ротацию сертификатов мастера?
kredeal
Отделение Bereke Bank
Это примерно как опенвпн тсп внутри опенвнп тсп гонять
доводилось openvpn tcp внутри ssltunnel гонять, когда в КЗ блочили трафик openvpn-ов 😞
Anonymous
Да или проброс pptp через IPSec тоже потому-то блочат
Denis
Привет. Может кто-то прояснить следующий вопрос, сделал readinessprobe readinessProbe:
httpGet:
path: /template/info/1
port: 8080
httpHeaders:
- name: Custom-Header
value: Awesome
initialDelaySeconds: 10
periodSeconds: 3
в выводе kubectl describe pod выдает unhealthy, но если посылаю запрос извне на сервис через nodeport, то выдает нужный мне результат,
и еще вопрос, разве если проба не срабатыват должен ли сервис на неё подавать трафик? у меня получается так, что под unhealthy но могу обращаться к сервису через nodePort извне
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-a-liveness-command
Ilya
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-a-liveness-command
Т.е. нужно одновременно использовать liveness и readiness probe?
Denis
Т.е. нужно одновременно использовать liveness и readiness probe?
liveness - проверка на живучесть пода.
readiness - проверка для того, что бы знать когда на под можно пускать трафик
Denis
liveness - проверка на живучесть пода.
readiness - проверка для того, что бы знать когда на под можно пускать трафик
This page shows how to configure liveness and readiness probes for Containers.
The kubelet uses liveness probes to know when to restart a Container. For example, liveness probes could catch a deadlock, where an application is running, but unable to make progress. Restarting a Container in such a state can help to make the application more available despite bugs.
The kubelet uses readiness probes to know when a Container is ready to start accepting traffic. A Pod is considered ready when all of its Containers are ready. One use of this signal is to control which Pods are used as backends for Services. When a Pod is not ready, it is removed from Service load balancers.
Ilya
Да, я читал это, поэтому я и задал вопрос, потому что не понимаю, как readiness не проходит, а трафик на под все равно идёт
ᴅⁱᵐⁱᴅʳ0ˡ
ребят, как можно сбросить счетчик рестартов на поде?
V 🏴☠️
Удалить под
ᴅⁱᵐⁱᴅʳ0ˡ
не вариант
Denis
ᴅⁱᵐⁱᴅʳ0ˡ
1
ᴅⁱᵐⁱᴅʳ0ˡ
))
Denis
))
А на твой вопрос ответ: никак, кроме как kubectl delete pod, ну или в etcd наверное можно поправить😁Но я бы не советовал)))
V 🏴☠️
Вообще весь смысл этого всего, что можно удалять поды как попало
V 🏴☠️
Оно само должно тут же ожить
Vadim
почему нода в статусе ready, а при обращении к поду, допустим лог посмотреть, пишет
connect: no route to host
Denis
почему нода в статусе ready, а при обращении к поду, допустим лог посмотреть, пишет
connect: no route to host
Зайти на воркер и посмотреть лог kubelet.