Деплой и инфра
K8s objects: тест на воспроизведение
Воспроизведение бьёт перечитывание. На каждый промпт скажите или запишите полный ответ по памяти, прежде чем открыть модельный — реконструкция механизма закрепляет его так, что он всплывёт, когда вы будете смотреть на сломанный раскат в 2 часа ночи.
Восстановите ключевые механизмы юнита — reconciliation loop, иерархию объектов, селекторы Service, readiness против liveness, распространение ConfigMap/Secret и requests против limits — не подглядывая в урок.
- 01Почему Deployment самовосстанавливается после отказа узла, а голый Pod — нет?
- 02Опишите иерархию Pod → ReplicaSet → Deployment — какую единственную задачу добавляет каждый слой?
- 03Как Service узнаёт, на какие поды маршрутизировать, и каков режим отказа при пересекающихся метках?
- 04Сравните readiness, liveness и startup probes — какой гейтит трафик и каков классический отказ?
- 05Почему обновление ConfigMap или Secret не катит потребляющие их поды и как команды форсируют обновление?
- 06Объясните разницу между resource requests и limits и почему CPU и память ведут себя по-разному на лимите.
Если вы смогли восстановить каждый ответ по памяти, вы держите хребет юнита: контроллеры вечно reconcile объявленное состояние (поэтому Deployment самовосстанавливается, а голый Pod нет), иерархия добавляет по задаче на слой (Pod гоняет, ReplicaSet считает, Deployment катит), Service привязываются к подам по метке без знания о владении, readiness гейтит трафик, liveness перезапускает, а startup покрывает медленный старт, изменения ConfigMap/Secret никогда не катят автоматически — потому их хешируют в аннотацию, а ресурсы делятся на троттлящийся CPU и OOMKill-память. Именно к этим семантикам сводится любой инцидент K8s в этой области.