Any plans to add an open source license (Apache 2.0, MIT, etc) to this repo?

Hi,

I've been using this script for a while and it has been working great. But I've had some issues with the deployment script as it seems like .status.conditions[-1] has changed to .status.conditions[0] on all of my deployments except for coredns.

Example deployment 1:

    "availableReplicas": 1,
    "conditions": [
      {
        "lastTransitionTime": "2021-11-01T13:00:41Z",
        "lastUpdateTime": "2021-11-01T13:00:41Z",
        "message": "Deployment has minimum availability.",
        "reason": "MinimumReplicasAvailable",
        "status": "True",
        "type": "Available"
      },
      {
        "lastTransitionTime": "2021-11-01T13:51:56Z",
        "lastUpdateTime": "2021-11-29T15:04:01Z",
        "message": "ReplicaSet \"snapshot-controller-786647474f\" has successfully progressed.",
        "reason": "NewReplicaSetAvailable",
        "status": "True",
        "type": "Progressing"
      }
    ],

Example deployment 2:

    "availableReplicas": 2,
    "conditions": [
      {
        "lastTransitionTime": "2021-11-01T13:51:25Z",
        "lastUpdateTime": "2021-11-01T13:51:32Z",
        "message": "ReplicaSet \"coredns-8474476ff8\" has successfully progressed.",
        "reason": "NewReplicaSetAvailable",
        "status": "True",
        "type": "Progressing"
      },
      {
        "lastTransitionTime": "2021-11-01T13:51:32Z",
        "lastUpdateTime": "2021-11-01T13:51:32Z",
        "message": "Deployment has minimum availability.",
        "reason": "MinimumReplicasAvailable",
        "status": "True",
        "type": "Available"
      }
    ],

This causes my check to get this result:

$ ./check_kube_deployments.sh -n kube-system
Unknown: snapshot-controller has condition Progressing: True - ReplicaSet "snapshot-controller-786647474f" has successfully progressed.
Unknown: dns-autoscaler has condition Progressing: True - ReplicaSet "dns-autoscaler-7df78bfcfb" has successfully progressed.
Unknown: csi-cinder-controllerplugin has condition Progressing: True - ReplicaSet "csi-cinder-controllerplugin-74d8dd876d" has successfully progressed.
OK: coredns has condition Available: True - Deployment has minimum availability.

Anyone else had this issue before?

/kind feature

The curl methods are clean however only the netrc authentication method is possible. We have a need for authentication using native Kubernetes Service Account tokens.

Feature request: Add an optional input parameter for token based authentication

Usage ./check_kube_nodes.sh [-t <TARGETSERVER> -c <CREDENTIALSFILE> -b <BEARERTOKEN>] [-k <KUBE_CONFIG>]

K8STATUS="$(curl -sS $SSL --header "Authorization: Bearer $BEARERTOKEN" $TARGET/api/v1/nodes)"

Hi,

check_kubernetes.sh -m components fails with Kubernetes 1.19 with the following error:

parse error: Invalid numeric literal at line 1, column 8

It seems to be caused by a warning message displayed before the JSON payload after calling api/v1/componentstatuses:

Warning: v1 ComponentStatus is deprecated in v1.19+{"apiVersion": "v1","items":...

Due to #23 checking all namespaces got 2 unknown entries .. at least it should.
The actual output is somewhat messed up:

$ ./check_kube_deployments.sh
Unknown: deployment#1 has condition Progressing: True - ReplicaSet "deployment#1-77db4cb58c" has successfully progressed.
OK: deployment#2 has condition Available: True - Deployment has minimum availability.
OK: deployment#3 has condition Available: True - Deployment has minimum availability.
OK: deployment#4 has condition Available: True - Deployment has minimum availability.
OK: deployment#5 has condition Available: True - Deployment has minimum availability.
Unknown: deployment#6 has condition Progressing: True - ReplicaSet "deployment#6-78994478dc" has successfully progressed.
OK:deployment#7 has condition Available: True - Deployment has minimum availability.
OK: deployment#8 has condition Available: True - Deployment has minimum availability.
OK: deployment#9 has condition Available: True - Deployment has minimum availability.
OK: deployment#10 has condition Available: True - Deployment has minimum availability.
OK: deployment#11 has condition Available: True - Deployment has minimum availability.
OK: deployment#12 has condition Available: True - Deployment has minimum availability.
OK: deployment#13 has condition Available: True - Deployment has minimum availability.
OK: deployment#14 has condition Available: True - Deployment has minimum availability.
OK: deployment#19 has condition Available: True - Deployment has minimum availability.
Unknown: deployment#15 has condition Available
Available: True
True - Deployment has minimum availability.
Deployment has minimum availability.
OK: deployment#16 has condition Available: True - Deployment has minimum availability.
OK: deployment#17 has condition Available: True - Deployment has minimum availability.
Unknown: deployment#18 has condition Available
Available: True
True - Deployment has minimum availability.
Deployment has minimum availability.
Unknown: deployment#15 has condition Available
Available: True
True - Deployment has minimum availability.
Deployment has minimum availability.
Unknown: deployment#18 has condition Available
Available: True
True - Deployment has minimum availability.
Deployment has minimum availability.

note the duplicated deployment#15, also there should be only 2 Unknown entries (checked by namespace and found two with the issue früm #23)

kubectl proxy in kubernetes_api_check.sh may fail due to an already bound port 8001.

In that case there may already be a check running which proxies to a completely different cluster. In effect we are then checking one cluster only rather than failing (or allowing parallel cluster checks).

/kind bug

The Deployment resource API post k8s 1.16 is /apps/v1. /extensions/v1beta1/ is deprecated.

Parameterize API versions as variable within shell scripts to accommodate

from:
/apis/extensions/v1beta1/
to:
/apis/apps/v1/

Hi,
i want to watch my cluster from an Icinga master and not in the other direction =/

Current situation :
My cluster doesn't have public IP and he is not in the same network from my icinga master (master got public ip and Agent use AWS tools too comunicate with ext.).

Can we run the "script" and command from my cluster directly, to send informations to my icinga master.

I know its complicated to explain but i want know if i can send kube status form my cluster to my icinga master. In this case agent icinga send informations to master icinga but master icinga has nothing to do except display on icingaweb2, because i can't sent check_command to my icinga agent from master.

thanks for your help

The script reports "OK" even if a node is down, if docker is down or if the Kubelet has crashed or entered an error condition.

In this case, I stopped the Kubelet on docker02, but the script says the node is OK.

$ kubectl get nodes
NAME        STATUS       ROLES                      AGE    VERSION
docker01   Ready          controlplane,etcd,worker   421d   v1.17.4
docker02   NotReady   controlplane,etcd,worker   421d   v1.17.4
docker03   Ready          controlplane,etcd,worker   421d   v1.17.4

$ ./check_kube_nodes.sh -k kube_config_cluster.yml
OK - Kubernetes nodes all OK
$

We should prevent this error:

$ ./check_kube_nodes.sh
./check_kube_nodes.sh: line 48: kubectl: command not found
CRITICAL - unable to connect to Kubernetes via kubectl!

Hello Team,

I'm trying to set up monitoring of Kubectl cluster using this article https://github.com/colebrooke/kubernetes-nagios

I came a weird Issues. I have the Kubectl cluster running on Remote RHEL server. When I try to run the scripts locally using NRPE it works.
From Remote server locally.
/usr/local/nagios/libexec/check_pods.sh -k -n -w 500 -C 800
OK - pods are all OK, found 2 in state.

Same command using nrpe plugin on remote server too
/usr/local/nagios/libexec/check_nrpe -H localhost -c check_pod_cjoc
NRPE: Unable to read output

So I have defined a command definition in nrpe.cfg & restarted NRPE agent on the Remote server.

When I try to invoke this script from Nagios server. I'm getting "NRPE: Unable to read output" error.

From Nagios Server
/usr/local/nagios/libexec/check_nrpe -H -c check_pod_cjoc
NRPE: Unable to read output

I have tested with two versions of NRPE agent i.e 3.2.1 & 4.0.3, I didn't try with other versions, but getting same error message

Note: Nagios user has admin(sudo) rights to run these scripts on Remote server.

Nagios running is running on v4.4.5 on RHEL server.

Let me know if you need more information. Can you guys please look at it. @ericloyd @sawolf
######Stay Home#######Stay Safe#########
Thanks,
Srikanth

/kind feature

Cater for more resource types:

Either:
A. Clone check_kube_deployments.sh to check_kube_statefulsets.sh and check_kube_daemonsets.sh and update the specific differences where needed.

B. Modify check_kube_deployments.sh to gather status for all resource types (deployments, statefulsets and daemonsets) within the same namespace.

In favor of option B because:

• Less input variables required for Nagios operators & consumers.
• Likely kubernetes operators are interested in all failures within a namespace and not a partial view.