Added new Import-EKSKubeConfig Cmdlet for updating kubeconfig files

[aberus]

Description

This cmdlet returns an object containing the configured current-context and the path of the updated kubeconfig file. It provides similar functionality to AWS CLI Command aws eks update-kubeconfig. It lossy based on Get-EKSCluster cmdlet.

Motivation and Context

Kubeconfig file generation for EKS #62

Testing

Import-EKSKubeConfig
    -Name <String>
    -KubeConfigPath <String>
    -RoleArn <String>
    -Alias <String>
    -UserAlias <String>
    -ClientConfig <AmazonEKSConfig>

Example 1

PS C:> Import-EKSKubeConfig -Name example -Region us-west-1
Context                                            Path
-------                                            ----
arn:aws:eks:us-west-2:012345678910:cluster/example /Users/ericn/.kube/config

Screenshots (if appropriate)

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

We require a second engineer to validate the PR before merging

• [ ] My code builds in Gamma and passes backward compatibility validation (required)
• [x] My code follows the code style of this project
• [x] My change requires a change to the documentation
• [ ] I have updated the documentation accordingly
• [x] I have read the README document
• [ ] I have added tests to cover my changes
• [ ] All new and existing tests passed

New/existing dependencies impact assessment, if applicable

Added dependency YamlDotNet

Note to reviewers: Please follow runbook to update the internal open source attribution tool

License

• [x] I confirm that this pull request can be released under the Apache 2 license

[afroz429]

Thanks for the PR.

All the csproj files are generated by the generator during the build process. So the changes that are made directly to AWS.Tools.EKS.csproj will be lost after the build. Here's the location of the template where the change needs to be made.

Before the change is made, the SDK team will need to review if the licensing of YamlDotNet is compatible with aws licensing. if yes, then the decision needs to be made if it make sense to take the dependency in the common module or service specific module.

We will discuss with the team and get back to you soon.

[jnunn-aws]

We have discussed as a team and decided that there's not enough confidence in taking a runtime dependency on YamlDotNet. We're not aware of a reliable way to provide this functionality without a YAML parser so there does not appear to be a path forward to implement this request.