Control Plane/ Service Mesh Feature Request
coffeebe4code opened this issue · comments
The biggest blocker for adoption is CICD for the krakend gateway is not having a mechanism for providing new or updated config without having the image being redployed.
We can't have an instance of a gateway per api as that becomes expensive, so now we are in a scenario where we need to build a locking mechanism to make sure all config that is provided to the krakend image, is correct version at that time.
Given api's A,B, C, D
A1,
B1,
C1,
D1
Those 4 api's are in production and being served by one krakend gateway.
Two API's could receive updates from the respective teams nearly simultaneously,
So,
A2,
B1,
C1,
D1,
Needs to get released,
While those two are releasing, and A/B or Blue/Green deployment is happening, a new version of B needs to go out,
A1,
B2,
C1,
D1
Problem here is, if we didn't lock all the configs tied to a gateway, they might select the config for A1!
Whats even worse, is rollback scenarios, there is a chance that A doesn't pass its tests, but B will, so A rolls back B.
We also need to preemptively update the configs, before a successful blue/green deployment, because the B deployment will need the transitioning versions as well.
If you want CNCF graduation as well, imo this type of control plane/service mesh CICD integration is necessary.
Sorry, this can be closed, I have opened it in the wrong project.
This issue was marked as resolved a long time ago and now has been automatically locked as there has not been any recent activity after it. You can still open a new issue and reference this link.