Rational behind appending versions as Service/Deployment name on k8s with spring cloud skipper

0
votes

I am kind of new the spring cloud dataflow world and while playing around with the framework, I see that if I have a stream = 'test-steram' with 1 application called 'app'. When I deploy using skipper to kubernetes, I see that It creates pod/deployment & service on kubernetes with name as

test-stream-app-v1.

My question is why do we need to have v1 in service/deployment names on k8s? What role does it play in the overall workflow using spring cloud dataflow?

------Follow up -----------

Just wanted to confirm few points to make sure i am on right track to understand the flow

  • My understanding is with traditional stream (bind through kafka topics) service (object on kubernetes) do not play a significant role.

  • Rolling Update (Red/Black) pattern has implemented in following way in skipper and versioning in deployment/service plays a role in following way.

    Let's assume that app-v1 deployment already exists and upgrade is requested. Skipper creates app-v2 deployment and wait for it to be ready. Once ready it destroys app-v1

If my above understanding is right I have following follow up questions...

  1. I see that skipper can deploy and package (and it do not have to be a traditional stream) to work with. Is that the longer term plan or Skipper is only intended to work spring-cloud-dataflow streams?

  2. In case of non-tradtional stream package, where an package has multiple apps(rest microservices) in a group, how this model of versioning will work? I mean when I want to call the microservice from other microservice, I cannot possibly know or less than ideal to know the release-version of the app?

1
spring-cloud-dataflowspring-cloud-skipper

1 Answers

0
votes

@Anand. Congrats on the 1st post!

The naming convention goes by the idea that each of the stream application is "versioned" if Skipper is used with SCDF. The version gets bumped for when, as a user, when you rolling-upgrade and rolling-downgrade the streaming-application versions or the application-specific properties either on-demand or via CI/CD automation.

It is very relevant for continuous-delivery and continuous-deployment workflows, and we provide native options in SCDF through commands such as stream update .. and stream rollback .. respectively. For any of these operations, the applications will be rolling updated in K8s, and each action will bump the number in the application name. In your example, you'd see them as test-stream-app-v1, `test-stream-app-v2, etc.

With all the historical versions in a central place (i.e., Skipper's database), you'd be able to interact with them via stream history.. and stream manifest .. commands in SCDF.

To learn more about all this, watch this demo-webinar (starts @ ~41.25), and also have a look at samples in the reference guide.

I hope this helps.