whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'master' of https://github.com/kubernetes/kubernetes.github.io into release-1.6

Browse Source 
* 'master' of https://github.com/kubernetes/kubernetes.github.io: (58 commits)
  fix unsupported parameter of wget command
  Update Weave Net's title.
  Update garbage-collection.md
  Correct ASM logo filename
  fixed ASM blurb
  Repair Spotinst logo
  Doc formatting update
  fixing typo
  Minor spelling correction -- "rtk" to "rkt"
  update init-containers.md
  Update local instructions to new method.
  Update ubuntu install instructions.
  Highlighted command for `kubectl proxy`.
  Update Tasks landing page. (#2697)
  Deprecate Guide topics: quick-start ... (#2696)
  Deprecate Guide topic: Secrets Walkthrough. (#2695)
  Update multiple-schedulers doc  (#2063)
  remove extra space
  Reimplement PR #2525
  Deprecate Guide topic: Persistent Volume Walkthrough. (#2692)
  ...
This commit is contained in:
Andrew Chen
2017-03-06 11:28:15 -08:00
parent 8dcc673d5d 68d5fe503f
commit 2f9aa17560
82 changed files with 777 additions and 639 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/tasks/configure-pod-container/configure-persistent-volume-storage.md
+3
View File
@@ -1,5 +1,8 @@
---
title: Configuring a Pod to Use a PersistentVolume for Storage
redirect_from:
- "/docs/user-guide/persistent-volumes/walkthrough/"
- "/docs/user-guide/persistent-volumes/walkthrough.html"
---
{% capture overview %}
docs/tasks/configure-pod-container/distribute-credentials-secure.md
+14 -11
View File
@@ -1,5 +1,8 @@
---
title: Distributing Credentials Securely
redirect_from:
- "/docs/user-guide/secrets/walkthrough/"
- "/docs/user-guide/secrets/walkthrough.html"
---
{% capture overview %}
@@ -22,11 +25,11 @@ Suppose you want to have two pieces of secret data: a username `my-app` and a pa
convert your username and password to a base-64 representation. Here's a Linux
example:
echo 'my-app' | base64
echo '39528$vdg7Jb' | base64
echo -n 'my-app' | base64
echo -n '39528$vdg7Jb' | base64
The output shows that the base-64 representation of your username is `bXktYXBwCg==`,
and the base-64 representation of your password is `Mzk1MjgkdmRnN0piCg==`.
The output shows that the base-64 representation of your username is `bXktYXBw`,
and the base-64 representation of your password is `Mzk1MjgkdmRnN0pi`.
## Creating a Secret
@@ -37,12 +40,12 @@ username and password:
1. Create the Secret
kubectl create -f http://k8s.io/docs/tasks/administer-cluster/secret.yaml
kubectl create -f secret.yaml
**Note:** If you want to skip the Base64 encoding step, you can create a Secret
by using the `kubectl create secret` command:
kubectl create secret generic test-secret --from-literal=username="my-app",password="39528$vdg7Jb"
kubectl create secret generic test-secret --from-literal=username='my-app',password='39528$vdg7Jb'
1. View information about the Secret:
@@ -69,8 +72,8 @@ username and password:
Data
====
password: 13 bytes
username: 7 bytes
password: 12 bytes
username: 6 bytes
## Creating a Pod that has access to the secret data through a Volume
@@ -80,7 +83,7 @@ Here is a configuration file you can use to create a Pod:
1. Create the Pod:
kubectl create -f http://k8s.io/docs/tasks/administer-cluster/secret-pod.yaml
kubectl create -f secret-pod.yaml
1. Verify that your Pod is running:
@@ -112,7 +115,7 @@ is exposed:
1. In your shell, display the contents of the `username` and `password` files:
root@secret-test-pod:/etc/secret-volume# cat username password
root@secret-test-pod:/etc/secret-volume# cat username; echo; cat password; echo
The output is your username and password:
@@ -127,7 +130,7 @@ Here is a configuration file you can use to create a Pod:
1. Create the Pod:
kubectl create -f http://k8s.io/docs/tasks/administer-cluster/secret-envars-pod.yaml
kubectl create -f secret-envars-pod.yaml
1. Verify that your Pod is running:
docs/tasks/debug-application-cluster/counter-pod.yaml
+10
View File
@@ -0,0 +1,10 @@
apiVersion: v1
kind: Pod
metadata:
name: counter
spec:
containers:
- name: count
image: busybox
args: [/bin/sh, -c,
'i=0; while true; do echo "$i: $(date)"; i=$((i+1)); sleep 1; done']
docs/tasks/troubleshoot/debug-init-containers.md → docs/tasks/debug-application-cluster/debug-init-containers.md
+3
View File
@@ -8,6 +8,9 @@ assignees:
- kow3ns
- smarterclayton
title: Debugging Init Containers
redirect_from:
- "/docs/tasks/troubleshoot/debug-init-containers/"
- "/docs/tasks/troubleshoot/debug-init-containers.html"
---
{% capture overview %}
docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md
+104
View File
@@ -0,0 +1,104 @@
---
assignees:
- crassirostris
- piosz
title: Logging Using Elasticsearch and Kibana
---
On the Google Compute Engine (GCE) platform, the default logging support targets
[Stackdriver Logging](https://cloud.google.com/logging/), which is described in detail
in the [Logging With Stackdriver Logging](/docs/user-guide/logging/stackdriver).
This article describes how to set up a cluster to ingest logs into
[Elasticsearch](https://www.elastic.co/products/elasticsearch), and view
them using [Kibana](https://www.elastic.co/products/kibana), as an alternative to
Stackdriver Logging when running on GCE. Note that Elasticsearch and Kibana do not work with Kubernetes clusters hosted on Google Container Engine.
To use Elasticsearch and Kibana for cluster logging, you should set the
following environment variable as shown below when creating your cluster with
kube-up.sh:
```shell
KUBE_LOGGING_DESTINATION=elasticsearch
```
You should also ensure that `KUBE_ENABLE_NODE_LOGGING=true` (which is the default for the GCE platform).
Now, when you create a cluster, a message will indicate that the Fluentd log
collection daemons that run on each node will target Elasticsearch:
```shell
$ cluster/kube-up.sh
...
Project: kubernetes-satnam
Zone: us-central1-b
... calling kube-up
Project: kubernetes-satnam
Zone: us-central1-b
+++ Staging server tars to Google Storage: gs://kubernetes-staging-e6d0e81793/devel
+++ kubernetes-server-linux-amd64.tar.gz uploaded (sha1 = 6987c098277871b6d69623141276924ab687f89d)
+++ kubernetes-salt.tar.gz uploaded (sha1 = bdfc83ed6b60fa9e3bff9004b542cfc643464cd0)
Looking for already existing resources
Starting master and configuring firewalls
Created [https://www.googleapis.com/compute/v1/projects/kubernetes-satnam/zones/us-central1-b/disks/kubernetes-master-pd].
NAME ZONE SIZE_GB TYPE STATUS
kubernetes-master-pd us-central1-b 20 pd-ssd READY
Created [https://www.googleapis.com/compute/v1/projects/kubernetes-satnam/regions/us-central1/addresses/kubernetes-master-ip].
+++ Logging using Fluentd to elasticsearch
```
The per-node Fluentd pods, the Elasticsearch pods, and the Kibana pods should
all be running in the kube-system namespace soon after the cluster comes to
life.
```shell
$ kubectl get pods --namespace=kube-system
NAME READY REASON RESTARTS AGE
elasticsearch-logging-v1-78nog 1/1 Running 0 2h
elasticsearch-logging-v1-nj2nb 1/1 Running 0 2h
fluentd-elasticsearch-kubernetes-node-5oq0 1/1 Running 0 2h
fluentd-elasticsearch-kubernetes-node-6896 1/1 Running 0 2h
fluentd-elasticsearch-kubernetes-node-l1ds 1/1 Running 0 2h
fluentd-elasticsearch-kubernetes-node-lz9j 1/1 Running 0 2h
kibana-logging-v1-bhpo8 1/1 Running 0 2h
kube-dns-v3-7r1l9 3/3 Running 0 2h
monitoring-heapster-v4-yl332 1/1 Running 1 2h
monitoring-influx-grafana-v1-o79xf 2/2 Running 0 2h
```
The `fluentd-elasticsearch` pods gather logs from each node and send them to
the `elasticsearch-logging` pods, which are part of a
[service](/docs/user-guide/services/) named `elasticsearch-logging`. These
Elasticsearch pods store the logs and expose them via a REST API.
The `kibana-logging` pod provides a web UI for reading the logs stored in
Elasticsearch, and is part of a service named `kibana-logging`.
The Elasticsearch and Kibana services are both in the `kube-system` namespace
and are not directly exposed via a publicly reachable IP address. To reach them,
follow the instructions for [Accessing services running in a cluster](/docs/user-guide/accessing-the-cluster/#accessing-services-running-on-the-cluster).
If you try accessing the `elasticsearch-logging` service in your browser, you'll
see a status page that looks something like this:
![Elasticsearch Status](/images/docs/es-browser.png)
You can now type Elasticsearch queries directly into the browser, if you'd
like. See [Elasticsearch's documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-uri-request.html)
for more details on how to do so.
Alternatively, you can view your cluster's logs using Kibana (again using the
[instructions for accessing a service running in the cluster](/docs/user-guide/accessing-the-cluster/#accessing-services-running-on-the-cluster)).
The first time you visit the Kibana URL you will be presented with a page that
asks you to configure your view of the ingested logs. Select the option for
timeseries values and select `@timestamp`. On the following page select the
`Discover` tab and then you should be able to see the ingested logs.
You can set the refresh interval to 5 seconds to have the logs
regularly refreshed.
Here is a typical view of ingested logs from the Kibana viewer:
![Kibana logs](/images/docs/kibana-logs.png)
Kibana opens up all sorts of powerful options for exploring your logs! For some
ideas on how to dig into it, check out [Kibana's documentation](https://www.elastic.co/guide/en/kibana/current/discover.html).
docs/tasks/debug-application-cluster/logging-stackdriver.md
+148
View File
@@ -0,0 +1,148 @@
---
assignees:
- crassirostris
- piosz
title: Logging Using Stackdriver
---
Before reading this page, it's highly recommended to familiasrize yourself with the [overview of logging in Kubernetes](/docs/user-guide/logging/overview).
This article assumes that you have created a Kubernetes cluster with cluster-level logging support for sending logs to Stackdriver Logging. You can do this either by selecting the **Enable Stackdriver Logging** checkbox in the create cluster dialogue in [GKE](https://cloud.google.com/container-engine/), or by setting the `KUBE_LOGGING_DESTINATION` flag to `gcp` when manually starting a cluster using `kube-up.sh`.
The following guide describes gathering a container's standard output and standard error. To gather logs written by an application to a file, you can use [a sidecar approach](https://github.com/kubernetes/contrib/blob/master/logging/fluentd-sidecar-gcp/README.md).
## Overview
After creation, you can discover logging agent pods in the `kube-system` namespace,
one per node, by running the following command:
```shell
$ kubectl get pods --namespace=kube-system
NAME READY STATUS RESTARTS AGE
...
fluentd-gcp-v1.30-50gnc 1/1 Running 0 5d
fluentd-gcp-v1.30-v255c 1/1 Running 0 5d
fluentd-gcp-v1.30-f02l5 1/1 Running 0 5d
...
```
To understand how logging with Stackdriver works, consider the following
synthetic log generator pod specification [counter-pod.yaml](/docs/tasks/debug-application-cluster/counter-pod.yaml):
{% include code.html language="yaml" file="counter-pod.yaml" ghlink="/docs/tasks/debug-application-cluster/counter-pod.yaml" %}
This pod specification has one container that runs a bash script
that writes out the value of a counter and the date once per
second, and runs indefinitely. Let's create this pod in the default namespace.
```shell
$ kubectl create -f http://k8s.io/docs/user-guide/logging/examples/counter-pod.yaml
pod "counter" created
```
You can observe the running pod:
```shell
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
counter 1/1 Running 0 5m
```
For a short period of time you can observe the 'Pending' pod status, because the kubelet
has to download the container image first. When the pod status changes to `Running`
you can use the `kubectl logs` command to view the output of this counter pod.
```shell
$ kubectl logs counter
0: Mon Jan 1 00:00:00 UTC 2001
1: Mon Jan 1 00:00:01 UTC 2001
2: Mon Jan 1 00:00:02 UTC 2001
...
```
As described in the logging overview, this command fetches log entries
from the container log file. If the container is killed and then restarted by
Kubernetes, you can still access logs from the previous container. However,
if the pod is evicted from the node, log files are lost. Let's demonstrate this
by deleting the currently running counter container:
```shell
$ kubectl delete pod counter
pod "counter" deleted
```
and then recreating it:
```shell
$ kubectl create -f http://k8s.io/docs/user-guide/logging/examples/counter-pod.yaml
pod "counter" created
```
After some time, you can access logs from the counter pod again:
```shell
$ kubectl logs counter
0: Mon Jan 1 00:01:00 UTC 2001
1: Mon Jan 1 00:01:01 UTC 2001
2: Mon Jan 1 00:01:02 UTC 2001
...
```
As expected, only recent log lines are present. However, for a real-world
application you will likely want to be able to access logs from all containers,
especially for the debug purposes. This is exactly when the previously enabled
Stackdriver Logging can help.
## Viewing logs
Stackdriver Logging agent attaches metadata to each log entry, for you to use later
in queries to select only the messages you're interested in: for example,
the messages from a particular pod.
The most important pieces of metadata are the resource type and log name.
The resource type of a container log is `container`, which is named
`GKE Containers` in the UI (even if the Kubernetes cluster is not on GKE).
The log name is the name of the container, so that if you have a pod with
two containers, named `container_1` and `container_2` in the spec, their logs
will have log names `container_1` and `container_2` respectively.
System components have resource type `compute`, which is named
`GCE VM Instance` in the interface. Log names for system components are fixed.
For a GKE node, every log entry from a system component has one the following
log names:
* docker
* kubelet
* kube-proxy
You can learn more about viewing logs on [the dedicated Stackdriver page](https://cloud.google.com/logging/docs/view/logs_viewer).
One of the possible ways to view logs is using the
[`gcloud logging`](https://cloud.google.com/logging/docs/api/gcloud-logging)
command line interface from the [Google Cloud SDK](https://cloud.google.com/sdk/).
It uses Stackdriver Logging [filtering syntax](https://cloud.google.com/logging/docs/view/advanced_filters)
to query specific logs. For example, you can run the following command:
```shell
$ gcloud beta logging read 'logName="projects/$YOUR_PROJECT_ID/logs/count"' --format json | jq '.[].textPayload'
...
"2: Mon Jan 1 00:01:02 UTC 2001\n"
"1: Mon Jan 1 00:01:01 UTC 2001\n"
"0: Mon Jan 1 00:01:00 UTC 2001\n"
...
"2: Mon Jan 1 00:00:02 UTC 2001\n"
"1: Mon Jan 1 00:00:01 UTC 2001\n"
"0: Mon Jan 1 00:00:00 UTC 2001\n"
```
As you can see, it outputs messages for the count container from both
the first and second runs, despite the fact that the kubelet already deleted
the logs for the first container.
### Exporting logs
You can export logs to [Google Cloud Storage](https://cloud.google.com/storage/)
or to [BigQuery](https://cloud.google.com/bigquery/) to run further
analysis. Stackdriver Logging offers the concept of sinks, where you can
specify the destination of log entries. More information is available on
the Stackdriver [Exporting Logs page](https://cloud.google.com/logging/docs/export/configure_export_v2).
docs/tasks/index.md
+9 -5
View File
@@ -1,5 +1,10 @@
---
title: Tasks
redirect_from:
- "/docs/user-guide/configuring-containers/"
- "/docs/user-guide/configuring-containers.html"
- "/docs/user-guide/production-pods/"
- "/docs/user-guide/production-pods.html"
---
This section of the Kubernetes documentation contains pages that
@@ -32,9 +37,12 @@ single thing, typically by giving a short sequence of steps.
* [Using Port Forwarding to Access Applications in a Cluster](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)
* [Providing Load-Balanced Access to an Application in a Cluster](/docs/tasks/access-application-cluster/load-balance-access-application-cluster/)
#### Debugging Applications in a Cluster
#### Monitoring, Logging, and Debugging
* [Determining the Reason for Pod Failure](/docs/tasks/debug-application-cluster/determine-reason-pod-failure/)
* [Debugging Init Containers](/docs/tasks/debug-application-cluster/debug-init-containers/)
* [Logging Using Stackdriver](/docs/tasks/debug-application-cluster/logging-stackdriver/)
* [Logging Using ElasticSearch and Kibana](/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/)
#### Accessing the Kubernetes API
@@ -55,10 +63,6 @@ single thing, typically by giving a short sequence of steps.
* [Debugging a StatefulSet](/docs/tasks/manage-stateful-set/debugging-a-statefulset/)
* [Force Deleting StatefulSet Pods](/docs/tasks/manage-stateful-set/delete-pods/)
#### Troubleshooting
* [Debugging Init Containers](/docs/tasks/troubleshoot/debug-init-containers/)
### What's next
If you would like to write a task page, see