verbose output for cilium status command

[liyihuang]

Proposal / RFE

Is your feature request related to a problem?

no Describe the solution you'd like The current cilium status will only display some basic status from k8s perspective. I hope if we have cilium status --verbose we can grab the cilium status from the cilium agent pod

Here is the example of the cilium status from the pod

KVStore:                Ok   Disabled
Kubernetes:             Ok   1.26 (v1.26.3) [linux/arm64]
Kubernetes APIs:        ["cilium/v2::CiliumClusterwideNetworkPolicy", "cilium/v2::CiliumEndpoint", "cilium/v2::CiliumNetworkPolicy", "cilium/v2::CiliumNode", "core/v1::Namespace", "core/v1::Node", "core/v1::Pods", "core/v1::Service", "discovery/v1::EndpointSlice", "networking.k8s.io/v1::NetworkPolicy"]
KubeProxyReplacement:   Disabled
Host firewall:          Disabled
CNI Chaining:           none
CNI Config file:        CNI configuration file management disabled
Cilium:                 Ok   1.13.4 (v1.13.4-4061cdfc)
NodeMonitor:            Disabled
IPAM:                   IPv4: 2/254 allocated from 10.0.0.0/24,
IPv6 BIG TCP:           Disabled
BandwidthManager:       Disabled
Host Routing:           Legacy
Masquerading:           IPTables [IPv4: Enabled, IPv6: Disabled]
Controller Status:      11/12 healthy
  Name                    Last success   Last error   Count   Message
  ipcache-inject-labels   never          4s ago       3       k8s cache not fully synced
Proxy Status:                     OK, ip 10.0.0.97, 0 redirects active on ports 10000-20000
Global Identity Range:            min 256, max 65535
Hubble:                           Warning Server not initialized
Encryption:                       IPsec
Cluster health:                   0/2 reachable   (2023-08-18T03:15:59Z)
  Name                            IP              Node          Endpoints
  minikube/minikube (localhost)   192.168.49.2    reachable     unreachable
  minikube/minikube-m02           192.168.49.3    unreachable   reachable

[asauber]

We have had some feedback that cilium status takes too long to execute for large clusters. This seems potentially quite useful, but we would have to keep performance in mind.

[liyihuang]

Let me try to understand the performance you are referring to here.

If cilium status takes too long because of the cilium itself for some pods. I can only think of we can run cilium status in parallel in different goroutines and come back to the client with a fixed timeout and disregard the ones take too long.

thanks for the reminder

[asauber]

Imposing a cutoff time for the response from all agents is a great idea.

[liyihuang]

I personally think about this again. If the goal is to understand the overall status of the cilium, we can just pick one pod to run cilium status and return it.

I doubt the value of returning all of pods' output to the stdout...

more advanced troubleshooting should be done by https://github.com/cilium/cilium-cli/issues/1930

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[github-actions[bot]]

This issue has not seen any activity since it was marked stale. Closing.