MOSAIC complements the developer's toolkit by helping us:
- Perform root cause analysis on the many things that can go wrong in a cluster
- Logically structure the the web of K8s resources, to make it surfable
- Automate repetitive or un-memorizable
- Understand the how and whys in Kubernetes without pausing the game
You interact with MOSAIC through a web app that runs in your browser. You must have a cluster to run MOSAIC. One step installation detailed below. The software is made of three deployments that live in your Kubernetes cluster. You will also be able to interact with K8Kat - the brain behind MOSAIC - as a CLI.
Several features are missing as this is still an alpha. The workflows MOSAIC assists with are:
- Troubleshooting problems with resources
- GitOps - from source to image to deployment
- Surfing the cluster, manually verifying and proding resources
To clear up some misconceptions, MOSAIC does not:
- Provision your cluster or add resources to it
- Assist with root cause analysis of the apps running in your cluster
- Give you a place to run a cluster
Root Cause Analysis
Decision Tree Diagnosis
For common problems like services not connecting, pods not being created, permissions, MOSAIC has built-for-purpose wizards that diagnose the issue while showing you exactly why/how it's operating.
Probable Cause Highlight
MOSAIC also extracts information from the API to turn your attention towards likely problems.
Even with standard visualizations, MOSAIC conveys the notion of "it should look like X".
In Kubernetes it's sometimes onerous to verify your work. This is especially true with networking, which is why MOSAIC has a built in HTTP tool.
This creates a temporary pod with a cURL-capable container, through which a request is sent to a service of your choice.
MOSAIC assumes that you think about your cluster as a collection of microservices. The homepage is therefore organized in terms of the deployments in your cluster.
GitHub and DockerHub Integration
If you're a developer, you probably care about what's running inside a deployment. That's why MOSAIC lets you bind any deployment in your cluster its corresponding source and image repos.
This is thanks to the GitHub and DockerHub integrations MOSAIC lets you do. (Bitbucket and friends coming soon).
You can even tell MOSAIC to clone a repo, build an image, push it, and restart the its matching deployment. There are no triggers, as the point is to facilitate development workflows, but this is something we can work on if the demand is there.
MOSAIC usses a deployment that runs a Docker image of Docker to build and push your deploymnent.
Unlike in most dashboards, you can create permanent workspaces that you define with white/black lists.
MOSAIC is not a 'learn K8s' tool, but it will to make you better at Kubernetes.
Every action in MOSAIC features a "game plan" where it shows you a
kubectl representation of its work.
There is even a smart cheat sheet for kubectl (and soon others) where commands are interpolated to fit the current resource.
What Goes Inside/Outside my Cluster?
The Frontend lives INSIDE your cluster. It's the main thing you interact with. It's a React app. Details here. It just runs in your browser and has zero direct contact with your infrastructure, and hence no permissions at all.
Kapi (pronnounced 'Kahpee', short for Kubernetes API), lives INSIDE your cluster.
It's the Flask backend that the frontend uses to talk to your cluster.
Note that kapi does not use kubectl to talk to your cluster; it uses the official python client.
We'll be publishing K8Kat. - the brains behind MOSAIC - as a standalone library so check that out too.
Kapi authenticates itself using a
ServiceAccount bundled in
nectar and authorizes itself via RBAC. Look through
in the manifest (as you always should when putting foreign software in your cluster!); here's the simplified version:
|Resource / Namespace||Not Nectar||Nectar||Comments|
|Pods||CRD||CRUD||create cURL pods, create Docker build pods, delete for cleanup|
|Deployments||RU||CRUD||change replica count i.e "scale"|
|Namespaces, Services, Events, Endpoints||R||R||introspection, root cause analysis, etc...|
You can customize the manifest.yaml's perms, but Kapi will fail if it can't do the things it expects to.
Docker inside Docker
MOSAIC wraps the official Docker image inside a deployment. This is used to build images from your applications' source code (see above).
To get rid of this, scale it down through MOSAIC's GUI or with kubectl:
kubectl scale deploy dind --replicas=0 -n nectar kubectl delete deploy dind -n nectar #or more violently
Note that this deployment gives its container root access:
containers: - name: dind image: docker:18.05-dind securityContext: privileged: true volumeMounts: - name: dind-storage mountPath: /var/lib/docker
Far from ideal, but that's the best I found. If you know a better way, ping me or start a PR.
The backend lives OUTSIDE your cluster. It's on a Nectar-owned server. Here's what it stores:
|Data / Notes||What||Encrypted?|
|Workspace Metadata||name, filters||No|
|Deployment Matchings||dep name, git/docker repo names||No|
|Git/Docker Hubs||identifier, token||Yes|
The main reason we use a remote backend is that persistent storage on k8s is still relatively hard, so dealing with data problems on individual users' clusters would be a flustercluck of an ops nightmare.
Install, portforward, open:
kubectl apply -f https://raw.githubusercontent.com/nectar-cs/mosaic/master/manifest.yaml kubectl port-forward svc/frontend -n nectar 9000:80 kubectl port-forward svc/kapi -n nectar 5000:5000 #visit http://localhost:9000
Read about the permissions used
All the MOSAIC resources you created with the
apply command above are in the
kubectl delete ns/nectar kubectl delete clusterrole/nectar-cluster-wide-role kubectl delete clusterrolebinding/nectar-permissions
Note that none of the deps use resource limits at the moment. I'm waiting for some community feedback before settling on those.
Finally, keep in mind that MOSAIC is still in alpha so there will be bugs.
MOSAIC has a built-in self-update mechanism. When an update is available, a popup will show that lets you one-click update:
You need to stop/start your port-forward ~15 seconds after clicking Update.
There's a lot more work to do, starting with polishing what exists.
After that, the planned big ticket items are listed in the Roadmap.
MOSAIC is built on three beliefs:
- Help without explanation builds dependence, not empowerment.
- Memorizing the complicated is worth little; understanding the complex is worth a lot.
- Visualizing is organizing, representing is conveying. All good things.
I'll be making a group in kubernetes.slack. Otherwise, issues, pull requests, etc as usual. Don't hesitate to reach out for details.
We're looking for cream of the crop engineers who want to create the new standard in container orchestration for the next decade.
Frontend, backend, infra, design, VP Developer Advocacy, and CTO. London, San Francisco, or remote. Drop me a line: firstname.lastname@example.org or Xavier M in kubernetes.slack.
What is Nectar?
Nectar is the company that makes MOSAIC. We're just out of stealth mode, have raised pre-seed, are raising seed now, and are based in London.
You just installed foreign software into your cluster to enhance it. We want to make that the norm, because that's how we think tomorrows's systems will be built: out of other sub systems.
But how can we trust the systems we integrate if they're so opaque? Our first step is to bring transparency to the cloud native executables (YAML + images). MOSAIC is the first page in that chapter.