引入一个实际生产环境案例，介绍在阿里云Ack集群中如何实现Pod独占公网EIP
某线上应用部署在ack集群内，用于根据用户定义的http请求项配置，周期性检查http接口的请求响应状态，接口地址为内网或公网，当接口地址为公网时，频繁出现请求超时的报警错误。经过排查发现，在公网请求发生超时的时刻，集群vpc NAT带宽达到上限200Mbps，也就是25MB/s
分析：由于集群占用vpc，vpc内所有ip（node和pod的ip）都属于vpc内各子网地址，这些地址出公网的请求共用vpc绑定的公网NAT，在某时刻子网ip请求公网使用的EIP是随机的，无法控制，会产生和其他ip同时请求公网使用同一个EIP的情况，由此发生了带宽内拥挤，超限的情况，因此上述超时报警其实是客户端带宽不够产生的误报
为了避免发生上述情况，解决办法是避免这些特定的pod请求公网时和其他ip发生公网带宽的争抢，走独立的公网出口，有以下两种方案：
将这些pod调度到特定的子网node，node的ip和pod的ip会使用特定的子网，这个特定的子网由于在特定的vSwitch虚拟交换机下，因此可以为这个子网单独指定路由条目，也就是将请求公网地址的请求的下一跳路由到特定的公网NAT，特定的公网NAT使用特定的EIP且不和其他子网共用
ack集群的网络使用的是阿里云Terway，在此前提下，阿里云提供了为Terway网络中的Pod挂载独立的公网EIP的解决方案，具体可以查看文档说明，简单来说就是阿里云提供了集群内的控制器，实现了通过k8s原生的声明式配置，调用EIP产品相关api动态为pod绑定EIP的功能
方案一，改动较大，需要将pod调度到特定的node上，且需要人工维护路由条目，维护性较差；
方案二，更为直接，在安装控制器插件后，通过给pod添加特定注解实现目的，主要分为两种方式：
apiVersion: apps/v1
kind: Deployment
metadata:
name: example
labels:
app: example
spec:
replicas: 1
selector:
matchLabels:
app: example
template:
metadata:
labels:
app: example
annotations:
k8s.aliyun.com/pod-with-eip: "true" # 自动创建并绑定EIP
k8s.aliyun.com/eip-bandwidth: "200" # EIP峰值带宽
k8s.aliyun.com/eip-internet-charge-type: "PayByTraffic" # EIP的计量方式
k8s.aliyun.com/eip-instance-charge-type: "PostPaid" # EIP的计费方式
k8s.aliyun.com/eip-name: "app-eip" # EIP名称
k8s.aliyun.com/eip-description: "app-eip" # EIP描述
apiVersion: apps/v1
kind: Deployment
metadata:
name: example
labels:
app: example
spec:
replicas: 1
selector:
matchLabels:
app: example
template:
metadata:
labels:
app: example
annotations:
k8s.aliyun.com/pod-eip-instanceid: eip-2zeXXXXXx # EIP ID
按照文档操作，配置挂载EIP所需的RAM权限
安装插件ack-extend-network-controller，安装时启用插件pod eip的能力，一键安装即可
由于业务目前只有1个pod，为了后续排查方便，选择通过先购买EIP再根据EIP id绑定的方式
购买EIP，按量付费，带宽上限为200Mbps
在deployment的yaml中为pod添加注解，根据EIP id绑定这个EIP即可
spec:
template:
metadata:
annotations:
k8s.aliyun.com/pod-eip-instanceid: eip-xxx
绑定后效果
控制器会自动创建一个和pod名称相同的PodEIP的cr，从这个cr的status中可以看到和上面购买的EIP相关的信息
~ kubectl get pods -o wide|grep app
app-79dcf755fb-ks2ld 1/1 Running 0 47h 10.245.36.4 ack-010245035222packets-spot <none> 1/1
~ kubectl get podeips app-79dcf755fb-ks2ld -o yaml
apiVersion: alibabacloud.com/v1beta1
kind: PodEIP
metadata:
creationTimestamp: "2024-04-01T07:55:46Z"
finalizers:
- podeip-controller.alibabacloud.com/finalizer
generation: 1
name: app-79dcf755fb-ks2ld
namespace: dev
resourceVersion: "2389078403"
uid: 292773d3-80b4-4c88-b0ef-17f011a1530e
spec:
allocationID: eip-xxxxx
allocationType:
releaseStrategy: Follow
type: Static
status:
eipAddress: 101.xxx.xxx.5
internetChargeType: PayByTraffic
isp: BGP
name: app独享
networkInterfaceID: eni-2zexxxxxxxqvrrpxxx
podLastSeen: "2024-04-01T07:39:39Z"
privateIPAddress: 10.xxx.36.4
resourceGroupID: rg-xxxxx5afyhf3xky
status: InUse
以上实现了pod绑定特定EIP的功能，在此条件下，pod请求公网时会固定为此eip出公网，为了保障配置的稳定，经过测试，上面提到此业务pod只有一个副本，且通过deployment管理，属于无状态应用，只做上面为pod添加注解的方式会有以下问题
控制器会在Pod IP分配后，为Pod配置EIP地址，Pod Ready状态可能早于EIP绑定成功时间。解决办法是为pod添加就绪前的检测
kind: Pod
...
spec:
readinessGates:
- conditionType: "k8s.aliyun.com/eip"
...
status:
conditions:
- lastProbeTime: "2022-12-12T03:45:48Z"
lastTransitionTime: "2022-12-12T03:45:48Z"
reason: Associate eip succeed
status: "True"type: k8s.aliyun.com/eip
...
apiVersion: v1
kind: Pod
metadata:
name: example
annotations:
k8s.aliyun.com/pod-with-eip: "true"
spec:
containers:
- name: example
image: busybox:1.28
command: ['sh', '-c', 'echo The app is running! && sleep 3600']
initContainers:
- name: init
image: busybox:1.28
command: ['timeout', '-t' ,'60', 'sh','-c', "until grep -E '^k8s.aliyun.com\\/allocated-eipAddress=\\S?[0-9]+\\S?' /etc/podinfo/annotations; do echo waiting for annotations; sleep 2; done"]
volumeMounts:
- name: podinfo
mountPath: /etc/podinfo
volumes:
- name: podinfo
downwardAPI:
items:
- path: "labels"
fieldRef:
fieldPath: metadata.labels
- path: "annotations"
fieldRef:
fieldPath: metadata.annotations
pod如果发生了滚动更新，且pod在配置有探针的情况下，可以保障始终只有一个pod接收流量，但是无法保证EIP的正常绑定，因为发布过程中有两个pod同时绑定了这个EIP，新pod启动后，老的pod下线调用了解绑EIP的动作，EIP绑定是需要调用接口到vpc去绑定，只有绑定了这个EIP pod的后续探针才会ready。在新pod滚动更新的过程中，会重新绑定EIP，但是旧pod的回收，又会卸载绑定这个EIP
这里EIP当做了创建pod所需的基础资源，实际上EIP并不是pod运行所必须的，解决办法：
A. 修改控制器实现支持在pod滚动更新结束后才将新的pod ip与EIP绑定（下述C可以避免此问题）
B. 将pod的滚动更新模式修改为销毁重建Recreate，这样会损失一定流量
C. 控制器支持有状态应用的pod在一定时间内发生更新后仍然使用之前的EIP，因此把pod由deployment改为statefulset，并声明pod在更新过程中仍然使用之前的EIP即可（固定EIP可以保证Pod重建后依然使用之前的EIP地址。该策略可与自动分配EIP能力结合，用于有状态应用的固定EIP）
annotations:
k8s.aliyun.com/pod-with-eip: "true"
k8s.aliyun.com/pod-eip-release-strategy: "10m"
结合现状，业务pod如果支持多副本模式，可以切换到statefulset并创建2个副本，有状态应用的滚动更新本身就是副本销毁和重新创建，在多副本的情况下不会有流量丢失。目前只有一个（暂不支持多副本模式），且可以接受在升级的过程中丢失一定的流量，在不改变原有的无状态应用属性的情况下，选择的解决办法为B
最终配置如下:
apiVersion: apps/v1
kind: Deployment
metadata:
name: app
spec:
strategy:
type: Recreate
template:
metadata:
annotations:
k8s.aliyun.com/pod-eip-instanceid: eip-XXXXXXXlus72fax
spec:
readinessGates:
- conditionType: "k8s.aliyun.com/eip"
pod由于没有通过NAT请求公网，是EIP和Pod IP（ecs 弹性辅助网卡）直接绑定，因此默认情况下，通过pod ip（vpc内网）:端口可以直接访问到pod暴露的接口，通过eip（公网）:端口也可以访问到，但是由于EIP绑定的是ecs的弹性辅助网卡，因此和ecs共用了一个安全组，ecs是集群node，只开放了集群子网间互通，因此这个问题已经规避
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。