标签 容器 下的文章

上次的数据库故障余波未平。老服务整改周期内仍有可能增高，有没什么方法限制单个pod只能建立一定数量的数据库连接，把事故控制在一定范围内

  • 首先是数据库层面，可以在配置文件中限制连接数，但基于容器的环境IP会有变化 pass
  • 其次想到的是服务网格，因为是业务标配+出色的流量控制，应该可以从这里入手。看了圈文档，Istio更多关注的是进方向
  • 再次想到kubernetes本身的网络插件也有限流的功能，calico具备对进出方向端口的限制，但没找到连接数的

陷入僵局，最笨用iptables限制，但还能实时发现pod的重启更换IP，难道要复杂化，监控结合脚本的方式吗？忽然灵光一闪，initContainers阶段不是可以做很多事情嘛

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  initContainers:
  - name: init-iptables
    image: my-iptables-image
    command: ['sh', '-c', 'iptables -A OUTPUT -p tcp --dport 3306 -m connlimit --connlimit-above 20 -j REJECT']
  containers:
  - name: my-container
    image: my-image

😅未验证，原理可行- -

遇到一种场景，某前端服务部署在kubernetes中，有偶发的服务故障。想着健康探针重启就行，忽然想到，如果是重要的线上服务宕机，不查出来心里憋得慌，怎么让服务恢复的同时又能保留现场呢
改当前pod的标签，这样deployment会认为副本消失，自动创建。完美实现老容器保留，业务也及时恢复
截图.jpg