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 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
Flannel: change default backend type
We support udp, which has to the default for backwards-compatibility,
but also new clusters will now use vxlan.
This will allow us to set CIDRs for nodeport access, which in turn will
allow e2e tests that require nodeport access to pass.
Then add a feature-flagged flag to `kops create cluster` to allow
arbitrary setting of spec values; currently the only value supported is
cluster.spec.nodePortAccess
The current implementation does not ignore any possible interpolation of bash in the content. This PR wrapped the various spec content in 'EOF' to ignore all.
- updated the tests to reflect the changes
- wrapped the component configuration in 'eof' to ensure interpolation is ignored
Automatic merge from submit-queue
Add cluster spec to node user data so component config changes are detected
Related to #3076
Some cluster changes such as component config modifications are not picked up when performing updates (nodes are not marked as `NEEDUPDATE`). This change introduces the ability to:
1. Include certain cluster specs within the node user data file ~(`enableClusterSpecInUserData: true`)~
2. ~Encode the cluster spec string before placing within the user data file (`enableClusterSpecInUserData: true`)~
~The above flags default to false so shouldn't cause any changes to existing clusters.~
Following feedback I've removed the optional API flags, so component config is included by default within the user data. This WILL cause all nodes to have a required update to their bootstrap scripts.
Automatic merge from submit-queue
Use SSL in ELB API server health check
This switch causes the ELB to perform a SSL handshake and makes the
`I0427 03:57:55.059255 1 logs.go:41] http: TLS handshake error from IP:PORT: EOF`
disappear from the apiserver logs.
Tested manually and everything looks ✅
Inspiration from https://github.com/kubernetes-incubator/kube-aws/pull/604
This switch causes the ELB to perform a SSL handshake and makes the
`I0427 03:57:55.059255 1 logs.go:41] http: TLS handshake error from IP:PORT: EOF`
disappear from the apiserver logs.
Added:
- Instance role name
- Instance role arn
as terraform outputs, this can then be references later on to
use as sts:assume role, create after this one
- new property is only used when KubernetesVersion is 1.6 or greater
- taints are passed to kubelet via --register-with-taints flag
- Set a default NoSchedule taint on masters
- Set --register-schedule=true when --register-with-taints is used
- Changed the log message in taints.go to be less alarming if taints are
found - since they are expected on 1.6.0+ clusters
- Added Taints section to the InstanceGroup docs
- Only default taints are allowed in the spec pre-1.6
- Custom taint validation happens as soon as IG specs are edited.
We build a statically linked version and distribute it with kops.
Note that our version of socat does not include libssl, but kubernetes
does not use it anyway.
- --cloud-labels will be applied to every kops-created resource
- Also ran apimachinery to regenerated the conversions for the new
Cluster.ClusterLabels property.
* Integrating Canal (Flannel + Calico) for CNI
Initial steps to integrate Canal as a CNI provider for kops
Removed CNI in help as per chrislovecnm
* Integration tests, getting closer to working
- Added some integration tests for Canal
- Finding more places Canal needed to be added
- Sneaking in update to Calico Policy Controller
* Add updated conversion file
* turned back on canal integration tests
* fixed some rebase issues
* Fixed tests and flannel version
* Fixed canal yaml, and some rebasing errors
- Added some env vars to the install-cni container to get the proper
node name handed off
* Added resource limits
- set resource limits on containers for Canal
- Ran through basic calico tutorials to verify functionality
* Updating Calico parts to Calico 2.0.2
We probably should use a canned channel, but in the interim this is
probably the best option, otherwise every time we update the stable
channel we break the tests.
* The master zones are the default set of zones unless explicitly set
* The master count is the number of master zones unless explicitly set
* We then round-robin around the zones
* We append a suffix -1, -2, -3 if there are more masters than zones
* We trim prefixes to keep etcd member names short
Fix#1653
Rather than always setting it (incorrectly in many cases), we infer it
from the subnets.
Users can still set it, we just don't default it to a value we then
ignore.
Fix#1582
Justin Santa Barbara
Kubernetes Submit Queue
chrislovecnm
rushtehrani
Kashif Saadat
Rohith
Derek VerLee
Johannes Würbach
Lars Lehtonen
Hanfei Shen
Pierre-Alexandre St-Jean
Bill Broach
dima
Miao Luo
Adam H. Leventhal
Robin Percy
Eric Hole
yissachar
Jakub Paweł Głazik
Kris Nova
Zac Blazic
Matthew Mihok
Stephen Schlie
Thomas Peitz
Vincent Ambo