为何在单个Kubernetes配置文件中需先定义Service再定义Deployment？

Great question! Let's unpack why this recommendation exists, even if your test with reversed order worked perfectly fine.

First, Clarifying the Official Documentation's Intent #

The docs state:

资源将按文件中出现的顺序创建。因此，最好先指定Service，这样可以确保调度器在控制器（如Deployment）创建Pod时，能够将与该Service关联的Pod进行调度分布。

This wording is a bit misleading—it’s not about the scheduler spreading Pods across nodes (your test confirms this: Pod scheduling to nodes depends on resource availability, node affinity, taints/tolerations, etc., not whether a Service exists). Instead, it’s focused on two key aspects of service reliability and consistency:

1. Timely Endpoint Registration #

When you create the Service first, the Kubernetes control plane immediately sets up the underlying EndpointSlice (or legacy Endpoints) resource tied to that Service. As soon as Pods from the Deployment start up, kubelet registers their IP addresses with the Service’s EndpointSlice right away. This means the Service can start routing traffic to new Pods almost instantly.

If you create the Deployment first, Pods may begin running before the Service exists. While Kubernetes will eventually sync the Pods to the Service once it’s created, there’s a small window where the Pods are live but not reachable via the Service. For production workloads where uptime is critical, this brief gap can cause unnecessary failed requests.

2. Consistent Service Environment Variables #

Kubernetes automatically injects environment variables for each Service in the same namespace into running Pods (e.g., INCORRECT_ORDER_SERVICE_HOST and INCORRECT_ORDER_SERVICE_PORT).

• If the Service exists when the Pod starts, these variables are injected at launch time.
• If the Service is created after the Pod, the variables won’t be present when the Pod initializes. While modern setups with dynamic DNS-based service discovery can work around this, applications that rely on these environment variables at startup will fail.

Your nginx test didn’t hit this issue because nginx doesn’t depend on these variables—it just listens on a port, and the Service finds it via labels later. But for custom applications that need to resolve the Service at boot time, this order becomes critical.

Why Your Reversed-Order Test Worked #

Your test with Deployment first worked for two simple reasons:

• Pod scheduling is independent of Service: The scheduler doesn’t consider Services when placing Pods on nodes—it only evaluates node resources, affinity rules, and other scheduling constraints. So your two nginx Pods still spread across nodes as expected.
• Nginx doesn’t require Service environment variables: Since nginx doesn’t use those injected variables to operate, it runs fine even if the Service is created later. The Service eventually picks up the Pods via label selectors once it exists.

Is This Recommendation Outdated? #

No, it’s still a valid best practice. While Kubernetes has improved (e.g., faster EndpointSlice syncing), creating the Service first eliminates edge cases like:

• Short-lived service unavailability when Pods start before the Service is ready
• Application failures due to missing environment variables at startup
• Race conditions in CI/CD pipelines where rapid deployments might exacerbate these gaps

For most production workloads, following this order ensures a more reliable and consistent deployment process.

内容的提问来源于stack exchange，提问作者yuppie-flu