According to #23 this seems to have changed with Kubernetes 1.20, however I've just recently encountered this.
I have a single deployment in my cluster with an Available condition that is older in time than it's Progressing condition. Then check_kube_deployments.sh will always look at the Progressing condition and will always tell that it has an Unknown status even if it's just fine.
So this commit changes the sorting of the conditions to sort by .type instead of .lastTransitionTime, then it picks the first element (which hopefully is the one with the type Available), it also picks up the status from the same sorting and status. Then it checks if it matches Available-True or Available-False or is Unknown just as before.
This fixes #23.
According to #23 this seems to have changed with Kubernetes 1.20, however I've just recently encountered this.
I have a single deployment in my cluster with an Available condition that is older in time than it's Progressing condition. Then
check_kube_deployments.shwill always look at the Progressing condition and will always tell that it has an Unknown status even if it's just fine.So this commit changes the sorting of the conditions to sort by
.typeinstead of.lastTransitionTime, then it picks the first element (which hopefully is the one with the typeAvailable), it also picks up the status from the same sorting and status. Then it checks if it matchesAvailable-TrueorAvailable-Falseor isUnknownjust as before.