4 ms·

This is what I meant. This is in no way related to kustomize or what it does. One is to make hierarchical templated deployment files, while the other is to conn

This is what I meant. This is in no way related to kustomize or what it does. One is to make hierarchical templated deployment files, while the other is to connect and interact with the API server. The client library is more analogous to kubectl, which consumes yamls.

dqpb 8y ago
I'm telling you it is. Look at the models in the repo here: https://github.com/kubernetes-client/python/tree/master/kubernetes/client/models https://github.com/kubernetes-client/python/tree/master/kube... or the docs here: https://github.com/kubernetes-client/python/tree/master/kubernetes#documentation-for-models https://github.com/kubernetes-client/python/tree/master/kube... These are python classes that serialize to dict which you can dump to yaml. In other words, you can define your kubernetes spec as python classes, with variables, inheritance, and all the other good things that come with a programming language. Once you have your kubernetes spec, you can either deploy it with the endpoint helpers (https://github.com/kubernetes-client/python/tree/master/kubernetes#documentation-for-api-endpoints https://github.com/kubernetes-client/python/tree/master/kube...) Or you can serialize to yaml if what you want is to generate a bunch of yaml. There is no need for a yaml template language.
- shaklee3 8y ago
  It's not the same. I have written custom scheduler with the python client API. It is missing many things from the go API, despite it being an officially supported language. You will encounter things that you just can't do with the python client, and end up hacking in your own custom yaml. what you pointed to will definitely work for most of the basic resources, but it certainly won't work for everything. Although, it's good that you pointed it out since I think it will help people that need fairly basic resources without doing something more complicated.

dqpb 8y ago

I'm telling you it is. Look at the models in the repo here: https://github.com/kubernetes-client/python/tree/master/kubernetes/client/models https://github.com/kubernetes-client/python/tree/master/kube... or the docs here: https://github.com/kubernetes-client/python/tree/master/kubernetes#documentation-for-models https://github.com/kubernetes-client/python/tree/master/kube... These are python classes that serialize to dict which you can dump to yaml. In other words, you can define your kubernetes spec as python classes, with variables, inheritance, and all the other good things that come with a programming language. Once you have your kubernetes spec, you can either deploy it with the endpoint helpers (https://github.com/kubernetes-client/python/tree/master/kubernetes#documentation-for-api-endpoints https://github.com/kubernetes-client/python/tree/master/kube...) Or you can serialize to yaml if what you want is to generate a bunch of yaml. There is no need for a yaml template language.

shaklee3 8y ago
It's not the same. I have written custom scheduler with the python client API. It is missing many things from the go API, despite it being an officially supported language. You will encounter things that you just can't do with the python client, and end up hacking in your own custom yaml. what you pointed to will definitely work for most of the basic resources, but it certainly won't work for everything. Although, it's good that you pointed it out since I think it will help people that need fairly basic resources without doing something more complicated.