Reader small image

You're reading from  Getting Started with Kubernetes, Second Edition - Second Edition

Product typeBook
Published inMay 2017
PublisherPackt
ISBN-139781787283367
Edition2nd Edition
Right arrow
Author (1)
Jonathan Baier
Jonathan Baier
author image
Jonathan Baier

Jonathan Baier is an emerging technology leader living in Brooklyn, New York. He has had a passion for technology since an early age. When he was 14 years old, he was so interested in the family computer (an IBM PCjr) that he pored over the several hundred pages of BASIC and DOS manuals. Then, he taught himself to code a very poorly-written version of Tic-Tac-Toe. During his teenage years, he started a computer support business. Throughout his life, he has dabbled in entrepreneurship. He currently works as Senior Vice President of Cloud Engineering and Operations for Moody's corporation in New York.
Read more about Jonathan Baier

Right arrow

Chapter 5. Deployments, Jobs, and DaemonSets

This chapter will cover the various types of workloads that Kubernetes supports. We will cover Deployments for applications that are regularly updated and long running. We will also revisit the topics of application updates and gradual rollouts using Deployments. In addition, we will look at Jobs used for short-running tasks. Finally, we will look at DaemonSets, which allow programs to be run on every node in our Kubernetes cluster.

This chapter will discuss the following:

  • Deployments
  • Application scaling with deployments
  • Application updates with deployments
  • Jobs
  • DaemonSets

Deployments


In the previous chapter, we explored some of the core concepts for application updates using the old rolling-update method. Starting with version 1.2, Kubernetes added the Deployment construct, which improves on the basic mechanisms of rolling-update and Replication Controllers. As the name suggests, it gives us a finer control of the code deployment itself. Deployments allow us to pause and resume application rollouts. Additionally, it keeps a history of past deployments and allows the user to easily rollback to previous versions.

In the following, listing 5-1, we can see that the definition is very similar to a Replication Controller. The main difference is that we now have an ability to make changes and updates to the deployment objects and let Kubernetes manage updating the underlying pods and replicas for us:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: node-js-deploy
labels:
    name: node-js-deploy
spec:
    replicas: 1
   template:
     metadata:
 ...

Jobs


Deployments and Replication Controllers are a great way to ensure long running applications are always up and able to tolerate a wide array of infrastructure failures. However, there are some use cases this does not address—specifically short running, run once, tasks as well as regularly scheduled tasks. In both cases, we need the tasks to run until completion, but then terminate and start again at the next scheduled interval.

To address this type of workload, Kubernetes has added a Batch API, which includes the Job type. This type will create 1 to n pods and ensure that they all run to completion with a successful exit. Based on restartPolicy, we can either allow pods to simply fail without retry (restartPolicy: Never) or retry when a pods exits without successful completion (restartPolicy: OnFailure). In this example, we will use the latter technique:

apiVersion: batch/v1
kind: Job
metadata:
  name: long-task
spec:
  template:
    metadata:
      name: long-task
    spec:
      containers...

DaemonSets


While Replication Controllers and Deployments are great at making sure that a specific number of application instances are running, they do so in the context of the best fit. This means that the scheduler looks for nodes that meet resource requirements (available CPU, particular storage volumes, and so on) and tries to spread across the nodes and zones.

This works well for creating highly available and fault tolerant applications, but what about cases where we need an agent to run on every single node in the cluster? While the default spread does attempt to use different nodes, it does not guarantee that every node will have a replica and, indeed, will only fill a number of nodes equivalent to the quantity specified in the RC or Deployment specification.

To ease this burden, Kubernetes introduced DaemonSet, which simply defines a pod to run on every single node in the cluster or a defined subset of those nodes. This can be very useful for a number of production–related activities...

Node selection


As mentioned previously, we can schedule DaemonSets to run on a subset of nodes as well. This can be achieved using something called nodeSelectors. These allow us to constrain the nodes a pods runs on, by looking for specific labels and metadata. They simply match key-value pairs on the labels for each node. We can add our own labels or use those that are assigned by default.

The default labels are listed in the following table:

Summary


Now you should have a good foundation of the core constructs in Kubernetes. We explored the new Deployment abstraction and how it improves on the basic Replication Controller, allowing for smooth updates and solid integration with services and autoscaling. We also looked at other types of workload in jobs and DaemonSets. You learned how to run short-running or batch tasks as well as how to run agents on every node in our cluster. Finally, we took a brief look at node selection and how that can be used to filter the nodes in the cluster used for our workloads.

We will build on what you learned in this chapter and look at the Stateful applications in the next chapter, exploring both critical application components and the data itself.

lock icon
The rest of the chapter is locked
You have been reading a chapter from
Getting Started with Kubernetes, Second Edition - Second Edition
Published in: May 2017Publisher: PacktISBN-13: 9781787283367
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
undefined
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $15.99/month. Cancel anytime

Author (1)

author image
Jonathan Baier

Jonathan Baier is an emerging technology leader living in Brooklyn, New York. He has had a passion for technology since an early age. When he was 14 years old, he was so interested in the family computer (an IBM PCjr) that he pored over the several hundred pages of BASIC and DOS manuals. Then, he taught himself to code a very poorly-written version of Tic-Tac-Toe. During his teenage years, he started a computer support business. Throughout his life, he has dabbled in entrepreneurship. He currently works as Senior Vice President of Cloud Engineering and Operations for Moody's corporation in New York.
Read more about Jonathan Baier

Default Node Labels

Description

kubernetes.io/hostname

This shows the hostname of the underlying instance or machine

beta.kubernetes.io/os

This shows the underlying operating system as a report through the Go Language

beta.kubernetes.io/arch

This shows the underlying processor architecture as a report through the Go Language

beta.kubernetes.io/instance-type

(Cloud-Only) This is the instance type of the underlying cloud provider

failure-domain.beta.kubernetes.io/region

(Cloud-Only) This is the region of the underlying cloud provider

failure-domain.beta.kubernetes...