This document discusses Kubernetes and Elixir. It provides an overview of Kubernetes, including what it is, basic concepts like pods and services, and how it can manage containerized workloads. It also compares Kubernetes to Elixir's BEAM capabilities, noting they are orthogonal and can coexist. The document argues Kubernetes can provide benefits to Elixir applications like easier deployments and multi-tenancy, while acknowledging there may be some drawbacks around hot deployments and BEAM clustering within Kubernetes.
4. "Kubernetes is a portable, extensible open-source
platform for managing containerized workloads and
services, that facilitates both declarative
configuration and automation."
- Kubernetes Documentation
5. MY INTERPRETATION
• Distributed platform to run anything, as long as it's
containers
• Batteries included (networks, security, service
discovery, secrets)
• "Easier" to automate because you don't need to
script
6. BASIC PLATFORM CONCEPTS
• All applications are just
some sort of task/worker
(does things), workloads
may be different
• Needs to run on something
(server, local desktop, etc.)
• Usually needs to talk to
other things through via
network
• Would be good if it's secure
7. THIS IS WHAT KUBERNETES
DOES
• Takes care of all these things for us e.g.
• What machine does the task run on?
• How does each group of tasks find/talk to each other?
• How does the clients talk to us?
• How do I protect each workload?
9. DIGRESSION - DOCKER
CONTAINERS
• Different types of container like LXC, Solaris Zones, Rkt
• Think of it as a packaging system for your app and all it's dependencies (including OS
libraries), which also contains
• hooks to run the application safely inside the package (container)
• Not a Virtual Machine
• Images are sharable through a "Docker Registry", e.g. [Dockerhub](https://
hub.docker.com/), [Google Container Engine (GKE)](https://cloud.google.com/
kubernetes-engine/) or your own internal registry.
• This means I can build an image which anyone (or system) can pull down and run,
provided they have Docker installed
• In general, this means I can build and compile something locally, test it and push it up
and be fairly sure it will work in other places
10. KUBERNETES CONCEPTS
• Pods (e.g. Application Units)
• Smallest Logical Unit (Usually 1 container per Pod)
• Tasks/Worker containers (Does the work)
• Controllers (A way to deploy the pods)
• Deployments - Typical Service, long running replicated
apps with multiple instances, Blue green
• Jobs - These are just single tasks which runs to completion
X number of times
• Cronjobs - Tasks which run on schedule
11. KUBERNETES CONCEPTS - SERVICES, LOAD
BALANCING AND NETWORKING
• Quite complicated but the basic concepts are:
• Services - an endpoint to sit in front of your
workload to be accessed internally/externally
• Ingress - Internal rules to control what can and
cannot be accessed, e.g. paths/routes. Like
NGINX configuration
• DNS - A way to find other services in the cluster
13. BEAM VS KUBERNETES
BEAM Kubernetes
Monitor Tasks ✅ ✅
Distributed across multiple nodes ✅ ✅
Service Discovery ✅ ✅
Hot Upgrades ✅ ❌
Language Agnostic ❌ ✅
Platform Components (networks) ❌ ✅
14. BEAM VS KUBERNETES
• They are orthogonal, can co-exist peacefully
• Kubernetes is focused on Day 2 and Enterprise
Ops
• BEAM is just awesome, but can be complicated
and scary for Ops
15. KUBERNETES AND ELIXIR
TOGETHER
• Elixir Application needs to be inside a Docker container
• Easier deployments
• Good multi-tenancy
• Treat Elixir App like any other app (task)
• Environment variables for configs
(REPLACE_OS_VARS=true)
• Stateless is best
16. KUBERNETES AND ELIXIR -
POSSIBLE DRAWBACKS
• May not be able to use some BEAM goodies
• No hot deployments
• BEAM clustering can be messy (EPMD will have a
hard time finding nodes)
• No DETS
• Kubernetes is great to use, super difficult to operate
17. CONCLUSION
• Kubernetes and Elixir can be great together
• Treat your Elixir app like any other app, except it’s
rock solid compared to other apps (e.g. Node.js)
• Some drawbacks to be aware of
• Kubernetes may not actually be necessary for your
needs - Dev Experience vs Ops Pain