search

iotaledger / one-click-tangle

"One Click Tangle" intends to make lives easier to IOTA adopters by providing pre-configured scripts and recipes that allow to deploy IOTA Networks and Nodes "in one click".
MIT License
55 stars 35 forks source link

Added an example of kubernetes resources for mainnet: this is just an example #59

Closed mastrogiovanni closed 2 years ago

mastrogiovanni commented 2 years ago

Description of change

I added first example of kubernetes resources: a service to expose TCP ports and another service (NodePort) for UDP port that need to be used for peering. kubectl port-forward does not work with UDP ports. Ingress controller need to be added.

Type of change

How the change has been tested

With a kubernetes cluster (e.g minikube) and kubectl installed:

kubectl apply \
     -f hornet-mainnet/kubernetes/hornet-cm.yaml \
     -f hornet-mainnet/kubernetes/hornet-deployment.yaml \
     -f hornet-mainnet/kubernetes/hornet-service.yaml

Change checklist

Add an x to the boxes that are relevant to your changes, and delete any items that are not.

jmcanterafonseca-iota commented 2 years ago

thank you for this @mastrogiovanni

Quick feedback. I think even though this can be a good start I was thinking on something more elaborated:

A/ Config Map automatically generated from a the config-template we already have in the repo B/ I think Hornet can be modelled using a StatefulSet, as a result we could be able to launch multiple Hornets and even load balance them. But not only that, we will be able to bind them to automatically requested Persistent Volume Claims. C/ Secrets corresponding to Hornet identity private key stored properly D/ Peering and autopeering solved

Also you would need to think whether the existing hornet.sh script can be "parameterised" or better modularised so that it serves for Kubernetes deployments, probably we will have a hornet-k8s.sh script that will do that work.

Definitely more work is needed here

mastrogiovanni commented 2 years ago

I definitely agree with you, but at this point I see two different roads. The first road is pure kubernetes deployment where in the README there are extended instructions on how create secrets (C) or how to configure/edit config maps related to configuration to cover also (A). The second road is to create an helm chart (I was doing it) in order to get all those issues at installation time. I would prefer to create helm chart. Regarding persistent container, helm chart will solve that since in general you can use an empty container or use persistent container changing a variable (the name of persistent volume). Daemon set will solve the peering problem. In the future we can also think to use ingress instead to NodePort to allow autopeering. If it's ok, I'll proceed to create helm chart and include A, B, C, D

jmcanterafonseca-iota commented 2 years ago

I am not a big fan of Helm Charts due to its horrible and unreadable templating mechanism

Can we have the clean K8s manifests based on Statefulset and then have a version with Helm Charts?

I have my doubts with what you are saying regarding autopeering and peering it is not so easy in general and you have to take into account we are talking about peering with the outside and not through HTTP but through other protocols I am not sure ingress controller support at all or what would be the role of an ingress controller there.

On Fri, Oct 22, 2021 at 8:47 AM Michele Mastrogiovanni < @.***> wrote:

I definitely agree with you, but at this point I see two different roads. The first road is pure kubernetes deployment where in the README there are extended instructions on how create secrets (C) or how to configure/edit config maps related to configuration to cover also (A). The second road is to create an helm chart (I was doing it) in order to get all those issues at installation time. I would prefer to create helm chart. Regarding persistent container, helm chart will solve that since in general you can use an empty container or use persistent container changing a variable (the name of persistent volume). Daemon set will solve the peering problem. In the future we can also think to use ingress instead to NodePort to allow autopeering. If it's ok, I'll proceed to create helm chart and include A, B, C, D

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/iotaledger/one-click-tangle/pull/59#issuecomment-949333524, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQEZJLTEAZEEDAUQJT2NVUTUIECG7ANCNFSM5GOCJJXA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

-- IOTA Foundation Pappelallee 78/79 10437 Berlin, Germany

Board of Directors: Dominik Schiener, Serguei Popov, Navin Ramachandran ID/Foundation No.: 3416/1234/2 (Foundation Register of Berlin)

mastrogiovanni commented 2 years ago

I hate helm Chart as well but I have no other ideas on how to deploy parametric configuration at installation time. However I'll start cleaning up all deployment files. For autopeering I already tested: NodePort is ok to open the UDP port to the outside world (and I'll keep this for the meantime). The only other solution is via Ingress controller but I'll need to check and I let you know.

mastrogiovanni commented 2 years ago

I need to explore how to inject in the json configuration secrets from outside (maybe an init container). I let you know when I will cover also C. Notice that aoutopeering is solved since the port exposed by node port is fixed and is inserted inside the configuration file. If I can inject runtime information in the config.json, I will be able to allow a random port selection for NodePort in order to let autopeering work

jmcanterafonseca-iota commented 2 years ago

see #67

jmcanterafonseca-iota commented 2 years ago

already landed