Писал ли чарты для Kubernetes

Что проверяют

Умеете ли вы довести свой сервис до кластера сами, без отдельного инженера на каждую выкладку. От разработчика на Go редко ждут глубины платформенной команды, но ждут, что вы опишете деплой манифестами и разберётесь, почему под не поднялся.

Как отвечать

Скажите честно, писали с нуля или правили существующий чарт, и покажите, что знаете устройство: Chart.yaml с метаданными и зависимостями, values.yaml со значениями по умолчанию, шаблоны в каталоге templates, вложенные чарты в charts. В третьей версии Helm зависимости объявляются в Chart.yaml и фиксируются в Chart.lock, отдельного файла требований больше нет.

Дальше то, что отличает рабочий чарт от учебного:

• пробы: readinessProbe убирает под из балансировки, livenessProbe перезапускает зависший;
• resources с запросами и лимитами, иначе планировщик не знает, куда ставить под, а сервис ловит вытеснение;
• секреты не в values.yaml, а из внешнего хранилища или отдельно созданного объекта Secret;
• аннотация с хэшем конфигурации в шаблоне пода, чтобы правка ConfigMap перезапускала поды;
• проверка до выкладки: helm lint, helm template для просмотра готовых манифестов, helm upgrade --install --atomic с откатом при неудаче.

Где спотыкаются

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

Второе: приносят чужой чарт целиком и не могут объяснить половину его значений. Интервьюер спрашивает, что делает конкретное поле и почему оно такое, и разговор на этом заканчивается.

Третье: путают инструменты. Helm это шаблонизатор и учёт релизов, сам по себе он ничего не выкатывает по коммиту: за это отвечает пайплайн или оператор непрерывной доставки внутри кластера.