Hetzner-k3s私有IP集群部署实践与问题解决指南

前言

在云原生环境中，出于安全性和成本考虑，许多团队选择将Kubernetes集群部署在私有网络环境中。本文基于Hetzner-k3s项目实践经验，详细介绍了在Hetzner Cloud上部署纯私有IP Kubernetes集群的完整方案，包括常见问题及其解决方案。

核心挑战与解决方案

1. 网络架构设计

私有IP集群面临的首要挑战是网络连通性问题。我们采用以下架构设计：

• 堡垒主机：部署在私有网络(10.0.0.0/16)中，同时拥有公网IP，作为集群的唯一出入口
• NAT网关：在堡垒主机上启用IP转发和NAT功能，使私有节点能够访问互联网
• 路由配置：精心设计的路由规则确保内部节点能访问Hetzner元数据服务

2. 关键配置实现

通过cloud-init配置实现节点自动化部署：

additional_packages:
 - ifupdown
 
post_create_commands:
  - ip route add default via 10.0.0.1
  - ip route add 169.254.0.0/16 via 172.31.1.1
  - echo "auto enp7s0" > /etc/network/interfaces.d/enp7s0
  - echo "iface enp7s0 inet dhcp" >> /etc/network/interfaces.d/enp7s0
  - echo "    post-up ip route add default via 10.0.0.1" >> /etc/network/interfaces.d/enp7s0
  - echo "    post-up ip route add 169.254.169.254 via 172.31.1.1" >> /etc/network/interfaces.d/enp7s0
  - echo 'nameserver 185.12.64.1' > /etc/resolv.conf
  - echo 'nameserver 185.12.64.2' >> /etc/resolv.conf

3. 典型问题与解决方案

3.1 K3s安装失败

现象：k3s安装过程中出现STDIN错误，kubeconfig为空

原因：私有网络环境下下载k3s二进制文件不稳定

解决方案：

1. 预下载k3s二进制文件
2. 设置INSTALL_K3S_SKIP_DOWNLOAD=true
3. 添加cloud-init完成检查逻辑

3.2 自动扩缩容问题

现象：新节点无法加入集群

原因：节点无法访问Hetzner元数据服务(169.254.169.254)

解决方案：添加特定路由规则

ip route add 169.254.169.254 via 172.31.1.1

3.3 DNS解析问题

现象：容器内DNS解析失败

解决方案：直接配置Hetzner DNS服务器，绕过systemd-resolved

3.4 SSH访问问题

现象：自动扩缩节点SSH访问失败

解决方案：通过post_create_commands预置SSH密钥和root密码

最佳实践建议

1. 网络设计：

   • 堡垒主机使用10.0.0.2，默认网关设为10.0.0.1
   • 启用IP转发和NAT：echo 1 > /proc/sys/net/ipv4/ip_forward
   • 配置MASQUERADE规则：iptables -t nat -A POSTROUTING -s '10.0.0.0/16' -o eth0 -j MASQUERADE

2. 系统配置：

   • 使用ifupdown替代netplan进行网络配置
   • 禁用cloud-init的DNS管理，直接配置resolv.conf
   • 预置必要的系统工具包

3. 安全考虑：

   • 限制堡垒主机暴露的端口
   • 使用SSH证书认证
   • 定期轮换凭证

架构优势

这种设计具有以下优点：

1. 安全性：集群节点完全隔离在私有网络
2. 成本效益：只需为堡垒主机支付公网IP费用
3. 可维护性：简单清晰的网络架构，便于故障排查
4. 灵活性：可根据需要调整NAT和路由策略

总结

在Hetzner Cloud上部署纯私有IP的Kubernetes集群需要特别注意网络配置和组件间的依赖关系。通过合理的架构设计和自动化配置，可以构建出既安全又高效的云原生环境。本文提供的解决方案已在生产环境验证，可作为类似场景的参考实现。