Release 1.11 ga

Makefile

@@ -1,4 +1,4 @@
-# Copyright 2016 The Kubernetes Authors.
+# Copyright 2019 The Kubernetes Authors.
 #
 # Licensed under the Apache License, Version 2.0 (the "License");
 # you may not use this file except in compliance with the License.
@@ -54,7 +54,7 @@ unexport KOPS_BASE_URL KOPS_CLUSTER_NAME KOPS_RUN_OBSOLETE_VERSION KOPS_STATE_ST
 unexport SKIP_REGION_CHECK S3_ACCESS_KEY_ID S3_ENDPOINT S3_REGION S3_SECRET_ACCESS_KEY VSPHERE_USERNAME VSPHERE_PASSWORD
 
 # Keep in sync with upup/models/cloudup/resources/addons/dns-controller/
-DNS_CONTROLLER_TAG=1.11.0-alpha.1
+DNS_CONTROLLER_TAG=1.11.0
 
 # Keep in sync with logic in get_workspace_status
 # TODO: just invoke tools/get_workspace_status.sh?
@@ -486,6 +486,7 @@ dep-ensure: dep-prereqs
 	rm -rf vendor/k8s.io/code-generator/cmd/set-gen/
 	rm -rf vendor/k8s.io/code-generator/cmd/go-to-protobuf/
 	rm -rf vendor/k8s.io/code-generator/cmd/import-boss/
+	rm -rf vendor/github.com/docker/docker/contrib/
 	make bazel-gazelle
 
 
@@ -772,8 +773,14 @@ bazel-version-dist: bazel-crossbuild-nodeup bazel-crossbuild-kops bazel-protokub
 bazel-upload: bazel-version-dist # Upload kops to S3
 	aws s3 sync --acl public-read ${BAZELUPLOAD}/ ${S3_BUCKET}
 
-#-----------------------------------------------------------  
-# static html documentation  
+# prow-postsubmit is run by the prow postsubmit job
+# It uploads a build to a staging directory, which in theory we can publish as a release
+.PHONY: prow-postsubmit
+prow-postsubmit: bazel-version-dist
+	${UPLOAD} ${BAZELUPLOAD}/kops/${VERSION}/ ${UPLOAD_DEST}/${KOPS_RELEASE_VERSION}-${GITSHA}/
+
+#-----------------------------------------------------------
+# static html documentation
 
 .PHONY: live-docs
 live-docs:
@@ -783,8 +790,9 @@ live-docs:
 build-docs:
 	@docker run --rm -it -v ${PWD}:/docs aledbf/mkdocs:0.1 build
 
+# Update machine_types.go
 .PHONY: update-machine-types
-update-machine-types: #Update machine_types.go
-	go build -o hack/machine_types/machine_types  ${KOPS_ROOT}/hack/machine_types/machine_types.go
+update-machine-types:
+	go build -o hack/machine_types/machine_types  ${KOPS_ROOT}/hack/machine_types/
 	hack/machine_types/machine_types --out upup/pkg/fi/cloudup/awsup/machine_types.go
 	go fmt upup/pkg/fi/cloudup/awsup/machine_types.go

README.md

@@ -197,7 +197,7 @@ Our office hours call is recorded, but the tone tends to be casual. First-timers
 Office hours are designed for ALL of those contributing to kops or the community. Contributions are not limited to those who commit source code. There are so many important ways to be involved- 
  - helping in the slack channels
  - triaging/writing issues 
- - thinking about the topics raised at office hours and forming and advocating for your good ideas  forming opinions
+ - thinking about the topics raised at office hours and forming and advocating for your good ideas forming opinions
  - testing pre-(and official) releases
 
 Although not exhaustive, the above activities are extremely important to our continued success and are all worth contributions. If you want to talk about kops and you have doubt, just come.

ROADMAP.md

@@ -1,99 +1,51 @@
 # ROADMAP
 
-The kops 1.N.x version officially supports kubernetes 1.N.x and earlier.  While kubernetes 1.99 will likely run with kops 1.98,
-the configuration will probably not be correct (for example docker versions, CNI versions etc).
+## VERSION SUPPORT
+kops 1.N.x _officially_ supports Kubernetes 1.N.x and prior versions. We understand that those in the community run a wide selection of versions and we do our best to maintain backward compatibility as far as we can. 
 
-kops 1.N.0 is released when it is believed that kubernetes 1.N.x is stable, along with all the core addons (e.g. networking).
-This can mean that kops can release months after the release of kubernetes.  It's also not a deterministic release criteria,
-particularly with some networking plugins that are supported by kops but themselves still under development.  We discussed
-this challenge in kops office hours in March 2018, and the consensus was that we want to keep this, but that we should release
-alphas & betas much earlier so that users can try out new kubernetes versions on release day.
+However, kops 1.N.x does NOT support Kubernetes 1.N+1.x. Sometimes you get lucky and kops 1.N will technically install a later version of Kubernetes, but we cannot guarantee or support this situation. As always, we recommend waiting for the official release of kops with minor version >= the version of Kubernetes you wish to install. Please see the [compatibility matrix](README.md#Compatibility_Matrix) for further questions.
 
-For the next few releases this means that:
+## RELEASE SCHEDULE
+There is a natural lag between the release of Kubernetes and the corresponding version of kops that has full support for it. While the first patch versions of a minor Kubernetes release are burning in, the kops team races to incorporate all the updates needed to release. Once we have both some stability in the upstream version of Kubernetes AND full support in kops, we will cut a release that includes version specific configuration and a selection of add-ons to match.
 
-* 1.9.0 release target April 7th
-* 1.10 alpha.1 with release of kops 1.9.0 (April 7th)
-* 1.10 release target April 28th
-* 1.11 alpha.1 at release of kops 1.10
-* 1.11 beta.1 at release of k8s 1.11
-* 1.12 alpha.1 at release of kops 1.11 etc
+In practice, sometimes this means that kops release lags the upstream release by 1 or more months. We sincerely try to avoid this scenario- we understand how important this project is and respect the need that teams have to maintain their clusters. 
 
+Our goal is to have an official kops release no later than a month after the corresponding Kubernetes version is released. Please help us achieve this timeline and meet our goals by jumping in and giving us a hand. We always need assistance closing issues, reviewing PRs, and contributing code! Stop by office hours if you're interested. 
 
-### _kops 1.10_
+A rough outline of the timeline/release cycle with respect to the Kubernetes release follows. We are revising the automation around the release process so that we can get alpha and beta releases out to the community and other developers much faster for testing and to get more eyes on open issues.
 
-* Support for kubernetes 1.10
-* Full support for GCE
-* Make the etcd-backup tool enabled-by-default, so everyone should have backups.
-* Allow users to opt-in to the full etcd-manager.
-* Make etcd3 the default for new clusters, now that we have an upgrade path.
-* Beginning of separation of addon functionality
-* Support for more clouds (Aliyun, DigitalOcean, OpenStack)
+Example release timeline based on Kubernetes quarterly release cycle:
+July 1: Kubernetes 1.W.0 is released.
+July 7: kops 1.W.beta1
+July 21: kops 1.W.0 released
+August 15: kops 1.W+1alpha1
+August 31: kops 1.W+1alpha2
+etc...
+September 25: Kubernetes1.W+1.RC-X
+Oct 1: Kubernetes 1.W+1.0
+Oct 7: kops 1.W+1beta1
+Oct 21: kops 1.W+1.0
 
-### _kops 1.11_
 
-* Make the etcd-manager the default, deprecate the protokube-integrated approach
-* kops-server
-* Machines API support (including bare-metal)
+## UPCOMING RELEASES
 
-# HISTORICAL
+### kops 1.11
 
-# 1.9
+* Full support for Kubernetes 1.11
+* Alpha support for bundles (etcd-manager is the test case)
+* etcd3 will be the default for newly created clusters. 
+  - Existing clusters will continue to run etcd2 but will be prompted to upgrade to 3. The upgrade will become mandatory in 1.12.
+* Default to Debian stretch images which increase support for newer instance types
+* Improvements to the release process that will make it easier for community members to cut releases.
 
-## Must-have features
+### kops 1.12
+* Full support for Kubernetes 1.12
+* Improvements to etcd3 support
 
-* Support for k8s 1.9 _done_
-* etcd backup support _done_
-
-## Other features
-
-* Use NodeAuthorizer / bootstrap kubeconfigs [#3551](https://github.com/kubernetes/kops/issues/3551) _no progress; may be less important with machines API_
-
-# 1.8
-
-## Must-have features
-
-* Support for k8s 1.8
-
-## Other features
-
-* Improved GCE support
-* Support for API aggregation
-
-# 1.7
-
-## Must-have features
-
-* Support for k8s 1.7
-
-## Other features we are working on in the 1.7 timeframe
-
-* etcd controller to allow moving between versions
-* kops server for better team scenarios
-* support for bare-metal
-* more gossip backends
-* IAM integration
-* more cloud providers
-* promote GCE to stable
-* RBAC policies for all components
-* bringing rolling-update out of alpha
-
-## 1.6
-
-### Must-have features
-
-* Support for k8s 1.6 _done_
-* RBAC enabled by default _yes, but we kept RBAC optional_
-
-## Other features we are working on in the 1.6 timeframe
-
-* Support for GCE _alpha_
-* Support for Google's [Container Optimized OS](https://cloud.google.com/container-optimized-os) (formerly known as GCI) _alpha_
-* Some support for bare-metal _private branches, not merged_
-* Some support for more cloud providers _initial work on vsphere_
-* Some IAM integration _discussions, but no code_
-* Federation made easy _no progress_
-* Authentication made easy _no progress_
-* Integration with kubeadm _kops now uses kubeadm for some RBAC related functionality_
-* CloudFormation integration on AWS _beta_
+## UPCOMING FEATURES
+NB: These are features that are in process and may be introduced behind flags or in alpha capacity but are not explicitly targeting specific releases. 
 
+* Documentation revamp that is closer to k8s.io: Stories and walkthroughs of common scenarios, restructure and update information
+* Additional cloud provider support: spotinst, aliyun, azure...?
+* Revisit recommended base cluster configurations to get them modernized. Update recommendations and defaults for instances, disks, etc, 
 

WORKSPACE

@@ -1,24 +1,27 @@
+load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
+load("@bazel_tools//tools/build_defs/repo:git.bzl", "git_repository")
+
 #=============================================================================
 # Go rules
 
 http_archive(
     name = "io_bazel_rules_go",
-    url = "https://github.com/bazelbuild/rules_go/releases/download/0.14.1/rules_go-0.14.1.tar.gz",
-    sha256 = "ee0e3b346388c447f13009d789c8bf2d7bae4643ac70bd7997ded0ad09b2fff7",
+    url = "https://github.com/bazelbuild/rules_go/releases/download/0.15.11/rules_go-0.15.11.tar.gz",
+    sha256 = "7b7c74740e3a757204ddb93241ce728906af795d6c6aa0950e0e640716dc1e4a",
 )
 
 http_archive(
     name = "bazel_gazelle",
-    url = "https://github.com/bazelbuild/bazel-gazelle/releases/download/0.14.0/bazel-gazelle-0.14.0.tar.gz",
-    sha256 = "c0a5739d12c6d05b6c1ad56f2200cb0b57c5a70e03ebd2f7b87ce88cabf09c7b",
+    url = "https://github.com/bazelbuild/bazel-gazelle/releases/download/0.15.0/bazel-gazelle-0.15.0.tar.gz",
+    sha256 = "6e875ab4b6bf64a38c352887760f21203ab054676d9c1b274963907e0768740d",
 )
 
 load("@io_bazel_rules_go//go:def.bzl", "go_rules_dependencies", "go_register_toolchains")
 
 go_rules_dependencies()
 
 go_register_toolchains(
-    go_version = "1.10.3",
+    go_version = "1.10.8",
 )
 
 load("@bazel_gazelle//:deps.bzl", "gazelle_dependencies")
@@ -31,7 +34,7 @@ gazelle_dependencies()
 git_repository(
     name = "io_bazel_rules_docker",
     remote = "https://github.com/bazelbuild/rules_docker.git",
-    tag = "v0.4.0",
+    tag = "v0.5.1",
 )
 
 load(
@@ -54,7 +57,7 @@ container_pull(
 git_repository(
     name = "distroless",
     remote = "https://github.com/googlecloudplatform/distroless.git",
-    commit = "886114394dfed219001ec3b068b139a3456e49d4",
+    commit = "3585653b2b0d33c3fb369b907ef68df8344fd2ad",
 )
 
 load(

addons/cluster-autoscaler/cluster-autoscaler.sh

@@ -14,6 +14,8 @@
 # See the License for the specific language governing permissions and
 # limitations under the License.
 
+set -e
+
 #Set all the variables in this section
 CLUSTER_NAME="myfirstcluster.k8s.local"
 CLOUD_PROVIDER=aws
@@ -61,6 +63,7 @@ cat > asg-policy.json << EOF
             "Action": [
                 "autoscaling:DescribeAutoScalingGroups",
                 "autoscaling:DescribeAutoScalingInstances",
+                "autoscaling:DescribeLaunchConfigurations",
                 "autoscaling:DescribeTags",
                 "autoscaling:SetDesiredCapacity",
                 "autoscaling:TerminateInstanceInAutoScalingGroup"

addons/cluster-autoscaler/v1.10.0.yaml

@@ -155,7 +155,7 @@ spec:
             - --stderrthreshold=info
             - --cloud-provider={{CLOUD_PROVIDER}}
             - --skip-nodes-with-local-storage=false
-            - --nodes={{MIN_NODES}:{{MAX_NODES}}:{{GROUP_NAME}}
+            - --nodes={{MIN_NODES}}:{{MAX_NODES}}:{{GROUP_NAME}}
           env:
             - name: AWS_REGION
               value: {{AWS_REGION}}

addons/metrics-server/README.md

@@ -1,9 +1,27 @@
 # Kubernetes Metrics Server
 
+## User guide
+
+You can find the user guide in
+[the official Kubernetes documentation](https://kubernetes.io/docs/tasks/debug-application-cluster/core-metrics-pipeline/).
+
+## Design
+
+The detailed design of the project can be found in the following docs:
+
+- [Metrics API](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/resource-metrics-api.md)
+- [Metrics Server](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md)
+
+For the broader view of monitoring in Kubernetes take a look into
+[Monitoring architecture](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/monitoring_architecture.md)
+
+## Deployment
+
 Compatibility matrix:
 
 Metrics Server | Metrics API group/version | Supported Kubernetes version
 ---------------|---------------------------|-----------------------------
+0.3.x          | `metrics.k8s.io/v1beta1`  | 1.8+
 0.2.x          | `metrics.k8s.io/v1beta1`  | 1.8+
 0.1.x          | `metrics/v1alpha1`        | 1.7
 
@@ -18,3 +36,44 @@ $ kubectl apply -f https://raw.githubusercontent.com/kubernetes/kops/master/addo
 # Kubernetes 1.8+
 $ kubectl apply -f https://raw.githubusercontent.com/kubernetes/kops/master/addons/metrics-server/v1.8.x.yaml
 ```
+
+## Flags
+
+Metrics Server supports all the standard Kubernetes API server flags, as
+well as the standard Kubernetes `glog` logging flags.  The most
+commonly-used ones are:
+
+- `--logtostderr`: log to standard error instead of files in the
+  container.  You generally want this on.
+
+- `--v=<X>`: set log verbosity.  It's generally a good idea to run a log
+  level 1 or 2 unless you're encountering errors.  At log level 10, large
+  amounts of diagnostic information will be reported, include API request
+  and response bodies, and raw metric results from Kubelet.
+
+- `--secure-port=<port>`: set the secure port.  If you're not running as
+  root, you'll want to set this to something other than the default (port
+  443).
+
+- `--tls-cert-file`, `--tls-private-key-file`: the serving certificate and
+  key files.  If not specified, self-signed certificates will be
+  generated, but it's recommended that you use non-self-signed
+  certificates in production.
+
+Additionally, Metrics Server defines a number of flags for configuring its
+behavior:
+
+- `--metric-resolution=<duration>`: the interval at which metrics will be
+  scraped from Kubelets (defaults to 60s).
+
+- `--kubelet-insecure-tls`: skip verifying Kubelet CA certificates.  Not
+  recommended for production usage, but can be useful in test clusters
+  with self-signed Kubelet serving certificates.
+
+- `--kubelet-port`: the port to use to connect to the Kubelet (defaults to
+  the default secure Kubelet port, 10250).
+
+- `--kubelet-preferred-address-types`: the order in which to consider
+  different Kubelet node address types when connecting to Kubelet.
+  Functions similarly to the flag of the same name on the API server.
+s