Using a HorizontalPodAutoscaler [1] you can scale up and down the amount of "pods" (a grouping of containers that are scheduled as a unit) based on the desired metric.
Try not to see a feature file as a way to automate tests but to capture the requirements in a language that isn't technical.
Business rules change far less often than implementations, so the feature files shouldn't be tied to the implementation - that tying together can happen in the ruby code that implement the steps.
You can refactor that code easily but the feature is denoting the business rule.
Before the feature files get written, have a conversation with the PO and other stakeholders.
Involve a QA person and relevant developers.
Catch the changes early, ask for more examples of the feature or goal, "have you thought about ...", "What happens in this case...?".
You will get better quality features with less rework, because you are writing the thing the PO actually wants and cover off edge cases before they crop up in testing.