Carrier is a project with the goal to make Kubernetes feel like a Platform as a Service. It's main goal is to simplify the deployment of applications on Kubernetes for the software developer.
Currently Carrier is only a cli. All commands are talking to the kubernetes API directly behind the scenes in order to:
- Install/Uninstall Carrier (uses, helm, kubectl or golang kubernetes clients behinds the scenes)
- Push applications
- Create in-cluster services
- Bind services to applications
For some tasks, command line interfaces are faster and better suited but there are cases where a graphical interface helps. Compare for example
k9s when trying to debug something on your cluster. With k9s, it takes a lot less typing to jump from deployments to secrets, edit a secret and then go back to deployments and see the result than it would take with just using
kubectl. Graphical user interfaces do less things but sometimes do them in less keystrokes (or even clicks).
In order to have any alternative user interface in Carrier (web, terminal or other), we should have a common contact point for all of them. A restful HTTP API is an obvious solution.
Additionally, some of the above commands need to make multiple requests to the kubernetes API in order to complete. When the cluster is running in a location remote to Carrier cli, the total amount of time until the command completion can be confusing to the user. When the kubernetes API is running close to the Carrier cli there is no noticeable delay. By collecting all the needed information on a location close to the kubernetes API and returning the aggregated result to the user's remote location we could fix this issue.
On more way to benefit from a long running process (like an http server) is to cache information. For example, there is no reason to ask the kubernetes api for any new deployments before at least 1 second has passed. If many users are using Carrier at the same time, listing applications, it would be good if we returned the cached result and only call the kubernetes API every other second. This may not be the best example but it describes the caching possibilities that become available.
Goal for this Hackweek
The goal of this Hackweek project is to implement some of the existing commands as API endpoints and try out a basic web UI. It's not meant to be a full implementation but rather an experiment to get a feel of the proposed architecture.
- Carrier repository: https://github.com/suse/carrier
Looking for hackers with the skills:
Nothing? Add some keywords!
This project is part of:
Hack Week 20
This project is one of its kind!
Be the first to comment!