@kd9yYw2RyhQwAwzn nacos 没必要部署到 k8s 集群上，有状态服务部署到集群内你还要考虑独占节点的问题，不然异常情况可能会导致 pod 驱逐等情况，所以才会有可能不稳定，建议直接 k8s 集群外找个服务器部署 nacos ，微服务不太适合研发本地调试 ，调试就 push 代码自动发布,然后去 dev/test 环境。 用 kt-connect 也会存在若干问题，微服务里你的服务通过 kt-connect 连接到集群上,有可能你的版本和别人的不匹配 别人调用服务时候就会各种异常，或者你服务不在线时候别人访问又会找不到服务。 至于 istio 等 要考虑业务了，一般公司 感觉实际上没必要上。

说句实话 感觉没必要换，nacos 作为配置中心和注册中心 挺稳定的了，简单省事，开发人员如果 configmap 写配置都费劲，这就没有绝对的理由相信能用好 spring-cloud-starter-kubernetes ，还要去理解 k8s 中的各种对象的概念,切本地开发复杂度也会增加很多。然后你用 configmap 还要考虑权限控制，历史记录等问题

@Barnard 感觉珠海就是环境好适合居住，但是工资低消费又高

可以突破的大一点，换成 win 又不是不能用

有这样的神仙企业早就自己去了，为啥会推荐给一个陌生人，哈哈😄

一个愿打一个愿挨

可以，但是没必要，收益和风险完全不成正比

我只能说这种基础服务用容器部署完全没啥优势，我是 yum 安装，维护最方便，每次更新按官方升级路线直接 update ，没啥问题。不想更新要么坦然接受安全问题，毕竟哪个软件没漏洞，要么就放到内网里

我一般说自己除了技术外优势就是性格好

厂商毕竟不是做慈善的，人家肯定考虑受众，前几年 24 2k 的还有，现在就很少了，现在主流 27 4k

k8s 监控 cicd

直接银行的大额存单不就可以满足了么

感觉有必要那么多微服务么，你们客户对这些没意见么，我们供应商要是给我搞这么多微服务，我估计裂开。 你可以用服务全做成容器，去客户现场部署，k8s+yaml 直接梭哈

全用大写看起来不难受么

为啥一定要推广，目的性那么强，写起来不会很累么

能用 我推土机架构的 apu a10-7800 还在服役呢 ，你这个比我那个性能好多了

@hanyuwei70 其实也不是大规模实践才会有比较深的体会，很多公司从 19/20 年都已经开始用 k8s 这一套东西了，基本我最近几年工作的工作都是趋向于 all in 容器，不然工作岗位的选择就很少了，目前来看大多数运维岗位都是需要这些，或许你还考虑一下目前是选择开发还是运维运维方向，二者兼得感觉目前深度不太够，会不符合你的工作年限

它亏不亏钱不知道 你的时间成本肯定比它高