0

Our Services utilize Kafka to publish and consume messages. We deploy our services using Blue-Green deployment strategy. Consider below scenario :

- Suppose we have App1.0 service in Blue(which is live and taking traffic) currently ,consuming from topic,
 - when we start deploying a new version App1.1, it will get deployed to Green first,so now 
      Green has : App1.1 (not consuming)
      Blue has :  App1.0 (consuming messages)
 - once we switch green to blue , Blue has App1.1 , and green has App1.0.

Our issue here is that once the switch happens, our green pods(in which we have older code App1.0) are still consuming messages from that kafka topic . Ideally green pods should now stop consuming from the topic. We are looking for a solution wherein when we deploy ,our green pods should stop consuming .

OneCricketeer
  • 179,855
  • 19
  • 132
  • 245
Dev-vruper
  • 421
  • 3
  • 12
  • If you want the same consumer group, then there is no such feature that Kafka can provide for this. You'd need to make a locking mechanism around the KafkaConsumer class poll loop that can handle that yourself – OneCricketeer Aug 18 '20 at 17:37
  • @OneCricketeer Locking mechanism can be a option , also it creates another question - ' How will our service know that's its in Green zone ? As our apps dont know the state of deployment.(i'll research on this :))' And lastly thank you for your input ! cheers :) – Dev-vruper Aug 21 '20 at 10:50
  • Assuming you use Zookeeper for a Coordinated Lock, you could try to store a ZNode that contains a JSON list of `[{'version': '1.0', 'active': false}, {'version': '1.1', 'active': true}]`, then work with some metadata like that as apps change and get deployed... Haven't tried personally that way, but worth a try – OneCricketeer Aug 21 '20 at 15:55

0 Answers0