k8s 如何让你的应用活的更久

Posted 2023-04-27

参考技术A

众所周知，k8s 可以托管你的服务 / 应用，当出现各种原因导致你的应用挂掉之后，k8s 会自动重启你的服务，那么 k8s 是如何做到的呢？它又是通过什么功能实现这个效果的呢？这就是本文将要介绍的内容： 副本控制器 及 存活探针 。

注：因为本文讨论的是如何让应用活的更久，所以文中提到的 pod 类型均为持久型，不包含其他如 Job 之类的应用。

首先解释一下副本控制器是什么，副本控制器是 k8s 中用于控制 pod 数量的一个工具，只要 告诉它你期望中的 pod 有多少，他就会努力去把 pod 控制在这个数量 。这个副本控制器具体有两种，分别是： ReplicationController (简称 rc )和 ReplicaSet (简称 rs )。在具体了解他们的区别之前，我们先来看一下副本控制器为了达到目标（把 pod 数量维持在你给它的期望值）都做了那些事：

很简单不是么，只做了两步，这和把大象塞进冰箱没什么实质性的区别。好，先来看第一步：如何找到目标 pod。

副本控制器是通过 pod 的标签来进行查找的 ，在创建副本控制器时，需要给他指定标签选择器。在生成之后，它就会通过自己携带的选择器来查找 pod 并将其纳入自己的管辖之下。比如，你可以通过下述文件创建一个 ReplicationController ，我们给其命名为 kubia-controller ：

ReplicationController.yaml

然后使用 kubectl create -f ReplicationController.yaml 就可以创建出一个可用的副本控制器了。这时候再使用 kubectl get pod ，就会发现副本控制器 kubia-controller 自己创建了三个 pod：

kubia-controller 在创建之后发现自己要管理的 pod 一个都没有（ 在 ReplicationController.yaml 里我们指定了要检查标签 app 的值为 kubia 的 pod ），于是 kubia-controller 根据 ReplicationController.yaml 里我们告诉它的 pod 模板创建了三个新的 pod。

这时候如果我们使用 kubectl delete pod kubia-2bb8c 杀死其中的一个 pod。再次查看之后就会发现 kubia-controller 又创建出了一个全新的 pod：

这里需要强调的是， 副本控制器是通过 pod 的标签来进行控制的 。如果修改了某个 pod 的标签，那么就可以使其脱离指定 rc 的控制。

例如，我们刚才生成的 kubia-controller 控制器是控制标签 app 的值为 kubia 的 pod。如下，我们修改一个已存在 pod 的标签。然后就会发现 kubia-controller 又新建了一个 pod，这说明标签被我们修改的 pod 脱离了该副本控制器的管理：

这时再把这个 pod 的标签改回来，就可以看到 kubia-controller 因为副本数量大于 4，不符合期望数量而删除了一个 pod。

了解完了 ReplicationController 之后再来看一下 ReplicaSet （简称 rs ）。其实这两个的区别就是， rs 支持更加完善的标签选择器，例如， rc 的标签选择器允许包含某个标签的 pod。而 rs 支持如下条件：

好了，下面来看一下如何生成一个 rs ，首先生成如下 yaml 文件：

replicaset.yaml

然后使用 kubectl create -f replicaset.yaml 来创建出一个 rs 资源，如果你认真观察了，你就会发现这个配置与 rc 的配置几乎完全一样。事实上，k8s 在实际的使用中几乎已经用 rs 完全代替了 rc 。

了解完了副本控制器后，我们再来看一下存活探针，这个存活探针是用在什么地方的呢？我们知道副本控制器可以把 pod 的数量保持在期望的数量。再详细一点就是： 副本控制器可以把运行状态在 Running 的 pod 数量维持在期望的数量 。

那么问题来了，如果 pod 里运行的 docker 容器已经假死了，但是 k8s 不知道他已经挂掉了怎么办？例如：一个 java 程序因为内存溢出异常停止服务了，但是 JVM 依旧在运行。这时 k8s 依旧会把该 pod 的状态标记为 Running 。

这时候，如果有一个小工具，把他插在 pod 上，不停的进行测试，然后对外输出 pod 里运行的服务是否状态良好就好了。是的，这个小工具就是存活探针。

存活探针都有什么手段来进行测试？

存活探针的监测方式包括以下三种：

接下来因为篇幅 作者能力 的原因，只简单讲述一下最常用的 http get 存活探针。首先来介绍一下如何创建一个 http 存活探针：

liveness-probe.yaml

然后使用 kubectl create -f libeness-probe.yaml 即可创建一个拥有 http 探针的 pod。可以看到，想要创建探针只需要给 containers 数组的元素指定 livenessProbe 字段即可，然后使用 httpGet 创建一个 http 探针。 httpGet 需要如下两个属性：请求的访问路径 path 以及访问端口 port 。

可以看到不需要指定其 ip 地址，因为 pod 的 ip 并不是固定的。探针会动态的获取其 ip 地址进行测试。这里使用的 luksa/kubia-unhealthy 是一个存在”异常“的 web 应用。向端口 8080 请求超过 5 次后服务会停止正常服务。

启动之后获取 pod 看一下：

没问题呀，看起来一切正常，我们执行 kubectl logs -f kubia-liveness 打开它的日志看一下：

你会看到服务正在缓慢的被请求，这个请求就是我们定义的 http 探针发出的。当我们耐心的等待到 8 次之后，日志突然被关闭了，怎么回事？这时我们再 kubectl get pod 看一下，可以看到他的 RESTARTS 值从 0 变成了 1 ，原来是因为容器重启了呀：

我们还可以通过 kubectl describe pod kubia-liveness 来查看他的详细重启信息，以下是 pod 的事件信息，你可以在输出的末尾找到它：

可以看到第四条事件被标记为了 Warning ，而原因是因为探针检查到了 pod 的响应状态为 500 服务器错误。然后从第 5 ~ 7 条事件可以看到 pod 被杀死并重新启动。

如果你足够无聊，在 pod 重启数十次之后你可能会发现他的状态变成了 CrashLoopBackOff ，这是容器多次异常退出导致的。不过不用担心，k8s 依旧会尽力重启它，经过几十秒时候你就可以看到容器的状态重新变成 Running 了。

存活探针的附加属性

现在我们更近一步，了解存活探针的具体配置。执行 kubectl get pod kubia-liveness -o yaml 命令来打开该容器的完整 yaml 配置。然后我们定位到 livenessProbe 字段，如下，可以看到完整的配置里多出了几个属性，需要我们关注的就是下面添加了注释的四条属性：

首先回想一下， luksa/kubia-unhealthy 容器会响应五次请求，然后返回 500 服务器异常，那为什么我们看到日志里刷新出了 8 次请求后容器才重启呢？这个就是 failureThreshold 属性的功劳。

存活探针在发现了请求失败时首先会将 pod 标记为异常状态。然后继续发送请求， 如果依旧失败的请求次数超过了 failureThreshold 的次数，那么容器将会被删除重建，而在被标记为异常状态之后如果请求成功了，并且成功的总次数超过了 successThreshold 的次数。那么异常状态将会被清除。 至于 timeoutSeconds 属性则代表了请求的超时时间，而 periodSeconds 则是间隔多久进行下一次测试，它们两个的单位都是秒。

上述四个属性是属于 livenessProbe 对象的，而非 httpGet 对象，在创建时不要搞错缩进了。

探针导致的问题

探针并不是尽善尽美的，如果使用不当的话很容易引起无限重启的问题。最容易发生的是以下三种：

k8s 通过副本控制器和存活探针来保证服务健康可靠。副本控制器分为 ReplicationController 和 ReplicaSet 两种，但是在实际使用中 rs 已经全面取代了 rc 。副本控制器通过规定好的标签来将容器纳入自己的管理，并根据用户指定的期望数量来维持实际存在的容器数量。但是副本控制器只能保证 Running 的副本数量不会减改变，而不能得知处于 Running 状态的容器是否健康。为了实现这个目标，我们使用存活探针来获取容器内部的服务是否健康。通过自定义的探针，k8s 就可以持续的获取容器的内部状态，进而完成更加可靠的健康管理。

张书乐：专注“皮肤”生意的《王者荣耀》，超越还是抄袭暴雪？

如果你想要一个游戏活的够久，请让它电子竞技化；如果你想要一个游戏活的更久，请让它拍电影。

这样的状态，有个典型的正反面例子，前者是暴雪公司出品的《魔兽争霸》和《星际争霸》，在PC端游戏最近20年中，几乎就是电子竞技的代名词；而后者依然是暴雪出品的《魔兽世界》，作为曾经全球最火爆的PC端网游，2016年的大电影，或许是它唯一在衍生品上的瑕疵，据说最终亏损千万美元。但在中国，依然以14.72亿元票房，雄霸内地票房年度排行老三的位置。

文/张书乐（人民网、人民邮电报专栏作者）

新著有《微博运营完全自学手册》

不去讨论这场银幕上的Cosplay中，中国玩家的贡献之类的话题，只是用来对比后来者《王者荣耀》的套路。或许，真的有机会颠覆暴雪那句经典语录：一直被模仿，从未被超越。

《王者荣耀》是一款典型的手游电竞，而显然，在问世一年多后，它开始走向了“活得更久”的路线中，只是不拍电影，而是综艺。

6月中旬，“2017年腾讯视频综艺+音乐推介会”上很意外的推销起了游戏IP:《〈 王者荣耀〉明星竞技实景真人秀》。这个综艺节目该如何理解呢？其实你就把它看作是一个有摄像头监控的5人制彩弹游戏即可。

所谓由一线明星带领各自朋友组成王者战队，真实还原《王者荣耀》中5V5对战，也就不过是看明星现场出糗罢了。算起来，这也是20年前湖南卫视《快乐大本营》的套路活，更是当下综艺节目的一贯模式，只是有了一个更让年轻人有代入感的王者荣耀“皮肤”罢了。

这俨然是《王者荣耀》在游戏本身单靠卖皮肤都可以日入1.5亿元的同时，正在开发的另一门“皮肤”生意。

不得不说，这样的轨迹，和暴雪的路线图很像，而或许这恰恰印证了在4月被明晃晃“爆料”出来的那句豪言壮语：让我们悄悄地超过Blizzard（暴雪）”。

彼时，正是舆论从网易《阴阳师》转向到腾讯《王者荣耀》的时间节点，说这话的人，恰恰是天美工作室群总裁姚晓光。备注一下，天美，正是《王者荣耀》的研发“工厂”。而在与此同时，舆论对姚晓光的追捧，也一度达到了和创造微信奇迹的张小龙比肩的位置上。

但显然，他还不构成与拥有Foxmail和微信前后两大传奇的张小龙并列为腾讯最佳产品经理的实力，而支撑他此番“悄悄超过”的论调的，除了继续用强大吸金能力来维持神话外，必须要给自己增加更多的附加值。

沿着暴雪的IP衍生路径前进，这本身或许应该算是致敬。

在《王者荣耀》的计划里，我们能看到很多有趣的内容：年初，腾讯互动娱乐高级品牌经理张雅缇公开表示，今后会着重推出如《王者为你读古诗》、《历史上的TA》、《王者历史课》等衍生内容，其目的就是想要通过这些教育产品，成为传统文化的“内容索引”，从而来实现传统文化的传承。

好吧，我表示被打败了，这很显然是在蹭当时风头还没消歇的《中国诗词大会》第二季这个大热点，又是一个很王者、很腾讯的蹭话题路线，而这个内容怎么体现呢？在微博上，请到游戏内角色声优和知名配音演员来朗读《将进酒》 《观沧海》 《木兰辞》等著名诗篇而已。

比如2月17日蹭热点的那条《将进酒》微博，只有3千多评论，实在愧对其200万微博粉丝和动辄过完评论的微博常态。话说那条朗读视频，只有70万点击，也是“醉”了。

为何《王者荣耀》如此急着给自己衍生呢？除了利，除了被诟病的名，还有更多套路在等待……（刊载于《人民邮电报》2017年7月14日《乐游记》专栏152期）