Closed MoBlockbuster closed 1 year ago
Thank you for your efforts but this change seems to be incorrect. If CRIT > WARN (that's the common case) then your EXITCODE will never be 2. It will always be rewritten by the second WARN condition.
Indeed. It's a confusion on my side. I will close this PR. I am working on a solution to check the k8s-apissl expiredate. If the PKI certificate in a k8s cluster expires, the cluster will stop the services. therefore we need a check to avoid this situation. Do you have already a solution for it or can I develop the needed part?
It is barely achievable by K8s API. We check our TLS certificates (ca, etcd, calico, apiserver and whatever else) with custom scripts designed for our infra.
The K8s API use also the internal PKI TLS certificate to provide HTTPs. We can check the TLS certificate on port 6443 to check the expiredate of the internal PKI TLS certificate. We can use params like -w 30 (days) and -c 15 (days) to sent warning and critical alarms. This would be a own MODE.
The API cert in K8s: /etc/kubernetes/pki/apiserver.crt
I will close this PR now and open an new PR with the new MODE. Thank you for your support.
BR
modfiy the if-condition order to check the CRIT state at first. Otherwise we check the WARN at first and bypass the CRIT check because the WARN state will also be true if the $restart_count is actually in CRIT.