- k8s 用 docker runtime 确实有性能不如 containerd，k8s 已经弃用了 docker 。
- 单机配置不足不建议 k8s 。k8s 本身资源占用相对固定，配置越高，这部分资源锁定越可以忽略。

但是，也不至于拉垮到 1000kps 都困难，能看下整个性能约束点在哪，服务转发，网络处理还是后段之类的，找到约束点，而这个约束点确实是 k8s 本身设计不合理产生的那就比较有说服力。

结论的话，网络组件用的啥，服务暴露方式是什么。比如图里面 3 节点跟 4 节点后段曲线趋同，就很像节点外的单点性能瓶颈导致的

@julyclyde
都说了只当虚拟环境管理工具用，自然不包括其他功能。监控等功能按普通进程一样就可以了。

@haishenmao
继续推荐容器，不用镜像分发，当作虚拟环境管理器就可以了。

跑起来主进程挂个 cat.更新文件就行了。

什么样的服务，怼怼函数再省一波

个人的话用 Windows 吧...
企业，说的好像你改的了似的🐶

@watara
logstash 默认有 @timestamp 字段表示处理时间。
date 可以解析 nginx 日志时间。

格式转换的话，看你之前架构支持格式了，必须转文本的话 grok 或者直接写 ruby 都很省事。

都保持同步了，直接用原来的呗

https://www.elastic.co/guide/en/logstash/current/plugins-filters-date.html

If your time field has multiple possible formats, you can do this:

match => [ "logdate", "MMM dd yyyy HH:mm:ss",
"MMM d yyyy HH:mm:ss", "ISO8601" ]

数据权限也加上权限标识

F12 好像也可以看。扩展的调用里面也有显示

@plko345 就是周期性换密码。比如每个月换一下所有线上服务的密码 /token 之类

@calmzhu 用 ansible 吧

@beryl 存粹 toB 不高频私有化部署的话。个人觉得 docker-compose pxe/系统自定义镜像+hook 脚本更好 。k8s 优势在于可以把各种变更的成本降低到极致之后，做一些高抽象层级的事更方便

有下面需求 建议上 k8s 。下面需求都可以自己二开实现，但是工作量不比维护 k8s 少。
k8s 的定义是云操作系统,不是基础硬件设施。操作系统上开发应用总比裸机方便。

1.CD 持续部署，k8s 自带机制可以省很多事情。比如蓝绿部署减少当机时间;测试开发过程中防止单个应用部署失败造成其他人工作中断。

2.多个环境的频繁创建维护，甚至动态部署一套全新的应用。

3. 配置以及密码的集中管理和密码的定期轮换

4. 可视化展示交互需求。比如获取应用状态信息。k8s 本身 api 交互就比 docker compose 方便

堡垒机？