Question

我们正在针对托管2个小型（3个容器）pod实例的群集运行工作负载。使用带有nodeport的服务访问pod。如果我们停止一个pod并且rc启动一个新的，我们的常量（低容量）工作负载有很多失败（Rational Perf Tester，http测试击中主服务器上的服务......但如果它遇到任何一个minion可能相同...主人也有一个奴才）。无论如何，如果我们只添加一个具有kubectl规模的pod，我们也会收到错误。如果我们然后取下这个pod（rc没有启动一个新的因为我们因为规模而有一个比需要的更多）......没有错误。似乎服务开始将工作发送到新的pod，因为kubelet完成了他的工作，即使容器没有启动。因此，无论何时启动吊舱......它都会很快开始接收工作（在kubelet完成他的工作之后，但在所有容器准备好之前）。有没有办法保证在所有容器启动之前服务不会路由到此pod？除非有一些方法可以说在发送到这个吊舱前等待'n'秒？我可能错了，但行为似乎暗示了这种情况。

Answer 1

这正是readinessProbe选项的原因：）

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

例如，您可以使用类似下面的pod规范来确保您的nginx pod不会被标记为就绪（因此不会向其发送流量），直到它响应为/index.html的HTTP请求：

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

在使用pod之前是否有kubernetes config parm（service或rc或其他）延迟

1 个答案: