Tectonic Summit 2016: Brandon Philips, CTO of CoreOS, Keynote
Download as PPTX, PDF2 likes516 views
The document discusses CoreOS's expertise across the technology stack for container-based applications. This includes Linux, container engines, container image specifications, clustered databases like etcd, cloud independence, identity federation, and more. CoreOS is focused on open standards through initiatives like the Open Container Initiative and ensuring technologies like Kubernetes, rkt, and etcd can scale to power large production deployments.
Tectonic Summit 2016: Brandon Philips, CTO of CoreOS, Keynote
- 1. Brandon Philips @brandonphilips | [email protected] | coreos.com
- 3. Experts at Every Layer of the Stack Linux Container Engines & Runtime Specs Image Specs, Build, & Hosting Clustered Database Cloud Independence & Lifecycle Identity & Federation
- 4. Experts at Every Layer of the Stack Linux Container Engines & Runtime Specs Container Image Build, Hosting, & Specs Clustered Database Cloud Independence & Lifecycle Identity & Federation
- 5. Experts at Every Layer of the Stack Linux Container Engines & Runtime Specs Container Image Build, Hosting, & Specs Clustered Database Cloud Independence & Lifecycle Identity & Federation
- 6. The shared foundation of this ecosystem is the container
- 7. And CoreOS is ensuring that the shared foundation is built on standards
- 8. Open Container Initiative OCI Announced June 2015 OCI 1.0 Q1 2017 rkt OCI support July 2016 OCI Image Spec Added April 2016 Quay, Kubernetes, etc Q2 2017 OCI 1.0 RC-1 July 2016
- 9. Create developer collaboration Build interoperating products Confidence in ecosystem stability Investment in standards
- 10. An update about the pod native container engine
- 11. rkt community traction ● Laptop Kubernetes, minikube, can use rkt with a single flag ● BlaBlaCar (Series D, $350m) rkt in prod and moving to Kubernetes ● Container Linux services now run under rkt ● Google GKE using rkt for Kubelet mount management
- 12. Kubernetes & rkt integration via CRI Support all OCI standards as they reach 1.0 Continue innovation in design and security Roadmap for rkt
- 13. Kubernetes & rkt integration via CRI Support all OCI standards as they reach 1.0 Continue innovation in design and security Roadmap for rkt
- 14. Quick Reminder: Pod Basics cache (pid 5) asset fetcher (pid 8) web server (pid 9) pod sandbox
- 15. Quick Reminder: Pod Lifecycle worker nodes controllers nodes EC2 VM EC2 VM EC2 VM EC2 VM EC2 VM EC2 VM EC2 VM EC2 VM EC2 VM
- 16. Quick Reminder: Pod Lifecycle A1 Kubernetes Scheduler Kube API Monitoring Service worker nodes controllers nodes
- 17. Quick Reminder: Pod Lifecycle A1 Kubernetes Scheduler Kube API Monitoring Service worker nodes controllers nodes
- 18. Quick Reminder: Pod Lifecycle A1 Kubernetes Scheduler Kube API Monitoring Service J2 worker nodes controllers nodes
- 19. Quick Reminder: Pod Lifecycle A1 Kubernetes Scheduler Kube API Monitoring Service J2 worker nodes controllers nodes
- 20. Container Runtime Interface cache (pid 5) asset fetcher (pid 8) web server (pid 9) pod sandbox
- 21. Container Runtime Interface cache (pid 5) asset fetcher (pid 8) web server (pid 9) pod sandbox
- 22. Container Runtime Interface cache (pid 5) asset fetcher (pid 8) web server (pid 9) pod sandbox Health Check Fail
- 23. Container Runtime Interface cache (pid 5) asset fetcher (pid 8) pod sandbox
- 24. Container Runtime Interface cache (pid 5) asset fetcher (pid 8) pod sandbox web server (pid 10)
- 25. rkt and CRI will help enable faster innovation in Kubernetes in 2017.
- 26. Kubernetes & rkt integration via CRI Support all OCI standards as they reach 1.0 Continue innovation in design and security Roadmap for rkt
- 27. rkt and runc cache (pid 5) asset fetcher (pid 8) web server (pid 8) runc runc runc pod sandbox
- 28. Kubernetes & rkt integration via CRI Support all OCI standards as they reach 1.0 Continue innovation in design and security Roadmap for rkt
- 29. rkt is the only container engine with both Linux native and VM isolation.
- 30. rkt is the only container engine with both Linux native and VM isolation. We continue to explore new ideas.
- 31. Normal rkt execution cache (pid 5) debug agent (pid 8) web server (pid 9) pod sandbox cache (pid 10) debug agent (pid 38) web server (pid 20) pod sandbox
- 32. VM rkt execution cache (pid 5) debug agent (pid 8) web server (pid 9) pod sandbox cache (pid 5) debug agent (pid 8) web server (pid 9) pod sandbox
- 33. bash (uid 1001, pid 8) Lifecycle of a process bash (uid 1001, pid 9) fork() identical perms su (uid 0, pid 9) exec() setuid binary elevate perms bash (uid 0, pid 9) exec() identical perms Normal Execution Path
- 34. bash (uid 1001, pid 8) Lifecycle of a process bash (uid 1001, pid 9) fork() identical perms bash (uid 0, pid 9) open() kernel exploit elevate perms Exploit Execution Path Container Terminated
- 35. VM rkt execution cache (pid 5) debug agent (pid 8) web server (pid 9) kvm virtual machine Privilege Escalation Validator pod sandbox Can PID 8 open /proc/9/environ it is uid 0?
- 36. VM rkt execution Yes, valid elevation to uid 0 cache (pid 5) debug agent (pid 8) web server (pid 9) kvm virtual machine Privilege Escalation Validator pod sandbox
- 37. cache (pid 5) debug agent (pid 8) web server (pid 9) kvm virtual machine VM rkt execution rootkit payload Privilege Escalation Validator pod sandbox
- 38. cache (pid 5) debug agent (pid 8) web server (pid 9) kvm virtual machine VM rkt execution rootkit payload Privilege Escalation Validator pod sandbox Can PID 9 open /etc/shadow it is uid 0?
- 39. cache (pid 5) debug agent (pid 8) web server (pid 9) kvm virtual machine VM rkt execution rootkit payload No, invalid transition to uid 0 Privilege Escalation Validator pod sandbox
- 40. cache (pid 5) debug agent (pid 8) web server (pid 9) kvm virtual machine pod sandbox VM rkt execution Privilege Escalation Validator Container Terminated
- 42. Tectonic will support users with Docker Engine or rkt engine. End-to-end.
- 43. Kubernetes scales. And we have worked end-to-end to make it happen
- 44. ● Clients talk to Kubernetes API server ● API is stateless and horizontally scales ● State from API persisted to etcd DB Quick Reminder: Kubernetes Architecture
- 45. ● etcd introduced in 2013 by CoreOS ● Persistent database of Kubernetes ● Auto-leader election for availability etcd Overview
- 46. etcd is the foundation of Kubernetes
- 47. CoreOS ensures it is scalable, simple, solid etcd is the foundation of Kubernetes
- 48. Scaling Milestones of Kubernetes 100 Nodes 300 Pods June 2015 2,000 Nodes 60,000 Pods November 2016 1,000 Nodes 30,000 Pods March 2016 5,000 Nodes 150,000 Pods December 2016
- 49. ● Google Chubby ● etcd by CoreOS ● ZooKeeper by Apache ● Consul by Hashicorp Consistent Key-Value Database
- 50. ● Google Chubby (closed source) 1.etcd by CoreOS 2.ZooKeeper by Apache 3.Consul by Hashicorp Consistent Key-Value Database, Benchmark
- 51. Memory, key to scalability
- 52. Latency, key to reliability
- 53. Latency, key to reliability etcd's delivers consistent latency
- 54. Scaling Milestones of Kubernetes 2,000 Nodes 60,000 Pods November 2016 1,000 Nodes 30,000 Pods March 2016 5,000 Nodes 150,000 Pods December 2016 20,000 Nodes 600,000 Pods 2017
- 55. CoreOS ensures it is scalable, simple, solid etcd is the foundation of Kubernetes
- 56. etcd Operator
- 57. etcd Operator
- 58. etcd Operator
- 59. etcd Operator
- 60. CoreOS ensures it is scalable, simple, solid etcd is the foundation of Kubernetes
- 62. etcd is Trusted by 100s of OSS Projects
- 63. Google. Amazon. Microsoft. etcd is Trusted by 100s of OSS Projects Including Projects From Teams At
- 66. $ uname -s minix $ gcc linux.c
- 67. $ uname -s minix $ gcc linux.c
- 69. $ uname -s linux $ gcc linux.c
- 70. $ uname -s linux $ gcc linux.c
- 71. Self-Hosted Architecture worker nodes controllers nodes EC2 VM EC2 VM EC2 VM EC2 VM EC2 VM EC2 VM EC2 VM EC2 VM EC2 VM
- 73. Self-Hosted Architecture Kubernetes Scheduler Kube API MS controllers nodes A1 J2 worker nodes KS
- 74. Self-Hosted Architecture Kubernetes Scheduler Kube API MS controllers nodes A1 J2 worker nodes KS
- 76. Toil is the kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows. Self-Driving Removes Toil
- 77. CHECK But... Failures Still Happen Self-Driving Removes Toil
- 81. "Self-hosted" is being adopted in the Kubernetes community.
- 86. OpenID Connect (OIDC) provider with LDAP plugin. Integrated into upstream Kubernetes. No external databases, simply use the Kubernetes API. Default in Tectonic.
- 88. CoreOS is ensuring that the shared foundation is built on standards
- 89. rkt will help enable faster innovation in Kubernetes in 2017.
- 90. Kubernetes scales. And we have worked end-to-end to make it happen.
- 91. Self-driving architecture simplifies and removes toil.
- 92. Experts at Every Layer of the Stack Linux Container Engines & Runtime Specs Container Image Build, Hosting, & Specs Clustered Database Cloud Independence & Lifecycle Identity & Federation
- 93. THANK YOU!! @brandonphilips | [email protected] | coreos.com
Editor's Notes
- #4: Thanks for joining us for day 2. Continue great conversations use cases. Our big mission only works when we have engaged users pushing us forward. This morning: walk through places CoreOS has applied our expertise.
- #5: To deliver containers and Kubernetes a number of technologies need to come together. From Linux Operating Systems to Identity and Federation.
- #6: CoreOS has been building the products and OSS investments to make the ecosystem go. And some of these are non-trivial undertakings. Example: we have introduced widely adopted Linux distro and a best-in-class database to market.
- #7: Alex covered a few of the parts of that stack yesterday so I will skip those today. I will focus on progress across the rest of the stack. Namely in containers, etcd, kubernetes, and identity with Dex.
- #8: Everything we have built over the last 3 years relies on the success of containers. From Container Linux, Kubernetes, and rkt the health of container technology is critical.
- #9: And we have been working alongside the entire industry to ensure this foundation is built on standards.
- #10: About 18 months ago the OCI was formed. Including CoreOS as a founding member. There are now about 50 member companies all working on standards And a number of important milestones have been accomplished over this last year. As a technical board member and maintainer on both specifications I look forward to release of OCI 1.0 And I know there are many products planning on integrating OCI into their products next year.
- #11: But, why do standards matter? Dev collaboration: it is easy to miss critical details low in the stack Interoperating products: even with open source it is easy to make lego pieces that don't quite fit together Stability: having leading companies come together means this interoperation isn't transient.
- #12: Two years ago we introduced rkt. The focus was on using good standards and security practices. And the product has found itself used successfully in many places. With a bright future ahead; lets dig in.
- #13: Quick update on some milestones that rkt has seen in users. These are highlights from a large list; but give you a sense of where rkt has been getting used.
- #14: Over the next year we have three major goals: Full Kubernetes integration, today we are at about 90% Support all of OCI as it reaches 1.0 And continue to push the limits of design and security. Lets break these down.
- #15: Over the next year we have three major goals: Full Kubernetes integration, today we are at about 90% Support all of OCI as it reaches 1.0 And continue to push the limits of design and security. Lets break these down.
- #28: Over the next year we have three major goals: Full Kubernetes integration, today we are at about 90% Support all of OCI as it reaches 1.0 And continue to push the limits of design and security. Lets break these down.
- #30: Over the next year we have three major goals: Full Kubernetes integration, today we are at about 90% Support all of OCI as it reaches 1.0 And continue to push the limits of design and security. Lets break these down.
- #56: 5000 nodes kubemark data: ~16K ops/second (~14k reads, ~700 writes, ~700 watch events), ~1GB data set etcd3 max performance with k8s workload: ~80k ops; ~4GB data set.
- #58: This work is critical for running single clusters
- #59: Reference back to david's talk monday
- #60: Reference back to david's talk monday
- #61: Reference back to david's talk monday
- #80: JOKE:
- #81: JOKE:
- #83: kubeadm, kops, SIG cluster-lifecycle
- #84: Reference back to david's talk monday
- #85: Reference back to david's talk monday
- #86: Reference back to david's talk monday
- #87: Reference back to david's talk monday
- #95: Positive about how far we have come Now we need to do X