[FOLIO-1996] SPIKE: dynamic YAML service deployments (K8s) Created: 02/May/19  Updated: 03/Jun/20  Resolved: 25/Jun/19

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

Type: Task Priority: P3
Reporter: Jakub Skoczen Assignee: Wayne Schneider
Resolution: Done Votes: 0
Labels: platform-backlog
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 OKAPI-736 PoC: Deploy through the Kubernetes API Open
Sprint:
Story Points: 5
Development Team: Core: Platform

 Description   

Investigate a way to generate YAML service deployment dynamically based on Okapi-provided dependency resolution.

So far we have discussed the following approach:

  • add Kubernets deployment mode to Okapi (in addition to the existing Docker and exec modes). In this mode Okapi would call K8s API (similarly how it calls the Docker API) when install with deploy=true is called (see OKAPI-736 Open )
  • the YAML deployment would be generated directly within Okapi based on a template shipped with Okapi. In order to allow customisability of deployment, a custom template could be provided in the launchDescriptor. Okapi would "inject" template variables (like module name, version, type, etc) similarly to how Helm works.

There could be also other approaches which are more elegant. We should investigate similar solution in the Kube ecosystem and propose a solution.



 Comments   
Comment by Wayne Schneider [ 15/May/19 ]

A possible approach: Okapi could generate pod configuration from a template and post to Kubernetes. Using the metadata attached to the pod, we could create deployment configurations and service definitions that operate by matching the label metadata – that may be something that needs to be separate from Okapi?

One issue with this approach is that Okapi needs to communicate with a service, not a pod, possibly using DNS resolution (see OKAPI-729 Open ), to allow the operator to scale and upgrade the service as needed. Perhaps Okapi should create the entire service and deployment configuration (including the pod )from a template?

Comment by Jakub Skoczen [ 16/May/19 ]

Wayne Schneider Yep – i think the above approach is worth considering. This would be similar to how Helm works. Helm introduces templating to static K8s YAML files. Okapi's role would be similar – we can either use the templating approach (like Helm) and pass the initial Deployment controller to Okapi and let Okapi "fill out" the blanks OR try to rely on selectors/labels. I still prefer the selectors/labels matching approach IFF it is flexible enough.

Comment by Jakub Skoczen [ 17/Jun/19 ]

jroot Wayne Schneider We discussed that Okapi producing K8s YAML that can subsequently be consumed by whatever orchestration tool is a more flexible approach (from the DevOps point of view) than calling the K8s API directly (experimented with through OKAPI-736 Open )

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