一、cilium介绍
Cilium 本质上是一个 Kubernetes 的网络与安全组件（通常以 CNI 插件的身份安装），它用 eBPF 在 Linux 内核里实现：Pod/Service 的转发、网络策略（NetworkPolicy）、可观测性（流量可视化/追踪）、负载均衡，甚至部分服务网格能力。
可以把它理解成：“把 Kubernetes 网络、负载均衡和安全策略，尽量下沉到内核里做”，相比传统 iptables 方案更高性能、更可观测、策略能力更强。二、cilium是什么
在 K8s 里，想让 Pod 能互通、能访问 Service、能做 NetworkPolicy，需要一个网络方案。Cilium 通常承担这些职责：
1. CNI（容器网络接口）：给 Pod 分配 IP、配置路由/隧道/网卡，把 Pod 接入集群网络
2. Service 负载均衡实现：让访问 ClusterIP/NodePort/LoadBalancer 服务能正确转发到后端 Pod
3. 网络安全策略：实现 Kubernetes NetworkPolicy，甚至更强的 L3/L4/L7（HTTP/gRPC/DNS）策略
4. 网络可观测性：看到“谁在跟谁说话、延迟多少、丢包在哪里、命中了哪些策略”
5. （可选）替代 kube-proxy：用 eBPF 实现 Service 转发（kube-proxy replacement）三、cilium有什么用（解决了哪些痛点）
A. 更快、更稳的转发与负载均衡
传统 kube-proxy 依赖 iptables/ipvs，规则多了会膨胀、调试困难。Cilium 用 eBPF 做转发和 LB：
1. 内核态快速转发（少走用户态/少遍历规则）
2. 大规模 Service/Endpoint 场景下更稳定
3. 更容易观测“为什么这次转发去了哪个后端、命中什么规则”
B. 更强的安全能力（不仅是“允许/拒绝”）
K8s 原生 NetworkPolicy 更多是 L3/L4（IP/端口）。Cilium 能做到更细：
1. 按 Pod 标签、命名空间、服务账户 做策略（身份感更强）
2. L7 策略（可选，通常依赖 Envoy）：
3. 允许某些 HTTP Path / Method
4. gRPC 服务/方法级别控制
5. DNS 解析策略（允许访问哪些域名）
C. 可观测性（排障神器）
Cilium 自带/配套 Hubble（可选）可以做到：
1. 实时看流量（flow logs）：谁访问了谁、是允许还是被拒绝、RTT、丢包
2. 快速定位：是 DNS 问题？策略拦了？还是 Service LB 选后端异常？
D. 可选的高级能力（看你是否启用）
不同环境会选用其中一部分能力：
1. 透明加密（节点间/Pod 间加密）
2. BGP/路由通告（部分场景下替代或配合传统 LB）
3. Gateway API / Ingress（通过 cilium-envoy）
4. 多集群互联（ClusterMesh）三、cilium是怎么工作的（核心：eBPF 数据面）
关键点：eBPF
eBPF 是 Linux 内核机制，允许把程序挂到内核的网络钩子上（如 tc、XDP、cgroup），从而：
1. 在包进入/离开网卡、进入容器、进入 socket 前后做处理
2. 实现 NAT、负载均衡、策略过滤、可观测统计
3. 尽量减少 iptables 链式规则带来的复杂性
Cilium 常见组件（你 kubectl get pod -n kube-system 看到的那些）
1. cilium (DaemonSet)：每个节点一个 agent，负责该节点上的转发/策略/eBPF 程序装载
2. cilium-operator (Deployment)：做控制面工作（例如管理 IPAM、节点资源、状态同步等）
3. cilium-envoy (DaemonSet，可选)：用于 L7 能力/Gateway/Ingress 等（不是所有场景都必须）四、IPAM 是什么
IPAM = IP Address Management，就是“Pod 的 IP 从哪里来、怎么分配、怎么回收”。
Cilium 支持多种 IPAM 模式（不同环境选不同方式），常见两类理解：
1. kubernetes 模式：Pod IP 通常来自每个节点的 PodCIDR（例如你看到的 10.244.x.x）
2. cluster-pool / 等模式：由 Cilium 自己维护一个地址池分配（适合一些特定架构或需要 Cilium 管理地址的场景）
遇到的现象（Helm 改了 ipam.mode=kubernetes 但不重启不生效）很符合实际（后面案例）：
ConfigMap 改了 ≠ agent 自动 reload，Cilium agent 还是用旧配置跑着，所以要 rollout restart 让它重新读取配置并重新装载相关 datapath这两个模式本质上都在做一件事：给每个节点准备一段“Pod 子网（PodCIDR）”，然后由该节点上的 cilium-agent 在这段子网里给 Pod 分 IP。真正的核心区别只有一个：
“每个节点的 PodCIDR 由谁来分配/作为事实来源（Source of Truth）？
- cluster-pool / cluster-scope（默认）：PodCIDR 由 Cilium Operator 分配，写到 v2.CiliumNode 里。
- kubernetes（Kubernetes Host Scope）：PodCIDR 由 Kubernetes 分配，写到 v1.Node.spec.podCIDR(s) 里（依赖 kube-controller-manager 分配 Node CIDR）。
cluster-pool / cluster-scope（Cilium 管 PodCIDR）
机制:
- Cilium Operator 从你配置的 clusterPoolIPv4PodCIDRList 里切块，给每个节点分一个 PodCIDR，记录在 CiliumNode。
- 节点上的 cilium-agent 再从该 PodCIDR 里发放 Pod IP。
优点:
- 不依赖 Kubernetes 给 Node 下发 PodCIDR：很多环境（尤其是你没法改 controller-manager 参数、或 K8s 不分配 PodCIDR 的场景）会更省事。
- 集群地址池扩容相对直观：池不够了可以往 clusterPoolIPv4PodCIDRList 追加新的 CIDR（注意是“追加”，不要改已有元素）。
- 支持 “集群多 CIDR”（多段池）——官方 IPAM 能力表里，cluster-scope 这一项是
缺点/坑点:
- 和“标准 Kubernetes 语义”有点脱钩：因为 Node 的 spec.podCIDR 不是事实来源（可能为空或不一致），某些依赖 Node PodCIDR 的外部组件/脚本可能不适配（例如你自己写的自动化、某些网络周边控制器）。
- 默认池容易和节点网段冲突：文档明确提醒默认 10.0.0.0/8 如果跟节点网络重叠会直接炸（跨节点通信会被误判成 Pod 流量）。
- 控制面多了一个 CiliumNode（CRD）对象：排障时要懂它（但对运维来说也不算坏事）。ipam.mode=kubernetes（Kubernetes Host Scope，K8s 管 PodCIDR）
机制:
- Cilium 从 Kubernetes Node 上读 spec.podCIDR(s)，在该范围内分配 Pod IP。
- 文档强调：需要 kube-controller-manager 开启 --allocate-node-cidrs 才能给节点分 PodCIDR。
优点:
- 最“原生 Kubernetes”：Node 的 spec.podCIDR 就是标准字段，很多周边组件、工具链、排障习惯都默认看它。
- 和集群初始化参数（如 kubeadm 的 --pod-network-cidr）天然一致：你想让 Pod 都落在 10.244.0.0/16 这种规划网段时更符合直觉。
- 配合云厂商/托管集群时，若平台本身就按 Node 分配 PodCIDR，这个模式更顺滑。
缺点:
- 依赖 Kubernetes 能正确分配 Node PodCIDR：如果你的集群没开 allocate-node-cidrs、或托管环境不给 PodCIDR，这个模式会卡 Pod 分配/导致 Pod 起不来。
- “集群多 CIDR”不支持（能力表里 Kubernetes Host Scope 这项是 ❌）。
- 想扩容地址空间通常会牵涉更大范围的 K8s 网络规划调整（成本更高）。选哪个？
你能控制/确认 Kubernetes 会给 Node 分 PodCIDR（kubeadm 常见） → 优先选 ipam.mode=kubernetes：标准、兼容性好、排障直观。
你没法/不方便让 Kubernetes 分 PodCIDR，或希望 Cilium 自己掌控地址池（并可能需要多段 CIDR） → 选 cluster-pool/cluster-scope。Cilium 官方明确建议：不要在“存量集群”里随意切换 IPAM 模式，可能造成持续的网络中断风险；最安全是新集群按目标 IPAM 重装。你这次切换后通过重启恢复正常，说明你场景比较“干净”，但生产环境还是要非常谨慎。五、什么时候适合用 Cilium
很适合这些场景：
1. 集群规模比较大、Service/Endpoint 多，追求性能和稳定性
2. 对 NetworkPolicy 有较强需求，想要更细粒度的安全控制
3. 经常排查网络问题，希望“看得见流量”
4. 想减少 kube-proxy/iptables 的复杂度
不一定要上满功能（比如 L7、Gateway、加密、BGP），很多团队只用它当高性能 CNI + NetworkPolicy + 可观测性，就已经很值了。六、ubuntu 22.04 部署Cilium
前置条件（每个节点都要满足）
Linux kernel ≥ 5.10（Ubuntu 22.04 默认一般是 5.15，通常没问题）。
uname -r6.1 方案 A：用 cilium-cli 快速安装（最省事）（我使用的是方案B）
1) 安装 cilium-cli（在有 kubectl 的那台机器上）
按官方 quick install 文档的 Linux 安装方式：
CILIUM_CLI_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/cilium-cli/main/stable.txt)
CLI_ARCH=amd64
if [ "$(uname -m)" = "aarch64" ]; then CLI_ARCH=arm64; fi
curl -L --fail --remote-name-all \
https://github.com/cilium/cilium-cli/releases/download/${CILIUM_CLI_VERSION}/cilium-linux-${CLI_ARCH}.tar.gz{,.sha256sum}
sha256sum --check cilium-linux-${CLI_ARCH}.tar.gz.sha256sum
sudo tar xzvfC cilium-linux-${CLI_ARCH}.tar.gz /usr/local/bin
rm cilium-linux-${CLI_ARCH}.tar.gz{,.sha256sum}
2) 安装 Cilium（作为 CNI）
官方示例（以文档当时的 stable 版本为例 1.18.5）：
cilium install --version 1.18.53) 验证
cilium status --wait
cilium connectivity test6.2 方案 B：用 Helm 安装（方便走 GitOps/精细配置）
官方 Helm 安装入口：
1) 添加 Helm 仓库并安装
helm repo add cilium https://helm.cilium.io/
helm repo update
helm install cilium cilium/cilium --version 1.18.5 --namespace kube-system2) 验证
cilium status --wait
cilium connectivity test
# 安装前
root@k8s-master-01:~# ls -l /etc/cni/net.d/
total 8
-rw-r--r-- 1 root root 664 Dec 23 01:17 10-calico.conflist
-rw------- 1 root root 2796 Dec 23 01:17 calico-kubeconfig
# 安装后 会把calico重命名 默认使用的cilium
root@k8s-master-02:~# ls -l /etc/cni/net.d/
total 12
-rw------- 1 root root 191 Dec 23 02:01 05-cilium.conflist
-rw-r--r-- 1 root root 664 Dec 23 01:17 10-calico.conflist.cilium_bak
-rw------- 1 root root 2796 Dec 23 01:17 calico-kubeconfig
6.3 此时集群有两个cni插件
Calico 没删时，Cilium + Calico 会不会冲突？
默认会（除非你明确配置了 CNI chaining 让两者协同）。常见情况是：
1. 现有 Pod：基本还是走 Calico（它们创建时用的就是 Calico 的 CNI），短时间内通常还能通信。
2. 新建 Pod：如果 Cilium 已经把自己的 CNI 配置写进了 /etc/cni/net.d/，而且文件排序优先级比 Calico 高，那么新 Pod 可能会用 Cilium。这样集群就会出现“一部分 Pod 用 Calico，一部分用 Cilium”的混用状态——这时 Pod-Pod 通信非常容易出问题（跨节点路由/overlay/iptables/BPF 规则不一致）。
3. 另外，两套 agent 都在节点上跑，也可能同时改动路由、iptables、BPF 挂载/系统参数，带来不可预期的问题。
需要提前做好预案 删除calico的同时需要把所有的控制器资源如deploy 同时rollout restart 把cni切换成cilium否则就会出现上面说的情况6.4 升级切换
# 这个看你需求上面有说 要说的一点是 改 ConfigMap 之后，Cilium agent / operator 通常需要重启才能读取新配置并重建 datapath。
root@k8s-master-01:~# helm upgrade cilium cilium/cilium \
-n kube-system \
--version 1.18.5 \
--reuse-values \
--set ipam.mode=kubernetes
Release "cilium" has been upgraded. Happy Helming!
NAME: cilium
LAST DEPLOYED: Tue Dec 23 02:28:01 2025
NAMESPACE: kube-system
STATUS: deployed
REVISION: 2
TEST SUITE: None
NOTES:
You have successfully installed Cilium with Hubble.
Your release version is 1.18.5.
For any further help, visit https://docs.cilium.io/en/v1.18/gettinghelp
kubectl -n kube-system rollout restart ds/cilium
kubectl -n kube-system rollout restart ds/cilium-envoy
kubectl -n kube-system rollout restart deploy/cilium-operator# 查看 给每个node节点分配的IP段 IPAM
root@k8s-master-01:~# kubectl get node -o custom-columns=NAME:.metadata.name,PODCIDR:.spec.podCIDR,PODCIDRS:.spec.podCIDRs
NAME PODCIDR PODCIDRS
k8s-master-01 10.244.0.0/24 [10.244.0.0/24]
k8s-master-02 10.244.1.0/24 [10.244.1.0/24]
k8s-node-03 10.244.2.0/24 [10.244.2.0/24]
k8s-node-04 10.244.3.0/24 [10.244.3.0/24]
#为什么会有PODCIDRS和PODCIDR 这是因为k8s后面支持IPV4和IPV6 老的支持支单IP 新的支持数组 多IP配置root@k8s-master-01:~# kubectl get pod -n kube-system -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
cilium-envoy-655sx 1/1 Running 0 6h50m 192.168.30.160 k8s-master-01 <none> <none>
cilium-envoy-6f6jv 1/1 Running 0 6h50m 192.168.30.163 k8s-node-04 <none> <none>
cilium-envoy-7w54q 1/1 Running 0 6h50m 192.168.30.161 k8s-master-02 <none> <none>
cilium-envoy-fg7q6 1/1 Running 0 6h50m 192.168.30.162 k8s-node-03 <none> <none>
cilium-fsq6s 1/1 Running 0 6h50m 192.168.30.161 k8s-master-02 <none> <none>
cilium-g4c79 1/1 Running 0 6h50m 192.168.30.162 k8s-node-03 <none> <none>
cilium-jxmh5 1/1 Running 0 6h50m 192.168.30.160 k8s-master-01 <none> <none>
cilium-operator-84cd4f9cb8-nqtlp 1/1 Running 0 6h50m 192.168.30.161 k8s-master-02 <none> <none>
cilium-operator-84cd4f9cb8-vtphd 1/1 Running 0 6h50m 192.168.30.160 k8s-master-01 <none> <none>
cilium-w4jqv 1/1 Running 0 6h50m 192.168.30.163 k8s-node-04 <none> <none>
coredns-6d58d46f65-2sbtg 1/1 Running 0 6h50m 10.244.2.180 k8s-node-03 <none> <none>
coredns-6d58d46f65-z4l4l 1/1 Running 0 6h50m 10.244.3.158 k8s-node-04 <none> <none>
etcd-k8s-master-01 1/1 Running 5 (8h ago) 2d4h 192.168.30.160 k8s-master-01 <none> <none>
etcd-k8s-master-02 1/1 Running 1 (8h ago) 2d3h 192.168.30.161 k8s-master-02 <none> <none>
kube-apiserver-k8s-master-01 1/1 Running 2 (8h ago) 2d4h 192.168.30.160 k8s-master-01 <none> <none>
kube-apiserver-k8s-master-02 1/1 Running 1 (8h ago) 2d3h 192.168.30.161 k8s-master-02 <none> <none>
kube-controller-manager-k8s-master-01 1/1 Running 7 (8h ago) 2d4h 192.168.30.160 k8s-master-01 <none> <none>
kube-controller-manager-k8s-master-02 1/1 Running 1 (8h ago) 2d3h 192.168.30.161 k8s-master-02 <none> <none>
kube-proxy-44cbs 1/1 Running 1 (8h ago) 2d4h 192.168.30.160 k8s-master-01 <none> <none>
kube-proxy-bjjb2 1/1 Running 1 (8h ago) 2d3h 192.168.30.163 k8s-node-04 <none> <none>
kube-proxy-bvptw 1/1 Running 1 (8h ago) 2d3h 192.168.30.161 k8s-master-02 <none> <none>
kube-proxy-m5dt2 1/1 Running 1 (8h ago) 2d3h 192.168.30.162 k8s-node-03 <none> <none>
kube-scheduler-k8s-master-01 1/1 Running 6 (8h ago) 2d4h 192.168.30.160 k8s-master-01 <none> <none>
kube-scheduler-k8s-master-02 1/1 Running 2 (8h ago) 2d3h 192.168.30.161 k8s-master-02 <none> <none>
只要你的业务是多副本/有滚动策略，通常只是“抖一下”，不会全断；单副本服务会有短暂不可用，这是任何 CNI 迁移都绕不开的。
#部署前
root@k8s-master-01:~# ls -l /etc/cni/net.d/
total 8
-rw-r--r-- 1 root root 664 Dec 23 01:17 10-calico.conflist
-rw------- 1 root root 2796 Dec 23 01:17 calico-kubeconfig
#部署后 会把calico重命名 后续pod的创建会默认走cilium 所以cilium启动好后 需要把所有业务pod 都重启一遍
root@k8s-master-01:~# ls -l /etc/cni/net.d/
total 12
-rw------- 1 root root 191 Dec 23 02:03 05-cilium.conflist
-rw-r--r-- 1 root root 664 Dec 23 01:17 10-calico.conflist.cilium_bak
-rw------- 1 root root 2796 Dec 23 01:17 calico-kubeconfig七、Cilium组件
7.1 Cilium Agent（DaemonSet，每节点 1 个）
这是 Cilium 的核心，每个节点都必须有。
主要功能：
eBPF 数据面加载与维护
- 在节点内核里加载 eBPF 程序（TC/XDP、cgroup hooks 等），实现 Pod 之间转发、Service 负载均衡、网络策略等。
- 维护 Cilium 的 BPF maps（相当于内核里的高性能“路由/连接/策略表”）。
管理 Pod/Endpoint 生命周期
- 监听 K8s（Pod/Service/EndpointSlice/Node 等）变化，创建/更新 CiliumEndpoint 等资源。
- 负责把“这个 Pod 的 IP/身份/策略”下发到本节点的数据面。
Kubernetes Service 转发（L4）
- 用 eBPF 做 Service 的四层负载均衡、DNAT/SNAT、session affinity 等（即使你没开 kube-proxy replacement，也会参与很多转发能力）。
NetworkPolicy 落地
- 处理 K8s NetworkPolicy / CiliumNetworkPolicy / CiliumClusterwideNetworkPolicy，转换成 eBPF 可执行的规则。
可选能力
- Hubble（可观测）、加密（WireGuard/IPsec）、eBPF HostRouting、Egress Gateway、带宽管理等（取决于你装的时候开没开）。
一句话：cilium Pod 就是每个节点的“网络内核驱动 + 控制代理”。7.2 Envoy 代理（DaemonSet，每节点 1 个）
这是 L7/Ingress/Gateway API 等功能的“七层代理执行器”。
Cilium 本身用 eBPF 擅长 L3/L4（IP/端口/连接层面的东西），但如果你要做这些就需要 Envoy：
- L7 网络策略（HTTP/gRPC/Kafka 等按域名、路径、方法、Header 的策略）
- Ingress / Gateway API（很多场景由 Envoy 承担实际转发）
- TLS 终止/重加密、L7 可观测（看你启用的功能）
工作方式通常是：
- cilium agent 用 eBPF 把某些流量“重定向”给本机的 cilium-envoy
- Envoy 做完七层处理后再把流量送回去继续转发
一句话：cilium-envoy 是 Cilium 的 L7 扩展引擎。7.3 Cilium Operator（Deployment，集群级 1~2 个）
这是 集群级控制面组件，不需要每节点一个。
它主要负责“跨节点/全局”的事情，比如：
1.IPAM/地址相关的集群级管理
- 你现在 ipam: kubernetes：PodCIDR 是 Kubernetes 控制器分给 Node 的，agent 按 Node 的 PodCIDR 分配 Pod IP。
- 即便如此，operator 仍会参与一些 Node/CRD 的维护工作（不同版本细节略有差异）。
2.LB-IPAM（你已经开启）
- 你 config 里 enable-lb-ipam: "true"、default-lb-service-ipam: lbipam
- 这意味着：当你创建 type: LoadBalancer 的 Service 时，Cilium 可以用 LB-IPAM 给它分配外部 IP（来自你配置的地址池/策略）。
- 这类“全局分配/回收”的事通常由 operator 负责协调，agent 负责在节点上落实转发。
3.管理/清理一些全局资源
- 例如身份（identity）相关、旧对象回收、状态一致性维护等（具体看你启用的功能和版本）。
一句话：cilium-operator 是 Cilium 的“集群级大管家”，负责全局资源协调。八、开启UI
#最简单一把梭
helm upgrade cilium cilium/cilium -n kube-system --version 1.18.5 --reuse-values \
--set hubble.relay.enabled=true \
--set hubble.ui.enabled=true \
--set hubble.ui.service.type=NodePort
九、开启kube-proxy-free 代替集群原来的 kube-proxy
用 kubeconfig 里的 server 作为 k8sServiceHost
在 master 上执行，看看你的 kubeconfig 当前指向哪个 apiserver（通常是 VIP/LB，强烈建议用 VIP/LB，不要写死单个 master IP）：
root@k8s-master-01:~# kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}'; echo
https://192.168.30.58:16443
helm upgrade cilium cilium/cilium -n kube-system --version 1.18.5 --reuse-values \
--set kubeProxyReplacement=true \
--set k8sServiceHost=192.168.30.58 \
--set k8sServicePort=6443
kubectl -n kube-system rollout restart ds/cilium
kubectl -n kube-system rollout restart deploy/cilium-operator
验证是否开启
root@k8s-master-01:~# kubectl -n kube-system exec ds/cilium -- cilium-dbg status | grep KubeProxyReplacement
KubeProxyReplacement: True [ens33 192.168.30.160 192.168.30.58 fe80::20c:29ff:fef6:2d (Direct Routing)]#备份
kubectl -n kube-system get ds kube-proxy -o yaml > kube-proxy.ds.yaml
kubectl -n kube-system get cm kube-proxy -o yaml > kube-proxy.cm.yaml
#删除 kube-proxy DaemonSet + ConfigMap（官方推荐连 CM 也删，避免 kubeadm 升级时装回来
kubectl -n kube-system delete ds kube-proxy
kubectl -n kube-system delete cm kube-proxy
#每个节点清理遗留 KUBE* iptables 规则（官方给的命令）
不能随便执行 如果你节点上面有特定的规则 还有就是执行后 ssh会连接不上 实在要执行先执行前面这两条 保证ssh和已建立连接永久放行
iptables -I INPUT 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -I INPUT 2 -p tcp --dport 22 -j ACCEPT
iptables-save | grep -v KUBE | iptables-restore十、开启Gateway api
#安装 Gateway API 的 standard CRDs（否则 apiserver 里没有 Gateway/GatewayClass/HTTPRoute 这些资源）
kubectl apply --server-side=true -f \
https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.0/standard-install.yaml
#在 Cilium 里开启 Gateway API Controller
helm upgrade cilium cilium/cilium -n kube-system --version 1.18.5 --reuse-values \
--set gatewayAPI.enabled=true#选择暴露方式（二选一）
有 LoadBalancer 能力（云 LB / MetalLB）：不用 hostNetwork（默认走 LB Service）
没有 LoadBalancer 能力（你这种裸金属常见）：开启 hostNetwork
helm upgrade cilium cilium/cilium -n kube-system --version 1.18.5 --reuse-values \
--set gatewayAPI.enabled=true \
--set gatewayAPI.hostNetwork.enabled=true#案例
root@k8s-master-01:~# cat nginx.yaml
apiVersion: v1
kind: Namespace
metadata:
name: webs
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
namespace: webs
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: registry.cn-guangzhou.aliyuncs.com/xingcangku/nginx:1.18
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: nginx-svc
namespace: webs
spec:
selector:
app: nginx
ports:
- name: http
port: 80
targetPort: 80
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: nginx-gw
namespace: webs
spec:
gatewayClassName: cilium
listeners:
- name: http
protocol: HTTP
port: 8080
hostname: nginx.axzys.cn
allowedRoutes:
namespaces:
from: Same
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: nginx-route
namespace: webs
spec:
parentRefs:
- name: nginx-gw
sectionName: http
hostnames:
- nginx.axzys.cn
rules:
- matches:
- path:
type: PathPrefix
value: /
backendRefs:
- name: nginx-svc
port: 80
root@k8s-node-04:~# curl -H 'Host: nginx.axzys.cn' http://192.168.30.160:8080/
no healthy upstreamroot@k8s-node-04:~# curl -H 'Host: nginx.axzys.cn' http://192.168.30.160:8080/
no healthy upstreamrcurl -H 'Host: nginx.axzys.cn' http://192.168.30.160:8080/ | head30.160:8080/ | head
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 612 100 612 0 0 21315 0 --:--:-- --:--:-- --:--:-- 21857
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
body {
width: 35em;
margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;
}
在浏览器中显示需要hosts文件中添加上
评论 (0)