klipper + traefik 实现公网服务

目录

• 一、Traefik 安装配置
  • 1. NodePort？
  • 2.全站加速
  • 基本架构如下
• LoadBalaner 是怎么工作的
• 总结
• 参考

---

Traefik的代理服务器。 相较于Nginx，Traefik更加专注于流量整形，常被用作Kubernetes Ingress 是一个非常流程的云原生、API Gateway等角色。

年前使用k3s搭建了一个简陋的Kubernetes的集群，为了便于管理集群安装了KubeSphere。今天心血来潮打算使用全站加速访问KubeShpere，来看下Traefik Ingress是怎么工作的。Here we go…

一、Traefik 安装配置

k3s 默认安装了Taefik，如果没有安装或者希望安装最新版本 参照 https://doc.traefik.io/traefik/getting-started/install-traefik/#use-the-helm-chart。 这里建议独立安装来获取更多的自主性。

k3s 默认使用klipper-lb 作为负载均衡组件，这是一个使用iptables作为端口监听的轻量工具。

1. NodePort？

严格来说不算是NodePort，而是一种ServiceLB 的LowB方案，因为非云原生部署（穷且好奇心重），LB Endpoint复用了Node。架构如下

这个架构做到了基本可用，因为DNS修改的生效时间问题，作为一个好奇心奇重的人，怎么能忍受这种基本可用呢。

2.全站加速

全站加速是一种优化过的CDN，严格来说就是CDN，但这种产品一般支持的协议比较多，大多数云厂商Websocket加速都采用类似的产品，价格稍贵，人心不古啊。

基本架构如下

LoadBalaner 是怎么工作的

klipper-lb 做为负载均衡Daemonset，会在每个Node安装一个svclb-traefik Pod,在Node上做一个80端口的DNAT，将所有发来80/443的流量转发到Traefik 80/443端口上。traefik接受到请求后做7层转发。这就是Traefik的Ingress/IngressRoute 工作方式。

[root@k3s-master ~]# kubectl logs -f -n traefik svclb-traefik-wfmc2  lb-port-80
+ trap exit TERM INT
+ echo 10.43.108.196
+ grep -Eq :
+ cat /proc/sys/net/ipv4/ip_forward
+ '[' 1 '!=' 1 ]
+ iptables -t nat -I PREROUTING '!' -s 10.43.108.196/32 -p TCP --dport 80 -j DNAT --to 10.43.108.196:80
+ iptables -t nat -I POSTROUTING -d 10.43.108.196/32 -p TCP -j MASQUERADE
+ '[' '!' -e /pause ]
+ mkfifo /pause

[root@k3s-master ~]# kubectl get ds -n traefik
NAME            DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
traefik         3         3         3       3            3           traefik=true    71d
svclb-traefik   4         4         4       4            4           <none>          71d

一些特殊的原因某些节点并不开启80/443端口甚至8080/8443也不可用，基于上面我们得到的经验，CDN回源使用 IP:PORT， PORT避开这些端口就可以了。也就是这些不开放80/443的节点上我们可以使用其他端口比如9990/9443。设置如下:

iptables -t nat -I PREROUTING '!' -s 10.43.108.196/32 -p TCP --dport 9980 -j DNAT --to 10.43.108.196:80
iptables -t nat -I PREROUTING '!' -s 10.43.108.196/32 -p TCP --dport 9443 -j DNAT --to 10.43.108.196:443

本着提高可用性的目的我们在看下klipper怎么处理的这些规则。

containers:
- env:
  - name: SRC_PORT
    value: "80"
  - name: DEST_PROTO
    value: TCP
  - name: DEST_PORT
    value: "80"
  - name: DEST_IPS
    value: 10.43.108.196
  image: rancher/klipper-lb:v0.3.4
  name: lb-port-80
  ports:
  - containerPort: 80
    hostPort: 80
    name: lb-port-80
    protocol: TCP

呀哈，每个端口启动一个容器来注入iptales，我们也可以创建两个新的Container来处理我们的新规则。

- env:
    - name: SRC_PORT
      value: "9980"
    - name: DEST_PROTO
      value: TCP
    - name: DEST_PORT
      value: "80"
    - name: DEST_IPS
      value: 10.43.108.196
    image: rancher/klipper-lb:v0.3.4
    imagePullPolicy: IfNotPresent
    name: lb-port-9980
    ports:
    - containerPort: 9980
      hostPort: 9980
      name: lb-port-9980
      protocol: TCP
    resources: {}
    securityContext:
      capabilities:
        add:
        - NET_ADMIN

修改完毕，就可以在CDN控制台修改了回源节点了。

总结

klipper 可靠行比较高,在一些低负载应用或者测试环境下可以尝试使用;

Traefik 作为Ingress功能丰富性要强于Nginx-Ingress;

参考

• [1] klipper-lb
• [2] Traefik IngressRoute