Deploying Restate services
You can deploy your Restate service on any standalone machine. If you want to spread load across multiple machines, it is best to put your services behind a load balancer (L4/L7).
If you want to run your service behind a load balancer, please make sure that you configure the load balancer to allow HTTP2 traffic.
Deploying Restate services to Kubernetes
Service deployments can be deployed like any Kubernetes service; a Deployment of more than one replica is generally appropriate, and a Service is used to provide a stable DNS name and IP for the pods. If your services are running over HTTP2 (the default), each Restate partition will generally have only one TCP connection to a single destination pod. However, because there are many partitions (by default 24, typically more in a larger cluster) your pods should get a reasonably even distribution of traffic even without a L7 load balancing solution (Cilium, Istio etc).
RestateDeployment CRD
The Restate operator allows for the use of a RestateDeployment
CRD to deploy your services.
The CRD is an extension of a native Deployment
object, but will manage registration and versioning for you, by keeping old
ReplicaSets around with an associated Service object so that in-flight invocations can drain against the old code versions. You can deploy a CRD as follows:
apiVersion: restate.dev/v1beta1kind: RestateDeploymentmetadata:name: servicespec:replicas: 1restate:register:# set this if you want to register against your RestateCluster named 'restate'# alternatively, you can set a url or a Service reference to register againstcluster: restateselector:matchLabels:app: servicetemplate:metadata:labels:app: servicespec:containers:- name: serviceimage: path.to/yourrepo:yourtagenv:- name: PORTvalue: "9080"ports:- containerPort: 9080name: restate
Kubernetes Deployment and Service definition
If you want to deploy without the operator, a simple deployment setup with a single pod in Kubernetes is as follows:
apiVersion: apps/v1kind: Deploymentmetadata:name: servicespec:replicas: 1selector:matchLabels:app: servicetemplate:metadata:labels:app: servicespec:containers:- name: serviceimage: path.to/yourrepo:yourtagenv:- name: PORTvalue: "9080"ports:- containerPort: 9080name: restate---apiVersion: v1kind: Servicemetadata:name: servicespec:selector:app: serviceports:- port: 9080name: restatetype: ClusterIP
You would then register the service at http://<service>.<namespace>:9080
. Note however that this setup will not account for keeping around old code versions, so updating your code can break in-flight invocations.
Knative
Restate supports Knative services. Knative allows scaling to zero when there are no in-flight invocations and automatically configures an L7 load balancer. There are no special requirements to deploy a service deployment container with Knative:
$ kn service create service-name --port h2c:9080 --image path.to/yourrepo:yourtag
Or using the YAML manifest:
apiVersion: serving.knative.dev/v1kind: Servicemetadata:name: service-namespec:template:spec:containers:- image: path.to/yourrepo:yourtagports:- name: h2ccontainerPort: 9080
The service will be accessible at http://<service-name>.<namespace>
but to handle versioning, it is preferable to register the new revision url like http://<service-name>-0001.<namespace>
as part of your deployment workflow.
By default Knative exposes the service through the Ingress. This is not required by Restate, and you can disable this behavior adding the argument --cluster-local
to the aforementioned creation command.