2016-05-02 2 views
0

При запуске развертывания я получаю время простоя. Запросы терпят неудачу после переменного количества времени (20-40 секунд).При развертывании Kubernetes происходит простои

Проверка готовности контейнера ввода не выполняется, когда preStop отправляет SIGUSR1, ждет 31 секунду, а затем отправляет SIGTERM. В течение этого периода блок должен быть удален из службы, поскольку проверка готовности установлена ​​на неудачу после 2 неудачных попыток с 5-секундными интервалами.

Как я могу видеть события для добавления и удаления контейнеров из службы, чтобы узнать, что вызывает это?

И события вокруг готовности проверяют себя?

Я использую Google Container Engine версии 1.2.2 и использую балансировку сетевой нагрузки GCE.

обслуживание:

apiVersion: v1 
kind: Service 
metadata: 
    name: myapp 
    labels: 
    app: myapp 
spec: 
    type: LoadBalancer 
    ports: 
    - name: http 
    port: 80 
    targetPort: http 
    protocol: TCP 
    - name: https 
    port: 443 
    targetPort: https 
    protocol: TCP 
    selector: 
    app: myapp 

развертывание:

apiVersion: extensions/v1beta1 
kind: Deployment 
metadata: 
    name: myapp 
spec: 
    replicas: 3 
    strategy: 
    type: RollingUpdate 
    revisionHistoryLimit: 10 
    selector: 
    matchLabels: 
     app: myapp 
    template: 
    metadata: 
     labels: 
     app: myapp 
     version: 1.0.0-61--66-6 
    spec: 
     containers: 
     - name: myapp 
     image: **** 
     resources: 
      limits: 
      cpu: 100m 
      memory: 250Mi 
      requests: 
      cpu: 10m 
      memory: 125Mi 
     ports: 
     - name: http-direct 
      containerPort: 5000 
     livenessProbe: 
      httpGet: 
      path: /status 
      port: 5000 
      initialDelaySeconds: 30 
      timeoutSeconds: 1 
     lifecycle: 
      preStop: 
      exec: 
       # SIGTERM triggers a quick exit; gracefully terminate instead 
       command: ["sleep 31;"] 
     - name: haproxy 
     image: travix/haproxy:1.6.2-r0 
     imagePullPolicy: Always 
     resources: 
      limits: 
      cpu: 100m 
      memory: 100Mi 
      requests: 
      cpu: 10m 
      memory: 25Mi 
     ports: 
     - name: http 
      containerPort: 80 
     - name: https 
      containerPort: 443 
     env: 
     - name: "SSL_CERTIFICATE_NAME" 
      value: "ssl.pem"   
     - name: "OFFLOAD_TO_PORT" 
      value: "5000" 
     - name: "HEALT_CHECK_PATH" 
      value: "/status" 
     volumeMounts: 
     - name: ssl-certificate 
      mountPath: /etc/ssl/private 
     livenessProbe: 
      httpGet: 
      path: /status 
      port: 443 
      scheme: HTTPS 
      initialDelaySeconds: 30 
      timeoutSeconds: 1 
     readinessProbe: 
      httpGet: 
      path: /readiness 
      port: 81 
      initialDelaySeconds: 0 
      timeoutSeconds: 1 
      periodSeconds: 5 
      successThreshold: 1 
      failureThreshold: 2 
     lifecycle: 
      preStop: 
      exec: 
       # SIGTERM triggers a quick exit; gracefully terminate instead 
       command: ["kill -USR1 1; sleep 31; kill 1"] 
     volumes: 
     - name: ssl-certificate 
     secret: 
      secretName: ssl-c324c2a587ee-20160331 

ответ

1

Когда зонд не удается, тестовые пробники будут выдавать предупреждающее событие с разумом, как Unhealthy и сообщения как xx probe errored: xxx.

Вы должны быть в состоянии найти эти события, используя kubectl get events или kubectl describe pods -l app=myapp,version=1.0.0-61--66-6 (фильтры по его метке).

+0

Что я заметил до сих пор, так это то, что у моих новых контейнеров «Сбой готовности» не удалось: HTTP-запрос не прошел со статусом: 503 »в качестве последнего события. Я ожидаю, что за этим последует сообщение о том, что оно здорово и готово к приему трафика. –

Смежные вопросы