MOSAIC

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 kubectl/git/docker chores
• Understand the how and whys in Kubernetes without pausing the game

Overview

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".

Fast Testing

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.

Workflow

Microservice-Centric Homepage

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).

GitOps

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.

Customizable Workspaces

Unlike in most dashboards, you can create permanent workspaces that you define with white/black lists.

Education

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?

Frontend

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

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.

Default Permissions

Kapi authenticates itself using a ServiceAccount bundled in the manifest named nectar and authorizes itself via RBAC. Look through ClusterRoleBinding 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.

Backend

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
User	email, pw	Yes
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.

Installing

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 here. All the MOSAIC resources you created with the apply command above are in the nectar namespace.

To uninstall

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.

Updating

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.

Getting involved

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.

Contributing

I'll be making a group in kubernetes.slack. Otherwise, issues, pull requests, etc as usual. Don't hesitate to reach out for details.

Joining Nectar

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: [email protected] 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.