是否有一個kubernetes config parm（服務或rc或其他）在使用pod之前延遲

Question

我們針對託管2個小型（3容器）pod實例的集羣運行工作負載。使用w/nodeport服務訪問該窗格。如果我們停止一個pod並且rc啓動一個新的pod，那麼我們的常量（低容量）工作負載會有很多失敗（Rational Perf Tester，http測試會觸發主服務）主人也有奴才）。無論如何，如果我們只是添加kubectl規模的吊艙，我們也會得到錯誤。如果我們拿下這個吊艙（rc沒有開始一個吊艙，因爲我們有比因需要而需要的多一個吊艙）......沒有錯誤。似乎服務開始發送工作到新的吊艙，因爲儘管容器沒有啓動，但kubelet已經完成了他的工作。因此，任何時候一個吊艙開始了...它開始接受工作有點過早（在kubelet完成他的工作之後，但在所有容器準備就緒之前）。有沒有一種方法可以保證服務在所有容器都啓動之前不會路由到此容器？除非有什麼方法可以說，在發送到此Pod之前等待'n'秒？我可能是錯的，但行爲似乎表明了這種情況。

Answer 1

這正是readinessProbe選項是什麼:)

它的記錄更here和here，並且是一個豆莢裏的規範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