[FOLIO-2019] SPIKE: evaluate Rancher 2.x vs vanilla K8s Created: 16/May/19  Updated: 03/Jun/20  Resolved: 13/Jun/19

Status: Closed
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Task Priority: P2
Reporter: Jakub Skoczen Assignee: Wayne Schneider
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Blocks
blocks FOLIO-2117 Kubernetes integration (Q2, container... Closed
blocks UXPROD-1823 Kubernetes integration (Q3, Okapi fea... Draft
Relates
relates to FOLIO-2057 SPIKE: explore AWS K8s cost models Closed
Sprint:
Story Points: 5

 Description   

Rancher is a UI and API abstraction on top of K8s (since v2.x) that allows to centralize management of multiple heterogenous K8s clusters: https://rancher.com/what-is-rancher/what-rancher-adds-to-kubernetes/. It includes it's own K8s "distribution" that can be deployed on-prem (RKE). The product similar to RedHat's OpenShift and Pivotal's PKS. Rancher Labs provides commercial support for Rancher.

The purpose of this spike is to evaluate Rancher over vanilla Kubernetes. The primary focus of this evaluation is on utilising Kubernetes-based cluster for internal CI pipelines supporting FOLIO development. The secondary focus is on supporting container deployment integration between Okapi and Kubernetes (see OKAPI-1996) and production FOLIO deployments.

Evaluation criteria:

1. ease of setting up – FOLIO development cluster configuration and number of clusters is unlikely to change often and the clusters (assuming more than on) are likely to be homogenous (AWS). The opposite is likely true for a production FOLIO environment which may utlize a mix of different cloud vendors and on-prem installtions.

2. integration via the API – Rancher provides a Restful API that abstract K8s API. Access to the "raw" K8s API is possible but manipulated resources must be labelled according to Rancher's labelling scheme or they may not be detected by Rancher. Jenkins has plugins both for K8s and Rancher which likely alleviates this problem (critical for CI and FOLIO development). Okapi is more likely to utilize "raw" K8s API to avoid vendor lock-in.

3. administration and UI – Rancher provides a UI (control panel) and it's own CLI while a vanilla K8s provides a Dashboard UI and standard CLI (kubectl).



 Comments   
Comment by mark.stacy [ 16/May/19 ]

I have used both AWS EKS and RKE(AWS EC2) clusters. When using AWS EKS which leverage more of AWS Services(Cloud Formation) and separation of cluster and Rancher were more distinct. When creating a cluster using RKE(AWS EC2) the cluster is more tightly coupled with Rancher. So this is still a valid discussion, and of course, the answer is "It Depends". Sorry for generating any confusion during this mornings meeting.

Comment by mark.stacy [ 16/May/19 ]

Jakub Skoczen From the description above 'Okapi is more likely to utilize "raw" K8s API to avoid vendor lock-in.' So the plan is to have Okapi performing orchestration within K8s? or is it a plan where Okapi would generate raw k8s YAML for FOLIO deployment? In my opinion, if you focus on the standard YAML resources templates this would fit better in the creation of Helm Chart and give institutions the ability to create k8s clusters in any current or future manner. Following the Kubernetes standard for resource YAML creation.

From Rancher FAQ:
"If we use Kubernetes native YAML files for creating resources, should we expect that to work as expected, or do we need to use Rancher/Docker compose files to deploy infrastructure?
Absolutely."

Comment by jroot [ 17/May/19 ]

Currently, Okapi can spit you out a list of modules to run a Folio system - given version of a module or set of modules you need/want. mark.stacy, are you saying it could also be possible/useful for Okapi to spit you out a "manifest" of modules to run, in YAML format - that define Kubernetes services for a Folio system? Assuming of course Kubernetes plugin support is added to Okapi...

Comment by Jakub Skoczen [ 20/May/19 ]

mark.stacy I think it's key that standard resource templates are eventually used to offer full flexibility of creating clusters with any tool or process institutions wish (please see and provide your feedback on FOLIO-1996 Closed ). This will be a prerequisite for for any sensible "orchestration" performed by Okapi itself. So in short I think we will get both: ability to generate/expand resource templates (production) and basic built-in orchestration that relies on them that can be used for development.

Comment by Jakub Skoczen [ 13/Jun/19 ]

Wayne Schneider I am closing this with the assumption that we have converged on a solution and that solution will be implemented through the course of FOLIO-2054 Closed .

Comment by Wayne Schneider [ 13/Jun/19 ]

Agreed.

Generated at Thu Feb 08 23:17:36 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.