Automatic merge from submit-queue.
Bump channels version of dashboard to 1.7.1
Shouldn't it be a requirement to bump addons.yaml at the same time as the other files?
The current implementation fails on template which reference unset variables, it is however useful at times to permit overriding this behavior and using sprig default() for example methods to handle it
- added a new command line option --fail-on-missing (defaults to true, so keeps the current behaviour)
- updated the unit test to reflect the changes
- updated the cli docs
Automatic merge from submit-queue.
update kubernetes-dashboard image version to v1.7.1
https://github.com/kubernetes/dashboard/issues/2401, causing high CPU, is fixed in 1.7.1.
Image version number is the only change.
Automatic merge from submit-queue.
Add etcd settings to nodeup and protokube
This adds etcd settings for leader timeout and heartbeat interval to protokube. It uses the additions to `EtcdClusterSpec` that were given the go ahead in https://github.com/kubernetes/kops/pull/3663
@chrislovecnm
@robinpercy
Automatic merge from submit-queue.
Add Cloud Controller Manager addon
This adds the CCM addon for the Kubernetes cluster.
This is a follow-up PR to https://github.com/kubernetes/kops/pull/3408.
cc @chrislovecnm @andrewsykim
Automatic merge from submit-queue.
simplified AWS tutorial instruction to export AWS env variables
Since we already run `aws configure`, we can simply use the AWS CLI to fetch the key and secret instead of relying on the user to replace the value in the templated command.
Automatic merge from submit-queue.
Add kops toolbox template docs
Document the template format of new command `kops toolbox template` (https://github.com/kubernetes/kops/pull/3040)
Automatic merge from submit-queue.
Add Calico v2.5 support for Kubernetes v1.8+
Added support for Canal (Calico) v2.5.1, which is required to work with Kubernetes v1.8.0+.
Older versions of Calico relied on ThirdPartyResources API to store it's config data, however this is now fully deprecated in Kubernetes v1.8 and has moved over to CustomResourceDefinitions (CRD). Calico v2.5+ has been updated to use CRD, however there is a manual upgrade process involved to migrate the configuration data across: https://github.com/projectcalico/calico/blob/master/upgrade/v2.5/README.md
Automatic merge from submit-queue.
Add missing "-nanny" in image name.
The instructions for hot-fixing the recent dnsmasq vulnerability use a different image name than what is in use by the dnsmasq container. When the command in question is run it causes the container to fail on startup. Using the "nanny" image works, though.
Automatic merge from submit-queue.
Phase integration tests
This depends on https://github.com/kubernetes/kops/pull/3616 in order to pass.
Please only review eeafe6467c
## Use Cases
This improvement of phases and lifecycles will allow a user to:
1. allows users to have complex networking patterns that kops does not support out of the box: no IG, custom nat gw, vpn, etc
2. allows users to just run a single phase w/o dependencies
3. allows users to output tf for certain sections of phase
4. allow users to have validation fail, but still run kops
## Design
### Phase / Lifecycle Improvement
Break down lifecycles and corresponding phases into:
1. IAM - already exists
1. Network - already exists, but need to remove components
1. Security Groups - new, pretty self explanitory
1. Cluster - exists already but has too much in it
1. ELB - new will include ELBs and DNS, if required
The implementation will consist of new phases and lifecycles
### Capability for kops to fail validation but run
Currently, if kops fails validation in a lifecycle it will not run. Along with these lifecycles, I am recommending a mode where a user can allow for validation to fail.
I would like to introduce into kops a cli or API mapping that allows users to fail particular phase validation. We can start with the cli options, but with a kops server, I think we will need it in the API.
An idea
```
kops update cluster --phase cluster --allow-validate-fail=iam,network
```
This would run update cluster and allow the IAM and network validation to fail. But security groups validation would need to pass.
## This PR - test cases
This is creating the tests for the reworking of phases, and the work allowing failed validation. The cluster test, for instance, will not pass, until we allow for kops phase validation to fail, but then still allow `kops update` to run.
The TF files are pretty solid for the tests, once the work has been completed. I filed a couple of other issues in regards to no DNS for the bastion exists, and the outputs are also clashing with each other if you have TF broken into the Phases.
Kubernetes Submit Queue