Compare commits

..

10 commits

Author SHA1 Message Date
jon brookes
3c41835e1a Fix typo in MVK viability header and add link to MVK site; include new diagram for clarity 2025-10-21 16:00:15 +01:00
jon brookes
072e2998ae Revise MVK documentation: replace mermaid diagrams with images, add new sections for single node and three node viability, and enhance the usage slide with additional context. 2025-10-21 15:47:15 +01:00
jon brookes
563e6333dc Revise personal experience section in slides.md for clarity and conciseness 2025-10-17 18:19:24 +01:00
jon brookes
5e79d7efb2 Revise introduction in slides.md to clarify the purpose of Minimal Viable Kubernetes and share personal experiences with Kubernetes deployment. 2025-10-17 17:45:49 +01:00
jon brookes
460c84ac9b Revise MVK documentation: enhance CLI-centric explanations, clarify use cases, and expand introduction with personal experiences and tooling insights. 2025-10-17 16:45:11 +01:00
jon brookes
3d027bd7f7 Update GCE demo link, revise infctl summary, and enhance MVK descriptions 2025-10-16 16:27:02 +01:00
jon brookes
09f36dff16 added gcloud intro
- Created a new script `instalL_asciinema.sh` to automate the installation of asciinema.
- The script detects the operating system and architecture to download the appropriate binary.
- Supports Linux (both musl and GNU) and macOS (Darwin).
- Sets executable permissions for the downloaded binary and verifies the installation by displaying the version.
2025-10-16 10:05:51 +01:00
jon brookes
f3d077e3c4 Add Ingress and Storage test slides with Vagrant instructions 2025-08-27 10:54:58 +01:00
jon brookes
09f01d409f Add new slides for run and diagram with fade-out transitions 2025-08-26 10:07:47 +01:00
jon brookes
af174eaa63 Add usage instructions slide to presentation 2025-08-16 18:42:12 +01:00
55 changed files with 7061 additions and 8817 deletions

2
.gitignore vendored
View file

@ -5,3 +5,5 @@ dist
.vite-inspect
.remote-assets
components.d.ts
*.deleted
vite.config.ts

Binary file not shown.

Before

Width:  |  Height:  |  Size: 737 KiB

After

Width:  |  Height:  |  Size: 483 KiB

Before After
Before After

8763
package-lock.json generated

File diff suppressed because it is too large Load diff

View file

@ -2,12 +2,21 @@
level: 2
---
# Configuration
# `infctl`
Configuration is based on a list of simple JSON objects.
Keep it simple, list of JSON objects.
````md magic-move {lines: true}
```js {1,12|2-10}
```js {1-4}
[
{},
{}
]
```
```js {2-10}
[
{
"name": "...",
@ -62,3 +71,26 @@ Configuration is based on a list of simple JSON objects.
```
````
<!--
`infctl` uses a simple JSON list of objects to represent a pipeline of tasks
each object
* has a name
* calls a function
* an retry failed steps
* optionally exits on failure
a function may be internally implemented in `infctl`
there is currently only the one: `K8sNamespaceExists`
more may be added but this is for reference at this time and so as to illustrate how this may be implemented for other use cases
the majority of the time `infctl` uses `RunCommand` to execute scripts and executables
additionally, pipeline steps may be repeated so as to allow for some steps to be re-tried until complete or fail over time
-->

34
pages/diagram-3node.md Normal file
View file

@ -0,0 +1,34 @@
---
level: 2
---
# MVK for pre-production
The **V** in MVK is for *viable*, so why is MVK viable for 3 or more nodes ?
<div class="grid grid-cols-1">
<img src="/k8s-3.drawio.png">
</div>
<!--
why is MVK 'viable' ?
Out of the box K8s examples and some deployments are not useable without other externalities
* Persistent storage - often built in to managed kubernetes cloud platforms
* Ingress - is also provided by cloud providers, K8s does not natively have this
* ETCD is often offered as the 'management plane', again as part of managed kubernetes by cloud providers
K3s does not use k8s traditional 3 node ETCD unless you configure it to do so
MKK's infctl pipelines configure 3 node k3s on all 3 nodes
it also adds Longhorn for persistent storage
ingress is impossible without metallb and some kind of load balancer - traefik being my preference but others could be used, of course
-->

View file

@ -0,0 +1,36 @@
---
level: 2
---
# MVK for development
The **V** in MVK is for *viable*, so why is MVK viable for single 'dev' nodes ?
<div class="grid grid-cols-1">
<img src="/k8s-2.drawio.png">
</div>
<!--
why is MVK 'viable' ?
Out of the box K8s examples and some deployments are not useable without other externalities
* Persistent storage - often built in to managed kubernetes cloud platforms
* Ingress - is also provided by cloud providers, K8s does not natively have this
* ETCD is often offered as the 'management plane', again as part of managed kubernetes by cloud providers
K3s does not use k8s traditional 3 node ETCD unless you configure it to do so
MKK's infctl pipelines configure 3 node k3s on all 3 nodes
it also adds Longhorn for persistent storage
ingress is impossible without metallb and some kind of load balancer - traefik being my preference but others could be used, of course
-->

87
pages/gcloud-single.md Normal file
View file

@ -0,0 +1,87 @@
---
level: 2
---
# GCE
Google Compute Engine
````md magic-move {lines: true}
```bash
# 1. PREREQS
# 2. CONFIGURE
# 3. RUN
```
```bash
# PREREQS
# run pre flight checks ...
#
# we need to run this at least once to ensure we have tooling available ...
```
```bash
# PREREQS
# run pre flight checks ...
cd /home/user/projects/infctl-cli # where we checked out infct-cli to
./gcloud/tf/scripts/pre-flight-checks.sh
```
```bash
# PREREQS
# running pre flight checks ...
./gcloud/tf/scripts/pre-flight-checks.sh
# .....
✅ tofu is installed,...
✅ gcloud is installed,...
✅ kubectl is installed,...
✅ envsubst is installed,...
# .....
✅ Pre-flight checks passed. You are ready to proceed 🙂
```
```bash
# CONFIGURE
[ -f .env ] || cp -v .env.gcloud-example .env
# edit to include
export PROJECT_NAME="the name of your gcp project, often referred to as the project"
export EMAIL="your email address to identify yourself with letsencrypt"
export APP_DOMAIN_NAME="your domain name for the app, e.g., frgdr.some-domain.com"
export INSTALL_FORGEJO="true"
```
```bash
# RUN
LOG_FORMAT=none infctl -f ./gcloud/tf/scripts/build-gcloud-k3s-pipeline-wait-dns.json
```
````
<div v-click>
Lets see a Google Compute Engine install [Demo](https://ascii.headshed.dev/a/jgUbXEHHhv9kmm9A2vfr3m5OU)
</div>
<!--
TBC
....
-->

View file

@ -0,0 +1,31 @@
# Pre release
<div grid="~ cols-2 gap-4">
<div>
[MVK](https://mvk.headshed.dev) is new and evolving
`infctl` is an early release.
Its a snapshot of ideas I've been working on for over 10 years.
I'd like to share it as I code it and use it.
It is open to ideas, comments, contribution and collaboration.
License: [GNU General Public License](https://www.gnu.org/licenses/gpl-3.0.en.html)
# [https://headshed.dev/n25](https://headshed.dev/n25)
</div>
<div>
<img class="mx-auto" alt="qr code for https://headshed.dev/n25/" src="/n25-qr.png">
</div>
</div>
<!--
TBC
-->

View file

@ -1,39 +1,31 @@
# Alpha release
# Pre release
<div grid="~ cols-2 gap-4">
<div>
[MVK](https://mvk.headshed.dev) is new and evolving
`infctl` is an early release.
treat is as 'Alpha'.
Its a sketch of ideas I've been working on for decades.
Its a snapshot of ideas I've been working on for over 10 years.
I'd like to share it as I code it and use it.
Open to ideas, comments, contribution and collaboration.
It is open to ideas, comments, contribution and collaboration.
License: [GNU General Public License](https://www.gnu.org/licenses/gpl-3.0.en.html)
Check out [https://codeberg.org/headshed/infctl-cli](https://codeberg.org/headshed/infctl-cli) for more.
# [https://headshed.dev/n25](https://headshed.dev/n25)
</div>
<div>
<img src="/infctl.png">
<img src="/container_night2_c.jpg">
</div>
</div>
<!--
Presenter note with **bold**, *italic*, and ~~striked~~ text.
Also, HTML elements are valid:
<div class="flex w-full">
<span style="flex-grow: 1;">Left content</span>
<span>Right content</span>
</div>
TBC
-->

53
pages/ingress-test.md Normal file
View file

@ -0,0 +1,53 @@
---
level: 2
---
# Ingress test
... with Vagrant
````md magic-move {lines: true}
```bash {1|2|3|4|5}
vagrant ssh workstation
cd /vagrant/certs/
bash secret.sh
bash copy_secret_to_default.sh
cd $HOME
```
```bash {1|2|3|4}
cd k8s/nginx-test
kubectl apply -f deployment.yaml
kubectl apply -f service.yaml
kubectl apply -f ingress.yaml
```
````
<div v-click>
Lets see an install of metallb and traefic ingress in a [Demo](http://ascii.headshed.dev/a/NwWLIm29tu2eU5Ah7H4GyU6Vg)
</div>
<div v-click>
The creation of a valid certificate is handled by [mkcert](https://github.com/FiloSottile/mkcert)
And our workstation already has [dnsmasq](https://thekelleys.org.uk/dnsmasq/doc.html) installed acting as a forwarding DNS and serving the address of our test domain `headshed.it` from earlier
</div>
<!--
TBC
....
-->

38
pages/ingress.md Normal file
View file

@ -0,0 +1,38 @@
---
level: 2
---
# Ingress
... with Vagrant
````md magic-move {lines: true}
```bash {1|2|3}
vagrant ssh workstation
infctl -f pipelines/vagrant-metallb.json
infctl -f pipelines/vagrant-ingress.json
```
````
<div v-click>
Lets see an install of metallb and traefic ingress in a [Demo](https://ascii.headshed.dev/a/lLlJj9Mscia6rPXrp1wB9fBna)
</div>
<!--
TBC
....
-->

View file

@ -1,22 +0,0 @@
# What is Minimal Viable Kubernetes?
MVK is kubernetes for the impatient and impeverished, and consists the following features
- ≥ **CLI** - Living in the terminal, uses [`infctl`](https://mvk.headshed.dev/guides/intro/) command line pipeline
- 🧑‍💻 **Startup Friendly** - Getting a functional stack quickly and simply
- 🤹 **Automated** - Focus on an infrastructure as code
- 🎥 **Repeatable** - Repeatable, re-useable and predictable.
- 📤 **Portable** - Kubernetes that can run anywhere
- 🛠 **Hackable** - Simple to modify, extend and prototype
<br>
<br>
<div mt-20 v-click>
See a [Demo that goes terribly wrong](http://ascii.headshed.dev/a/f8S5WqD7OyCzkTcoPZhCSnefX?t=30)
Then see [one that goes right](http://ascii.headshed.dev/a/jSYcC7p4pbkMdf1B07rQOiIa0?t=01:30)
</div>

51
pages/intro01.md Normal file
View file

@ -0,0 +1,51 @@
# Minimal Viable Kubernetes
What is MVK ?
### ≥ CLI friendly, CLI first
<!--
I work at the command line.
It is efficient and powerfull.
I find that I can get the most done with tooling that is cli first and can automate everything that is.
Infrastrructure used to be manually crafted.
Now it is encoded and version controlled, recoverable, repeatable, maintainable
can be reviewed and quality controlled
MVK as self hosted is more portable across environments
cloud to cloud ( ish ) but mostly
dev => test => pre-prod => prod, all can use similar pipelines and plugins
MVK started out as a means of sharing knowlege and providing a kick-start into k8s
microlearnings
templates
avoids using cloud based servies that cannot port to other providers
k8s has many of these
storage
ingress
load balancing
...
more and more
-->

26
pages/intro02.md Normal file
View file

@ -0,0 +1,26 @@
# Minimal Viable Kubernetes
What is MVK ?
### ≥ CLI friendly, CLI first
### 🤹 Promotes Infrastructure as code
<!--
We live in the command line, so MVK is CLI centric. It uses a very simple command line tool, `infctl` to marshal scripts and commands in a stop by step manner, similar to the way we right pipelines in the cloud.
It is simple to get started, so that startups and the impatient can become productive with Kubernetes quickly, without having to rely on managed offerings and in order to self host easily.
Each pipeline use steps of code that are repeatable, idempotent and using infrastructure as code.
Kubernetes *can run anywhere* so MVK takes that principle and applies this to the self hosted approach making it possible to have the same setup on-prem and in the cloud
It is important to keep things simple so as to be understandable, maintainable and easy to change and extend to our own use cases
-->

26
pages/intro03.md Normal file
View file

@ -0,0 +1,26 @@
# Minimal Viable Kubernetes
What is MVK ?
### ≥ CLI friendly, CLI first
### 🤹 Promotes Infrastructure as code
### 📤 **Portable** on-prem, cloud
<!--
We live in the command line, so MVK is CLI centric. It uses a very simple command line tool, `infctl` to marshal scripts and commands in a stop by step manner, similar to the way we right pipelines in the cloud.
It is simple to get started, so that startups and the impatient can become productive with Kubernetes quickly, without having to rely on managed offerings and in order to self host easily.
Each pipeline use steps of code that are repeatable, idempotent and using infrastructure as code.
Kubernetes *can run anywhere* so MVK takes that principle and applies this to the self hosted approach making it possible to have the same setup on-prem and in the cloud
It is important to keep things simple so as to be understandable, maintainable and easy to change and extend to our own use cases
-->

27
pages/intro04.md Normal file
View file

@ -0,0 +1,27 @@
# Minimal Viable Kubernetes
What is MVK ?
### ≥ CLI friendly, CLI first
### 🤹 Promotes Infrastructure as code
### 📤 **Portable** on-prem, cloud
### 🧐 Fosters curiosity
<!--
We live in the command line, so MVK is CLI centric. It uses a very simple command line tool, `infctl` to marshal scripts and commands in a stop by step manner, similar to the way we right pipelines in the cloud.
It is simple to get started, so that startups and the impatient can become productive with Kubernetes quickly, without having to rely on managed offerings and in order to self host easily.
Each pipeline use steps of code that are repeatable, idempotent and using infrastructure as code.
Kubernetes *can run anywhere* so MVK takes that principle and applies this to the self hosted approach making it possible to have the same setup on-prem and in the cloud
It is important to keep things simple so as to be understandable, maintainable and easy to change and extend to our own use cases
-->

29
pages/intro05.md Normal file
View file

@ -0,0 +1,29 @@
# Minimal Viable Kubernetes
What is MVK ?
### ≥ CLI friendly, CLI first
### 🤹 Promotes Infrastructure as code
### 📤 **Portable** on-prem, cloud
### 🧐 Fosters curiosity
### 🔒 Avoids lock-in
<!--
We live in the command line, so MVK is CLI centric. It uses a very simple command line tool, `infctl` to marshal scripts and commands in a stop by step manner, similar to the way we right pipelines in the cloud.
It is simple to get started, so that startups and the impatient can become productive with Kubernetes quickly, without having to rely on managed offerings and in order to self host easily.
Each pipeline use steps of code that are repeatable, idempotent and using infrastructure as code.
Kubernetes *can run anywhere* so MVK takes that principle and applies this to the self hosted approach making it possible to have the same setup on-prem and in the cloud
It is important to keep things simple so as to be understandable, maintainable and easy to change and extend to our own use cases
-->

38
pages/make-it-work.md Normal file
View file

@ -0,0 +1,38 @@
---
level: 2
---
# MVK Viability
[mvk](https://mvk.headshed.dev)
<div class="grid grid-cols-1">
<div class="flex justify-center">
<img src="/k8s-2.drawio.png">
</div>
</div>
<!--
why is MVK 'viable' ?
Out of the box K8s examples and some deployments are not useable without other externalities
* Persistent storage - often built in to managed kubernetes cloud platforms
* Ingress - is also provided by cloud providers, K8s does not natively have this
* ETCD is often offered as the 'management plane', again as part of managed kubernetes by cloud providers
K3s does not use k8s traditional 3 node ETCD unless you configure it to do so
MKK's infctl pipelines configure 3 node k3s on all 3 nodes
it also adds Longhorn for persistent storage
ingress is impossible without metallb and some kind of load balancer - traefik being my preference but others could be used, of course
-->

38
pages/out-the-box-node.md Normal file
View file

@ -0,0 +1,38 @@
---
level: 2
---
# K8s Viablility
Is K8s out of the box, self-hosted, viable ?
<div class="grid grid-cols-1">
<div class="flex justify-center">
<img src="/k8s-1.drawio.png">
</div>
</div>
<!--
why is MVK 'viable' ?
Out of the box K8s examples and some deployments are not useable without other externalities
* Persistent storage - often built in to managed kubernetes cloud platforms
* Ingress - is also provided by cloud providers, K8s does not natively have this
* ETCD is often offered as the 'management plane', again as part of managed kubernetes by cloud providers
K3s does not use k8s traditional 3 node ETCD unless you configure it to do so
MKK's infctl pipelines configure 3 node k3s on all 3 nodes
it also adds Longhorn for persistent storage
ingress is impossible without metallb and some kind of load balancer - traefik being my preference but others could be used, of course
-->

View file

@ -2,9 +2,9 @@
level: 2
---
# Plugins
# RunCommand plugins
Plugins are any script or executable that print output and exit with a number.
Plugins are any script or executable that print output and exit with a system code of 0 (OK) or greater (error).
````md magic-move {lines: true}
```bash
@ -28,3 +28,21 @@ exit 1
````
<!--
RunCommand plugins are scripts or executables that do two things
1. print some output that can be seen and logged
2. exit with a system code
The example is of a bash script but it could be any scripting language that can do the same.
It could be a compiled program, so long as it also outputs logging information to the terminal and exits with a system code of [0|1 or greater]
Long running scripts or commands are expected
exiting with 1 or greater will signify a failure of some kind
-->

98
pages/run-slide.md Normal file
View file

@ -0,0 +1,98 @@
---
level: 2
---
# Getting Started
... with Vagrant
````md magic-move {lines: true}
```bash
cd ~/projects
git clone https://codeberg.org/headshed/infctl-cli.git
```
```bash
cd infctl-cli/vagrant/dev/ubuntu
pwd
/home/user/projects/infctl-cli/vagrant/dev/ubuntu
```
```bash
vagrant up
Bringing machine 'vm1' up with 'virtualbox' provider...
Bringing machine 'vm2' up with 'virtualbox' provider...
Bringing machine 'vm3' up with 'virtualbox' provider...
Bringing machine 'workstation' up with 'virtualbox' provider...
==> vm1: Checking if box 'ubuntu/jammy64' version '20241002.0.0' is up to date...
==> vm1: Clearing any previously set network interfaces...
==> vm1: Available bridged network interfaces:
1) wlp0s20f3
2) docker0
3) br-9ebcfa7b8ec0
4) br-b036d14629a8
5) veth9ae7cf3
==> vm1: When choosing an interface, it is usually the one that is
==> vm1: being used to connect to the internet.
==> vm1:
vm1: Which interface should the network bridge to?
```
```bash
cd ../../..
export LOG_FORMAT=none
export VAGRANT_BRIDGE=wlp0s20f3
infctl -f pipelines/dev/vagrant-k3s.json
🔄 Running step: Create Vagrant nodes
🐞 Running command: ./scripts/install_vagrant_nodes.sh
```
````
<div v-click>
Lets see what this looks like for real in a [Demo](http://ascii.headshed.dev/a/ISIOKVA1AmckG2muwOMUOG4z5)
</div>
<div v-click>
Lets [try again](http://ascii.headshed.dev/a/bUzNNojNjkxytfDT6cRqhSVwN)
</div>
<!--
Let's see how to get started with vagrant
We use Vagrant to stand up a cluster of 3 nodes and a workstation locally
Vagrant by default uses Virtualbox which works across Windows, Linux and Mac
Git cloning the `infctl-cli` repository gets us the starter files
changing to the vagrant folder we can use `vagrant up` to see what would happen **without** `infctl`
we see the first gotcha in any automation process - where the tooling does not know what to do and asks the user for input
This in IaC is an epic fail and we need to copy the name of the interface we want to use for the external network in our test case and export it as an environment variable
export VAGRANT_BRIDGE=wlp0s20f3
sets to a device on the example system
which allows us now to run `infctl` with a deployment file
lets see what this looks like for real
....
-->

47
pages/storage.md Normal file
View file

@ -0,0 +1,47 @@
---
level: 2
---
# Storage
... with Vagrant
````md magic-move {lines: true}
```bash
cd infctl-cli/vagrant/dev/ubuntu
pwd
/home/user/projects/infctl-cli/vagrant/dev/ubuntu
```
```bash
vagrant ssh workstation
```
```bash
export LOG_FORMAT=none
infctl -f pipelines/vagrant-longhorn.json
...
```
````
<div v-click>
Lets see a longhorn install [Demo](https://ascii.headshed.dev/a/qslfF9KTMj69zcSwzD6xm1uZ7)
</div>
<!--
TBC
....
-->

36
pages/three-node-happy.md Normal file
View file

@ -0,0 +1,36 @@
---
level: 2
---
# MVK for pre-production
### MVK, three node, production
<div class="grid grid-cols-1">
<div class="flex justify-center">
<img src="/k8s-3.drawio.png" alt="3-node Kubernetes diagram">
</div>
</div>
<!--
why is MVK 'viable' ?
Out of the box K8s examples and some deployments are not useable without other externalities
* Persistent storage - often built in to managed kubernetes cloud platforms
* Ingress - is also provided by cloud providers, K8s does not natively have this
* ETCD is often offered as the 'management plane', again as part of managed kubernetes by cloud providers
K3s does not use k8s traditional 3 node ETCD unless you configure it to do so
MKK's infctl pipelines configure 3 node k3s on all 3 nodes
it also adds Longhorn for persistent storage
ingress is impossible without metallb and some kind of load balancer - traefik being my preference but others could be used, of course
-->

72
pages/usage-slide.md Normal file
View file

@ -0,0 +1,72 @@
---
level: 2
---
# Usage
`infctl` has a single, compulsory parameter `[-f|--deployment-file]` and an optional environment variable `LOG_FORMAT` which may be ["none"|"basic"|""]
there must be a valid `deployment-file`
`LOG_FORMAT` is used to switch structured log to be off, "none", 2 field with "basic" or JSON ( the default )
````md magic-move {lines: true}
```bash
export LOG_FORMAT=none
infctl
no config specified with --deployment-file=<path_to_config_file>
```
```bash
export LOG_FORMAT=none
infctl -f pipelines/dev/vagrant-k3s.json
🔄 Running step: Create Vagrant nodes
🐞 Running command: ./scripts/install_vagrant_nodes.sh
...
```
```bash
export LOG_FORMAT="basic"
infctl -f pipelines/dev/vagrant-k3s.json
level=INFO msg="Project name already exists: hdshd\n"
level=INFO msg="🔄 Running step: Create Vagrant nodes"
...
```
```bash
export LOG_FORMAT=""
infctl -f pipelines/dev/vagrant-k3s.json
{"time":"2025-08-16T18:28:00.412416282+01:00","level":"INFO","msg":"Project name already exists: hdshd\n"}
{"time":"2025-08-16T18:28:00.412511255+01:00","level":"INFO","msg":"🔄 Running step: Create Vagrant nodes"}
...
```
````
[cast](https://ascii.headshed.dev/a/OB2jSE47d1HTz2d5vFhJhIKAl)
<!--
`infctl` has only one compulsory parameter
-f | --deployment-file
another, entirely optional environment variable `LOG_FORMAT` sets the degree to which output is structured
none - supresses all structured logging
basic - shows level and standard / error output
default - structures log output as JSON with date timestamp, level and message
the latter is purposed for ingesting logs into other systems that can use these fields for categorizing the data
-->

28
pages/uses01.md Normal file
View file

@ -0,0 +1,28 @@
# Minimal Viable Kubernetes
## Use Cases
### 🏠 Local development
<!--
Development is where everything starts from
logically we use k8s within development to start
packaging containers
testing
security scanning
-->

23
pages/uses02.md Normal file
View file

@ -0,0 +1,23 @@
# Minimal Viable Kubernetes
## Use Cases
### 🏠 Local development
### 🛠️ Integration and smoke testing
<!--
proving we have not broken things with changes between componetnts and apps outisde of our own
-->

23
pages/uses03.md Normal file
View file

@ -0,0 +1,23 @@
# Minimal Viable Kubernetes
## Use Cases
### 🏠 Local development
### 🛠️ Integration and smoke testing
### 🎬 Pre-prod & production
<!--
In pipelines we can deploy production like environments allowing us to try out produciton configurations before going into live
test and pre-prod environmetns can be entirely or in part ephemeral, cutting cost and proving infrastructure as code
-->

26
pages/uses04.md Normal file
View file

@ -0,0 +1,26 @@
# Minimal Viable Kubernetes
## Use Cases
### 🏠 Local development
### 🛠️ Integration and smoke testing
### 🎬 Pre-prod & production
### 💣 Disaster recovery rehearsal
<!--
prodduction can be never upgraded, rather, new productdion can replace old, provin infra as code and migrating to major updates
We are already backing up our data right ?
how can we prove our backups are valid without DR tests, rehearsals ?
we can if we have infra as code
-->

31
pages/why.md Normal file
View file

@ -0,0 +1,31 @@
# Why ?
* 2025 building a minimal k8s for our own hosting
* asked for an intro for techs getting into k8s
* been working with Linux and Unix from SME to large enterprise since before Y2K
* k8s since 2018
<div v-click>
**I want to ...**
➤ bring down the cost of k8s
➤ pass on what I have learnt
</div>
<div v-click>
➤ not pay vercel
</div>
<!--
-->

5912
pnpm-lock.yaml generated Normal file

File diff suppressed because it is too large Load diff

BIN
public/boat-under-water.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 184 KiB

BIN
public/cont13_c.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 150 KiB

BIN
public/cont3_c.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 244 KiB

BIN
public/cont8_c.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 267 KiB

BIN
public/cont_ship3_c.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 205 KiB

BIN
public/cont_ship4_c.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 295 KiB

BIN
public/cont_ship5_c.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 97 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 191 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 348 KiB

BIN
public/containers.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.3 MiB

BIN
public/containers.webp Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 131 KiB

BIN
public/containers2.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 270 KiB

BIN
public/containers3.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.8 MiB

BIN
public/containers3.webp Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 247 KiB

BIN
public/error.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 831 KiB

BIN
public/hi-and-dry.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.2 MiB

View file

Before

Width:  |  Height:  |  Size: 129 KiB

After

Width:  |  Height:  |  Size: 129 KiB

Before After
Before After

BIN
public/k8s-1.drawio.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 26 KiB

BIN
public/k8s-2.drawio.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 40 KiB

BIN
public/k8s-3.drawio.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 57 KiB

View file

Before

Width:  |  Height:  |  Size: 5.9 KiB

After

Width:  |  Height:  |  Size: 5.9 KiB

Before After
Before After

BIN
public/og-image.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 737 KiB

BIN
public/why.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 164 KiB

46
scripts/instalL_asciinema.sh Executable file
View file

@ -0,0 +1,46 @@
#!/usr/bin/env bash
## available versions as of Tue 7 Oct 18:34:05 BST 2025
# https://github.com/asciinema/asciinema/releases/download/v3.0.0/asciinema-aarch64-apple-darwin
# https://github.com/asciinema/asciinema/releases/download/v3.0.0/asciinema-aarch64-unknown-linux-gnu
# https://github.com/asciinema/asciinema/releases/download/v3.0.0/asciinema-x86_64-apple-darwin
# https://github.com/asciinema/asciinema/releases/download/v3.0.0/asciinema-x86_64-unknown-linux-gnu
# https://github.com/asciinema/asciinema/releases/download/v3.0.0/asciinema-x86_64-unknown-linux-musl
VERSION="3.0.0"
LINK="https://github.com/asciinema/asciinema/releases/download/v${VERSION}/asciinema-"
unameOut="$(uname -s)"
archOut="$(uname -m)"
case "${unameOut}" in
Linux)
if ldd --version 2>&1 | grep -q musl; then
platform="x86_64-unknown-linux-musl"
else
platform="x86_64-unknown-linux-gnu"
fi
if [[ "${archOut}" == "aarch64" ]]; then
platform="aarch64-unknown-linux-gnu"
fi
;;
Darwin)
if [[ "${archOut}" == "arm64" ]]; then
platform="aarch64-apple-darwin"
else
platform="x86_64-apple-darwin"
fi
;;
*)
echo "Unsupported platform: ${unameOut} ${archOut}"
exit 1
;;
esac
echo "Detected platform: $platform"
echo "installing asciinema version ${VERSION} for ${platform}"
sudo curl -sL "${LINK}${platform}" -o /usr/local/bin/asciinema
sudo chmod +x /usr/local/bin/asciinema
asciinema --version

151
slides.md
View file

@ -3,7 +3,11 @@
theme: seriph
# random image from a curated Unsplash collection by Anthony
# like them? see https://unsplash.com/collections/94734566/slidev
background: https://cover.sli.dev
# background: https://cover.sli.dev
# background: https://cdn.jsdelivr.net/gh/slidevjs/slidev-covers@main/static/mYBMP8pW4uQ.webp
# background: https://cdn.jsdelivr.net/gh/slidevjs/slidev-covers@main/static/zRkBOOpKRhs.webp
# background: https://cdn.jsdelivr.net/gh/slidevjs/slidev-covers@main/static/3XXSKa4jKaM.webp
background: container_pipeline.jpg
# some information about your slides (markdown enabled)
title: Minimal Viable Kubernetes
info: |
@ -30,7 +34,7 @@ seoMeta:
# Minimal Viable Kubernetes
Kubernetes for the impatient and impoverished
Kubernetes for the impatient and pragmatic
Jon Brookes 2025
@ -49,15 +53,110 @@ Jon Brookes 2025
</a>
</div>
<!-- Hidden image reference to force bundling -->
<img src="/containers.webp" alt="preload" style="display:none;" />
<!--
This is an introduction to Minimal Viable Kubernetes (MVK). What it is, why it is and tooling around it.
why and why now ?
I created it because
* was building a minimal k8s for our own hosting
* asked for an intro for techs getting into k8s
as I've been working with unix, linux and systems since before Y2K and k8s since 2018 I thought I could have something to say
so I wanted to
* use my own knowlege to deliver my own self managed k8s
* bring down the cost of k8s
* pass on what I have learnt
* not pay vercel
-->
---
layout: image-left
image: why.jpg
transition: fade-out
src: ./pages/intro-slide.md
src: ./pages/why.md
---
---
layout: image-right
image: cont3_c.jpg
transition: fade-out
src: ./pages/intro01.md
---
---
layout: image-right
image: cont8_c.jpg
transition: fade-out
src: ./pages/intro02.md
---
---
layout: image-right
image: containers3.png
transition: fade-out
src: ./pages/intro03.md
---
---
layout: image-right
image: containers2.jpg
transition: fade-out
src: ./pages/intro04.md
---
---
layout: image-right
image: boat-under-water.jpg
transition: fade-out
src: ./pages/intro05.md
---
---
layout: image-left
image: cont_ship3_c.jpg
transition: fade-out
src: ./pages/uses01.md
---
---
layout: image-left
image: cont_ship4_c.jpg
transition: fade-out
src: ./pages/uses02.md
---
---
layout: image-left
image: cont_ship5_c.jpg
transition: fade-out
src: ./pages/uses03.md
---
---
layout: image-left
image: hi-and-dry.png
transition: fade-out
src: ./pages/uses04.md
---
<!--
You can have `style` tag in markdown to override the style for the current page.
Learn more: https://sli.dev/features/slide-scope-style
@ -75,10 +174,6 @@ h1 {
}
</style>
<!--
Here is another comment.
-->
---
src: ./pages/config-slide.md
---
@ -90,12 +185,48 @@ src: ./pages/plugins-slide.md
---
transition: fade-out
src: ./pages/infctl-summary.md
src: ./pages/usage-slide.md
---
---
transition: fade-out
src: ./pages/out-the-box-node.md
---
---
transition: fade-out
src: ./pages/make-it-work.md
---
---
transition: fade-out
src: ./pages/gcloud-single.md
---
---
transition: fade-out
src: ./pages/three-node-happy.md
---
---
transition: fade-out
src: ./pages/infctl-summary.md
---
---
transition: fade-out
src: ./pages/infctl-summary-end.md
---
---
layout: center
class: text-center
@ -108,5 +239,3 @@ class: text-center
#### Jon Brookes
[https://headshed.dev/n25/](https://headshed.dev/n25/)
<PoweredBySlidev mt-10 />