hjacobs / kube-ops-view Goto Github PK

Unassigned pods are not "greyed out" when filtering.

This screenshot shows one unassigned pod which does not match the "doesnotmatchanything" string, but it's still shown in yellow (instead of grey):

There is a vertical line "staying" from the former cluster box when the cluster box resizes (new node created).

We currently have no indication in the frontend whether the Kubernetes data is outdated (cached in Redis) or not. Calls to the API server could fail for various reasons, the user should immediately know about it.

Store last snapshot time?

Pods with the same name in different clusters are mixed up.

The current search/filter query should be added as an URL hash in order to send it around as a link to others.

Pods are currently unsorted, they are displayed in the same order as returned by the Kubernetes API server.

Should we sort them by name to be consistent? Or should we sort them by creation timestamp?

/cc @ChristianLohmann @shuaibiyy

Node meters should have tooltips showing actual values (like 500 MiB of 16 GiB memory used).

Number of pod restarts is a relevant metric to know 😏

It would be nice to get some screenshots on the existing state of the dashboard.

Cheers!
J

Object.values is not as widely supported as one could believe: https://kangax.github.io/compat-table/es2016plus/

It works in recent browsers like Firefox 47+ and Chrome 55+, but it does not work in Chrome 53 which comes with Ubuntu 14.04 (old LTS, EOL April 2019).

Ubuntu 14.04 LTS should probably still be supported.

All the node.js modules and node itself are kept in the final Docker image --- we should get rid of it.

Only install nodejs and modules before the npm build and remove it afterwards (all in one RUN command).

Users might want to share the cluster view to unauthenticated users (e.g. to display on some TV dashboard screen). A similar mechanism as in ZMON can be applied, see https://docs.zmon.io/en/latest/user/tv-login.html?highlight=tv

The UI design should have a common look & feel. I like to have a Sci-Fi themed UI, good inspiration can be found on this site: http://www.core77.com/posts/28183/Fantastical-UI-Design-from-Sci-Fi-Movies

Try to read ~/.kube/config by default and use it to directly connect to the default context thus not requiring kubectl proxy anymore.

Also add --kubeconfig-path option to read arbitrary kubeconfig file containing credentials (possibly client certs #72).

Allow switching "themes" (colors) to make everyone happy.

app.switchTheme() leaves the app in a "corrupt" state --- current workaround is a manually-triggered page reload.

Users should be able to filter the view by cluster:

• clicking on the cluster title bar should "maximize" this single cluster, i.e. only showing this one cluster on screen
• clicking on a new "minimize" button in the cluster title bar should hide the cluster
• the cluster selection should be persisted in the location hash
• only the data for the selected cluster(s) should be loaded from the backend

The current UI causes browser crashes (Firefox and Chromium) after a few hours 😞

Options:

• find the memory leak or whatever it is...
• add safety guards like regular page refreshes

Add some nice favicon.ico 😄

If the mousepointer hovers over greyed out pods they are switch back to their origin status color.

Full Kubernetes state is polled on every request, this works for small clusters and few clients.
Consider possible improvements:

• keep state in backend and poll in background (decouple frontend requests from API requests)
• watch Kubernetes resources and update local state as needed
• use something like WebSockets to push updates to JS client

Pods with not-yet-ready containers are currently flashing red, but this is normal during deployments --- show them as pending or similar.

Retrying failing/unreachable clusters every time just spams the log and won't help anybody. This is especially interesting for the --kubeconfig-path option (#95) as users might have any number of "old" context entries in ~/.kube/config (where only a subset of them might actually work).

The initial page load should get some cached cluster information JSON (stored in Redis) instead of waiting for new events (as this causes a delay for the user to see anything).

https://github.com/kubernetes/charts/

kubectl top nodes
...
I0110 10:21:57.938861    8278 round_trippers.go:318] GET https://my-cluster/api/v1/proxy/namespaces/kube-system/services/http:heapster:/apis/metrics/v1alpha1/nodes?labelSelector= 200 OK in 210 milliseconds
I0110 10:21:57.938910    8278 round_trippers.go:324] Response Headers:
I0110 10:21:57.938920    8278 round_trippers.go:327]     Content-Type: application/json
I0110 10:21:57.938928    8278 round_trippers.go:327]     Date: Tue, 10 Jan 2017 09:21:57 GMT
F0110 10:21:57.941378    8278 helpers.go:116] error: metrics not available yet

The URL http://localhost:8001/api/v1/namespaces/kube-system/services/heapster/proxy/apis/metrics/v1alpha1/nodes might return null as the value of `items. We should handle this instead of throwing an exception:

10.2.15.0 - - [2017-01-10 09:19:07] "GET /kubernetes-clusters?id= HTTP/1.1" 404 342 0.001122
ERROR:root:Failed to get metrics
Traceback (most recent call last):
  File "/app.py", line 290, in get_kubernetes_clusters
    for metrics in response.json()['items']:
TypeError: 'NoneType' object is not iterable

Allow gathering information from multiple API servers.

Services and Ingress can/should also be included in the Kubernetes Operational View:

• draw services as entities inside of cluster, but outside any node
• indicate number of service endpoints (no endpoints = red / unhealthy)
• draw ingress on cluster boundary
• indicate ingress metrics (proprietary, depends on ingress implementation e.g. Skipper metrics)

A lot of information is contained in the cluster visualization. There should be an onscreen help/tutorial showing the most important aspects:

• explain the node resource bars (CPU/memory, requested/used)
• explain the different pod states and colors

😢

http://eslint.org/docs/rules/semi

I don't want to write semicolons, but other people might have other opinions.

We should have a mock mode which provides sample Kubernetes data:

• good for developing the UI (dependable data)
• good for other people to try out without having to run Kubernetes

Node and pod age should somewhat expressed visually.

Organize code cleanly into a Python package instead of having everything in app.py.

Handle SIGTERM and switch health endpoint to HTTP status 503.

To be discussed: it might make sense to visualize Kubernetes events somehow:

• What events? (only problems or important changes, ..)
• How to visualize?

Pods are in "Pending" state until they get a node assigned by the Kubernetes scheduler. Unassigned pods should be shown and animated ("flying to") the assigned node.

This JS error got caught on the browser console during a cluster upgrade:

Uncaught TypeError: Cannot read property 'position' of null

No location details as it was happening in minified production JS code.

Cluster and node sizes need to be completely dynamic. The current node box width/height is hardcoded.

https://webpack.github.io/docs/library-and-externals.html

Idea would be to have a global "app" var which we can use in the browser console
to access all underlying things (mostly for debugging/inspection).

In our Kubernetes clusters, we use client-side certs for authentication. I see that in the Readme it states:

Note that authentication via client-certificates is currently not supported!

It would be great if that could be added.

In general, it would be great if the app could read a kubeconfig file. Then you could specify a comma-separated lists of contexts to connect to via command-line arg or environment variable.

Create some initial documentation:

• How to configure / set up
• User guide / how to interpret the UI

Pod metrics such as CPU and memory usage (collected via Heapster) should be visible.

See http://caniuse.com/#feat=fetch

The list of Kubernetes clusters should not be hardcoded on startup, but instead a lookup to some "Cluster Registry" should be performed regularly (to "discover" new clusters).

The endpoint for the Cluster Registry would look like:

curl https://my-cluster-registry.example.org/kubernetes-clusters
{"items": [{"id": "my-cluster1-id", "api_server_url": "https://cluster1.example.org", "lifecycle_status": "ready"}]}

Only Kubernetes clusters having lifecycle_status value ready should be considered.

Idea: "disintegrate" or let the pod explode.

It would be helpful to have a small search box at the top to filter pods/nodes by query string to quickly find something. We could use some black/white or blur filter to hide all non-matching pods/nodes.