k8s 困惑

[leeeee9]

目前我是 6 台机器+1 个虚 ip，keepalive+haproxy 部署，存储用的是 nfs helm 部署了一些常见的中间件(mongo 、redis 、rabbitmq 这些），这些都是以集群方式部署，相比 docker 部署单一镜像，性能是否取决于 service 这一层？如果做测试的话是要怎么测？微服务调用这些中间件的话，微服务逻辑需要修改吗？ vscode： 基础的 yaml 、docker compose 、helm 这些转换 vscode 里有推荐的工具嘛; vscode 里目前使用的 IcePanel 这个远程连接的时候有时候好用有时候打不开; 监控： 中间件通过 helm 部署，里面有 prometues 参数，这部分有前辈踩过坑的吗 k8s 进阶有推荐的资料吗？

[hwdef]

1. nfs 的性能貌似也不好？
2. service 规模不大的话，iptables 撑得住，规模大了可以用 ipvs，再大可以上 ebpf

[leeeee9]

@hwdef nfs 主要自己玩，ceph 太复杂了，目前考虑 glusterfs

[jyjmrlk]

docker-compose 的 yaml 转换成 k8s 对象的 yaml 似乎可以用 https://kompose.io/ 这个工具然后手工调整。

[dcoder]

@leeeee9
简单说，就是配置坑无数, k8s 远没有吹的那么好用
如果你不是专业的 DevOps 运维之类, 还是不要深入研究了

[rbe]

@jyjmrlk #3 这个我用过，单个 docker-compose.yaml 能转出来一堆 k8s 的 yaml 配置，而且可能是为了避免冲突，转出来的东西有点诡异，对新手不是很友好…

[AkideLiu]

nfs 性能是问题
喜欢 object 可以试试 minio
rancher 的 longhorn 性能不错

[defunct9]

k9s

[defunct9]

为一个公司搭了一套用于生产。里面坑无数。生产和自己闹着玩完全是两码事

[mazyi]

k8s 也要有一个团队运营的，东西是不错，前提是你们的确需要

[arischow]

上 EKS AKS GKE

[lhx2008]

在 k8s 搞中间件、数据库是天坑，还是老老实实用云上的

[arischow]

再看了一眼，上云服务

[chendy]

如果可以的话，数据库之类的基础服务建议直接买运营商的，k8s 也建议买运营商的，一般出问题几率比自己搞低，而且出了问题可以索赔……

[mritd]

存储换 longhorn 吧，https://mritd.com/2021/03/06/longhorn-storage-test/

[OrangeLoveMilan]

1 、性能不能单说取决于哪一层，而根据业务看瓶颈，举个例子，如果 to c 的高并发，那么 nginx-ingress 的大概率需要调优
2 、新人上手 k8s，最好从无状态服务开始
3 、微服务调用中间件，逻辑跟不用 k8s 是一样的，只不过中间件地址变成了中间件的 service 地址加端口
4 、新手推荐部署方式从 yaml->kustomize->helm->operator 的部署过程渐进
5 、关于 prometheus 参数，很多开源工具都自带了 prometheus 监控参数获取接口，方便你部署后快速接入 prometheus，具体可以学习下 kube prometheus operator
6 、存储的话，k8s 支持非常多类型的存储，主要依靠于你对哪种存储比较熟悉。我们测试环境用的 ceph，线上直接用 nas

[amrom]

推荐一本书，《 Kubernetes in Action 》

[vus520]

@hwdef 来来来，我们来聊聊头像的事情

[vus520]

@hwdef 话说不是内核支持的话，会自动优先用 ipvs 么。

顺道安利一下阿里的 k8s 课程
https://edu.aliyun.com/course/1651

[vhwwls]

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 强大很多，资料看官方文档就够了。

[risky]

@defunct9 能介绍下都有啥坑么……