Initial pod logs documentation

doc/user/project/clusters/index.md

@@ -349,6 +349,11 @@ To remove the Kubernetes cluster integration from your project, simply click on
 **Remove integration** button. You will then be able to follow the procedure
 and add a Kubernetes cluster again.
 
+## View Kubernetes pod logs from GitLab **[ULTIMATE]**
+
+Learn how to easily
+[view the logs of running pods in connected Kubernetes clusters](kubernetes_pod_logs.md).
+
 ## What you can get with the Kubernetes integration
 
 Here's what you can do with GitLab if you enable the Kubernetes integration.
@@ -361,7 +366,7 @@ displaying the status of the pods in the deployment. Developers and other
 teammates can view the progress and status of a rollout, pod by pod, in the
 workflow they already use without any need to access Kubernetes.
 
-[> Read more about Deploy Boards](../deploy_boards.md)
+[Read more about Deploy Boards](../deploy_boards.md)
 
 ### Canary Deployments **[PREMIUM]**
 
@@ -369,14 +374,14 @@ Leverage [Kubernetes' Canary deployments](https://kubernetes.io/docs/concepts/cl
 and visualize your canary deployments right inside the Deploy Board, without
 the need to leave GitLab.
 
-[> Read more about Canary Deployments](../canary_deployments.md)
+[Read more about Canary Deployments](../canary_deployments.md)
 
 ### Kubernetes monitoring
 
 Automatically detect and monitor Kubernetes metrics. Automatic monitoring of
 [NGINX ingress](../integrations/prometheus_library/nginx.md) is also supported.
 
-[> Read more about Kubernetes monitoring](../integrations/prometheus_library/kubernetes.md)
+[Read more about Kubernetes monitoring](../integrations/prometheus_library/kubernetes.md)
 
 ### Auto DevOps
 
@@ -386,7 +391,7 @@ applications.
 To make full use of Auto DevOps(Auto Deploy, Auto Review Apps, and Auto Monitoring)
 you will need the Kubernetes project integration enabled.
 
-[> Read more about Auto DevOps](../../../topics/autodevops/index.md)
+[Read more about Auto DevOps](../../../topics/autodevops/index.md)
 
 ### Web terminals
 
@@ -402,9 +407,9 @@ containers. To use this integration, you should deploy to Kubernetes using
 the deployment variables above, ensuring any pods you create are labelled with
 `app=$CI_ENVIRONMENT_SLUG`. GitLab will do the rest!
 
-## Read more
+## Integrating Amazon EKS cluster with GitLab
 
-- [Connecting and deploying to an Amazon EKS cluster](eks_and_gitlab/index.md)
+Learn how to [connect and deploy to an Amazon EKS cluster](eks_and_gitlab/index.md).
 
 [permissions]: ../../permissions.md
 [ee]: https://about.gitlab.com/products/

doc/user/project/clusters/kubernetes_pod_logs.md

+# Kubernetes Pod Logs **[ULTIMATE]**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/4752) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 11.0.
+
+GitLab makes it easy to view the logs of running pods in [connected Kubernetes clusters](index.md).
+By displaying the logs directly in GitLab, developers can avoid having to manage console tools or jump to a different interface.
+
+## Overview
+
+[Kubernetes](https://kubernetes.io) pod logs can be viewed directly within GitLab. Logs can be displayed by clicking on a specific pod from [Deploy Boards](../deploy_boards.md):
+
+1. Go to **Operations > Environments** and find the environment which contains the desired pod, like `production`.
+1. On the **Environments** page, you should see the status of the environment's pods with [Deploy Boards](../deploy_boards.md).
+1. When mousing over the list of pods, a tooltip will appear with the exact pod name and status.
+![Deploy Boards pod list](img/pod_logs_deploy_board.png)
+1. Click on the desired pod to bring up the logs view, which will contain the last 500 lines for that pod. Support for pods with multiple containers is coming [in a future release](https://gitlab.com/gitlab-org/gitlab-ee/issues/6502).
+![Deploy Boards pod list](img/kubernetes_pod_logs.png)
+
+## Requirements
+
+There are a few key requirements in order to be able to use Pod Logs:
+
+1. [Create or connect a Kubernetes cluster to the project](index.md#adding-and-creating-a-new-gke-cluster-via-gitlab)
+1. A GitLab Runner. If one is not available, they can be easily [deployed](index.md#installing-applications).
+1. Ensure a Kubernetes label of `app: $CI_ENVIRONMENT_SLUG` is applied to the
+   deployments, replica sets, and pods, where `$CI_ENVIRONMENT_SLUG` is the value
+   of the [CI variable](../../../ci/variables/README.md#predefined-variables-environment-variables).
+   This needed to determine the environment a pod belongs to
+   when is more than one. These resources should be
+   contained in the namespace defined in the Kubernetes service setting.
+   The [Auto DevOps](../../../topics/autodevops/index.md) `.gitlab-ci.yml` template has predefined
+   stages and commands to use, and automatically applies the labeling.

doc/user/project/deploy_boards.md

@@ -78,7 +78,7 @@ To display the Deploy Boards for a specific [environment] you should:
     ![Deploy Boards Kubernetes Label](img/deploy_boards_kubernetes_label.png)
 
 Once all of the above are set up and the pipeline has run at least once,
-navigate to the environments page under **Pipelines > Environments**.
+navigate to the environments page under **Operations > Environments**.
 
 Deploy Boards are visible by default. You can explicitly click
 the triangle next to their respective environment name in order to hide them.