Docker Compose如何创建容器网络别名？K8s中Nginx如何复用该方案

First, let's break down how Docker Compose handles those network aliases without touching /etc/hosts:

Docker Compose's Mechanism #

When you spin up services with docker-compose up, Compose automatically creates a custom bridge network for your project (unless you specify otherwise). Unlike Docker's default bridge network, custom networks use Docker's built-in embedded DNS server. Here's what happens:

• Each service defined in your docker-compose.yml gets a DNS entry matching its service name. So if you have a service named backend, any container in the same network can resolve backend to the IP of the backend container(s).
• If you explicitly set aliases in the service configuration (e.g., aliases: ["api", "backend-service"]), those additional names are also registered in the DNS server for that container.
• All DNS resolution happens internally within the network—no need to modify /etc/hosts at all. Containers just query the Docker DNS server (usually at 127.0.0.11 inside the container) to resolve these aliases.

Replicating This in Kubernetes for Nginx #

Kubernetes has its own robust DNS system (CoreDNS is the default these days) that works similarly to Docker's embedded DNS. The key is to leverage Kubernetes Services and DNS resolution instead of manually updating /etc/hosts. Here's how to make this work for your Nginx container:

1. Use Kubernetes Service Names Directly in Nginx Config

Kubernetes Services act as stable endpoints for your pods. Every Service gets a DNS record that resolves to its cluster IP. Here's what to do:

• Create a ConfigMap that holds your Nginx configuration. Instead of hardcoding IPs, use the Service name as the target in proxy_pass. For example:

  server {
    listen 80;
    location /api/ {
      proxy_pass http://my-backend-service; # Works for services in the same namespace
      # For cross-namespace targets: proxy_pass http://my-backend-service.my-other-namespace.svc.cluster.local;
    }
  }
  

• Mount this ConfigMap into your Nginx pod so it uses the config file. When Nginx tries to connect to my-backend-service, Kubernetes' DNS will resolve it to the Service's cluster IP automatically—even if the underlying pods change or scale.

2. Dynamic Config Generation (If You Need Flexibility)

If you need to inject dynamic values into your Nginx config (though DNS resolution often makes this unnecessary), you can use an init container with envsubst to generate the config from a template:

• Create a ConfigMap with an Nginx template that uses placeholders, like:

  server {
    listen 80;
    location /api/ {
      proxy_pass http://${BACKEND_SERVICE_NAME};
    }
  }
  

• In your pod spec, add an init container that runs envsubst to replace the placeholders with values from environment variables (which can come from ConfigMaps or Secrets):

  initContainers:
  - name: config-generator
    image: alpine:latest
    command: ["/bin/sh", "-c"]
    args:
    - envsubst < /template/nginx.conf.template > /nginx-config/nginx.conf;
    volumeMounts:
    - name: nginx-template
      mountPath: /template
    - name: nginx-config
      mountPath: /nginx-config
  volumes:
  - name: nginx-template
    configMap:
      name: nginx-template-configmap
  - name: nginx-config
    emptyDir: {}
  

• Then mount the generated config from the emptyDir volume into your Nginx container.

3. Avoid Manual /etc/hosts Updates

Unlike Docker Compose, Kubernetes doesn't automatically populate /etc/hosts with Service names (though it does add some cluster-related entries). Manually updating /etc/hosts is not recommended because pods are ephemeral—if a pod restarts, those changes are lost. DNS resolution is the native, scalable way to handle service discovery in Kubernetes, just like in Docker Compose.

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