在公有云环境中，LoadBalancer Service 通常由云厂商的负载均衡器实现；但在裸机或普通内网 Kubernetes 环境中，集群本身通常没有对应的 LoadBalancer 实现。因此，如果没有额外部署 MetalLB 等组件，服务一般只能通过 NodePort、hostNetwork 或外部负载均衡器等方式暴露。

然而，MetalLB提供了这一功能，通过IPAddressPool，将同网段的IP地址声明为VIP地址，并通过Speaker宣告此IP，可以让应用通过Load Balancer的方式对外提供应用。

本文将以一个单节点k3s作为实验环境，从0部署MetalLB、IpAddressPool、L2Advertisement等CRD，并以当前博客为Demo，搭建一个使用Load Balancer提供访问能力的博客服务。

实验环境#

用途	配置
节点	`k3s`，`10.211.55.26/24`，`enp0s5`
K3s Pod CIDR	`10.42.0.0/16`
Calico IPPool	`10.42.0.0/16`
Service CIDR	`10.43.0.0/16`
Calico	Operator 管理、VXLAN、iptables、BGP 禁用
kube-proxy	iptables
ServiceLB/Traefik	从 K3s 安装时禁用
SELinux	禁用
firewalld	禁用，避免干扰 K3s/Calico 规则

安装k3s#

节点预处理#

确保以下内核能力和ipv4流量转发功能开启

1
sysctl net.ipv4.ip_forward
2
modprobe br_netfilter
3
modprobe vxlan
4
# 验证
5
lsmod | grep -E 'br_netfilter|vxlan'

如果 net.ipv4.ip_forward 为 0

1
cat >/etc/sysctl.d/90-kubernetes.conf <<'EOF'
2
net.ipv4.ip_forward = 1
3
EOF
4
# 然后应用配置
5
sysctl --system

创建k3s配置文件#

1
cat > /etc/rancher/k3s/config.yaml << EOF
2
node-name: k3s
3
node-ip: 10.211.55.26
4
cluster-cidr: 10.42.0.0/16
5
service-cidr: 10.43.0.0/16
6
flannel-backend: none
7
disable-network-policy: true
8
kube-proxy-arg:
9
  - proxy-mode=iptables
10
selinux: false
11
disable:
12
  - servicelb
13
  - traefik
14
EOF

然后chmod 600 /etc/rancher/k3s/config.yaml

安装k3s#

1
curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION='v1.36.4+k3s1' sh -

安装完成后，Pod应该都是pending状态，这是正常的，因为目前还没有网络插件

安装Calico#

安装CRD和Operator

1
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.32.1/manifests/v1_crd_projectcalico_org.yaml
2
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.32.1/manifests/tigera-operator.yaml

创建与 K3s 对齐的 Installation，以及 Calico 官方 Operator 安装所需的 APIServer/default

1
cat > /root/metallb/calico-installation.yaml << EOF
2
apiVersion: operator.tigera.io/v1
3
kind: Installation
4
metadata:
5
  name: default
6
spec:
7
  cni:
8
    type: Calico
9
  calicoNetwork:
10
    linuxDataplane: Iptables
11
    bgp: Disabled
12
    containerIPForwarding: Enabled
13
    linuxPolicySetupTimeoutSeconds: 10
14
    nodeAddressAutodetectionV4:
15
      kubernetes: NodeInternalIP
16
    ipPools:
17
      - name: k3s-pod-cidr
18
        blockSize: 26
19
        cidr: 10.42.0.0/16
20
        encapsulation: VXLAN
21
        natOutgoing: Enabled
22
        nodeSelector: all()
23
---
24
apiVersion: operator.tigera.io/v1
25
kind: APIServer
26
metadata:
27
  name: default
28
spec: {}
29
EOF

然后

1
kubectl apply --dry-run=server -f calico-installation.yaml
2
kubectl apply -f calico-installation.yaml

calico-installation.yaml 固定了 10.42.0.0/16、VXLAN、iptables、BGP Disabled、containerIPForwarding: Enabled，并用 Kubernetes NodeInternalIP 识别节点地址。

第二份资源 APIServer/default 会部署 Tigera API server；缺少它时，tigerastatus/tiers 会持续显示 Waiting for Tigera API server to be ready。

检查资源状态

1
kubectl get tigerastatus
2
kubectl get apiserver.operator.tigera.io default
3
kubectl get pods -n calico-system -o wide
4
kubectl get pods -n tigera-operator -o wide
5
kubectl get ippools.crd.projectcalico.org -o wide

确保资源都存在，并且状态正常

所有 TigeraStatus 必须 AVAILABLE=True、PROGRESSING=False、DEGRADED=False，Calico Pod 必须为 Running状态

验证

1
kubectl get node k3s -o jsonpath='nodePodCIDR={.spec.podCIDR}{"\n"}'
2

3
kubectl get ippool.crd.projectcalico.org k3s-pod-cidr -o jsonpath='calicoPool={.spec.cidr}{"\n"}vxlanMode={.spec.vxlanMode}{"\n"}'
4

5
grep -n '"allow_ip_forwarding": true' /etc/cni/net.d/10-calico.conflist

预期结果如下：

1
nodePodCIDR=10.42.0.0/24
2
calicoPool=10.42.0.0/16
3
vxlanMode=Always

安装Helm#

1
dnf install -y helm
2
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
3
helm list --all-namespaces

K3s 自带的 kubectl 默认读取 /etc/rancher/k3s/k3s.yaml，独立安装的 Helm 不会自动使用该路径。没有设置 KUBECONFIG 时，Helm会尝试连接 http://localhost:8080，并返回错误；

后续 Helm 集群操作同时显式传入 --kubeconfig，避免因 shell 会话变化而丢失设置。

部署MetalLB#

安装MetalLB Controller#

1
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.16.1/config/manifests/metallb-native.yaml

渲染Envoy Gateway CRD#

使用Helm生成 Gateway API standard CRD和Envoy Gateway扩展CRD

注意: Helm 4 在拉取 OCI chart 时会把 Pulled: 和 Digest: 输出到标准输出，不能把原始标准输出直接作为 Kubernetes YAML。需要将原始输出保存为文件，再从第一个 YAML 文档分隔符开始提取：

1
RAW_CRDS=/tmp/envoy-gateway-crds-v1.9.1.raw
2
RENDERED_CRDS=/tmp/envoy-gateway-crds-v1.9.1.yaml
3

4
helm template eg-crds \
5
  oci://docker.io/envoyproxy/gateway-crds-helm \
6
  --version v1.9.1 \
7
  --set crds.gatewayAPI.enabled=true \
8
  --set crds.gatewayAPI.channel=standard \
9
  --set crds.envoyGateway.enabled=true \
10
  > "$RAW_CRDS"
11

12
sed -n '/^---$/,$p' "$RAW_CRDS" > "$RENDERED_CRDS"
13

14

15
kubectl apply --server-side --dry-run=server -f "$RENDERED_CRDS"
16
kubectl apply --server-side -f "$RENDERED_CRDS"

验证安装:

1
kubectl get crd gateways.gateway.networking.k8s.io \
2
  -o go-template='version={{ index .metadata.annotations "gateway.networking.k8s.io/bundle-version" }} channel={{ index .metadata.annotations "gateway.networking.k8s.io/channel" }}{{ "\n" }}'
3
kubectl get crd gateways.gateway.networking.k8s.io \
4
  httproutes.gateway.networking.k8s.io \
5
  envoyproxies.gateway.envoyproxy.io

安装Envoy gateway controller#

1
helm install eg oci://docker.io/envoyproxy/gateway-helm \
2
  --version v1.9.1 \
3
  --namespace envoy-gateway-system \
4
  --create-namespace \
5
  --set crds.enabled=false \
6
  --kubeconfig /etc/rancher/k3s/k3s.yaml

安装成功后，应该显示以下内容:

1
Pulled: docker.io/envoyproxy/gateway-helm:v1.9.1
2
Digest: sha256:91bae9aedb91ab34731e987afe01a3ccf454393015abeca705eea8ee15553e86
3
NAME: eg
4
LAST DEPLOYED: Mon Aug 31 15:45:42 2026
5
NAMESPACE: envoy-gateway-system
6
STATUS: deployed
7
REVISION: 1
8
DESCRIPTION: Install complete
9
TEST SUITE: None
10
NOTES:
11
**************************************************************************
12
*** PLEASE BE PATIENT: Envoy Gateway may take a few minutes to install ***
13
**************************************************************************
14

15
Envoy Gateway is an open source project for managing Envoy Proxy as a standalone or Kubernetes-based application gateway.
16

17
Thank you for installing Envoy Gateway! 🎉
18

19
Your release is named: eg. 🎉
20

21
Your release is in namespace: envoy-gateway-system. 🎉
22

23
To learn more about the release, try:
24

25
  $ helm status eg -n envoy-gateway-system
26
  $ helm get all eg -n envoy-gateway-system
27

28
To have a quickstart of Envoy Gateway, please refer to https://gateway.envoyproxy.io/latest/tasks/quickstart.
29

30
To get more details, please visit https://gateway.envoyproxy.io and https://github.com/envoyproxy/gateway.

使用MetalLb为服务提供Load Balancer IP#

创建IP池#

1
cat > ipaddresspool.yaml << EOF
2
apiVersion: metallb.io/v1beta1
3
kind: IPAddressPool
4
metadata:
5
  name: uat
6
  namespace: metallb-system
7
spec:
8
  autoAssign: false
9
  addresses:
10
    - 10.211.55.251/32
11
---
12
apiVersion: metallb.io/v1beta1
13
kind: IPAddressPool
14
metadata:
15
  name: sit
16
  namespace: metallb-system
17
spec:
18
  autoAssign: false
19
  addresses:
20
    - 10.211.55.252/32
21
---
22
apiVersion: metallb.io/v1beta1
23
kind: IPAddressPool
24
metadata:
25
  name: prod
26
  namespace: metallb-system
27
spec:
28
  autoAssign: false
29
  addresses:
30
    - 10.211.55.253/32
31
EOF

这里我将IP池拆分成三个，分别对应不同的模拟环境，如UAT/SIT/PROD；
当IP地址只有一个时（指定IP），应将掩码设置为 /32
可以设置多个地址，比如通过10.211.55.240-10.211.55.249设置指定的地址段，或者通过CIDR指定可分配的地址范围10.211.55.240/28
如果想要随机分配IP，可以将autoAssign设置为true

之后kubectl apply -f ipaddresspool.yaml应用配置

使用kubectl get ipaddresspool -A可以看到如下地址池:

1
root@k3s:~/metallb/prod# kubectl get ipaddresspool -A
2
NAMESPACE        NAME   AUTO ASSIGN   AVOID BUGGY IPS   ADDRESSES
3
metallb-system   prod   false         false             ["10.211.55.253/32"]
4
metallb-system   sit    false         false             ["10.211.55.252/32"]
5
metallb-system   uat    false         false             ["10.211.55.251/32"]

创建L2Advertisemnt#

1
cat > l2advertisement.yaml << EOF
2
apiVersion: metallb.io/v1beta1
3
kind: L2Advertisement
4
metadata:
5
  name: env-vips
6
  namespace: metallb-system
7
spec:
8
  # 宣告从这些池中分配给 Service 的 VIP
9
  ipAddressPools:
10
    - uat
11
    - sit
12
    - prod
13

14
  # 只允许 hostname 标签为 k3s 的节点负责宣告
15
  nodeSelectors:
16
    - matchLabels:
17
        kubernetes.io/hostname: k3s
18

19
  # 从该节点的这张网卡宣告
20
  interfaces:
21
    - enp0s5
22
EOF

L2Advertisement用来告诉 MetalLB，哪些地址池中已经分配给 Service 的 VIP，需要通过哪些节点、哪些网卡向局域网宣告。

VIP 通常不会出现在节点的 ip addr 结果中；MetalLB Speaker 通过 ARP/NDP 让局域网认为该 VIP 由当前节点持有，而不是像Keepalived一样将一个虚拟IP切实绑定在某个虚拟机上。

它解决的是：客户端知道 VIP 后，应该把网络报文发给哪台机器。

以UAT VIP 10.211.55.251 为例：

MetalLB 为 Envoy 的 LoadBalancer Service 分配 10.211.55.251。
同一局域网中的客户端访问这个 VIP，先发送 ARP 请求：“谁拥有 10.211.55.251？”
K3s 节点上的 MetalLB Speaker 根据 L2Advertisement，回答：“把报文发送到我的网卡 MAC 地址。”
客户端将报文发送到 K3s 节点，再由节点的 Service 转发规则送到 Envoy Pod。 IPv4 使用 ARP，IPv6 使用 NDP。Speaker 负责地址宣告，并不代理实际 HTTP 请求。

因此，L2 模式下 MetalLB 并不是一个传统意义上的四层负载均衡器，它主要解决的是 VIP 的分配和二层可达性问题；真正进入节点后的 Service 转发仍由 Kubernetes 数据平面负责。

关于Envoy Pod, L2Advertisement与标签选择器#

在上面的配置里，配置了nodeSelectors，当配置后，只有拥有对应标签的节点才能够宣告VIP；这里我只有一个节点，所以必然会被绑定到这个节点上；但是事实上，一个VIP同时只能由一个节点进行宣告，因此，一般有两种玩法:

不设定nodeSelector，任何工作节点都可能成为VIP宣告的候选
设定nodeSelector的标签为node-role.kubernetes.io/gateway，由专门的gateway节点负责宣告VIP，并承载流量；这样的节点通常有2-3个或者更多(取决于集群规模)，以确保在一个节点宣告VIP失败时，其他节点能过快速接替宣告

externalTrafficPolicy的两种模式对VIP有效性的影响#

当externalTrafficPolicy设置为local时:

如果节点上有Envoy Pod，但没有实际的工作负载，此时会出现跨节点转发，也就是“多一跳”
MetalLB 会把本地 Envoy Endpoint 作为宣告资格的判断条件,如果节点根本没有Envoy Pod
- 正常情况下，该节点不应成为该VIP的有效宣告节点，因为它没有本地、Ready 的 Envoy Endpoint。
- 如果 nodeSelector只允许VIP宣告在节点A，而Envoy Pod只能运行在其他节点，此时通常会变成: Service 已获得 EXTERNAL-IP，但没有符合条件的节点宣告 VIP，最终VIP是一个仅在记录中存在，但无法被访问的地址

当externalTrafficPolicy设置为cluster时:

此时允许入口节点将流量转发到其他节点上的 Envoy Pod
因此如果宣告VIP的节点上没有Envoy Pod，则必定有至少一跳(从VIP到Envoy Pod所在节点)，如果被选中的envoy Pod所在节点上也，没有工作负载，则会再次出现一次跨节点转发

创建GatewayClass#

Gateway的作用是指定一类 Gateway 由哪个控制器负责管理，类似 Ingress 中的 IngressClass;

1
cat > gatewayclass.yaml << EOF
2
apiVersion: gateway.networking.k8s.io/v1
3
kind: GatewayClass
4
metadata:
5
  name: envoy
6
spec:
7
  controllerName: gateway.envoyproxy.io/gatewayclass-controller
8
EOF

此配置定义了一个名为 envoy 的网关类别，由Envoy Gateway控制器负责处理; 同时，gateway也可以通过gatewayClassName来引用这个控制器;

Envoy Gateway 控制器发现这个 Gateway 使用自己负责的类别后，才会根据配置创建和管理对应的 Envoy Deployment、Service，并下发代理配置。

各个资源的区别#

资源	作用
`GatewayClass`	选择由哪个控制器实现网关
`Gateway`	定义具体网关的监听端口、协议和路由接入范围
`EnvoyProxy`	配置 Envoy 实例，例如副本、资源、Service 注解
`HTTPRoute`	定义 HTTP 请求如何匹配并转发到后端

配置三个环境的EnvoyProxy实例和网关#

先创建namespace

1
kubectl create ns vip-demo

以uat配置为例

1
apiVersion: gateway.envoyproxy.io/v1alpha1
2
kind: EnvoyProxy
3
metadata:
4
  name: uat
5
  namespace: vip-demo
6
spec:
7
  provider:
8
    type: Kubernetes
9
    kubernetes:
10
      envoyDeployment:
11
        replicas: 1
12
        container:
13
          resources:
14
            requests:
15
              memory: 128Mi
16
            limits:
17
              cpu: 500m
18
              memory: 512Mi
19
      envoyService:
20
        annotations:
21
          metallb.io/address-pool: uat
22
          metallb.io/loadBalancerIPs: 10.211.55.251
23
---
24
apiVersion: gateway.networking.k8s.io/v1
25
kind: Gateway
26
metadata:
27
  name: uat
28
  namespace: vip-demo
29
spec:
30
  gatewayClassName: envoy
31
  infrastructure:
32
    parametersRef:
33
      group: gateway.envoyproxy.io
34
      kind: EnvoyProxy
35
      name: uat
36
  listeners:
37
    - name: http
38
      protocol: HTTP
39
      port: 80
40
      allowedRoutes:
41
        namespaces:
42
          from: Same

其中:

EnvoyProxy定义了EnvoyPod的参数，如资源使用等; 通过envoyService声明将使用哪个ipaddresspool
Gateway定义了EnvoyProxy Pod的具体网关的监听端口、协议和路由接入范围; 如果后端服务时HTTPS，则需要在listeners配置对应的协议和端口; 不过要注意的是，外部流量到EnvoyProxy Pod和流量从EnvoyProxy到后端服务并不等价，这其实是两个阶段

成功部署后，应该能看到如下结果:

1
root@k3s:~/metallb/uat# kubectl get gateway -A
2
NAMESPACE   NAME   CLASS   ADDRESS         PROGRAMMED   AGE
3
vip-demo    prod   envoy   10.211.55.253   True         153m
4
vip-demo    sit    envoy   10.211.55.252   True         156m
5
vip-demo    uat    envoy   10.211.55.251   True         153m
6
root@k3s:~/metallb/uat# kubectl get envoyproxy -A
7
NAMESPACE   NAME   AGE
8
vip-demo    prod   153m
9
vip-demo    sit    156m
10
vip-demo    uat    153m

Demo应用部署#

Demo以我当前博客为示例，使用Astro 7框架

构建镜像#

使用分阶段构建的模式编写Dockerfile

1
FROM docker.io/library/node:24-bookworm-slim AS build
2

3
WORKDIR /app
4
ENV CI=true
5

6
RUN corepack enable \
7
    && corepack prepare pnpm@11.22.0 --activate
8

9
COPY package.json pnpm-lock.yaml pnpm-workspace.yaml .npmrc ./
10
RUN pnpm install --frozen-lockfile
11

12
COPY . .
13
RUN pnpm build
14

15
FROM docker.io/nginxinc/nginx-unprivileged:1.29-alpine
16

17
COPY --from=build --chown=101:101 /app/dist/ /usr/share/nginx/html/
18

19
EXPOSE 8080
20
USER 101

构建镜像

1
podman build -t localhost/white-festa-blog:demo-v1 .

将本地镜像导入k3s containerd 本地 Podman/Docker 镜像不会自动出现在 K3s containerd 中，因此需要:

1
# 导入镜像
2
podman save localhost/white-festa-blog:demo-v1 |
3
  k3s ctr images import -
4
# 确认镜像是否成功导入
5
k3s ctr images list | grep white-festa-blog

编写kubernetes manifest#

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: white-festa-blog
5
  namespace: vip-demo
6
  labels:
7
    app.kubernetes.io/name: white-festa-blog
8
    app.kubernetes.io/part-of: metallb-vip-demo
9
spec:
10
  replicas: 1
11
  selector:
12
    matchLabels:
13
      app.kubernetes.io/name: white-festa-blog
14
  template:
15
    metadata:
16
      labels:
17
        app.kubernetes.io/name: white-festa-blog
18
    spec:
19
      containers:
20
        - name: blog
21
          image: localhost/white-festa-blog:demo-v1
22
          imagePullPolicy: Never
23
          ports:
24
            - name: http
25
              containerPort: 8080
26
              protocol: TCP
27
          readinessProbe:
28
            httpGet:
29
              path: /
30
              port: http
31
            initialDelaySeconds: 2
32
            periodSeconds: 5
33
          livenessProbe:
34
            httpGet:
35
              path: /
36
              port: http
37
            initialDelaySeconds: 10
38
            periodSeconds: 10
39
          resources:
40
            requests:
41
              cpu: 20m
42
              memory: 32Mi
43
            limits:
44
              cpu: 200m
45
              memory: 128Mi
46
          securityContext:
47
            allowPrivilegeEscalation: false
48
            capabilities:
49
              drop:
50
                - ALL
51
            runAsNonRoot: true
52
            seccompProfile:
53
              type: RuntimeDefault
54
---
55
apiVersion: v1
56
kind: Service
57
metadata:
58
  name: white-festa-blog
59
  namespace: vip-demo
60
  labels:
61
    app.kubernetes.io/name: white-festa-blog
62
spec:
63
  selector:
64
    app.kubernetes.io/name: white-festa-blog
65
  ports:
66
    - name: http
67
      port: 8080
68
      targetPort: http
69
      protocol: TCP
70
  type: ClusterIP
71
---
72
apiVersion: gateway.networking.k8s.io/v1
73
kind: HTTPRoute
74
metadata:
75
  name: white-festa-blog
76
  namespace: vip-demo
77
  labels:
78
    app.kubernetes.io/name: white-festa-blog
79
spec:
80
  parentRefs:
81
    - name: uat
82
      sectionName: http
83
  #hostnames:
84
  #  - white-festa.local
85
  #  - "*.white-festa.local"
86
  rules:
87
    - matches:
88
        - path:
89
            type: PathPrefix
90
            value: /
91
      backendRefs:
92
        - name: white-festa-blog
93
          port: 8080

service用clusterIP就行，因为直接接受流量的是EnvoyProxy，通过demo的clusterIP service将流量转发到pod中
HTTPRoute和Ingress Rule类似，都是定义路由规则的; parentRefs用来引用Gateway，表示这条路由挂载到哪个网关、哪个 listener 上。
如果要配置域名，可以在HTTPRoute.spec.hostnames中直接声明，可以接受普通域名和通配符域名，不过注意通配符域名不能匹配到根域名，因此如果要同时支持根域名和子域名时，要写两个

最后，根据在IpAddressPool中声明的UAT VIP，可以在宿主机上直接访问这个服务

流量是如何经过MetalLB VIP最终进入Pod的#

先看架构图

实际流量路径：

1
客户端
2
  → ARP 查询 VIP
3
  → MetalLB Speaker 返回节点网卡 MAC
4
  → 报文进入 K3s 节点
5
  → 命中 kube-proxy 为 Envoy LoadBalancer Service 创建的 iptables 规则
6
  → 转发到 Envoy Pod
7
  → Envoy 根据 HTTPRoute 匹配路由
8
  → 根据 backendRef/Service 与 EndpointSlice 解析实际后端
9
  → Envoy 通过 Calico 网络直接访问 Blog Pod:8080

配置HTTPS访问#

配置自签名证书#

1
mkdir -p /root/metallb/demo/white-festa.local
2
cd /root/metallb/demo/white-festa.local
3
umask 077

创建证书

1
openssl req -x509 -nodes -newkey rsa:2048 \
2
  -sha256 \
3
  -days 365 \
4
  -keyout tls.key \
5
  -out tls.crt \
6
  -subj "/CN=white-festa.local" \
7
  -addext "subjectAltName=DNS:white-festa.local" \
8
  -addext "basicConstraints=critical,CA:FALSE" \
9
  -addext "keyUsage=critical,digitalSignature,keyEncipherment" \
10
  -addext "extendedKeyUsage=serverAuth"

创建kubernetes tls secret#

1
kubectl create secret tls white-festa-local-tls \
2
  -n vip-demo \
3
  --cert=/root/metallb/demo/white-festa.local/tls.crt \
4
  --key=/root/metallb/demo/white-festa.local/tls.key \
5
  --dry-run=client -o yaml |
6
kubectl apply -f -

修改 Gateway 和 HTTPRoute#

修改UAT gateway

在gateway.spec下面增加:

1
    - name: https
2
      hostname: white-festa.local
3
      protocol: HTTPS
4
      port: 443
5
      tls:
6
        mode: Terminate
7
        certificateRefs:
8
          - group: ""
9
            kind: Secret
10
            name: white-festa-local-tls
11
      allowedRoutes:
12
        namespaces:
13
          from: Same

其中mode: Terminate意味着客户端发起的 TLS 连接在 Envoy Gateway 处终止并解密。也就说说，客户端到Envoy Pod的请求是HTTPS协议，Envoy Pod转发请求到后端Pod走的是HTTP协议。

如果后端也需要走HTTPS，这被叫做TLS 重加密，在此demo中，需要后端Pod中的Nginx同样支持HTTPS协议，也就是说，TLS证书需要挂载到Pod中，Nginx配置文件也需要配置相应的HTTPS listener

之后，还需要声明一个BackendTLSPolicy资源，确保Envoy Pod到后端也走HTTPS加密。TLS重加密一般在对安全标准要求较高的服务中，比如支付，访问敏感数据等，一般的Web服务在Envoy Pod处终止HTTPS并解密就可以了，在访问量高时也有性能优势。这里就先不配置了。

修改white-festa-blog的HTTPRoute

1
apiVersion: gateway.networking.k8s.io/v1
2
kind: HTTPRoute
3
metadata:
4
  name: white-festa-blog
5
  namespace: vip-demo
6
spec:
7
  parentRefs:
8
    - name: uat
9
      sectionName: http
10
      # 绑定uat gateway中名为https的端口和配置
11
    - name: uat
12
      sectionName: https
13

14
  hostnames:
15
    - white-festa.local
16

17
  rules:
18
    - matches:
19
        - path:
20
            type: PathPrefix
21
            value: /
22
      backendRefs:
23
        - name: white-festa-blog
24
          port: 8080

然后重新apply这两份文件

验证#

指定证书验证

1
curl --resolve white-festa.local:443:10.211.55.251 \
2
  --cacert /root/metallb/demo/white-festa.local/tls.crt \
3
  -I https://white-festa.local/

会得到以下结果:

1
HTTP/2 200
2
server: nginx/1.29.8
3
date: Tue, 01 Sep 2026 03:48:14 GMT
4
content-type: text/html
5
content-length: 740262
6
last-modified: Mon, 31 Aug 2026 07:59:19 GMT
7
etag: "6a953457-b4ba6"
8
accept-ranges: bytes

浏览器访问先设置静态解析:

1
echo '10.211.55.251 white-festa.local' >> /etc/hosts

浏览器访问结果:

如图，证书确实存在，只不过因为是自签名的ssl证书，所以会显示为insecure ssl

实验环境#

安装k3s#

节点预处理#

创建k3s配置文件#

安装k3s#

安装Calico#

安装Helm#

部署MetalLB#

安装MetalLB Controller#

渲染Envoy Gateway CRD#

安装Envoy gateway controller#

使用MetalLb为服务提供Load Balancer IP#

创建IP池#

创建L2Advertisemnt#

关于Envoy Pod, L2Advertisement与标签选择器#

externalTrafficPolicy的两种模式对VIP有效性的影响#

创建GatewayClass#

各个资源的区别#

配置三个环境的EnvoyProxy实例和网关#

Demo应用部署#

构建镜像#

编写kubernetes manifest#

流量是如何经过MetalLB VIP最终进入Pod的#

配置HTTPS访问#

配置自签名证书#

创建kubernetes tls secret#

修改 Gateway 和 HTTPRoute#

验证#

支持与分享

评论区

音乐

音乐

使用MetalLB VIP为原生kubernetes配置负载均衡服务

实验环境#

安装k3s#

节点预处理#

创建k3s配置文件#

安装k3s#

安装Calico#

安装Helm#

部署MetalLB#

安装MetalLB Controller#

渲染Envoy Gateway CRD#

安装Envoy gateway controller#

使用MetalLb为服务提供Load Balancer IP#

创建IP池#

创建L2Advertisemnt#

关于Envoy Pod, L2Advertisement与标签选择器#

externalTrafficPolicy的两种模式对VIP有效性的影响#

创建GatewayClass#

各个资源的区别#

配置三个环境的EnvoyProxy实例和网关#

Demo应用部署#

构建镜像#

编写kubernetes manifest#

流量是如何经过MetalLB VIP最终进入Pod的#

配置HTTPS访问#

配置自签名证书#

创建kubernetes tls secret#

修改 Gateway 和 HTTPRoute#

验证#

支持与分享

评论区

音乐

音乐