Saturday, June 10, 2017

Kubernetes Distilled

Kubernetes documentation is thorough, and you should read it when you have the time. Until then, this is a condensed overview aimed at developers using a kubernetes platform, that should get you comfortable enough, quickly enough.

I'm not an expert, so YMMV.

This is a work in progress! Feedback appreciated.

Overview

Kubernetes (or "k8s"–which is to kubernetes as a11y is to accessibility) runs on top of a cluster of nodes, where a node is machine as in physical or virtual machines, and a cluster is a datacenter or part of one. Nodes are the resources k8s uses to run itself (as a set of services) and the workloads it schedules. You'll interact with k8s through these services' APIs, usually from a command line client like kubectl, or from client libraries in a language of your choice.

On top of k8s, there are often services like OpenShift which provide yet another layer of abstraction, and can for example handle provisioning nodes and clusters running k8s for you.

Objects

K8s APIs are declarative. You do not say exactly how your application will run. Instead, you describe what your needs are in terms of objects (sometimes also called resources), each with an accompanying specification (or simply "spec"). Then, k8s figures out how to make your spec reality, communicating how it and its resources (nodes) are doing as an object's status. Objects come in their own varying degrees of abstraction, with higher level objects like Deployments managing lower level objects like Pods. Many objects, like Deployments, are controllers, which may run periodic tasks or watch and maintain the state of other objects. Controllers are usually where developers spend their time interfacing with k8s.

Specs are usually provided via kubectl and yaml files that look something like this:

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

K8s is constantly trying to keep an object's status in sync with its spec. This is one of the ways k8s makes your applications self healing. For this reason you may find if you go "below" an abstraction and try to change something, your changes may quickly be undone as k8s thinks it's "recovering" your objects that strayed from their specs.

All objects have a name, lower case strings made up of alphanumerics, dashes, and dots, unique among other objects of the same type, and a uid, unique among all objects over the lifetime of the cluster. Name and uid are are metadata. There is additional, optional metadata, too, that we'll talk about later.

Most of your kubectl usage will be via the create, get, and replace subcommands which work with objects, their specs and statuses (for example kubectl get -o yaml deployments my-deployment).

Pods

A pod defines a single deployable unit as one or more containers that share networking and storage. A pod is to a container like a VM is to your application's process(es). Most pods will run one container. Like VMs, pods are your unit of horizontal scaling: pods are replicated by a kind of Controller, like a Deployment. Unlike VMs, pods are always "ephemeral"–they don't maintain state. Non-volatile, persistent storage is provided by a different object, a PersistentVolume.

You need to understand them because this is where your code actually runs, however like mentioned above you won't ever be writing PodSpecs directly; you'll spec your pod(s) indirectly through controllers and templates. Templates tell controllers how to define PodSpecs for pods they manage.

Deployments

Deployments accomplish bread and butter k8s use cases: deploying and updating your application as a set of containers with various resource requirements to a number of scheduled pods. Generally, your first steps into k8s will be by defining a Deployment spec. Deployment specs include a PodTemplateSpec, which defines the containers and volumes about a pod. A container spec includes the image to use, and the ports to be exposed.

Services

Services are the other essential piece of a basic, production-ready application on k8s. TODO!

Post a Comment