/tags/eks/ Recent content in eks on Hugo -- gohugo.io en Wed, 11 Nov 2026 11:40:00 +0800 /posts/eks-migrate-vpc-cni-to-cilium-ebpf/ Wed, 11 Nov 2026 11:40:00 +0800 /posts/eks-migrate-vpc-cni-to-cilium-ebpf/ 在公有云 Kubernetes 集群中，网络插件（CNI）是承载服务通信的最底层基础设施。默认情况下，AWS EKS 采用官方的 aws-vpc-cni。虽然它与 VPC 路由开箱集成，但在业务微服务高频交互、集群规模扩大或有更严苛的安全审计要求时，会有几个受限之处： 依赖 iptables 与 kube-proxy：随 Service 与 Pod 数量增长，内核中大量的 iptables 规则和连接跟踪（conntrack）带来额外的转发延迟与 CPU 损耗； 缺乏细粒度安全管控：原生 aws-vpc-cni 早期默认不带网络策略，即便开启也以 L4 CIDR 为主，难以支持域名级（FQDN）出网控制或跨微服务探测拦截； 网络可观测性不足：AWS VPC Flow Logs 存在 10–15 分钟延迟，且无法抓取同节点 Pod 间的内部通信； 防御 SSRF 与元数据外带受限：在 Pod 出口层面较难原生拦截针对节点 IMDS（169.254.169.254）的探测或动态外部域名请求。 为了兼顾 AWS 原生私网路由互通与 eBPF 内核级转发性能，可以将 EKS 集群迁移至 Cilium（Standalone ENI IPAM 模式 + kubeProxyReplacement=true）。 以下梳理在 Nitro AL2023 架构、双 CNI 调度隔离、IAM 权限配置、节点滚动替换以及出网安全策略中的落地步骤与注意点。 目标架构与技术选型 为什么选择 Standalone ENI 模式 Cilium 支持多种 IPAM 模式（如 Kubernetes Host-Scope、Cluster-Scope、Overlay/VXLAN 以及云厂商专有模式）。在 AWS 上，最常见的有两种： /posts/eks-alb-ingressgroup-targetgroupbinding/ Sun, 08 Nov 2026 09:00:00 +0800 /posts/eks-alb-ingressgroup-targetgroupbinding/ 在 EKS 上用 AWS Load Balancer Controller（下称 LBC）暴露服务，默认每个 Ingress 都会得到一个独立的 ALB。服务一多，ALB 的个数和费用跟着涨。LBC 有三种共用 ALB 的办法：IngressGroup 把多个 Ingress 的规则合并到一个 ALB 上；TargetGroupBinding 让 ALB 和 Target Group 在集群外建好，LBC 只负责把 Pod 注册进去；Gateway API 用一个 Gateway 对应一个 ALB，各团队在自己的 namespace 里挂 HTTPRoute。文中的行为以 LBC v3.6.2（2026-10-25 发布）对应的文档为准。 默认一个 Ingress 一个 ALB 按 LBC 的文档，Ingress 默认不属于任何 IngressGroup，每个 Ingress 自成一个「implicit IngressGroup」，对应一个 ALB。下面这个 Ingress 会让 LBC 在 AWS 上建一个新的 internet-facing ALB： apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: order-ingress namespace: order-ns annotations: alb. /posts/k8s-pod-dns-short-name-ndots/ Sun, 08 Nov 2026 08:50:30 +0800 /posts/k8s-pod-dns-short-name-ndots/ Pod 里 curl http://nginx-service 能通，curl http://order-service.production 也能通，配置和代码里很少有人写全 nginx-service.default.svc.cluster.local.。把短名称补全成 FQDN 的是容器里 C 库的解析器：kubelet 给 Pod 写好 /etc/resolv.conf，解析器按里面的 search 和 ndots 决定一个名字先拼哪个后缀、什么时候按原样查。同一套规则作用在外部域名上，就会多出一串注定失败的查询。 下面的输出来自 kind 起的 Kubernetes 1.37.0 单节点集群。客户端 Pod 主要用 debian:trixie-slim（glibc 2.41），对照组用 alpine:3.22（musl 1.2.5），都用 getent ahosts 解析，它走 getaddrinfo，每一轮 A 和 AAAA 各发一个查询。CoreDNS 打开了 log 插件并缩到 1 个副本，日志的顺序就是查询的顺序，下面的日志只留了查询类型、名字、返回码、标志位和耗时。集群里建了两个 Service：default 下的 nginx-service 和 production 下的 order-service。 kubelet 写进 Pod 的 resolv.conf Pod 不写 dnsPolicy 时用的是 ClusterFirst（DNS for Services and Pods），kubelet 按它生成 /etc/resolv.conf： kubectl exec client -- cat /etc/resolv.