Kubernetes的健康监测机制以及常见ExitCode问

　　kubernetes进行Killed我们服务的问题背景
　　无论是在微服务体系还是云原生体系的开发迭代过程中，通常都会以Kubernetes进行容器化部署，但是这也往往带来了很多意外的场景和情况。例如，虽然我们已经将JVM堆内存设置为小于Docker容器中内存及K8S的Pod的内存，但是还是会被K8s给无情的杀掉（Kill9Kill15）Killed。当发生了Killed的时候，我们该如何分析和判断呢？在此我们介绍一下K8s的Killed的ExitCode编码。kubernetes健康检测体系之探针
　　K8s中的探针用来对pod中容器的状态进行检测，有3种探针，存活探针、就绪探针、启动探针。
　　kubernetes如何监控和管理我们的Pod的运行状态
　　Kubernetes中的健康检查主要使用就绪性探针（readinessProbes）和存活性探针（livenessProbes）来实现，service即为负载均衡，k8s保证service后面的pod都可用，是k8s中自愈能力的主要手段，主要基于这两种探测机制，可以实现如下需求：异常实例自动剔除，并重启新实例多种类型探针检测，保证异常pod不接入流量不停机部署，更安全的滚动升级存活探针livenessProbes
　　kubelet使用存活探针来确定什么时候要重启容器。例如，存活探针可以探测到应用死锁（应用程序在运行，但是无法继续执行后面的步骤）情况，重启这种状态下的容器有助于提高应用的可用性，即使其中存在缺陷。就绪探针readinessProbes
　　kubelet使用就绪探针可以知道容器何时准备好接受请求流量，当一个Pod内的所有容器都就绪时，才能认为该Pod就绪。该指针用来指示容器是否准备好为请求提供服务。如果就绪态探测失败，kubelet将该Pod提供的所有服务的endpoint列表中删除该Pod的IP地址。与存活探针的区别
　　当容器未通过检查准备，则不会被终止或重新启动。存活探针通过杀死异常的容器并用新的容器去替代他们的工作，而就绪探针确保只有准备好处理请求的pod才能在服务集群中。启动探针startupProbes（1。17版本新增）
　　kubelet使用启动探针来了解应用容器何时启动。如果配置了这类探针，你就可以控制容器在启动成功后再进行存活性和就绪态检查，确保这些存活、就绪探针不会影响应用的启动。
　　启动探针可以用于对慢启动容器进行存活性检测，避免它们在启动运行之前就被杀掉，如：使用了启动探针，则所有其他探针都会被禁用，直到此探针成功为止。如果启动探测失败，kubelet将杀死容器，而容器依其重启策略进行重启。探针的3种机制
　　每种探测机制支持三种健康检查方法，分别是命令行exec，httpGet和tcpSocket，其中exec通用性最强，适用与大部分场景，tcpSocket适用于TCP业务，httpGet适用于web业务。HTTPGEt：该类型的探针通过容器的IP地址、端口号及路径调用HTTPGet请求，如果响应的状态码大于等于200且小于400，则认为容器健康。TcpSocket：该类型的探针尝试与容器指定端口建立TCP连接，如果端口打开，则诊断被认为是成功的。Exec（自定义健康检查）：该类型的探针在容器内执行任意的命令，如果命令退出时返回码为0，则认为诊断成功。配置和设定livenessProbes探针
　　通过在yaml文件中pod的spec部分的containers里面添加一个字段livenessProbe来添加存活指针：livenessProbe执行模式执行探针控制（httpGet）apiVersion：v1kind：Podmetadata：labels：test：livenessname：livenesshttpspec：containers：name：livenessimage：registry。k8s。iolivenessargs：serverlivenessProbe：httpGet：path：healthzport：8080httpHeaders：name：CustomHeadervalue：AwesomeinitialDelaySeconds：3periodSeconds：3复制代码
　　Exec执行模式执行探针控制（exec）apiVersion：v1kind：Podmetadata：labels：test：livenessname：livenessexecspec：containers：name：livenessimage：registry。k8s。iobusyboxargs：binshctouchtmphealthy；sleep30；rmftmphealthy；sleep600livenessProbe：exec：command：cattmphealthyinitialDelaySeconds：5periodSeconds：5复制代码livenessProbe执行模式执行探针控制（tcpSocket）apiVersion：v1kind：Podmetadata：name：goproxylabels：app：goproxyspec：containers：name：goproxyimage：registry。k8s。iogoproxy：0。1ports：containerPort：8080readinessProbe：tcpSocket：port：8080initialDelaySeconds：5periodSeconds：10livenessProbe：tcpSocket：port：8080initialDelaySeconds：15periodSeconds：20复制代码
　　每次探测都将获得以下三种结果之一：Success（成功）：表示容器通过了诊断。Failure（失败）：表示容器未通过诊断。Unknown（未知）：表示没有正常进行且诊断失败，因此不会采取任何行动。容器退出状态码的区间
　　ExitCodes的取值范围必须在0255之间。可以参考：tldp。orgLDPabshtm
　　0：表示正常退出1128：一般程序自身原因导致的异常退出状态区间在1128（这只是一般约定，程序如果一定要用129255的状态码也是可以的）129255：外界中断将程序退出的时候状态码区间在129255，（操作系统给程序发送中断信号，比如kill9是SIGKILL）查看Pod退出状态码kubectldescribepods｛podname｝复制代码
　　如下图所示：
　　ExitCode0
　　退出代码0表示特定容器没有附加前台进程，该退出代码是所有其他后续退出代码的例外，这不一定意味着发生了不好的事情。如果开发人员想要在容器完成其工作后自动停止其容器，则使用此退出代码。比如：kubernetesjob在执行完任务后正常退出码为0ExitCode1
　　程序错误，或者Dockerfile中引用不存在的文件，如entrypoint中引用了错误的包程序错误可以很简单，例如除以0，也可以很复杂，比如空引用或者其他程序crashExitCode139
　　ExitCode139：IndicatesfailureascontainerreceivedSIGSEGV
　　表明容器收到了SIGSEGV信号，无效的内存引用，对应kill11，一般是代码有问题，或者docker的基础镜像有问题ExitCode143
　　ExitCode143：IndicatesfailureascontainerreceivedSIGTERM
　　表明容器收到了SIGTERM信号，终端关闭，对应kill15，一般对应dockerstop命令，有时dockerstop也会导致ExitCode137，发生在与代码无法处理SIGTERM的情况下，docker进程等待十秒钟然后发出SIGKILL强制退出。ExitCode137
　　ExitCode137：IndicatesfailureascontainerreceivedSIGKILL
　　表明容器收到了SIGKILL信号，进程被杀掉，对应kill9，引发SIGKILL的是dockerkill。这可以由用户或由docker守护程序来发起，手动执行：dockerkill（Manualinterventionor‘oomkiller’〔OUTOFMEMORY〕）被手动干预杀死进程，或者违反系统限制被杀
　　137比较常见，如果pod中的limit资源设置较小，会运行内存不足导致OOMKilled，此时state中的OOMKilled值为true，你可以在系统的dmesgT中看到oom日志内存溢出问题
　　此状态码一般是因为pod中容器内存达到了它的资源限制（resources。limits），一般是内存溢出（OOM），CPU达到限制只需要不分时间片给程序就可以。因为限制资源是通过linux的cgroup实现的，所以cgroup会将此容器强制杀掉，类似于kill9，此时在describepod中可以看到Reason是OOMKilled
　　还可能是宿主机本身资源不够用了（OOM），内核会选取一些进程杀掉来释放内存，不管是cgroup限制杀掉进程还是因为节点机器本身资源不够导致进程死掉，都可以从系统日志中找到记录：
　　ubuntu的系统日志在varlogsyslog，centos的系统日志在varlogmessages，都可以用journalctlk来查看系统日志。