k8s pod with multiple containers merges the name of each container about xpipe

[crschnick]

So I replaced the cluster name with context name and I guess that should fix the context issue. The kubectl commands now get supplied with --context=<name> instead of --cluster=<name>.

[crschnick]

In the latest staging test version (https://github.com/xpipe-io/xpipe_staging/releases/tag/1.6.0), I added support for scanning all namespaces now.

[crschnick]

That is an interesting issue, I'm not sure why it gets detected like this. What is the output of kubectl get pods <pod name> -o="custom-columns=Containers:.spec.containers[*].name,Status:.status.phase" for you?

[hahn-kev]

This is the output.

kubectl get pods lexbox-5968bc5d7d-p9cqg -o="custom-columns=Containers:.spec.containers[*].name,Status:.status.phase"
Containers                  Status
lexbox-api,otel-collector   Running

I think there's only 1 row because get pods only returns 1 row.

[hahn-kev]

another related issue that I'm running into is that I can only connect to my active context, I can't connect to any others. One way to solve this would be to add the context as a cli flag. For example kubectl get pods will list all pods in your active context. But kubectl get pods --context docker-desktop will get all the pods for the docker-desktop context no mater what the current context is. Probably all commands from xpipe should specify the context if they use kubectl directly.

[crschnick]

This is the output.

kubectl get pods lexbox-5968bc5d7d-p9cqg -o="custom-columns=Containers:.spec.containers[*].name,Status:.status.phase"
Containers                  Status
lexbox-api,otel-collector   Running

I think there's only 1 row because get pods only returns 1 row.

Maybe I'm just using the wrong formatting arguments which fail in your case. At least on my end all the output is as expected with one container per line. What happens when you use -o="custom-columns=Containers:.metadata.name,Status:.status.phase"? I used this answer as a resource, maybe I have to investigate a bit further.

I should be able to list all contexts first and then search in all of them, let me see what I can come up with.

[crschnick]

Alright, so I think I managed to fix both issues. If you want, you can try out the development build at https://github.com/xpipe-io/xpipe_staging/releases/tag/1.5.1. You have to delete your existing cluster connections and regenerate them by clicking on Local Machine -> Kubernetes.

I think it is apparent that I have not a lot of Kubernetes knowledge, so any related feedback is highly appreciated as I don't utilize it for my own use cases (mainly because it's too expensive). I even deleted the small EKS instance I used for testing because the monthly bill was quite high for it.

[hahn-kev]

This is great it's working much better now. The browse screen is a little confusing as it'll be loading but there's no indication. Also a minor thing but I have a production and staging environment with the same container names, so I can't tell which tab is for which cluster when they both have the same name. But that's a minor issue.

I can also connect to both of my contexts without issue now. It might be worth noting that k8s has namespaces, which is another layer that you might need to take account of eventually. Right now the default namespace of your context will be used which is probably fine for now.

One thing that is probably a bug is that each k8s cluster shows the name of the first one I opened in the status message:

notice how aws-rke is the status of each row, it should probably have the name of the respective row? I'm not really sure what that text is for but it looks weird here.

On the subject of testing k8s, there are multiple tools for running a cluster locally on your machine, then you don't have to pay for anything. It's usually close enough to a production envinronment for testing something like this. Here's how you can enable it in docker desktop.

Looking forward to 1.5.1 to be released! great work.

[hahn-kev]

One other thing I noticed is that any container commands assume that the sh shell is installed in the container. That might not be the case and it would be nice to be able to customize that (for example alpine containers only have the ash terminal)

[crschnick]

Also a minor thing but I have a production and staging environment with the same container names, so I can't tell which tab is for which cluster when they both have the same name.

I can just add a tooltip when you hover the tab name to show the full name/id here.

notice how aws-rke is the status of each row, it should probably have the name of the respective row? I'm not really sure what that text is for but it looks weird here.

I think I missed passing the appropriate context when querying the cluster name, that should be an easy fix.

On the subject of testing k8s, there are multiple tools for running a cluster locally on your machine, then you don't have to pay for anything. It's usually close enough to a production envinronment for testing something like this. Here's how you can enable it in docker desktop.

I actually use that, the limitation is that it is not real world environment. These context issues weren't really apparent for me as there was only one cluster/context for me for example.

One other thing I noticed is that any container commands assume that the sh shell is installed in the container. That might not be the case and it would be nice to be able to customize that (for example alpine containers only have the ash terminal)

I have seen that a few times, however I was under the impression that even if a container did not contain sh but another shell that at least sh was symlinked to that other shell.

Looking forward to 1.5.1 to be released! great work.

These changes will be included in 1.5.2, I just forgot to bump the version number in the test release as 1.5.1 is already out for a few days.

[crschnick]

Concerning namespaces, I think I can just pass --all-namespaces to some commands to cover all namespaces?

[crschnick]

So I released this build and it should include a proper tooltip in the file browser and the proper display name for all cluster contexts.