最近在往 k8s 上迁移生产环境, 怎么说呢, 茫茫多的坑, 但搞定了用起来会很舒服: https://blog.monsterxx03.com/tags/k8s/

实际生产环境中除了 k8s 以外, 还要面对其他程序在 k8s 上跑的各种坑,几个月里我碰到了 jenkins, fluent-bit, datadog-agent ... 等等程序的 bug, 更别提公司内部的业务程序了.

apline 的 musl 在 /etc/resolv.conf 里不支持全部 option set, 对 dns 有特殊要求的可能有问题.

还有 apline 里面是 busybox, 有些程序如果用 shell 调用一些系统命令, 可能参数不一样会出错(比如 fluentd 的某个版本调用 gzip)

我的理解你是想用 rabbitmq 之类的 队列 broker 来实现类似 rpc 的同步调用方式?

用 github 路径可以支持 go get, 项目根路进不行, 有了 go mod 后，我自己的项目都用根路径了.

目前没直接办法，看能不能把他们放在一个 pod 里，通过 localhost 访问。有个 kep 是关于这个的 https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/0033-service-topology.md

第三方应用的 chart(jenkins,sonarqube...) 我的做法是直接 cp 到自己的 repo 里, 在里面加一个文件夹 helm_vars 用来 override values.yaml 里面的值, 更新时候直接再从上游拷过来覆盖一次,看 git diff, 没问题再 helm upgrade xx . -f helm_vars/prod.yaml( 这句写死在 Makefile 里). 这种应用更新频率很低直接让 helm 管理了.

自己的应用也用 helm 初始化, 后续更新一般都是代码的更新, 只更新 image tag, 不走 helm, 在 jenkins pipeline 用 kubeclt set image + kubectl rollout status 更新. image 都是时间戳, 每次发布新的 image 同时把 latest tag 指向最新的 tag. helm chart 里 image 永远写 latest.

自己的应用只有在改应用运行环境的时候才需要执行 helm upgrade (很少很少), 风险是此时 tag 变成了 latest, 如果之前线上做了 rollback 就会处问题(但只有我有这权限,所以问题不大)

helm 的依赖管理对我真的没啥用处,有的 chart 里有 requirements 的,我都想办法禁掉, 单独部署它的依赖

aws 文档其实蛮有套路的，看久了就知道哪些是废话可以跳过，我 99.9%的问题都是自己看文档解决的，只有碰到他们的锅时候才会发 ticket,多数时候 support engineer 还挺靠谱的，偶尔有鸡同鸭讲的情况

日志量不大的话，直接用 syslog 协议打到 远端的 fluentd 也可以, fluentd 定时把 log 归档到本地的某个文件夹. 这样你只需要一台日志服务器就行了，只需要配置 fluentd 这一个程序.

对日志没有很强的分析和可视化需求的话, ELK 那套我觉得有点重了.

迁移 k8s 的过程中正好在做, 我的做法是应用日志全部打到 stdout, fluent-bit 做 daemonset, 读取本地 pod log, 发送到中心化的 fluentd, 定时归档到 s3.

https://blog.monsterxx03.com/2019/05/26/centralized-logging-on-k8s/

aws 北京从昨晚 2 点炸到现在了...

自建的话我也想不到什么好办法, 你们估计用的 flannel 之类的 overlay 网络. 在 aws 上的话可以通过 vpc cni plugin 直接给 pod 分配 vpc 里的 ip, 这样 k8s 内外的服务可以直接通过 ip 通信.

我对 dubbo 不熟悉, overlay 网络, 你要内外通信, 必然需要一个 service 做 NodePort, 不知道 dubbo 有没有单端口的代理方案.

给 k8s 内的 dubbo 服务设置一个 NodePort 类型的 service 不就完了吗: https://kubernetes.io/docs/concepts/services-networking/service/#nodeport

华短男...

换 deskmini A300, amd 2200g , A300 还能放 4 块硬盘(2 m2 + 2 2.5 寸 sata).

H310 和 A300 我都有, A300 真的性价比高

打包脚本移走日志后给你的 service 发一个 signal (比如 kill -USR1 `cat /var/run/web.pid`), service 监听这个 signal, 重新创建日志文件. logrotate 处理 nginx 日志就是这样

试试看用 https://github.com/CodisLabs/redis-port

它是把自己伪装成一个 redis slave, 从 master 那边把数据 dump 过来, 解析过后写到 slave.

可以试试把数据恢复的部分改一下, 把你不需要的 key 过滤掉, 这样应该就能不停机迁移到新的 redis 了.

粗略看下, 改下 doRestoreDBEntry 和 doRestoreAoflog 这两个函数就行了.

不过你这 100 好大了，找台 slave 测试一下吧.

看你怎么定义运维了, 我们也是全套 AWS, 我大概 20%的时间在做接近运维的活: ansible 配置管理，aws 资源用 terraform 代码化, CI/CD ... 还有一半时间是开发,剩下的时间是 performance tuning, troubleshooting.

stateless 的 service 做好 autoscaling 基本没什么事要做的.
少数自己 host 的 stateful 的 service 做好监控报警事情也不多, 需要手工做的部分也就是扩容或升级 instance type.

不管用不用云, 需要解决的问题其实都是那些,只是做的方式不一样, 重要的是技能不是职位.