仅在AWS EKS集群中服务无法启动Kestrel的问题排查求助

从你的EKS日志里的System.Net.Sockets.SocketException (13): Permission denied错误，核心原因很明确：你的非root用户lirantal没有权限绑定80端口——Linux系统默认限制非root用户不能监听1024以下的特权端口。

为什么本地集群没问题？因为Docker Desktop（尤其是WSL 2集成环境）默认会放宽这个端口权限限制，或者通过宿主机的端口转发绕过了容器内的特权端口检查，所以本地运行时不会触发这个错误；而AWS EKS的节点是标准的Linux环境，严格遵循系统安全规则，所以这个问题只在EKS中显现。

下面是几个可行的解决方案，按推荐优先级排序：

方案1：改用非特权端口（最安全推荐） #

让Kestrel监听1024以上的端口（比如8080），同时调整Deployment配置匹配这个端口：

1. 修改Deployment的环境变量，指定Kestrel的监听地址：

   env:
   - name: "ASPNETCORE_ENVIRONMENT"
     value: "KubernetesDevelopment"
   - name: "ASPNETCORE_URLS"
     value: "http://+:8080"
   

2. 更新Deployment里的容器端口和探针配置，把所有port: 80改成8080：

   livenessProbe:
     httpGet:
       path: /health/live
       port: 8080
   readinessProbe:
     httpGet:
       path: /health/ready
       port: 8080
   ports:
   - containerPort: 8080
   

3. 重新部署：

   kubectl apply -f deployment.yml
   

这个方案不需要额外的权限，完全符合容器安全最佳实践，是最推荐的做法。

方案2：给容器添加绑定特权端口的能力 #

如果业务必须使用80端口，可以通过给容器添加CAP_NET_BIND_SERVICE Linux能力，允许非root用户绑定特权端口：

在Deployment的容器spec里添加securityContext配置：

containers:
- name: xxxxxxxx
  image: yyyyyy.dkr.ecr.qqqqq.amazonaws.com/xxxxxxxx:2676
  securityContext:
    capabilities:
      add: ["NET_BIND_SERVICE"]
  # 其余配置保持不变...

重新部署后，lirantal用户就能正常绑定80端口了。这个方案比直接用root用户安全，但还是会给容器额外的系统能力，按需选择。

方案3：以root用户运行容器（不推荐） #

虽然可以修改Dockerfile去掉创建用户的步骤，直接以root用户运行，但这会降低容器的安全性，容易被恶意利用，不建议在生产环境使用。

验证修复 #

部署完成后，用以下命令检查Pod状态和日志：

kubectl get pods
kubectl logs <pod-name>

如果看到Now listening on: http://[::]:8080（方案1）或http://[::]:80（方案2）的日志，说明Kestrel启动成功，问题解决。

内容的提问来源于stack exchange，提问作者Daan