Merge branch 'master' into drop-breaking-raw-block

Author: chenopis

.gitignore

@@ -29,3 +29,6 @@ nohup.out
 
 # Hugo output
 public/
+
+# User-specific editorconfig files
+.editorconfig

.travis.yml

@@ -7,16 +7,16 @@ install:
 - export PATH=$GOPATH/bin:$PATH
 - mkdir -p $HOME/gopath/src/k8s.io
 - mv $TRAVIS_BUILD_DIR $HOME/gopath/src/k8s.io/website && cd $HOME/gopath/src/k8s.io/website
-# Fetch dependencies for us to run the tests in test/examples_test.go
-- go get -t -v k8s.io/website/test
+
 # Make sure we are testing against the correct branch
+- pushd $GOPATH/src/k8s.io && git clone https://github.com/kubernetes/kubernetes && popd
 - pushd $GOPATH/src/k8s.io/kubernetes && git checkout release-1.11 && popd
-
-# Simplified deduplication of dependencies.
 - cp -L -R $GOPATH/src/k8s.io/kubernetes/vendor/ $GOPATH/src/
 - rm -r $GOPATH/src/k8s.io/kubernetes/vendor/
 
+# Fetch additional dependencies to run the tests in examples/examples_test.go
+- go get -t -v k8s.io/website/content/en/examples
+
 script:
-# TODO(bep)
-- go test -v k8s.io/website/test #fixed by https://github.com/kubernetes/website/pull/8388
+- go test -v k8s.io/website/content/en/examples
 #- ./verify-docs-format.sh

OWNERS

@@ -1,19 +1,22 @@
 # Reviewers can /lgtm /approve but not sufficient for auto-merge without an
 # approver
 reviewers:
-- zhangxiaoyu-zidif
-- xiangpengzhao
+- Rajakavitha1
 - stewart-yu
-- Rajakavitha1 
+- xiangpengzhao
+- zhangxiaoyu-zidif
+
 # Approvers have all the ability of reviewers but their /approve makes
 # auto-merge happen if a /lgtm exists, or vice versa, or they can do both
 # No need for approvers to also be listed as reviewers
 approvers:
-- heckj
 - bradamant3
 - bradtopol
-- steveperry-53
-- zacharysarah
 - chenopis
+- kbarnard10
 - mistyhacks
+- ryanmcginnis
+- steveperry-53
 - tengqm
+- zacharysarah
+- zparnold

OWNERS_ALIASES

@@ -61,11 +61,25 @@ aliases:
     - smarterclayton
     - soltysh
     - sttts
-  sig-cluster-lifecycle: #GH: sig-cluster-lifecycle-pr-reviews
+  sig-cluster-lifecycle-kubeadm-approvers: # Approving changes to kubeadm documentation
     - timothysc
+    - lukemarsden
     - luxas
     - roberthbailey
-    - fabriziopandini 
+    - fabriziopandini
+  sig-cluster-lifecycle-kubeadm-reviewers: # Reviewing kubeadm documentation
+    - timothysc
+    - lukemarsden
+    - luxas
+    - roberthbailey
+    - fabriziopandini
+    - kad
+    - xiangpengzhao
+    - stealthybox
+    - liztio
+    - chuckha
+    - detiber
+    - dixudx
   sig-cluster-ops:
     - zehicle
     - jdumars
@@ -83,10 +97,19 @@ aliases:
     - spxtr
   sig-docs: #Team: documentation; GH: sig-docs-pr-reviews
     - bradamant3
+    - bradtopol
+    - chenopis
+    - kbarnard10
+    - mistyhacks
+    - rajakavitha1
+    - ryanmcginnis
     - steveperry-53
+    - stewart-yu
+    - tengqm
+    - xiangpengzhao
     - zacharysarah
-    - bradtopol
-    - heckj
+    - zhangxiaoyu-zidif
+    - zparnold
   sig-federation: #Team: Federation; e.g. Federated Clusters
     - csbell
   sig-gcp: #Google Cloud Platform; GH: sig-gcp-pr-reviews

README.md

@@ -21,10 +21,10 @@ For more information about contributing to the Kubernetes documentation, see:
 If you'd like, you can build the Kubernetes docs using Docker. To get started, build the image locally:
 
 ```bash
-$ make docker-image
+make docker-image
 
 # The underlying command:
-$ docker build . \
+docker build . \
   --tag kubernetes-hugo \
   --build-arg HUGO_VERSION=0.40.3
 ```
@@ -33,21 +33,22 @@ You can create an image for a different version of Hugo by changing the value of
 Once the `kubernetes-hugo` image has been built locally, you can build the site:
 
 ```bash
-$ make docker-serve
+make stage
 
 # The underlying command:
-$ docker run \
+docker run \
   --rm \
   --interactive \
   --tty \
   --volume $(PWD):/src \
-  kubernetes-hugo:latest \
-  hugo
+  -p 1313:1313 \
+  kubernetes-hugo \
+  hugo server --watch --bind 0.0.0.0
 ```
 
 As when building without using a Docker container, the results of the build will be published to the `public` directory (the default output directory for [Hugo](https://gohugo.io), the static site generator used to build this site).
 
 ## Thank you!
 
 Kubernetes thrives on community participation, and we really appreciate your
-contributions to our site and our documentation!
+contributions to our site and our documentation!

config.toml

@@ -7,7 +7,7 @@ enableRobotsTXT = true
 
 disableKinds = ["taxonomy", "taxonomyTerm"]
 
-ignoreFiles = [ "^OWNERS$", "README.md", "^node_modules$" ]
+ignoreFiles = [ "^OWNERS$", "README.md", "^node_modules$", "content/en/docs/doc-contributor-tools" ]
 
 contentDir = "content/en"
 

content/.gitkeep

@@ -47,6 +47,7 @@ <h2>The Challenges of Migrating 150+ Microservices to Kubernetes</h2>
         <button id="desktopShowVideoButton" onclick="kub.showVideo()">Watch Video</button>
         <br>
         <br>
+        <br>
         <a href="https://www.lfasiallc.com/events/kubecon-cloudnativecon-china-2018/" button id= "desktopKCButton">Attend KubeCon in Shanghai on Nov. 14-15, 2018</a>
         <br>
         <br>
@@ -120,14 +121,14 @@ <h4><a href="/docs/concepts/workloads/controllers/jobs-run-to-completion/">Batch
     <main>
         <h3>Case Studies</h3>
         <div id="caseStudiesWrapper">
-          <div>
-              <p>Driving Banking Innovation with Cloud Native</p>
-              <a href="/case-studies/ing">Read more</a>
-          </div>
           <div>
               <p>Supporting Fast Decisioning Applications with Kubernetes</p>
               <a href="/case-studies/capital-one">Read more</a>
           </div>
+          <div>
+              <p>Driving Banking Innovation with Cloud Native</p>
+              <a href="/case-studies/ing">Read more</a>
+          </div>
           <div>
               <p>Cloud Native at Northwestern Mutual</p>
               <a href="/case-studies/northwestern-mutual/">Read more</a>

content/en/_index.html

@@ -8,7 +8,7 @@ At Devoxx Belgium and Devoxx Morocco, Ray Tsang and I showed a Raspberry Pi clus
 
 ### Wait! Why the heck build a Raspberry Pi cluster running Kubernetes? 
 
-We had two big reasons to build the Pi cluster at Quintor. First of all we wanted to experiment with container technology at scale on real hardware. You can try out container technology using virtual machines, but Kubernetes runs great on on bare metal too. To explore what that’d be like, we built a Raspberry Pi cluster just like we would build a cluster of machines in a production datacenter. This allowed us to understand and simulate how Kubernetes would work when we move it to our data centers.  
+We had two big reasons to build the Pi cluster at Quintor. First of all we wanted to experiment with container technology at scale on real hardware. You can try out container technology using virtual machines, but Kubernetes runs great on bare metal too. To explore what that’d be like, we built a Raspberry Pi cluster just like we would build a cluster of machines in a production datacenter. This allowed us to understand and simulate how Kubernetes would work when we move it to our data centers.  
 
 Secondly, we did not want to blow the budget to do this exploration. And what is cheaper than a Raspberry Pi! If you want to build a cluster comprising many nodes, each node should have a good cost to performance ratio. Our Pi cluster has 20 CPU cores, which is more than many servers, yet cost us less than $400. Additionally, the total power consumption is low and the form factor is small, which is great for these kind of demo systems.  
 

content/en/blog/_posts/2015-11-00-Creating-A-Raspberry-Pi-Cluster-Running-Kubernetes-The-Shopping-List-Part-1.md

@@ -57,7 +57,7 @@ While we could have decreased the “pod startup time” substantially by exclud
 
 ### Metrics from Kubernetes 1.2 
 
-So what was the result?We run our tests on Google Compute Engine, setting the size of the master VM based on on the size of the Kubernetes cluster. In particular for 1000-node clusters we use a n1-standard-32 VM for the master (32 cores, 120GB RAM).  
+So what was the result?We run our tests on Google Compute Engine, setting the size of the master VM based on the size of the Kubernetes cluster. In particular for 1000-node clusters we use a n1-standard-32 VM for the master (32 cores, 120GB RAM).  
 
 
 #### API responsiveness 

content/en/blog/_posts/2016-03-00-1000-Nodes-And-Beyond-Updates-To-Kubernetes-Performance-And-Scalability-In-12.md

@@ -30,7 +30,7 @@ There is work in progress being done in Kubernetes for image authorization plugi
 **Limit Direct Access to Kubernetes Nodes**  
 You should limit SSH access to Kubernetes nodes, reducing the risk for unauthorized access to host resource. Instead you should ask users to use "kubectl exec", which will provide direct access to the container environment without the ability to access the host.  
 
-You can use Kubernetes [Authorization Plugins](http://kubernetes.io/docs/admin/authorization/) to further control user access to resources. This allows defining fine-grained-access control rules for specific namespace, containers and operations.  
+You can use Kubernetes [Authorization Plugins](http://kubernetes.io/docs/reference/access-authn-authz/authorization/) to further control user access to resources. This allows defining fine-grained-access control rules for specific namespace, containers and operations.
 
 **Create Administrative Boundaries between Resources**  
 Limiting the scope of user permissions can reduce the impact of mistakes or malicious activities. A Kubernetes namespace allows you to partition created resources into logically named groups. Resources created in one namespace can be hidden from other namespaces. By default, each resource created by a user in Kubernetes cluster runs in a default namespace, called default. You can create additional namespaces and attach resources and users to them. You can use Kubernetes Authorization plugins to create policies that segregate access to namespace resources between different users.  

content/en/blog/_posts/2016-08-00-Security-Best-Practices-Kubernetes-Deployment.md

@@ -16,7 +16,7 @@ For users who want to scale beyond 5,000 nodes or spread across multiple regions
 
 **Security and Setup** : Users concerned with security will find that [RBAC](https://kubernetes.io//docs/admin/authorization/rbac), now _beta_ adds a significant security benefit through more tightly scoped default roles for system components. The default RBAC policies in 1.6 grant scoped permissions to control-plane components, nodes, and controllers. RBAC allows cluster administrators to selectively grant particular users or service accounts fine-grained access to specific resources on a per-namespace basis. RBAC users upgrading from 1.5 to 1.6 should view the guidance [here](https://kubernetes.io//docs/admin/authorization/rbac.md#upgrading-from-15).   
 
-Users looking for an easy way to provision a secure cluster on physical or cloud servers can use [kubeadm](https://kubernetes.io/docs/getting-started-guides/kubeadm/), which is now _beta_. kubeadm has been enhanced with a set of command line flags and a base feature set that includes RBAC setup, use of the [Bootstrap Token system](http://kubernetes.io/docs/admin/bootstrap-tokens/) and an enhanced [Certificates API](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/).  
+Users looking for an easy way to provision a secure cluster on physical or cloud servers can use [kubeadm](https://kubernetes.io/docs/getting-started-guides/kubeadm/), which is now _beta_. kubeadm has been enhanced with a set of command line flags and a base feature set that includes RBAC setup, use of the [Bootstrap Token system](http://kubernetes.io/docs/reference/access-authn-authz/bootstrap-tokens/) and an enhanced [Certificates API](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/).  
 
 **Advanced Scheduling** : This release adds a set of [powerful and versatile scheduling constructs](https://kubernetes.io/docs/user-guide/node-selection/) to give you greater control over how pods are scheduled, including rules to restrict pods to particular nodes in heterogeneous clusters, and rules to spread or pack pods across failure domains such as nodes, racks, and zones.  
 

content/en/blog/_posts/2017-03-00-Kubernetes-1.6-Multi-User-Multi-Workloads-At-Scale.md

@@ -13,7 +13,7 @@ The focus of this post is to highlight some of the interesting new capabilities
 
 **RBAC vs ABAC**  
 
-Currently there are several [authorization mechanisms](https://kubernetes.io/docs/admin/authorization/) available for use with Kubernetes. Authorizers are the mechanisms that decide who is permitted to make what changes to the cluster using the Kubernetes API. This affects things like kubectl, system components, and also certain applications that run in the cluster and manipulate the state of the cluster, like Jenkins with the Kubernetes plugin, or [Helm](https://github.com/kubernetes/helm) that runs in the cluster and uses the Kubernetes API to install applications in the cluster. Out of the available authorization mechanisms, ABAC and RBAC are the mechanisms local to a Kubernetes cluster that allow configurable permissions policies.  
+Currently there are several [authorization mechanisms](https://kubernetes.io/docs/reference/access-authn-authz/authorization/) available for use with Kubernetes. Authorizers are the mechanisms that decide who is permitted to make what changes to the cluster using the Kubernetes API. This affects things like kubectl, system components, and also certain applications that run in the cluster and manipulate the state of the cluster, like Jenkins with the Kubernetes plugin, or [Helm](https://github.com/kubernetes/helm) that runs in the cluster and uses the Kubernetes API to install applications in the cluster. Out of the available authorization mechanisms, ABAC and RBAC are the mechanisms local to a Kubernetes cluster that allow configurable permissions policies.
 
 ABAC, Attribute Based Access Control, is a powerful concept. However, as implemented in Kubernetes, ABAC is difficult to manage and understand. It requires ssh and root filesystem access on the master VM of the cluster to make authorization policy changes. For permission changes to take effect the cluster API server must be restarted.  
 

content/en/blog/_posts/2017-04-00-Rbac-Support-In-Kubernetes.md

@@ -16,7 +16,7 @@ Also, for power users, API aggregation in this release allows user-provided apis
 Security:  
 
 - [The Network Policy API](https://kubernetes.io/docs/concepts/services-networking/network-policies/) is promoted to stable. Network policy, implemented through a network plug-in, allows users to set and enforce rules governing which pods can communicate with each other. 
-- [Node authorizer](https://kubernetes.io/docs/admin/authorization/node/) and admission control plugin are new additions that restrict kubelet’s access to secrets, pods and other objects based on its node.
+- [Node authorizer](https://kubernetes.io/docs/reference/access-authn-authz/node/) and admission control plugin are new additions that restrict kubelet’s access to secrets, pods and other objects based on its node.
 - [Encryption for Secrets](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/), and other resources in etcd, is now available as alpha. 
 - [Kubelet TLS bootstrapping](https://kubernetes.io/docs/admin/kubelet-tls-bootstrapping/) now supports client and server certificate rotation.
 - [Audit logs](https://kubernetes.io/docs/tasks/debug-application-cluster/audit/) stored by the API server are now more customizable and extensible with support for event filtering and webhooks. They also provide richer data for system audit.
@@ -36,7 +36,7 @@ Extensibility:
 
 Additional Features:  
 
-- Alpha support for [external admission controllers](https://kubernetes.io/docs/admin/extensible-admission-controllers/) is introduced, providing two options for adding custom business logic to the API server for modifying objects as they are created and validating policy. 
+- Alpha support for [external admission controllers](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) is introduced, providing two options for adding custom business logic to the API server for modifying objects as they are created and validating policy. 
 - [Policy-based Federated Resource Placement](https://kubernetes.io/docs/tasks/federation/set-up-placement-policies-federation/) is introduced as Alpha providing placement policies for the federated clusters, based on custom requirements such as regulation, pricing or performance.
 
 Deprecation:   

content/en/blog/_posts/2017-06-00-Kubernetes-1.7-Security-Hardening-Stateful-Application-Extensibility-Updates.md

@@ -71,7 +71,7 @@ Once you log in, all of your clusters are available within Codefresh.
 
 
 ### Add Cluster
-To add your cluster, click the down arrow, and then click **add cluste** r, select the project and cluster name. You can now deploy images!
+To add your cluster, click the down arrow, and then click **add cluster**, select the project and cluster name. You can now deploy images!