You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/documentation/getting-started.md
-55Lines changed: 0 additions & 55 deletions
Original file line number
Diff line number
Diff line change
@@ -38,60 +38,5 @@ to the cluster. This is why it was important to set up kubectl up front.
38
38
1. Verify if the operator is up and running. Don't run it locally anymore to avoid conflicts in processing events from
39
39
the cluster's API server.
40
40
41
-
## Controllers
42
-
Controllers are where you implement the business logic of the Operator. An Operator can host multiple Controllers,
43
-
each handling a different type of Custom Resource. In our samples each Operator has a single Controller.
44
41
45
-
[comment]: <>(## Automatic Retries)
46
42
47
-
[comment]: <>(## Running The Operator)
48
-
49
-
[comment]: <>(## Development Tips & Tricks)
50
-
51
-
[comment]: <>(TODO: explain running operator locally against a cluster)
52
-
53
-
[comment]: <>(## Event Processing Details)
54
-
55
-
[comment]: <>(### Handling Finalizers)
56
-
57
-
[comment]: <>(### Managing Consistency)
58
-
59
-
[comment]: <>(### Event Scheduling)
60
-
61
-
[comment]: <>(### Event Dispatching )
62
-
63
-
[comment]: <>(### Generation Awareness)
64
-
65
-
## Dealing with Consistency
66
-
67
-
### Run Single Instance
68
-
69
-
There should be always just one instance of an operator running at a time (think process). If there would be
70
-
two ore more, in general it could lead to concurrency issues. Note that we are also doing optimistic locking when we update a resource.
71
-
In this way the operator is not highly available. However for operators this is not necessarily an issue,
72
-
if the operator just gets restarted after it went down.
73
-
74
-
### At Least Once
75
-
76
-
To implement controller logic, we have to override two methods: `createOrUpdateResource` and `deleteResource`.
77
-
These methods are called if a resource is created/changed or marked for deletion. In most cases these methods will be
78
-
called just once, but in some rare cases, it can happen that they are called more then once. In practice this means that the
79
-
implementation needs to be **idempotent**.
80
-
81
-
### Smart Scheduling
82
-
83
-
In our scheduling algorithm we make sure, that no events are processed concurrently for a resource. In addition we provide
84
-
a customizable retry mechanism to deal with temporal errors.
85
-
86
-
### Operator Restarts
87
-
88
-
When an operator is started we got events for every resource (of a type we listen to) already on the cluster. Even if the resource is not changed
89
-
(We use `kubectl get ... --watch` in the background). This can be a huge amount of resources depending on your use case.
90
-
So it could be a good case to just have a status field on the resource which is checked, if there is anything needed to be done.
91
-
92
-
### Deleting a Resource
93
-
94
-
During deletion process we use [Kubernetes finalizers](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#finalizers
95
-
"Kubernetes docs"). This is required, since it can happen that the operator is not running while the delete
96
-
of resource is executed (think `oc delete`). In this case we would not catch the delete event. So we automatically add a
97
-
finalizer first time we update the resource if it's not there.
0 commit comments