底层是高度定制化的 KVM ，CPU 和内存当然只能是同一台机器上的，至于硬盘视情况而定，大部分情况是分布式存储上的。

每个月给火狐捐了 10 刀

@Vhc001 #6 会不会编程不敢说，也很难就在线上验证，我觉得至少是没有长期一线搬砖的，身上没有那种该有的扎实气质，讲的都是虚的，就很让人恶

楼上说的都对，这点 K8s 自己没有做，只能延长关闭 Pod 的等待期，其他的得从程序层面考量。

1 、性能是否取决于 service 这一层？
视整体架构而定。只考虑集群内部的网络性能，性能也不仅仅取决于 service 一层。service 的转发性能主要影响客户端对服务的访问这一块，这里的客户端有集群内的其他 service，以及从 Ingress 接入的外部流量。
同时，也应当考虑底层网络插件的网络模型，即跨节点的 Pod 通信模式也能影响应用的整体网络性能，例如，Flannel 的 UDP 模式在封包和解包时因为需要频繁的内核和用户态切换，性能较差。这一点可以自行验证。
总而言之，在不考虑在 Ingress 外部额外再加一层 Nginx （或者其他接入层）的情况下，集群内的整体网络性能取决于 Service 和 Pod 这两层。
2 、如果做测试的话应该要怎么测？
如果你说的测试指的是对 Pod 内的应用做压测，可以从两个维度进行；第一个是从外部直接访问 Pod，即通过 Ingress 接入的流量，即用于模拟用户访问的真实流程；第二个则是服务之间互相调用的压测，即通过服务 A 去调用服务 B，这种访问不经过 Ingress，只是在 Service 层面做互相访问。这两个维度将同时对集群内的网络性能和计算性能都做有限的压力测试，在测试时，重点关注响应延迟和 Pod 内的 CPU 负载。
3 、微服务调用集群内的中间件，微服务逻辑需要修改吗？
通常情况下不需要修改，中间件在集群内和集群外，对微服务自己来说唯一的区别只是访问地址不一样，仅此而已。
4 、vscode
我是个运维，对这块了解不多。
5 、Prometheus
拿来做监控的，在做白盒监控这块比 Zabbix 强大很多，资料看官方文档就够了。

1.提供每月生活补贴；
2.正常双休，朝九晚六；
3.设有绩效奖金及年终奖，根据考核结果最高可达 17 薪；
4.设有大小各种福利，全勤奖工龄奖生日红包，公司不定时下午茶及活动。

搞了六七年 Linux 的运维过来唠叨一句
无论是从实际经验还是从一些项目的官方文档建议来看，升级操作系统只有在少数的几种情况下是必要的：
- 重大的安全漏洞
- 当前旧版本上的某个软件存在某个 Bug，该 Bug 已经触发或者有潜在触发的可能
- 在当前系统上跑的软件需要系统更新至更新的版本
不过就实际经验来看，在线上跑的软件很少需要整个系统都升级的情况，即使像 K8s 明确在 3.10 内核上频繁创建 Pod 会触发 CGroup 内存泄露的 Bug 的这种问题，也可能通过仅仅升级内核而非整个操作系统都升级来解决。
所以这个帖子除了吐槽没有任何意义，正常的运维只要带了脑子上班都不会升级操作系统。
：）

给个思路，可能和 Windows 的权限管理有关系。

我之前送了两千多刀，不知道为什么，后面开了一台虚拟机，用了一阵子没管了，想着反正还有那么多钱在里面不花白不花，结果过了一段时间那个体验金还是用完了，于是我的信用卡每个月都给扣了四五百块钱。。后面还得手动关掉计算实例。

CCIE 太贵，考一个现在要三万多，而且今天思科改革，CCIE EI 的难度大了很多。真要系统学建议和我一样考个 CCNP 就够了。

背锅侠不是运维吗-_-||

你不会是马哥群里的那个吧。。。

盲猜黄赌毒

其实我觉得 LZ 的 idea 是挺好的，不过不应该定位在商场里面导航那么简单，就像上面有位老哥说的那样，你可以做成火灾或者地震逃生系统那种感觉，把产品定位在安全产品上，应该更有搞头。

@cpstar #46 不是杠。。我在北上广深也没有见过哪个商场里面可以实现 LZ 说的这种效果。。

分母+1

nacos 和 spring cloud config server 之类的项目就是为了解决这种问题存在的。kubernetes 自己提供的方式只是一个设计理念，告诉你可以这么干，是不是最优解还是要自己权衡。

平心而论，我欣赏这个社区，会有好结果的，加油，已加入。

KVM，我就是这样