gravitational / satellite Goto Github PK

Good Day Sir! I want to contribute in translating Filipino language.

Summary

The satellite README.md file mentions that we use 'dep'. However, in #226 we switched from dep to go modules. We should remove the entire dependencies section as it isn't complete or current:

## Dependencies
 - [serf], v0.7.0 or later
 - [godep]

https://github.com/gravitational/satellite/blob/5a67ae767d681f113be3cf5d81ed79bab9d0738c/README.md

Note

I'm filing this as a easy first bug for a git workshop that I'm running.

Once we have done research on what it would take to deploy Satellite as a Pod in a generic K8s cluster (#257), create a Helm chart for the Satellite stack.

Success:

• Satellite can be installed in the cluster using helm install command.
• Nethealth is included as a part of the Satellite Helm chart.
  • Double-check whether nethealth can be used on a generic cluster.

Currently satellite relies on serf as a cluster membership tool to determine which nodes are a part of the cluster, checking their health, etc.

When satellite becomes a standalone tool, it can no longer use serf for that. Instead, it should be using Kubernetes nodes API to retrieve the members of the cluster.

Once dependency on serf is removed (#256), we need to containerize Satellite and deploy it inside a generic Kubernetes cluster.

Things to consider:

• It should run as a DaemonSet.
• Figure out volumes that will need to be mounted into the container.
• Host networking?
• PodSecurityPolicies and RBAC.
• Figure out checks that it can/cannot execute.

Success:

• The design doc contains answers to the above questions, and a sample Satellite DaemonSet spec.

I explored this a little more, and to help add this docs. I started by creating this diagram. Let me know if the gist of it is right? I wasn't 100% clear on how EKS workers work, but wanted to see if I've got the right jist here.

Originally posted by @benarent in gravitational/teleport#2830 (comment)