Add Ingress and Storage test slides with Vagrant instructions
This commit is contained in:
parent
09f01d409f
commit
f3d077e3c4
19 changed files with 319 additions and 38 deletions
|
|
@ -4,10 +4,19 @@ level: 2
|
|||
|
||||
# Configuration
|
||||
|
||||
Configuration is based on a list of simple JSON objects.
|
||||
Configuration is based on a 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
|
||||
|
||||
-->
|
||||
|
|
@ -4,6 +4,7 @@ level: 2
|
|||
|
||||
# MVK
|
||||
|
||||
The **V** in MVK is for *viable*, so why is MVK viable ?
|
||||
|
||||
<div class="grid grid-cols-1">
|
||||
|
||||
|
|
@ -15,12 +16,12 @@ flowchart LR
|
|||
LH[Longhorn]
|
||||
ING[Ingress]
|
||||
TRA[Traefik]
|
||||
CM[cert-manager]
|
||||
MET[Metallb]
|
||||
ETCD[etcd]
|
||||
KA[keepalived]
|
||||
|
||||
root --> PS --> LH
|
||||
root --> ING --> TRA --> CM
|
||||
root --> ING --> TRA --> MET
|
||||
root --> ETCD --> KA
|
||||
|
||||
classDef default fill:transparent,color:#fff,stroke:#888
|
||||
|
|
@ -35,3 +36,23 @@ We have in the build so far etcd and keepalived
|
|||
there is still no persistent volume management or ingress
|
||||
|
||||
</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
|
||||
|
||||
-->
|
||||
|
|
@ -29,11 +29,5 @@ Check out [https://codeberg.org/headshed/infctl-cli](https://codeberg.org/headsh
|
|||
</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
53
pages/ingress-test.md
Normal 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
38
pages/ingress.md
Normal 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
|
||||
|
||||
|
||||
|
||||
....
|
||||
|
||||
-->
|
||||
|
|
@ -1,22 +1,30 @@
|
|||
# What is Minimal Viable Kubernetes?
|
||||
# Minimal Viable Kubernetes?
|
||||
|
||||
MVK is kubernetes for the impatient and impeverished, and consists the following features
|
||||
What is MVK ?
|
||||
|
||||
- ≥ **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>
|
||||
≥ **CLI first** uses [`infctl`](https://mvk.headshed.dev/infctl/quick-start/)
|
||||
|
||||
🧑💻 **Startup Ready** functional simply
|
||||
|
||||
🤹 **Automated** infrastructure as code
|
||||
|
||||
🎥 **Repeatable** re-useable and predictable.
|
||||
|
||||
📤 **Portable** kubernetes that can run anywhere
|
||||
|
||||
🛠 **Hackable** simple to modify & extend
|
||||
|
||||
|
||||
<div mt-20 v-click>
|
||||
<!--
|
||||
|
||||
See a [Demo that goes terribly wrong](http://ascii.headshed.dev/a/f8S5WqD7OyCzkTcoPZhCSnefX?t=30)
|
||||
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.
|
||||
|
||||
Then see [one that goes right](http://ascii.headshed.dev/a/jSYcC7p4pbkMdf1B07rQOiIa0?t=01:30)
|
||||
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.
|
||||
|
||||
</div>
|
||||
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
|
||||
|
||||
-->
|
||||
|
|
@ -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
|
||||
|
||||
|
||||
-->
|
||||
|
|
@ -2,9 +2,10 @@
|
|||
level: 2
|
||||
---
|
||||
|
||||
# RUN
|
||||
# Getting Started
|
||||
|
||||
... with Vagrant
|
||||
|
||||
So what does `infctl` look like then ...
|
||||
|
||||
````md magic-move {lines: true}
|
||||
|
||||
|
|
@ -57,7 +58,7 @@ infctl -f pipelines/dev/vagrant-k3s.json
|
|||
````
|
||||
<div v-click>
|
||||
|
||||
Here is a [Demo](http://ascii.headshed.dev/a/ISIOKVA1AmckG2muwOMUOG4z5)
|
||||
Lets see what this looks like for real in a [Demo](http://ascii.headshed.dev/a/ISIOKVA1AmckG2muwOMUOG4z5)
|
||||
|
||||
</div>
|
||||
|
||||
|
|
@ -66,3 +67,32 @@ Here is a [Demo](http://ascii.headshed.dev/a/ISIOKVA1AmckG2muwOMUOG4z5)
|
|||
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
47
pages/storage.md
Normal 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
|
||||
|
||||
....
|
||||
|
||||
-->
|
||||
|
|
@ -2,7 +2,7 @@
|
|||
level: 2
|
||||
---
|
||||
|
||||
# USAGE
|
||||
# Usage
|
||||
|
||||
`infctl` has a single, compulsory parameter `[-f|--deployment-file]` and an optional environment variable `LOG_FORMAT` which may be ["none"|"basic"|""]
|
||||
|
||||
|
|
@ -49,3 +49,21 @@ infctl -f pipelines/dev/vagrant-k3s.json
|
|||
|
||||
|
||||
````
|
||||
|
||||
<!--
|
||||
|
||||
`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
|
||||
|
||||
-->
|
||||
Loading…
Add table
Add a link
Reference in a new issue