они были девственно чисты

случайно обнаружил что DNS не работает только у подов на определенной Ноде
потом я начал читать документ
https://aws.amazon.com/ru/premiumsupport/knowledge-center/eks-dns-failure/
и вот пункт 3
3. Verify that the pods aren't blocked by a security group or network access control list (network ACL) when communicating with CoreDNS.

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

ну, поздравляю:) юзайте терраформ чтобы не было подобных сюрпризов

каким это образом юзание терраформ избавляет от того что "коллеге надо было настроить SG"? и "он настроил"? ;)
ну сделал бы он тоже самое через терраформ, хотя наверное да, избавляет. там думать надо а не кнопки в UI нажимать...

Подразумевалось, наверное, что чейнджи мержатся в мастер через ревью)

А уже из мастера все как то катается на инфраструктуру

;))) ну да, атлантис plan + apply
совет хорош, я тоже такие советы всем даю ;)

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

ну очевидно же что не спасает полностью, хотя конечно бардак превращается в автоматизированный бардак ;)
- кто-то, кто мог бы подсказать, не смотрит ревью (скидывает все письма на ревью в отдельную папку)
- есть side effects которые на ревью невозможно просчитать тупо в голове, даже смотря в terraform plan ;)
- terraform не контролирует весь life cycle особенно в динамических сущностях типа "группа нод с автоскейлингом"

в данном случае есть 2 варианта:
1) автор внес изменения под тф. тогда греп по коду. ревьюить все невозможно, но у кода хотя бы можно "спросить" по ключевым словам. это повышает шансы на получение знаний и уменьшает время дебага
2) автор не внес изменения под тф.
2.1) объект управляется тф. тогда план покажет дифф. сразу все наглядно
2.2) объект для тф неизвестен
тут мы пришли к существующей ситуации. и в ней мы можем бить линейкой по рукам автору. раз не внес, два не внес, депремирование, штраф, увольнение. если человек адекватный - таких ситуаций должно быть минимум. Понятное дело что тф полностью проблему не решает

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

хотя тот же тф например не умеет в вмваре контролировать стейт "вм должна быть включена"

дичь? дичь...

это не TF ;) это провайдер =)
скорее всего там просто тупо саппортить некому
или VMWare не отдает по API через которое provider работает, current state ;)

ну вообще отдает, да

19

есть подозрение что нужно гнать этого мастера метлой, или я не прав?

Ну если только спецом не задать овервольтаж и частоту

без овервольтажа, какая нибудь CUDA может карту попалить

температурный режим могли не выдержать - если ноут на подушке держать и нагружать по-полной, например долго

овервольтаж не задавали. Ноутбук 2010 года выпуска