All bites
The whole library, newest first. Filter by what you are here for, or pick a topic if you already know.
8668 bites
Page 83
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.
Two ways to consume a ConfigMap in a Pod
Inject keys as environment variables (good for a few simple settings), or mount the ConfigMap as a volume of files (good for config files and live updates).
ConfigMap vs Secret
ConfigMaps hold non-sensitive plain config; Secrets hold sensitive data, base64-encoded and treated specially (RBAC, optional encryption at rest).
Ingress resource vs Ingress controller
The Ingress resource is declarative routing rules; the controller is the running proxy (NGINX, etc.) that reads them and serves traffic.
Restricting Pod ingress with a NetworkPolicy
Create a NetworkPolicy with podSelector app=frontend, policyTypes Ingress, and one ingress from-rule matching podSelector role=api-gateway; requires a CNI that enforces policies.
kube-proxy and iptables vs IPVS modes
Kube-proxy watches Services/endpoints and programs node rules so ClusterIP traffic is DNAT'd to a backend Pod; iptables uses sequential rule chains, IPVS uses a hash table with real…
Debugging Service connectivity between Pods
Kubectl get endpoints to check the Service has Pod IPs (selector match); kubectl describe service to verify selector and ports; exec into the frontend to curl the Service DNS name.
Headless Services and direct Pod DNS
Set clusterIP: None so no virtual IP or proxy load balancing; DNS returns individual Pod IPs (A records). Primary use: StatefulSets needing stable per-Pod addressing.
Ingress for host and path routing
Use an Ingress with an Ingress controller for layer-7 host/path routing behind one external IP, instead of one cloud LoadBalancer per service.
Cross-namespace Service DNS resolution
CoreDNS gives each Service a name; cross-namespace you must qualify it as my-service.B.svc.cluster.local (or my-service.B).
ClusterIP vs NodePort vs LoadBalancer
ClusterIP for internal-only access; NodePort opens a port on every node for basic external reach; LoadBalancer provisions a cloud load balancer for production external traffic.
Why Kubernetes Services exist
Pod IPs are ephemeral and change on reschedule; a Service gives a stable virtual IP and DNS name plus load balancing across healthy Pods via label selectors.