Рациональное добавление версий в качестве имени службы / развертывания на k8s с весенним облачным шкипером

Question

Я в некотором роде новичок в мире весенних облачных потоков данных, и, играя с фреймворком, я вижу, что если у меня есть stream = 'test-steram' с 1 приложением под названием 'app'.При развертывании с использованием шкипера в kubernetes я вижу, что он создает pod / deploy & service для kubernetes с именем

test-stream-app-v1.

Мой вопрос: зачем намиметь v1 в именах сервисов / развертываний на k8s?Какую роль он играет в общем рабочем процессе, используя поток данных весеннего облака?

------ Продолжение -----------

Просто хотел подтвердить несколькоуказывает, чтобы убедиться, что я на правильном пути, чтобы понять поток

• Насколько я понимаю, с традиционной потоковой (привязка через кафку тем) служба (объект на kubernetes) не играет существенной роли.

• Шаблон скользящего обновления (красный / черный) реализован следующим образом в шкипере, а управление версиями в развертывании / обслуживании играет следующую роль.

  Предположим, что развертывание app-v1 уже существует и требуется обновление.Skipper создает развертывание app-v2 и ждет его готовности.Когда все готово, он уничтожает app-v1

Если мое понимание выше верно, у меня есть следующие вопросы ...

1. Я вижу, что шкиперМожно развернуть и упаковать (и это не обязательно должен быть традиционный поток) для работы.Это более долгосрочный план, или Skipper предназначен только для работы с потоками весенне-облачных данных?

2. В случае, когда пакет потока нетрадиционного типа, в котором пакет имеет несколько приложений (остальные микросервисы) в группе, как будет работать эта модель управления версиями?Я имею в виду, когда я хочу позвонить в микросервис из другой микросервисной службы, я не могу знать или не совсем знаю знать версию выпуска приложения?

Answer 1

@ Ананд.Поздравляю с 1-ым постом!

Соглашение об именах основывается на идее, что каждое потоковое приложение является «версионным», если Skipper используется с SCDF.Версия подвергается воздействию, когда пользователь, когда вы обновляете и обновляете версии потокового приложения или свойства конкретного приложения, либо по требованию, либо с помощью автоматизации CI / CD.

Это очень актуально для рабочих процессов с непрерывной доставкой и непрерывным развертыванием, и мы предоставляем собственные опции в SCDF с помощью таких команд, как stream update .. и stream rollback .. соответственно.Для любой из этих операций приложения будут обновляться в K8s, и каждое действие будет увеличивать число в имени приложения.В вашем примере вы увидите их как test-stream-app-v1, `test-stream-app-v2 и т. Д.

Со всеми историческими версиями в центральном месте (т. Е. В базе данных Skipper), вы быбыть в состоянии взаимодействовать с ними с помощью команд stream history.. и stream manifest .. в SCDF.

Чтобы узнать больше обо всем этом, посмотрите этот демонстрационный вебинар (начинается @ ~ 41.25), итакже посмотрите образцы в справочном руководстве .

Надеюсь, это поможет.