Skip to content

Can *.yml files be deployed? #329

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Open
stiller-leser opened this issue May 25, 2018 · 4 comments
Open

Can *.yml files be deployed? #329

stiller-leser opened this issue May 25, 2018 · 4 comments

Comments

@stiller-leser
Copy link

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
Copy link
Collaborator

cben commented May 27, 2018

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)

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
Copy link
Author

stiller-leser commented Jun 27, 2018

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
Copy link
Collaborator

cben commented Jun 27, 2018

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
Copy link
Author

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.

# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

2 participants