I recently began using MetalLB to manage layer 2 and 3 networks in my cluster’s datacenter to provide LoadBalancer type Kubernetes Service resources in a bare-metal cluster:
jmarhee/packet-multiarch-k8s-terraform
So, with a configuration like this for MetalLB:
apiVersion: v1
kind: Namespace
metadata:
name: metallb-system
---
apiVersion: v1
kind: ConfigMap
metadata:
namespace: metallb-system
name: config
data:
config: |
address-pools:
- name: provider-network
protocol: layer2
addresses:
- **192.168.1.200-192.168.1.250**
your Address pool, 192.168.1.200-192.168.1.250 would serve out, for the lifetime of your service’s LoadBalancer, an address from that pool. This can be exceptionally helpful, particularly for a service like the Fission.io router to get an IP from the upstream Layer 2 or 3 network services, as required.
When you install MetalLB:
kubectl create -f metallb-config.yaml ;\
kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.7.3/manifests/metallb.yaml
any Service connected to that provider network (meaning anything type: LoadBalancer ) will get an address from MetalLB. So, when you install Fission:
Serverless Functions for Kubernetes
you’ll see a service like the router which will act as the entry point to your tasks that have URI paths configured, that has an external IP configured:
jmarhee@controller:~$ kubectl get service router -n fission
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
router LoadBalancer 10.109.224.184 **192.168.1.200** 80:31180/TCP 9m40s
and then all tasks are accessible at, in this case:
http://192.168.1.200/<task route>
Creating a task with a --url argument will make the task HTTP trigger accessible:
**jmarhee@controller:~$** fission function create --name hello --env nodejs --code hello.js **--url /hello**
Package 'hello-js-9tb7' created
function 'hello' created
route created: GET /hello -> hello
**jmarhee@controller:~$** curl [**http://192.168.1.200/hello**](http://192.168.1.200/hello)
hello, world!
This is a fairly straight-forward use case for, both, the MetalLB external-ip automation, and the ingress setup by default with Fission, however, this creates some great automation opportunities for bare-metal Kubernetes (or those not on managed cloud services like AWS or GCP, or a Kubernetes SaaS with an available cloud controller to provision and abstract resources) making this a great utility for many network setups you might be using upstream of your cluster to provide services:
MetalLB, bare metal load-balancer for Kubernetes
Coupled with other features native to Kubernetes, you can more tightly control access and security options for loadbalanced services like Fission (i.e. TLS, with this services as a backend):
Using Kubernetes TLS Ingress with Platform9 Fission FaaS endpoints
Top comments (0)