It'd be handy to provide an SSH helper, as right now it's not very trial to jump into a node, as you have to remember kubectl command, or look in EC2 console (or use some other command). Most of the time I just want to SSH to any of the nodes.
@karinnainiguez did you intend to unassign this?
As @bowlesns was also asking abou this, I though I should clarify the use-cases a little more.
The intention would be to provide debugging utility to those who are using a custom AMI, or debugging eksctl. To start with, we probably want to SSH into the host, but in the future we may consider SSH into a privileged toolbox container, but there is no particular use for that at the moment.
As far as debugging use-case is concerned, we should be looking at EC2 API for node IPs, because one should be able to debug a node that hasn't joined the cluster. I'd guess default mode should be to SSH into any node, and specific node name should be an option also, but not required.
@errordeveloper thanks for checking! It was intentional, my coworker @kschumy is researching this one.
:)
@gotjosh is willing to take this one!
Anyone working on this ??
@thapakazi not as far as I'm aware, please feel free to have a go! I'm happy to chat on Slack, if you need help finding your way around the codebase.
Great, I would love to do it :heart_eyes:
I will ping you on slack as needby. Thanks :)
I have started working on this. I am thinking of:
eksctl utils ssh node...(master)âš¡ % go run ./cmd/eksctl/*.go utils list-nodes ~/go/src/github.com/thapakazi/eksctl
[ℹ] listing the worker nodes...
Host myeks-ng-96d7c0d7-Node
hostname 192.168.103.219
User ec2-user
Port 22
Host myeks-ng-96d7c0d7-Node
hostname 192.168.167.172
User ec2-user
Port 22
Sample Example HELP
$ go run ./cmd/eksctl/*.go utils list-nodes --help
List the nodes in the cluster in ssh config format
Usage: eksctl utils list-nodes [flags]
Common flags:
-C, --color string toggle colorized logs (true,false,fabulous) (default "true")
-h, --help help for this command
-v, --verbose int set log level, use 0 to silence, 4 for debugging and 5 for debugging with AWS debug logging (default 3)
Use 'eksctl utils list-nodes [command] --help' for more information about a command.
I am using ec2 apis from my old easyssh/library. Suggestion Please...
Oh, great! Do you mind opening an WIP PR and we can discuss there?
From that PR:
It might be nicer to use SSM Session Manager, rather than wrapping the SSH binary. You could then initiate a console session via either the AWS Management Console, or via the awscli (which eksctl could wrap).
https://cloudonaut.io/goodbye-ssh-use-aws-session-manager-instead/
This has some nice benefits:
- Easy support for node groups that sit in private subnets, rather than working with bastion hosts etc
- Better auditing/permission model
- No need to modify ssh_config, or depend on the user having an ssh binary present
You could still call the feature 'eksctl utils ssh' (as i suspect that will be the best UX for people), but just have the actual implementation use SSM.
_Originally posted by @PaulMaddox in https://github.com/weaveworks/eksctl/pull/787#issuecomment-497269156_
As @michaelbeaumont suggested using the Simple Session Manager (SSM) looks like a simpler way to connect to the nodes. Taking a look at the aws-sdk it does have a package for it https://docs.aws.amazon.com/sdk-for-go/api/service/ssm/#SSM.StartSession
I tried playing around with this locally and could not succesfully connect to an EKS node. Looking into it, it appears that SSM is not enabled by default in EKS nodes (related issue: https://github.com/aws/containers-roadmap/issues/593). You can install SSM as part of a custom AMI config, but this still means that the majority of EKS nodes are unlikely to have SSM installed, so having a eksctl utils ssh command that uses SSM probably won't be the best solution.
PR merged to enable turning on SSM https://github.com/weaveworks/eksctl/pull/2754
@aclevername I think this is done, right?
@aclevername I think this is done, right?
The SSM feature makes it easier to ssh on, but it's not a command through eksctl or a fix for existing clusters. So not quite?
Good point. However, I don't think we'll ever priortize anything beyond enableSSM + aws ssm start-session. I also don't think we'll prioritize supporting existing clusters. I'm going to close it but feel free to open it up again.