这是一个创建于 1339 天前的主题，其中的信息可能已经有所发展或是发生改变。
目前我是 6 台机器+1 个虚 ip，keepalive+haproxy 部署，存储用的是 nfs helm 部署了一些常见的中间件(mongo 、redis 、rabbitmq 这些），这些都是以集群方式部署，相比 docker 部署单一镜像，性能是否取决于 service 这一层？如果做测试的话是要怎么测？微服务调用这些中间件的话，微服务逻辑需要修改吗？ vscode： 基础的 yaml 、docker compose 、helm 这些转换 vscode 里有推荐的工具嘛; vscode 里目前使用的 IcePanel 这个远程连接的时候有时候好用有时候打不开; 监控： 中间件通过 helm 部署，里面有 prometues 参数，这部分有前辈踩过坑的吗 k8s 进阶有推荐的资料吗？
 |
1
hwdef 2021-04-24 14:49:41 +08:00
1. nfs 的性能貌似也不好？
2. service 规模不大的话，iptables 撑得住，规模大了可以用 ipvs，再大可以上 ebpf |
 |
3
jyjmrlk 2021-04-24 15:03:43 +08:00  1
docker-compose 的 yaml 转换成 k8s 对象的 yaml 似乎可以用 https://kompose.io/ 这个工具然后手工调整。
|
 |
4
dcoder 2021-04-24 16:13:37 +08:00
|
 |
5
rbe 2021-04-24 16:58:48 +08:00
@jyjmrlk #3 这个我用过，单个 docker-compose.yaml 能转出来一堆 k8s 的 yaml 配置，而且可能是为了避免冲突，转出来的东西有点诡异，对新手不是很友好…
|
 |
6
AkideLiu 2021-04-24 17:43:51 +08:00 via iPhone
nfs 性能是问题
喜欢 object 可以试试 minio rancher 的 longhorn 性能不错 |
 |
7
defunct9 2021-04-24 20:18:01 +08:00 via iPhone
k9s
|
|
8
defunct9 2021-04-24 20:20:06 +08:00 via iPhone 2
为一个公司搭了一套用于生产。里面坑无数。生产和自己闹着玩完全是两码事
|
 |
9
mazyi 2021-04-24 23:36:55 +08:00 via iPhone
k8s 也要有一个团队运营的，东西是不错，前提是你们的确需要
|
 |
10
arischow 2021-04-25 00:06:34 +08:00 via iPhone
上 EKS AKS GKE
|
 |
11
lhx2008 2021-04-25 00:22:54 +08:00
在 k8s 搞中间件、数据库是天坑，还是老老实实用云上的
|
|
12
arischow 2021-04-25 00:29:00 +08:00 via iPhone
再看了一眼，上云服务
|
 |
13
chendy 2021-04-25 01:49:34 +08:00
如果可以的话，数据库之类的基础服务建议直接买运营商的，k8s 也建议买运营商的，一般出问题几率比自己搞低，而且出了问题可以索赔……
|
 |
14
mritd 2021-04-25 09:20:01 +08:00 via iPhone
存储换 longhorn 吧，https://mritd.com/2021/03/06/longhorn-storage-test/
|
 |
15
OrangeLoveMilan 2021-04-25 09:32:34 +08:00
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 |
 |
16
amrom 2021-04-25 09:40:38 +08:00
推荐一本书，《 Kubernetes in Action 》
|
 |
18
vus520 2021-04-25 10:08:37 +08:00
|
 |
19
vhwwls 2021-04-25 10:48:54 +08:00
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 强大很多，资料看官方文档就够了。 |
|
21
defunct9 2021-04-25 15:07:11 +08:00 1
@risky 用的是阿里的 ACK，master 节点托管。So，坑多了。
1 、节点 pod 数量一定要选 256，选了 16 之后无法修改。 2 、如果要 pod 伸缩到 ECI 的话，不能挂任何 Hostpath，SecurityContext 也不能有。所以 Loki-stack 就没法用了 3 、如果买了 ALB 的 LB 的话，无法用。ACK 用的还是 SLB 4 、弃用 nginx ingress，改用 traefik 的话，需要自己手绑 nodePort ...... |
 |
22
killerv 2021-04-25 17:44:20 +08:00
感觉在 k8s 上部署中间件、数据库很不合适，这个维护成本太高了，最好使用云服务。
|
 |
24
dreamusername 2021-04-26 00:25:40 +08:00
建議直接使用 EKS AKS TKE 之類的雲服務廠商版 Kubernetes，免去各種部署 Kubernetes 的問題，直接使用，而且使用雲服務出現問題的時候，不會像自己搭建，第一時間找是不是自己環境部署的問題。
同時盡量不要使用 Kubernetes 部署有狀態的服務，這不是它擅長的，雖然他可以，如果你非要部署，那麽我不推薦 Helm，而是 Operator 。 |
 |
26
leeeee9 OP @dreamusername 一些 to b 的客户内网想要搞这个
|
Select Language