This is a step in Getting an API running in Kubernetes, and you should first have created an app to be deployed as described in Building your App ready for Kubernetes deployment, you have a cluster up and running as described in Getting cockroachDB running with Kubernetes and are using the Google Cloud console shell with the kubectl CLI.

I recommend that you save your commands in various scripts so you can repeat them or modify them later.

Deploying the demo app

A Kubernetes deployment is kind of a “wish list”. It states that you’d like an app to be run, with various parameteres and instances created, but not how or where to do it. Kubernetes takes care of this by creating and managing “pods” in which the app runs (actually multiple apps can run in a pod, but our example only has one). The principle of this approach is that failures can be recovered from and automatically run on the best available node on your Kubernetes cluster without your involvement.

The deployment covers this part of the process.


Namespaces

In Kubernetes, you can keep subjects delineated by assigning them to namespaces. This example will stick to the default namespace, so you can see how deployments interact with other resources already running on the same cluster.

Deploying

This references the image created in Building your App ready for Kubernetes deployment which has a copy in the Google Container Registry.

  • replicas=2 means run 2 instances of it. Kubernetes will create a pod for each one, and decide where and how to run it.
  • labels=”run=playback-app” will allow this deployment to be found and referenced by a service in a later step.

deploy-server.sh

# deploy the server back end
kubectl run playback --replicas=2 --image=gcr.io/fid-sql/playback --port=8080 --labels="run=playback-app"

Check the deployment

kubectl get deploy
NAME                                        DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
playback                                    2         2         2            2           8m

Kubernetes spins up 2 pods for you, 1 for each replica

kubectl get pods 
playback-cb6dd9dfb-l2qrq                                     1/1       Running   0          4m
playback-cb6dd9dfb-tmmrn                                     1/1       Running   0          4m

Check the logs, using the pod names

kubectl logs playback-cb6dd9dfb-l2qrq
> playback@1.0.0 start /usr/src/kube
> node index.js
v4
listening on:0.0.0.0:8080

Next step

The app is deployed, it’s running – if you delete a pod, Kubernetes will start another – this is how it “self heals”. However it’s running internally on the cluster for now – it’s not possible to talk to the app yet. The next step is to create a Service to communicate with the pods. See Getting an API running in Kubernetes for how.

Why not join our forum, follow the blog or follow me on Twitter to ensure you get updates when they are available.