From 3a87183a66685049c334be3b9ee1468c3628c175 Mon Sep 17 00:00:00 2001 From: Jerome Petazzoni Date: Sun, 26 May 2019 22:39:11 -0500 Subject: [PATCH] Add bottom-us vs top-down approaches Bottom-us is inspired by the Zalando ES operator --- slides/k8s/operators-design.md | 42 ++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/slides/k8s/operators-design.md b/slides/k8s/operators-design.md index 0e5e6704..62786d4e 100644 --- a/slides/k8s/operators-design.md +++ b/slides/k8s/operators-design.md @@ -12,6 +12,32 @@ --- +## Top-down vs. bottom-up + +- Both approaches are possible + +- Let's see what they entail, and their respective pros and cons + +--- + +## Top-down approach + +- Start with high-level design (see next slide) + +- Pros: + + - can yield cleaner design that will be more robust + +- Cons: + + - must be able to anticipate all the events that might happen + + - design will be better only to the extend of what we anticipated + + - hard to anticipate if we don't have production experience + +--- + ## High-level design - What are we solving? @@ -56,6 +82,22 @@ --- +## Bottom-up approach + +- Start with existing Kubernetes resources (Deployment, Stateful Set...) + +- Run the system in production + +- Add scripts, automation, to facilitate day-to-day operations + +- Turn the scripts into an operator + +- Pros: simpler to get started; reflects actual use-cases + +- Cons: can result in convoluted designs requiring extensive refactor + +--- + ## General idea - Our operator will watch its CRDs *and associated resources*