Merge branch 'master' into release-1.9

2017-12-15 13:11:00 -06:00
parent 989acbf6f8 0e628e7895
commit c4ea942a40
13 changed files with 273 additions and 122 deletions
@@ -1,6 +1,6 @@
 id: node
 name: Node
-full-link: /docs/concepts/architecture/node
+full-link: /docs/concepts/architecture/nodes/
 aka:
 - Minion
 related:
@@ -0,0 +1,13 @@
 id: replica-set
 name: ReplicaSet
 full-link: https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/
 related:
 - replication-controller
 tags:
 - core-object
 - architecture
 short-description: >
  ReplicaSet is the next-generation Replication Controller.
 long-description: >
  ReplicaSet, like ReplicationController, ensures that a specified number of pods replicas are running at one time.
  ReplicaSet supports the new set-based selector requirements as described in the labels user guide, whereas a Replication Controller only supports equality-based selector requirements.
@@ -1,6 +1,6 @@
 id: volume
 name: Volume
-full-link: kubernetes.io/docs/concepts/storage/volumes/
+full-link: /docs/concepts/storage/volumes/
 related:
 - pod
 - container
@@ -6,7 +6,7 @@ toc:
 - title: Native Tools
  section:
  - title: Kubectl
-    path: /docs/user-guide/kubectl/
+    path: /docs/reference/kubectl/overview/
  - title: Kubeadm
    path: /docs/getting-started-guides/kubeadm
  - title: Kubefed
@@ -140,8 +140,8 @@
 /docs/contribute/style-guide/     /docs/home/contribute/style-guide/ 301
 /docs/contribute/write-new-topic/        /docs/home/contribute/write-new-topic/ 301
-/docs/deprecate/     /ddocs/reference/deprecation-policy/ 301
+/docs/deprecate/     /docs/reference/deprecation-policy/ 301
-/docs/deprecated/     /ddocs/reference/deprecation-policy/ 301
+/docs/deprecated/     /docs/reference/deprecation-policy/ 301
 /docs/deprecation-policy/     /docs/reference/deprecation-policy/ 301
 /docs/federation/api-reference/     /docs/reference/federation/v1/operations/ 301
@@ -167,6 +167,7 @@
 /docs/getting-started-guides/juju/     /docs/getting-started-guides/ubuntu/installation/ 301
 /docs/getting-started-guides/kargo/     /docs/getting-started-guides/kubespray/ 301
 /docs/getting-started-guides/kubeadm/     /docs/setup/independent/create-cluster-kubeadm/ 301
 /docs/getting-started-guides/kubectl/     /docs/reference/kubectl/overview/ 301
 /docs/getting-started-guides/logging/     /docs/concepts/cluster-administration/logging/ 301
 /docs/getting-started-guides/logging-elasticsearch/     /docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/ 301
 /docs/getting-started-guides/meanstack/     https://medium.com/google-cloud/running-a-mean-stack-on-google-cloud-platform-with-kubernetes-149ca81c2b5d/ 301
@@ -235,6 +236,7 @@
 /docs/tasks/configure-pod-container/downward-api-volume-expose-pod-information/     /docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/ 301
 /docs/tasks/configure-pod-container/environment-variable-expose-pod-information/     /docs/tasks/inject-data-application/environment-variable-expose-pod-information/ 301
 /docs/tasks/configure-pod-container/limit-range/     /docs/tasks/administer-cluster/cpu-memory-limit/ 301
 /docs/tasks/configure-pod-container/opaque-integer-resource/    /docs/concepts/configuration/manage-compute-resources-container/#opaque-integer-resources-alpha-feature 301
 /docs/tasks/configure-pod-container/projected-volume/     /docs/tasks/configure-pod-container/configure-projected-volume-storage/ 301
 /docs/tasks/configure-pod-container/romana-network-policy/     /docs/tasks/administer-cluster/romana-network-policy/ 301
 /docs/tasks/configure-pod-container/weave-network-policy/     /docs/tasks/administer-cluster/weave-network-policy/ 301
@@ -343,7 +345,7 @@
 /docs/user-guide/kubectl-conventions/     /docs/reference/kubectl/conventions/
 /docs/user-guide/kubectl-cheatsheet/     /docs/reference/kubectl/cheatsheet/  
 /docs/user-guide/kubectl/1_5/*     https://v1-5.docs.kubernetes.io/docs/user-guide/kubectl/v1.5/ 301
-/docs/user-guide/kubectl/kubectl_*/     /docs/user-guide/kubectl/v1.7/#:splat 301
+/docs/user-guide/kubectl/kubectl_*/     /docs/reference/generated/kubectl/kubectl-commands#:splat 301
 /docs/user-guide/kubectl/v1.5/node_modules/*     https://v1-5.docs.kubernetes.io/docs/user-guide/kubectl/v1.5/ 301
 /docs/user-guide/kubectl/v1.6/node_modules/*     https://v1-6.docs.kubernetes.io/docs/user-guide/kubectl/v1.6/ 301
 /docs/user-guide/labels/     /docs/concepts/overview/working-with-objects/labels/ 301
@@ -422,7 +424,7 @@
 /v1.1/docs/admin/networking.html     /docs/concepts/cluster-administration/networking/     301
 /v1.1/docs/getting-started-guides/     /docs/tutorials/kubernetes-basics/ 301
-https://kubernetes-io-v1-7.netlify.com/*    https://v1-7.docs.kubernetes.io/"splat 301
+https://kubernetes-io-v1-7.netlify.com/*    https://v1-7.docs.kubernetes.io/:splat 301
 /docs/admin/cloud-controller-manager/     /docs/reference/generated/cloud-controller-manager/ 301
 /docs/admin/kube-apiserver/     /docs/reference/generated/kube-apiserver/ 301
@@ -317,7 +317,7 @@ For an identity provider to work with Kubernetes it must:
 3.  Have a CA signed certificate (even if the CA is not a commercial CA or is self signed)
 A note about requirement #3 above, requiring a CA signed certificate.  If you deploy your own identity provider (as opposed to one of the cloud providers like Google or Microsoft) you MUST have your identity provider's web server certificate signed by a certificate with the `CA` flag set to `TRUE`, even if it is self signed.  This is due to GoLang's TLS client implementation being very strict to the standards around certificate validation.  If you don't have a CA handy, you can use [this script](https://github.com/coreos/dex/blob/1ee5920c54f5926d6468d2607c728b71cfe98092/examples/k8s/gencert.sh) from the CoreOS team to create a simple CA and a signed certificate and key pair.
-Or you can use [this similar script](https://raw.githubusercontent.com/TremoloSecurity/openunison-qs-kubernetes/master/makecerts.sh) that generates SHA256 certs with a longer life and larger key size.
+Or you can use [this similar script](https://raw.githubusercontent.com/TremoloSecurity/openunison-qs-kubernetes/master/src/main/bash/makessl.sh) that generates SHA256 certs with a longer life and larger key size.
 Setup instructions for specific systems:
@@ -48,7 +48,7 @@ to advertise 2 `vendor-domain/foo`.
 Then, developers can request devices in a
 [Container](/docs/api-reference/{{page.version}}/#container-v1-core)
 specification by using the same process that is used for
-[opaque integer resources](/docs/tasks/configure-pod-container/opaque-integer-resource/).
+[opaque integer resources](/docs/concepts/configuration/manage-compute-resources-container/#opaque-integer-resources-alpha-feature).
 In version 1.8, extended resources are supported only as integer resources and must have
 `limit` equal to `request` in the Container specification.
@@ -316,7 +316,7 @@ Highly Available database statefulset has one master and three replicas, one may
 |:--------------------:|:-------------------:|:------------------:|:------------------:|
 | *DB-MASTER*          | *DB-REPLICA-1*      | *DB-REPLICA-2*     | *DB-REPLICA-3*     |
-[Here](https://kubernetes.io/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure) is an example of zookeper statefulset configured with anti-affinity for high availability.
+[Here](https://kubernetes.io/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure) is an example of Zookeeper statefulset configured with anti-affinity for high availability.
 For more information on inter-pod affinity/anti-affinity, see the design doc
 [here](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md).
@@ -94,13 +94,13 @@ This diagram shows the extension points in a Kubernetes system.
 <!-- image source diagrams: https://docs.google.com/drawings/d/1k2YdJgNTtNfW7_A8moIIkij-DmVgEhNrn3y2OODwqQQ/view -->
-1.   Users often interact with the Kubernetes API using `kubectl`. [Kubectl plugins](docs/tasks/extend-kubectl/kubectl-plugins) extend the kubectl binary. They only affect the individual user's local environment, and so cannot enforce site-wide policies.
+1.   Users often interact with the Kubernetes API using `kubectl`. [Kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) extend the kubectl binary. They only affect the individual user's local environment, and so cannot enforce site-wide policies.
-2.   The apiserver handles all requests. Several types of extension points in the apiserver allow authenticating requests, or blocking them based on their content, editing content, and handling deletion. These are described in the [API Access Extensions](docs/concepts/overview/extending#api-access-extensions) section.
+2.   The apiserver handles all requests. Several types of extension points in the apiserver allow authenticating requests, or blocking them based on their content, editing content, and handling deletion. These are described in the [API Access Extensions](/docs/concepts/overview/extending#api-access-extensions) section.
-3.   The apiserver serves various kinds of *resources*. *Built-in resource kinds*, like `pods`, are defined by the Kubernetes project and can't be changed. You can also add resources that you define, or that other projects have defined, called *Custom Resources*, as explained in the [Custom Resources](docs/concepts/overview/extending#custom-resources) section. Custom Resources are often used with API Access Extensions.
+3.   The apiserver serves various kinds of *resources*. *Built-in resource kinds*, like `pods`, are defined by the Kubernetes project and can't be changed. You can also add resources that you define, or that other projects have defined, called *Custom Resources*, as explained in the [Custom Resources](/docs/concepts/overview/extending#custom-resources) section. Custom Resources are often used with API Access Extensions.
-4.   The Kubernetes scheduler decides which nodes to place pods on. There are several ways to extend scheduling. These are described in the [Scheduler Extensions](docs/concepts/overview/extending#shceduler-extensions) section.
+4.   The Kubernetes scheduler decides which nodes to place pods on. There are several ways to extend scheduling. These are described in the [Scheduler Extensions](/docs/concepts/overview/extending#scheduler-extensions) section.
 5.   Much of the behavior of Kubernetes is implemented by programs called Controllers which are clients of the API-Server. Controllers are often used in conjunction with Custom Resources.
-6.   The kubelet runs on servers, and helps pods appear like virtual servers with their own IPs on the cluster network. [Network Plugins](docs/concepts/overview/extending#network-plugins) allow for different implementations of pod networking.
+6.   The kubelet runs on servers, and helps pods appear like virtual servers with their own IPs on the cluster network. [Network Plugins](/docs/concepts/overview/extending#network-plugins) allow for different implementations of pod networking.
-7.  The kubelet also mounts and unmounts volumes for containers. New types of storage can be supported via [Storage Plugins](docs/concepts/overview/extending#storage-plugins).
+7.  The kubelet also mounts and unmounts volumes for containers. New types of storage can be supported via [Storage Plugins](/docs/concepts/overview/extending#storage-plugins).
 If you are unsure where to start, this flowchart can help. Note that some solutions may involve several types of extensions.
@@ -116,7 +116,7 @@ Consider adding a Custom Resource to Kubernetes if you want to define new contro
 Do not use a Custom Resource as data storage for application, user, or monitoring data.
-For more about Custom Resources, see the [Custom Resources concept guide](/docs/concepts/api-extension/custom-resources.md).
+For more about Custom Resources, see the [Custom Resources concept guide](/docs/concepts/api-extension/custom-resources/).
 ### Combining New APIs with Automation
@@ -200,11 +200,11 @@ the nodes chosen for a pod.
 {% capture whatsnext %}
 * Learn more about [Custom Resources](/docs/concepts/api-extension/custom-resources/)
-* Learn about [Dynamic admission control](/docs/admin/extensible-admission-controller)
+* Learn about [Dynamic admission control](/docs/admin/extensible-admission-controllers/)
 * Learn more about Infrastructure extensions
-  * [Network Plugins](/docs/concepts/cluster-administration/network-plugin)
+  * [Network Plugins](/docs/concepts/cluster-administration/network-plugins/)
-  * [Device Plugins](/docs/concepts/cluster-administration/device-plugins.md)
+  * [Device Plugins](/docs/concepts/cluster-administration/device-plugins/)
-* Learn about [kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugin)
+* Learn about [kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/)
 * See examples of Automation
  * [List of Operators](https://github.com/coreos/awesome-kubernetes-extensions)
@@ -171,8 +171,86 @@ make sure `volumes` contains the `flexVolume` volume type, no flex volume driver
 otherwise. For example:
 ```yaml
-apiVersion: extensions/v1beta1
+# Authorize all service accounts in a namespace:
-kind: PodSecurityPolicy
+- kind: Group
  apiGroup: rbac.authorization.k8s.io
  name: system:serviceaccounts
 # Or equivalently, all authenticated users in a namespace:
 - kind: Group
  apiGroup: rbac.authorization.k8s.io
  name: system:authenticated
 ```
 For more examples of RBAC bindings, see [Role Binding
 Examples](/docs/admin/authorization/rbac/#role-binding-examples). For a complete
 example of authorizing a PodSecurityPolicy, see
 [below](#example).
 ### Troubleshooting
 - The [Controller Manager](/docs/admin/kube-controller-manager/) must be run
 against [the secured API port](/docs/admin/accessing-the-api/), and must not
 have superuser permissions. Otherwise requests would bypass authentication and
 authorization modules, all PodSecurityPolicy objects would be allowed, and users
 would be able to create privileged containers. For more details on configuring
 Controller Manager authorization, see [Controller
 Roles](/docs/admin/authorization/rbac/#controller-roles).
 ## Policy Order
 In addition to restricting pod creation and update, pod security policies can
 also be used to provide default values for many of the fields that it
 controls. When multiple policies are available, the pod security policy
 controller selects policies in the following order:
 1. If any policies successfully validate the pod without altering it, they are
   used.
 2. Otherwise, the first valid policy in alphabetical order is used.
 ## Example
 _This example assumes you have a running cluster with the PodSecurityPolicy
 admission controller enabled and you have cluster admin privileges._
 ### Set up
 Set up a namespace and a service account to act as for this example. We'll use
 this service account to mock a non-admin user.
 ```shell
 $ kubectl create namespace psp-example
 $ kubectl create serviceaccount -n psp-example fake-user
 $ kubectl create rolebinding -n psp-example fake-editor --clusterrole=edit --serviceaccount=psp-example:fake-user
 ```
 To make it clear which user we're acting as and save some typing, create 2
 aliases:
 ```shell
 $ alias kubectl-admin='kubectl -n psp-example'
 $ alias kubectl-user='kubectl --as=system:serviceaccount:psp-example:fake-user -n psp-example'
 ```
 ### Create a policy and a pod
 Define the example PodSecurityPolicy object in a file. This is a policy that
 simply prevents the creation of privileged pods.
 {% include code.html language="yaml" file="example-psp.yaml" ghlink="/docs/concepts/policy/example-psp.yaml" %}
 And create it with kubectl:
 ```shell
 $ kubectl-admin create -f example-psp.yaml
 ```
 Now, as the unprivileged user, try to create a simple pod:
 ```shell
 $ kubectl-user create -f- <<EOF
 apiVersion: v1
 kind: Pod
 metadata:
  name: allow-flex-volumes
 spec:
@@ -32,7 +32,7 @@ $ kubectl config view
 ```
 Many of the [examples](https://github.com/kubernetes/examples/tree/{{page.githubbranch}}/) provide an introduction to using
-kubectl. Complete documentation is found in the [kubectl manual](/docs/user-guide/kubectl/index).
+kubectl. Complete documentation is found in the [kubectl manual](/docs/reference/kubectl/overview/).
 ### Directly accessing the REST API
@@ -37,11 +37,48 @@ of rules in order. The first matching rule sets the [audit level][auditing-level
 of the event. The audit policy object structure is defined in the
 [`audit.k8s.io` API group][auditing-api].
-You can pass a file with the policy to [kube-apiserver][kube-apiserver]
+`AdvancedAuditing` is customizable in two ways. Policy, which determines what's recorded,
-using the `--audit-policy-file` flag. If the flag is omitted, no events are logged.
+and backends, which persist records. Backend implementations include logs files and
-__Note:__ `kind` and `apiVersion` fields along with `rules` __must__ be provided
+webhooks.
-in the audit policy file. A policy with no (0) rules, or a policy that doesn't
+
-provide valid `apiVersion` and `kind` values is treated as illegal.
+The structure of audit events changes when enabling the `AdvancedAuditing` feature
 flag. This includes some cleanups, such as the `method` reflecting the verb evaluated
 by the [authorization layer](/docs/admin/authorization/) instead of the [HTTP verb](/docs/admin/authorization/#determine-the-request-verb).
 Also, instead of always generating two events per request, events are recorded with an associated "stage".
 The known stages are:
 - `RequestReceived` - The stage for events generated as soon as the audit handler receives the request.
 - `ResponseStarted` - Once the response headers are sent, but before the response body is sent. This stage is only generated for long-running requests (e.g. watch).
 - `ResponseComplete` - Once the response body has been completed.
 - `Panic` - Events generated when a panic occurred.
 ### Audit Policy
 Audit policy is a document defining rules about what events should be recorded.
 The policy is passed to the [kube-apiserver][kube-apiserver] using the
 `--audit-policy-file` flag.
 ```
 --audit-policy-file=/etc/kubernetes/audit-policy.yaml
 ```
 If `AdvancedAuditing` is enabled and this flag is omitted, no events are logged.
 The policy file holds rules that determine the level of an event. Known audit levels are:
 - `None` - don't log events that match this rule.
 - `Metadata` - log request metadata (requesting user, timestamp, resource, verb, etc.) but not request or response body.
 - `Request` - log event metadata and request body but not response body.
 - `RequestResponse` - log event metadata, request and response bodies.
 When an event is processed, it's compared against the list of rules in order.
 The first matching rule sets the audit level of the event. The audit policy is
 defined by the [`audit.k8s.io` API group][audit-api].
 Some new fields are supported in beta version, like `resourceNames` and `omitStages`.
 In Kubernetes 1.8 `kind` and `apiVersion` along with `rules` __must__ be provided in
 the audit policy file. A policy file with 0 rules, or a policy file that doesn't provide
 a valid `apiVersion` and `kind` value will be treated as illegal.
 Some example audit policy files:
@@ -109,57 +146,66 @@ In this example, we will use fluentd to split audit events by different namespac
 1. install [fluentd, fluent-plugin-forest and fluent-plugin-rewrite-tag-filter][fluentd_install_doc] in the kube-apiserver node
 1. create a config file for fluentd
-          $ cat <<EOF > /etc/fluentd/config
+   ```shell
-          # fluentd conf runs in the same host with kube-apiserver
+   $ cat <<EOF > /etc/fluentd/config
-          <source>
+   # fluentd conf runs in the same host with kube-apiserver
-              @type tail
+   <source>
-              # audit log path of kube-apiserver
+       @type tail
-              path /var/log/audit
+       # audit log path of kube-apiserver
-              pos_file /var/log/audit.pos
+       path /var/log/audit
-              format json
+       pos_file /var/log/audit.pos
-              time_key time
+       format json
-              time_format %Y-%m-%dT%H:%M:%S.%N%z
+       time_key time
-              tag audit
+       time_format %Y-%m-%dT%H:%M:%S.%N%z
-          </source>
+       tag audit
-          
+   </source>
-          <filter audit>
+
-              #https://github.com/fluent/fluent-plugin-rewrite-tag-filter/issues/13
+   <filter audit>
-              type record_transformer
+       #https://github.com/fluent/fluent-plugin-rewrite-tag-filter/issues/13
-              enable_ruby
+       type record_transformer
-              <record>
+       enable_ruby
-              	namespace ${record["objectRef"].nil? ? "none":(record["objectRef"]["namespace"].nil? ?  "none":record["objectRef"]["namespace"])}
+       <record>
-              </record>
+        namespace ${record["objectRef"].nil? ? "none":(record["objectRef"]["namespace"].nil? ?  "none":record["objectRef"]["namespace"])}
-          </filter>
+       </record>
-          
+   </filter>
-          <match audit>
+
-              # route audit according to namespace element in context
+   <match audit>
-              @type rewrite_tag_filter
+       # route audit according to namespace element in context
-              rewriterule1 namespace ^(.+) ${tag}.$1
+       @type rewrite_tag_filter
-          </match>
+       rewriterule1 namespace ^(.+) ${tag}.$1
-          
+   </match>
-          <filter audit.**>
+
-          	  @type record_transformer
+   <filter audit.**>
-          	  remove_keys namespace
+      @type record_transformer
-          </filter>
+      remove_keys namespace
-          
+   </filter>
-          <match audit.**>
+
-              @type forest
+   <match audit.**>
-              subtype file
+       @type forest
-              remove_prefix audit
+       subtype file
-              <template>
+       remove_prefix audit
-                  time_slice_format %Y%m%d%H
+       <template>
-                  compress gz
+           time_slice_format %Y%m%d%H
-                  path /var/log/audit-${tag}.*.log
+           compress gz
-                  format json
+           path /var/log/audit-${tag}.*.log
-                  include_time_key true
+           format json
-              </template>
+           include_time_key true
-          </match>
+       </template>
   </match>
   ```
 1. start fluentd
-          $ fluentd -c /etc/fluentd/config  -vv
+   ```shell
   $ fluentd -c /etc/fluentd/config  -vv
   ```
 1. start kube-apiserver with the following options:
-          --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-log-path=/var/log/kube-audit --audit-log-format=json
+   ```shell
   --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-log-path=/var/log/kube-audit --audit-log-format=json
   ```
 1. check audits for different namespaces in /var/log/audit-*.log
 ### Use logstash to collect and distribute audit events from webhook backend
@@ -171,56 +217,68 @@ different users into different files.
 1. install [logstash][logstash_install_doc]
 1. create config file for logstash
-          $ cat <<EOF > /etc/logstash/config
+   ```shell
-          input{
+   $ cat <<EOF > /etc/logstash/config
-              http{
+   input{
-                  #TODO, figure out a way to use kubeconfig file to authenticate to logstash
+       http{
-                  #https://www.elastic.co/guide/en/logstash/current/plugins-inputs-http.html#plugins-inputs-http-ssl
+           #TODO, figure out a way to use kubeconfig file to authenticate to logstash
-                  port=>8888
+           #https://www.elastic.co/guide/en/logstash/current/plugins-inputs-http.html#plugins-inputs-http-ssl
-              }
+           port=>8888
-          }
+       }
-          filter{
+   }
-              split{
+   filter{
-                  # Webhook audit backend sends several events together with EventList
+       split{
-                  # split each event here.
+           # Webhook audit backend sends several events together with EventList
-                  field=>[items]
+           # split each event here.
-                  # We only need event subelement, remove others.
+           field=>[items]
-                  remove_field=>[headers, metadata, apiVersion, "@timestamp", kind, "@version", host]
+           # We only need event subelement, remove others.
-              }
+           remove_field=>[headers, metadata, apiVersion, "@timestamp", kind, "@version", host]
-              mutate{
+       }
-                  rename => {items=>event}
+       mutate{
-              }
+           rename => {items=>event}
-          }
+       }
-          output{
+   }
-              file{
+   output{
-                  # Audit events from different users will be saved into different files.
+       file{
-                  path=>"/var/log/kube-audit-%{[event][user][username]}/audit"
+           # Audit events from different users will be saved into different files.
-              }
+           path=>"/var/log/kube-audit-%{[event][user][username]}/audit"
-          }
+       }
   }
   ```
 1. start logstash
-          $ bin/logstash -f /etc/logstash/config --path.settings /etc/logstash/
+   ```shell
   $ bin/logstash -f /etc/logstash/config --path.settings /etc/logstash/
   ```
 1. create a [kubeconfig file](/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/) for kube-apiserver webhook audit backend
-          $ cat <<EOF > /etc/kubernetes/audit-webhook-kubeconfig
+   ```shell
-          apiVersion: v1
+   $ cat <<EOF > /etc/kubernetes/audit-webhook-kubeconfig
-          clusters:
+   apiVersion: v1
-          - cluster:
+   clusters:
-              server: http://<ip_of_logstash>:8888
+   - cluster:
-            name: logstash
+       server: http://<ip_of_logstash>:8888
-          contexts:
+     name: logstash
-          - context:
+   contexts:
-              cluster: logstash
+   - context:
-              user: ""
+       cluster: logstash
-            name: default-context
+       user: ""
-          current-context: default-context
+     name: default-context
-          kind: Config
+   current-context: default-context
-          preferences: {}
+   kind: Config
-          users: []
+   preferences: {}
-          EOF
+   users: []
   EOF
   ```
 1. start kube-apiserver with the following options:
-          --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-webhook-config-file=/etc/kubernetes/audit-webhook-kubeconfig
+   ```shell
   --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-webhook-config-file=/etc/kubernetes/audit-webhook-kubeconfig
   ```
 1. check audits in logstash node's directories /var/log/kube-audit-*/audit
 Note that in addition to file output plugin, logstash has a variety of outputs that
@@ -11,7 +11,7 @@ Horizontal Pod Autoscaler automatically scales the number of pods
 in a replication controller, deployment or replica set based on observed CPU utilization
 (or, with beta support, on some other, application-provided metrics).
-This document walks you through an example of enabling Horizontal Pod Autoscaler for the php-apache server.  For more information on how Horizontal Pod Autoscaler behaves, see the [Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horizontal-pod-autoscaler/).
+This document walks you through an example of enabling Horizontal Pod Autoscaler for the php-apache server.  For more information on how Horizontal Pod Autoscaler behaves, see the [Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horizontal-pod-autoscale/).
 ## Prerequisites
@@ -24,7 +24,7 @@ heapster monitoring will be turned-on by default).
 To specify multiple resource metrics for a Horizontal Pod Autoscaler, you must have a Kubernetes cluster
 and kubectl at version 1.6 or later.  Furthermore, in order to make use of custom metrics, your cluster
 must be able to communicate with the API server providing the custom metrics API.
-See the [Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horizontal-pod-autoscaler/#support-for-custom-metrics) for more details.
+See the [Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) for more details.
 ## Step One: Run & expose php-apache server