Skip to content

WIP ADR for clusters-without-CAPI#1617

Open
scottmbaker wants to merge 3 commits intomainfrom
adr-co-without-capi
Open

WIP ADR for clusters-without-CAPI#1617
scottmbaker wants to merge 3 commits intomainfrom
adr-co-without-capi

Conversation

@scottmbaker
Copy link
Copy Markdown
Contributor

Description

Starting a new ADR for the PoC of bringing up clusters without using CAPI.

Checklist:

  • I agree to use the APACHE-2.0 license for my code changes
  • I have not introduced any 3rd party dependency changes
  • I have performed a self-review of my code


### Rough Idea #1

Implement a new agent, installed by `node_agent`. The agent will be responsible for:
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We already have a node_agent in EMF today

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have well defined process in the "edge node" teams for creating a single node cluster during the OS provisioning task as part of the cloud-init we use to customize the OS already, we may just want to focus on that to reduce implication that we would "upgrade" outside of the OS provisioning as well.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@soniabha-intc what I meant was that the existing node-agent would install the new-cluster-agent (needs a better name).

Implement a new agent, installed by `node_agent`. The agent will be responsible for:

- Installing K3s if it is not already installed
- Reporting cluster status and kubeconfig back to a central CO database
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps the existing agent can be extended to detect presence of a Kubernetes cluster and to report that status back? It isn't clear how "app orch" communication gets established, if we can just insert an additional agent that then talks to the k8s API when present.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've updated idea #2 to be the "extend existing agent and existing databases" idea. I've also added the option to explore alternative 3rd party application management components, such as portainer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants