public/geek-cookbook
1
0
Fork 0
mirror of https://github.com/funkypenguin/geek-cookbook/ synced 2025-12-14 10:16:27 +00:00
Code Issues Releases Wiki Activity

Improve formatting on metallb recipe

Browse Source 
Signed-off-by: David Young <davidy@funkypenguin.co.nz>
This commit is contained in:
David Young
2022-11-18 12:48:38 +13:00
parent 7b9e9089b6
commit 791c30a294
1 changed files with 102 additions and 138 deletions
Download Patch File Download Diff File Expand all files Collapse all files

76
docs/kubernetes/loadbalancer/metallb/index.md
View File

@@ -32,10 +32,9 @@ You'll need to make some decisions re IP allocations.
### Namespace ### Namespace
We need a namespace to deploy our HelmRelease and associated ConfigMaps into. Per the [flux design](/kubernetes/deployment/flux/), I create this example yaml in my flux repo at `bootstrap/namespaces/namespace-metallb-system.yaml`: We need a namespace to deploy our HelmRelease and associated ConfigMaps into. Per the [flux design](/kubernetes/deployment/flux/), I create this example yaml in my flux repo:
??? example "Example NameSpace (click to expand)" ```yaml title="/bootstrap/namespaces/namespace-metallb-system.yaml"
```yaml
apiVersion: v1 apiVersion: v1
kind: Namespace kind: Namespace
metadata: metadata:
@@ -44,10 +43,9 @@ We need a namespace to deploy our HelmRelease and associated ConfigMaps into. Pe
### HelmRepository ### HelmRepository
Next, we need to define a HelmRepository (*a repository of helm charts*), to which we'll refer when we create the HelmRelease. We only need to do this once per-repository. In this case, we're using the (*prolific*) [bitnami chart repository](https://github.com/bitnami/charts/tree/master/bitnami), so per the [flux design](/kubernetes/deployment/flux/), I create this example yaml in my flux repo at `bootstrap/helmrepositories/helmrepository-bitnami.yaml`: Next, we need to define a HelmRepository (*a repository of helm charts*), to which we'll refer when we create the HelmRelease. We only need to do this once per-repository. In this case, we're using the (*prolific*) [bitnami chart repository](https://github.com/bitnami/charts/tree/master/bitnami), so per the [flux design](/kubernetes/deployment/flux/), I create this example yaml in my flux repo:
??? example "Example HelmRepository (click to expand)" ```yaml title="/bootstrap/helmrepositories/helmrepository-bitnami.yaml"
```yaml
apiVersion: source.toolkit.fluxcd.io/v1beta1 apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: HelmRepository kind: HelmRepository
metadata: metadata:
@@ -60,10 +58,9 @@ Next, we need to define a HelmRepository (*a repository of helm charts*), to whi
### Kustomization ### Kustomization
Now that the "global" elements of this deployment (*Namespace and HelmRepository*) have been defined, we do some "flux-ception", and go one layer deeper, adding another Kustomization, telling flux to deploy any YAMLs found in the repo at `/metallb-system`. I create this example Kustomization in my flux repo at `bootstrap/kustomizations/kustomization-metallb.yaml`: Now that the "global" elements of this deployment (*Namespace and HelmRepository*) have been defined, we do some "flux-ception", and go one layer deeper, adding another Kustomization, telling flux to deploy any YAMLs found in the repo at `/metallb-system`. I create this example Kustomization in my flux repo:
??? example "Example Kustomization (click to expand)" ```yaml title="/bootstrap/kustomizations/kustomization-metallb.yaml"
```yaml
apiVersion: kustomize.toolkit.fluxcd.io/v1beta1 apiVersion: kustomize.toolkit.fluxcd.io/v1beta1
kind: Kustomization kind: Kustomization
metadata: metadata:
@@ -83,7 +80,6 @@ Now that the "global" elements of this deployment (*Namespace and HelmRepository
kind: Deployment kind: Deployment
name: metallb-controller name: metallb-controller
namespace: metallb-system namespace: metallb-system
``` ```
!!! question "What's with that screwy name?" !!! question "What's with that screwy name?"
@@ -93,53 +89,21 @@ Now that the "global" elements of this deployment (*Namespace and HelmRepository
### ConfigMap (for HelmRelease) ### ConfigMap (for HelmRelease)
Now we're into the metallb-specific YAMLs. First, we create a ConfigMap, containing the entire contents of the helm chart's [values.yaml](https://github.com/bitnami/charts/blob/master/bitnami/metallb/values.yaml). Paste the values into a `values.yaml` key as illustrated below, indented 4 spaces (*since they're "encapsulated" within the ConfigMap YAML*). I create this example yaml in my flux repo at `metallb-system/configmap-metallb-helm-chart-value-overrides.yaml`: Now we're into the metallb-specific YAMLs. First, we create a ConfigMap, containing the entire contents of the helm chart's [values.yaml](https://github.com/bitnami/charts/blob/master/bitnami/metallb/values.yaml). Paste the values into a `values.yaml` key as illustrated below, indented 4 spaces (*since they're "encapsulated" within the ConfigMap YAML*). I create this example yaml in my flux repo at ``:
??? example "Example ConfigMap (click to expand)" ```yaml title="/metallb-system/configmap-metallb-helm-chart-value-overrides.yaml"
```yaml
apiVersion: v1 apiVersion: v1
kind: ConfigMap kind: ConfigMap
metadata: metadata:
creationTimestamp: null
name: metallb-helm-chart-value-overrides name: metallb-helm-chart-value-overrides
namespace: metallb-system namespace: metallb-system
data: data:
values.yaml: |- values.yaml: |- # (1)!
## @section Global parameters # <upstream values go here>
## Global Docker image parameters
## Please, note that this will override the image parameters, including dependencies, configured to use the global value
## Current available global Docker image parameters: imageRegistry, imagePullSecrets and storageClass
## @param global.imageRegistry Global Docker image registry
## @param global.imagePullSecrets Global Docker registry secret names as an array
##
global:
imageRegistry: ""
## E.g.
## imagePullSecrets:
## - myRegistryKeySecretName
<snip>
prometheus:
## Prometheus Operator service monitors
##
serviceMonitor:
## @param speaker.prometheus.serviceMonitor.enabled Enable support for Prometheus Operator
##
enabled: false
## @param speaker.prometheus.serviceMonitor.jobLabel Job label for scrape target
##
jobLabel: "app.kubernetes.io/name"
## @param speaker.prometheus.serviceMonitor.interval Scrape interval. If not set, the Prometheus default scrape interval is used
##
interval: ""
## @param speaker.prometheus.serviceMonitor.metricRelabelings Specify additional relabeling of metrics
##
metricRelabelings: []
## @param speaker.prometheus.serviceMonitor.relabelings Specify general relabeling
##
relabelings: []
``` ```
1. Paste in the contents of the upstream `values.yaml` here, intended 4 spaces, and then change the values you need as illustrated below.
--8<-- "kubernetes-why-full-values-in-configmap.md" --8<-- "kubernetes-why-full-values-in-configmap.md"
Then work your way through the values you pasted, and change any which are specific to your configuration. I'd recommend changing the following: Then work your way through the values you pasted, and change any which are specific to your configuration. I'd recommend changing the following:
@@ -149,10 +113,9 @@ Then work your way through the values you pasted, and change any which are speci
### ConfigMap (for MetalLB) ### ConfigMap (for MetalLB)
Finally, it's time to actually configure MetalLB! As discussed above, I prefer to configure the helm chart to apply config from an existing ConfigMap, so that I isolate my application configuration from my chart configuration (*and make tracking changes easier*). In my setup, I'm using BGP against a pair of pfsense[^1] firewalls, so per the [official docs](https://metallb.universe.tf/configuration/), I use the following configuration, saved in my flux repo as `metallb-system/configmap-metallb-config.yaml`: Finally, it's time to actually configure MetalLB! As discussed above, I prefer to configure the helm chart to apply config from an existing ConfigMap, so that I isolate my application configuration from my chart configuration (*and make tracking changes easier*). In my setup, I'm using BGP against a pair of pfsense[^1] firewalls, so per the [official docs](https://metallb.universe.tf/configuration/), I use the following configuration, saved in my flux repo:
??? example "Example ConfigMap (click to expand)" ```yaml title="metallb-system/configmap-metallb-config.yaml"
```yaml
apiVersion: v1 apiVersion: v1
kind: ConfigMap kind: ConfigMap
metadata: metadata:
@@ -182,7 +145,7 @@ Finally, it's time to actually configure MetalLB! As discussed above, I prefer t
!!! note "Dude, that's too complicated!" !!! note "Dude, that's too complicated!"
There's an easier way, with some limitations. If you configure MetalLB in L2 mode, all you need to do is to define a range of IPs within your existing node subnet, like this: There's an easier way, with some limitations. If you configure MetalLB in L2 mode, all you need to do is to define a range of IPs within your existing node subnet, like this:
```yaml ```yaml title="metallb-system/configmap-metallb-config.yaml"
apiVersion: v1 apiVersion: v1
kind: ConfigMap kind: ConfigMap
metadata: metadata:
@@ -199,10 +162,9 @@ Finally, it's time to actually configure MetalLB! As discussed above, I prefer t
### HelmRelease ### HelmRelease
Lastly, having set the scene above, we define the HelmRelease which will actually deploy MetalLB into the cluster, with the config and extra ConfigMap we defined above. I save this in my flux repo as `metallb-system/helmrelease-metallb.yaml`: Lastly, having set the scene above, we define the HelmRelease which will actually deploy MetalLB into the cluster, with the config and extra ConfigMap we defined above. I save this in my flux repo:
??? example "Example HelmRelease (click to expand)" ```yaml title="/metallb-system/helmrelease-metallb.yaml"
```yaml
apiVersion: helm.toolkit.fluxcd.io/v2beta1 apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease kind: HelmRelease
metadata: metadata:
@@ -212,7 +174,7 @@ Lastly, having set the scene above, we define the HelmRelease which will actuall
chart: chart:
spec: spec:
chart: metallb chart: metallb
version: 2.x version: 2.x # (1)!
sourceRef: sourceRef:
kind: HelmRepository kind: HelmRepository
name: bitnami name: bitnami
@@ -226,6 +188,8 @@ Lastly, having set the scene above, we define the HelmRelease which will actuall
valuesKey: values.yaml # This is the default, but best to be explicit for clarity valuesKey: values.yaml # This is the default, but best to be explicit for clarity
``` ```
1. This recipe was written when the chart was at version 2, it's now at v4.x, which introduces some breaking changes. Stay tuned for an upcoming refresh!
--8<-- "kubernetes-why-not-config-in-helmrelease.md" --8<-- "kubernetes-why-not-config-in-helmrelease.md"
## Deploy MetalLB ## Deploy MetalLB