How does gRPC know the service IP address of a microservice?

gRPC is a high-performance, open source remote procedure call framework for building microservices in distributed systems. When using gRPC, a common question is how to let the client know the service IP address of the microservice. First, PHP editor Shinichi explained how gRPC works. It uses Protocol Buffers as the interface definition language and HTTP/2 as the transport protocol. Then, the editor introduced two commonly used methods to solve the problem of service IP addresses: static configuration and service discovery. Static configuration hardcodes the IP address of the service in the client code. This method is simple and straightforward, but requires manual update of the configuration. Service discovery is to dynamically obtain the IP address of the service by using service registration and discovery tools, such as Consul or Etcd. This approach is more flexible and automated, but requires additional deployment and maintenance. No matter which method you choose, you need to implement corresponding logic in the client code to obtain the IP address of the service to ensure the normal operation of gRPC.

Question content

I started with the microservices demo of Google Cloud Platform. I'm curious how grpc stubs work when the service is deployed in a container.

As far as I understand, the container of a specific service is addressed by the service IP specified in the yaml configuration file. So does the service's grpc server have to listen on the service ip? But I came across the following code snippet:

l, err := net.Listen("tcp", fmt.Sprintf(":%s", port))
if err != nil {
    log.Fatal(err)
}

I want to know how the server listens to an address without an IP?

Solution

:{port} is not an "address without an IP".

The documentation for

Listen includes "If the host in the address parameter is empty or a literal unspecified IP address, Listen listens on all available unicast and anycast IP addresses on the local system."

So, in this case, without a host address, the effective address would be 0.0.0.0, which corresponds to all interfaces. By corollary, a common mistake people make when using containers is to bind their code to localhost (127.0.0.1), making that code inaccessible from outside the container.

Using 0.0.0.0 is a common (good) practice, especially when using containers, as it effectively delegates address binding to the container runtime.

Thus, your application runs on {port} on all interfaces within the container. The container runtime then binds one or more of these interfaces to the host's interface and your eg. The client code connects to the host's IP address.

When your containers are managed by Kubernetes, Kubernetes assigns IP addresses to the containers running your application, and these containers are typically exposed to other services using a Kubernetes service resource, which not only has an IP address, but also Cluster DNS .

1. Kubernetes YAML may specify service DNS.
2. Kubernetes resolves DNS name requests to the selected container (IP and port)
3. The container runtime routes incoming requests on the host port to the container port
4. Your gRPC server will accept traffic from the container runtime on the {port} interface that you have defined as net.Listen.

The above is the detailed content of How does gRPC know the service IP address of a microservice?. For more information, please follow other related articles on the PHP Chinese website!