kube_pod_status_ready is 2s late than pod.condistions.Ready timestamp

[qingguee]

What happened:
Hello,
Because missing pod ready timestamp metrics, I am using kube_pod_status_ready to monitoring pod ready.
I use http API query kube_pod_status_ready , then find the ready timestamp by go though the metrics data. When detect value is 1, then return the timestamp.
But after double check the ready timestamp from "kubectl get po xxx -o yaml" , it seems the metrics status value is always 2s late than the real ready timestamp from pod condition Ready.

For example,from "kubectl get po <xxx_pod_name> -o yaml"

status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2022-09-08T01:15:36Z"
    status: "True"
    type: Initialized
  - lastProbeTime: null
    lastTransitionTime: "2022-09-08T01:20:36Z"
    status: "True"
    type: Ready

Prometheus config, I am using 1s as scrape_interval.

- job_name: kubernetes-service-endpoints
  honor_timestamps: true
  scrape_interval: 1s
  scrape_timeout: 1s
  metrics_path: /metrics
  scheme: http

But from metrics result, I got below

],
        [
            1662600037,
            "0"
        ],
        [
            1662600038,    <<== This is the timestamp pod ready from kube_pod_status_ready 
            "1"
        ],
        [
            1662600039,
            "1"
        ],

I also checked the source code, looks like everything is correct.

kube-state-metrics/internal/store/pod.go

Line 1299 in 20ef8a7

"kube_pod_status_ready",

What you expected to happen:
Is there a way to get ready timestamp more accurate?
Because I need calculate the startup time for a pod, I will need to know when the pod become ready.

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

Environment:

• kube-state-metrics version:
• Kubernetes version (use kubectl version):
• Cloud provider or hardware configuration:
• Other info:

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.