前言

我们终于搭建好了Headscale控制平面和UI，并解决了统一登陆，现在零信任网络已经完全可以使用了

我们需要完成最后一步：把服务添加进来

在这里就是我的AquaDX Sidecar容器

SideCar的使用

如果你不需要自己搭建控制节点的话直接搭Sidecar就好

TailScale官方提供了Operator的方式自动化去代理容器流量 自动设置之类的

但我觉得不是很有必要，因为我们暂时有且只有一个要代理

而且我们也不是很确定Operator是否支持自定义控制节点，等下白折腾不是炸刚了

后续去看了下，确实是不支持Headscale的，因为他需要Oauth密钥，Headscale并未支持

Github上有Headscale的Operator，但那个已经三年没更新，作者已经弃坑了

我自己下下来Make都过不了

第一次见啥都没动Make都能空指针

反正不管怎么说，手动搭一个sidecar就好

Tailscale作为Sidecar启动的配置

由于Tailscale需要权限创建Secret去持久化自己的状态数据，因此Sidecar关键的在于以下几个点

• 绑定TailscalePod更改同命名空间Secret权限的ServiceAccount，他需要Secret去持久化自己的状态数据
• 增加NET ADMIN的capabilitiy
• Sidecar环境变量应为TS_USERSPACE=false，否则工作在USERSPACE下不是标准的sidecar做法 后面踩坑就是因为这个
• 为了Aqua能通过自检，要把容器的DNS给MagicDNS解析

为了统一和方便，以下Tailscale的Sidecar容器简称为Sidecar

首先实现第一点，给予他ServiceAccount

Role设置如下：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: tailscale
  namespace: aqua-dx
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: tailscale-role
  namespace: aqua-dx
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list", "create", "update", "patch", "delete"]
- apiGroups: [""]
  resources: ["events"]
  verbs: ["get", "create", "patch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: tailscale-rolebinding
  namespace: aqua-dx
subjects:
- kind: ServiceAccount
  name: tailscale
  namespace: aqua-dx
roleRef:
  kind: Role
  name: tailscale-role
  apiGroup: rbac.authorization.k8s.io

然后记得增加serviceAccount的绑定

spec:
  template:
    spec:
      serviceAccountName: tailscale

然后给予他Capabilities

然后设置DNS

整个容器组优先使用MagicDNS，然后才是coreDNS

coreDNS一般是固定的，照着填写就好

然后就翻车了

思考一下，因为我们的Aqua需要解析集群内的地址去访问数据库的Service 同时需要解析MagicDNS去进行80端口的自检

然后Sidecar需要解析集群内地址去更新自己状态的Secret

但如果让Sidecar更改dns，Aqua就翻车了

我们需要自己维护一份DNS给他们用

妈的早知道用Operator了

我在尝试了各种方法之后，我发现

我的Tailscale一直是在Usernamespace下跑的

我是大傻逼（

简而言之，既然需要用Sidecar接管整个容器的网络流量，不仅要给NET_ADMIN权限

但是不要给他hostNetwork的权限 让这两个容器处于独立的网络空间

还要让Sidecar的TS_USERSPACE=false

只有这样Tailscale才会修改两个容器的TUN，只有这样两个容器才真正同属于一个网络空间

之前Aqua一直通不过自检就是因为这个

关键配置如下：

选择ClusterFirst之后不需要添加CoreDNS的IP，等于说我们只需要默认DNS加一个Tailscale的MagicDNS即可

我们让Tailscale的–accept-dns为false，避免他修改Pod的DNS导致Aqua无法解析数据库的Service域名

因为我们用MagicDNS，所以Aqua的配置我们可以写虚拟局域网的内部域名

比如aqua.tailscale.lan 在控制平面可以随便改

能通过80端口的自检就是没问题了，这意味着Aqua能用MagicDNS解析到自己

当然在游戏上也要写相同的域名，否则会ALLS Authentication BAD()

后记

这个AquaDX的迁移是我拖了最久的一件事

主要也是懒

在这过程中还是学到了点东西 也算对Sidecar有了一个较为深入的理解

其实我可以少走很多弯路，我们可以看一下Tailscale的example

make proxy之后会输出一个yaml 我这里贴上来

apiVersion: v1
kind: Pod
metadata:
  name: proxy
spec:
  serviceAccountName: "tailscale"
  initContainers:
    # In order to run as a proxy we need to enable IP Forwarding inside
    # the container. The `net.ipv4.ip_forward` sysctl is not allowlisted
    # in Kubelet by default.
  - name: sysctler
    image: "ghcr.io/tailscale/tailscale:latest"
    securityContext:
      privileged: true
    command: ["/bin/sh"]
    args:
      - -c
      - sysctl -w net.ipv4.ip_forward=1 net.ipv6.conf.all.forwarding=1
    resources:
      requests:
        cpu: 1m
        memory: 1Mi
  containers:
  - name: tailscale
    imagePullPolicy: Always
    image: "ghcr.io/tailscale/tailscale:latest"
    env:
    # Store the state in a k8s secret
    - name: TS_KUBE_SECRET
      value: "tailscale"
    - name: TS_USERSPACE
      value: "false"
    - name: TS_DEBUG_FIREWALL_MODE
      value: auto
    - name: TS_AUTHKEY
      valueFrom:
        secretKeyRef:
          name: tailscale-auth
          key: TS_AUTHKEY
          optional: true
    - name: TS_DEST_IP
      value: ""
    - name: TS_AUTH_ONCE
      value: "true"
    - name: POD_NAME
      valueFrom:
        fieldRef:
          fieldPath: metadata.name
    - name: POD_UID
      valueFrom:
        fieldRef:
          fieldPath: metadata.uid
    securityContext:
      privileged: true

基本上的话就是privileged: true 要给他root权限 我是把userid设为0了 别的差不多了

也算是填了一个不大不小的坑

完事 睡觉

不过看起来MuNet准备替换Aqua了 看看后续发展怎么样 实在不行我打算自己维护一个服务器了

之前Artemis迁移折腾我半天 Artemis更新又严格遵循N-1 自己维护得了