在创建时是否根据支持服务定义了Kubernetes / GKE默认健康状况探针?

时间:2018-10-15 11:25:47

标签: kubernetes gcloud google-kubernetes-engine

背景:我有一个客户导向的Web应用程序,该应用程序将与Kubernetes一起部署在GKE上。与此类应用程序一样,我想将流量从http重定向到https。

在过去,我会用haproxy或nginx来做,但是现在我想在Kubernetes中做。由于某种原因,阅读该主题似乎很困难。 https://github.com/kubernetes/ingress-gce/tree/2d2c91a608987d07205c4a93537c2938bc67df38#ingress-cannot-redirect-http-to-https

因此,我决定只允许http进入我的webapp,并让我的app中的第一线中间件进行重定向。我读到GKE会像nginx一样设置x-forward-proto标头。

所以我在node + koa应用程序中做了类似的事情:

app.use((ctx, next) => {
  if (ctx.request.header['x-forwarded-proto'] === 'https') {
    return next()
  } else {
    const httpsHost = url.parse('http://' + ctx.request.header.host).hostname
    let redirectTo = 'https://' + httpsHost
    redirectTo += ctx.request.url
    ctx.response.status = 307
    ctx.response.redirect(redirectTo)
  }
})

这似乎在几分钟/几秒钟内都能正常工作,但是随后我的Ingress被标记为不好:

enter image description here

我很难解释GCloud控制台中的状态,但是它似乎是默认的运行状况检查服务,因为我要在内部http运行状况检查上重定向307,所以该服务失败了:

enter image description here

请注意此处的根路径。

我终于能够通过手动在部署中自行指定探针来解决此问题

    readinessProbe:
      httpGet:
        path: /healthz
        port: 5002
    livenessProbe:
      httpGet:
        path: /healthz
        port: 5002

并在应用程序中照顾它们:

router.get('/healthz', ctx => {
  console.log([ctx.request.headers]) //eslint-disable-line
  ctx.response.status = 200
})

由此我得到了健康状况探针的另一种定义:

enter image description here

有了新版本的我的应用程序,我就可以解决这个问题,一切都很顺利。

最让我感到困惑的是,我仍然想知道的是,作为Ingress一部分创建的默认探针在Deployment的更改中是持久的。我的意思是,在根据支持部署更新运行状况探测器之前,我需要拆除Ingress并重新创建它。仅更改定义了此位置的部署并不会重新创建运行状况探测服务的状态,并且它仍然与/冲突。这使得调试这件事变得很困难。

我已经仔细检查了在任何方向上都仍然存在这种情况。我删除了探针设置并重新应用了Deployment,但是由于运行状况检查服务仍与/ healthz抵触,因此一切仍可以正常工作。但是,执行kubectl delete ingress; kubectl create -f ingress.yml后,它又开始与/抵触并失败。因此,基本上从支持服务的角度定义了入口。这不是不好吗?

我仍然想了解的是:

  1. 这是Kubernetes还是GKE?
  2. 是否可以在不定义我自己的情况下禁用默认的运行状况检查?
  3. 是否有更好/更清洁的方法来实现我想要的基本目标?

1 个答案:

答案 0 :(得分:0)

这是由Google管理的kubernetes,因此为什么要使用Google kubernetes引擎。

如果要删除或添加运行状况检查问题,可以运行kubectl edit deployment <your deployment>,当前运行的部署中的Yaml应该在默认编辑器中弹出,然后编辑(添加/删除探针)。

对您来说,更好的解决方案是使用 reverse proxy in NGINX here和示例和配置将http重定向到https。