mogenius / punq Goto Github PK

Cluster connections are currently added by uploading a kubeconfig. For some providers, such as AWS, Azure, or GCP, this is not enough. They require additional authentication through service accounts. punq should support these providers by adding an authentication option (+ kubeconfig) when adding a cluster.

I have an issue while running the below commands which are for installing punq:

There have been some issues while selecting $Kubeconfig

To resolve this we have to change or Update the documentation of punq which we are using without ingress as per our need.

Most resources are related to other resources and it should be possible to easily navigate through these relations.

For example:

• From a node, navigate to all pods on this node
• Deployments -> Pod -> Container
• Namespace -> Pod -> Container
• etc.

I have kubectl installed at /usr/bin/kubectl via dnf

$ punq install -i punq.minikube.local
Do you really want to install punq to 'minikube' context? [Y/n]: y
Creating punq namespace ...
Created punq namespace. ✅
Creating punq RBAC ...
Created punq RBAC. ✅
Creating punq deployment ...
Created punq deployment. ✅
Determining cluster provider ...
Determined cluster provider: 'MINIKUBE'. ✅
Creating new punq-context secret ...
Created new punq-context secret. ✅
Creating punq service ...
Created punq service. ✅
Creating TRAEFIK punq ingress (punq.minikube.local) ...
Created TRAEFIK punq ingress (punq.minikube.local). ✅
Creating TRAEFIK middleware (punq.minikube.local) ...
Error: failed to execute command (/bin/bash -c /usr/local/bin/kubectl apply -f /tmp/traefik-middleware.yaml3688081572): exit status 127
/bin/bash: line 1: /usr/local/bin/kubectl: No such file or directory

A code review revealed there are several places where kubectl is called on ¬Windows using the full path /usr/local/bin/kubectl.
This is fine and desirable, but only when the fully qualified command is resolved, stored and checked.

Using a hardcoded call to /usr/local/bin/kubectl will fail, when the caller doesn't have kubectl installed at /usr/local/bin.
This can be the case if it is installed via a package manager, like dnf in my case, or when a custom location is chosen, e.g. when developing on kubectl.

There are four solutions and a local quick fix:

1. Every call to /usr/local/bin/kubectl should be resolved via path, instead of being hard-coded.
2. On startup, punq checks whether kubectl is available using PATH but only on CLI calls which use kubectl. kubectl is defined once, and referred afterwards.
3. (Like 2. but with a singleton pattern which raises 4.)
4. Instead of relying on an external CLI Tool like kubectl, punq should talk directly with the API server, e.g. by using https://github.com/kubernetes/client-go/. This is already a dependency.

NOTE: 1, 2, 3 will create a mess, when the behaviour ofkubectl is altered during execution, unlikely, but possible: e.g. kubectx or kubens changes.

Quick fix:

ln -s /usr/bin/kubectl /usr/local/bin/kubectl

At last, when one of the install commands fails, I suggest punq should do a clean up itself or reminds to do a clean install.

I wanted to test Punq, but it seems it is incompatible with Ubuntu 20.04.

Downloading the binary on Ubuntu 20.04 (in WSL) and running it results in the following errors:

punq
punq: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by punq)
punq: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by punq)

As per my version of Ubuntu 20.04, it has libc6 2.31 installed. Doing a kernel update is not viable.
This could be solved by building the executable on Ubuntu 20.04 instead of 22.04 - that should remove the dependency of libc6 2.32 and 2.34.

It should be possible to connect to containers via shell in the user interface. Something like xterm.js could be used to open a shell in a tab next to Log, Describe, YAML.

Adding and managing users is currently only available via CLI. The section to manage members in a punq instance already exists and we need options to add and edit users.

Since punq doesn't have support to integrate SMTP for transactional emails, invite links and double opt-in are not possible yet. Therefore, when adding a user, admins could set or generate a password that is changed by the user after login.

Apart from deleting services, it should be possible to perform quick actions on pods, deployments, etc., such as:

• Restart
• Kill
• Scale