裸金属也能Serverless？香港服务器部署Knative实现函数级弹性与冷启动秒开

过去我们总以为Serverless是公有云的专属名词，但当我手里握着一批高性能香港裸金属服务器资源时，一个想法逐渐清晰：能不能在这些“非云”资源上跑出和 FaaS 一样的体验？最终，我选择了 Knative —— 在 Kubernetes 上实现 Serverless 工作负载弹性伸缩的关键组件。本文分享我在香港服务器上从零部署 Knative 的实战过程，如何调优底层资源，解决冷启动问题，实现真正的“函数秒开”和资源按需弹性。

裸金属 + Serverless 的现实意义

在某些场景下，比如高频交易、内容分发、边缘计算，我们常部署在香港节点以兼顾时延和合规。而传统 Serverless 云函数平台（如 AWS Lambda）虽然功能强大，但其跨境访问延迟大、不易定制底层资源的问题始终无法满足我们的需求。

相比之下，香港本地部署的裸金属服务器可以提供：

• 更低的跨境 RTT；
• 更灵活的 GPU / SR-IOV / 本地 SSD 配置；
• 自主控制的网络出入口和合规可控性。

但裸金属天生没有“弹性调度”能力，也不支持按函数级别自动伸缩。我决定在香港的 Kubernetes 集群上部署 Knative，让传统服务器也能“拥抱 Serverless”。

环境准备：裸金属集群打底

我们在香港机房选用了 A5 数据提供的高性能裸金属机型（配置如下）：

规格项	参数
CPU	2 x Intel Xeon Gold 6338
内存	256 GB DDR4 ECC
存储	2 x 1.92TB NVMe + 2 x 10TB HDD
网络	2 x 25Gbps SR-IOV 支持口
地点	香港 MEGA-i 机房

所有服务器采用 Ubuntu 22.04 + containerd，使用 kubeadm 搭建 K8s 1.29 集群，并配置了 Calico + MetalLB（用于公网调度）。

安装 Kubernetes + 基础组件

kubeadm init --pod-network-cidr=192.168.0.0/16
kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

之后配置 MetalLB：

# metallb-config.yaml
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: public-ip-pool
spec:
  addresses:
  - 203.x.x.100-203.x.x.120

安装 Knative Serving：为 Kubernetes 增加“函数引擎”

Knative Serving 是整个 Serverless 能力的核心，它接收 HTTP 请求并按需创建容器。

1. 安装 Istio（作为网关）

istioctl install --set profile=demo
kubectl label namespace default istio-injection=enabled

2. 部署 Knative Serving

kubectl apply -f https://github.com/knative/serving/releases/download/knative-v1.14.0/serving-crds.yaml
kubectl apply -f https://github.com/knative/serving/releases/download/knative-v1.14.0/serving-core.yaml

配置域名（使用 nip.io 做临时解析）：

kubectl patch configmap config-domain \
  -n knative-serving \
  -p '{"data":{"203.x.x.101.nip.io":""}}'

部署第一个函数：Hello Knative

使用官方的 helloworld 示例：

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
spec:
  template:
    spec:
      containers:
        - image: gcr.io/knative-samples/helloworld-go
          env:
            - name: TARGET
              value: "Knative on Bare Metal"

访问地址如下：

curl http://helloworld-go.default.203.x.x.101.nip.io

冷启动优化：秒开函数的实战技巧

初始部署时，我们发现首次访问函数时延较高（2~3 秒）。这是因为 Knative 会 scale-to-zero，当请求来临时才拉起 pod。以下是我们的优化策略：

1. 使用预热 Pod（minScale）

spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/minScale: "1"

2. 缩短冷启动路径

我们把函数镜像优化为 30MB 内的 distroless 镜像，并启用了 lazy loading：

FROM gcr.io/distroless/static
COPY helloworld /
CMD ["/helloworld"]

3. 启用自动容器预加载（gVisor 禁用，使用 native runtime）

containerd 中配置使用 runc 而非 gVisor，以减少 sandbox 初始化开销。

弹性伸缩测试：秒级水平扩展

我们压测 Knative Service 并监控 HPA 的行为，发现 Knative 默认使用 KPA（Knative Pod Autoscaler）进行流量感知扩缩容：

autoscaling.knative.dev/metric: "concurrency"
autoscaling.knative.dev/target: "5"

通过并发访问模拟器（wrk）测试：

wrk -t10 -c100 -d30s http://helloworld-go.default.203.x.x.101.nip.io

Pod 实例从 1s 内由 1 扩容到 5，回落时间可自定义配置。

我们通过本次实战，成功在香港裸金属服务器上搭建了一个支持函数级弹性调度的 Knative Serverless 平台，实现了以下目标：

• 本地函数托管，摆脱云平台束缚；
• 冷启动优化，首请求响应时间 < 400ms；
• 资源按需弹性，自动伸缩收缩；
• 结合 MetalLB 实现公网入口控制；

如果你也拥有香港服务器资源，又希望部署轻量 Serverless 工作负载，Knative + Kubernetes 是一个非常值得尝试的架构选型。

附录：实用工具链推荐

工具名称	用途说明
kubectl	K8s 管理 CLI 工具
istioctl	Istio 安装与管理工具
kourier	替代 Istio 的轻量网关
kn	Knative 的命令行工具
prometheus	监控函数冷启动与延迟
wrk	并发性能测试工具