tezvyn:

Finalizers for clean external cleanup

AI-drafted, machine-checkedSource: interviewintermediate
WHAT IT TESTS

pre-deletion hooks.

OUTLINE

a finalizer is a key blocking deletion; deletion sets deletionTimestamp, the operator does cleanup then removes the finalizer so the object is purged.

WHAT THIS TESTS Whether you understand Kubernetes deletion mechanics and how to hook in cleanup of resources that live outside the cluster.

A GOOD ANSWER COVERS A finalizer is a string entry in an object's metadata.finalizers list that tells the API server not to physically delete the object until that entry is removed. This converts deletion into a two-phase process. When a user deletes the custom resource, the API server does not remove it; instead it stamps metadata.deletionTimestamp and leaves the object present. The operator's reconcile loop detects the non-nil deletionTimestamp, knows it is in teardown, and performs the external cleanup, for example calling the cloud API to delete the managed database. Only after cleanup succeeds does the operator remove its finalizer from the list; the API server then sees an empty finalizer list on a terminating object and completes deletion. Implementation: on first reconcile of a live object, add your finalizer if absent. On reconcile of a terminating object, run cleanup idempotently, and if it fails, requeue and retry so you never drop the finalizer prematurely. This guarantees no orphaned external resources.

COMMON WRONG ANSWERS Doing cleanup in normal reconcile without a finalizer, so deletion races ahead and orphans the database; removing the finalizer before cleanup succeeds; or assuming Kubernetes cleans external resources automatically.

LIKELY FOLLOW-UPS What is a stuck finalizer and how do you recover? Why must cleanup be idempotent? How does deletionTimestamp interact with reconcile? What about ownerReferences cascade?

ONE CONCRETE EXAMPLE Your operator manages an RDS instance via a Database custom resource. On create, reconcile adds the finalizer db.example.com/cleanup. When the user runs kubectl delete, the object gets a deletionTimestamp but stays. Reconcile sees this, calls the AWS API to delete the RDS instance, confirms success, then removes the finalizer. The API server now purges the Database object, leaving no orphaned cloud database.

Read the original → kubernetes.io

Get five bites like this every day.

Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.