Merge branch 'master' of https://github.com/kubernetes/kubernetes.git…

…hub.io into release-1.6

* 'master' of https://github.com/kubernetes/kubernetes.github.io:
  networking.md: Add reference to the Cilium network plugin
  Fix typo in cluster api docs
  [Kubeadm] bugfix in the index listing
  Fix log rotation description in the logging doc (#3918)
  Add colon to #3897
  add prompt about KUBE_REPO_PREFIX (#3597)
  Warn against managing ReplicaSets owned by Deployments
  Update small typo in components page (#3930)
  change the service name to pod ip (#3926)

docs/admin/kubeadm.md

@@ -389,6 +389,18 @@ configuration file.
 If `KUBE_KUBERNETES_DIR` is specified, you may need to rewrite the arguments of the kubelet.
 (e.g. --kubeconfig, --pod-manifest-path)
 
+If `KUBE_REPO_PREFIX` is specified, you may need to set the kubelet flag `--pod-infra-container-image` which specifies which pause image to use.
+Defaults to `gcr.io/google_containers/pause-${ARCH}:3.0` where `${ARCH}` can be one of `amd64`, `arm`, `arm64`, `ppc64le` or `s390x`.
+
+```bash
+cat > /etc/systemd/system/kubelet.service.d/20-pod-infra-image.conf <<EOF
+[Service]
+Environment="KUBELET_EXTRA_ARGS=--pod-infra-container-image=<your-image>"
+EOF
+systemctl daemon-reload
+systemctl restart kubelet
+```
+
 If you want to use kubeadm with an http proxy, you may need to configure it to
 support http_proxy, https_proxy, or no_proxy.
 

docs/concepts/cluster-administration/logging.md

@@ -61,13 +61,32 @@ Everything a containerized application writes to `stdout` and `stderr` is handle
 
 By default, if a container restarts, the kubelet keeps one terminated container with its logs. If a pod is evicted from the node, all corresponding containers are also evicted, along with their logs.
 
-An important consideration in node-level logging is implementing log rotation, so that logs don't consume all available storage on the node. Kubernetes uses the [`logrotate`](http://www.linuxcommand.org/man_pages/logrotate8.html) tool to implement log rotation.
-
-Kubernetes performs log rotation daily, or if the log file grows beyond 10MB in size. Each rotation belongs to a single container; if the container repeatedly fails or the pod is evicted, all previous rotations for the container are lost. By default, Kubernetes keeps up to five logging rotations per container.
-
-The Kubernetes logging configuration differs depending on the node type. For example, you can find detailed information for GCI in the corresponding [configure helper](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/cluster/gce/gci/configure-helper.sh#L96).
-
-When you run [`kubectl logs`](/docs/user-guide/kubectl/v1.6/#logs), as in the basic logging example, the kubelet on the node handles the request and reads directly from the log file, returning the contents in the response. Note that `kubectl logs` **only returns the last rotation**; you must manually extract prior rotations, if desired and cluster-level logging is not enabled.
+An important consideration in node-level logging is implementing log rotation,
+so that logs don't consume all available storage on the node. Kubernetes
+currently is not responsible for rotating logs, but rather a deployment tool
+should set up a solution to address that.
+For example, in Kubernetes clusters, deployed by the `kube-up.sh` script,
+there is a [`logrotate`](http://www.linuxcommand.org/man_pages/logrotate8.html)
+tool configured to run each hour. You can also set up a container runtime to
+rotate application's logs automatically, e.g. by using Docker's `log-opt`.
+In the `kube-up.sh` script, the latter approach is used for COS image on GCP,
+and the former approach is used in any other environment. In both cases, by
+default rotation is configured to take place when log file exceeds 10MB.
+
+As an example, you can find detailed information about how `kube-up.sh` sets
+up logging for COS image on GCP in the corresponding [script]
+[cosConfigureHelper].
+
+When you run [`kubectl logs`](/docs/user-guide/kubectl/v1.6/#logs) as in
+the basic logging example, the kubelet on the node handles the request and
+reads directly from the log file, returning the contents in the response.
+**Note:** currently, if some external system has performed the rotation,
+only the contents of the latest log file will be available through
+`kubectl logs`. E.g. if there's a 10MB file, `logrotate` performs
+the rotation and there are two files, one 10MB in size and one empty,
+`kubectl logs` will return an empty response.
+
+[cosConfigureHelper]: https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/cluster/gce/gci/configure-helper.sh
 
 ### System component logs
 
@@ -80,14 +99,16 @@ that do not run in a container. For example:
 On machines with systemd, the kubelet and container runtime write to journald. If
 systemd is not present, they write to `.log` files in the `/var/log` directory.
 System components inside containers always write to the `/var/log` directory,
-bypassing the default logging mechanism. They use the [glog](https://godoc.org/github.com/golang/glog)
+bypassing the default logging mechanism. They use the [glog][glog]
 logging library. You can find the conventions for logging severity for those
 components in the [development docs on logging](https://github.com/kubernetes/community/blob/master/contributors/devel/logging.md).
 
 Similarly to the container logs, system component logs in the `/var/log`
-directory are rotated daily and based on the log size. However,
-system component logs have a higher size retention: by default,
-they can store up to 100MB.
+directory should be rotated. In Kubernetes clusters brought up by
+the `kube-up.sh` script, those logs are configured to be rotated by
+the `logrotate` tool daily or once the size exceeds 100MB.
+
+[glog]: https://godoc.org/github.com/golang/glog
 
 ## Cluster-level logging architectures
 

docs/concepts/cluster-administration/networking.md

@@ -106,6 +106,14 @@ as an introduction to various technologies and serves as a jumping-off point.
 The following networking options are sorted alphabetically - the order does not
 imply any preferential status.
 
+### Cilium
+
+[Cilium](https://github.com/cilium/cilium) is open source software for
+providing and transparently securing network connectivity between application
+containers. Cilium is L7/HTTP aware and can enforce network policies on L3-L7
+using an identity based security model that is decoupled from network
+addressing.
+
 ### Contiv
 
 [Contiv](https://github.com/contiv/netplugin) provides configurable networking (native l3 using BGP, overlay using vxlan,  classic l2, or Cisco-SDN/ACI) for various use cases. [Contiv](http://contiv.io) is all open sourced.

docs/concepts/overview/components.md

@@ -15,7 +15,7 @@ deliver a functioning Kubernetes cluster.
 ## Master Components
 
 Master components provide the cluster's control plane. Master components make global decisions about the
-cluster (for example, scheduling), and detecting and responding to cluster events (starting up a new pod when a replication controller's 'replicas' field is unsatisfied. 
+cluster (for example, scheduling), and detecting and responding to cluster events (starting up a new pod when a replication controller's 'replicas' field is unsatisfied). 
 
 Master components can be run on any node in the cluster. However,
 for simplicity, set up scripts typically start all master components on

docs/concepts/workloads/controllers/deployment.md

@@ -16,7 +16,11 @@ A _Deployment_ provides declarative updates for [Pods](/docs/concepts/workloads/
 [ReplicaSets](/docs/concepts/workloads/controllers/replicaset/) (the next-generation ReplicationController).
 You only need to describe the desired state in a Deployment object, and the Deployment controller will
 change the actual state to the desired state at a controlled rate for you. You can define Deployments to
-create new resources, or replace existing ones by new ones.
+create new ReplicaSets, or remove existing Deployments and adopt all of their resources with new Deployments.
+
+**Note:** You should not manage ReplicaSets owned by a Deployment, otherwise you are racing with the Deployment
+controller! All of the use cases should be covered just by manipulating the Deployment object. Consider opening
+an issue in the main Kubernetes repository, if your use case is not covered below.
 
 A typical use case is:
 

docs/reference/index.md

@@ -15,7 +15,7 @@ assignees:
 
 * [kubectl](/docs/user-guide/kubectl-overview) - Main CLI tool for running commands and managing Kubernetes clusters.
     * [JSONPath](/docs/user-guide/jsonpath/) - Syntax guide for using [JSONPath expressions](http://goessner.net/articles/JsonPath/) with kubectl.
-* [kubeadm](/docs/admin/kubeadm/) - CLI tool to 
+* [kubeadm](/docs/admin/kubeadm/) - CLI tool to easily provision a secure Kubernetes cluster 
 
 ## Config Reference
 

docs/tasks/administer-cluster/access-cluster-api.md

@@ -36,7 +36,7 @@ $ kubectl config view
 ```
 
 Many of the [examples](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/) provide an introduction to using
-kubectl.  omplete documentation is found in the [kubectl manual](/docs/user-guide/kubectl/index).
+kubectl.  Complete documentation is found in the [kubectl manual](/docs/user-guide/kubectl/index).
 
 ### Directly accessing the REST API
 

docs/tasks/run-application/rolling-update-replication-controller.md

@@ -21,7 +21,7 @@ which in turn uses a
 For more information, see
 [Running a Stateless Application Using a Deployment](/docs/tasks/run-application/run-stateless-application-deployment/).
 
-To update a service without an outage, `kubectl` supports what is called ['rolling update'](/docs/user-guide/kubectl/v1.6/#rolling-update), which updates one pod at a time, rather than taking down the entire service at the same time. See the [rolling update design document](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/simple-rolling-update.md) and the [example of rolling update](/docs/tasks/run-application/rolling-update-replication-controller/) for more information.
+To update a service without an outage, `kubectl` supports what is called ['rolling update'](/docs/user-guide/kubectl/v1.6/#rolling-update), which updates one pod at a time, rather than taking down the entire service at the same time. See the [rolling update design document](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/simple-rolling-update.md) and the [example of rolling update](/docs/tasks/run-application/rolling-update-replication-controller/) for more information.
 
 Note that `kubectl rolling-update` only supports Replication Controllers. However, if you deploy applications with Replication Controllers,
 consider switching them to [Deployments](/docs/concepts/workloads/controllers/deployment/). A Deployment is a higher-level controller that automates rolling updates

docs/tasks/run-application/run-single-instance-stateful-application.md

@@ -160,7 +160,7 @@ behind a Service and you don't intend to increase the number of Pods.
 Run a MySQL client to connect to the server:
 
 ```
-kubectl run -it --rm --image=mysql:5.6 mysql-client -- mysql -h mysql -ppassword
+kubectl run -it --rm --image=mysql:5.6 mysql-client -- mysql -h <pod-ip> -ppassword
 ```
 
 This command creates a new Pod in the cluster running a mysql client