Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

[Kubernetes] Deploy to Kubernetes #110

Open
JonathanMace opened this issue Dec 5, 2023 · 5 comments
Open

[Kubernetes] Deploy to Kubernetes #110

JonathanMace opened this issue Dec 5, 2023 · 5 comments
Assignees
Labels
Kubernetes Issues relating to Kubernetes deployment or plugins

Comments

@JonathanMace
Copy link
Contributor

Blueprint v1 used a docker-to-kubernetes tool to translate docker-compose files into Kubernetes. We don't want to do this, because subsequent plugins will want to use kubernetes features that require modifying the kubernetes deployment files.

This issue needs to implement Kubernetes. Fortunately the docker-compose plugin already has the same end-to-end workflow as Kubernetes would have (collecting and combining container images, generating ports, etc.).

@JonathanMace JonathanMace added the Kubernetes Issues relating to Kubernetes deployment or plugins label Dec 5, 2023
@JonathanMace JonathanMace assigned vaastav and JonathanMace and unassigned vaastav Dec 5, 2023
@JonathanMace
Copy link
Contributor Author

Some thoughts / comments on design for the Kubernetes plugin:

  • Dividing the application into pods and services is modular and should be very straightforward. In terms of IR representation this should be very straightforward and can probably be adapted from the docker-compose implementation.
  • We will have the same concerns about ports and port mappings as the docker-compose implementation, but the logic should be transferable

New pieces:

  • We will probably need to build the docker images (where before we did not). This will require a registry where we build and push the images. It also requires us to name the images, so that we can refer to those image names in the Kubernetes yaml files.
  • The first answer to this question shows how to name images and publish them to a custom registry.
  • For now we can require that users manually run a local registry (as in that stack overflow post above), and error out if they haven't.
  • The kubernetes plugin can assume by default that images are published to localhost:5000 and thus images will be named things like localhost:5000/user_service. We can add a wiring spec function to allow overriding this (or alternatively use a command line flag)

If we do the above then the only difference between running with minikube vs. real kube is the image repo url (since we can assume that you wouldn't host the images on localhost if you're using real kube, instead there would be an actual image repo running somewhere in your cluster).

After some experimentation, the golang docker API is a bit of a pain and doesn't seem to be doing the same thing as equivalent command-line commands. Probably for now it's best to just execute command line commands.

We probably also want to make sure the image builds are done in parallel since it can be slow.

@canteversleep
Copy link

We thank the authors for making their contributions open-sourced and for their continued efforts. We are interested in using Blueprint as part of the authorship of a paper and were interested in learning about the progress on this issue and/or on the Kubernetes branch. Thank you very much once again.

@vaastav
Copy link
Contributor

vaastav commented Jun 4, 2024

Hi @canteversleep, we are in the process of adding the Kubernetes plugin (#162 ). I have been busy with some other projects so we haven't gotten around to fully implementing it. If you need this urgently, then we can prioritize this and have it implemented + merged in the next couple of weeks.

@canteversleep
Copy link

Hey @vaastav, thank you very much for your response and for considering prioritization of this branch. Our clusters are most compatible with Kubernetes deployments and we would therefore be aided by priority implementation of the plugin for our paper. I understand how working on multiple projects gets and really appreciate any time you can put into this. Thank you again for making this work open-sourced and sharing it with the community!

@alessandrocornacchia
Copy link

Following up @canteversleep comment, I also see the extension to Kubernetes as a top-priority support for my research. I'll be joining the SOSP tutorial, and I'd be happy to discuss and contribute if necessary! Thanks for this project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Kubernetes Issues relating to Kubernetes deployment or plugins
Projects
None yet
Development

No branches or pull requests

4 participants