Skip to main content

Kubernetes collection

A practical collection of my Kubernetes notes and real configurations learnt the hard way.

This section is the hub for everything Kubernetes in the Sphere. It points to pages you can use as building blocks for a local-first, on-premises, virtualised/hybrid/bare-metal platform.

What this covers

  • The foundation needed to run a reliable cluster on-premises or in a lab.
  • How to provision clusters with repeatable playbooks and minimal manual steps.
  • Core services I find useful.
  • Backup and recovery that you can test and prove end-to-end.
  • Operational practices to maintain a stable platform.
  • Architecture choices for small, medium, and enterprise-grade shapes.
  • Troubleshooting patterns that help you isolate and fix issues quickly.
  • A reference area with commands, manifests, and links.
  • Runbooks that provide a complete deployment, validation and testing guide.

New to Kubernetes

If you are new to Kubernetes I recommend that you build your first cluster following the three sections below.

  1. Foundation. Install essential tools and plan your environment.
  2. Provisioning. Prepare network, deploy load balancers and use Kubespray to deploy a cluster.
  3. Services. Install helm and use it to deploy the Kubernetes dashboard.
tip

Learn by doing. Stand up a production-style lab cluster with dashboard access in under an hour.

If you already operate clusters in the cloud

  1. Foundation. Map cloud provided components to on-premises components such as internal CAs, routing, and storage.
  2. Services. Standardise on one container network interface (CNI) and one ingress across sites.
  3. Architecture. Select an architecture within your constraints and desired growth.

If you run a small business or a solo practice

What application makes sense for you to self-host on-premises?

  1. Provisioning to start small with a simple, reproducible build.
  2. Services to keep only what you need for your workloads.
  3. Backup and recovery to test restores on a schedule.
  4. Operations to use short, dependable routines that fit into your available time.

Before you begin

  • You can use virtualisation, a spare workstation, or a small server as a lab.
  • Basic command-line experience will help, but it is not required.
  • Know your network ranges and a plan for name resolution.
  • Decide how you will handle certificates for internal services.
  • Set aside time to test a full restore.
warning

A backup that has not been restored is a hope, not a plan.


Principles I use here

  • Keep dependencies to a minimum and prefer local first.
  • One container network interface and one ingress across sites.
  • GitOps for every add-on and every application.
  • Local registry and chart mirrors for control and resilience.
  • Clear service level objectives for API, DNS, and ingress, with automated checks.
  • Backups automated and restore tests proven end-to-end.

What “good” looks like

  • A clean cluster build from a single playbook.
  • Services installed in a predictable way, tracked in Git.
  • Cluster certificates issued from an internal CA and renewed automatically.
  • Domain certificates issued from an external provider and renewed manually.
  • Monitoring and logs that quickly show cluster health.
  • A restore you have run and timed, with notes on what to improve.

Terms used throughout this section

  • API. The Kubernetes API server endpoint.
  • DNS. Name resolution used by your cluster and services.
  • Container network interface (CNI). The plugin that provides pod networking.
  • Ingress. The entry point for HTTP and HTTPS traffic into the cluster.
  • Service level objective. A target for availability or latency that you measure and review.
  • Control plane. The components that run the cluster.
  • Node. A machine that runs workloads.
  • Namespace. A way to group related objects for isolation and access control.

Out of scope

  • Exam preparation or certification tracks.
  • A full tour of every feature in Kubernetes.
  • Cloud-specific managed services that remove on-premises responsibilities.
note

You can still use a cloud lab if you want to practise, but the focus is on local-first and on-premises builds.