k8s pod java 接口 响应慢,超时 istio timeout

描述:对接方请求我方接口,阶段性 报 timeout  conntion  链接异常

我方:阿里云 k8s 容器化部署

排查:

第一次因为istio节点数据不够,2021-11

1、查看nginx日志,发现 upstream timeout ,问 运维 nginx 转发到了 某一个 istio 上
2、随后 在 nginx 所在服务器 telnet  istio 所在ip,发现 没有反应

3、看 istio 监控,发现流量较高,但不能确定 是 istio 的压力大造成的

4、nginx 转发 配置了 2个 istio ,但是 总共有 11个 istio,整个集群有11个node
5、增加 nginx 转发 的 istio 个数,增加到 4个,发现我方接口趋于正常,观察一夜再说

6、第二天,对方反应 仍然有 2个 timeout,整体少了许多

7、扩展 服务规格 ,由 4c16g 升到 8g32g,待观察 是否还有问题

8、准备安装 istio 一套完整的监控,可以查看istio 的整体情况,到时候知道 istio 的峰值

9、扩充完 istio-ingressgateway ,我方接口响应时间恢复正常

第二次 我方接口夜间高峰时段响应超过30s, 系统告警

1、查看pod cpu 内存 正常,查看数据量近2个月增加了30%

2、增加  istio-ingressgateway 数量,增加一倍,观察一夜再说

3、情况没有改善,证明瓶颈不在 istio

4、增加pod tomcat 线程数,之前是默认值,250吧应该是,改成500,观察一夜

5、第二天无告警,笑的就像吃了蜜蜂屎,整个集群每秒并发最高 1万 ,525个pod

6、又过了几天,告警出现,悲催,看到jvm监控运行线程15,由此想到,数据源线程默认是15吧

7、增加最大线程数   Hikari-pool  50

8、
观察监控,静待佳音,优化之路,任重而道远,永无止境

待后续继续完善该文。。。

### 如何维持 WebSocket 连接到 Kubernetes Pod 的稳定连接 为了确保 WebSocket 连接能够稳定地连接到 Kubernetes 中的 Pod,需要考虑多个方面来优化配置。 #### 配置 Ingress 控制器支持 WebSocket 协议 Ingress 资源用于定义进入集群的外部访问路径。要使 WebSocket 正常工作,需特别设置 Ingress Controller 支持 WebSocket 握手过程中的特定头部字段。通常情况下,在 Nginx 或其他类型的 Ingress Controller 上可以通过自定义注解实现这一点: ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: websocket-ingress annotations: nginx.ingress.kubernetes.io/proxy-read-timeout: "3600" nginx.ingress.kubernetes.io/proxy-send-timeout: "3600" spec: rules: - host: example.com http: paths: - pathType: Prefix path: "/" backend: service: name: websocket-service port: number: 8080 ``` 上述 YAML 文件通过 `nginx.ingress.kubernetes.io` 注解延长了代理读取超时时间和发送超时时间,从而允许更长时间保持 WebSocket 连接不中断[^1]。 #### 设置服务类型为 ClusterIP 并暴露端口 创建的服务应将目标指向运行 WebSocket 应用程序的工作负载(如 Deployment),并公开必要的端口以便于内部网络通信和服务发现机制正常运作。 ```yaml apiVersion: v1 kind: Service metadata: name: websocket-service spec: selector: app: websocket-app ports: - protocol: TCP port: 80 targetPort: 8080 type: ClusterIP ``` 此段代码片段展示了如何声明一个名为 `websocket-service` 的 K8S 服务资源对象,并将其关联至带有标签 `app=websocket-app` 的 Pods;同时指定了对外提供服务所使用的端口号以及实际转发给容器实例的目标端口[^3]。 #### 使用 StatefulSet 替代 Deployment 来增强会话亲和力 当应用程序依赖于有状态协议(例如 Websocket)时,可能希望每次重新建立连接都回到同一个 Pod 实例上继续之前的对话。为此可以采用 StatefulSet 取代普通的 Deployments,因为前者提供了有序性和稳定的网络身份识别功能,有助于维护长期存在的客户端-服务器关系[^4]。 ```yaml apiVersion: apps/v1 kind: StatefulSet metadata: name: websocket-statefulset spec: serviceName: "websocket-service" replicas: 3 selector: matchLabels: app: websocket-app template: metadata: labels: app: websocket-app spec: containers: - name: websocket-app image: your-docker-image:latest ports: - containerPort: 8080 ``` 这段配置文件说明了一个基于 StatefulSets 构建的应用部署方案,它不仅继承了原 Deployment 的大部分属性,还额外赋予了成员个体独一无二的名字序列化特性,使得每个副本都能获得固定的主机名和 IP 地址分配。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值