diff --git a/docs/docs-content/integrations/metallb.md b/docs/docs-content/integrations/metallb.md index ad55b66d78..aa65e046a6 100644 --- a/docs/docs-content/integrations/metallb.md +++ b/docs/docs-content/integrations/metallb.md @@ -10,58 +10,244 @@ logoUrl: 'https://registry.spectrocloud.com/v1/lb-metallb/blobs/sha256:3d09a1eab tags: ['packs', 'metallb', 'network'] --- -MetalLB is a load-balancer implementation for bare metal [Kubernetes](https://kubernetes.io/) clusters, using standard routing protocols. This integration is recommended for the on-prem cloud(s) and will help external service(s) get an IP address when the service type is set as LoadBalancer. +MetalLB is a load-balancer implementation for bare metal [Kubernetes](https://kubernetes.io/) clusters that uses standard routing protocols. This integration is recommended for self-hosted clouds and helps external services obtain an IP address when the service type is set to LoadBalancer. -## MetalLB Pack Working Details: +MetalLB deploys a controller and a speaker. The speaker is deployed as a DaemonSet on all nodes. -* The address set in pack values goes into a configMap **`config`** in **`metallb-system`** namespace. This configMap is used by the MetalLB controller and speakers as volume mounts. -* Any changes to the address will get updated in the configMap. Our users may confirm this with this command: +## Versions Supported - kubectl describe cm config -n metallb-system. + -* However, the controller and speaker pods are already running with a previous copy of the configMap and these deployments are not aware of the new changes made to configMap. To ensure the address change are reflected, we need to restart the controller and speaker pods so that they will fetch the new configMap and start assigning new addresses correctly. + -* Run the following commands, which will help restart the controller and speaker: +## Prerequisites + +- A Kubernetes cluster with Kubernetes version 1.13.0 or later that does not already have network load-balancing functionality. + + +- A cluster network configuration that does not conflict with MetalLB. For more information, refer to the official Kubernetes [Cluster Networking](https://kubernetes.io/docs/concepts/cluster-administration/networking) documentation + + +- Ensure sufficient IPv4 addresses for MetalLB are available for the number of services in each cluster. + + +- When using the Border Gateway Protocol (BGP), one or more BGP-capable routers are required. + + +- When using the Layer 2 (L2) operating mode, Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) traffic on port 7946 must be allowed between nodes, as required by the [HashiCorp memberlist](https://github.com/hashicorp/memberlist). You can configure other port as needed. + + +## Parameters + +The `addresses` parameter applies to the manifest-based MetalLB pack. You can provide multiple entries, but usually only one is needed. + +| **Parameter** | **Description** | +|---------------|-----------------| +| `addresses`| This can be a range of addresses or a CIDR address. Examples:
192.168.250.48-192.168.250.55
192.168.250.0/24 | + +## Usage + +The *lb-metallb* manifest-based pack supports direct configuration of an L2 IP address set. The *lb-metallb-helm* Helm-based pack provides an L2 address pool. + +
+ +### Manifest + +Manifest-based MetalLB supports direct configuration of an L2 IP address set. You can set either a range of addresses or use CIDR format, such as `192.168.250.48/29`. A more advanced MetalLB configuration, such as Border Gateway Protocol (BGP) routing requires you to write your own manifests and add them to the Palette cluster profile. + +The example shows the syntax used to set an address range. + +
+ +```yaml +manifests: + metallb: + images: + controller: "" + speaker: "" + namespace: "metallb-system" + avoidBuggyIps: true + addresses: + - 192.168.250.48-192.168.250.55 +``` + +
+ +### Helm Chart + +Helm-based MetalLB default gives you an L2 address pool by default. It has two sections, `charts:metallb-full:configuration` and `charts:metallb-full:metallb`, as shown in the following examples. + +Use the `charts:metallb-full:configuration` parameter section to set resource types that MetalLB supports. The pack default gives you an L2 address pool. To set up a more advanced scenario, you can use the other resource types provided in the pack. The pack includes a commented-out example for each resource. + +
+ + +```yaml +charts: + metallb-full: + configuration: + ipaddresspools: + first-pool: + spec: + addresses: + - 192.168.10.0/24 + avoidBuggyIPs: true + autoAssign: true + + l2advertisements: + default: + spec: + ipAddressPools: + - first-pool + + bgpadvertisements: {} + bgppeers: {} + communities: {} + bfdprofiles: {} +``` +
+ +The `charts:metallb-full:metallb` parameter section provides access to all the options of the base chart that installs MetalLB. You don’t need to change anything unless you want to install MetalLB in Free Range Routing (FRR) mode. To use FRR mode, set the option to `true`, as the example shows. + +
+ +```yaml +charts: + metallb-full: + metallb: + speaker: + frr: + enabled: true +``` - kubectl rollout restart deploy controller -n metallb-system - kubectl rollout restart ds speaker -n metallb-system -## Versions Supported - - -* **0.13.5** -* **0.11.0** - +## Prerequisites + +- A Kubernetes cluster with Kubernetes version 1.13.0 or later that does not already have network load-balancing functionality. + + + +- A cluster network configuration that does not conflict with MetalLB. For more information, refer to the official Kubernetes [Cluster Networking](https://kubernetes.io/docs/concepts/cluster-administration/networking) documentation. + + +- Ensure sufficient IPv4 addresses for MetalLB are available for the number of services in each cluster. + + +- When using the Border Gateway Protocol (BGP), one or more BGP-capable routers are required. + + +- When using the L2 operating mode, Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) traffic on port 7946 must be allowed between nodes, as required by the [HashiCorp memberlist](https://github.com/hashicorp/memberlist). You can configure other port as needed. + + +## Parameters + +The `addresses` parameter applies to the manifest-based MetalLB pack. You can provide multiple entries but only one is typically needed. + +| **Parameter** | **Description** | +|---------------|-----------------| +| `addresses`| This can be a range of addresses or a CIDR address. Examples:
192.168.250.48-192.168.250.55
192.168.250.0/24 | + +## Usage + +The *lb-metallb* manifest-based pack supports direct configuration of an L2 IP address set. You can set either a range of addresses or use CIDR format, such as `192.168.250.48/29`. A more advanced MetalLB configuration, such as Border Gateway Protocol (BGP) routing requires you to write your own manifests and add them to the Palette cluster profile. + +The example shows the syntax used to set an address range. + +
+ +```yaml +manifests: + metallb: + images: + controller: "" + speaker: "" + namespace: "metallb-system" + avoidBuggyIps: true + addresses: + - 192.168.250.48-192.168.250.55 +``` + + - -* **0.9.5** - - * **0.8.3** + + +:::caution + +All versions of the manifest-based pack less than v0.9.x are considered deprecated. Upgrade to a newer version to take advantage of new features. + +::: + -## Components +
+ +## Troubleshooting + +If controller and speaker pods are not assigning new IP addresses that you provided in the MetalLB pack, it is likely pods in existing deployments do not have the latest configMap file. + +IP addresses you specify in MetalLB pack values go into a configMap called `config` in the `metallb-system` namespace. The MetalLB controller and speakers use the configMap as a volume mount. + +Any changed IP addresses will get updated in the configMap. You can confirm this by issuing the following command. + +
+ +```bash +kubectl describe cm config --namespace metallb-system +``` -* MetalLB controller. -* Speaker (runs on all nodes, deployed as DaemonSet). +
+ +Since the controller and speaker pods are using a previous copy of the configMap, existing deployments are unaware of the changes made to configMap. + +
+
+ +To ensure updated addresses are reflected in the configMap, you need to restart the controller and speaker pods so they fetch the new configMap and start assigning new addresses correctly. Issue the commands below to restart the controller and speaker. + +
+ + +```bash +kubectl rollout restart deploy controller --namespace metallb-system +kubectl rollout restart ds speaker --namespace metallb-system +``` + +
+ +## Terraform + +```hcl +data "spectrocloud_pack" "MetalLB" { + name = "lb-metallb" + version = "0.13.5" +} +data "spectrocloud_pack" "MetalLB-Helm" { + name = "lb-metallb-helm" + version = "0.13.7" +} +``` + +
## References -- [MetalLB Home](https://metallb.universe.tf) +- [MetalLB](https://metallb.universe.tf/) + -- [MetalLB GitHub](https://github.com/metallb/metallb) +- [MetalLB GitHub ](https://github.com/metallb/metallb) \ No newline at end of file diff --git a/vale/styles/Vocab/Internal/accept.txt b/vale/styles/Vocab/Internal/accept.txt index f710fa0e23..6a305cc9c6 100644 --- a/vale/styles/Vocab/Internal/accept.txt +++ b/vale/styles/Vocab/Internal/accept.txt @@ -141,4 +141,7 @@ Kubevious Citrix Disable Hotfixes -Hotfix \ No newline at end of file +Hotfix +Layer 2 +L2 +HashiCorp \ No newline at end of file