In this session we'll discuss some of Kubernetes' basic concepts and talk about the architecture of the system, the problems it solves, and the model that it uses to handle containerized deployments and scaling.

2. Contents
Why even bother
Containers
Container Orchestrators
Kubernetes - What? Why? How?
Kubernetes - The details
Extending Kubernetes
Relation status - it’s complicated
Going forward

4. Let’s define players
Service based
Event driven
Open API
No infra management
Managed security
Pay only for usage
Developer Operator

7. Containers

8. Container - What's in a name?
Coming from the shipping industry
Caused aquatic theme for domain

9. Shipping containers
Portability - can be used on any of supported types of ships
Wide variety of cargo that can be packed inside
Standard sizes - standard fittings on ships
Many containers on a ship
Isolates cargo from each other

10. Translated to software
Portability - can be used on any supported system (system with container execution
environment)
Wide variety of software that can be packed inside
Standard format
Many containers to a physical node
Isolates execution of one container from another

11. What is a container?
way to pack code and dependencies together
can run anywhere
execute multiple containers to a physical machine

12. Sounds familiar?
same concept as virtual machines
pack OS and software together, to run in isolated instances
can run anywhere the specific hypervisor runs
multiple VMs to a physical machine

13. How do VMs work?
hypervisor = layer between VM and kernel
emulates system calls
allows multiple types of operating systems on a machine (Windows on Linux)
overhead for hypervisor

14. Containers on the other hand ...
only contain application and application-related libraries and frameworks, that run on
the host machine's kernel
smaller
lower overhead
differences in OS distributions and dependencies are abstracted - same kernel

15. Working together, not against each other
Windows on Linux possible only with VMs
older software needs to be adapted to be run as containers (and won't)
usage of VMs as a medium for containers (better isolation and easier scaling)

16. Greater modularity in software
Monolithic application → independent services that interact (microservices)

17. Containers empowering microservices
quicker start times -> easy to prototype or scale
allow work to be done independently on modules -> independent releases for
components (take care of interfaces)
isolated and abstracted runtime environments, that can be tailored for each module
shared runtime environment, for heterogeneous applications

18. Containers history – early days
need for resources to be shared among many users -> multiple terminals connected to
the same mainframe
main problem - execution can cause the main computer to crash -> down for
everybody

19. Containers history – Linux containers (lxc)
2008
Provides virtualization at OS level
Provides containers with its own process and network space

20. Containers history – Docker
2013
Container execution and management system
Originally started with lxc, then moved to libcontainer, which allows containers to work
with:
• linux namespaces
• libcontainer control groups
• capabilities
• app armor security profiles
• network interfaces
• firewall rules

21. Containers history – OCI & CNCF
Open Container Initiative – 2015
industry format for a container format and container runtime software for all platforms
spend resources on developing additional software to support use of standard containers,
instead of format alternatives
Cloud Native Container Foundation – 2015
Working on different projects to further standardize the market:
• Kubernetes
• Container Network Interface
• Containerd

22. Container orchestration

23. Need for something more?
docker started out with a CLI tool on top of lxc, that built, created, started, stopped
and exec'd containers
does management at a node level, upon specific requests
easy to manually manage with up to 100s of containers and 10s of nodes, but what
next?

24. Orchestrator
manage and organize both hosts and docker containers running on a cluster
main issue - resource allocation - where can a container be scheduled, to fulfill its
requirements (CPU/RAM/disk) + how to keep track of nodes and scale

25. Some orchestrator tasks
manage networking and access
track state of containers
scale services
do load balancing
relocation in case of unresponsive host
service discovery
attribute storage to containers

26. Orchestrator options
Kubernetes – open-source, product of CNCF
Apache Mesos – cluster management tool, with container orchestration being only one
of the things it can do, originally through a plugin called Marathon
Docker Swarm – integrated in docker container platform

27. Lately ...
Mesos announced Kubernetes support as container orchestration, alongside Marathon
Docker Enterprise Edition - integration with Kubernetes alongside Swarm
→ Kubernetes becoming the de-facto standard for container
orchestration (allowing developers to focus on building on top
instead of alternatives)

28. Kubernetes – What? Why? How?

29. What is Kubernetes?
“Kubernetes” = Greek for governor, helmsman, captain
open-source container orchestration system
originally designed by Google, maintained by CNCF
aim to provide "platform for automating deployment, scaling and operations of
application containers across clusters of hosts"

30. Why Kubernetes? - Goals
Main objectives, stated by devs, for community
Achieve velocity
Allow scaling of both software and teams
Present abstract infrastructure
Gain efficiency

31. Achieve velocity
Velocity = number of things you ship while maintaining a highly available service
Achieved by:
• immutability - created artifact cannot be changed
• declarative configuration - declare desired state and Kubernetes' job is to ensure it
matches
• self-healing systems - trying to maintain desired states if something changes

32. Allow scaling of software
encouraging decoupling in applications - separated components that communicate via
defined APIs via load-balanced services
running in shared abstract environment, without interference
utilizing standard container format that runs on any machine

33. Allow scaling of teams
separation of concerns for consistency and scaling
• application ops rely on the SLA provided by the platform
• orchestrator ops uphold SLA

34. Present abstract infrastructure
decoupling container images and machines
cluster can be heterogeneous and reduce overhead and cost
portability - container can be used on another cluster without being changed

35. Gain efficiency
optimized usage of physical machines - multiple containers on same machine
isolated with namespaces, to not interfere with each other

36. Kubernetes - the details

37. Container image format
layered format, allowing to inherit from lower
levels and to modify them by adding, changing or
removing files
using unified file system that allows this layering
issue – deleted file remains in older layers
image size bigger and build time longer ->
development of better tools

38. Running a container
image provides the filesystem base for execution
configuration, to interoperate with the rest of the system – environment variables,
CPU/RAM requirements, process to execute, ports to expose, etc.

39. Kubernetes and containers
Can you deploy a container in Kubernetes? NO (not directly)
Why not? Because the smallest deployable unit of computing is not a container, but ...

40. Pod
smallest deployable unit of computing in Kubernetes
colocated multiple apps(containers) into a single atomic unit, scheduled onto a single
machine
upon creation, statically allocated to a certain node

41. Pod
each container runs in its own cgroup (CPU + RAM allocation), but they share some
namespaces and filesystems, such as:
• IP address and port space
• same hostname
• IPC channels for communication

42. So, why a pod and not container directly?
all or nothing approach for a group of symbiotic containers, that need to be kept
together at all times
pod considered running if all containers are scheduled and running
Can you deploy a container in Kubernetes? Yes, inside a pod!

43. Service
abstraction which defines a logical set of Pods (selected using label selector), that
provide the same functionality (same microservice)
different types, for different types of exposure provided by the service

44. Deployment
manages replica set through time and versions for pod spec
scale != version update
using health checks, makes sure a new version works
allows rollbacks to older versions (keeps track of changes)

45. Deployment strategies - recreate
all previous pods are destroyed and new pods are created
quickest
downtime while new pods start
in case of problems and rollback, even more downtime

46. Kubernetes - next steps

47. Soooo many things to configure :(
at least one controller
some services
some configMaps and Secrets
preallocate persistentVolumes or create storage class for dynamic provisioning

48. Solution: another level of abstraction
higher-level controller that can manage lower-level elements
for the moment, not included in Kubernetes ... YET!
BUT can be added, through third-party controllers

49. What is Helm?
package manager for Kubernetes
provides higher-level abstraction (Chart) to configure full-fledged applications
manage complexity, easy upgrades, simple sharing of full application setups, safe
rollbacks

50. How does Helm work?
Helm CLI + Tiller server in Kubernetes (which is a controller)
CLI responsible for management + requests for releases of charts on Kubernetes
Tiller - listens for requests, combines chart + configuration = release, install release,
track release

51. Helm++
Helm release controller - current Lentiq way to manage applications
expose HelmRelease as a CRD (custom resource definition) in Kubernetes, to work
directly with Kubernetes to manage apps

52. What are Operators?
domain-specific controller
manages lifetime of a single application
works with Kubernetes primitives, as well as performing application-specific steps

53. Operators
pre and post provision hooks, for application-specific operations
single tool to perform all management (kubectl)
work in a scalable, repeatable, standard fashion
improve resiliency while reducing burden on IT teams

54. Relation status - it’s complicated
Write
Build a container image
Deploy the application
Expose at an endpoint
Request-level load
balancing
Set up SSL/TLS
Scale up based on
demand
Scale down to zero
Canary deployments
Monitor metrics

55. Cloud native stack

56. What Kubernetes missing ?
Source-to-URL deploys
Canary deployments, rollouts/rollbacks
Kubernetes needs container images built/pushed
Kubernetes has no notion of immutable revisions to cleanly rollback
Manage application traffic
Kubernetes cannot natively split traffic (lack of L7 HTTP load balancing)
Out-of-the box monitoring
Kubernetes doesn’t provide monitoring signals beyond CPU/memory
Scale-to-zero
Kubernetes cannot do natively

57. Going forward
More projects will natively support k8s
CockroachDB - A database architected and built for Kubernetes
SiSense BI engine rewritten in k8s)
More business scenarios (KubeFlow - Running ML/DS pipeline)
Go serverless (Knative ,kubeless)
Lightweight k8s (k3s - running on edge devices)
Advanced k8s management systems (Multi cloud ,Backup and restore
,Security)

58. Q&A