使用Readiness Probe和RollBack策略的Kubernetes 0停机不起作用 [英] Kubernetes 0 Downtime using Readiness Probe and RollBack strategy not working

查看:137
本文介绍了使用Readiness Probe和RollBack策略的Kubernetes 0停机不起作用的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我已经在Kubernetes上设置了一个Node应用程序.我正在运行一个副本,并且我希望在更新映像时的停机时间为0.我在Kubernetes上使用set Image更新了Pod.

I have set up a Node app on Kubernetes. I'm running a single replica and I want 0 down-time when the image is updated. I update my Pod using set Image on Kubernetes.

'set', 'image', 'deployment/dev-web'

这是我的YAML文件

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "2"
  generation: 2
  labels:
    io.kompose.service: dev-web
  name: dev-web
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      io.kompose.service: dev-web
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        io.kompose.service: dev-web
    spec:
      containers:
      - env:
        image: gcr.io/my-project-link/my-image-link
        imagePullPolicy: Always
        name: dev-web-container
        ports:
        - containerPort: 2000
          protocol: TCP
        readinessProbe:
          failureThreshold: 3
          httpGet:
            path: /
            port: 2000
            scheme: HTTP
          initialDelaySeconds: 5
          periodSeconds: 5
          successThreshold: 1
          timeoutSeconds: 1
        resources:
          requests:
            cpu: 20m
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
status:
  availableReplicas: 1
  conditions:
  - lastTransitionTime: 2018-12-07T11:13:21Z
    lastUpdateTime: 2018-12-07T11:13:21Z
    message: Deployment has minimum availability.
    reason: MinimumReplicasAvailable
    status: "True"
    type: Available
  observedGeneration: 2
  readyReplicas: 1
  replicas: 1
  updatedReplicas: 1

我的应用程序确实对'/'给出200响应,因此Readiness Probe可以工作,但是当我更新图像并对其进行测试但不断命中CURL时,它使我的停机时间长达20-40秒.

My app does give 200 response on '/' get therefore Readiness Probe works but when I update the Image, and test it but continuously hitting CURL, it gives me downtime which lasts for like 20-40 seconds.

推荐答案

即使只有一个副本,您也将maxUnavailable设置为1,您应该将maxUnavailable设置为0.

You setup your maxUnavailable as 1 even when you have only one replica, you should be having maxUnavailable to 0.

strategy:
 type: RollingUpdate
 rollingUpdate:
   maxUnavailable: 0
   maxSurge: 1

它基本上告诉Kubernetes,部署(maxUnavailable: 0)时应该有零个不可用的Pod,并且一次(maxSurge: 1)应该一次有一个新Pod.

It basically tells Kubernetes that there should be zero unavailable pods while deploying (maxUnavailable: 0) and there should be one new pod at a time (maxSurge: 1).

我希望您设置readiness探针是这样的:

I am hoping you setup the readiness probe something like this:

readinessProbe:
  httpGet:
    path: /
    port: 80
  initialDelaySeconds: 5
  periodSeconds: 5
  successThreshold: 1

基本上,这是Kubernetes进行的检查,以确保您的Pod已准备好向其发送流量.在尚未准备好之前,Kubernetes不会使用您的Pod.

Basically, this is a check that Kubernetes does in order to make sure that your pod is ready to send traffic to it. Until it is not ready, Kubernetes will not use your pod.

这篇关于使用Readiness Probe和RollBack策略的Kubernetes 0停机不起作用的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆