在已配置Ingress的K8s环境中，Angular(ClusterIP Service)直接调用Golang(ClusterIP Service)API的可行性及性能差异咨询

Absolutely, this approach is totally feasible—let’s break down your questions one by one to give you a clear picture:

Yes, this is a standard and recommended way for inter-service communication within a Kubernetes cluster. Here’s why it works:

• Kubernetes automatically creates DNS records for every ClusterIP service. The default format is <service-name>.<namespace>.svc.cluster.local. If your frontend (forms-service) and backend (fiber-service) are in the same namespace, you can even use the shorthand <service-name>:<port> (like fiber-service:3000/api/v1)—the cluster’s DNS resolver will automatically resolve this to the correct ClusterIP (10.105.244.88 in your case).
• Your existing testUrl method only needs a small adjustment: make sure to include the HTTP protocol prefix, e.g., http://fiber-service:3000/api/v1, since the Angular HttpClient requires a full URL to make requests.

No, the Ingress will not interfere at all. Here’s the key distinction:

• The Ingress resource and its associated Nginx Ingress Controller only handle traffic coming from outside the cluster (or traffic explicitly routed through the Ingress rules).
• Your internal service-to-service call uses Kubernetes’ cluster network directly. It bypasses the Ingress entirely—there’s no path through the Nginx controller or any Ingress rules for this traffic. The Ingress configuration you shared only governs how external requests to lite.com are routed, so it won’t affect your internal service communication.

Calling directly via the ClusterIP service will outperform going through the Ingress by a noticeable margin. Here’s the breakdown of the performance differences:

1. Fewer network hops: When using the Ingress, requests travel from your client → Ingress Controller Pod → backend service → backend Pod. With internal service calls, the path is frontend Pod → backend service → backend Pod (or even directly between Pods if they’re on the same node). This cuts out an entire layer of forwarding.
2. Lower latency: Kubernetes’ cluster network is optimized for low-latency internal communication. Skipping the Ingress Controller removes the overhead of reverse proxying, path rewriting, and any additional processing the Ingress might perform (like SSL termination, rate limiting, or header manipulation).
3. Reduced resource usage: The Ingress Controller doesn’t have to process these internal requests, freeing up its resources for external traffic.

A quick note: If your frontend and backend Pods are scheduled on the same node, the internal call can even use the node’s local network, further reducing latency compared to cross-node traffic (though even cross-node internal calls are faster than going through Ingress).

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