From baf428ebdba8e00c7539f69157aa72a803d7b323 Mon Sep 17 00:00:00 2001 From: Jerome Petazzoni Date: Sun, 26 May 2019 22:46:24 -0500 Subject: [PATCH] Add note about operator reliability --- slides/k8s/operators-design.md | 24 ++++++++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-) diff --git a/slides/k8s/operators-design.md b/slides/k8s/operators-design.md index 62786d4e..d259303b 100644 --- a/slides/k8s/operators-design.md +++ b/slides/k8s/operators-design.md @@ -4,7 +4,7 @@ - Writing a robust operator is hard -- We will describe the general idea +- We will describe the general idea - We will identify some of the associated challenges @@ -164,7 +164,7 @@ - CoreOS / RedHat Operator Framework [GitHub](https://github.com/operator-framework) - | + | [Blog](https://developers.redhat.com/blog/2018/12/18/introduction-to-the-kubernetes-operator-framework/) | [Intro talk](https://www.youtube.com/watch?v=8k_ayO1VRXE) @@ -302,6 +302,26 @@ --- +## Operator reliability + +- Remember that the operator itself must be resilient + + (e.g.: the node running it can fail) + +- Our operator must be able to restart and recover gracefully + +- Do not store state locally + + (unless we can reconstruct that state when we restart) + +- As indicated earlier, we can use the Kubernetes API to store data: + + - in the custom resources themselves + + - in other resources' annotations + +--- + ## Beyond CRDs - CRDs cannot use custom storage (e.g. for time series data)