In preparation for production, we need to do two main things:
- Write a Kubernetes deployment spec
- Configure our Akka cluster application
The final configuration file and deployment spec are in the sample application. In this guide we will show snippets. Locations of the samples:
Create a deployment spec in
kubernetes/akka-cluster.yaml. The following configuration uses:
- Application name / Actor system name:
Change these for your application.
- name: appka
- name: management
- name: http
Here are a few things to note:
- We’re using a Kubernetes deployment. Deployments are logical groupings of pods that represent a single service using the same template. They support configurable rolling updates, meaning the cluster will be gradually upgraded, rather than upgrading every node at once and incurring an outage. Be sure to consult Kubernetes Rolling Updates for recommendations.
- We label the pod in the
app: appka. This must match the ActorSystem name so that Akka Bootstrap finds the other nodes in the cluster.
- The image we’re using is
akka-sample-cluster-kubernetes:latest. This corresponds to the name and version of the service in our build. We will discuss how to select an appropriate version number below.
- We’ve only requested minimal CPU to the pods for this service. This is suitable for a local deployment, but you may wish to increase it if you’re deploying to a real deployment. Note that we also haven’t set a CPU limit, this is because it’s recommended that JVMs do not set a CPU limit.
- We’ve configured a liveness probe and readiness probe. These are provided out of the box by Akka Management and are discussed later.
We use a version tag of
latest for the image. Not specifying a tag is the same as using the
latest tag. We could have just specify
akka-sample-cluster-kubernetes, and this would mean the same thing as
For production, the use of the
latest tag is bad practice. For development, it’s convenient and usually fine. We recommend if you’re deploying to production, that you replace this with an actual version number that is updated each time you deploy. In the Building your application section of this guide we will describe how to configure your build to base its version number off the current git commit hash, which is great especially for continuous deployment scenarios as it means a human doesn’t need to be involved in selecting a unique version number. After building the image, you can take the version number generated in that step and update the image referenced in the spec accordingly.