nearmap/kubefs

User friendly kubernetes tools to make your clusters less mysterious and more accessible

kubefs's Issues

Add filter/sort by pod phase

The colour coding is great, makes it much easier to spot. However, if the pod list is quite long, it would be helpful to filter/sort on phase.

An example use case is for when responders want to check general health of pods or diagnose an alert, and they're interested in non-running/succeeded pods.

optimize discovery of api resources

When browsing clusters the first get_directory_entries on a cluster is quite slow because kubefs has to discover the registered API resources and this requires a dozen separate http requests. These requests are done sequentially, but they don't have to be. They should actually be easy to parallelize (either all at once, or in batches) and it should be no issue for the API server either because it must be a very cheap operation just to list registered API resources.

add screenshot feature

It would be really useful to be able to take a (textual) screenshot in podview to paste into a bug report and such. We can just take a copy of the whole buffer and save it to a timestamped file.

consider displaying container ready state

Container readiness determines whether the container will receive traffic via the Service. ready is just a boolean attribute which we don't currently show, but we should consider showing it.

missing api resources

When discovering api resources we fetch the api groups, eg:

    {
      "name": "batch",
      "versions": [
        {
          "groupVersion": "batch/v1",
          "version": "v1"
        },
        {
          "groupVersion": "batch/v1beta1",
          "version": "v1beta1"
        }
      ],
      "preferredVersion": {
        "groupVersion": "batch/v1",
        "version": "v1"
      }
    },

And we just use the preferredVersion, but it turns out that there are api resources that may be in a non-preferred version which we thus miss. We should instead use all versions mentioned.

also show init containers

Right now init containers are never shown at all. Generally they succeed, but if an init container were to fail podview would never show it.

• Include the init container in the list of containers.
• We can probably hide it if it exited with code 0.

add support for `exec` in kubeconfig user

We don't support AWS EKS clusters at the moment, because the credentials are not long lived and stored in the kube config. Instead, they are rotated in a matter of hours and have to be refreshed. This requires running the aws cli as part of our kubeconfig logic to obtain the credentials.

make the selector key more distinct from the value

The podview selector in the header would be a bit more readable by using a dimmer color for the key and a brighter color for the value.

Probably keep white for the value and use a gray tone for the key.

reap old pods and old terminated init containers

Currently, pods that were deleted hours ago are still being shown in the view. At that point they are not really relevant anymore. It would be better to reap them 1h after they were deleted.

An attempt to implement this was made in the updater, in the event handler function. This doesn't really work, because it presupposes that we still get more (and quite frequent) events after the pod has been deleted, which is unlikely to be the case. So that code was unlikely to ever run.

Instead, we need to implement this as a periodic piece of logic that runs as part of the ui mainloop. Reaping init containers 1h after termination was implemented in #5 and does seem to work pretty well, but it would be better to move this too to the same (new) cleanup code.