1

我们正在针对托管 2 个小型（3 个容器）pod 实例的集群运行工作负载。使用带有 nodeport 的服务访问 pod。如果我们停止一个 pod 并 rc 启动一个新的，我们的恒定（低容量）工作负载会出现许多故障（Rational Perf Tester，http 测试在主服务器上命中服务......但如果它命中任何一个 minion 可能相同......主人也有一个仆从）。无论如何，如果我们只是添加一个带有 kubectl scale 的 pod，我们也会得到错误。如果我们然后取下这个 pod（rc 不会启动一个新的，因为由于规模，我们有一个比需要的多）......没有错误。似乎服务开始将工作发送到新 pod，因为 kubelet 已经完成了他的工作，即使容器没有启动。因此，任何时候 Pod 启动......它开始接收工作有点过早（在 kubelet 完成他的工作之后，但在所有容器都准备好之前）。有没有办法保证在所有容器都启动之前服务不会路由到这个 pod？除非有某种方式可以说在发送到这个 pod 之前等待“n”秒吗？我可能错了，但行为似乎暗示了这种情况。

4

1 回答 1

3

这正是readinessProbe选项的含义:)

它在此处和此处进行了更多记录，并且是pod 规范中container定义的一部分。

例如，您可以使用如下所示的 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
于 2015-10-16T02:24:50.277 回答