EXPOSE and containerPort fields serve documentation and integration purposes but do not enforce network policies; actual port exposure depends on container runtime and service configurations.

Why This Matters

In production, misunderstanding these directives leads to misconfigured services, security gaps, and debugging headaches. While they don’t “open” ports themselves, they inform tooling and humans about intended network behavior.

Actionable Workflow

1. Define ports in Dockerfile: Use EXPOSE to document the port the app intends to listen on.

   EXPOSE 8080  
   

2. Specify in Kubernetes Pod spec: Use containerPort to align with the Dockerfile and document the port.

   containers:  
   - name: app  
     image: myapp:latest  
     ports:  
       - containerPort: 8080  
   

3. Create a Kubernetes Service: This actually exposes the port externally.

   apiVersion: v1  
   kind: Service  
   metadata:  
     name: myapp-service  
   spec:  
     selector:  
       app: myapp  
     ports:  
       - protocol: TCP  
         port: 80  
         targetPort: 8080  
   

4. Validate with kubectl describe:

   kubectl describe pod myapp-pod | grep -i port  
   kubectl describe service myapp-service  
   

Policy Example

Enforce documentation consistency in CI/CD pipelines:

# Lint Dockerfile for missing EXPOSE  
grep -q "EXPOSE" Dockerfile || { echo "EXPOSE missing"; exit 1; }  

Tooling

• Docker: docker inspect <container> shows exposed ports from Dockerfile.
• Kubernetes: kubectl get endpoints <service> verifies traffic routing.
• Network debugging: Use nc or curl to test connectivity.

Tradeoffs

• Documentation vs. enforcement: Relying solely on EXPOSE/containerPort without service definitions leaves ports inaccessible externally.
• Security: Misdocumented ports can lead to unintended exposure if automation tools auto-publish based on these fields.

Troubleshooting

• Port not accessible:
  • Check if a Service or Ingress is configured to expose the port.
  • Verify the app actually listens on the port (e.g., lsof -i :8080 inside the container).
• Random port assignments:
  • Docker’s -P flag publishes all exposed ports but maps them to ephemeral host ports. Use -p for explicit mappings.
• Kubernetes Service issues:
  • Ensure targetPort matches containerPort.
  • Check endpoint selectors for correct pod labeling.

Conclusion

EXPOSE and containerPort are critical for documentation and tooling but are not network enforcement mechanisms. Always pair them with explicit Service or Ingress definitions to control actual traffic flow.

Source thread: Is it true that EXPOSE in Dockerfile and containerPort in Kubernetes are just for documentation?