问题背景
去年底信息安全团队进行网络权限治理，要求所有应用实例使用静态IP，公网访问策略与静态IP绑定；之后实例重启时偶现“端口被占用”错误。通过分析总结应用日志，共有以下4种错误类型，实质都是端口被占用。
// Netty框架
Caused by: java.net.BindException: Address already in use
// Jetty
Failed to start jetty server at port 8080, cause: Address already in use
// Embedded Tomcat
Embedded servlet container failed to start. Port 8080 was already in use.
// Tomcat
The Tomcat connector configured to listen on port 8080 failed to start. The port ay already be in use or the connector may be misconfigured. 原因分析
学过计算机网络的同学应该知道，网络连接的建立需要通过调用操作系统内核函数来实现；查询linux的官方文档，确定端口被占用的校验发生在系统调用bind()阶段。
端口被占用原因
TCP/IP连接断开后，进入TIME_WAIT状态，等待2MSL(Maximum Segment Lifetime)时间后才会释放网络资源，在此过程中重新打开相同端口会报：bind: address already in use错误。
为什么需要等待2MSL时间
1.可靠的实现TCP全双工连接终止，正确处理关闭连接的四次握手。
2.确保迷路的数据包在网络中消失，防止上一次连接中的包影响新连接（数据包及应答均被丢弃。
不同操作系统中MSL默认值
Windows: 120s
Linux(centos, ubuntu): 60s
Unix: 30s
为什么治理前未发生问题
在采用动态IP时，实例每次重启都会从IP池中选取一个未被使用的IP，新建socket的IP与之前socket的IP不同，属于不同的连接，因此不会报错。
linux源码分析
由于不能使用动态IP，为了寻找解决方案，在对端口被占用逻辑有了大致了解后，我们进一步研读源代码了解端口被占用的详细判断逻辑。
// 系统调用bind()对应的入口函数是__sys_bind()
// 端口被占用判断逻辑是inet_bind_conflict函数
static bool inet_bind_conflict(const struct sock *sk, struct sock *sk2,
kuid_t sk_uid, bool relax,
bool reuseport_cb_ok, bool reuseport_ok)
{
int bound_dev_if2;
if (sk == sk2)
return false;
bound_dev_if2 = READ_ONCE(sk2->sk_bound_dev_if);
if (!sk->sk_bound_dev_if || !bound_dev_if2 ||
sk->sk_bound_dev_if == bound_dev_if2) {
if (sk->sk_reuse && sk2->sk_reuse &&
sk2->sk_state != TCP_LISTEN) {
if (!relax || (!reuseport_ok && sk->sk_reuseport &&
sk2->sk_reuseport && reuseport_cb_ok &&
(sk2->sk_state == TCP_TIME_WAIT ||
uid_eq(sk_uid, sock_i_uid(sk2)))))
return true;
} else if (!reuseport_ok || !sk->sk_reuseport ||
!sk2->sk_reuseport || !reuseport_cb_ok ||
(sk2->sk_state != TCP_TIME_WAIT &&
!uid_eq(sk_uid, sock_i_uid(sk2)))) {
return true;
}
}
return false;
} 可以看到判断端口占用逻辑用到如下字段：
// 端口被占用判断字段
sk_bound_dev_if --> 网卡编号
sk_reuse --> 套接字复用
sk_reuseport --> 端口复用
sk_state --> 当前状态listen还是time_wait
sk_uid socket --> 所属用户ID
reuseport_cb_ok --> 内核是否支持端口复用 这些字段中网卡编号、用户ID、内核是否支持端口复用均无法修改，能够调整的参数是端口复用和超时时间。
解决方案
鉴于公司所有应用都绑定了静态IP，应用重启时创建的socket与上一个socket必定是同一个应用，此时开启端口复用，不会出现超时报文被其他应用接收的情况，因此开启端口复用（sk_reuseport）是比较合理解决方式。
端口复用开启方式
开启端口复用主要有两种方式：
1. 应用级别：每个业务项目在启动时自行开启端口复用，由于需要修改业务代码，并且不同框架实现方式不同，推广难度大
2. 操作系统层次：直接修改系统内核的net.ipv4.tcp_tw_reuse=1
其中第2种方式对用户无感，便于集中处理，因此我们对第2种方式进行验证。
Node与Pod系统参数相互隔离
在我们研究如何修改tcp_tw_reuse时，发现Node节点的端口复用开关是开启状态，但是运行在上面的Pod中的端口复用开关却是关闭的，而应用容器使用的端口复用状态是Pod中的值，此时问题变成了如何开启pod中的端口复用开关。
Node上的端口复用开启
Pod中的端口复用关闭
开启Pod中的端口复用
默认情况Pod是无法修改内核相关配置的，经过调研得知Pod需要获取系统级权限(securityContext.privileged=true)才能修改内核参数，但是次权限太大存在安全风险，如果直接在应用容器开通此权限可能影响宿主机的稳定性；最终我们决定增加一个init容器，当系统参数修改成功后再退出，这样既能有足够权限修改内核参数，又不扩大业务容器的权限。测试实例如下：
# 增加一个busybox的init容器，修改完端口复用开关后退出
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-deployment
spec:
replicas: 2
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-container
image: nginx
initContainers:
- name: sysctl-modifier
image: busybox
securityContext:
privileged: true
command: ["sysctl -w net.ipv4.tcp_tw_reuse=1 && exit"] 使用kubectl部署yaml文件之后，使用kubectl exec -it进入Pod，可以看到pod中的端口被占用功能已经开启。
参考文档
linux源码 https://github.com/torvalds/linux
linux man手册：https://www.man7.org/linux/man-pages/man2/bind.2.html
作者介绍
Randy，现任技术架构资深专家
来源-微信公众号:拍码场
出处:https://mp.weixin.qq.com/s/n8Bf0KBGIpVcr9VebcESnA