kubent is reporting old apiVersion but kubectl says its updated

[red8888]

I did an apply to update some PodDisruptionBudget resources.

I ran kubent and it shows they were still outdated:

__________________________________________________________________________________________
>>> Deprecated APIs removed in 1.25 <<<
------------------------------------------------------------------------------------------
KIND                               NAMESPACE      NAME                                      API_VERSION      REPLACE_WITH (SINCE)
PodDisruptionBudget   test                      test                                          policy/v1beta1     policy/v1 (1.21.0)

I ran kubectl get poddisruptionbudget.v1.policy -A though and it returned the "test" PodDisruptionBudget

Does this mean kubent is wrong? How does it determine the apiVersion is outdated?

[mike-serchenia]

same for me on PodDisruptionBudget RoleBinding and some CustomResourceDefinition

update: updated manually or via terraform resources looks fine

update via argocd still appear in kubent report

[olsemenov]

@mike-serchenia I found the issue kubent validates annotations as well, and as argocd saves the previous state in annotations, that is why we have false-positive reports

[ayush-jain1]

Same for me its reporting false positives as its scanning annotation " kubectl.kubernetes.io/last-applied-configuration" and other server side "fields "

Any fix for it to get accurate date or any suggestion for alternate tool ? @olsemenov @mike-serchenia

[hpl002]

Any ideas on why its scanning kubectl.kubernetes.io/last-applied-configuration and not the actual api-version?

[stepanstipl]

Hi everyone,

so kubent does look only at the last-applied-configuration (or Helm in-cluster manifests if you use Helm). This is described in README and I've tried to explain it in https://github.com/doitintl/kube-no-trouble/issues/276#issuecomment-1062082004. This is due to how K8s work, and basically the original version used to create the resource is not preserved anywhere else (leaving aside newer managed fields for now).

As to kubectl - K8S will return the resource in the API version that was requested by the client, please see https://github.com/doitintl/kube-no-trouble/issues/276#issuecomment-1062928787. This version is independent of a) the version used when the resource was created and b) of the internal stored version.

TL;DR: If the kubectl.kubernetes.io/last-applied-configuration annotation contains old API version, it's expected behaviour this will be returned by kubent. This is how kubent works and I would say it's desirable, as it suggests the resource was created using the old API version, i.e. you will run into trouble if you try to do the same after cluster upgrade.

I hope it answers this issue, please check the annotation. And if it does not contain old API version there, please comment. Thanks 👍