ну ты чего, опять ленишься загуглить kubernetes service type: nodeport?

«Эксперты RedLock обнаружили, что облачная AWS-инфраструктура компании Tesla использовалась злоумышленниками для майнинга криптовалюты Monero. Неизвестные сумели проникнуть в облако компании, обнаружив учетные данные в консоли Kubernetes. » GOD I FUCKEN LOVE THIS FUTURE

обьясните как это работает. Не оч понял про какую консоль речь и как к ней получен был доступ

если вон сайт astra linux имел на сайте уязвимость к sql инъекции и ее даже за пару дней не заметили, вернее не заметили как была активность по имитации скачки базы

сайт астры на шаред-хостинге

https://blog.redlock.io/cryptojacking-tesla здесь чуть понятнее написано

xaxaxa.eu

лол, что это?

И кстати, я вот столкнулся с тем, что eu может регнуть только житель Европы или же компания, которая зарегистрирована в Европе. Как-то так...

И кстати, я вот столкнулся с тем, что eu может регнуть только житель Европы или же компания, которая зарегистрирована в Европе. Как-то так...

Подскажите, какой самый простой способ получить доступ к сервису в k8s, если машинка никак не связана с кластером, но в одной локалке с ним? Желательно по внутреннему DNS-имени.

А как taints работают? Был тестовый кластер из одной ноды, решил к нему воркеров докинуть, а первую вернуть taint что она мастер. # kubectl taint nodes <node> node-role.kubernetes.io/master:NoSchedule error: at least one taint update is required

ктто нибудь сталкивалася с тем что встроенные днс сервера кубернета не резолвят ничего из внешних сервисов(google.com ya.ru) только внутренние?

ктто нибудь сталкивалася с тем что встроенные днс сервера кубернета не резолвят ничего из внешних сервисов(google.com ya.ru) только внутренние?

врчную добавлял в него nameserver гугла?

у хоста свои внутренние днсы бинда

У нас калико, а хотелось бы бгп

Я б посмотрел в то, что взяли в cncf

Скорее всего это верно и для обновления в рамках деплоймента: When a user requests deletion of a pod the system records the intended grace period before the pod is allowed to be forcefully killed, and a TERM signal is sent to the main process in each container. Once the grace period has expired the KILL signal is sent to those processes and the pod is then deleted from the API server. https://kubernetes.io/docs/concepts/workloads/pods/pod/ проще всего просто проверить микроприложением, которое ловит сигналы и пишет все в лог

Господа, есть где почитать как конкретно происходит убиение поды при rolling update? Какие сигналы процессу отправляются, сколько кубер ждет и после чего и тд? Задача - сделать zero-downtime deployment для http-сервиса с длинными подключениями (загрузка больших файлов)

Кстати, в их случае правильной стратегией было бы пилить правильный handover WS-подключений на живые поды. Это скорее всего геморр с точки зрения разработки, но оставлять клиентов висеть на старых версиях с учетом того, что конекшн может жить по 2 дня - тоже не айс

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

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

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