service - 在使用Pod之前是否有kubernetes配置参数(服务，rc或其他)要延迟

Question

我们正在针对承载2个小容器(3个容器)的实例的集群运行工作负载。使用w / nodeport服务访问pod。如果我们停止Pod，而rc启动了一个新Pod，那么我们的恒定(低容量)工作负载就会出现许多故障(Rational Perf Tester，http测试在主服务器上击中了服务……但是如果它击中了任何一个奴隶，则可能会...师父也有一个奴才)无论如何，如果我们仅添加一个具有kubectl比例的容器，我们也会收到错误消息。如果我们随后拆下该 pods (rc不会启动一个新 pods ，因为由于规模原因我们的 pods 多于所需的 pods )...没有错误。似乎服务开始将工作发送到新的Pod，因为kubelet已经完成了他的工作，即使容器没有启动。因此，只要 pods 启动，它就会开始接收工作太早(在kubelet完成工作之后，但在所有容器准备就绪之前)。有没有办法保证在所有容器都装满之前，服务不会路由到该容器？除非有某种方式说要等'n'秒才能发送到此Pod？我可能是错的，但是行为似乎暗示了这种情况。

Answer 1

这正是readinessProbe选项的含义:)

它记录了更多的here和here，并且是pod规范中 container definition的一部分。

例如，您可以使用如下所示的Pod规范，以确保您的Nginx Pod在响应HTTP请求/index.html之前不会被标记为就绪(因此不会向其发送流量):

apiVersion: v1
kind: ReplicationController
metadata:
  name: my-nginx
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
        lifecycle:
          httpGet:
            path: /index.html
            port: 80
          initialDelaySeconds: 10
          timeoutSeconds: 5