Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Become a cloud-native developer
http://meetup.com/docker-hanoi
Tu Nguyen
Master student @ University of Basel,
Switzerland
Docker Hanoi organizer
Apache Software Foundation committer
Kubernetes committer
Solution Architect @ FPT-Software
Interests:
Open-source cloud computing lover
Docker, Microservices, DevOps
Kubernetes crazy fan
Golang, OCaml, Chapel
Design Patterns
1980s-1990s: Object-oriented programming revolutionized software
development.
Why design patterns ?
Encode best practices.
Simplify development.
Make the application more reliable.
Make it easier for less experienced programmers to produce well-engineered code.
Which design patterns are suitable for today ?
Trend
Popularity of microservice architectures.
Popularity of {public} clouds.
Built from containerized software components.
Distributed applications running on distributed systems.
Emergence
A new design pattern which abstracts away the low-level details of code for developing
containerized applications.
Container Design Patterns
Container and container image
The abstractions needed for the development of distributed applications.
Container ⟺ Object.
Three types of container design patterns
Single-container patterns.
for container management.
Single-node patterns.
For cooperating containers.
Multi-node patterns.
For distributed algorithm.
Single-container patterns
Container boundary
Container interface
Container provides a natural boundary for defining an interface.
Much like object boundary.
Traditional container interface is extremely limited.
run()
pause()
stop()
Container interface
The interface is generally becoming richer.
Expose information
Application-specific monitoring metrics
Logs, events
Healthcheck
Configuration
Standard lifecycle
Create, start, stop, kill, delete
Graceful termination
SIGTERM, SIGKILL
Provide priority
High-priority containers guaranteed to run even when the cluster is oversubscribed.
Low-priority containers have to wait until resources become available.
Replicate yourself - scale up
Etc.
https://github.com/opencontainers/runtime-spec
Single-node patterns
Consist of symbiotic containers that are co-scheduled as an atomic unit onto a single machine
Kubernetes Pod
What is K8S pod ?
A pod is a group of one or more containers which are relatively tightly coupled, co-located, co-
scheduled, and run in a shared contexts.
Shared contexts ?
Share IP address
Share port space
Find each other via localhost
Have access to shared volumes
http://kubernetes.io/docs/user-guide/pods/
1. Sidecar
2. Ambassador
3. Adapter
Sidecar
Sidecars extend and enhance the main container.
Sidecar
Benefits
Container is the unit of resource accounting and allocation:
Main container can be configured to provide low-latency responses to queries.
Sidecar container is configured to trigger when the server is not busy.
Container is the unit of packaging:
Separating containers make it easy to divide responsibility for different development teams.
Container is the unit of reuse:
Sidecar can be paired with numerous different main containers.
Container provides failure boundary:
Main container can continue serving even if the sidecar has failed.
Container is the unit of deployment:
Allows each piece of functionality to be upgraded and rollbacked independently.
Note: version compatibility.
Ambassador
Ambassador proxy communication to and from a main container.
It presents an application with a simplified view of the outside world.
Ambassador
Benefits
Developers only have to think and program in term of their application connection to a localhost
single server.
Developers can test their application standalone by running a real instance on their local
machine.
Developers can reuse the ambassador with other applications that might even be coded in
different programming languages.
Adapter
In contrast to Ambassador.
Adapters present the outside world with a simplified, homogenized view of an application.
Standardizing output and interfaces.
Ensure all containers in the system have the same adapters interface. (ex: monitoring interface)
Multi-node patterns
Modular containers make it easier to build coordinated multi-node distributed applications.
1. Leader election
2. Work queue
3. Scatter/gather
Leader election
One of the most common problems in distributed systems.
Replication
Commonly used to share load among multiple instances of a component.
Replication in distributed application
Need to distinguish one replica from a set as the “leader”.
The other replicas are available to quickly take the place of leader if it fails.
Leader election
Typical leader election
A set of candidates is identified.
These candidates all race to declare themselves the leader.
One of the candidates win and becomes the leader.
The leader continually “heartbeats” to renew their position.
Other candidates periodically make new attempts to become the leader.
Raft consensus algorithm
https://raft.github.io/
Leader election
How to apply `leader election` to my app?
Import leader election libraries
https://raft.github.io/
They are generally complicated to understand and use correctly.
They are limited in particular programming languages.
Will container design pattern provide a better solution ???
Leader election with sidecar pattern
A set of leader-election containers, each one co-scheduled with an instance of
the application that requires leader election
Leader election sidecar
Container image
gcr.io/google_containers/leader-elector:0.4
Opening a HTTP endpoint at port 4040
curl http://localhost:4040
{"name":"(name-of-pod-leader-here)"}
Benefits
Can be built once and reused by application
developers
Regardless of programming languages.
Work queue
Container interfaces run() and mount() make it fairly straightforward to
implement a generic work queue framework.
Developers only have to build a container that can take input data on the
filesystem, process and give output.
Queue
Scatter/Gather
Commonly used in parallel computing
The root “node” fans the request out to a number of “leaf” nodes to perform computations in
parallel
Each “leaf” returns partial data, and the “root” gathers data into a single response.
Scatter/Gather containers
Questions ?
Related Documents
