cockpit-podman VS kind

Hey, I have homelab NUC server where I run different services as rootless podman pods and containers running by dedicated users, eg. nextcloud pod running by nextcloud user, gitea by gitea, znc by znc and more. Next step was trying to monitor these services. First trey was using cockpit-podman feature, but in UI I see only containers of my user and rootfull which both was empty. I cannot switch to another user because the're not capable for login to cockpit. Now I'm testing prometheus and podman-exporter which seems ok, but again I see containers only if I run prometheus-podman-exporter service as user who run another podman container (e.g. as nextcloud user). Of course I can run this service parallel as dedicated user with another port and add them as target to prometheus scrape config but from obvious reason I want to avoid that. Is it more gentle way to monitor my pods? I know that those namespaces are one of the main feature of Podman but I don't consider this before my deploys :)

Cockpit has a podman module (cockpit-podman)

Tested podman to replace docker (the cli) on a mac yesterday Most of it works fine. They have an easy way to setup a vm now with `podman machine`: https://podman.io/getting-started/installation#macos

If you want the management GUI, install cockpit: https://github.com/cockpit-project/cockpit-podman

Try podman, you'll be impressed.

To get started, you'll need to install clusteradm and kubectl and start up three Kubernetes clusters. To simplify cluster administration, this article starts up three kind clusters with the following names and purposes:

Kind: is a tool for running local Kubernetes clusters using Docker container "nodes." It was primarily designed for testing Kubernetes itself but can also be used for local development or continuous integration.

Fortunately, just as projects like kind and Minikube enable developers to spin up a local Kubernetes environment in no time, CRC, also known as OpenShift Local and a recursive acronym for "CRC - Runs Containers", offers developers a local OpenShift environment by means of a pre-configured VM similar to how Minikube works under the hood.

I recently purchased a used Lenovo M900 Think Centre (i7 with 32GB RAM) from eBay to expand my mini-homelab, which was just a single Synology DS218+ plugged into my ISP's router (yuck!). Since I've been spending a big chunk of time at work playing around with Kubernetes, I figured that I'd put my skills to the test and run a k3s node on the new server. While I was familiar with k3s before starting this project, I'd never actually run it before, opting for tools like kind (and minikube before that) to run small test clusters for my local development work.

Features compared to https://kind.sigs.k8s.io/

Kind allows you to run a Kubernetes cluster inside Docker. This is incredibly useful for developing Helm charts, Operators, or even just testing out different k8s features in a safe way.

Check out KinD

If you're just messing around, just use kind (https://kind.sigs.k8s.io) or minikube if you want VMs (https://minikube.sigs.k8s.io). Both work on ARM-based platforms.

You can also use k3s; it's hella easy to get started with and it works great.

We'll install APIClarity into a Kubernetes cluster to test our API documentation. We're using a Kind cluster for demonstration purposes. Of course, if you have another Kubernetes cluster up and running elsewhere, all steps also work there.

yes I know there is lens, but it does not allow me to see logs of multiple pods at same time and what is even more important it is not friendly for ephemeral clusters - in my case with help of kind I am recreating whole cluster each time from scratch