IP Controller - Revision history

DrEdWilliams: updates for newer version of metallb

2024-02-10T01:03:46Z

updates for newer version of metallb

← Older revision		Revision as of 01:03, 10 February 2024
Line 5:		Line 5:
	The basic load balancer is deployed with a simple manifest:		The basic load balancer is deployed with a simple manifest:

	<nowiki>kubectl apply -f https://raw.githubusercontent.com/~~google~~/metallb/v0.~~9.6/manifests/namespace.yaml~~		<nowiki>kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.14.3/config/manifests/metallb-native.yaml
	~~kubectl apply -f https://raw.githubusercontent~~.~~com~~/~~google/metallb/v0.9.6~~/manifests/metallb.yaml		</nowiki>
	~~# On first install only~~
	~~kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)"~~</nowiki>

	At this point, the controller itself is active, but it has nothing to do -- it doesn't have any IP addresses to hand out. The controller uses a ~~ConfigMap~~ to define address pools, allocation methods, and routing protocols. There are multiple definitions in the [https://gitlab.williams-net.org/k8s/k8s-admin k8s-admin repository on GitLab], use the one appropriate to the system:		At this point, the controller itself is active, but it has nothing to do -- it doesn't have any IP addresses to hand out. The controller uses a Custom Resource Definition to define address pools, allocation methods, and routing protocols. There are multiple definitions in the [https://gitlab.williams-net.org/k8s/k8s-admin k8s-admin repository on GitLab], use the one appropriate to the system:

	{\| class="wikitable"		{\| class="wikitable"
Line 16:		Line 14:
	! filename !! IP range		! filename !! IP range
	\|-		\|-
	\| ~~metallb-config-dev.yaml \|\| 10.0.0.200 - 10.0.0.209~~		\| ipaddresspool-prod.yaml \|\| 10.0.0.110 - 10.0.0.127
	\|-
	~~\| metallb-config-rke.yaml \|\| 10.0.0.210 - 10.0.0.219~~
	\|-
	~~\| metallb-config~~-prod.yaml \|\| 10.0.0.110 - 10.0.0.127
	\|-
	~~\| metallb-config-test.yaml \|\| 10.0.0.190 - 10.0.0.197~~
	\|}		\|}

DrEdWilliams at 20:36, 23 May 2021

2021-05-23T20:36:18Z

← Older revision		Revision as of 20:36, 23 May 2021
Line 16:		Line 16:
	! filename !! IP range		! filename !! IP range
	\|-		\|-
	\| metallb-config-dev.yaml \|\| 10.0.0.200 - 10.0.0.~~240~~		\| metallb-config-dev.yaml \|\| 10.0.0.200 - 10.0.0.209
			\|-
			\| metallb-config-rke.yaml \|\| 10.0.0.210 - 10.0.0.219
	\|-		\|-
	\| metallb-config-prod.yaml \|\| 10.0.0.110 - 10.0.0.127		\| metallb-config-prod.yaml \|\| 10.0.0.110 - 10.0.0.127

DrEdWilliams at 19:30, 25 April 2021

2021-04-25T19:30:45Z

← Older revision		Revision as of 19:30, 25 April 2021
Line 5:		Line 5:
	The basic load balancer is deployed with a simple manifest:		The basic load balancer is deployed with a simple manifest:

	<nowiki>kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.9.5/manifests/namespace.yaml		<nowiki>kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.9.6/manifests/namespace.yaml
	kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.9.5/manifests/metallb.yaml		kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.9.6/manifests/metallb.yaml
	# On first install only		# On first install only
	kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)"</nowiki>		kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)"</nowiki>

DrEdWilliams at 20:52, 7 November 2020

2020-11-07T20:52:51Z

← Older revision		Revision as of 20:52, 7 November 2020
Line 5:		Line 5:
	The basic load balancer is deployed with a simple manifest:		The basic load balancer is deployed with a simple manifest:

	<nowiki>kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.9.3/manifests/namespace.yaml		<nowiki>kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.9.5/manifests/namespace.yaml
	kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.9.3/manifests/metallb.yaml		kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.9.5/manifests/metallb.yaml
	# On first install only		# On first install only
	kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)"</nowiki>		kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)"</nowiki>

DrEdWilliams at 00:56, 24 March 2020

2020-03-24T00:56:19Z

← Older revision		Revision as of 00:56, 24 March 2020
Line 5:		Line 5:
	The basic load balancer is deployed with a simple manifest:		The basic load balancer is deployed with a simple manifest:

	<nowiki>kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.9.2/manifests/metallb.yaml		<nowiki>kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.9.3/manifests/namespace.yaml
			kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.9.3/manifests/metallb.yaml
	# On first install only		# On first install only
	~~openssl rand -base64 128 \|~~ kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey=-</nowiki>		kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)"</nowiki>

	At this point, the controller itself is active, but it has nothing to do -- it doesn't have any IP addresses to hand out. The controller uses a ConfigMap to define address pools, allocation methods, and routing protocols. There are multiple definitions in the [https://gitlab.williams-net.org/k8s/k8s-admin k8s-admin repository on GitLab], use the one appropriate to the system:		At this point, the controller itself is active, but it has nothing to do -- it doesn't have any IP addresses to hand out. The controller uses a ConfigMap to define address pools, allocation methods, and routing protocols. There are multiple definitions in the [https://gitlab.williams-net.org/k8s/k8s-admin k8s-admin repository on GitLab], use the one appropriate to the system:

DrEdWilliams at 00:35, 21 March 2020

2020-03-21T00:35:39Z

← Older revision		Revision as of 00:35, 21 March 2020
Line 5:		Line 5:
	The basic load balancer is deployed with a simple manifest:		The basic load balancer is deployed with a simple manifest:

	<nowiki>kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.8.3/manifests/metallb.yaml</nowiki>		<nowiki>kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.9.2/manifests/metallb.yaml
			# On first install only
			openssl rand -base64 128 \| kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey=-</nowiki>

	At this point, the controller itself is active, but it has nothing to do -- it doesn't have any IP addresses to hand out. The controller uses a ConfigMap to define address pools, allocation methods, and routing protocols. There are multiple definitions in the [https://gitlab.williams-net.org/k8s/k8s-admin k8s-admin repository on GitLab], use the one appropriate to the system:		At this point, the controller itself is active, but it has nothing to do -- it doesn't have any IP addresses to hand out. The controller uses a ConfigMap to define address pools, allocation methods, and routing protocols. There are multiple definitions in the [https://gitlab.williams-net.org/k8s/k8s-admin k8s-admin repository on GitLab], use the one appropriate to the system:

DrEdWilliams: Updated version to 0.8.3

2019-10-31T23:11:04Z

Updated version to 0.8.3

← Older revision		Revision as of 23:11, 31 October 2019
Line 5:		Line 5:
	The basic load balancer is deployed with a simple manifest:		The basic load balancer is deployed with a simple manifest:

	<nowiki>kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.8.1/manifests/metallb.yaml</nowiki>		<nowiki>kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.8.3/manifests/metallb.yaml</nowiki>

	At this point, the controller itself is active, but it has nothing to do -- it doesn't have any IP addresses to hand out. The controller uses a ConfigMap to define address pools, allocation methods, and routing protocols. There are multiple definitions in the [https://gitlab.williams-net.org/k8s/k8s-admin k8s-admin repository on GitLab], use the one appropriate to the system:		At this point, the controller itself is active, but it has nothing to do -- it doesn't have any IP addresses to hand out. The controller uses a ConfigMap to define address pools, allocation methods, and routing protocols. There are multiple definitions in the [https://gitlab.williams-net.org/k8s/k8s-admin k8s-admin repository on GitLab], use the one appropriate to the system:

DrEdWilliams: Created page with "In order for kubernetes services to be accessible outside the cluster, they need to have externally routable IP addresses. While it would seem that this is a basic need that..."

2019-08-03T00:58:21Z

Created page with "In order for kubernetes services to be accessible outside the cluster, they need to have externally routable IP addresses. While it would seem that this is a basic need that..."

New page

In order for kubernetes services to be accessible outside the cluster, they need to have externally routable IP addresses. While it would seem that this is a basic need that should be provided by kubernetes itself, its implementation is actually very dependent on the underlying platform -- and therefore left for the provider to implement.

We are using the bare metal load balancer called [https://metallb.universe.tf/ MetalLB]. It is a full featured loadbalancer and IP controller that has multiple modes of operation. As deployed here, it is using simple Layer 2 operation, advertising IP addresses using the existing network interfaces.

The basic load balancer is deployed with a simple manifest:

<nowiki>kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.8.1/manifests/metallb.yaml</nowiki>

At this point, the controller itself is active, but it has nothing to do -- it doesn't have any IP addresses to hand out. The controller uses a ConfigMap to define address pools, allocation methods, and routing protocols. There are multiple definitions in the [https://gitlab.williams-net.org/k8s/k8s-admin k8s-admin repository on GitLab], use the one appropriate to the system:

{| class="wikitable"
|-
! filename !! IP range
|-
| metallb-config-dev.yaml || 10.0.0.200 - 10.0.0.240
|-
| metallb-config-prod.yaml || 10.0.0.110 - 10.0.0.127
|-
| metallb-config-test.yaml || 10.0.0.190 - 10.0.0.197
|}

Apply the correct pool definition to get things working:
kubectl apply -f <filename>

This loadbalancer implementation supports the requesting of IP addresses through the '''loadBalancerIP''' parameter in the service -- if the address is available, it will allocate it. The '''externalTrafficPolicy''' parameter is also respected.

See the home page for the MetalLB package for complete installation and configuration options.

----

<references/>