kubernetes: kubectl create -f doesn't create services first, violating config best practice
Config best practices says:
Create a service before corresponding replication controllers so that the scheduler can spread the pods comprising the service. You can also create the replication controller without specifying replicas, create the service, then scale up the replication controller, which may work better in an example using progressive disclosure and may have benefits in real scenarios also, such as ensuring one replica works before creating lots of them)
It also says:
Use kubectl create -f <directory> where possible. This looks for config objects in all .yaml, .yml, and .json files in <directory> and passes them to create.
It looks like kubectl just creates things in sorted order:
zml@zml:~/kubernetes$ ls -1 examples/spark/*.yaml
examples/spark/spark-driver-controller.yaml
examples/spark/spark-master-controller.yaml
examples/spark/spark-master-service.yaml
examples/spark/spark-worker-controller.yaml
zml@zml:~/kubernetes$ kubectl create -f examples/spark
replicationcontrollers/spark-driver-controller
replicationcontrollers/spark-master-controller
services/spark-master
replicationcontrollers/spark-worker-controller
About this issue
- Original URL
- State: closed
- Created 9 years ago
- Reactions: 17
- Comments: 24 (13 by maintainers)
The way I implemented my CD is using the kubectl apply. I then in order to guarantee the order I prefix the files with numbers. e.g: 0_namespace.yaml 1_secret.yaml 2_service.yaml 3_deployment.yaml 4_ingress.yaml
Works like a charm.
On Mon, Jan 14, 2019, 10:02 PM borg286 <notifications@github.com wrote:
This might not be a solution to this exact issue, but kubectl’s new
-kmode, based on kustomize, does reorder resources.Even if you’re not interested in kustomize’s other features, as long as you can upgrade your kubectl, you should be able to work around this limitation in a relatively clean way (at least compared to 0-prefixing).
any news about this?
That doesn’t look like a proper solution 😉
As some of the more recent comments allude to, the issue of resource creation ordering is a lot more complicated than just Services->Deployments. Even if we were to implement a dependency graph between all built-in kinds, which would be non-trivial, we would still encounter several stumbling blocks:
createis not always sufficient to provide behavioural startup ordering. To get that, you may need to wait for a status on the earlier resource. E.g. CRD has to be accepted, not merely created, before submitting a dependent CR.We discussed this at a SIG-CLI meeting today, and for all these reasons, we don’t think this is a change we should pursue in kubectl. The current behavior is effectively to have users fully control the dependency chain by providing the resources in the desired order. This is the right behavior for a tool at this level of abstraction. If more complex behavior is desired, there are many more opinionated, higher-level deploy orchestration tools available in the ecosystem.
/close