第一次把测试平台迁到 Kubernetes，都会先把注意力放在两件事上： Helm 能不能把 Deployment、Service、Ingress 一次装起来 values.yaml 能不能把镜像、端口、环境变量配进去 这一步通常不难，难的是上线几轮之后出现的长期问题： 测试环境和预发环境的 values 差异越来越大，没人说得清哪些差异是合理的 一个 chart 同时承载 api、worker、scheduler、web，多服务模板互...
测试平台容器化之后，最先感受到的不是部署更快，而是排查更难。 在虚机阶段，一台机器通常对应一个环境、一套配置、一组日志目录。到了 Kubernetes 里，同一个平台会被拆成多个 Deployment、Job、CronJob、Worker、Ingress、ConfigMap、Secret 和外部依赖。如果还沿用原来的做法，现场通常会很快变成下面这样： 配置到底来自镜像、环境变量、ConfigMap、Secret 还是 Helm valu...
Kubernetes 进入测试环境之后，最容易被低估的并不是部署动作本身，而是环境数量、资源生命周期和团队并发使用带来的治理压力。 刚开始接入 Kubernetes 时，关注点通常只有两件事： 服务能不能部署起来 Pod 能不能扩起来 这两个问题当然重要，但它们通常只解决了“能不能跑”的第一层问题。 一旦测试环境开始真正承担日常提测、联调、回归、专项验证、性能摸底、灰度预演这些任务，问题会很快从“会不会部署”转成下面这些更实际的工程问题...
一提到 Kubernetes，最容易先聊的是这些话题： 集群怎么搭 节点怎么加 Helm 怎么装 Pod、Service、Ingress 分别是什么 这些内容当然重要，但对测试团队来说，日常最常处理的往往不是“概念理解”，而是更具体的现场问题： 某个版本在测试环境里发布后，Pod 一直起不来 服务已经 Running，但页面还是 502 或 404 接口偶发超时，测试结果不稳定，但应用日志里看不出明显报错 配置明明改过，容器里实际跑的却...
性能测试真正高价值的地方，不是证明系统哪里慢，而是把瓶颈、收益和风险量化，让架构优化从经验判断走向证据驱动。
生产压测最大的难点不是把流量打进去，而是在真实用户、真实数据、真实依赖都在线的情况下，设计一套可控、可隔离、可回退、可止损的验证机制。
一、hosts配置加入harbor仓库地址1234192.168.147.35 alpha-pack.51iwifi.com192.168.195.3 k8s-alpha-node2192.168.195.70 dev-harbor.51iwifi.com192.168.195.2 alpha-harbor.51iwifi.com 二、docker地址修改 1vi /etc/docker/daemon.json 三、nfs搭建，mast...
扩容12345678910111213141516 kubectl scale deployment cgp-zuul --replicas 2 kubectl scale deployment cgp-protocol-converter --replicas 2 kubectl scale deployment cloud-switch-resmgr --replicas 2 kubectl scale deployment ing...
压测报告真正要输出的不是截图，而是结论链：测了什么、系统怎么退化、瓶颈在哪、风险边界在哪、下一步该怎么优化。
docker images \\\\\\\\| grep ingress打包成tar包：docker save 镜像id 文件名.tar加载本地文件到镜像...