proxy: followup to last-queued-change metric

[squeed]

Fixes two small issues with the metric added in #90175:

1. Bump the timestamp on initial informer sync. Otherwise it remains 0 if restarting kube-proxy in a quiescent cluster, which isn't quite right.
2. Bump the timestamp even if no healthz server is specified.

/kind cleanup

What this PR does / why we need it:
The metrics introduced in #90175 don't quite match expectations.

Does this PR introduce a user-facing change?:
No, because this has not yet been released.

NONE

[squeed]

/sig network

[squeed]

/cc @danwinship @dcbw

[danwinship]

Bump the timestamp on initial informer sync. Otherwise it remains 0 if restarting kube-proxy in a quiescent cluster, which isn't quite right.

But there's still a race condition at startup even with this patch isn't there? If you look at the metrics before the initial sync, you'll get nonsense?

I'm not sure what the expected behavior for timestamp metrics in this case is...

Kube-proxy always forces a resync shortly after startup, so arguably just starting up kube-proxy counts as requesting a proxy sync, and it might be reasonable to just set SyncProxyRulesLastQueuedTimestamp at startup...

[squeed]

But there's still a race condition at startup even with this patch isn't there? If you look at the metrics before the initial sync, you'll get nonsense?

I'm not sure what the expected behavior for timestamp metrics in this case is...

It is indeed awkward for all "gauge" metrics. Now that Prometheus handles stale metrics better, the convention is to not report an unobserved metric. Unfortunately, the existing library (and the k8s wrapper around it) makes this somewhat awkward. I'm asking around to see if there's a reasonable way to do this.

Kube-proxy always forces a resync shortly after startup, so arguably just starting up kube-proxy counts as requesting a proxy sync, and it might be reasonable to just set SyncProxyRulesLastQueuedTimestamp at startup...

Yeah, that might be the right thing to do. Arguably, for a running system, the user doesn't care about the difference between a slow informer sync and a slow iptables sync. Either way, there's latency.

[squeed]

OK, updated to bump the timestamp on proxy startup.

[ksubrmnn]

@JocelynBerrendonner @dineshgovindasamy FYI

[danwinship]

/lgtm

[squeed]

/retest

[squeed]

Update: I asked around, and prometheus client-go doesn't currently have an ergonomic way of exposing a Gauge (timestamp) that has no value until first observed. In this particular case, we don't care anymore since we're bumping the value on startup.

[danwinship]

oh forgot that I have to say
/approve
too

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: danwinship, squeed

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• pkg/proxy/OWNERS [danwinship]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[fejta-bot]

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to fejta).

Review the full test history for this PR.

Silence the bot with an /lgtm cancel or /hold comment for consistent failures.

[fejta-bot]

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to fejta).

Review the full test history for this PR.

Silence the bot with an /lgtm cancel or /hold comment for consistent failures.

[fejta-bot]

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to fejta).

Review the full test history for this PR.

Silence the bot with an /lgtm cancel or /hold comment for consistent failures.

[k8s-ci-robot]

@squeed: The following test failed, say /retest to rerun all failed tests:

Test name	Commit	Details	Rerun command
pull-kubernetes-e2e-gci-gce-ipvs	042daa2	link	/test pull-kubernetes-e2e-gci-gce-ipvs

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

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. I understand the commands that are listed here.