KURMA - A Containerized Container Platform - KubeCon 2016
7 likes2,795 views
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.
KURMA - A Containerized Container Platform - KubeCon 2016
- 2. 2016
- 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
- 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 – ...
- 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 ...
- 26. Kurma Extending Boundries with Semantics
- 27. Kurma Remote API
- 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?