Merge branch 'master' of https://github.com/kubernetes/kubernetes.github.io into release-1.7
* 'master' of https://github.com/kubernetes/kubernetes.github.io: 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)
This commit is contained in:
Andrew Chen
@@ -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.
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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:
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user