Why KubeDeploymentReplicasMismatch use ReplicaAvailable instead of ReplicaReady?

[awcodify]

I have a question regarding a specific rule in the kube-prometheus repository and would like to initiate a discussion to gain more insights.

The rule in question can be found here:

kube-prometheus/manifests/kubernetesControlPlane-prometheusRule.yaml

Lines 53 to 70 in d388980

	- alert: KubeDeploymentReplicasMismatch
	annotations:
	description: Deployment {{ $labels.namespace }}/{{ $labels.deployment }} has not matched the expected number of replicas for longer than 15 minutes.
	runbook_url: https://runbooks.prometheus-operator.dev/runbooks/kubernetes/kubedeploymentreplicasmismatch
	summary: Deployment has not matched the expected number of replicas.
	expr: |
	(
	kube_deployment_spec_replicas{job="kube-state-metrics"}
	>
	kube_deployment_status_replicas_available{job="kube-state-metrics"}
	) and (
	changes(kube_deployment_status_replicas_updated{job="kube-state-metrics"}[10m])
	==
	0
	)
	for: 15m
	labels:
	severity: warning

My question is why are we comparing kube_deployment_spec_replicas with kube_deployment_status_replicas_available in this alert rule?

Based on the information provided in the Kubernetes API documentation:

• AvailableReplicas represents the total number of pods that are available for scheduling on nodes, regardless of whether they have passed their readiness checks yet.
• ReadyReplicas represents the number of pods that are targeted by the Deployment with a Ready Condition.

If I understand correctly, comparing kube_deployment_spec_replicas with kube_deployment_status_replicas_available could potentially lead to false alarms, as the alert would trigger even if pods have been scheduled on nodes but have not yet passed their readiness checks. Wouldn't it be more appropriate to compare kube_deployment_spec_replicas with kube_deployment_status_replicas_ready instead?

For context: I need an alert to make sure there's no performance degradation (or down) of my application while the pod is already have traffic. Currently, i have a prober in blackbox exporter which also hit to the application health check. Since our deployment readinessProbe is also hitting to the same health check, i'm thinking about removing the blackbox exporter probe and only using state from deployment.

Thank you.

[awcodify]

Is it because the alert's focus is not to determine whether there is an issue with the pod or not after serving the traffic, but rather to ensure that the deployment itself is not experiencing any problems? Means this alert is focusing state before -> deployed state instead of after deployment success?