中文版：在Kubernetes中部署Cloudflare Tunnel – Frank’s Weblog

Cloudflare Tunnel is a tunneling service provided by Cloudflare. With Cloudflare Tunnel you can connect the origin to Cloudflare and provide service without exposing any ports on the server or cluster, therefore minimizing the attack surface.

Cloudflare Tunnel was formerly known as Argo Tunnel. Later Cloudflare Tunnel became part of the Cloudflare Zero Trust and became available to all users for free in 2021.

Cloudflare Tunnel had several iterations in the past two years, many tutorials on the internet have become outdated. The latest Cloudflare Tunnel needs no configuration on the client (cloudflared) side besides token. All sites (services) can be configured on the Cloudflare web console. If a tutorial asks you to configure the site on Cloudflared through yaml, the tutorial is likely outdated.

This post will use httpbin as an example to illustrate how to deploy Cloudflared on Kubernetes and serve other services deployed on the cluster.

English Version: Deploy Cloudflare Tunnel on Kubernetes – Frank’s Weblog

Cloudflare Tunnel 是一个隧道服务，通过Cloudflare Tunnel可以无需在服务器上暴露任何端口的情况下将源站连接到Cloudflare并提供服务，从而降低攻击面。

Cloudflare Tunnel以前叫Cloudflare Argo Tunnel。后来Cloudflare Tunnel成为了Cloudflare Zero Trust的一部分，并向所有用户免费提供。

Cloudflare Tunnel在过去两年经过了大量迭代，网络上的很多教程，甚至包括官方的教程都已经过时。最新的Cloudflare Tunnel无需在客户端(Cloudflared)上做除了token之外的任何配置，所有网站（服务）配置都可以通过Cloudflare Web控制台进行。如果一篇教程让你在Cloudflared上通过yaml来配置网站，那么这篇教程大概率是过时的。

本文将以httpbin为例，介绍如何在Kubernetes上部署Cloudflared并路由Kubernetes上部署的其他服务。

中文版：一次Tailscale网络问题的调试过程 – Frank’s Weblog

As mentioned in an earlier post, I used Tailscale to create a mesh network that connects all of my devices, and I used a cloud server located in AliCloud Beijing as an exit node, in order to access geographically restricted internet services.

However, I noticed that I could not access the Internet at all when using that exit node. I thought it was a network connectivity issue with the relays, so I didn’t worry too much about it. But afterward, I noticed some other services on that server stopped functioning, so I looked into it and found out that the problem was not that simple.

First I noticed that I couldn’t access the internet at all from the server, but curl the IP address was working, which indicated the problem with DNS resolution. resolvectl status showed that there were two DNS servers. I assumed this was the DNS server for the Tailscale internal network (actually not, will elaborate later) since the IPs started with 100.100^[1],

Link 2 (eth0)
......
  Current DNS Server: 100.100.2.136
         DNS Servers: 100.100.2.136
                      100.100.2.138

I tried dig @100.100.2.136 baidu.com to check the response from the DNS server and got connection timed out: no servers could be reached. The response from the command became normal after shutting down Tailscale. So probably Tailscale somehow affected the DNS resolution on the system.

English version: Troubleshooting Tailscale Network – Frank’s Weblog

前文提到，我使用Tailscale将我的所有设备组成了一个Mesh网络，并且将位于阿里云北京的轻量应用服务器作为出口节点用于访问一些限制地理位置的网络服务。

然而我却发现在使用该出口节点时完全无法访问互联网。我本以为是Relay的网络质量问题就没有在意。但是后来陆续发现该服务器上的其他一些服务都出现了问题，于是进行了一番检查，结果发现问题并没有这么简单。

首先我发现从服务器上完全无法访问互联网，但是直接curl IP地址是可以的，这样就基本上将问题定位到了DNS上。resolvectl status显示有两个DNS服务器，因为IP以100.100打头^[1]，我以为这是Tailscale内网的DNS服务器（实际上不是，请看后文）。

Link 2 (eth0)
......
  Current DNS Server: 100.100.2.136
         DNS Servers: 100.100.2.136
                      100.100.2.138

我试图dig @100.100.2.136 baidu.com来检查DNS服务器的回应，得到connection timed out: no servers could be reached.。关掉Tailscale之后，上述命令的回应则正常。因此我认为问题在于Tailscale从某种形式上影响了系统的DNS解析。

去年我负责开发了产品中的一个大型feature，这个feature被分解成了A, B两个小feature。大致的工作流程是这样的：

我从master branch out出分支feature-a，在分支feature-a上开发；然后从feature-a branch out出feature-b，在feature-b上开发；最后创建feature-b -> feature-a，feature-a -> master 两个PR分别进行code review并依次合并进master。

当我在开发feature-b时由于master上有了很多更新，于是我将master分别merge进了feature-a和feature-b。整个流程的简化版大致如下：