Kubernetes The Path to Cloud Native

Size: px

Start display at page:

Download "Kubernetes The Path to Cloud Native"

Bernard Anthony
6 years ago
Views:

1 Kubernetes The Path to Cloud Native Eric Brewer VP, August 28, 2015 ACM SOCC

2 Cloud Na*ve Applica*ons Middle of a great transition unlimited ethereal resources in the Cloud an environment of services not machines thinking in APIs and co-designed services high availability offered and expected

3 Google has been developing and using containers to manage our applications for over 10 years. 2B launched per week simpliﬁes management performance isolation eﬃciency Images by Connie Google conﬁdential Do not Zhou distribute

4 VMs vs. Containers Virtual Machines Containers User Code Libraries Operating System Private Copy User Code Libraries Operating System syscall ISA Virtual Processor Physical Processor Shared Virtual Processor Physical Processor Containers: less overhead, enable more magic

5 Merging Two Kinds of Containers Docker It s about packaging Control: o packages o versions o (some config) Layered file system Prod matches testing Linux Containers It s about isolation performance isolation not security isolation use VMs for that Manage CPUs, memory, bandwidth, Nested groups

6 Google Pla=orm Layering GAE App Engine: Language-based Kubernetes GKE Containers: Process-based Easy to use, Flexible GCE Infrastructure: Machines

7 Kubernetes: Higher level of Abstrac*on Think About Composition of services Load-balancing Names of services State management Monitoring and Logging Upgrading Don t Worry About OS details Packages no conflicts Machine sizes (much) Mixing languages Port conflicts

8 Evolu*on is the Real Value Apps Structured as Independent Microservices Encapsulated state with APIs (like objects ) Mixture of languages Mixture of teams Services are Abstract A Service is just a long-lived abstract name Varied implementations over time (versions) Kubernetes routes to the right implementation

9 Service- Oriented Architecture? This is similar, but a also new Practical difference: Simple network RPCs now common JSON/http for REST (or grpc for sessions) Much better structure Micro smaller services and more of them New in Kubernetes: modular sub-services

10 A Quick Your Code

11 & Your Code Community Contribute Customized Use Trade Secret

12 SOA wrong granularity

13 Kubernetes: sub-structure Don t think of a container as the boundary of your application A container is more like a class in an object-oriented language. --- Google s Brendan Burns

14 Requirements... Sharing among containers Share namespaces (esp. PID, Network and IPC) Share filesystems (Often) Share a resource hierarchy

15 Requirements... Atomic co-scheduling of containers Composition requires co-location

16 Requirements... Parameterization of containers Configurable at runtime Documented and discoverable

17 Substructure Containers: Handle package dependencies Different versions, same machine No DLL hell Pods: Co-locate containers Shared volumes IP address, independent port space Unit of deployment, migration Pod MyService python glibc 2.21 /data MySQL python glibc 2.19

18 Dependencies: Services Service: Replicated pods o Source pod is a template Auto-restart member pods Abstract name (DNS) IP address for the service o in addition to the members Load balancing among replicas Service IP Load Balancer

19 Some Patterns... Examples of how you use substructure

20 Sidecars Sidecars extend and enhance Application Container node.js Sidecar Container Git Synchronizer Pod

21 Sidecar Pattern Sidecars extend and enhance Application Container nginx Sidecar Container Git Synchronizer Pod

22 Ambassador Pattern Ambassadors represent and present Application Container Ambassador Container PHP app redis proxy Redis Shards localhost Pod

23 Adapter Pattern Adapters normalize and abstract Application Container Adapter Container Monitoring System redis redis exporter Pod localhost Other adapters

24 Example: Rolling Upgrade with Labels v1.2 frontend v1.3 replicas: replicas: Replication Controller Replication Controller Pods: Labels: frontend v1.2 frontend v1.2 frontend v1.2 frontend v1.2 frontend v1.3 frontend v1.3 frontend v1.3 frontend v1.3

25 Summary A new path for Cloud Native applications: Collection of independent (micro) services Each service evolves on its own o Scale as needed o Update as needed o Mix versions as needed Pods provide critical structure o Template for service members o Group containers and volumes o Dedicated IP and thus port space Containers are the new classes

26 BACKUP

27 How? Implemented by a number of (unrelated) Linux APIs: cgroups: Restrict resources a process can consume CPU, memory, disk IO,... namespaces: Change a process s view of the system Network interfaces, PIDs, users, mounts,... capabilities: Limits what a user can do mount, kill, chown,... chroots: Determines what parts of the filesystem a user can see Google confidential Do not distribute

So, I have all these containers! Now what?

So, I have all these containers! Now what? Image by Connie Zhou Developer View job hello_world = { runtime = { cell = 'ic' } // Cell (cluster) to run in binary = '.../hello_world_webserver' // Program