Use-case for Kubernetes with Rancher 2.0
FOLIO microservices are being developed for use in Docker containers.
Currently Okapi deploys these Docker container modules, it is useful for Okapi not to oversee deployment/orchestration. (How would Okapi know to spin up several of one module?)
It makes sense not to reinvent the wheel on how these services are delivered and integrated into FOLIO.
Comparison:
Kubernetes:
- Free to the end user
- The need for container orchestration
- It’s open source – and vendor agnostic
- Ability to keep track of containers. This is useful not only for performance metrics, but also for billing CPU time or storage when running on a cloud provider
- Can manage the deployment of multiple pods (one or more containers that logically go together) across multiple nodes (VMs or bare metal)
- Easy to scale, load balance and schedule containerized workloads
-Concerns:
- Complicated to setup and there is a large learning curve
Rancher 2.0 front-end:
- Free to the end user
-Easily manage Kubernetes environments with a slick GUI interface
- Ability to set up namespaces where clusters, services, apps and containers are defined and shared
- Containers on clusters in an environment communicate over a shared network
- Scalability of microservices for increasing or decreasing workloads
- Resources can be access-controlled for user management
- Ability to manage hosts across different providers (AWS, IBM Cloud, on-prem)
- Integrated real-time performance monitoring (memory, CPU, I/O, network resources individual container performance)
-Concerns:
- Complicated to splay out in a wide environment
- Support is paid
Docker Swarm:
- Free to the end user
- Quick to set up a basic swarm environment
-Concerns:
- Requires network plugin for multicast discovery
- Egress and ingress with Docker networks – need to be very well defined
- Limited functionality compared with Docker Enterprise (which is not free)
- Limitations when it comes to container orchestration
Our thought process:
When it comes to on Premise containers, we considered two major choices: Docker Swarm or Kubernetes. Docker can be run on a single host or in a cluster of hosts using Docker Swarm or Docker Enterprise. Docker Swarm is free and Docker Enterprise requires a purchase. Docker Swarm has limited functionality compared to Docker Enterprise. Swarm has limitations when it comes to container orchestration. Many of its processes are manual and limited, which is why Docker Enterprise exists, to fill in these container automation and orchestration gaps.
This is also why Kubernetes exists. Kubernetes is an open source project managed by the Cloud Native Computing Foundation. It solves many of the container automation and orchestration problems, but its main draw is that it’s free. Kubernetes is the most popular container orchestration tool by far. It is easy to scale, load balance and schedule containerized workloads. The problem with Kubernetes is that it is complicated to setup and there is a large learning curve.
The complexity of setting up Kubernetes has opened the door for many vendors to create products designed to easily install, configure and update Kubernetes clusters. Some of the most popular vendors in this space are RedHat's OpenShift product, VMware's Pivotal Container Service and Rancher's Kubernetes Engine. There are a lot of vendors in this space. Each vendor has very specific ideas on how Kubernetes clusters should work and the capabilities of these clusters, from networking to storage to load balancing. It is important to examine the capabilities offered by these vendors to ensure that their product meets your needs.
For Texas A&M Libraries, one of the most important features in a container orchestration product is flexibility around networking. We do not control our own network and have very specific needs around container networking, which we cannot compromise on. Both Docker Swarm and Docker Enterprise have very rigid stances on networking that we could not get to work in our environment. This led us to examine Kubernetes with its flexible approach to networking. We quickly realized the complexity of setting up Kubernetes and started looking at Kubernetes vendors. We looked at RedHat's OpenShift product, VMware's Pivotal Container Service and Rancher's Kubernetes Engine. Both Redhat and VMware approaches to Kubernetes networking were not flexible enough for our needs. In Rancher we found a flexible and cheap alternative.
Rancher is free and is designed to make working with Kubernetes easier. It can help you stand up Kubernetes clusters and Kubernetes containers. Rancher has a good user interface that can help to reduce the learning curve. They offer regular webinars about Rancher and Kubernetes. You can also purchase support and training from Rancher.
Web resources:
Kubernetes resources
- Choosing the Right Containerization and Cluster Management Tool: https://kublr.com/blog/choosing-the-right-containerization-and-cluster-management-tool/
- Running Kubernetes Locally via Minikube: https://kubernetes.io/docs/setup/minikube/
- Hello Minikube tutorial: https://kubernetes.io/docs/tutorials/hello-minikube/#create-a-docker-container-image
Rancher 2.0 resources
- Rancher 2.0 Youtube training: https://www.youtube.com/results?search_query=Rancher+2.0
- Deploying Rancher Server: https://rancher.com/docs/rancher/v2.x/en/quick-start-guide/deployment/ (Choose Vagrant or Manual Quick Start)
- Single Node Installation: https://rancher.com/docs/rancher/v2.x/en/installation/single-node-install/
Docker resources
- Docker Registry: https://docs.docker.com/registry/
- Deploy a registry server: https://docs.docker.com/registry/deploying/