📋
k8s use handbook
  • 概述
  • 1. kuberbetes应用接入准则篇
    • 1.1 git分支管理规范
    • 1.2 接入elk字段格式以及约定
    • 1.3 健康检测接口规范
    • 1.4 项目命名规范
  • 2. kubernetes集群部署篇
    • 2.0 kubernetes手动安装概览
      • 201 创建跟证书和秘钥
      • 202 ETCD集群部署及维护
      • 203 kubectl部署以及基本使用
      • 204 Master节点部署及维护
        • 2041 kube-apiserver
        • 2042 kube-scheduler
        • 2043 kube-controller-manager
      • 205 Node节点部署及维护
        • 2051 Flannel部署及维护
        • 2052 kubernetes runtime部署及维护
        • 2053 kubelet
        • 2054 kube-proxy
    • 2.1 kubernetes ansible安装
    • 2.2 kubernetes kubeadm安装
    • 2.3 kubernetes 组件安装
      • 231 coredns
      • 232 kube-dashboard
  • 3. kubernetes权限控制篇
    • 认证
    • 授权
    • 准入机制
  • 4. what happens when k8s .....
    • Kubernetes使用什么方法方法来检查应用程序的运行状况?
    • 如何优雅的关闭pod?
    • TLS bootstrapping 是如何工作的?
    • 怎么编辑kubernetes的yaml文件以及kubernetes的控制是什么样的?
    • deployment如何使用不同的策略部署我们的程序?
    • Kubernetes 如何接收请求,又是如何将结果返回至客户端的?
    • Kubernetes 的调度流程是怎样的?
    • Kubelet 是如何接受调度请求并启动容器的?
    • Kube-proxy 的作用,提供的能力是什么?
    • Kubernetes 控制器是如何工作的?
    • ingress-service-deployment如何关联的?
    • 如何指定pod的运行节点?
    • Https 的通信过程?
  • 5. kubernetes私有仓库篇
  • 6. kubernetes CI/CD篇
    • 5. kubernetes cicd发布流水线
  • 6. kubernetes日志系统篇
    • 6.1 elk使用规范和指南
    • 6.2 kibana搜索简易指南
    • 6.3 基于es api进行查询的注意事项
    • 6.4 集群部署
      • 6.4.1 es规划
        • 索引的生命周期
      • 6.4.2 安装
      • 6.4.3 elasticsearch配置
      • 6.4.4 logstash配置
      • 6.4.5 kibana配置
      • 6.4.6 enable-xpack
        • 6.4.6.1 X-Pack on Elasticsearch
        • 6.4.6.2 X-Pack on Logstash
        • 6.4.6.3 X-Pack on Kibana
        • 6.4.6.4 xpack破解
        • 6.4.6.5 LDAP user authentication
      • 6.4.7 Cerebro configuration
      • 6.4.8 Curator configuration
    • 6.10 备份恢复
  • 7.0 kuberbetes服务暴露Ingress篇
    • 7.1 Ingress规划
    • 7.2 Traefik ingress controller
      • 7.2.1 Traefik配置详解
      • 7.2.2 Traefik部署
      • 7.2.3 分场景使用示例
      • 7.2.4 Traefik功能示例
      • 7.2.5 Traefik日志收集
      • 7.2.6 https证书更新
    • 7.3 Nginx ingress controller
      • 7.3.1 Nginx 配置详解
      • 7.3.2 Nginx 部署
      • 7.3.3 使用示例
    • 7.4 ingress日常运维
  • 8.0 kubernetes监控篇
    • 8.1 prometheus非k8s部署
    • 8.2 prometheusk8s部署
    • 8.3 prometheus 配置文件详解
    • 8.3 prometheus alertmanager
  • 9.0 kubernetes配置管理篇
  • 10.0 权威DNS篇
    • 10.1 PowerDNS安装部署
    • 10.1 PowerDNS zone设置
由 GitBook 提供支持
在本页
  • 容器健康监测
  • Pod的整个生命阶段
  • 示例
  • TCPSocketAction 使用示例
  • HTTPGetAcction 使用示例
  • More Information

这有帮助吗?

  1. 4. what happens when k8s .....

Kubernetes使用什么方法方法来检查应用程序的运行状况?

Kubernetes会定期检查容器进程状态,并在检测到问题时重新启动它。但是,从实践中我们知道,检查进程状态不足以决定应用程序的运行状况。在许多情况下,应用程序挂起,但其进程仍处于运行状态。例如,Java应用程序可能会抛出OutOfMemoryError并仍在运行JVM进程。另外,应用程序可能会死机,因为它会遇到无限循环,死锁或某些崩溃。为了检测这种情况,Kubernetes需要一种可靠的方法来检查应用程序的运行状况。也就是说,不是要了解应用程序在内部如何工作,而是要检查表明该应用程序是否按预期运行并能够提供服务

容器健康监测

虽然kubelet会在每个节点上不间断的检测container的运行状态, 如果container为停止状态时会重启它, 但是这并不能完全解决我们的问题。

当前kubelet拥有两个检测器,他们分别对应不通的触发器(根据触发器的结构执行进一步的动作):

  • Liveness Probe:表示container是否处于live状态。如果 LivenessProbe失败,LivenessProbe将会通知kubelet对应的container不健康了。随后kubelet将kill掉 container,并根据RestarPolicy进行进一步的操作。默认情况下LivenessProbe在第一次检测之前初始化值为 Success,如果container没有提供LivenessProbe,则也认为是Success;

  • Readiness Probe:表示container是否以及处于可接受service请求的状态了。如果ReadinessProbe失败,endpoints controller将会从service所匹配到的endpoint列表中移除关于这个container的IP地址。因此对于Service匹配到的 endpoint的维护其核心是ReadinessProbe。默认Readiness的初始值是Failure,如果一个container没有提供 Readiness则被认为是Success。

Pod的整个生命阶段

  • Pending:表示集群系统正在创建Pod,但是Pod中的container还没有全部被创建,这其中也包含集群为container创建网络,或者下载镜像的时间;

  • Running:表示pod已经运行在一个节点上,并且所有的container都已经被创建。但是并不代表所有的container都运行,它仅仅代表至少有一个container是处于运行的状态或者进程出于启动中或者重启中;

  • Succeeded:所有Pod中的container都已经终止成功,并且没有处于重启的container;

  • Failed:所有的Pod中的container都已经终止了,但是至少还有一个container没有被正常的终止(其终止时的退出码不为0)

对于liveness probes的结果也有几个固定的可选项值:

  • Success:表示通过检测

  • Failure:表示没有通过检测

  • Unknown:表示检测没有正常进行

Liveness Probe的种类:

  • ExecAction:在container中执行指定的命令。当其执行成功时,将其退出码设置为0;

  • TCPSocketAction:执行一个TCP检查使用container的IP地址和指定的端口作为socket。如果端口处于打开状态视为成功;

  • HTTPGetAcction:执行一个HTTP默认请求使用container的IP地址和指定的端口以及请求的路径作为url,用户可以通过host参数设置请求的地址,通过scheme参数设置协议类型(HTTP、HTTPS)如果其响应代码在200~400之间,设为成功。

对于LivenessProbe和ReadinessProbe用法都一样,拥有相同的参数和相同的监测方式。

  • initialDelaySeconds:用来表示初始化延迟的时间,也就是告诉监测从多久之后开始运行,也就是容器启动后第一次执行探测需要等待多少秒

  • timeoutSeconds: 用来表示监测的超时时间,如果超过这个时长后,则认为监测失败

  • periodSeconds:执行探测的频率。默认是10秒,最小1秒。

  • successThreshold:探测失败后,最少连续探测成功多少次才被认定为成功。默认是1。对于liveness必须是1。最小值是1

  • failureThreshold:探测成功后,最少连续探测失败多少次才被认定为失败。默认是3。最小值是1。

当前对每一个Container都可以设置不同的restartpolicy,有三种值可以设置:

  • Always: 只要container退出就重新启动

  • OnFailure: 当container非正常退出后重新启动

  • Never: 从不进行重新启动

如果restartpolicy没有设置,那么默认值是Always。如果container需要重启,仅仅是通过kubelet在当前节点进行container级别的重启。

以traefik daemeset为例进行说明

readinessProbe:
    tcpSocket:
    port: 80
    failureThreshold: 1
    initialDelaySeconds: 10
    periodSeconds: 10
    successThreshold: 1
    timeoutSeconds: 2
livenessProbe:
    tcpSocket:
    port: 80
    failureThreshold: 3
    initialDelaySeconds: 10
    periodSeconds: 10
    successThreshold: 1
    timeoutSeconds: 2

livenessProbe 部分:

​ 使用tcpSocket 方式监测容器80端口是否可用, initialDelaySeconds 容器启动后10s开始监测, periodSeconds 每10s监测一次, successThreshold 成功一次认为服务是可以正常对外提供服务的, failureThreshold 失败3次认为服务不能对外提供服务, 如果检测2s没有没有响应返回超时。

readinessProbe部分:

和上面解释基本相同,唯一不同认为失败一次认定改容器不能对外提供服务, 从service中删除

示例

TCPSocketAction 使用示例

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-test
  labels:
    k8s-app: nginx
    traffic-type: external
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80
        readinessProbe:
          tcpSocket:
            port: 80
          failureThreshold: 1
          initialDelaySeconds: 10
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 2
        livenessProbe:
          tcpSocket:
            port: 80
          failureThreshold: 3
          initialDelaySeconds: 10
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 2

HTTPGetAcction 使用示例

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-test
  labels:
    k8s-app: nginx
    traffic-type: external
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80
        readinessProbe:
          httpGet:
            port: 80
            path: /healthz
          initialDelaySeconds: 1
          periodSeconds: 5
          timeoutSeconds: 4
          successThreshold: 2
          failureThreshold: 3
        livenessProbe:
          httpGet:
            port: 80
            path: /healthz
          failureThreshold: 3
          initialDelaySeconds: 10
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 2

More Information

上一页4. what happens when k8s .....下一页如何优雅的关闭pod?

最后更新于5年前

这有帮助吗?

Health Probe Example
Configuring Liveness and Readiness Probes
Setting Up Health Checks Wth Readiness and Liveness Probes Resource Quality of Service
Graceful Shutdown with Node.js and Kubernetes
Advanced Health-Check Patterns in Kubernetes