Download as PDF, PPTX
Uploaded byBergamo Linux Users Group
Orchestrating Linux Containers
The document discusses orchestrating Linux containers with a focus on developing scalable microservices architectures across hybrid cloud environments. It highlights the challenges of container deployment, including service discovery, self-healing, and data persistence, while presenting Kubernetes as a robust orchestration engine that manages application states and simplifies these issues. Practical examples are provided, such as managing a guestbook application with MongoDB, detailing how to effectively handle changes and resource allocation for containers.
More Related Content
Similar to Orchestrating Linux Containers
Orchestrating Linux Containers
- 1. Orchestrating Linux Containers Flavio Castelli EngineeringManager fcastelli@suse.com
- 2. New development challenges ● Releaseearly, release often ● Be flexible: react to changes quickly ● Adoption of micro services architectures ● Different cloud providers ● Higher complexity of cloud environments ● Hybrid cloud deployments ● Application super portability 2
- 3. Let’s talk about applicationcontainers... 3
- 4.
- 5.
- 6.
- 7. Multi-host deployment 7 host-A host-Bhost-C App X App Y App Z eth0 eth0 eth0
- 8. Some of thechallenges ● Decide where to run each container ● Monitor nodes and containers ● Recover from failures ● Service discovery ● Expose services to external consumers ● Handle secrets (eg: credentials, certificates, keys,…) ● Handle data persistence 8
- 9.
- 10. How can theyhelp us? ● No need to find the right placement for each container ● No manual recovery from failures ● Just declare a “desired state” 10
- 11. Desired state reconciliation 11 Statedescription Current state Compute actionsExecute actions
- 12.
- 13.
- 14. Kubernetes ● Created by Google,now part of CNCF ● Solid design ● Big and active community ● Opinionated solution, has an answer to most questions 14
- 15.
- 16.
- 17. A simple webapplication ● Guestbook application ● Mongodb as database ● Both running inside of dedicated containers 17
- 18.
- 19. Challenge #1: self-healing 19 host-Ahost-B mongo-01 eth0 eth0 Automatic recovery from failures, enforce desired state host-A host-B eth0 eth0 mongo-01
- 20. Replica Set ● Ensure thata specific number of “replicas” are running at any one time ● Recovery from failures ● Automatic scaling 20
- 21.
- 22. Challenge #2: servicediscovery 22 host-A host-B gbook-01 mongo-01 eth0 eth0 Where is mongo? host-A host-B gbook-01 mongo-01 eth0 eth0 ● “mongo” container: producer ● “gbook” container: consumer
- 23. Use DNS ● Not agood solution: – Containers can die/be moved somewhere more often – Return DNS responses with a short TTL → more load on the server – Some clients ignore TTL → old entries are cached Note well: ● Docker < 1.11: updates /etc/hosts dynamically ● Docker >= 1.11: integrates a DNS server 23
- 24. Key-value store ● Rely ona key-value store (etcd, consul, zookeeper) ● Producer register itself: IP, port # ● Orchestration engine handles this data to the consumer ● At run time either: – Change your application to read data straight from the k/v – Rely on some helper that exposes the values via environment file or configuration file 24
- 25. Handing changes & multiplechoices 25
- 26. Challenge #3: reactto changes 26 host-A host-B gbook-01 mongo-01 eth0 eth0 host-C eth0 “gbook” is already connected to “mongo”
- 27. Challenge #3: reactto changes 27 host-A host-B gbook-01 mongo-01 eth0 eth0 host-C mongo-01 eth0 “gbook” points to to the old location → it’s broken “mongo” is moved to another host → different IP
- 28. Challenge #3: reactto changes 28 The link has to be reestablished host-A host-B gbook-01 eth0 eth0 host-C mongo-01 eth0 Containers can be moved at any time: ● The producer can be moved to a different host ● The consumer should keep working
- 29. Challenge #4: multiplechoices 29 Multiple instances of the “mongo” image host-A host-B gbook-01 mongo-01 eth0 eth0 host-C mongo-01 eth0 Which mongo? Workloads can be scaled: ● More instances of the same producer ● How to choose between all of them?
- 30. DIY solution ● Use aload balancer ● Point all the consumers to a load balancer ● Expose the producer(s) using the load balancer ● Configure the load balancer to react to changes → More moving parts 30
- 31. Kubernetes services 31 host-B mongo-01 eth0 host-C mongo-01 eth0 host-A gbook-01 eth0 mongo service VIP ● Servicegets a unique and stable Virtual IP Address ● VIP always points to one of the service containers ● Consumers are pointed to the VIP ● Can run in parallel to DNS for legacy applications
- 32.
- 33. Challenge #5: publishapplications ● Your production application is running inside of a container cluster ● How to route customers’ requests to these containers? ● How to react to changes (containers moved, scaling,…)? 33
- 34. Kubernetes’ approach Services canbe of three different types: ● ClusterIP: virtual IP reachable only by containers inside of the cluster ● NodePort: “ClusterIP” + the service is exposed on all the nodes of the cluster on a specific port → <NodeIP>:<NodePort> ● LoadBalancer: “NodePort” + k8s allocates a load balancer using the underlying cloud provider. Then it configures it and it keep it up-to-date 34
- 35. Ingress traffic flow 35 Load balancer http://guestbook.com host-B gbook-01 8081 blog-01 8080 host-A gbook-01 80818080 host-C 8081 blog-01 8080 ● Loadbalancer picks a container host ● Traffic is handled by the internal service ● Works even when the node chosen by the load balancer is not running the container
- 36.
- 37. Challenge #6: statefulcontainers ● Not all applications can offload data somewhere else ● Some data should survive container death/relocation 37
- 38. Kubernetes Volumes ● Built intokubernetes ● They are like resources → scheduler is aware of them ● Support different backends via dedicated drivers: – NFS – Ceph – Cinder – ... 38
- 39.
- 40.