GKE Ingress

To expose your application’s gRPC or HTTPS endpoints publicly to the internet you can use the GKE Ingress Controller new tab with a Kubernetes Ingress new tab created by the Akka Operator. This is useful when external services, or clients beyond the GKE cluster need to consume the gRPC or HTTPS endpoints. For the Akka Operator to manage ingress into your HTTP and GRPC endpoints on GKE via the cloud-native controllers, you need to setup a VPC-native cluster. Please find instructions at https://cloud.google.com/kubernetes-engine/docs/how-to/alias-ips new tab to setup a VPC-native cluster. You can read about the benefits of a VPC-native cluster at https://cloud.google.com/kubernetes-engine/docs/concepts/alias-ips new tab.

Container native load balancing

The Akka Operator depends on container-native load balancing new tab for setting up ingress on GKE. Container-native load balancing allows load balancers to target Kubernetes Pods directly and to evenly distribute traffic to Pods. The Akka Management port is used for the load balancer health check. If you override the readiness probe to a path on your HTTP port, this will also be used for the load balancer health check.

TLS certificate

  1. Internet traffic

    You need a TLS certificate for the internet facing load balancer. For development and test you can import a self-signed certificate, which can be created with for example:

    openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout dummy-key.pem -out dummy-cert.pem -subj "/CN=dummy/O=dummy"

    Create a secret for the certificate:

    kubectl create secret tls my-ingress-secret --cert dummy-cert.pem  --key dummy-key.pem

    This secret will be referenced from the Akka Microservice (see example below).

  2. Internal traffic

    The traffic from the intern-facing LoadBalancer to your application may or may not require TLS. On the httpIngress you don’t need an SSL certificate and private key. When serving gRPC, though, you need a certificate for the traffic from the load balancer to your pod as GKE load balancer for HTTP/2 only works over SSL. Therefore, Akka gRPC needs to be configured with a certificate. The certificate between the load balancer and the pod can be any self-signed certificate as no validation is done. The How to enable TLS for gRPC section will help you set up your Akka HTTP server to serve TLS traffic.

Enable an ingress

Add the grpcIngress or httpIngress section to the deployment descriptor with the class attribute set to gce:

apiVersion: akka.lightbend.com/v1
kind: AkkaMicroservice
  name: shopping-cart-service
  namespace: "shopping"
  image: <docker-image>
    enabled: true
    certificate: "my-ingress-secret" (1)
    class: "gce"
    enabled: true
    certificate: "my-ingress-secret" (1)
    class: "gce"
1 See the section [TLS Certificate] above.

When the deployment descriptor has been applied the Akka Operator will create:

  • an Ingress with the appropriate GKE annotations

  • a ClusterIP service

  • a BackendConfig to configure a health check to match the readiness check

The GKE Ingress instance takes a few minutes to be ready. Then, even when the ingress is listed as OK it will take a few more minutes to be HEALTHY and usable.

You can retrieve the public address with:

kubectl get ingress shopping-order-service-grpc-ingress --namespace=shopping

To access the public endpoint with grpcurl you use the public address from above, with port 443:

grpcurl -insecure -d '{"cartId":"cart3", "itemId":"hoodie", "quantity":2}' <ingress ip>:443 shoppingcart.ShoppingCartService.AddItem

You have to use the -insecure flag if the certificate is self-signed.