Hi,
We are planning to deploy our services in pods. We have around 7 services, we want each of them to be deployed in individual pods so that they can scale independently. Following are a couple of questions which are holding us back at the moment:
During upgrade, can we ensure that either all or none of the services are upgraded?
When a new version is available in the docker registry (ECR), can we ask the user whether to upgrade or not?
There is no kubernetes primitive to manage a set of different deployment objects (are you talking about different kubernetes deployment objects, right?). You can do a script to handle it yourself, specially if the upgrade is easy (like run kubectl set-image for several deployments, or run it again with the old version if something fails). Does it make sense?
Not sure I follow. What do you mean if you can ask users to upgrade or not? Can you please elaborate?
Yes, I’m talking about different deployment objects.
Ours is a product deployed per customer in their respective VPC in AWS. In the current version, we have a UI screen where we present an option to the user to select whether she/he wants to upgrade. When we move to kubernetes, can we provide such an option to the user so that he/she can choose whether to go ahead with upgrade or remain in the current version of the service?
Upgrade only when user gives consent, not upgrade automatically whenever a new version of the service pushed to the registry.
Following is the automatic upgrade workflow we are looking for:
Build server pushes a new version of the service to docker registry with appropriate tags. User is presented with a yes/no question in the app UI. If user says “yes”, then upgrade, else don’t upgrade.