Deploying Fission in an Offline Kubernetes Cluster
There are certain use cases where the Kubernetes cluster might be in a environment with restricted internet or no internet access at all due to business or compliance reasons. This guide explains the way to deploy and use a Fission instance in such a cluster. It is assumed that the CI/CD tooling which deploys to Kubernetes will have internet access, but not the Kubernetes cluster itself.
Cloning Fission Images
Before installing Fission you will need to make container images available in a container registry which is accessible to Kubernetes cluster. You can download and retag them or export and import image tar files based on your setup. For Fission to be installed you will need following images:
fission/fission-bundle fission/fetcher fission/influxdb fission/fluentd
In addition you will need to import environment images which will be used by functions. For example if you are only going to use python and node environments then you will need to import following images:
If Kubernetes cluster has Helm installed then you can download the charts of appropriate versions from charts repo. You can then install the chart by passing the tar file or by extracting the chart into a directory. The key here is to update the image references in values.yaml to images in your internal docker registry.
$ helm install ./fission-all-0.12.0.tgz
On an on premise environment where a LoadBalancer can not be provisioned, the services should be exposed with type “NodePort” instead of default LoadBalancer.
routerServiceType: NodePort serviceType: NodePort
If you want to enable Prometheus with Fission, then you will have to download the chart for Prometheus and related images in registry before you can install Fission.
If you are not using Helm then you can use the YAML files from Fission releases to install Fission. Once you have downloaded the YAML you will have to change the references to Fission images and prometheus images if you want to enable prometheus.
For all services that use the type
LoadBalancer it should be changed to NodePort. The service then can be accessed on the host’s IP and NodePort.
In a offline setup the builder won’t work if it has to fetch dependencies from the internet. If you are using a private artifact manager such as Artifactory or Nexus to fetch dependencies then the URLs for those servers have to be configured in respective build tool. Please check the build tool’s documentation to configure the custom artifact server from which dependencies can be fetched.
LoadBalancer & Accessing Fission Functions
As mentioned earlier, in an on premise environment a LoadBalancer can not be provisioned, hence the services should be exposed with type “NodePort” instead of default LoadBalancer.
If you are exposing functions outside the cluster using an ingress controller then you would have to use
--createingress flags when creating routes. You can then access functions on ingress controllers nodeport and the function path.