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:
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:
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:
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:
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):