EKS集群中GitLab Runner作业Pod网络通信原理咨询

Kubernetes的Service资源核心作用是把Pod的服务暴露给集群内其他资源、或者集群外部访问，从来不是Pod主动发起对外网络请求的前置条件。只要EKS集群的节点网络、Pod网络配置了正常的出网规则，Pod本身就能直接发起对外连接，和有没有关联Service没有任何关系。

你用的是Kubernetes executor类型的GitLab Runner，作业Pod的网络完全遵循集群本身的网络规则：

• EKS默认使用Amazon VPC CNI插件，创建的作业Pod会直接分配VPC网段内的IP，出网流量完全走VPC本身的路由规则：如果要访问公网托管的GitLab，流量会通过绑定公网IP的节点、或者VPC公网NAT网关出公网；如果是访问私网部署的GitLab，流量直接走VPC内部路由、VPC对等连接或者PrivateLink连通，全程不需要Service做中转。
• 如果你的集群配置了全局出网网关（比如Calico Egress Gateway、服务网格Sidecar出网策略），作业Pod的对外流量直接匹配这些策略转发即可，Runner本身不会做特殊的网络拦截。

拉取代码仓库的逻辑 #

作业Pod启动时，Runner会自动注入初始化容器（init container），容器内预置了git、gitlab-runner-helper等必要二进制。初始化阶段容器会读取Runner注册时保存的凭据、或者作业动态生成的CI_JOB_TOKEN，主动向外部GitLab服务发起HTTPS/SSH请求拉取代码——这个请求是Pod主动向外发起的出向连接，不需要外部主动连入Pod，完全不需要Service支撑。
你只需要保证Pod所在网段到GitLab地址的路由可达，对应安全组、网络ACL放通HTTPS（默认443）、SSH（默认22）端口即可，不需要额外给作业Pod配置网络资源。

作业状态、结果回传GitLab的逻辑 #

整个CI作业执行的全流程，都不是GitLab主动连入作业Pod拉取日志和结果：作业容器内的Runner进程、配套的helper容器会主动维持和GitLab服务端的长连接，实时把作业日志、执行状态、执行结果通过这个出向连接推回GitLab。
作业执行完成后，如果配置了作业产物上传，helper容器也会主动调用GitLab的API，通过出向连接把产物数据上传到GitLab服务端。全程没有任何外部主动入站访问作业Pod的需求，自然不需要给作业Pod绑定Service。

补充：只有当你需要入站访问作业Pod的时候——比如临时进Pod调试、作业内启动了需要对外提供访问的服务，才需要给Pod配置Service、Ingress这类入站暴露资源，普通CI作业的所有网络交互都是Pod主动向外发起的，不需要这类资源。

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