原因1:请求需要10s完成,但是服务所在pod在第8秒被干掉
解决:设置preStop和延迟销毁pod, sleep时间要小于terminationGracePeriodSeconds.且sleep之后不会再有请求进入该pod
imagePullPolicy: Always
lifecycle:
preStop:
exec:
command:
- sleep
- '30'
.......
restartPolicy: Always
terminationGracePeriodSeconds: 40
原因2:pod启动时,是running状态(即容器创建成功),running 后被加入到 Endpoints ,但是其中的业务服务并没有起来,无法正常处理请求
解决:添加就绪探针,服务可用后再将pod加入服务列表中
http请求:
name: coding-cloud-platform-cron
readinessProbe:
failureThreshold: 1
httpGet:
path: >-
/api/cron/stats/stu/review?key=idnehmC68npnUXDU&startTime=2021-06-08%2000:00:00&endTime=2021-06-08%2000:00:00
port: 8080
scheme: HTTP
initialDelaySeconds: 5
periodSeconds: 2
successThreshold: 2
timeoutSeconds: 1
端口监控(开启isito边车有问题):
name: coding-cloud-platform-api
readinessProbe:
failureThreshold: 3
initialDelaySeconds: 30
periodSeconds: 10
successThreshold: 1
tcpSocket:
port: 8080
timeoutSeconds: 1
在帮助田老师进行skywalking的的容器化的过程中发现如下问题:
k8s+isito,配置tcp存活或就绪指针,如果开启了envoy自动注入,那么所有的端口都可以被检测到,从而导致指针会存在失效问题。该问题可以通过增加如下配置解决:
traffic.sidecar.istio.io/excludeInboundPorts: '12800'
但是会影响后期isito相关流量治理功能的使用,所以推荐的存活或就绪指针还是http请求方式比较靠谱。
开启了envoy自动注入,那么所有的端口都可以被检测到 怎么立即呢?
pod中java服务提供的端口是1280,无论java服务是否起来,
telnet podIP 1280 总是通的;
注意如果java服务没有启动,那么在pod内执行telnet localhost 1280是不通的,原因如下:
istio的边车开启后,会拦截所有端口对应的所有流量
特别说明:
pom中引包
yml存活探针开启配置:
management: endpoints: web: exposure: include: prometheus,health,info,metric endpoint: health: probes: enabled: true 然后请求验证: curl localhost:8086/api/ai/actuator/health/readiness curl localhost:8086/api/ai/actuator/health/liveness
优雅停机配置
server:
shutdown: graceful
应用优雅停机可持续最大时间
spring:
lifecycle:
timeout-per-shutdown-phase: 30s
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: delayed-close-timeout
namespace: istio-system
spec:
configPatches:
- applyTo: NETWORK_FILTER
match:
listener:
filterChain:
filter:
name: envoy.http_connection_manager
patch:
operation: MERGE
value:
typed_config:
'@type': >-
type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
delayed_close_timeout: 0s