The document outlines the development of the Kurma platform, which evolved from the Apcera system, focusing on containerization and minimizing host dependencies. It introduces a new process model that enhances flexibility and extensibility, along with integrations for networking and orchestration in a Kubernetes environment. Key features include a minimalist operating system for services as containers and reusable components for improved deployment and management.

2. 2016

3. In the beginning…
(2012)

4. The Go Landscape
2012

5. Apcera Platform
The Instance Manager

6. Instance Manager
State Machine Apocalypse
● Started out simple, but naive about the future
● Few small libraries…
● … but all integration logic was central
● 8 states
● 53 function handlers

7. Existing Weight
● Ubuntu base OS
● CAPS deployment
● .deb packaging
● Operational tooling

8. System Skew is a Problem
● Deploys non-atomic
● Different lifecycle per host
● Operational access

10. A New Model
Kurma
● Minimize host dependencies
● Everything is a container
● Simple notions that could be easily extended
● Simple, well defined APIs

11. What is Kurma made of?
Existing
● Go + C
● App Container (AppC)
● Apcera’s existing
instrumentation
Coming soon
● Go + C
● AppC
● libcontainer based
● CNI for networking

12. What is Kurma made of?
Existing
● Go + C
● App Container (AppC)
● Apcera’s existing
instrumentation
Coming soon
● Go + C
● AppC
● libcontainer based
● CNI for networking

13. Delivery
kurmad
● Existing host
● Download and run
● Immediately benefit
● Depends on host kernel
and libc
kurmaOS
● Minimalist distro
● Services as containers
● A/B partition model
● Console is just a
container

14. Delivery
kurmad
● Existing host
● Download and run
● Immediately benefit
● Depends on host kernel
and libc
kurmaOS
● Minimalist distro
● Services as containers
● A/B partition model
● Console is just a
container

15. Kurma
Process Model

16. Kurma
Stager Process

17. Kurma
User Processes

18. Stager
Pluggable Process Orchestration
● Responsible for instrumenting the pod
● Packaged as a signed, trusted ACI image
● Gets own mount and network namespace

19. Stager API
● Simplest unit of work: an executable
● Setup via image ‘Exec’ setting
● Other calls through expected executables
– /opt/stager/run
– /opt/stager/status
– /opt/stager/logs
– ...

20. Kurma
Reusable Unit

21. Kurma
Reusable Unit for Extensibility

22. Networking API
● ACI image
● Passes along JSON configuration
● Executes commands to setup networking on
other containers
– /opt/network/add <ns> <container-id>
– /opt/network/del <ns> <container-id>

23. Kurma
Reusable Unit for Extensibility
/opt/stager/run cni /opt/network/add ...

24. Kurma
Extensibility Through Reuse

25. Kurma
Extensibility Through Reuse

26. Kurma
Extending Boundries with Semantics

27. Kurma
Remote API

28. Kubernetes + Kurma

29. Why?
● Kurma usage outside Apcera
● Increased platform flexibility
● Integrating with broader community

30. Kubelet
● Has existing Runtime interface
● Rich interface for engine communication
● Kubelet is a bit of a leaky abstraction
● Workarounds for Dockerisms

31. Testing
● Mystical
● Documentation gaps
● Excellent Github/PR integration

32. Codebase
● Godep pains
● “hack” directory?
● Documentation gaps
● Interface movement
Runtime.ConvertPodStatusToAPIPodStatus()

33. Kurmanetes
● Maturing Kurma based on Kubernetes needs
– Pods
– Networking
– Image management
● Runtime abstraction nearly complete

34. Kurmanetes
● Done
– Pod management
– Image retrieval and management
● Remaining
– Landing Kurma’s pod/stager branch
– cAdvisor integration
– Integration testing
– Work towards improving the abstraction leaks

35. Questions?

36. Resources
Kurma
kurma.io
github.com/apcera/kurma
Me
ken@apcera.com
@krobertson
We’re hiring for the Kurma team.