Automatic merge from submit-queue. .
Allow specifying a SSH key name for AWS
Related to #2309, this allows naming an existing key pair using the
cluster spec field `sshKeyName`.
In our use case, kops can now be used without providing the ability to
create EC2 key pairs.
Automatic merge from submit-queue
Makefile remove redundant logic
The `verify-gendocs` target in the Makefile checks for the existence of the kops binary. By making the kops binary a dependency, this check need not exist.
I've silenced the commands in this target by prepending them with `@`, so all that the end-user sees is the echoed text, not the shell logic.
Automatic merge from submit-queue
Add file assets to node user data scripts, fingerprint fileAssets and hooks content.
**Changes made:**
- Include FileAssets in the bootstrapscript (user-data for all nodes), selectively dependent on the roles specified for each asset.
- Fingerprint the sections of the FileAssets (Content) and Hooks (Manifests, ExecContainer Commands) Specs within the bootstrap script to reduce size (otherwise this can very quickly hit the 16KB user data limit with AWS).
Automatic merge from submit-queue
Revision to IAM Policies created by Kops
Based off of the work done by @chrislovecnm in PR #2497.
This PR tightens down the IAM policies created for Master & Node instance groups. The Cluster Spec `IAMSpec.Legacy` flag is used to control application of stricter policy rules, which is defaulted to true for existing clusters (to limit potential regression impact), and false for new cluster creation.
Automatic merge from submit-queue
Add romana to built-in CNI options
This PR adds `romana` as a networking option for kops.
It installs the latest "preview" release of Romana v2.0, which provides the expected features in terms of IP allocations and route configuration. Network policy features are being ported to 2.0 and will be in the final release. (We intend to submit a followup PR for kops as part of that rolling out that release.)
Note: in this setup, we're using the etcd cluster that kops deploys for k8s. This isn't ideal, but some possibilities (eg: StatefulSets) aren't practical for the CNI itself, and creating a parallel etcd cluster via manifests seemed to be a more-intrusive approach than using the existing one.
If this is a concern or problem, then I'm very open to discussing and implementing it based on your suggestions.
Also, some functionality is exclusive to AWS environments. Other cloud platforms are on Romana's roadmap but not developed yet. Let me know that restriction needs to be enforced in code or directly documented.
Automatic merge from submit-queue
Makefile improvements
Makefile separate install directive from kops
Makefile TESTABLE_PACKAGES variable to opt-out of testing
Makefile .build/local to keep development kops and go-bindata out of PATH
Makefile fewer PHONY targets that actually generate artifacts
Makefile prevent root-owned artifacts
Automatic merge from submit-queue
Add a doc to describe how to use kops in AWS China
Closes#2933, closes#3282.
@wangycc, @mgyong, @hb404 This doc might be helpful for you guys to deploy a cluster in AWS China Region.
@chrislovecnm, @justinsb Please help to review. Thanks.
Automatic merge from submit-queue
add autoscaling:DescribeLaunchConfigurations permission
As of 0.6.1, Cluster Autoscaler supports [scaling node groups from/to 0](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler/cloudprovider/aws#scaling-a-node-group-to-0), but requires the `autoscaling:DescribeLaunchConfigurations` permission.
It'd be great to have this in kops since this permission needs to be re-added back to the master policy every time the cluster is updated.
Automatic merge from submit-queue
small docs improvement
Make cmd1 populate the var for cmd2
Using `tee /dev/stderr` allows the user to still get output if they copy-pasta the first command. The other changes prepare the HZC variable so it can be used if they copy-pasta the second command.
Automatic merge from submit-queue
Added ability to set --service-node-port-range
Addresses: #3052 and #3326
From what I can tell, `--service-node-port-range` has been a valid option forever, so I haven't worried about k8s versions.
@justinsb @chrislovecnm let me know if any changes are required.
Lars Lehtonen