[Feature] Ability to see status of deployment, pods, access logs & exec into pods

[audip]

I'd to request a feature enhancement that allows more detailed information in the ArgoCD integration of Karmada. Let me describe what our current experience is like, where by default in ArgoCD a user is able to see the deployment, the pods underneath it along with the ability to look at pod logs and exec into the pod to run commands (if need be). Attached screenshot below shows an application in ArgoCD

What would you like to be added:

When looking at Karmada, this existing functionality goes obscure as resource bindings are shown in ArgoCD which lacks the ability to look at pod logs or exec into pods. This request is to add the functionality in Karmada such that ArgoCD can show pod level information, allow user to view logs and exec into containers.

Why is this needed:

Today, when switching to Karmada from ArgoCD ApplicationSet, the developer experience is worse as it obscures this information and users are having to connect to N clusters manually to see pod logs where their microservice is deployed & run commands to perform rolling restart. This will allow many companies to easily migrate from ArgoCD AppSet to Karmada.

[RainbowMango]

Hi @audip I'm one of the maintainers of the Karmada project, I'm very interested in this topic.
I'm exploring the differences between ArgoCD ApplicationSet and Karmada recently. Can you share your insights here?

Today, when switching to Karmada from ArgoCD ApplicationSet,

Also, I would like to understand the reasons for considering the transition from ApplicationSet to Karmda.

[audip]

We are very interested in using Karmada to manage our AWS EKS fleet of clusters and we use ApplicationSet to deploy an argo application to multiple clusters (which shows up as several apps in Argo UI). We'd like to move to use Karmada and not lose the existing functionality that allows us to access pod logs, exec into containers and see status of pods.

The reasons for us to move from Argo ApplicationSet to Karmada are to do pod scheduling at the fleet level, have one application in Argo that then manages it in several EKS clusters, do autoscaling across clusters, multi-cluster failover, and explore other use-cases.