MetalLB offers a network load balancer implementation which workes on "bare metal" (as opposed to a cloud provider).

This is a companion discussion topic for the original entry at

Wondering if anyone is running into this issue when trying to deploy:

✗ HelmRelease reconciliation failed: unable to read values from key 'values.yaml' in ConfigMap 'metallb-system/metallb-helm-chart-value-overrides': error converting YAML to JSON: yaml: line 15: could not find expected ':'

I’ve tried several different YAML validation tools and techniques to resolve this error but I always continue to run into this. Can not figure out why (also still learning Flux so not everything is obvious to me at the moment).

Nevermind, figured out it was a tab issue.

I keep stumbling upon the error:

Kustomization/flux-system/metallb–metallb-system dry-run failed: failed to create typed patch object (flux-system/metallb–metallb-system;, Kind=Kustomization): .spec.validation: field not declared in schema

What am I missing?

Aah, this is due to a deprecation of the old Flux CRDs. I’ll update the recipe shortly - the fix is to remove the validation: server line from the Kustomization.

And the recipe’s now up-to-date! :+1:

Thank you for sharing this great article! I like your explanations and I feel I learn a lot.

However, I am getting this error message that I can not figure out how to solve:

✗ Kustomization reconciliation failed: IPAddressPool/metallb-system/metallb-pool dry-run failed: failed to get API group resources: unable to retrieve the complete list of server APIs: the server could not find the requested resource

I hope you can point me to the reason why the kustomization are failing.

Br Jesper

Hey @jespernohr!

Flux is complaining that it can’t create MetalLB’s custom resources, because the CRDs don’t exist yet, because the helmrelease hasn’t installed yet.

Check this section in the recipe : MetalLB - Kubernetes Bare-Metal Loadbalancing |・∀・

Essentially you’ll want to end up with 2 directories at the root of your repo…

  1. metallb - HelmRelease goes in here
  2. metallb-config - CRs go in here

And you define 2 Kustomizations, so that the CRs in the config--metallb-system Kustomization are only applied after metallb itself is applied in the metallb--metallb-system Kustomization :slight_smile:

These guides are extremely helpful for newbies like me. However. I am not understanding this section. I have used your template to create my repo and I don’t know where the copied “Values.yaml” is supposed to go in my repo, and then how do I (reference it I guess) in the “configmap-metallb-helm-chart-value-overrides.yaml”. Sorry for the dumb question. Just trying to understand how to use flux and also configure this metalLB. Thanks again!

Based on the current way that recipe is written (I have an update pending), you’ll take the contents of the upstream values.yaml file, and paste it (indented 4 spaces) into your configmap, then make any necessary changes.

So you might end up with something like this:

apiVersion: v1
kind: ConfigMap
  name: metallb-helm-chart-value-overrides
  namespace: metallb-system
  values.yaml: |-  

    # Default values for metallb.
    # This is a YAML-formatted file.
    # Declare variables to be passed into your templates.

    imagePullSecrets: []
    nameOverride: ""
    fullnameOverride: ""

I tried mostly following your same examples. I’m seeing, I think, similar issues with the CRDs not being defined and set first.

$ flux get kustomizations --watch
NAME       	REVISION	SUSPENDED	READY	MESSAGE                                                                                                                       
flux-system	        	False    	False	IPAddressPool/metallb-system/default-pool dry-run failed: no matches for kind "IPAddressPool" in version ""

Does anyone have additional recommendations for debugging? It’s difficult to trace what flux is doing in terms of ordering.

Bootstrap pieces: my-flux-kubernetes/clusters/home/bootstrap at master · firefly2442/my-flux-kubernetes · GitHub