Kubernetes Basics

Understanding the YAML app manifest

A Kubernetes YAML file or manifest defines the container orchestration bits of your application, including but not limited to:

workloads like pods or deployments
networking related stuff such as services or Ingress
data and storage related things, for example volumes and persistent volumes
other things that you as an appops usually don't need to care about, for example nodes and access control

Let's have a look at a concrete example, so things become clearer. Remember the stock-gen and stock-con microservices from the previous scenario? We define each of these as an app in Kubernetes, consisting of a deployment and a service, like so (source):

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  labels:
    app: stock-con
  name: stock-con
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: stock-con
    spec:
      containers:
      - name: stock-con
        image: quay.io/mhausenblas/stock-con:0.3
        env:
        - name: DOK_STOCKGEN_HOSTNAME
          value: stock-gen
        - name: DOK_STOCKGEN_PORT
          value: "9999"
        ports:
        - containerPort: 9898
          protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: stock-con
  name: stock-con
spec:
  type: ClusterIP
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 9898
  selector:
    app: stock-con

Deploying an app using kubectl apply

Time to actually create something here! Ready? Let's do it :)

Install Kubectl

curl -k -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -k -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
chmod +x ./kubectl
sudo mv ./kubectl /usr/local/bin/kubectl

First we deploy the stock-con app:

kubectl apply -f dok-example-us/stock-con/app.yaml

Next up is the stock-gen app:

kubectl apply -f dok-example-us/stock-gen/app.yaml

Is everything up and running? Let's check:

kubectl get deploy,svc,po

See both deployments and services? All pods show their STATUS as Running? Good, now we're done here. That wasn't too hard, was it now? Note that it make take a few moments before Kubernetes has pulled the images so you might need to execute the kubectl get … command above again until you see that all is deployed and running.

Let's see if we can call the two services:

kubectl run -i -t --rm jumpod --restart=Never --image=quay.io/mhausenblas/jump:v0.1 -- sh

Now you should be in the jumpod, that is inside the cluster, and can curl the services like so:

curl stock-gen:9999/stockdata

… as well as:

curl stock-con:80/average/NYSE:RHT

If you see proper JSON output for both, you may move on, young jedi master!

Don't forget to exit from the jumpod so that you're back on the prompt of the host (you should see a master $ now).

App lifecycle management

OK, so we've deployed our app and can use it from within the cluster. But what about kicking off a new deployment in the general case? Or how about when our app gets really busy, serving 10x the traffic compared to where we started? How about some horizontal scaling then?

Let's first see how we can trigger a new deployment. For certain changes, such as updating spec.template.spec.containers[].image we get a new deployment for free, that is, if you'd change the image from quay.io/mhausenblas/stock-con:0.3 to quay.io/mhausenblas/stock-con:0.4 and kubectl apply … it, a new deployment is triggered. However, not all changes in the resource spec cause a new deployment being rolled out.

Luckily there's a way to tickle the deployment resource spec to trigger a change (and you can use this trick for any resource change trigger)—simply add an annotation, for example:

kubectl patch deployment stock-con -p "{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"date\":\"$(date +'%s')\"}}}}}"

With that out of the way, how about some horizontal scaling? Say we want three identical copies of our stock consumer:

kubectl scale deploy/stock-con --replicas=3

Do we have three pods now?

kubectl get pods -l=app=stock-con

Note that if you want to idle the app manually you can set --replicas=0. This might help with your resource consumption and/or that you stay within quota.

If you want to get rid of the app, you can delete deployments and services with kubectl delete deploy stock-gen and kubectl delete svc stock-gen and the same for the stock-con microservice.

cd <directory>	Change directory
ls	List directory
echo 'contents' > <file>	Write contents to a file
cat <file>	Output contents of file

i	In Command Mode	Change into Insert Mode, you can now insert and edit text in the file
esc	In Insert Mode	Change into Command Mode, you can now execute commands
:wq	In Command Mode	Save and Exit

Welcome!

Congratulations!

You've completed the scenario!

Scenario Rating

Steps