标签: kubernetes-health-check

我想永久删除一个pod,所以我可以再次从fresh创建deployment.yaml和derveice.yaml,所以我尝试了:

 kubctl delete pod <pod>

并且pod仍在那里,也尝试过:

kubectl delete pods <pod> --grace-period=0

并没有奏效.

唯一有效的是当我设置部署replicas: 0然后应用它时,但是当我尝试创建新部署时,我得到:

服务器出错:创建"myService/deployment.yaml"时出错:deployments.extensions"myService"已经存在

我有一个简单的Kubernetes部署.它由一个未复制的单个容器组成.没有服务暴露容器.容器具有运行状况检查,该检查检查它是否已正确配置并可与其外部依赖项进行通信.我使用更新部署kubectl apply.

更新部署后,我想检查新版本是否已完全推出并正在通过其运行状况检查.我无法弄清楚如何配置我的部署来实现这一目标.

我尝试了各种活动和准备探测,部署策略和就绪/进度部署属性的组合.我已经尝试检查部署状态,其pod和rollout命令.一切都无济于事.

我得到的印象是我应该查看部署条件以了解状态,但我无法找到有关这些条件是什么或如何实现这些条件的明确文档.

我有一个运行状况检查端点/status返回以下状态代码和响应正文:

• 健康 - 200 OK
• 退化 - ?
• 不健康 - 503 Service Unnavailable

HTTP状态代码对于降级响应应该是什么？"降级"检查用于成功但速度缓慢或不稳定的检查.什么HTTP状态代码最有意义？

我有一个在 kubernetes (GKE) 上运行的非常简单的 Flask 应用程序。Pod 获得了相当多的流量 (60req/s +-)，并且它们在至少 4 个活动和 10 个最大的自动缩放组下运行。

每隔 4-5 小时，活性探测就会开始失败，所有 pod 都会重新启动。我有时会发现我的 Pod 在一个晚上会重启 11-12 次。当我描述豆荚时，我得到了同样的错误：

Liveness probe failed: Get http://10.12.5.23:5000/_status/healthz/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

所有 pod 都具有相同的重启次数，因此这不是负载问题（而且我也有自动缩放功能）。

该_status/healthz/端点很简单，因为它得到：

@app.route('/')
@app.route('/_status/healthz/')
def healthz():
    return jsonify({
        "success": True
    })

我在此应用程序上还有另一条路由，它连接到 mysql 并验证一些数据。我将相同的应用程序分布在 digitalocean droplets 上，并在更高的负载下运行数月而没有出现问题。

我似乎无法找出为什么活性检查开始失败一次并且我的 pod 重新启动。

分配的资源也不错，与我在 digitalocean droplets 上的资源非常接近：

"resources": {
    "requests": {
        "cpu": "500m",
        "memory": "1024Mi"
    },
    "limits": {
        "cpu": "800m", …

我正在努力在 Kubernetes 文档中找到任何答案。场景如下：

• 基于 AWS 的 Kubernetes 1.4 版
• 8 个运行 NodeJS API (Express) 的 Pod，部署为 Kubernetes Deployment
• 其中一个 Pod 在深夜无缘无故地重新启动（没有流量、没有 CPU 峰值、没有内存压力、没有警报……）。因此，重新启动的次数会增加。
• 日志没有显示任何异常（运行kubectl -p查看以前的日志，那里根本没有错误）
• 资源消耗正常，看不到任何关于Kubernetes将pod重新调度到另一个节点或类似的事件
• 描述 pod 返回TERMINATED状态、返回COMPLETED原因和退出代码 0。我没有确切的输出，kubectl因为这个 pod 现在已被多次更换。

pods 是 NodeJS 服务器实例，它们无法完成，它们总是在运行等待请求。

这会是 Kubernetes 内部对 pod 的重新排列吗？有没有办法知道这种情况何时发生？不应该是某个地方的事件说明它为什么发生吗？

更新

这只是发生在我们的生产环境中。描述违规 pod 的结果是：

api: Container ID: docker://7a117ed92fe36a3d2f904a882eb72c79d7ce66efa1162774ab9f0bcd39558f31 Image: 1.0.5-RC1 Image ID: docker://sha256:XXXX Ports: 9080/TCP, 9443/TCP State: Running Started: Mon, 27 Mar 2017 12:30:05 +0100 Last State: Terminated Reason: …

我有一个带有两个节点的 kubernetes 集群，还有两个用于 etcd 的节点，而且我正在对我的 kubernetes 使用身份验证。当我运行此命令时：kubectl get cs我得到以下输出：

NAME                 STATUS      MESSAGE                                                                                        ERROR
scheduler            Unhealthy   Get http://127.0.0.1:10251/healthz: dial tcp 127.0.0.1:10251: getsockopt: connection refused   
controller-manager   Healthy     ok                                                                                             
etcd-1               Healthy     {"health": "true"}                                                                             
etcd-0               Healthy     {"health": "true"}   

当我检查 kube-apiserver 的日志时，出现以下错误：

E0516 22:28:14.312855       1 watcher.go:188] watch chan error: etcdserver: mvcc: required revision has been compacted

这个错误是什么？我该如何解决这个问题？

我的 kube-controller-manager 也收到此警告：

W0516 22:28:14.314137       1 reflector.go:323] k8s.io/kubernetes/pkg/controller/garbagecollector/graph_builder.go:192: watch of <nil> ended with: etcdserver: mvcc: required revision has been compacted

对于我的 kube 调度程序：

W0516 10:43:38.097940       1 …

创建GCE入口时，Google Load Balancer不会通过“就绪”探针设置运行状况检查。根据文档（Ingress GCE运行状况检查），应该将其选中。

公开任意URL作为对支持该服务的pod的准备情况调查。

有什么想法吗？

部署：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: frontend-prod
  labels:
    app: frontend-prod
spec:
  selector:
    matchLabels:
      app: frontend-prod
  replicas: 3
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: frontend-prod
    spec:
      imagePullSecrets:
        - name: regcred
      containers:
      - image: app:latest
        readinessProbe:
          httpGet:
            path: /healthcheck
            port: 3000
          initialDelaySeconds: 15
          periodSeconds: 5
        name: frontend-prod-app
      - env:
        - name: PASSWORD_PROTECT
          value: "1"
        image: nginx:latest
        readinessProbe:
          httpGet:
            path: /health
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 5
        name: …

操作系统：Mac OS 10.13.6 终端

用于远程访问的 Kubectl

当我使用“--insecure-skip-tls-verify”执行命令时，它工作正常。

dev-env at balabimac in ~/kthw
$ kubectl --insecure-skip-tls-verify --context=kubernetes-me get pods
No resources found.
dev-env at balabimac in ~/kthw
$ kubectl --insecure-skip-tls-verify --context=kubernetes-me get nodes
NAME                        STATUS     ROLES    AGE   VERSION
balab29123.mylabserver.com   NotReady   <none>   4h    v1.10.2
balab29124.mylabserver.com   NotReady   <none>   4h    v1.10.2
dev-env at balabimac in ~/kthw
$ kubectl --insecure-skip-tls-verify --context=kubernetes-me version
Client Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.0", GitCommit:"0ed33881dc4355495f623c6f22e7dd0b7632b7c0", GitTreeState:"clean", BuildDate:"2018-09-28T15:20:58Z", GoVersion:"go1.11", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.2", GitCommit:"81753b10df112992bf51bbc2c2f85208aad78335", GitTreeState:"clean", BuildDate:"2018-04-27T09:10:24Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

但我无法使用以下命令访问，我被卡住了。 …

我遇到过这样一种情况，突然发生很长的 GC 暂停，我需要找出突然内存分配的根源是什么。长时间的 GC 暂停（大约 30 秒）会导致 pod 连续多次 K8s 健康检查失败，并且 pod 会重新启动，而实际上并没有发生 OOM。我想在 K8s 实际重新启动 pod 之前创建堆转储。我意识到应该对某些外部持久安装进行转储。

我对如何导致堆转储发生的唯一想法是使用 preStop 挂钩。问题是，pod因健康检查失败而重启时，preStop钩子是否会被触发？

也许有一个更优雅的解决方案？

我想知道是否有可能对 Pod 中的多个容器或仅对 Pod 中的一个容器应用活性和就绪性探测检查。我确实尝试检查多个容器，但容器 A 的探测检查失败，而容器 B 中的探测检查通过。