Notes from episode 13 of TGIK: Serverless with Fission
Over the past few months I’ve been trying to learn everything there is to know about Kubernetes. Kubernetes is an amazing technology for deploying and scaling containers though it comes with a cost. It’s an incredibly complex piece of software and there are a ton of bells and whistles to become familiar with. One way that I’ve found for coming up to speed is Joe Beda’s weekly TGIK live broadcast. This occurs each Friday at 4PM EST and is CHOCK full of fantastic information. In episode thirteen Joe discusses running serverless applications with fission. You can watch it here:
Here are some of my takeways from the episode:
Fission is a fast serverless platform to run functions on top of Kubernetes.
The grafeas project was created by a number of large organizations to provide a uniform way to audit and govern your software supply chain.
Grafeas keeps track of where your artifacts came from and allows you to track what is running when and where.
Moby is the community project that was recently spawned to govern docker development.
Linuxkit is a toolkit for building secure, portable and lean operating systems for containers.
Infrakit is a toolkit for creating and managing declaractive self-healing infrastructure.
Libnetwork provides a native Go implementation for connecting containers.
Notary’s are used to sign and verify container images.
Helm is the suggested way to deploy fission.
Fission provides two versions:
Minimal
Full (contains NATs streaming and InfluxDB and FluentD for logs)
The default fission installation doesn’t utilize RBAC.
Helm uses go templates to speclialize the YAML that is created and sent to Kubernetes.
Fission makes liberal use of ClusterRoles.
Fission provisions a number of services and resources:
NAT streaming
Timer service
InfluxDB
Fluentd
Router
Builder manager
Controller
Kubernetes watcher
Pool manager
Logger daemon
The logger daemon pulls logs from the host it’s running on.
NATs is a simple high performance messaging system.
NATs streaming buids on top of NATs and adds data streaming and persistent and durable storage
Streaming uses a single replica so its possible to lose messages.
You interact with fission through the fission command line client.
The Kubernetes jsonpath option can be used to retrieve arbitrary elements from a JSON document:
$ kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}'
Authentication and multi tenancy support will be added to Fission in the future.
Fission uses 3rd party resoources which have been deprecated in favor of CRDs.
Fission advertises a 100ms cold start time.
Fission keeps a pool of containers available to run your code.
Couple of interesting notes from Joe:
Things are more centralized with Fission.
Runs in the Kubernetes security context which gives it wide access.
Somewhat difficult to control and segment resources.
Initializers allow you to set up the runtime environment (e.g., add an audting sidecar) prior to the container starting up.
Fission builders are used to build the code that gets executed.
Fission Workflows provide a way to control the execution flow of your functions.
Fission doesn’t use horizontal pod autoscaling. It implements it’s own approach.
The Kubernetes metacontroller is a serverless-like approach to creating controllers.
Things I need to learn more about:
Read up on the Kubernetes metacontroller.
See what options are available to perform blue-green deployments.
This article was posted by Matty on 2018-03-11 08:00:00 -0500 -0500