Can *.yml files be deployed?

[stiller-leser]

Hi everybody,

I am aware that this goes against the purpose of this gem, but I am curious if I could use this gem to deploy yml-files to a Kubernetes cluster (basically kubectl create -f deployment.yml) since I am editing these files in ruby before anyways and really like the framework this gem offers.

Thanks ahead, stiller-leser

[cben]

Yes and no :-) Easiest case is something like this:

deployment = Kubeclient::Resource.new(YAML.safe_load(File.read('path/to/deployment.yaml')))
client.create_deployment(deployment)

• kubeclient currently disregards kind and apiVersion inside the Kubeclient::Resource (#208).
  • if you don't know ahead of time kind will be "deployment", you may need another method than "create_deployment". (hint: there is generic create_entity but it's not public yet — #332 — please speak up there if you want to use it!)
  • if you don't know ahead of time apiVersion, you need to take the actual version and construct an appropriate Kubeclient::Client.
• if yaml contains many objects (likely to have multiple kind and apiVersion), do the above in a loop...

This is being asked repeatedly #325, #187. Would be nice to document in README (PRs welcome!) Would be even better to improve multi-group/version interface...

[stiller-leser]

Hey @cben,

been a while and I've been able to work around most of the issues with create_entity.

However with that I can't seem to create deployments, since I only get HTTP status code 404, the server could not find the requested resource for POST https://my-ip/api/v1/namespaces/default/deployments.

I tried the create_deployment method you've referenced, but I only get because undefined method 'create_deployment' for #<Kubeclient::Client:. Any hint?

EDIT:

It turns out that in order to create deployments, I need to POST https://my-ip/apis/apps/v1beta1/namespaces/default/deployments. And even this is an old endpoint (haven't gotten it to work with the newest one yeet, see: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/#deployment-v1-apps .

To work around it for now (without having to set up a new Kubeclient), I would need to modify the api-endpoint as well as the api_version on the fly, which currently is not possible.

Or we could solve it finalizing #241

Thanks ahead, stiller-leser

[cben]

Yeah. You need to create a Kubeclient::Client per API group you use.

I don't see this changing soon. The way Kubeclient creates methods per resource, like get_deployments, ties a client to one api version. IIUC #241 would tie a client to a "version vector", one version per API group. I can see how that's friendly to a 90% of uses, but it gets ~~ugly~~ tricky in 10%. It's also a huge code change.

IMHO it's more realistic in the near term to keep "separate client per API group" but make it easy to create "related" clients from an existing client. I could be wrong, you're welcome to work on #241 if you see a good way.

[stiller-leser]

Well it would already help if we could expose the neccessary attributes with a setter method. This way one could use one client and just switch the endpoints. This would save the new init. I am currently using memoization to keep the load as low as possible during initialization, but this is more of a workaround.