public/geek-cookbook
1
0
Fork 0
mirror of https://github.com/funkypenguin/geek-cookbook/ synced 2025-12-13 09:46:23 +00:00
Code Issues Releases Wiki Activity

Fix markdownlint, add Discourse page

Browse Source 
Signed-off-by: David Young <davidy@funkypenguin.co.nz>
This commit is contained in:
David Young
2022-08-23 10:47:09 +12:00
parent 956ebe8c38
commit 45a851df7a
30 changed files with 132 additions and 79 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/kubernetes/cluster/k3s.md
View File

@@ -35,7 +35,6 @@ Some of the "let's-just-get-started" advantages to k3s are:
Strictly, it doesn't matter. I prefer the latest Ubuntu LTS server version, but that's because I like to standardize my toolset across different clusters / platforms - I find this makes it easier to manage the "cattle" :cow: over time!
## k3s single node setup
If you only want a single-node k3s cluster, then simply run the following to do the deployment:
@@ -157,5 +156,4 @@ Cuddle your beautiful new cluster by running `kubectl cluster-info` [^1] - if th
[^2]: Looking for your k3s logs? Under Ubuntu LTS, run `journalctl -u k3s` to show your logs
[^3]: k3s is not the only "lightweight kubernetes" game in town. Minikube (*virtualization-based*) and mikrok8s (*possibly better for Ubuntu users since it's installed in a "snap" - haha*) are also popular options. One day I'll write a "mikrok8s vs k3s" review, but it doesn't really matter for our cluster operations - as I understand it, microk8s makes HA clustering slightly easire than k3s, but you get slightly less "out-of-the-box" in return, so mikrok8s may be more suitable for experience users / production edge deployments.
--8<-- "recipe-footer.md"

2
docs/kubernetes/deployment/flux/index.md
View File

@@ -8,4 +8,4 @@ In a break from tradition, the flux design is best understood *after* installing
1. [Install](/kubernetes/deployment/flux/install/)
2. [Design](/kubernetes/deployment/flux/design/)
3. [Operate](/kubernetes/deployment/flux/operate/)
3. [Operate](/kubernetes/deployment/flux/operate/)

4
docs/kubernetes/ssl-certificates/wildcard-certificate.md
View File

@@ -16,8 +16,8 @@ This behaviour can be prohibitive, because (a) we don't want to have to request/
To take advantage of the various workarounds available, I find it best to put the certificates into a dedicated namespace, which I name.. `letsencrypt-wildcard-cert`.
!!! question "Why not the cert-manager namespace?"
Because cert-manager is a _controller_, whose job it is to act on resources. I should be able to remove cert-manager entirely (even its namespace) from my cluster, and re-add it, without impacting the resources it acts upon. If the certificates lived in the `cert-manager` namespace, then I wouldn't be able to remove the namespace without also destroying the certificates.
Because cert-manager is a _controller_, whose job it is to act on resources. I should be able to remove cert-manager entirely (even its namespace) from my cluster, and re-add it, without impacting the resources it acts upon. If the certificates lived in the `cert-manager` namespace, then I wouldn't be able to remove the namespace without also destroying the certificates.
Furthermore, we can't deploy ClusterIssuers (a CRD) in the same kustomization which deploys the helmrelease which creates those CRDs in the first place. Flux won't be able to apply the ClusterIssuers until the CRD is created, and so will fail to reconcile.
## Preparation