使用 KPNG 编写专用 kube-proxy

这篇文章将向你展示如何使用 Kubernetes Proxy NG kpng 创建一个专用的、kube-proxy 风格的网络代理，而不干扰现有的 kube-proxy。kpng 项目旨在更新默认的 Kubernetes Service 实现，即 "kube-proxy"。kpng 的一个重要特性是它可以作为一个库，用于在 K8s 外部创建代理。虽然这对于取代 kube-proxy 的 CNI 插件很有用，但它也为任何人创建专用代理提供了可能性。

定义一个使用专用代理的 Service

apiVersion: v1
kind: Service
metadata:
  name: kpng-example
  labels:
    service.kubernetes.io/service-proxy-name: kpng-example
spec:
  clusterIP: None
  ipFamilyPolicy: RequireDualStack
  externalIPs:
  - 10.0.0.55
  - 1000::55
  selector:
    app: kpng-alpine
  ports:
  - port: 6000

如果定义了 service.kubernetes.io/service-proxy-name 标签，kube-proxy 将会忽略该 Service。自定义控制器可以监视设置了该标签且标签值等于其自身名称（例如此处的 "kpng-example"）的 Service，并设置专用的负载均衡。

service.kubernetes.io/service-proxy-name 标签并非新功能，但到目前为止，编写一个专用代理相当困难。

专用代理的常见用途通常是处理某些 Kubernetes 不支持的用例中的外部流量。在这种情况下，不需要 ClusterIP，因此我们在本例中使用“无头” Service。

使用 kpng 的专用代理

基于 kpng 的代理由处理所有 Kubernetes API 相关功能的 kpng 控制器和实现负载均衡的“后端”组成。后端可以与 kpng 控制器二进制文件链接，也可以是使用 gRPC 与控制器通信的独立程序。

kpng kube --service-proxy-name=kpng-example to-api

这将启动 kpng 控制器，并告诉它只监视服务代理名称为 "kpng-example" 的 Service。“to-api” 参数将为后端打开一个 gRPC 服务器。

你可以在集群外自行测试。请参阅下面的示例。

现在我们启动一个仅打印控制器更新的后端。

$ kubectl apply -f kpng-example.yaml
$ kpng-json | jq     # (this is the backend)
{
  "Service": {
    "Namespace": "default",
    "Name": "kpng-example",
    "Type": "ClusterIP",
    "IPs": {
      "ClusterIPs": {},
      "ExternalIPs": {
        "V4": [
          "10.0.0.55"
        ],
        "V6": [
          "1000::55"
        ]
      },
      "Headless": true
    },
    "Ports": [
      {
        "Protocol": 1,
        "Port": 6000,
        "TargetPort": 6000
      }
    ]
  },
  "Endpoints": [
    {
      "IPs": {
        "V6": [
          "1100::202"
        ]
      },
      "Local": true
    },
    {
      "IPs": {
        "V4": [
          "11.0.2.2"
        ]
      },
      "Local": true
    },
    {
      "IPs": {
        "V4": [
          "11.0.1.2"
        ]
      }
    },
    {
      "IPs": {
        "V6": [
          "1100::102"
        ]
      }
    }
  ]
}

一个真正的后端会使用某种机制将外部 IP 的流量负载均衡到端点。

编写后端

kpng-json 后端如下所示

package main
import (
        "os"
        "encoding/json"
        "sigs.k8s.io/kpng/client"
)
func main() {
        client.Run(jsonPrint)
}
func jsonPrint(items []*client.ServiceEndpoints) {
        enc := json.NewEncoder(os.Stdout)
        for _, item := range items {
                _ = enc.Encode(item)
        }
}

（是的，这就是整个程序）

一个真正的后端当然会复杂得多，但这说明了 kpng 如何让你专注于负载均衡。

你可以将多个后端连接到同一个 kpng 控制器，因此在开发或调试期间，让类似 kpng-json 的后端与你真正的后端并行运行可能会很有用。

示例

完整示例可在此处找到。

作为示例，我们实现一个“all-ip”后端。它将所有外部 IP 的流量导向本地端点，无论端口和上层协议如何。有一个关于此功能的 KEP，本示例是一个大大简化的版本。

要将来自外部地址的所有流量导向本地 Pod，只需要一个 iptables 规则，例如：

ip6tables -t nat -A PREROUTING -d 1000::55/128 -j DNAT --to-destination 1100::202

如你所见，地址已包含在后端调用中，它只需要做的是

• 提取 Local: true 的地址
• 为 ExternalIPs 设置 iptables 规则

一个执行此操作的脚本可能如下所示

xip=$(cat /tmp/out | jq -r .Service.IPs.ExternalIPs.V6[0])
podip=$(cat /tmp/out | jq -r '.Endpoints[]|select(.Local == true)|select(.IPs.V6 != null)|.IPs.V6[0]')
ip6tables -t nat -A PREROUTING -d $xip/128 -j DNAT --to-destination $podip

假设上述 JSON 输出存储在 /tmp/out 中（jq 是一个很棒的程序！）。

鉴于这是一个示例，我们通过稍微修改上面的 kpng-json 后端来简化操作。不再是仅仅打印，而是调用一个程序，并将 JSON 输出通过 stdin 传递给该程序。该后端可以独立测试

CALLOUT=jq kpng-callout

其中 jq 可以替换为你自己的程序或脚本。脚本可能类似于上面的示例。有关更多信息和完整示例，请参阅 https://github.com/kubernetes-sigs/kpng/tree/master/examples/pipe-exec。

总结

尽管 kpng 仍处于早期开发阶段，但本文旨在展示未来如何构建自己的专用 Kubernetes 代理。你的应用唯一需要做的就是在 Service 清单中添加 service.kubernetes.io/service-proxy-name 标签。

将新功能添加到 kube-proxy 是一个繁琐的过程，并且很可能会被拒绝，因此编写一个专用代理可能是唯一的选择。

• ←上一篇
• 下一篇→