k8s 有一项作用是把多台服务器管理起来部署节点，我有几个 AWS 领的那种试用 vps，把好几个小 vps 加到一个集群里充分利用资源？

[289396212]

之前没用过 k8s,不太熟悉，以前只用 docker 部署服务，最近在研究 MicroK8s,想拿我一台 vps 做主服务，然后把另外几台小 vps 添加到这个集群里，这样能充分利用硬件资源，部署服务直接都在主服务上就好了？

[anubu]

自己研究学习，折腾着玩是没问题的。主要是网络问题，节点间最好是二层互联的，或者能够借助 overlay 实现二层互联，如基于 wireguard 的 VPN 。可以看看 kairos ，包含开箱即用的 wireguard-vpn 。
刚刚接触 k8s ，个人还是推荐使用 kubeadm ，在标准的二层网络中进行学习研究。

[ysicing]

个人大都数都是基于 k3s 跨云吧。
我是基于 k3s+tailscale+metallb 实现资源利用的，不然就吃会探针了

[locoz]

当然可以，我的服务器现在都在一个集群内，任意一台机器都能通过基于 k8s 的网络架构进行互访，每个部署了 traefik 的节点都相当于一个反代节点，走哪个都能访问到家里服务器或其他云服务器上跑的服务。

[289396212]

@ysicing 吃探针是啥意思呀？

[289396212]

@locoz 这样是不是有点花生壳的感觉，把家里的电脑当作服务器，请求通过 k8s 的网关来访问家里的电脑

[289396212]

@anubu kubeadm 和 MicroK8s 用起来有什么区别吗，我看微软的教程是用 MicroK8s 来学的

[locoz]

@289396212 #5 跟花生壳不一样，花生壳是起到 DDNS 的效果，也就是动态设置 DNS 的解析为最新的公网 IP 。这种情况其实更像是没有缓存机制的 CDN ，而如果运行服务的节点没有公网 IP ，那就是多节点的 FRP 。

[ysicing]

@ysicing 像 mjj 们一样吃灰跑探针，闲置

[anubu]

@289396212 kubeadm 是一个生产级的集群部署工具，个人使用场景更偏向学习运维侧的集群部署维护相关技能。需要提前规划集群节点数量、网络地址、控制平面、业务平面高可用支持等问题，在个人电脑或虚拟化平台上启动多个虚拟机去模拟多节点集群。基本覆盖了实际生产中部署一个集群要考虑的主要方面了。
microk8s 我没有使用过，印象中可能和 kind 差不多。更偏向 k8s 集群的实际使用而不是部署维护，可以快速的拉起一个集群而不用关注具体的细节。方面快速的学习在 k8s 集群上部署应用，或者基于 api 二次开发。

[defunct9]

你这种想法是有问题的

[Actrace]

k8s 或者 k3s 这类集群，本身就很吃资源，vps 不够玩。
管理独立服务器倒是可以试试。但是 k8s 本身就很吃人工，之后有的忙。

[GeruzoniAnsasu]

k8s 会「充分地 **耗尽**」你为数不多的资源


单主机内存没超 8G 都不建议运行集群节点，不过当然了，学习和玩的目的的话也不是不能忍。

microk8s 声称只需要 512m 内存就能跑起 non control plane 的节点，但实际上我自己试过，2G 的机子跑起来都略微吃力。coredns 和 calico 那几个核心服务都够喝一壶了，而且由于使用的组件和网络架构跟其它 k8s 实现不太一样，你找教程的时候会比较痛苦，而且也不通用。

[locoz]

@anubu #9 “需要提前规划集群节点数量、网络地址、控制平面、业务平面高可用支持等问题”
错误的，kubeadm 正常按照 k8s 官方文档部署并不需要考虑这些，直接按高可用方式配置，单主多主都能用，剩下没提到的全部默认配置就行了，非特殊场景毫无问题。

[dayeye2006199]

自己用用没问题的。
网络问题需要设置一下。可以用 consul 这种 mesh solution （ https://www.consul.io/）

记得多关注一下流量的问题。节点间通讯流量有时候很客观的，账单会令人瞩目

[zedpass]

k8s 本身就很耗费资源，你这种需求不如使用 docker swarm

[Gonlandooo]

你使用 k8s 集群情况下你应用也受限于 k8s 的 pod 所在主机的计算资源，你送的小主机本来裸机还能跑的东西，挂个 k8s 估计跑不动了

[anubu]

@locoz kubeadm 并不负责节点的创建和管理，如果搭建一个 6 节点集群的学习环境，6 个虚拟机需要自行部署，虚拟机的 IP 是需要规划一下的。学习环境的高可用主要是 VIP 和 LB ，不管是传统的 keepalived+haproxy ，还是 kube-vip 、metallb ，都需要自己维护，kubeadm 不负责这部分。kubeadm 只是提供了--control-plane-endpoint 选项来指定 VIP 或域名，以支持高可用控制平面，但具体的 VIP 和 LB 实现都要自己管理维护。

[locoz]

@anubu #16 这算啥“规划”...如果用虚拟机搭建，虚拟机软件通常都会预设一个虚拟机专用网络的网段，而且也可以让虚拟机直接从宿主机网络获取 IP ，在没有强迫症必须要连号 IP 的情况下，直接用就完事了。LB 用 metallb 直接两行还是三行命令按着复制粘贴部署，给个没被其他设备用的 IP 段就行。control-plane-endpoint 参数随便指定个自定义的域名，然后每个节点设个 /etc/hosts 就完事，这个参数也是官方文档里直接就提到的。

都是简单按说明做个配置直接用就行，算不上规划，甚至是管理维护吧...哪有那么复杂？

[anubu]

@locoz 是我唐突了。因为上下文是在讨论 microk8s\kind 这种可以暂时忽略节点概念的一键启动工具，所以下意识把 kubeadm 这种至少要考虑创建几个虚拟机的工具定义为需要规划的。误导了大家，抱歉。