Containers & Orchestration
Kubernetes: The Orchestrator, Argued Honestly
Kubernetes is the container orchestrator that became infrastructure's default big-system substrate: deployments, services, ingress, PersistentVolumes, and an API that describes desired state. It is also enormous. The honest article on Kubernetes begins with when not to use it, then covers the real architecture, hosting options (managed vs k3s), and the ops discipline it demands.
Key points
- The core object model is genuinely good: Deployments describe desired replica state, Services give stable networking, ConfigMaps/Secrets separate config, and Ingress reaches the outside; declarative reconciliation (controllers fixing drift) is the architecture that everything else builds upon.
- The operational weight is real: control plane components (API server, etcd, scheduler, controller manager) each need HA and monitoring; etcd backups are the single unglamorous task that decides whether a cluster is recoverable; and upgrade discipline (one minor version per step, canary nodes first) is a standing obligation.
- The managed vs self-managed fork: GKE/EKS/AKS trade control for ops reduction, k3s/microk8s are legitimate mini-distributions for small fleets, and self-managing HA masters remains a large-team project; for a hosting business, k3s on a handful of nodes is often the correct ceiling.
- Storage is where most first clusters hurt: PV/PVC across the storage classes on different clouds differ, hostPath is a footgun, and block-storage-backed classes have real IOPS/rate semantics; plan storage classes and backup strategy (velero-class) before the first stateful workload.
- Networking is its own discipline: CNI choices (flannel, calico, cilium) control overlay vs native routing and egress policy; Ingress (nginx/traefik) plus cert-manager handle TLS; market tools differ on Gateway API maturity; measure before choosing.
- The honest verdict in our containers category: adopt Kubernetes when multi-node scheduling, auto-scaling, and API-driven deployment automation carry the workload; do not k8s a single WordPress server; k3s-class distributions extend the utility zone, but the smallest honest clusters still cost more ops than compose does.
Field note
The client who 'needed Kubernetes' turned out to need exactly four services on two hosts, and k3s brought them a control plane to babysit for the privilege. We migrated them to plain compose stacks and their on-call pager went silent. The best Kubernetes decision is often the one you do not make.
Frequently asked questions
Should our small hosting stack move to Kubernetes?
Probably not: if your workloads are a handful of services across a handful of hosts, compose or Podman-managed stacks are simpler to secure and monitor; the k8s payoff begins with genuinely dynamic scheduling needs or API-driven automation at scale.
GKE, EKS, AKS, or self-managed k3s?
Managed control planes trade control for offloaded upgrades; k3s-class for on-prem and cost ceilings; self-managed full Kubernetes is a specialty project and rarely the right answer for a hosting business profile.
What is the most common operational failure?
etcd goes unbacked up: certificate expiry in the control plane shows up next; treat cluster backup (etcd snapshots or velero) as the first thing deployed after the cluster itself.
How do we secure a cluster sanely?
RBAC least-privilege with real roles per team, network policies that actually segment namespace traffic, image scanning on admission (trivy-class policy hooks), and in-cluster secrets handled via your external secret manager rather than raw YAML.
How Kinetikatech helps with containers & orchestration
Here's the deal: Running software in images instead of installs: Docker, Podman, Portainer, and Kubernetes, with the image hygiene, daemon security, and upgrade discipline that decide whether containers help ops or complicate them. Hand it to our Server Management and Linux Server Security service and it's covered, assessed properly, implemented cleanly, monitored around the clock.