Add nodeadm usage, config example

[cartermckinnon]

Description of changes:

Adds some more detail to the README, to aid in discussion with other projects in this AMI's orbit.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[bryantbiggs]

how does this interface with managed nodegroups - are the details to join to the cluster contained in this same config, can multiple configs be provided and merged, etc?

Mainly - will this get around the current issues with managed nodegroups today #844 - where the injected bootstrap script invocation leaves users to find hacky ways to pass in values supported by the bootstrap script

[cartermckinnon]

You're talking about passing this config object in a custom launch template, without specifying an AMI in the LT, right? i.e. a "custom LT" nodegroup instead of a "custom AMI" nodegroup?

We have the ability to implement that with this approach, yes; because managed nodegroups can add the important bits as necessary, instead of only tacking on a MIME part.

[bryantbiggs]

i.e. a "custom LT" nodegroup instead of a "custom AMI" nodegroup?

Correct

The most basic, contrived example would be a managed nodegroup using the AL2_x86_64 AMI type (EKS AMI, not custom AMI), and the user provides a custom launch template where they want to somehow do the equivalent of --local-disks raid0. Today this is a bit of a challenge since MNGs will append the bootstrap script in the last MIME doc, so you have to find various hacky ways for that invocation to pick up this config. So with either Karpenter or MNG, if there was a way to do something where users can pass in a config that does not conflict with the node joining the cluster logic, that would be ideal. something that is probably merged in with whatever defaults you all set