Understanding Kubernetes Workloads

Before you can manually update your applications running in Kubernetes, you need to understand the different types of Kubernetes objects and their collective workloads that require deploying and updating.

At a high level, updating apps in your cluster is done with deployment templates that can be applied with the Kubernetes API or alternatively can be controlled by Kubernetes command line tool, ‘kubectl’.  Here are the Kubernetes objects, each of these has its own YAML definition or manifest.

  • Stateless applications – refers to an application that does not maintain its history or state in a persistent database, but rather all user state is kept with the client.  Examples of these types of applications include: NGINX, and a TomCat application server.
  • Stateful applications – need to store their state information in a persistent storage so that other applications can access it.  Examples are MongoDB and message queues like RabbitMQ.
  • Batch jobs – these are parallel tasks that are finite and that need to run to completion. Examples include video rendering and email processing.
  • Daemons – perform background tasks on their assigned node without the need for human interaction.

Links:

What are Deployments?

Deployments give you fine grain control over how Pods are updated and rolled back.  A deployment runs multiple replicas of your application and replaces any instances that have failed or are unresponsive. In this way, deployments ensure that one or more instances of your application are always available to serve requests to your users.

Deployments use a Pod or deployment template, written in YAML, that contains the specification for its Pods. The Pod specification defines its desired state, and it identifies what applications run inside its containers, which volumes, if any, the Pods it should mount, its labels, and any annotations that have been defined for it.

When a Deployment Pod template is changed, new ReplicaSets are created that will create new Pods one at a time in real-time with zero application downtime. This is what’s referred to as a rolling update.

From Kubernetes Basics Tutorial

Example Deployment Template

Deployment templates are defined in a YAML file. The following snippet is taken from the Kubernetes documentation and it shows an example manifest for deploying NGINX:

apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

The template field contains the following instructions:

  • The Pods are labeled app: nginx
  • Create one container and name it nginx
  • Run the nginx image at version 1.7.9
  • Open port 80 so that the container can send and accept traffic

Links:

Managing Pod Configurations

Depending on how you are working and the types of applications you are deploying, you will want to ensure that the container image and its deployment configuration are decoupled.  This not only ensures that your app is more portable between environments, but in some cases it is necessary to keep your data secure.

Approach

Type of Data

How it's mounted or referred to

Example

Using a manifest's container definition

Non-confidential

Environment variable

Command-line flag

Using ConfigMaps

Non-confidential

Environment variable OR local file

nginx configuration

Using Secrets

Confidential

Environment variable OR local file

Database credentials

Links:

Choose Your Object Management Method

Once the deployment template is defined and you’re ready to do some rolling updates, you will need to choose how you’re going to do those updates. Kubernetes Objects and updates to your application can be managed using one of these three methods:

Method

Definition

Advantages

Imperative commands

These are raw `kubectl` commands.

These are used directly on Live objects in the cluster.  It  saves no history and isn’t very useful on a daily basis with a large team of developers. Generally used for ‘one off’ tasks.  

Imperative object definition

‘kubectl` commands applied to at least one file.

The file generally is generally in YAML format. Allows some rollback and can be stored in source control, but users still need to understand the schema in order to update it.

Declarative object configuration

Applies the ‘kubectl’ to directories of files.

Allows you to work on different object types at the same time.

Links:

Steps for a Manual Update

These are the steps that you’ll need to do, if you want to manually update an app in Kubernetes:

  1. Unit test code in a CI system.
  2. Build an updated Docker image (with a new tag).
  3. Upload the image to a repository.
  4. Update your deployment definition YAMLs for your app: deployment, service and  Kubernetes secret and ingress.
  5. Apply or ‘set image’ to the changes in your Kubernetes cluster.
  6. Scale your deployment appropriately (if necessary).
  7. If all went well, and you don’t have to rollback, clean up and remove the deployment.
  8. If you’re using the declarative method you can check your deployment definitions into Git so that you have a history of it.

Try Weave Cloud 14 days for free

Get up and running in minutes – no credit card required.

Sign Up Now