idou老师教你学Istio 14:如何用K8S对Istio Service进行流量健康检查

Istio利用k8s的探针对service进行流量健康检查,有两种探针可供选择,分别是liveness和readiness:

liveness探针用来侦测什么时候需要重启容器。比如说当liveness探针捕获到程序运行时出现的一个死锁,这种情况下重启容器可以让程序更容易可用。

readiness探针用来使容器准备好接收流量。当所有容器都ready时被视为pod此时ready。比如说用这种信号来控制一个后端服务,当pod没有到ready状态时,服务会从负载均衡被移除。

使用场景:

liveness探针被用来移除异常的pod,不重启pod就无法恢复的应用常使用liveness探针。比如前文提到的死锁,进程会一直处于活跃状态,k8s会认为正常并继续发送流量。但使用liveness探针之后会发现应用已经不再处理请求,继而重启异常pod。

readiness探针被用来控制流量进入pod。比如应用程序需要加载一个大的文件或者需要启动后进行一些配置。但默认只要容器进程启动完成就会有流量发送过来。使用readiness探针会一直等待直到完成所有加载或配置再让流量进入。

两种探针的配置相似,区别在于使用livenessProbe还是readinessProbe字段

探针配置参数:

探针有以下几个参数:

initialDelaySeconds:容器启动之后到启动探针之间的时延

periodSeconds:探针的循环执行时间,最小单位为1秒

timeoutSeconds:探针超时时间,默认值1秒

successThreshold: 成功阈值数,失败之后最小的连续成功信号数,liveness必须是1

failureThreshold:失败阈值数,当探针失败之后,在放弃之前k8s尝试重新执行探针次数,如果是liveness探针放弃意味着重启容器,readiness探针意味着pod标记为unready,默认值为3次。

HTTP探针还有以下额外的参数:

host: 所连接主机名,默认值是pod IP

scheme: HTTP或者HTTPS

path: 访问HTTP 服务器的路径

httpHeaders: 访问HTTP的报头

port:访问容器的端口

探针可以进行三种操作:

命令行:在容器中执命令行操作,exit 0为成功状态

HTTP请求:向容器发送HTTP GET请求,如果返回值为200-400之间为成功状态

TCP 请求:向指定端口发送TCP请求,如果该端口开放监听,则为成功

下面我们来演示以下健康检查的操作:

命令行操作

首先准备busybox镜像,设置如下的yaml配置文件:

idou老师教你学Istio 14:如何用K8S对Istio Service进行流量健康检查

在配置文件中我们设置了一个liveness探针,在容器启动之后的5s,每隔5s去执行一下访问/tmp/healthy这个文件的操作,如果操作成功返回0,则为容器健康,如果返回值不为0, 会重启容器。

当容器启动之后会执行:

touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600

前30s会建立/tmp/healthy文件,30s之后删除,此时访问会返回错误.

使用kubectl create -f ./your-exec-liveness.yaml建立pod

idou老师教你学Istio 14:如何用K8S对Istio Service进行流量健康检查

在30s之内通过kubectl describe pod liveness-exec来查看pod状态,为健康:

idou老师教你学Istio 14:如何用K8S对Istio Service进行流量健康检查

在30s之后查看pod的状态,发现无法访问文件,返回不健康:

idou老师教你学Istio 14:如何用K8S对Istio Service进行流量健康检查

之后查看pod的状态,pod的重启次数为1,此时通过liveness探针检测到不健康状态已经重启pod。

idou老师教你学Istio 14:如何用K8S对Istio Service进行流量健康检查

如果使用readiness探针,需要修改上文your-exec-liveness.yaml的红框字段:

idou老师教你学Istio 14:如何用K8S对Istio Service进行流量健康检查

通过与上文相同的方法,在30s之前查看pod的状态,为ready:

idou老师教你学Istio 14:如何用K8S对Istio Service进行流量健康检查

在30s之后查看pod状态,readiness探针将应用容器置为unready, ready的容器是istio-proxy:

idou老师教你学Istio 14:如何用K8S对Istio Service进行流量健康检查

可以看到readiness探针并不会重启容器。

HTTP请求

另一种使用liveness探针的方法是HTTP GET请求,可以用来监测网页的运行状态,我们用google liveness镜像来进行演示:

idou老师教你学Istio 14:如何用K8S对Istio Service进行流量健康检查

这里我们让HTTP的服务器/healthz路径前10s返回200 的OK状态,10s之后返回状态500。

设置如下的配置文件:

idou老师教你学Istio 14:如何用K8S对Istio Service进行流量健康检查

liveness探针会向容器的8080端口发送请求访问/healthz, 在容器启动3s之后每隔3s发送一次。我们建立pod并查看pod的运行状态kubectl describe pod liveness-http:

idou老师教你学Istio 14:如何用K8S对Istio Service进行流量健康检查

会发现10s之后 liveness探针监测到了返回值是500,状态标记为不健康。

TCP请求

两种探针还可以共同使用,下面以TCP请求为例,TCP和HTTP连接类似。使用google的goproxy镜像,该镜像会在8080端口开放TCP socket连接,使用如下的配置文件:

idou老师教你学Istio 14:如何用K8S对Istio Service进行流量健康检查

我们用探针去访问8000端口查看pod状态;此时理论上应该无法连接:

idou老师教你学Istio 14:如何用K8S对Istio Service进行流量健康检查

可以看到readiness探针会每隔10s监测,无法访问时会将pod置于unready状态,liveness探针20s监测,无法成功则重启pod。

通过以上演示我们了解了如何配置两种探针和执行三种操作。通过合理的探针配置,可以实时监控Istio各个pod的运行状态,提供方便的应用治理手段。

相关服务请访问https://support.huaweicloud.com/cce/index.html?cce_helpcenter_2019

原文地址:http://blog.51cto.com/14051317/2347989

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


istio的授权功能,也称为基于角色的访问控制(RBAC),它为istio服务网格中的服务提供命名空间级别、服务级别和方法级别的访问控制。基于角色的访问控制具有简单易用、灵活和高性能等特性。本文介绍如何在服务网格中为服务进行授权控制。·前置条件·•安装istio的k8s集群,启用认证功能、
Errorfromserver(Forbidden):errorwhencreating"oot/istio.yaml":configmaps"istio-galley-configuration"isforbidden:unabletocreatenewcontentinnamespaceistio-systembecauseitisbeingterminatedErrorfromserver(Forbid
3.1Istio的核心组件及其功能Istio总体分两部分:控制面和数据面。数据面(sidecar):sidecar通过注入的方式和业务容器共存于一个pod,会劫持业务容器的流量,并接受控制面组件的控制,同时会向控制面输出日志、跟踪以及监控数据。控制面:Istio的核心,管理Istio的所有功能。
在Istio中,双向TLS是传输身份验证的完整堆栈解决方案,它为每个服务提供可跨集群的强大身份、保护服务到服务通信和最终用户到服务通信,以及提供密钥管理系统。本文阐述如何在不中断通信的情况下,把现存Istio服务的流量从明文升级为双向TLS。使用场景 在部署了Istio的集群中,使用人员
在之前的最佳实践中,已经带大家通过一系列的实践任务领略了Istio的无穷魅力。今天,将向大家介绍如何用Istio实现流量熔断。熔断机制是创建弹性微服务应用程序的重要模式。熔断可以帮助您自由控制故障影响的范围、网络延迟的峰值以及抵御其他一些来自外部的恶意***等场景。在接下来
流量镜像流量镜像,也称为影子流量,流量镜像提供一种尽可能低的风险为生产带来变化的强大功能。镜像会将实时流量的副本发送到镜像服务。镜像流量发生在主服务的关键请求路径之外。在非生产或者测试环境中,尝试访问一个服务所有可能的测试用例组合是个非常不现实的任务。在某些情况下
一、负载均衡算法原理与实战负载均衡算法(loadbalancingalgorithm),定义了几种基本的流量分发方式,在Istio中一共有4种标准负载均衡算法。•Round_Robin:轮询算法,顾名思义请求将会依次发给每一个实例,来共同分担所有的请求。•Random:随机算法,将所有的请求随机分发给健康的实例•
本文整理自华为CloudBU技术专家在K8S技术社上关于Istio调用链的分享。前言大家好,我是idouba,来自华为CloudBU,当前在做Istio服务网格在华为云容器服务的产品化工作。今天跟大家分享的主题是Istio调用链相关内容。通过剖析Istio的架构机制与Istio中调用链的工作原理来解答一个大
今天,我们就来谈谈Istio主打功能---保护服务。那么,便引出3个问题:Istio凭什么保护服务?Istio具体如何保护服务?如何告诉Istio发挥保护能力?Istio凭什么保护服务?将单体应用程序分解为一个个服务,为大型软件系统的开发和维护带来了诸多好处,比如更好的灵活性、可伸缩性和可复用性
istio-opentracing链路追踪方案istio-opentracing链路追踪主要是由sidecar(envoy)支持的,istio只是在上层进行配置的修改。envoy链路追踪envoy主要用三个功能来支撑系统范围内的跟踪生成RequestID:envoy会在需要的时候生成UUID,并操作名为[x-request-id]的HTTPHeader。应用可
在前面的文章中,大家都已经熟悉了Istio的故障注入和流量迁移。这两个方面的功能都是Istio流量治理的一部分。今天将继续带大家了解Istio的另一项功能,关于请求超时的管理。首先我们可以通过一个简单的Bookinfo的微服务应用程序来动手实践一下Istio是如何实现请求超时的管理。看过ido
调用链原理和场景正如ServiceMesh的诞生是为了解决大规模分布式服务访问的治理问题,调用链的出现也是为了对应于大规模的复杂的分布式系统运行中碰到的故障定位定界问题。大量的服务调用、跨进程、跨服务器,可能还会跨多个物理机房。无论是服务自身问题还是网络环境的问题导致调用
在Istio中,双向TLS是传输身份验证的完整堆栈解决方案,它为每个服务提供可跨集群的强大身份、保护服务到服务通信和最终用户到服务通信,以及提供密钥管理系统。本文阐述如何在不中断通信的情况下,把现存Istio服务的流量从明文升级为双向TLS。使用场景在部署了Istio的集群中,使用人员刚
前言在Istio的世界里,如果想把外部的请求流量引入网格,你需要认识并会学会配置IstioIngressGateway什么是IngressGateway由于KubernetesIngressAPI只能支持最基本的HTTP路由,使用KubernetesIngress资源来配置外部流量的方式不能满足需求。因此Istiov1alpha3routingAPI引
Istio是什么?使用云平台可以为组织提供丰富的好处。然而,不可否认的是,采用云可能会给DevOps团队带来压力。开发人员必须使用微服务已满足应用的可移植性,同时运营商管理了极其庞大的混合和多云部署。Istio允许您连接、保护、控制和观测服务。在较高的层次上,Istio有助于降低这些
Istio利用k8s的探针对service进行流量健康检查,有两种探针可供选择,分别是liveness和readiness:liveness探针用来侦测什么时候需要重启容器。比如说当liveness探针捕获到程序运行时出现的一个死锁,这种情况下重启容器可以让程序更容易可用。readiness探针用来使容器准备好接收流量。
摘要使用Istio可以很方便地实现微服务间的访问控制。本文演示了使用Denier适配器实现拒绝访问,和Listchecker适配器实现黑白名单两种方法。使用场景有时需要对微服务间的相互访问进行控制,比如使满足某些条件(比如版本)的微服务能够(或不能)调用特定的微服务。访问控制属于策略
导读目前以Kubernetes为基础构建的容器生态逐渐完善,这其中Kubernetes、Istio、Knative三个独立项目被越来越多的人提及,并且已经开始尝试大规模落地实践,它们恰好构成了容器云的未来拼图。今天与大家一起分享下,这三个项目究竟解决了什么问题,为什么它们能够一鸣惊人。随着微服务理念
注:以下讲述的按理环境场景是基于Kubernetes环境基础上部署的Istio环境。涉及到Envoy概念介绍请参考深度解析Istio系列之流量控制篇。本文重点针对Envoy初始化场景进行拆解。Istio-proxy(Envoy)作为Istio数据平面的重要组件,基于sidecar方式与业务应用混合部署到同一pod,为应用提
使用云平台可以为组织提供丰富的好处。然而,不可否认的是,采用云可能会给DevOps团队带来压力。开发人员必须使用微服务以满足应用的可移植性,同时运营商管理了极其庞大的混合和多云部署。Istio允许您连接、保护、控制和观测服务。在较高的层次上,Istio有助于降低这些部署的复杂性,