Update Getting Started logging docs for Cloud Logging #10203
Conversation
|
|
||
| ### Logging with Fluentd and Elastiscsearch | ||
| Cluster level logging for Kubernetes allows us to collect logs which persist beyond the lifetime of the pod’s container images or the lifetime of the pod or even cluster. In this article we assume that a Kubernetes cluster has been created with cluster level logging support for sending logs to Google Cloud Logging. This is an option when creating a Google Container Engine (GKE) cluster, and is enabled by default for the open source Google Compute Engine (GCE) Kubernetes distribution. After a cluster has been created you will have a collection of system pods running that support monitoring, logging and DNS resolution for names of Kubernetes services: |
There was a problem hiding this comment.
I believe Google Cloud Logging is also enabled by default for GKE.
There was a problem hiding this comment.
Removed the line about it being optional.
|
Thanks for adding, Satnam. LGTM, but I'd like @a-robinson to take a look. |
|
GCE e2e build/test failed for commit 8d44eff99897e9cbc91b7736d407dd4aa700c868. |
|
|
||
|  | ||
|
|
||
| This diagram shows four nodes created on a GCE cluster with the name of each VM node on a purple background. The internal and public IPs of each node are shown on gray boxes and the pods running in each node are shown in green boxes. Each pod box shows the name of the pod and the namespace it runs in, the IP address of the pod and the images which are run as part of the pod’s execution. The default namespace is used to run privileged system services rather than user applications. Here we see that every node is running a fluentd-cloud-logging pod which is collecting the log output of the containers running on the same node and sending them to Google Cloud Logging. A pod which provides a DNS service runs on one of the nodes and a pod which provides monitoring support runs on another node. |
There was a problem hiding this comment.
"The default namespace is used to run privileged system services rather than user applications"
Isn't the default namespace typically used for both?
There was a problem hiding this comment.
Can you make the "a DNS service" bit say "the cluster DNS service" and link to docs/dns.md?
There was a problem hiding this comment.
Removed the line about the namespace, added link to cluster DNS doc.
satnam6502
force-pushed
the
logging-doc
branch
2 times, most recently
from
edc1d22
to
4f3efc7
Compare
|
Thank you. PTAL. |
|
I've also updated the blog article with these changes. Thank you. |
|
LGTM Only nit is that it's better to use non-relative paths to other files in the repo rather than relative ones so that it's easier to move files around later, e.g. (/docs/dns.md) instead of (../dns.md) |
a-robinson
added
the
lgtm
|
Changed relative doc paths to absolute. |
|
GCE e2e build/test passed for commit edc1d22bd8039ed83070ac572253df2ed7e40d70. |
|
GCE e2e build/test passed for commit 4f3efc73c3433259a2c312033d5cb8425c77d5e1. |
|
LGTM |
|
GCE e2e build/test passed for commit 67991dd673c17b6a3216eddf8b3829c68f52aa64. |
Update Getting Started logging docs for Cloud Logging
|
GCE e2e build/test passed for commit 90caacb. |
Update the Getting Started guides for cluster level logging with Google Cloud Logging and update the env vars for Elasticsearch logging.