为什么我应该在部署Kubernetes配置文件之前指定服务？

Question

我试图理解为什么kubernetes docs 建议在部署之前在一个配置文件中指定服务:

资源将按照它们在文件中出现的顺序创建.因此,最好先指定服务,因为这样可以确保调度程序可以在服务器创建服务时(例如部署)传播与服务关联的pod.

这是否意味着在kubernetes集群节点之间传播pod？

我使用以下配置进行测试,其中部署位于服务之前,并且在nod之间分配pod而没有任何问题.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: incorrect-order
  namespace: test
spec:
  selector:
    matchLabels:
      app: incorrect-order
  replicas: 2
  template:
    metadata:
      labels:
        app: incorrect-order
    spec:
      containers:
      - name: incorrect-order
        image: nginx
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: incorrect-order
  namespace: test
  labels:
    app: incorrect-order
spec:
  type: NodePort
  ports:
  - port: 80
  selector:
    app: incorrect-order

另一种解释是,在这种情况下,不会为pod设置一些带有服务URL的环境变量.但是,如果配置在一个文件中,如上例所示,它也可以正常工作.

您能否解释为什么在部署配置文件的情况下在部署之前指定服务更好？或者可能是一些过时的推荐.

Answer 1

如果DNS用作服务发现，则创建顺序无关紧要。

在Environment Vars（K8S 提供服务发现的第二种方式）的情况下，顺序很重要，因为一旦这些变量被传递到起始pod，如果服务定义发生变化，它们将无法在以后修改。

因此，如果您的服务在启动 Pod之前已部署，则服务 envvars 将被注入到链接的 Pod 中。

如果你创建一个带有标签的 Pod/Deployment 资源，这个资源将在最后一个创建后通过服务公开（使用适当的选择器来指示要公开的资源）。

Answer 2

您是正确的，它会影响工作节点之间的传播。

没有服务的部署将简单地调度到具有最少 CPU/内存分配的节点上。例如，一个全新的空节点将从新部署中获取所有新的 Pod。

对于还包含服务的部署，调度程序会尝试在节点之间分布 pod，而不考虑 cpu/内存负载（在限制范围内），以帮助服务更好地生存。

令我困惑的是，部署本身并不会导致最佳传播，但它不会，至少目前还没有。