本站的再一次“重启”，最早是用虚拟空间，后来迁移到VPS，再”上云“到云主机，后来又部署到容器，于是这次就成为kubernetes集群里的"微服务"。
wordpress部署到k8s不是什么新鲜事，k8s的官方教程也有拿wordpress做示例，我也是在1.10版的的时候，练手时间把本站部署到了HomeLab的k8s。
由于一些我知你不知的原因，譬如家庭宽带的443端口被限制，没有心思继续维护，停了很长一段时间。
为什么
直接上拓扑:
HomeLab:worker — OpenWrt <———— ipsec ————> Cloud:master
因为我想做一个Home-Cloud（家庭-公有云）的混合云k8s集群。
k8s作为一个企级的容器平台解决方案，可部署为私有云，公有云及混合云，就像虚拟化（云）会普及到家庭场景，我相信k8s也会慢慢融入家庭混合云场景。
HomeLab便宜量又足，家庭宽带足够便宜，上行带宽也够用，但是不开放80和443端口，Cloud的网络则是开放80和443端口，但价格"不菲"，一台4核16G的云主机往往够买一台HomeLab+N年电费，更别说带宽费了。
怎么办？二者结合。HomeLab作为负载节点，服务和存储可以放在上面，Cloud的轻量化云主机(1核1G)作为Ingress Controller，流量出口。云主机的带宽一般只限制上行（出口），下行带宽是充裕，这正好对应HomeLab节点的上行，也就是把存储和计算放到HomeLab，是有相对宽裕的带宽的：Cloud发请求和指令到HomeLab，HomeLab上传数据到Cloud。
已解决的问题
节点互通
k8s要求的是节点直接路由可达，然而两端的主机都位于NAT后，是内网IP。
第一个想法的办法是端口映射，一通操作之后，比如--control-plane-endpoint参数，总算是用kubeadm启动了集群，然而问题就出在kubelet，kubelet使用的是内网IP，搜了一通官网关于kubelet的参数，没有应对这种场景的参数。
既然端口映射不行，那就给节点之间建隧道。这里大概有如下几种技术方案。
1.SSH隧道。这个目前已被官方废弃。
2.IPsec隧道。那么最终的网络模式应是vxlan over ipsec。
3.先建立vxlan，k8s通过cni接入vxlan，一个overlay双用。
理论上第3种是最理想的，兼容性好，损耗低，但需要一些时间和精力去研究，先采用IPsec隧道把集群跑起来。
IPsec site to site隧道建立后，两端的内网IP可以直接通信，然后按照正常步骤部署即可。
存储
这种情况下是不适合依赖网络的存储，而loal volume不支持动态PV，好在Rancher出了个local-path-provisioner，可以把本机的存储，通过storage class的方式动态进行供应，不用手动管理PV的感觉真好。
后续考虑采用其它轻量化的存储方案，能组合使用，比如S3,Rook NFS，Longhorn。
存在的问题
cni
本来是想用cilium插件，体验下eBPF,但cilium的pod总是失败，估计和IPsec不兼容。退而求其次用calico，同样也是有问题，简单排查后，也没找到头绪。最终只好选择flannel。
DDNS
HomeLab的宽带也不稳定，公网IP不固定，但因为建立IPse隧道后，是内网IP在通信，理论上不会有什么问题，但是apiserver和kubelet是长连接，是否能稳定提供服务还有待观察。
带宽
虽然上面说到Cloud的下行对应HomeLab的上行，但终究也达不到100Mbps水准，并且Cloud的上行也实在太小，上行满载跑满的时候，集群的健康也会是个问题。
后续
麻雀虽小，五脏俱全。对比企业部署，Home-Cloud k8s要做事情也不少，甚至还有一些在企业环境中不会有的问题。
本篇作为Home-Cloud k8s的开篇，后续会持续更新，记录这个Home-Cloud混合k8s集群的实践过程，包括优化，构思、方案等。