61 docs tagged with "kubernetes"

Keepalived and HAProxy configuration and validation.

Older techniques and runbooks that I no longer use move here. They remain available for reference, research, or migration work, but they are not maintained.

How to run Blaster in production. Self-hosted, Vercel, and Kubernetes with GitOps.

Runbook on how the blaster game moves from local development to Kubernetes dev and prod using GitLab, Kaniko, FluxCD and dynamic images.

Structure and contents of the Blaster app Kubernetes manifests under k8s/dev and k8s/prod, including secrets, database, deployment, ingress and SOPS encryption.

High-level overview of how the Blaster demo game is used as a worked example of moving from local development to Kubernetes dev and prod using GitLab, Kaniko and FluxCD.

Repo preparation before k8s deployment.

Repository-wide lint and validate.

This runbook provides end-to-end instructions on how to deploy and manage Cloudflare and the Cloudflare CA issuer onto the cluster using GitOps automation via Flux.

Workload placement controls and examples.

A quick overview of the network ranges, base VM template, and DNS entries used for the development cluster.

Cluster-wide trust.

End-to-end runbook for assessing Blaster exposure to CVE-2025-55182, pinning safe versions, resolving npm ci lockfile drift, hardening the runtime Docker image (Option 1), and verifying dev and prod in-cluster.

Default maximum pods

End to end verification and troubleshooting guide for the Blaster GitOps stack, covering Git, CI, SOPS, Flux, image automation and Kubernetes health.

No inbound firewall ports open.

Mac install (with Homebrew):

Local network DNS records and resolution testing.

Kubernetes clusters can be deployed in many different environments and bootstrapped in several ways. The tables below show a range of host platforms and cluster bootstrap combinations to choose from.

I prefer operating Kubernetes on-premises because it gives me full control over the environment and, with open-source choices, it’s very low-cost to run.

GitOps overview.

Helm helps you manage Kubernetes applications. Helm Charts help you define, install, and upgrade even the most complex Kubernetes applications.

Replace the virtual worker with a physical node to make the development cluster hybrid. This adds realistic CPU, memory, storage, and network performance while keeping the control plane simple and virtualised.

Install and join process for the physical node.

Validation commands and expected outputs.

High level overview of the dual ZITADEL identity providers, why this pattern exists, and how to navigate the identity runbooks.

Use the ZITADEL console for the internal IdP to complete initial admin setup, configure SMTP, connect NAS LDAP, and define Kubernetes-related projects, roles and applications.

Deploy the internal ZITADEL identity provider into the cluster with FluxCD (namespace, Postgres, HelmRelease, ingress) as the foundation for LDAP, OIDC, and SSO runbooks.

Configure the Kubernetes API server, RBAC bindings, and all related ZITADEL console configuration so the internal instance acts as an OIDC identity provider for the cluster.

Protect Kubernetes Dashboard with OAuth2 Proxy using the internal ZITADEL instance, with secrets stored in Git via SOPS and deployed by FluxCD.

Cluster data store overview, checks, and impact.

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

Installation of the Kubernetes dashboard, metrics server, and login process.

Kubernetes notes for Stage 1.

Key variables in all.yml, k8s-cluster.yml, and network settings.

Running the playbooks and validating success.

Prerequisites and repository initialisation.

Common errors and remedies.

MetalLB is a load-balancer implementation for bare-metal Kubernetes clusters, it gives your on-prem or non-cloud Kubernetes environment the same external load-balancing capability that cloud providers (like AWS ELB or GCP Load Balancer) offer automatically.

Process to deploy MetalLB via helm. I will be using BGP with my upstream router and enabling FRR for routing.

Operator with FRR backend (frr-k8s): You can control what’s allowed inbound using the FRRConfiguration CR. That’s where you set toReceive.allowed and (optionally) prefix lists.

Each node name follows the pattern:

Provisioning, mounts, and PVC templates.

High level overview of the Blaster production deployment, with pointers to detailed runbooks for Kubernetes manifests, Flux GitOps, Cloudflare and security hardening.

Runbook on how the blaster game moves from Kubernetes dev to prod using GitLab, Kaniko, FluxCD and dynamic images.

Detailed runbook for the Blaster production Kubernetes manifests, including DB StatefulSet, app Deployment, Ingress, Secrets, ConfigMaps and SOPS encryption.

Production environment on bare-metal infrastructure.

My method to bring a local-first, on-premises Kubernetes cluster to life quickly using the pairing of virtualistion and Kubespray.

Each runbook provides a complete guide, including deployment, validation and testing.

| Purpose | IP Address | Hostname | FQDN/notes |

Vagrant, kubeadm, docker and flannel runbook (archived).

Compatibility, CLI install, backup schedules, and restore.

Virtual environments

Prepare VM template

Add the WordPress app repo into `flux-config` by defining the namespace, GitRepository, and Kustomization objects, then reconcile and verify.

High-level overview of the WordPress-on-Kubernetes GitOps workflow (repo layout, Flux configuration, restore and ops toolkit).

Archived on high.

Application repository Kubernetes manifests under `k8s/prod`, including SOPS policy, Secrets, MariaDB, WordPress, Ingress, cron, Redis, NetworkPolicies, and Kustomize configuration.

Restore workflow (DB then wp-content), wpcli-shell procedures, manual and Velero backups, post-migration steps, and security hardening notes.

Prerequisites, local tooling verification, Cloudflare portal hardening, and initial GitLab app repository setup for a Flux-managed WordPress deployment.