mirror of
https://github.com/jpetazzo/container.training.git
synced 2026-07-19 12:59:24 +00:00
121 lines
3.3 KiB
Markdown
121 lines
3.3 KiB
Markdown
# SwarmKit
|
|
|
|
- [SwarmKit](https://github.com/docker/swarmkit) is an open source
|
|
toolkit to build multi-node systems
|
|
|
|
- It is a reusable library, like libcontainer, libnetwork, vpnkit ...
|
|
|
|
- It is a plumbing part of the Docker ecosystem
|
|
|
|
--
|
|
|
|
.footnote[.emoji[🐳] Did you know that кит means "whale" in Russian?]
|
|
|
|
---
|
|
|
|
## SwarmKit features
|
|
|
|
- Highly-available, distributed store based on [Raft](
|
|
https://en.wikipedia.org/wiki/Raft_%28computer_science%29)
|
|
<br/>(avoids depending on an external store: easier to deploy; higher performance)
|
|
|
|
- Dynamic reconfiguration of Raft without interrupting cluster operations
|
|
|
|
- *Services* managed with a *declarative API*
|
|
<br/>(implementing *desired state* and *reconciliation loop*)
|
|
|
|
- Integration with overlay networks and load balancing
|
|
|
|
- Strong emphasis on security:
|
|
|
|
- automatic TLS keying and signing; automatic cert rotation
|
|
- full encryption of the data plane; automatic key rotation
|
|
- least privilege architecture (single-node compromise ≠ cluster compromise)
|
|
- on-disk encryption with optional passphrase
|
|
|
|
---
|
|
|
|
class: extra-details
|
|
|
|
## Where is the key/value store?
|
|
|
|
- Many orchestration systems use a key/value store backed by a consensus algorithm
|
|
<br/>
|
|
(k8s→etcd→Raft, mesos→zookeeper→ZAB, etc.)
|
|
|
|
- SwarmKit implements the Raft algorithm directly
|
|
<br/>
|
|
(Nomad is similar; thanks [@cbednarski](https://twitter.com/@cbednarski),
|
|
[@diptanu](https://twitter.com/diptanu) and others for pointing it out!)
|
|
|
|
- Analogy courtesy of [@aluzzardi](https://twitter.com/aluzzardi):
|
|
|
|
*It's like B-Trees and RDBMS. They are different layers, often
|
|
associated. But you don't need to bring up a full SQL server when
|
|
all you need is to index some data.*
|
|
|
|
- As a result, the orchestrator has direct access to the data
|
|
<br/>
|
|
(the main copy of the data is stored in the orchestrator's memory)
|
|
|
|
- Simpler, easier to deploy and operate; also faster
|
|
|
|
---
|
|
|
|
## SwarmKit concepts (1/2)
|
|
|
|
- A *cluster* will be at least one *node* (preferably more)
|
|
|
|
- A *node* can be a *manager* or a *worker*
|
|
|
|
- A *manager* actively takes part in the Raft consensus, and keeps the Raft log
|
|
|
|
- You can talk to a *manager* using the SwarmKit API
|
|
|
|
- One *manager* is elected as the *leader*; other managers merely forward requests to it
|
|
|
|
- The *workers* get their instructions from the *managers*
|
|
|
|
- Both *workers* and *managers* can run containers
|
|
|
|
---
|
|
|
|
## Illustration
|
|
|
|
On the next slide:
|
|
|
|
- whales = nodes (workers and managers)
|
|
|
|
- monkeys = managers
|
|
|
|
- purple monkey = leader
|
|
|
|
- grey monkeys = followers
|
|
|
|
- dotted triangle = raft protocol
|
|
|
|
---
|
|
|
|
class: pic
|
|
|
|
|
|
|
|
---
|
|
|
|
## SwarmKit concepts (2/2)
|
|
|
|
- The *managers* expose the SwarmKit API
|
|
|
|
- Using the API, you can indicate that you want to run a *service*
|
|
|
|
- A *service* is specified by its *desired state*: which image, how many instances...
|
|
|
|
- The *leader* uses different subsystems to break down services into *tasks*:
|
|
<br/>orchestrator, scheduler, allocator, dispatcher
|
|
|
|
- A *task* corresponds to a specific container, assigned to a specific *node*
|
|
|
|
- *Nodes* know which *tasks* should be running, and will start or stop containers accordingly (through the Docker Engine API)
|
|
|
|
You can refer to the [NOMENCLATURE](https://github.com/docker/swarmkit/blob/master/design/nomenclature.md) in the SwarmKit repo for more details.
|