-
Notifications
You must be signed in to change notification settings - Fork 30
[request] Support to create a K8s Deployment instead of Statefulset resource #94
Comments
We have created an issue in Pivotal Tracker to manage this: https://www.pivotaltracker.com/story/show/172858637 The labels on this github issue will be updated when the story is started. |
Hi @cmoulliard - the main reason we use StatefulSet is to continue to support the I'm interested if there are specific problems with StatefulSet vs. Deployment you're aware of that would make this higher priority? We set .spec.podManagementPolicy=Parallel on the created StatefulSets so in practice there isn't (we think!) much of a difference between the two approaches. |
Very interesting. If the |
Which kind of kubernetes resource are you gonna to create for a |
Yeah, unfortunately I think we looked in to this and it's quite difficult to do with Deployment, even with a label (it's hard to apply a label to individual pods in a deployment in an ordered way). Again the good news is we can't actually find many ways in which a StatefulSet with We'd still definitely like to move back to Deployments once we deprecate |
|
Did you happen to write down the results of investigating the differences? I didn't (yet) look any deeper, but what immediately comes to mind is that This alone will not help cover the drain behaviour as executed by Diego and discussed in cloudfoundry/cf-for-k8s#600, but also application updates should rather overprovision an app than underprovision it imho. |
Actually it is a big problem to use StafefulSets rather than Deployments. |
Hey @jsimao71, Nowadays the community is focusing on Korifi, which is a reimplementation of CF done from scratch on top of Kubernetes. It still supports the CF v3 API via a shim, so we still try to be compatible with the original CF as much as we can and to support existing clients. That said, we don't reuse any of the original CF components, which should make it easier to introduce changes like this. We're currently in the process of introducing abstractions that would allow anyone to customise how Korifi builds container images and runs workloads. Once these abstractions are in, it should be relatively easy to introduce a We'd still have to figure out the best way not to break existing clients which expect a numeric instance ID, and probably introduce string IDs too. It should still be a lot easier than on I understand these issues might be frustrating but please keep in mind that we're trying to reimplement a system on top of a different one with different behaviours, guarantees and design choices, while trying hard not to break existing clients and not to surprise existing users too much. Keeping a balance between Kubernetes functionality and CF compatibility is one of our biggest challenges and we put a lot of thought into it: most of the times it's not as simple as it looks. |
Hello, @gcapizzi ! The INSTANCE_INDEX could be always 0 in this installation mode.
There are several ways to then implement or emulate this:
The global config of cf4k8s could be used to select this two options: If you and the team of CF4K8s don't have bandwidth to work on this option(s) in the next couple of months, can you provide some hints about the code base so we can do it in our own private fork?!? |
Hey @jsimao71,
If you want to do this yourself, you should check cloudfoundry/eirini-release#207, which was an experiment to test the consequences of doing the change. That issue references a bunch of commits which should guide through the changes. Our constraints back then were different from yours, so you might get away with it with fewer or no issues, but I'm afraid it might be tricky. |
OK! Understood! We will study the eirini-release#207 to see if we can make sense of it and use it. Thanks! |
Request
When
cf
is used withEirini
and commandcf push
executed, then a k8s statefulset resource is created.While this resource addresses a specific use case needed for master/slave topology, this is not the best k8s resource to be created to deploy a microservice application which only requires to be stateless (see : https://stackoverflow.com/questions/41583672/kubernetes-deployments-vs-statefulsets).
Would it be possible to offer an option or config parameter that we could pass between CAPI and Eirini in order to specify the type fo the resource to be created ?
The text was updated successfully, but these errors were encountered: