开发和运维对K8S中的应用都做了什么?
发布网友
发布时间：2022-10-02 14:13
共1个回答
热心网友
时间：2023-10-08 18:47
在应用的整个生命周期里，开发和运维都和它密不可分。一个塑造它，一个保养它。
如果应用需要部署到K8S中，开发和运维在其中都做了什么呢？
从开发侧来说，我们的应用应该具备以下能力：
健康 检测接口用于检测应用的 健康 状态，在K8S中，使用Readiness和Liveness分别来探测应用是否就绪和是否存活，如果未就绪或者未存活，K8S会采取相应的措施来确保应用可用。
如果我们应用未定义好相应的 健康 检测接口，K8S就无法判断应用是否正常可用，整个应用对我们来说就是黑匣子，也就谈不上应用稳定性了。
定义一个简单的 健康 检测接口如下：
如上我们定义了 health 接口，当应用启动后，只需要探测这个接口，如果返回OK，表示应用是正常的。
当然，上面的接口是非常简单的，在实际情况下，应用本身也许还依赖起来应用，比如redis，mysql，mq等，如果它们异常，应用是不是异常的呢？那我们的应用 健康 检测需不需要检测其他应用的 健康 状态呢？
既然我们定义好了 健康 检测接口，那我们的YAML模板就可以增加 健康 检测功能，如下：
应用发版是常规不能再常规的操作，通常情况下都是滚动更新的方式上线，也就是先起一个新应用，再删一个老应用。
如果这时候老应用有部分的流量，突然把老应用的进程杀了，这部分流量就无法得到正确的处理，部分用户也会因此受到影响。
怎么才会不受影响呢？
假如我们在停止应用之前先告诉网关或者注册中心，等对方把我们应用摘除后再下线，这样就不会有任何流量受到影响了。
在K8S中，当我们要删除Pod的时候，Pod会变成Terminating状态，kubelet看到Pod的状态如果为Terminating，就会开始执行关闭Pod的流程，给Pod发SIGTERM信号，如果达到宽限期Pod还未结束就给Pod发SIGKILL信号，从Endpoints中摘除Pod等。
从上面可知，Pod在停止之前会收到SIG信号，如果应用本身没有处理这些信号的能力，那应用如果知道什么时候该结束呢？
下面简单定义一个处理SIG信号的功能。
当接收到SIG信号的时候，就会调用 Shutdown 方法做应用退出处理。
除此，还要结合K8S的 PreStop Hook 来定义结束前的钩子，如下：
如果使用注册中心，比如nacos，我们可以在 PreStop Hook 中先告诉nacos要下线，如下：
Metrics主要用来暴露应用指标，可以根据实际情况自定义指标，以便于监控工具Prometheus进行数据收集展示。
有些语言有现成的exporter，比如java的jmx_exporter，没有的就需要自己在应用中集成。
比如：
这种会暴露默认的Http指标，可以通过 curl 127.0.0.1:9527/metrics 获取指标。
如果需要自定义指标的话，只需按规则定义即可，如下：
这样就定义了 httpserver_request_total 和 httpserver_request_ration_seconds 指标，引用过后就能在 /metrics 中看到对应的数据。
定义好了指标，下面就是收集了。既可以通过自定义收集规则收集，也可以通过自动发现的方式收集，为了方便，主要采用自动发现的方式。
我们只需要在deployment的templates中定义好annotation，prometheeus就会自动添加采集目标，如下：
Trace用于跟踪，每个请求都会生成一个 TraceID ，这个ID会伴随请求的整个生命周期，我们也可以根据这个ID查询请求的整个链路情况。
链路追踪，目前市面上有很多开源系统，比如Skywalking，Jeager，Zipkin等，它们各有各的特点，如下。
我比较推荐使用Jaeger，它是CNCF的毕业项目，成长空间和云原生的系统架构兼容性比较好。
不过，我这里采用的Skywalking。
Skywalking有许多现成的客户端，比如Java、Python等，可以直接使用，它们都会自动埋点，但是对于Go来说就只有自己手动埋点了，需要我们自己去写代码。
比如：
定义reporter用于上报数据给Skywalking，这就是一个简单的集成Trace的例子。
应用的可观测性主要来源日志、监控、链路追踪，标准的日志有利于日志收集以及排查问题。
原则上，不论是什么类型的日志输出，什么格式的日志内容，都能收集。但是为了方便友好，建议把日志输出到标准输出，这样收集更方便。
我个人理解，在K8s中，完全没必要把日志输出到文件，浪费不说，没多大意义，因为所有的日志我们都会收集到日志系统，而输出到文件的日志也会随着应用发版而丢失，所以输出到文件的意义是什么呢？
开发把系统开发完，就会交付给运维部署。为了保障应用的稳定性，运维在部署应用的时候应该考虑以下几点。
K8S中可以部署有状态应用，也可以部署无状态应用。对于有状态应用，我其实很少部署到K8S中，大部分还是部署的无状态应用，至于为什么，用多了就晓得了。
对于业务应用，强烈建议使其保持无状态，就算有需要持久化的东西，要么保存到数据库，要么保存到对象存储或者其他单独的文件系统中，不要挂载到应用Pod上。
这样的好处是，应用和数据是分开的，应用可以随意启停、扩展、迁移等。
保持高可用应该是每个运维人员的使命。
在K8S中，我们应该怎么配置呢？（1）应用Pod应该是多副本
（2）应用Pod之间做反亲和性，避免同一应用调度到同一台主机，如下。
（3） 为了避免应用因为节点维护等原因驱逐Pod，导致全部Pod被驱逐，特别配置了PodDisruptionBudget，保障应用至少有一个可用，如下。
（4）如果某个节点因为一些原因需要驱逐一些Pod，为了避免重要应用被驱逐，应该给应用配置较高的QoS，如下：
所谓优雅上线能力，就是要确保应用能够提供服务了，再接入外界流量，不能在还没完全启动的情况下就提供服务。
在K8S中，应用在启动后会加入endpoints中，然后通过service接入流量，那在什么情况下才算启动成功呢？主要是通过K8S的 ReadinessProbe 来进行检测。这时候开发的 健康 检测接口就派上用场了，如下：
所以我们K8S的YAML文件应该加上如上的配置。
所谓异常自愈，就是应用本身在出现Crash，或者应用Pod所在节点出现异常的情况，应用能够自动重启或者迁移。这时候就需要通过K8S的 LivenessProbe 来进行检测了，如下。
当K8S的YAML清单加上如上配置过后，就会定时去探测应用是否正常，如果异常，就会触发重启的动作。如果是节点异常，K8S会对Pod进行重新调度。
应用通过HTTPS访问是比较常见的，企业级应用建议自己购买相应的SSL证书，然后进行配置即可。
比如。
上面介绍了开发和运维对于应用上线应该做的工作， 不全但够用 。
在不同的企业都有不同的尿性，但是作为运维，我们都要牢牢记住 稳定 永远是第一尿性。通过上面的梳理，我们的应用模板就整理如下：
如果我的文章对你有所帮助，还请帮忙一下，你的支持会激励我输出更高质量的文章，非常感谢！
你还可以把我的公众号设为「星标」，这样当公众号文章更新时，你会在第一时间收到推送消息，避免错过我的文章更新。
