MetalLB Kubernetes LoadBalancer with Fission.io
Tags: docker, systemadministratio, networking, kubernetes
Published: 2019-02-13 03:42:58

---
title: MetalLB Kubernetes LoadBalancer with Fission.io
published: true
tags: docker,system-administratio,networking,kubernetes
canonical_url: https://medium.com/@jmarhee/metallb-kubernetes-loadbalancer-with-fission-io-ed680443d679
---

I recently began using [MetalLB](https://metallb.universe.tf/) 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](http://github.com/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](http://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](https://docs.fission.io/installation/)

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](https://metallb.universe.tf/concepts/)

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](https://medium.com/@jmarhee/add-tls-to-your-fission-io-endpoint-with-kubernetes-ingresses-913a78403edf)