Description

This bug affects gathering logs from nrk8s-ksm and nri-kube-events pods.

This script was originally written back when these pods had just one container. They now each have two containers, and so we need to specify which container to get logs from (both containers). Otherwise kubectl returns an error.

Steps to Reproduce

Install the New Relic chart bundle with newrelic-infrastructure and kube-events enabled.

Run kube-diag on the newrelic namespace.

Result: kube-diag tries to pull logs from certain pods that have sidecars, and fails because it doesn't pass container names.

Expected Behavior

kube-diag pulls logs from all the containers on these pods instead of failing to pull any

Relevant Logs / Console output

Logs from newrelic-bundle-nrk8s-ksm
*****************************************************
error: a container name must be specified for pod newrelic-bundle-nrk8s-ksm-1234, choose one of: [ksm forwarder]

*****************************************************

Logs from newrelic-bundle-nri-kube-events
*****************************************************
error: a container name must be specified for pod newrelic-bundle-nri-kube-events-1234, choose one of: [kube-events forwarder]

Your Environment

Kubernetes 1.26 (any supported Kubernetes with current nri-bundle will reproduce this)

For bring-your-own KSM installations, it would be great if kube-diag included a kubectl describe of the kube-state-metrics pod.

This would allow comparing the labels on the kube-state-metrics pod with the default scrape labels.

More: https://github.com/newrelic/helm-charts/blob/master/charts/nri-bundle/README.md#bring-your-own-ksm

Summary

kube-diag should warn if it sees that New Relic is installed to kube-system namespace. This is an antipattern - many direct references on internet including our blog post: https://newrelic.com/blog/how-to-relic/how-to-organize-kubernetes-clusters

Desired Behavior

Print a single warning line if kube-diag detects it is running against kube-system namespace (or if kube-diag autodetects that the chart was installed there).

Possible Solution

Parse namespace name.

Additional context

Beyond difficulty in maintenance of New Relic chart in system namespace, Installations here may experience unknown problems if cluster has special security on this system namespace.

Description

kube-diag is detecting EKS as 'self hosted'.

Steps to Reproduce

Run kube-diag against an EKS 1.25 cluster (maybe other versions too?)

Expected Behavior

kube-diag should report EKS for an EKS cluster.

Relevant Logs / Console output

Running kubediag on a EKS 1.25 cluster, it reports:

Kubernetes cluster flavor: Self-hosted

Additional context

Possible data to key off of:

• String eks appears clearly in kubelet version string,
• k8s.io/cloud-provider-aws= label name is present on node descriptions.

Summary

Check for ingress controllers and NetworkPolicy on cluster

Desired Behavior

kube-diag should be able to spot any installed ingress controllers, such as: Calico, nginx-ingress

We should also be able to see a list of NetworkPolicy names, so we can see if there are customizations on the cluster.

Possible Solution

• Check cluster for unique CRDs belonging to these packages (medium)
• kubectl get -A networkpolicy (easy)

Additional context

Issues with network configuration can be difficult to troubleshoot, this will help illuminate the presence of an ingress controller in the cluster, or any network policies beyond the norm.

Summary

kube-diag and pixie-diag should auto detect the New Relic and/or Pixie namespaces

Desired Behavior

The script should auto detect the namespace. If it cannot detect the namespace, it should prompt for input.

Possible Solution

Check newrelic and if it's not there, prompt for input.

Check for Pixie at: olm, px-operator, newrelic and pl.

Search for resources on the cluster and parse the namespace out.

Additional context

Sometimes the wrong namespace is targeted, this should help with that.