Kubernetes集群内服务间通信：是否应采用HTTPS？

Let’s tackle your questions one by one, with practical recommendations based on real-world Kubernetes deployments:

1. Should I use external HTTPS or internal HTTP for inter-service calls? #

Always prefer internal HTTP (or internal HTTPS if needed) via the cluster DNS name like http://serviceb/api/user/1 instead of routing through your external Ingress. Here’s why:

• Performance & latency: Skipping the external Ingress cuts out extra network hops, TLS termination overhead, and unnecessary checks (like WAF or rate limiting) that are meant for external traffic.
• Simplicity: You avoid dealing with external DNS resolution, public IP dependencies, or your Ingress controller becoming a bottleneck for internal traffic.
• Cost: Cloud providers often charge for external egress traffic—routing internal calls externally could add avoidable expenses.

That said, if strict compliance rules (like PCI-DSS) require encryption for all data in transit—even within the cluster—you can set up internal TLS. Tools like cert-manager can issue short-lived, cluster-internal certificates for your services, letting you use https://serviceb/api/user/1 without relying on your public TLS cert.

2. Is internal Kubernetes traffic "safe" without encryption? #

Kubernetes pod networks are private by default—traffic between pods stays within the cluster’s isolated internal network, and in cloud-managed clusters like GKE, this network is separated from other tenants. But "safe" depends on your data:

• Low risk for non-sensitive data: If you’re passing public, non-confidential info (like product listings), unencrypted internal HTTP is widely accepted in production.
• High risk for sensitive data: If you’re sending user credentials, PII, or payment data, internal traffic can still be intercepted if an attacker gains access to a malicious pod in your cluster. For this scenario, encrypting internal traffic with TLS is non-negotiable.

Think of it like a private office building—most people can’t get in, but if someone sneaks in, they could listen in on conversations. Encryption adds a locked room for your sensitive talks.

3. How to handle internal-only endpoints without exposing them externally? #

This is a common use case, and there are two reliable ways to keep internal endpoints hidden:

Option 1: Split services and ports #

• Configure your Service B deployment to expose two ports: one for external-facing /api endpoints, another for internal-only /internal endpoints.
• Create two Kubernetes Services:
  • A ClusterIP Service that only targets the internal port. This service is only accessible within the cluster, so Service A can call http://serviceb-internal/internal/info/abc.
  • A NodePort/LoadBalancer/Ingress-linked Service that targets the external port. Connect this to your GCE Ingress, so external users can only reach /api routes.

Option 2: Use Network Policies to restrict access #

• If you want to keep a single Service for Service B, use Kubernetes Network Policies to block external traffic to /internal endpoints:
  • Define a policy that allows traffic to the /internal path only from Service A’s pod labels or namespace.
  • Ensure your GCE Ingress only routes traffic to /api—even if someone tries to hit /internal via the external URL, the Network Policy will drop the request.

This way, your internal endpoints stay completely inaccessible from outside the cluster, while remaining usable by authorized internal services.

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