[Kubernetes] – P.2 – Deploying First App

Kubernetes Deployments

A Deployment is responsible for creating and updating instances of your application

Once you have a running Kubernetes cluster, you can deploy your containerized applications on top of it. To do so, you create a Kubernetes Deployment configuration. The Deployment instructs Kubernetes how to create and update instances of your application. Once you’ve created a Deployment, the Kubernetes master schedules mentioned application instances onto individual Nodes in the cluster.


Once the application instances are created, a Kubernetes Deployment Controller continuously monitors those instances. If the Node hosting an instance goes down or is deleted, the Deployment controller replaces the instance with an instance on another Node in the cluster. This provides a self-healing mechanism to address machine failure or maintenance.

In a pre-orchestration world, installation scripts would often be used to start applications, but they did not allow recovery from machine failure. By both creating your application instances and keeping them running across Nodes, Kubernetes Deployments provide a fundamentally different approach to application management.

Preparation for deployment

Make sure kubectl installed on your system by:

kubectl version

Run this command to view the nodes in the cluster

kubectl get nodes

Deploy an app

Use command run to create a new deployment. We need to provide the deployment name and app image location (include the full repository URL for images hosted outside Docker hub). We want to run the app on a specific port so we add the --port parameter:

kubectl run kubernetes-bootcamp --image=gcr.io/google-samples/kubernetes-bootcamp:v1 --port=8080

Great! You just deployed your first application by creating a deployment. This performed a few things for you:

  • searched for a suitable node where an instance of the application could be run (we have only 1 available node)
  • scheduled the application to run on that Node
  • configured the cluster to reschedule the instance on a new Node when needed

To list your deployments use the get deployments command

kubectl get deployments

View the app

Pods that are running inside Kubernetes are running on a private, isolated network. By default, they are visible from other pods and services within the same kubernetes cluster, but not outside that network. When we use kubectl, we’re interacting through an API endpoint to communicate with our application.

The kubectl command can create a proxy that will forward communications into the cluster-wide, private network. The proxy can be terminated by pressing control-C and won’t show any output while its running.

Open a second terminal window to run the proxy

kubectl proxy
Starting to serve on (you will see this line)

The proxy enables direct access to the API from these terminals.

You can see all those APIs hosted through the proxy endpoint, now available at through http://localhost:8001. For example, we can query the version directly through the API using the curl command:

curl http://localhost:8001/version

The API server will automatically create an endpoint for each pod, based on the pod name, that is also accessible through the proxy.

First we need to get the Pod name, and we’ll store in the environment variable POD_NAME:

export POD_NAME=$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}{{end}}')
echo Name of the Pod: $POD_NAME

then you will see something like

Name of the Pod: kubernetes-bootcamp-6bf84cb898-xs5jj

Now we can make an HTTP request to the application running in that pod:

curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME/proxy/

The URL is the route to the API of the Pod.

Leave a Reply

Your email address will not be published. Required fields are marked *