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

Question

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

тест-поток-приложение-v1.

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

------Следовать за -----------

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

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

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

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

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

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

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

Answer 1

@Anand. Поздравляю с первым постом!

Соглашение об именах основывается на идее, что каждое потоковое приложение является "версионным", если 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), а также посмотрите примеры в справочном руководстве.

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