In my last blog post, I spent time showing you how to build an Azure Kubernetes Service cluster. This time we'll go over some kubernetes specific terminology so that as we continue to grow we know exactly what these terms mean.

Terminology Overview

Let's get some of the terminologies out of the way. Here are a few key things from the Kubernetes core concepts for Azure Kubernetes Service (AKS) Documentation.

Pods

Kubernetes uses pods to run an instance of your application. A pod represents a single instance of your application. Pods typically have a 1:1 mapping with a container, although there are advanced scenarios where a pod may contain multiple containers. These multi-container pods are scheduled together on the same node, and allow containers to share related resources.

Deployments and YAML manifests

A deployment represents one or more identical pods, managed by the Kubernetes Deployment Controller. A deployment defines the number of replicas (pods) to create, and the Kubernetes Scheduler ensures that if pods or nodes encounter problems, additional pods are scheduled on healthy nodes.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-app
spec:
  selector:
      matchLabels:
        app: demo-app
  replicas: 1
  template:
      metadata:
        labels:
            app: demo-app
      spec:
        containers:
        - name: demo-app
          image:  ACRHERE.azurecr.io/demo-app:v1
          imagePullPolicy: Always
          readinessProbe:
            httpGet:
              port: 8000
              path: /
          livenessProbe:
            httpGet:
              port: 8000
              path: /
          resources:
            requests:
              memory: "128Mi"
              cpu: "100m"
            limits:
              memory: "256Mi"
              cpu: "500m"

StatefulSets and DaemonSets

The Deployment Controller uses the Kubernetes Scheduler to run a given number of replicas on any available node with available resources. This approach of using deployments may be sufficient for stateless applications, but not for applications that require a persistent naming convention or storage. For applications that require a replica to exist on each node, or selected nodes, within a cluster, the Deployment Controller doesn't look at how replicas are distributed across the nodes.

There are two Kubernetes resources that let you manage these types of applications:

• StatefulSets - Maintain the state of applications beyond an individual pod lifecycle, such as storage.
• DaemonSets - Ensure a running instance on each node, early in the Kubernetes bootstrap process.

Helm

A common approach to managing applications in Kubernetes is with Helm. You can build and use existing public Helm charts that contain a packaged version of application code and Kubernetes YAML manifests to deploy resources. These Helm charts can be stored locally, or often in a remote repository, such as an Azure Container Registry Helm chart repo.

To use Helm, a server component called Tiller is installed in your Kubernetes cluster. The Tiller manages the installation of charts within the cluster. The Helm client itself is installed locally on your computer, or can be used within the Azure Cloud Shell. You can search for or create Helm charts with the client, and then install them to your Kubernetes cluster.

For more information, see Install applications with Helm in Azure Kubernetes Service (AKS).

Video

Here's a video featuring Microsoft Distinguished Engineer Brendan Burns on kubernetes terminology:

Next?

These are just a few bits from the Azure Kubernetes Service documentation. Take a bigger bite of the docs and start building something right away.

If you'd like to try out the Azure Kubernetes Service, check out the free $200 in credit and 12 months of free Azure services.