Что будет происходить при kubectl apply

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

Короче, представь: у тебя есть кластер — этакий зоопарк из подов, деплоев и прочей живности. И есть у тебя бумажка, манифест, где нарисовано, как всё должно быть. И вот ты командуешь: «apply!». И эта команда, ёпта, начинает сравнивать то, что есть в реале, с тем, что нарисовано в твоей бумажке.

Как она работает, если по-простому:

1. Ресурса нет? Ну, всё просто — создаётся. Как будто ты принёс в зоопарк нового жирафа по имени deployment.yaml. kubectl apply -f deployment.yaml — и готово, жираф на месте.
2. Ресурс УЖЕ есть? Вот тут начинается самое интересное. Она не тупо всё перетирает, а пытается быть умной. Смотрит: «Так-так, у этого существующего деплоя было два реплики, а в новой бумажке — четыре. Ладно, апдейтну». Она вносит только те изменения, которые ты указал. Но, внимание, не всё можно так просто поменять! Некоторые вещи, особенно в Pod'ах, после создания становятся immutable, то есть неприкосновенными. Попробуй поменять — получишь ошибку, и будешь сидеть с круглыми глазами, думать: «Какого хуя?».

А главный фокус — в аннотации. После каждого успешного apply команда оставляет метку, типа граффити на стене: kubectl.kubernetes.io/last-applied-configuration. Это типа записка: «А помнишь, чувак, в прошлый раз ты хотел вот так?». И когда ты приходишь снова с новой версией манифеста, kubectl смотрит на три вещи:

• Что было (записано в той аннотации).
• Что есть сейчас в кластере (вдруг кто-то ручками через kubectl edit что-то подкрутил).
• Что ты принёс нового.

И на основе этого тройного сравнения (three-way merge) решает, что именно менять. Это чтобы, если ты, например, убрал какое-то поле из манифеста, оно удалилось из конфига в кластере, а не осталось висеть мёртвым грузом.

Нюансы, от которых волнение ебать:

• Тонкий лёд. Если ты не понимаешь, как работает merge, можно нечаянно откатить чьи-то ручные правки. Вы там ходите по охуенно тонкому льду, когда одновременно и apply и edit используете.
• Не всё можно. Я уже говорил — некоторые поля Pod'ов, особенно в spec’е, после создания — всё, приехали. Чтобы их поменять, часто надо удалять ресурс и создавать заново. apply тут бессилен, хоть ты тресни.
• Доверия ебать ноль к консистентности. Если ты применяешь манифест, а потом кто-то лезет и меняет что-то через kubectl patch или прямо в API — в следующий раз apply может выдать совершенно неожиданный результат. Потому что его «записка» (аннотация) уже не отражает реальность.

Так что запомни: kubectl apply — это не волшебная палочка «сделай красиво». Это инструмент, который пытается быть умным, но требует от тебя понимания, как он работает. А то будет тебе не хиросима, а настоящий нагасаки в кластере. Используй с умом, и проверяй, что собираешься применить, командой kubectl diff -f file.yaml, прежде чем делать apply. Сэкономит кучу нервов.