关于后端:存活探针副本机制2

存活探针正本机制 2

本次咱们开始 k8s 中存活探针和正本控制器的学习

如何放弃 pod 衰弱

后面咱们曾经晓得如何创立 pod，删除和治理 pod 了，然而咱们要如何能力放弃 pod 的衰弱状态呢？

咱们能够应用 存活探针和正本机制

探针的分类

探针目前有

• 存活探针 liveness probe
• 就绪探针 readiness probe

本次咱们这里先分享存活探针

存活探针

应用存活探针 能够查看容器是否还在运行 ，咱们能够为 pod 中的每一个容器独自的指定存活探针， 如果探测失败，那么 k8s 就会定期的执行探针并重启容器

在 k8s 中，有 3 中探测容器的机制：

• http get 探针

能够对容器的 IP 地址，指定的端口和门路，进行 http get 申请，若探测器收到的状态码不是谬误（2xx，3xx 的状态码），那么就认为是认为是探测胜利，否则就是探测失败，本次容器就会被终止，而后重新启动一个 pod

• tcp 套接字探针

探测器尝试与指定端口建设 TCP 连贯，如果胜利建设连贯，则探测胜利，否则，失败

• Exec 探针

在容器外部执行命令，并查看退出的错误码，如果错误码是 0，则探测胜利，否则失败

存活探针案例

咱们来创立一个 pod，退出咱们的存活探针

kubia-liveness.yaml

apiVersion: v1
kind: Pod
metadata:
  name: kubia-liveness
spec:
  containers:
  - image: luksa/kubia-unhealthy
    name: kubia
    livenessProbe:
      httpGet:
        path: /
        port: 8080

还是应用之前的 kubia 的例子，咱们拉取的镜像是 luksa/kubia-unhealthy，这个镜像和之前的镜像有一些区别，就是当收到内部拜访的时候，前 5 次会失常响应，前面的申请都会报错

咱们就能够通过这样的形式来测试 存活探针

部署一个 liveprobe 的案例，不衰弱的利用 kubia

部署 pod

kubectl create -f kubia-liveness.yaml

部署之后，大略 1 -2 分钟的时候，咱们就能够看到咱们启动的 pod 存在重启的状况

例如上图，kubia-liveness 11 分钟内，就重启了 5 次

查看解体利用的日志

咱们查看日志的时候个别应用 kubectl logs -f xxx，然而咱们当初须要查看解体利用的日志，咱们能够这么查看

kubectl logs -f kubia-liveness –previous

咱们能够看到解体利用的程序是这样的

查看 pod 的详细信息

kubectl describe po kubia-liveness

查看 pod 的详细信息的时候，咱们能够看到这些要害信息：

• Exit Code

137 是代表 128 + x，能够看出 x 是 9，也就是 SIGKILL 的信号编号，认为这强行终止

有时候，也会是 143，那么 x 就是 15，就是 SIGTERM 信号

• Liveness

  • delay 提早

  容器启动后延时多少工夫才开始探测，若 该数值为 0，那么在容器启动后，就会立刻探测

  • timeout 超时工夫

  超时工夫，能够看出上图超时工夫为 1 秒，因而容器必须在 1 s 内做出响应，否则为探测失败

  • period 周期

  上图为 10 s 探测一次

  • failure 失败次数

  指 失败多少次之后，就会重启容器（此处说的重启容器，指删除掉原有 pod，从新创立一个 pod），上图是 失败 3 次后会重启容器

如上图，咱们还能够看到 pod 的状态是不衰弱的，存活探针探测失败，起因是容器报 500 了，没有响应，因而会立刻重启容器

配置存活探针的参数

配置存活探针的参数也就是和上述的 liveness probe 的参数一一对应，咱们个别会设置一个延迟时间，因为容器启动之后，具体的应用程序有时并筹备好

因而咱们须要设定一个延迟时间，这个延迟时间，也能够标记是应用程序的启动工夫

咱们能够这样退出配置，设置容器启动后第一次探测时间延迟 20 s：

apiVersion: v1
kind: Pod
metadata:
  name: kubia-liveness
spec:
  containers:
  - image: luksa/kubia-unhealthy
    name: kubia
    livenessProbe:
      httpGet:
        path: /
        port: 8080
      initialDelaySeconds: 20

存活探针的注意事项

咱们创立存活探针的时候，须要保障是一个无效的存活探针

• 配置存活探针申请的端口和地址，保障端口和地址无效
• 存活探针拜访地址的时候，保障不须要认证，否则会始终失败，一起重启容器
• 肯定要检查程序的外部，没有被内部因素所影响
• 要留神探针的不应耗费太多资源，个别必须在 1 s 内实现响应

遗留问题

应用探测放弃 pod 衰弱，看上去感觉还不错，当 pod 中容器出现异常的时候，存活探针可能删除掉异样的 pod，并立即从新创立 pod

然而，如果是 pod 所在节点挂掉了，那么 存活探针就没有方法进行解决了，因为是节点下面的 Kubelet 来解决存活探针的事项，当初节点都异样了

咱们能够应用正本机制来解决

ReplicationController 正本控制器

ReplicationController 也是 K8S 的一种资源，后面有简略说到过，能够确保它治理的 pod 始终保持运行状态，如果 pod 因为任何起因隐没了，ReplicationController 都会检测到这个状况，并会创立 pod 用于代替

举个 rc 的例子

rc 是 ReplicationController 的简称，rc 旨在创立和治理 pod 的多个正本

例如，node1 下面 有 2 个 pod，podAA 和 pod BB

• podAA 是独自创立的 pod，不受 rc 管制
• pod BB，是由 rc 管制的

当 node1 节点出现异常的时候，podAA 是没了就没了，没有人管它，本身自灭的

pod BB 就不一样，当 node1 出现异常的时候，rc 会在 node2 下面创立一个 pod BB 的正本

rc 小案例

rc 也是 k8s 的一种资源，那么创立 rc 的时候，也是通过 json 或者 yaml 的形式来创立的，创立 rc 有 3 个重要的组成部分：

• label selector 标签选择器

用于 rc 作用域哪些 pod

• replica count 正本个数

指定应运行的 pod 数量

• pod template pod 模板

用于创立新的 pod 股本

咱们能够这样写，创立一个名为 kubia 的 rc

kubia-rc.yaml

apiVersion: v1
kind: ReplicationController
metadata:
  name: kubia
spec:
  replicas: 3
  selector:
    app: xmt-kubia
  template:
    metadata:
      labels:
        app: xmt-kubia
    spec:
      containers:
      - name: rc-kubia
        image: xiaomotong888/xmtkubia
        ports:
        - containerPort: 8080

• 示意创立一个 rc，名字是 kubia，正本数是 3 个，选择器是 app=xmt-kubia
• rc 对应的 pod 模板，拉取的镜像地址是 xiaomotong888/xmtkubia，标签是 app=xmt-kubia

咱们创立 rc 的时候，个别也能够不必写 selector，因为 Kubernetes API 会去查看 yaml 是否正确，yaml 中是否有模板，如果有模板的话，selector 对应的标签，就是 pod 模板中的标签

然而肯定要写 pod 的模板 template，否则 Kubernetes API 就会报错误信息

部署 rc

kubectl create -f kubia-rc.yaml

查看 rc 和 查看 pod 的标签

kubectl get rc

kubectl get pod –show-labels

咱们能够看到创立的 rc 资源，所须要创立 pod 数量是 3，以后理论数量是 3，就绪的也是 3 个

kubia-749wj

kubia-mpvkd

kubia-tw848

并且，他们的标签都是 app=xmt-kubia，没故障老铁

rc 的扩容和缩容

rc 控制器会管制创立 pod 和删除 pod，大抵逻辑是这样的

rc 启动的时候，会在环境中搜寻匹配的标签，

• 若搜寻到的标签数量 小于 rc 中配置的冀望数量，则进行创立新的 pod
• 若搜寻到的标签数量 大于rc 中配置的冀望数量，则进行删除多余的 pod

咱们尝试删除掉 kubia-749wj，验证 rc 是否会主动创立新的 pod

kubectl delete po kubia-749wj

果然 kubia-749wj 曾经是终止状态了，且 rc 曾经为咱们创立了一个 新的 pod

查看 rc 的详情

kubectl describe rc kubia

咱们能够看到，从创立 rc 到当初，rc 创立的 pod 的记录是 4 个

批改 pod 的标签

咱们尝试批改某个 pod 的标签，看看是否会影响 rc 的

在 kubia–mpvkd pod 下面减少一个 ver=dev 的标签，看看该 pod 是否会被删除掉

kubectl get pod --show-labels
kuebctl label pod kubia-mpvkd ver=dev

果然是没有的，对于 rc 来说，他只会治理和管制本人配置好的标签，其余的标签他一律不论

重写 app 标签

后面咱们有说到过，如果 pod 上曾经有标签，若是要批改的话，须要应用 --overwrite 进行重写， 这也是 k8s 为了形式误操作，笼罩了曾经配置好的标签

咱们将 app 标签批改成 app=anonymous

kubectl label pod kubia-mpvkd app=anonymous –overwrite

查看到的成果是原来的 kubia-mpvkd pod 没有什么影响，然而 rc 检测到 app=xmt-kubia 标签的数量小于 rc 的期望值，因而会被动创立一个新的 pod 作为代替

简略流程和成果如下图：

说一下批改模板

批改模板的话，是很简略的，只须要编辑一个 rc 配置即可

kubectl edit rc kubia

执行命令后，将 rc 配置中 pod 模板中 image 的地位，批改成本人须要下载的镜像地址即可，对于 pod 模板的简略流程如下：

上图中，咱们能够了解，批改了 pod 模板的话，对于之前的 pod 是没有影响的，因为正本的个数还是没有变动

当咱们删除掉一个 pod 的时候，次数 rc 检测到 理论的 pod 个数小于 冀望的个数，因而会创立一个新的 pod，此时创立的 pod，用的就是方才咱们批改的 pod 模板

批改正本数

咱们能够尝试批改正本数为 6，还是一样的操作，编辑 rc 配置即可

kubectl edit rc kubia

成果如上，rc 为咱们又创立了 3 个 pod，总共是 6 个

批改正本数为 2

成果如上，rc 的确将其余的 4 个 pod 都干掉了，最初剩下 2 个 pod

删除 rc

小伙伴们有没有这样的疑难，删除 rc 的话，是不是 pod 也就跟着被销毁了，是的，没故障老铁

然而咱们也能够做到删除 rc 后，不影响 pod 资源，能够这样来执行

kubectl delete rc kubia –cascade=false

看到信息提醒， --cascade=false 曾经被废除了，咱们能够应用 --cascade=orphan

删除 rc 失效，咱们来看看简略的删除流程和成果

明天就到这里，学习所得，若有偏差，还请斧正

欢送点赞，关注，珍藏

敌人们，你的反对和激励，是我保持分享，提高质量的能源

好了，本次就到这里

技术是凋谢的，咱们的心态，更应是凋谢的。拥抱变动，背阴而生，致力向前行。

我是 阿兵云原生，欢送点赞关注珍藏，下次见~