All bites
The whole library, newest first. Filter by what you are here for, or pick a topic if you already know.
4247 bites
Page 41
Helm Subcharts: Composing Applications from Dependencies
Helm subcharts are nested components a parent chart can configure, like a docker-compose for Kubernetes manifests. Use them to bundle dependencies like a database with your app. The footgun: subcharts are sandboxed and cannot access parent values directly.
Helm Hooks: Running Operations During a Release
Helm Hooks are Kubernetes resources that run at specific moments in a release lifecycle. Use them to run a database migration before an app upgrade or to back up data before a deletion. The footgun: a failing hook Job will block and fail the entire.
Argo CD Sync Phases and Waves: Ordering Your Deployments
Argo CD Sync Phases and Waves are a recipe for ordering deployments. Use them for complex apps where a database migration must run pre-sync. The footgun: a single failed resource in a wave halts the entire sync process, making it brittle if overused.

Flux Image Update Automation: Closing the GitOps Loop
Flux's image update automation acts like a bot that watches your container registry. It finds new image tags that match your policies (like semver) and automatically commits the change back to your Git repository, triggering a deployment.
Helm Post-Rendering: Customize Charts Without Forks
Helm post-rendering lets you modify a chart's Kubernetes manifests just before deployment. It's ideal for applying kustomize patches or injecting sidecars without forking a public chart.

Custom Resource Definitions (CRDs): Teach Kubernetes New Tricks
CRDs let you define your own resource types, teaching Kubernetes new nouns like Database or Backup. This is how operators manage complex apps declaratively. The footgun is that a CRD only defines the API; you still need a controller to act on the objects.

The Operator Pattern: A Robot SRE for Your App
The Operator pattern adds a custom, automated "robot SRE" to your Kubernetes cluster. It encodes human operational knowledge for a specific application, like a database, into software that handles complex tasks like upgrades, backups, and failovers…

kubectl Treats Custom Resources Like Native Ones
kubectl interacts with Custom Resources (CRs) using the same commands you know for built-in types like Pods. Once a CRD is installed, you can kubectl get, describe, and delete its objects.
Operator SDK: Build Kubernetes Operators Faster
The Operator SDK is a developer toolkit that scaffolds the boilerplate for building, testing, and packaging Kubernetes Operators. Use it to automate complex application lifecycle management, like deploying a database cluster that can self-heal and perform…

Kubernetes Finalizers: The 'Do Not Delete Yet' Lock
A finalizer is a pre-deletion lock. It tells Kubernetes to block an object's deletion until a controller cleans up external resources, like a cloud database or storage bucket.
OLM: Kubernetes' App Store for Operators
OLM is the app store for Kubernetes Operators: it installs, updates, and resolves dependencies declaratively. Use it when managing third-party or custom Operators across clusters.
controller-runtime: The Engine for Kubernetes Operators
Think of controller-runtime as the standard library for writing Kubernetes controllers. It handles the boilerplate of watching resources and reconciling state, forming the foundation for tools like Kubebuilder and Operator SDK.

Kubernetes API Aggregation Layer: Extending the API Server
The API Aggregation Layer bolts custom API servers onto the main Kubernetes API, with kube-apiserver acting as a proxy. This powers features like the metrics server (kubectl top) and enables complex extensions.
Control Plane vs. Data Plane: The Brain and the Brawn
Think of a system as having a brain and a body. The Control Plane is the brain, making decisions and setting rules. The Data Plane is the body, executing those rules on actual data or traffic, like in a service mesh's network of proxies.

The Sidecar Pattern: Your App's Helper Container
The Sidecar pattern attaches a helper container to your main application, like a sidecar on a motorcycle. It handles peripheral tasks like logging or networking, letting you add features without changing the app's code.

Service Mesh Ingress: The Doorkeeper for Your Mesh
A Service Mesh Ingress Gateway is the dedicated entry point for external traffic into your mesh. It lets you apply advanced routing, security, and observability policies at the boundary, like TLS termination or traffic splitting.
SPIFFE: Cryptographic Identity for Services
SPIFFE gives every service a cryptographic passport instead of a static secret. It's used in zero-trust networks for services to authenticate each other, like in a Kubernetes service mesh.

Mutual TLS (mTLS): When Services Need to Trust Each Other
mTLS is a two-way ID check for services. Both parties exchange certificates to prove their identity before communicating. Service meshes like Istio use it to secure traffic between microservices.

Traffic Splitting: Route Live Traffic Between Service Versions
Traffic splitting directs percentages of live user traffic to different versions of a service. It's key for canary releases, letting you test new code on a small user group before a full rollout.

Content-Based Routing: Directing Traffic by Request Details
Content-based routing is a smart traffic cop for your services. It inspects request headers or URIs to direct traffic, enabling canary releases or A/B tests. The footgun is rule order: a broad rule placed first can shadow specific rules below it.