Docker &amp; Kubernetes

When to build an Operator vs a Helm chart

Charts handle install-time templating; operators add continuous day-two logic like failover, backups, and scaling for stateful apps.

Adding a required field to a live CRD

Don't make it required immediately; add it optional with a default, introduce a new version with conversion, migrate existing objects, then tighten.

Finalizers for clean external cleanup

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

The reconciliation loop in an Operator

Reconcile compares desired spec to observed state and converges them, idempotently; triggered by resource changes, watched dependents, and periodic resync.

Creating an instance of a custom resource

Write a manifest with apiVersion (group/version), kind, metadata.name, and a spec matching the CRD schema, then kubectl apply -f it.

Core components of a Kubernetes Operator

A CRD defines the type, a controller watches instances via the API server and runs a reconcile loop, encoding operational knowledge to drive real state.

What is a Custom Resource Definition?

A CRD registers a new resource kind so the API server stores and serves it like built-ins; it lets you model domain concepts declaratively.

Helm migration hooks under GitOps

Use a pre-upgrade hook Job with weights and delete policy; the challenge is GitOps tools render statically and reconcile, conflicting with Helm's imperative hook lifecycle.

GitOps repo layout for environment promotion

Shared base plus per-env overlays via Kustomize or value files, promotion by PR moving a pinned version forward, separating app source from config repos.

Argo CD App of Apps pattern

A parent Application whose manifests are themselves Application resources, so syncing one app declaratively manages many.

Managing secrets in a GitOps workflow

Never commit plaintext; encrypt with Sealed Secrets or SOPS, or reference an external store via External Secrets Operator.

How GitOps controllers detect drift and sync

The controller renders desired manifests from Git, diffs them against live cluster objects, marks OutOfSync, then a sync applies the diff to converge.

Helm upgrade and rollback workflow

Helm upgrade creates a new revision; helm history lists revisions; helm rollback reverts to a prior one; --atomic auto-rolls-back on failure.

Override Helm values at install time

Pass custom files with -f or --values, single keys with --set, and know precedence: defaults, then files, then --set.

What is the basic principle of GitOps?

Git holds desired state; a controller continuously reconciles the cluster to match it; benefits are auditability, rollback, and drift correction.

What is a Helm chart?

A chart is a templated, versioned bundle of manifests with a values file; it solves config duplication and reuse across environments.

Head-based vs tail-based trace sampling

Head decides up front (cheap, may miss rare errors); tail decides after the trace completes (catches errors and slow traces but needs buffering).

Diagnose a Prometheus cardinality explosion

Find offenders via TSDB stats and topk count by __name__, identify unbounded labels, then drop or aggregate them with relabeling.

What is distributed tracing in microservices?

A trace is a tree of spans tied by trace and span IDs, propagated via headers like W3C traceparent.