2. 环境准备与基础搭建：Kubernetes集群部署、Cilium与Hubble安装、Helm Chart配置

本章是实战课程的基石。我们将从零搭建一套完整的Kubernetes实验环境，并在此基础上部署Cilium作为CNI插件，同时启用Hubble可观测性组件。所有部署均通过Helm Chart进行标准化管理，为后续的故障注入与自动化回滚演练提供稳定、可复现的基础设施。

2.1 环境概览与版本选型

为保证课程内容的一致性与可复现性，本次实验环境采用以下核心组件版本。建议读者在相同或兼容的版本下进行操作，以避免因版本差异导致的兼容性问题。

组件 版本 说明
Kubernetes v1.28.7 使用kubeadm部署，兼容Cilium 1.15+
Cilium v1.15.5 作为CNI与eBPF运行时，启用Hubble
Hubble v1.15.5 随Cilium Helm Chart一同安装
Helm v3.14.0 包管理工具，用于部署Cilium
操作系统 Ubuntu 22.04 LTS 内核版本 5.15+，支持eBPF
版本兼容性提示： Cilium 1.15 要求 Kubernetes 版本 >= 1.26。请确保你的集群版本满足此要求，否则可能导致Cilium Agent启动失败。

2.2 Kubernetes集群部署（kubeadm方式）

我们使用kubeadm在3台Ubuntu节点上部署一个高可用的Kubernetes集群。集群包含1个控制平面节点和2个工作节点。

2.2.1 节点初始化与容器运行时安装

在所有节点上执行以下操作：

  1. 更新系统并安装必要依赖：apt-get update && apt-get install -y apt-transport-https ca-certificates curl
  2. 安装containerd作为容器运行时。
  3. 配置内核参数，启用bridge-nf-call-iptables。
  4. 安装kubeadm、kubelet、kubectl并锁定版本。
# 在所有节点上执行
cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF

sudo modprobe overlay
sudo modprobe br_netfilter

# 设置所需的 sysctl 参数，参数在重新启动后保持不变
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables  = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward                 = 1
EOF

# 应用 sysctl 参数而不重新启动
sudo sysctl --system

2.2.2 初始化控制平面

在控制平面节点上执行 kubeadm init。注意，由于我们将使用Cilium作为CNI，初始化时需要跳过默认的CNI安装。

# 在控制平面节点执行
sudo kubeadm init \
  --pod-network-cidr=10.244.0.0/16 \
  --skip-phases=addon/kube-proxy \
  --cri-socket unix:///run/containerd/containerd.sock

# 配置kubectl
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
重要： 我们使用 --skip-phases=addon/kube-proxy 跳过了kube-proxy的安装。这是因为Cilium可以完全替代kube-proxy的功能（通过eBPF实现），从而获得更好的性能和更低的延迟。如果你需要保留kube-proxy，可以省略此参数，但后续Cilium配置中需要调整。

2.2.3 加入工作节点

使用 kubeadm init 输出的 kubeadm join 命令，在两个工作节点上执行，将其加入集群。

# 在工作节点执行（示例命令，实际以控制平面输出为准）
sudo kubeadm join 192.168.1.10:6443 -- <your-> \
    --discovery--ca-cert-hash sha256:<your-hash>

2.3 Cilium与Hubble安装（Helm Chart方式）

集群就绪后，我们使用Helm Chart来部署Cilium。这是官方推荐的生产级部署方式，能够灵活配置Hubble、Cluster Mesh、eBPF等高级特性。

2.3.1 添加Helm仓库并更新

helm repo add cilium https://helm.cilium.io/
helm repo update

2.3.2 创建Cilium配置Values文件

我们创建一个名为 cilium-values.yaml 的配置文件，用于定制化部署。以下配置启用了Hubble、eBPF数据平面，并禁用了kube-proxy。

# cilium-values.yaml
# 全局设置
cluster:
  name: hubble-lab
  id: 1

# 替换kube-proxy
kubeProxyReplacement: true

# eBPF 数据平面
bpf:
  masquerade: true
  tproxy: true

# Hubble 可观测性
hubble:
  enabled: true
  relay:
    enabled: true
  ui:
    enabled: true
    ingress:
      enabled: false  # 生产环境建议开启
  metrics:
    enabled:
      - dns
      - drop
      - tcp
      - flow
      - port-distribution
      - icmp
      - http

# IPAM 模式
ipam:
  mode: kubernetes

# 路由模式
routingMode: native

# 自动检测设备
autoDirectNodeRoutes: true

2.3.3 执行Helm安装

# 在控制平面节点执行
helm install cilium cilium/cilium \
  --namespace kube-system \
  --values cilium-values.yaml \
  --version 1.15.5

2.3.4 验证安装状态

安装完成后，通过以下命令验证Cilium和Hubble组件是否正常运行。

# 检查Cilium Pod状态
kubectl -n kube-system get pods -l k8s-app=cilium

# 检查Hubble相关Pod
kubectl -n kube-system get pods -l k8s-app=hubble-relay
kubectl -n kube-system get pods -l k8s-app=hubble-ui

# 使用Cilium CLI检查集群状态
cilium status --wait

预期输出应显示所有Cilium Agent处于 Running 状态，且Hubble Relay与UI也已就绪。

验证要点： 执行 cilium connectivity test 可以运行一套完整的端到端连通性测试，包括Pod间通信、DNS解析、服务转发等。这是确认Cilium网络功能正常的最佳实践。

2.4 部署架构与组件关系

下图展示了部署完成后，Kubernetes集群、Cilium Agent、Hubble Relay与UI之间的逻辑关系与数据流。

Cilium与Hubble部署架构图 Cilium & Hubble 部署架构 Kubernetes Cluster (kube-system Namespace) Control Plane Node kube-apiserver kube-controller-manager kube-scheduler Worker Node 1 Cilium Agent Hubble Observer App Pods Worker Node 2 Cilium Agent Hubble Observer App Pods Hubble Relay gRPC 聚合层 Hubble UI Web 可视化界面 图例： 控制平面 工作节点 Hubble Relay Hubble UI 数据流方向：Hubble Observer → Hubble Relay → Hubble UI

2.5 Helm Chart配置详解

Helm Chart是管理Cilium部署的核心。理解关键配置项对于后续的故障排查和自动化回滚至关重要。下表列出了我们在 cilium-values.yaml 中使用的主要参数及其作用。

配置项 值 作用与影响
kubeProxyReplacement true 启用eBPF完全替代kube-proxy，提升服务转发性能，减少CPU开销。
bpf.masquerade true 使用eBPF进行SNAT，避免iptables性能瓶颈。
hubble.enabled true 启用Hubble可观测性组件，采集网络流数据。
hubble.relay.enabled true 部署Hubble Relay，聚合所有节点的流数据，提供统一查询接口。
hubble.ui.enabled true 部署Hubble UI，提供图形化界面查看网络流与服务依赖。
hubble.metrics.enabled [dns, drop, tcp, ...] 指定Hubble采集的指标类型，用于故障排查和性能分析。
routingMode native 使用原生路由模式，要求底层网络支持Pod CIDR路由，性能优于隧道模式。
配置建议： 在开发/测试环境中，建议开启 hubble.ui.ingress.enabled=true 并配置Ingress，以便通过浏览器直接访问Hubble UI。在生产环境中，应通过kubectl port-forward或内部DNS访问，避免暴露管理界面。

2.6 验证Hubble数据采集

部署完成后，我们通过Hubble CLI快速验证数据采集是否正常。这为后续的故障注入演练提供了数据基准。

# 安装Hubble CLI（在控制平面节点）
export HUBBLE_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/hubble/master/stable.txt)
curl -L --remote-name-all https://github.com/cilium/hubble/releases/download/$HUBBLE_VERSION/hubble-linux-amd64.tar.gz
sudo tar xzvf hubble-linux-amd64.tar.gz -C /usr/local/bin/ hubble

# 通过端口转发连接到Hubble Relay
kubectl port-forward -n kube-system svc/hubble-relay 4245:80 &

# 观察实时网络流
hubble observe --from-pod default/test-pod --to-pod default/nginx-pod

如果配置正确，上述命令将输出两个Pod之间的TCP连接流记录，包含源IP、目标IP、端口、协议、Verdict（转发/丢弃）等关键信息。

2.7 环境验证清单

在进入下一章之前，请使用以下清单确认环境已完全就绪。

  • Kubernetes集群： kubectl get nodes 显示所有节点为 Ready 状态。
  • Cilium Agent： kubectl -n kube-system get pods -l k8s-app=cilium 所有Pod为 Running。
  • Hubble Relay： kubectl -n kube-system get pods -l k8s-app=hubble-relay 状态为 Running。
  • Hubble UI： kubectl -n kube-system get pods -l k8s-app=hubble-ui 状态为 Running。
  • 连通性测试： cilium connectivity test 全部通过。
  • Hubble数据流： hubble observe 能够输出Pod间的网络流记录。
常见问题： 如果Cilium Agent启动失败，请检查节点内核版本是否 >= 5.15，以及 CONFIG_BPF 相关内核选项是否开启。可以使用 cilium sysdump 命令收集诊断信息。

至此，我们的实验环境已全部搭建完成。Kubernetes集群、Cilium CNI、Hubble可观测性栈均已就绪，为后续的eBPF模板制品库构建与自动化回滚演练奠定了坚实的基础。

← 上一章 📖 返回目录 下一章 →