Наглядное объяснение работы «native sidecar-контейнеров». Лучше, конечно, прочитать и оригинал текста :)

Kubernetes Native Sidecars

Fun Fact: объекта поля Sidecar нет даже в Kubernetes 1.28. Встроенные sidecar-контейнеры — это просто старые добрые init-контейнеры, но с некоторыми новыми свойствами:

▪️ Чтобы сделать init-контейнер sidecar-контейнером, необходимо добавить атрибут «restartPolicy: Always» в его спецификацию.

▪️ Поскольку сайдкары являются init-контейнерами, они соблюдают порядок запуска в списке Pod.initContainers.

▪️ Однако они не блокируют следующий запуск контейнера (init или обычного).

▪️ В отличие от init-контейнеров, в случае сбоя сайдкары будут перезапущены.

▪️ В отличие от не встроенных сайдкаров (исторически имитируемых обычными контейнерами), встроенные sidecar-контейнеры не блокируют завершение пода.

▪️startup|readiness|liveness пробы теперь можно настроить для init-контейнеров, но только для тех, у которых для параметра restartPolicy установлено значение «Always».

Другими словами, единственная «true init» особенность новых встроенных Sidecars, заключается в том, что они следуют порядку запуска инициализации. В остальном их поведение сильно отличается от init-контейнеров.

Эта конструкция открывает путь к более продвинутому типу init-контейнера. В Sidecar PEP даже упоминается новый тип, называемый «infra containers», который может быть использован для унификации поведения старых init и новых контейнеров Sidecar.

Вот как новое поведение можно визуализировать с помощью одного пода:

• Два обычных контейнера работают до завершения
• Два init-контейнера ic1 и ic2 работают до завершения.
• ... и смешанный с двумя сайдкарами sc1 (периодически выходит из строя и перезапускается) и sc2 (работает до завершения)

Обратите внимание, как:

• Первый сайдкар постоянно перезапускается.
• Оба сайдкара принудительно уничтожаются после завершения работы обоих обычных контейнеров.
• Окончательный статус пода — «Succeeded», несмотря на то, что оба сайдкара сообщают о non-zero exit codes.

#лонгрид