public/geek-cookbook
1
0
Fork 0
mirror of https://github.com/funkypenguin/geek-cookbook/ synced 2025-12-13 17:56:26 +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

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

@@ -32,59 +32,55 @@ 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: name: metallb-system
name: metallb-system ```
```
### 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: name: bitnami
name: bitnami namespace: flux-system
namespace: flux-system spec:
spec: interval: 15m
interval: 15m url: https://charts.bitnami.com/bitnami
url: https://charts.bitnami.com/bitnami ```
```
### 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: name: metallb--metallb-system
name: metallb--metallb-system namespace: flux-system
namespace: flux-system spec:
spec: interval: 15m
interval: 15m path: ./metallb-system
path: ./metallb-system prune: true # remove any elements later removed from the above path
prune: true # remove any elements later removed from the above path timeout: 2m # if not set, this defaults to interval duration, which is 1h
timeout: 2m # if not set, this defaults to interval duration, which is 1h sourceRef:
sourceRef: kind: GitRepository
kind: GitRepository name: flux-system
name: flux-system validation: server
validation: server healthChecks:
healthChecks: - apiVersion: apps/v1
- apiVersion: apps/v1 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?"
> Why'd you call the kustomization `metallb--metallb-system`? > Why'd you call the kustomization `metallb--metallb-system`?
@@ -93,52 +89,20 @@ 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: name: metallb-helm-chart-value-overrides
creationTimestamp: null namespace: metallb-system
name: metallb-helm-chart-value-overrides data:
namespace: metallb-system values.yaml: |- # (1)!
data: # <upstream values go here>
values.yaml: |- ```
## @section Global parameters
## 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 1. Paste in the contents of the upstream `values.yaml` here, intended 4 spaces, and then change the values you need as illustrated below.
## @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: []
```
--8<-- "kubernetes-why-full-values-in-configmap.md" --8<-- "kubernetes-why-full-values-in-configmap.md"
@@ -149,32 +113,31 @@ 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: namespace: metallb-system
namespace: metallb-system name: metallb-config
name: metallb-config data:
data: config: |
config: | peers:
peers: - peer-address: 192.168.33.2
- peer-address: 192.168.33.2 peer-asn: 64501
peer-asn: 64501 my-asn: 64500
my-asn: 64500 - peer-address: 192.168.33.4
- peer-address: 192.168.33.4 peer-asn: 64501
peer-asn: 64501 my-asn: 64500
my-asn: 64500
address-pools: address-pools:
- name: default - name: default
protocol: bgp protocol: bgp
avoid-buggy-ips: true avoid-buggy-ips: true
addresses: addresses:
- 192.168.32.0/24 - 192.168.32.0/24
``` ```
!!! question "What does that mean?" !!! question "What does that mean?"
In the config referenced above, I define one pool of addresses (`192.168.32.0/24`) which MetalLB is responsible for allocating to my services. MetalLB will then "advertise" these addresses to my firewalls (`192.168.33.2` and `192.168.33.4`), in an eBGP relationship where the firewalls' ASN is `64501` and MetalLB's ASN is `64500`. Provided I'm using my firewalls as my default gateway (*a VIP*), when I try to access one of the `192.168.32.x` IPs from any subnet connected to my firewalls, the traffic will be routed from the firewall to one of the cluster nodes running the pods selected by that service. In the config referenced above, I define one pool of addresses (`192.168.32.0/24`) which MetalLB is responsible for allocating to my services. MetalLB will then "advertise" these addresses to my firewalls (`192.168.33.2` and `192.168.33.4`), in an eBGP relationship where the firewalls' ASN is `64501` and MetalLB's ASN is `64500`. Provided I'm using my firewalls as my default gateway (*a VIP*), when I try to access one of the `192.168.32.x` IPs from any subnet connected to my firewalls, the traffic will be routed from the firewall to one of the cluster nodes running the pods selected by that service.
@@ -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,32 +162,33 @@ 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: name: metallb
name: metallb namespace: metallb-system
namespace: metallb-system spec:
chart:
spec: spec:
chart: chart: metallb
spec: version: 2.x # (1)!
chart: metallb sourceRef:
version: 2.x kind: HelmRepository
sourceRef: name: bitnami
kind: HelmRepository namespace: flux-system
name: bitnami interval: 15m
namespace: flux-system timeout: 5m
interval: 15m releaseName: metallb
timeout: 5m valuesFrom:
releaseName: metallb - kind: ConfigMap
valuesFrom: name: metallb-helm-chart-value-overrides
- kind: ConfigMap valuesKey: values.yaml # This is the default, but best to be explicit for clarity
name: metallb-helm-chart-value-overrides ```
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"