In a standard scenario, this knowledge might not be that useful.
However it might be relevant if you design and implement your own Kubernetes Operators.
- You may have noticed, that Kubernetes resources have two mechanisms that kind of keep track a version of the resource -
metadata.resourceVersionandmetadata.generation
Resource Version
- First - optimistic locking
- If you run update, including the resourceVersion, API Server will make sure, that the version matches. If not, it means that it was updated in the meantime, and there is a risk that full update will overwrite data that other update.
- Second - “state of the universe”
- If you call watch will resourceVersion, you will receive changes since that resourceVersion - https://kubernetes.io/docs/reference/using-api/api-concepts/#efficient-detection-of-changes
- Changes from last 5 minutes are preserved by default
- https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-versions
Generation
- The most widespread use of generation is in Conditions API. It’s used to track if Condition is up to date with the “spec” part, so the intended state.
- Conditions API includes “observedGeneration” field, that keeps track of generation that was used to come up with the condition value
- It’s API Server, that is responsible for incrementing the
generationfield.
TODO: Look at https://alenkacz.medium.com/kubernetes-operator-best-practices-implementing-observedgeneration-250728868792, explain the difference between spec and status
- Why needed ?
- Keep track of changes