From 5483b4a126a9d847cd5c60a16c630062f6e35aed Mon Sep 17 00:00:00 2001 From: jianglingxia Date: Thu, 1 Jun 2017 01:33:27 +0800 Subject: [PATCH 1/6] change the service name to pod ip (#3926) * change the service name to pod ip * update the outdate link --- .../run-application/rolling-update-replication-controller.md | 2 +- .../run-application/run-single-instance-stateful-application.md | 2 +- fsg5af58.txt | 0 3 files changed, 2 insertions(+), 2 deletions(-) delete mode 100644 fsg5af58.txt diff --git a/docs/tasks/run-application/rolling-update-replication-controller.md b/docs/tasks/run-application/rolling-update-replication-controller.md index b5dca703e7..005d971288 100644 --- a/docs/tasks/run-application/rolling-update-replication-controller.md +++ b/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 diff --git a/docs/tasks/run-application/run-single-instance-stateful-application.md b/docs/tasks/run-application/run-single-instance-stateful-application.md index dc032259db..d09918542b 100644 --- a/docs/tasks/run-application/run-single-instance-stateful-application.md +++ b/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 -ppassword ``` This command creates a new Pod in the cluster running a mysql client diff --git a/fsg5af58.txt b/fsg5af58.txt deleted file mode 100644 index e69de29bb2..0000000000 From 71177ff37aba0b71f4539fee391a3873f815df92 Mon Sep 17 00:00:00 2001 From: Swapnil Kulkarni Date: Mon, 29 May 2017 11:40:16 +0530 Subject: [PATCH 2/6] Update small typo in components page (#3930) [1] page has a typo in Master Components section. Updated the document. [1] https://kubernetes.io/docs/concepts/overview/components/ --- docs/concepts/overview/components.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/concepts/overview/components.md b/docs/concepts/overview/components.md index 696a5bd69e..acf252e893 100644 --- a/docs/concepts/overview/components.md +++ b/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 From 4471d3dbf024fab7fb0a1be9ea5a2a60b37541e3 Mon Sep 17 00:00:00 2001 From: Michail Kargakis Date: Thu, 25 May 2017 15:17:11 +0200 Subject: [PATCH 3/6] Warn against managing ReplicaSets owned by Deployments Signed-off-by: Michail Kargakis --- docs/concepts/workloads/controllers/deployment.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/docs/concepts/workloads/controllers/deployment.md b/docs/concepts/workloads/controllers/deployment.md index 693c535ce3..be776f87a2 100644 --- a/docs/concepts/workloads/controllers/deployment.md +++ b/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: From 75303cfee4f2ef337ed3708f6631e3ed8bcb86f9 Mon Sep 17 00:00:00 2001 From: "Charlie R.C" Date: Thu, 1 Jun 2017 01:45:55 +0800 Subject: [PATCH 4/6] add prompt about KUBE_REPO_PREFIX (#3597) * add prompt about KUBE_REPO_PREFIX * add period --- docs/admin/kubeadm.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/docs/admin/kubeadm.md b/docs/admin/kubeadm.md index 50c9f08a5d..56d5218444 100644 --- a/docs/admin/kubeadm.md +++ b/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 < Date: Wed, 31 May 2017 10:39:50 -0700 Subject: [PATCH 5/6] Add colon to #3897 --- docs/concepts/workloads/controllers/deployment.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/concepts/workloads/controllers/deployment.md b/docs/concepts/workloads/controllers/deployment.md index be776f87a2..f2c16958ee 100644 --- a/docs/concepts/workloads/controllers/deployment.md +++ b/docs/concepts/workloads/controllers/deployment.md @@ -18,7 +18,7 @@ You only need to describe the desired state in a Deployment object, and the Depl change the actual state to the desired state at a controlled rate for you. You can define Deployments to 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 +**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. From f4fd9e79edc435b977c9fe37219fe39c67f699b3 Mon Sep 17 00:00:00 2001 From: Mik Vyatskov Date: Wed, 31 May 2017 19:50:04 +0200 Subject: [PATCH 6/6] Fix log rotation description in the logging doc (#3918) * Fix log rotation description in the logging doc * Review comments * Address review comments * Address review comments --- .../cluster-administration/logging.md | 37 +++++++++++++++---- 1 file changed, 29 insertions(+), 8 deletions(-) diff --git a/docs/concepts/cluster-administration/logging.md b/docs/concepts/cluster-administration/logging.md index 5059a3d81f..283a2c3812 100644 --- a/docs/concepts/cluster-administration/logging.md +++ b/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. +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. -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. +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]. -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:** 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. -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. +[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