Kubernetes - BKJackson/BKJackson_Wiki GitHub Wiki

Kubernetes for Machine Learning

Scale Your Data Pipelines with Airflow and Kubernetes - The perfect Kubernetes and Airflow setup, Mar 16, 2020
Bringing Machine Learning models into production without effort at Dailymotion - How we manage to schedule Machine Learning pipelines seamlessly with Airflow and Kubernetes using KubernetesPodOperator, Nov. 21, 2019
We’re All Using Airflow Wrong and How to Fix It - Tl;dr: only use Kubernetes Operators, Aug. 3, 2018

Tutorials Articles

What is Kubernetes? Container orchestration explained - How the Kubernetes open source project from Google makes containerized applications astonishingly easy to deploy, scale, and manage (Apr. 4, 2018)
Kubeflow pipelines - Kubeflow is a machine learning (ML) toolkit that is dedicated to making deployments of ML workflows on Kubernetes simple, portable, and scalable.
How to create and deploy a Kubeflow Machine Learning Pipeline (Part 1)
Cloud Foundry and Kubernetes - In this guide we’ll explore how Cloud Foundry and Kubernetes work together, how they relate to each other, help you decide which workloads to run on which technology, and answer the following questions:

  • How are Cloud Foundry and Kubernetes different?
  • What features do Cloud Foundry and Kubernetes have in common?
  • How are Cloud Foundry and Kubernetes used together?
  • In which scenarios would I use Cloud Foundry and Kubernetes?

Kubernetes Patterns

The Cron Job Pattern
Detailed tutorial on Kubernetes cron job scheduler

Kubernetes horror stories

Kubernetes fails: 3 ways to kill your clusters - 5/6/2019
Kubernetes Failure Stories - 1/20/2019
101 Ways to Crash Your Cluster - Nordstrom, 12/15/2017

On the Need for Container Orchestration

Containers are so lightweight and flexible, they have given rise to new application architectures. The new approach is to package the different services that constitute an application into separate containers, and to deploy those containers across a cluster of physical or virtual machines. This gives rise to the need for container orchestration—a tool that automates the deployment, management, scaling, networking, and availability of container-based applications.

It’s important to keep in mind that none of the low-level mechanisms used by containers, like Docker itself, are replaced by Kubernetes. Rather, Kubernetes provides a larger set of abstractions for using them for the sake of keeping apps running at scale.

What Kubernetes does for containers

It provides high-level abstractions for managing groups of containers that allow Kubernetes users to focus on how they want applications to run, rather than worrying about specific implementation details. The behaviors they need are decoupled from the components that provide them.

Here are some of the tasks Kubernetes is designed to automate and simplify:

  • Deploy multi-container applications. E.g., a database, a web front end, and a caching server.
    Kubernetes reduces the amount of work needed to implement such applications. You tell Kubernetes how to compose an app out of a set of containers, and Kubernetes handles the nitty-gritty of rolling them out, keeping them running, and keeping the components in sync with each other.

  • Scale containerized apps.
    Apps need to be able to ramp up and down to suit demand, to balance incoming load, and make better use of physical resources. Kubernetes has provisions for doing all these things, and for doing them in an automated, hands-off way.

  • Roll out new versions of apps without downtime.
    Part of the appeal of a container-based application development workflow is to enable continuous integration and delivery. Kubernetes has mechanisms for allowing graceful updates to new versions of container images, including rollbacks if something goes awry.

  • Provide networking, service discovery, and storage.
    Kubernetes handles many other fiddly details of container-based apps. Getting containers to talk to each other, handling service discovery, and providing persistent storage to containers from various providers (e.g., Amazon’s EBS) are all handled through Kubernetes and its APIs.

  • Do all this in most any environment.
    Kubernetes isn’t tied to a specific cloud environment or technology. It can run wherever there is support for containers, which means public clouds, private stacks, virtual and physical hardware, and a single developer’s laptop are all places for Kubernetes to play. Kubernetes clusters can also run on any mix of the above. This even includes mixes of Windows and Linux systems.

Kubernetes cluster

The highest-level Kubernetes abstraction, the cluster, refers to the group of machines running Kubernetes (itself a clustered application) and the containers managed by it.

Kubernetes master

A Kubernetes cluster must have a master, the system that commands and controls all the other Kubernetes machines in the cluster. A highly available Kubernetes cluster replicates the master’s facilities across multiple machines. But only one master at a time runs the job scheduler and controller-manager.

Kubernetes nodes

Each cluster contains Kubernetes nodes. Nodes might be physical machines or VMs. Again, the idea is abstraction: whatever the app is running on, Kubernetes handles deployment on that substrate. It is also possible to ensure that certain containers run only on VMs or only on bare metal.

Kubernetes pods

Nodes run pods, the most basic Kubernetes objects that can be created or managed. Each pod represents a single instance of an application or running process in Kubernetes, and consists of one or more containers. Kubernetes starts, stops, and replicates all containers in a pod as a group.

Pods keep the user’s attention on the application, rather than on the containers themselves. Details about how Kubernetes needs to be configured, from the state of pods on up, is kept in Etcd, a distributed key-value store.

Pods are created and destroyed on nodes as needed to conform to the desired state specified by the user in the pod definition.

Kubernetes controller

Kubernetes provides an abstraction called a controller for dealing with the logistics of how pods are spun up, rolled out, and spun down. Controllers come in a few different flavors depending on the kind of application being managed.

For instance, the recently introduced “StatefulSet” controller is used to deal with applications that need persistent state. Another kind of controller, the deployment, is used to scale an app up or down, update an app to a new version, or roll back an app to a known-good version if there’s a problem.

Kubernetes service

A service describes how a given group of pods (or other Kubernetes objects) can be accessed via the network.

As the Kubernetes documentation puts it, the pods that constitute the back end of an application might change, but the front end shouldn’t have to know about that or track it. Services make this possible.

Kubernetes scheduler

The scheduler parcels out workloads to nodes so that they’re balanced across resources and so that deployments meet the requirements of the application definitions.

Kubernetes controller manager

The controller manager ensures the state of the system—applications, workloads, etc.—matches the desired state defined in Etcd’s configuration settings.

Etcd must be configured to use SSL/TLS when sending information including secrets between nodes, rather than in plaintext.

Kubernetes Helm

Helm is something like a package manager for Kubernetes (like Pip for Python). Helm provides a definition mechanism, a “chart,” that describes how a given piece of software can be run as a group of containers inside Kubernetes.

You can create your own Helm charts from scratch, and you might have to if you’re building a custom app to be deployed internally. But if you’re using a popular application that has a common deployment pattern, there is a good chance someone has already composed a Helm chart for it and published it by way of the Kubeapps.com directory.

Kubernetes volumes

Many common kinds of storage, from Amazon EBS volumes to plain old NFS shares, can be accessed via Kubernetes storage drivers, called volumes. Normally, volumes are bound to a specific pod, but a volume subtype called a “Persistent Volume” can be used for data that needs to live on independently of any pod.

Kubernetes federation

Kubernetes provides a set of primitives, collectively known as federation, for keeping multiple clusters in sync with each other across multiple regions and clouds.

For instance, a given app deployment can be kept consistent between multiple clusters, and different clusters can share service discovery so that a back end resource can be accessed from any cluster. Federation can also be used to create highly available or fault-tolerant Kubernetes deployments, whether or not you’re spanning multiple cloud environments.