Apply templates to all concepts and tasks to fix double bullets in TOC (#9149)
* Apply concept template to fix double bullet issue. * Apply concept template * Apply templates to tasks
This commit is contained in:
Steve Perry
committed by
k8s-ci-robot
k8s-ci-robot
parent
ec15f3fab9
commit
75f00dfc60
@@ -3,10 +3,11 @@ reviewers:
|
||||
- soltysh
|
||||
- sttts
|
||||
- ericchiang
|
||||
content_template: templates/concept
|
||||
title: Auditing
|
||||
---
|
||||
|
||||
{{< toc >}}
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< feature-state state="beta" >}}
|
||||
|
||||
@@ -23,6 +24,12 @@ answer the following questions:
|
||||
- from where was it initiated?
|
||||
- to where was it going?
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
[Kube-apiserver][kube-apiserver] performs auditing. Each request on each stage
|
||||
of its execution generates an event, which is then pre-processed according to
|
||||
a certain policy and written to a backend. The policy determines what's recorded
|
||||
@@ -97,6 +104,7 @@ In both cases, audit events structure is defined by the API in the
|
||||
`audit.k8s.io` API group. The current version of the API is
|
||||
[`v1beta1`][auditing-api].
|
||||
|
||||
{{< note >}}
|
||||
**Note:** In case of patches, request body is a JSON array with patch operations, not a JSON object
|
||||
with an appropriate Kubernetes API object. For example, the following request body is a valid patch
|
||||
request to `/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`.
|
||||
@@ -114,6 +122,7 @@ request to `/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`.
|
||||
}
|
||||
]
|
||||
```
|
||||
{{< /note >}}
|
||||
|
||||
### Log backend
|
||||
|
||||
@@ -200,7 +209,7 @@ 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
|
||||
|
||||
```shell
|
||||
```none
|
||||
$ cat <<EOF > /etc/fluentd/config
|
||||
# fluentd conf runs in the same host with kube-apiserver
|
||||
<source>
|
||||
@@ -260,7 +269,7 @@ In this example, we will use fluentd to split audit events by different namespac
|
||||
--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
|
||||
1. check audits for different namespaces in `/var/log/audit-*.log`
|
||||
|
||||
### Use logstash to collect and distribute audit events from webhook backend
|
||||
|
||||
@@ -271,7 +280,7 @@ different users into different files.
|
||||
1. install [logstash][logstash_install_doc]
|
||||
1. create config file for logstash
|
||||
|
||||
```shell
|
||||
```none
|
||||
$ cat <<EOF > /etc/logstash/config
|
||||
input{
|
||||
http{
|
||||
@@ -308,7 +317,7 @@ different users into different files.
|
||||
|
||||
1. create a [kubeconfig file](/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/) for kube-apiserver webhook audit backend
|
||||
|
||||
```shell
|
||||
```none
|
||||
$ cat <<EOF > /etc/kubernetes/audit-webhook-kubeconfig
|
||||
apiVersion: v1
|
||||
clusters:
|
||||
@@ -333,7 +342,7 @@ different users into different files.
|
||||
--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
|
||||
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
|
||||
let users route data where they want. For example, users can emit audit events to elasticsearch
|
||||
@@ -392,3 +401,5 @@ and `audit-log-maxage` options.
|
||||
[logstash]: https://www.elastic.co/products/logstash
|
||||
[logstash_install_doc]: https://www.elastic.co/guide/en/logstash/current/installing-logstash.html
|
||||
[kube-aggregator]: /docs/concepts/api-extension/apiserver-aggregation
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -3,13 +3,22 @@ reviewers:
|
||||
- fgrzadkowski
|
||||
- piosz
|
||||
title: Core metrics pipeline
|
||||
content_template: templates/concept
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
Starting from Kubernetes 1.8, resource usage metrics, such as container CPU and memory usage,
|
||||
are available in Kubernetes through the Metrics API. These metrics can be either accessed directly
|
||||
by user, for example by using `kubectl top` command, or used by a controller in the cluster, e.g.
|
||||
Horizontal Pod Autoscaler, to make decisions.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## The Metrics API
|
||||
|
||||
Through the Metrics API you can get the amount of resource currently used
|
||||
@@ -42,3 +51,5 @@ Metrics Server registered in the main API server through
|
||||
which was introduced in Kubernetes 1.7.
|
||||
|
||||
Learn more about the metrics server in [the design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -2,15 +2,22 @@
|
||||
reviewers:
|
||||
- janetkuo
|
||||
- thockin
|
||||
content_template: templates/concept
|
||||
title: Application Introspection and Debugging
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
Once your application is running, you'll inevitably need to debug problems with it.
|
||||
Earlier we described how you can use `kubectl get pods` to retrieve simple status information about
|
||||
your pods. But there are a number of ways to get even more information about your application.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Using `kubectl describe pod` to fetch details about pods
|
||||
|
||||
For this example we'll use a Deployment to create two pods, similar to the earlier example.
|
||||
@@ -255,7 +262,9 @@ kubernetes-node-861h NotReady 1h v1.6.0+fff5156
|
||||
kubernetes-node-bols Ready 1h v1.6.0+fff5156
|
||||
kubernetes-node-st6x Ready 1h v1.6.0+fff5156
|
||||
kubernetes-node-unaj Ready 1h v1.6.0+fff5156
|
||||
```
|
||||
|
||||
```shell
|
||||
$ kubectl describe node kubernetes-node-861h
|
||||
Name: kubernetes-node-861h
|
||||
Role
|
||||
@@ -307,8 +316,12 @@ Allocated resources:
|
||||
------------ ---------- --------------- -------------
|
||||
900m (60%) 2200m (146%) 1009286400 (66%) 5681286400 (375%)
|
||||
Events: <none>
|
||||
```
|
||||
|
||||
```shell
|
||||
$ kubectl get node kubernetes-node-861h -o yaml
|
||||
```
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Node
|
||||
metadata:
|
||||
@@ -350,7 +363,7 @@ status:
|
||||
systemUUID: ABE5F6B4-D44B-108B-C46A-24CCE16C8B6E
|
||||
```
|
||||
|
||||
## What's next?
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
Learn about additional debugging tools, including:
|
||||
|
||||
@@ -360,4 +373,4 @@ Learn about additional debugging tools, including:
|
||||
* [Connecting to containers via proxies](/docs/tasks/access-kubernetes-api/http-proxy-access-api/)
|
||||
* [Connecting to containers via port forwarding](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -3,14 +3,21 @@ reviewers:
|
||||
- mikedanese
|
||||
- thockin
|
||||
title: Troubleshoot Applications
|
||||
content_template: templates/concept
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
This guide is to help users debug applications that are deployed into Kubernetes and not behaving correctly.
|
||||
This is *not* a guide for people who want to debug their cluster. For that you should check out
|
||||
[this guide](/docs/admin/cluster-troubleshooting).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Diagnosing the problem
|
||||
|
||||
The first step in troubleshooting is triage. What is the problem? Is it your Pods, your Replication Controller or
|
||||
@@ -183,8 +190,12 @@ check:
|
||||
* Can you connect to your pods directly? Get the IP address for the Pod, and try to connect directly to that IP.
|
||||
* Is your application serving on the port that you configured? Kubernetes doesn't do port remapping, so if your application serves on 8080, the `containerPort` field needs to be 8080.
|
||||
|
||||
#### More information
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
If none of the above solves your problem, follow the instructions in [Debugging Service document](/docs/user-guide/debugging-services) to make sure that your `Service` is running, has `Endpoints`, and your `Pods` are actually serving; you have DNS working, iptables rules installed, and kube-proxy does not seem to be misbehaving.
|
||||
|
||||
You may also visit [troubleshooting document](/docs/troubleshooting/) for more information.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -2,13 +2,22 @@
|
||||
reviewers:
|
||||
- davidopp
|
||||
title: Troubleshoot Clusters
|
||||
content_template: templates/concept
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
This doc is about cluster troubleshooting; we assume you have already ruled out your application as the root cause of the
|
||||
problem you are experiencing. See
|
||||
the [application troubleshooting guide](/docs/tasks/debug-application-cluster/debug-application) for tips on application debugging.
|
||||
You may also visit [troubleshooting document](/docs/troubleshooting/) for more information.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Listing your cluster
|
||||
|
||||
The first thing to debug in your cluster is if your nodes are all registered correctly.
|
||||
@@ -113,3 +122,5 @@ Mitigations:
|
||||
|
||||
- Action: [Multiple independent clusters](/docs/concepts/cluster-administration/federation/) (and avoid making risky changes to all clusters at once)
|
||||
- Mitigates: Everything listed above.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -2,11 +2,10 @@
|
||||
reviewers:
|
||||
- bprashanth
|
||||
title: Debug Pods and Replication Controllers
|
||||
content_template: templates/concept
|
||||
---
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
## Debugging pods
|
||||
{{% capture overview %}}
|
||||
|
||||
The first step in debugging a pod is taking a look at it. Check the current
|
||||
state of the pod and recent events with the following command:
|
||||
@@ -18,6 +17,12 @@ there been recent restarts?
|
||||
|
||||
Continue debugging depending on the state of the pods.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
### My pod stays pending
|
||||
|
||||
If a pod is stuck in `Pending` it means that it can not be scheduled onto a
|
||||
@@ -105,3 +110,4 @@ or they can't. If they can't create pods, then please refer to the
|
||||
You can also use `kubectl describe rc ${CONTROLLER_NAME}` to inspect events
|
||||
related to the replication controller.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -2,16 +2,22 @@
|
||||
reviewers:
|
||||
- thockin
|
||||
- bowei
|
||||
content_template: templates/concept
|
||||
title: Debug Services
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
An issue that comes up rather frequently for new installations of Kubernetes is
|
||||
that a `Service` is not working properly. You've run your `Deployment` and
|
||||
created a `Service`, but you get no response when you try to access it.
|
||||
This document will hopefully help you to figure out what's going wrong.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Conventions
|
||||
|
||||
Throughout this doc you will see various commands that you can run. Some
|
||||
@@ -45,7 +51,7 @@ OUTPUT
|
||||
For many steps here you will want to see what a `Pod` running in the cluster
|
||||
sees. The simplest way to do this is to run an interactive busybox `Pod`:
|
||||
|
||||
```shell
|
||||
```none
|
||||
$ kubectl run -it --rm --restart=Never busybox --image=busybox sh
|
||||
If you don't see a command prompt, try pressing enter.
|
||||
/ #
|
||||
@@ -291,6 +297,8 @@ and verify it:
|
||||
|
||||
```shell
|
||||
$ kubectl get service hostnames -o json
|
||||
```
|
||||
```json
|
||||
{
|
||||
"kind": "Service",
|
||||
"apiVersion": "v1",
|
||||
@@ -430,7 +438,7 @@ depends on your `Node` OS. On some OSes it is a file, such as
|
||||
/var/log/kube-proxy.log, while other OSes use `journalctl` to access logs. You
|
||||
should see something like:
|
||||
|
||||
```shell
|
||||
```none
|
||||
I1027 22:14:53.995134 5063 server.go:200] Running in resource-only container "/kube-proxy"
|
||||
I1027 22:14:53.998163 5063 server.go:247] Using iptables Proxier.
|
||||
I1027 22:14:53.999055 5063 server.go:255] Tearing down userspace rules. Errors here are acceptable.
|
||||
@@ -584,7 +592,7 @@ the permission to operate in `/sys` on node. If everything works properly,
|
||||
you should see something like:
|
||||
|
||||
```shell
|
||||
u@node$ for intf in /sys/devices/virtual/net/cbr0/brif/*; do cat $intf/hairpin_mode; done
|
||||
for intf in /sys/devices/virtual/net/cbr0/brif/*; do cat $intf/hairpin_mode; done
|
||||
1
|
||||
1
|
||||
1
|
||||
@@ -603,7 +611,6 @@ UP BROADCAST RUNNING PROMISC MULTICAST MTU:1460 Metric:1
|
||||
|
||||
* Seek help if none of above works out.
|
||||
|
||||
|
||||
## Seek help
|
||||
|
||||
If you get this far, something very strange is happening. Your `Service` is
|
||||
@@ -617,7 +624,10 @@ Contact us on
|
||||
[email](https://groups.google.com/forum/#!forum/kubernetes-users) or
|
||||
[GitHub](https://github.com/kubernetes/kubernetes).
|
||||
|
||||
## More information
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
Visit [troubleshooting document](/docs/troubleshooting/) for more information.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -2,10 +2,11 @@
|
||||
reviewers:
|
||||
- piosz
|
||||
- x13n
|
||||
content_template: templates/concept
|
||||
title: Events in Stackdriver
|
||||
---
|
||||
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
Kubernetes events are objects that provide insight into what is happening
|
||||
inside a cluster, such as what decisions were made by scheduler or why some
|
||||
@@ -23,18 +24,24 @@ to capture events.
|
||||
This article describes a solution that exports Kubernetes events to
|
||||
Stackdriver Logging, where they can be processed and analyzed.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** it is not guaranteed that all events happening in a cluster will be
|
||||
exported to Stackdriver. One possible scenario when events will not be
|
||||
exported is when event exporter is not running (e.g. during restart or
|
||||
upgrade). In most cases it's fine to use events for purposes like setting up
|
||||
[metrics][sdLogMetrics] and [alerts][sdAlerts], but you should be aware
|
||||
of the potential inaccuracy.
|
||||
{{< /note >}}
|
||||
|
||||
[sdLogMetrics]: https://cloud.google.com/logging/docs/view/logs_based_metrics
|
||||
[sdAlerts]: https://cloud.google.com/logging/docs/view/logs_based_metrics#creating_an_alerting_policy
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Deployment
|
||||
|
||||
### Google Kubernetes Engine
|
||||
@@ -85,4 +92,6 @@ jsonPayload.source.component="default-scheduler"
|
||||
jsonPayload.involvedObject.name:"nginx-deployment"
|
||||
```
|
||||
|
||||
<img src="/images/docs/stackdriver-event-exporter-filter.png" alt="Filtered events in the Stackdriver Logging interface" width="500">
|
||||
{{< figure src="/images/docs/stackdriver-event-exporter-filter.png" alt="Filtered events in the Stackdriver Logging interface" width="500" >}}
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -2,9 +2,12 @@
|
||||
reviewers:
|
||||
- piosz
|
||||
- x13n
|
||||
content_template: templates/concept
|
||||
title: Logging Using Elasticsearch and Kibana
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
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).
|
||||
@@ -16,6 +19,10 @@ Stackdriver Logging when running on GCE. Note that Elasticsearch and Kibana
|
||||
cannot be setup automatically in the Kubernetes cluster hosted on
|
||||
Google Kubernetes Engine, you have to deploy it manually.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
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:
|
||||
@@ -101,6 +108,11 @@ Here is a typical view of ingested logs from the Kibana viewer:
|
||||
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
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).
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -3,15 +3,26 @@ reviewers:
|
||||
- piosz
|
||||
- x13n
|
||||
title: Logging Using Stackdriver
|
||||
content_template: templates/concept
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
Before reading this page, it's highly recommended to familiarize yourself
|
||||
with the [overview of logging in Kubernetes](/docs/concepts/cluster-administration/logging).
|
||||
|
||||
{{< note >}}
|
||||
**Note:** By default, Stackdriver logging collects only your container's standard output and
|
||||
standard error streams. To collect any logs your application writes to a file (for example),
|
||||
see the [sidecar approach](/docs/concepts/cluster-administration/logging#sidecar-container-with-a-logging-agent)
|
||||
in the Kubernetes logging overview.
|
||||
{{< /note >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Deploying
|
||||
|
||||
@@ -213,7 +224,7 @@ 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
|
||||
```none
|
||||
$ 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"
|
||||
@@ -335,3 +346,5 @@ with minor changes:
|
||||
|
||||
Then run `make build push` from this directory. After updating `DaemonSet` to pick up the
|
||||
new image, you can use the plugin you installed in the fluentd configuration.
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -2,12 +2,11 @@
|
||||
reviewers:
|
||||
- Random-Liu
|
||||
- dchen1107
|
||||
content_template: templates/task
|
||||
title: Monitor Node Health
|
||||
---
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
## Node Problem Detector
|
||||
{{% capture overview %}}
|
||||
|
||||
*Node problem detector* is a [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) monitoring the
|
||||
node health. It collects node problems from various daemons and reports them
|
||||
@@ -24,6 +23,16 @@ introduced to deal with node problems.
|
||||
See more information
|
||||
[here](https://github.com/kubernetes/node-problem-detector).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## Limitations
|
||||
|
||||
* The kernel issue detection of node problem detector only supports file based
|
||||
@@ -153,6 +162,10 @@ Kernel monitor uses [`Translator`](https://github.com/kubernetes/node-problem-de
|
||||
plugin to translate kernel log the internal data structure. It is easy to
|
||||
implement a new translator for a new log format.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture discussion %}}
|
||||
|
||||
## Caveats
|
||||
|
||||
It is recommended to run the node problem detector in your cluster to monitor
|
||||
@@ -163,3 +176,5 @@ resource overhead on each node. Usually this is fine, because:
|
||||
* Resource limit is set for node problem detector.
|
||||
* Even under high load, the resource usage is acceptable.
|
||||
(see [benchmark result](https://github.com/kubernetes/node-problem-detector/issues/2#issuecomment-220255629))
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -1,12 +1,19 @@
|
||||
---
|
||||
reviewers:
|
||||
- mikedanese
|
||||
content_template: templates/concept
|
||||
title: Tools for Monitoring Compute, Storage, and Network Resources
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
Understanding how an application behaves when deployed is crucial to scaling the application and providing a reliable service. In a Kubernetes cluster, application performance can be examined at many different levels: containers, [pods](/docs/user-guide/pods), [services](/docs/user-guide/services), and whole clusters. As part of Kubernetes we want to provide users with detailed resource usage information about their running applications at all these levels. This will give users deep insights into how their applications are performing and where possible application bottlenecks may be found. In comes [Heapster](https://github.com/kubernetes/heapster), a project meant to provide a base monitoring platform on Kubernetes.
|
||||
|
||||
## Overview
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
Heapster is a cluster-wide aggregator of monitoring and event data. It currently supports Kubernetes natively and works on all Kubernetes setups. Heapster runs as a pod in the cluster, similar to how any Kubernetes application would run. The Heapster pod discovers all nodes in the cluster and queries usage information from the nodes' [Kubelet](/docs/admin/kubelet/)s, the on-machine Kubernetes agent. The Kubelet itself fetches the data from [cAdvisor](https://github.com/google/cadvisor). Heapster groups the information by pod along with the relevant labels. This data is then pushed to a configurable backend for storage and visualization. Currently supported backends include [InfluxDB](http://influxdb.com/) (with [Grafana](http://grafana.org/) for visualization), [Google Cloud Monitoring](https://cloud.google.com/monitoring/) and many others described in more details [here](https://git.k8s.io/heapster/docs/sink-configuration.md). The overall architecture of the service can be seen below:
|
||||
|
||||
@@ -54,10 +61,10 @@ Here is a snapshot of the Google Cloud Monitoring dashboard showing cluster-wide
|
||||
|
||||
|
||||
|
||||
## Try it out!
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
Now that you've learned a bit about Heapster, feel free to try it out on your own clusters! The [Heapster repository](https://github.com/kubernetes/heapster) is available on GitHub. It contains detailed instructions to setup Heapster and its storage backends. Heapster runs by default on most Kubernetes clusters, so you may already have it! Feedback is always welcome. Please let us know if you run into any issues via the troubleshooting [channels](/docs/troubleshooting/).
|
||||
|
||||
***
|
||||
*Authors: Vishnu Kannan and Victor Marmol, Google Software Engineers.*
|
||||
*This article was originally posted in [Kubernetes Blog](https://kubernetes.io/blog/2015/05/resource-usage-monitoring-kubernetes).*
|
||||
{{% /capture %}}
|
||||
@@ -2,9 +2,12 @@
|
||||
reviewers:
|
||||
- brendandburns
|
||||
- davidopp
|
||||
content_template: templates/concept
|
||||
title: Troubleshooting
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
Sometimes things go wrong. This guide is aimed at making them right. It has
|
||||
two sections:
|
||||
|
||||
@@ -14,6 +17,12 @@ two sections:
|
||||
You should also check the known issues for the [release](https://github.com/kubernetes/kubernetes/releases)
|
||||
you're using.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Getting help
|
||||
|
||||
If your problem isn't answered by any of the guides above, there are variety of
|
||||
@@ -93,3 +102,5 @@ problem, such as:
|
||||
* Kubernetes version: `kubectl version`
|
||||
* Cloud provider, OS distro, network configuration, and Docker version
|
||||
* Steps to reproduce the problem
|
||||
|
||||
{{% /capture %}}
|
||||
Reference in New Issue
Block a user