update OShift/k8s instructions for older versions (DataDog#1616)

Dockerfiles/agent/OPENSHIFT.md

@@ -2,7 +2,7 @@
 
 Starting with version 6.1, the Datadog Agent supports monitoring OpenShift Origin and Enterprise clusters. Depending on your needs and the [security constraints](https://docs.openshift.org/latest/admin_guide/manage_scc.html) of your cluster, we support three deployment scenarios:
 
-| Security Context Constraints   | Restricted | Host network | Custom |
+| Security Context Constraints   | [Restricted](#restricted-scc-operations) | [Host network](#host-network-scc-operations) | [Custom](#custom-datadog-scc-for-all-features) |
 |--------------------------------|:----------:|:------------:|:------:|
 | Kubernetes layer monitoring    | ✅         | ✅          | ✅     |
 | Kubernetes-based Autodiscovery | ✅         | ✅          | ✅     |
@@ -18,13 +18,7 @@ Starting with version 6.1, the Datadog Agent supports monitoring OpenShift Origi
 ## General information
 
 - You should first refer to the [common installation instructions](README.md), and its [Kubernetes section](README.md#Kubernetes)
-- We only support full operations on OpenShift 3.7.0 and later, as we rely on new monitoring endpoints introduced in this version
-- On OpenShift 3.7, you will need to change the provided RBAC files to refer to the `rbac.authorization.k8s.io/v1beta1` apiVersion instead of `rbac.authorization.k8s.io/v1`. You can pipe them through sed like below:
-
-```
-sed "s%authorization.k8s.io/v1%authorization.k8s.io/v1beta1%" clusterrole.yaml | oc apply -f -
-sed "s%authorization.k8s.io/v1%authorization.k8s.io/v1beta1%" clusterrolebinding.yaml | oc apply -f -
-```
+- Our default configuration targets OpenShift 3.7.0 and later, as we rely on features and endpoints introduced in this version. [More installation steps](README.md#legacy-kubernetes-versions) are required for older versions.
 
 ## Restricted SCC operations
 

Dockerfiles/agent/README.md

@@ -167,6 +167,36 @@ This will create the Service Account in the default namespace, a Cluster Role wi
 
 The agent can collect node labels from the APIserver and report them as host tags. This feature is disabled by default, as it is usually redundant with cloud provider host tags. If you need to do so, you can provide a node label -> host tag mapping in the `DD_KUBERNETES_NODE_LABELS_AS_TAGS` environment variable. The format is the inline JSON described in the [tagging section](#Tagging).
 
+### Legacy Kubernetes Versions
+
+Our default configuration targets Kubernetes 1.7.6 and later, as we rely on features and endpoints introduced in this version. More installation steps are required for older versions:
+
+- [RBAC objects](https://kubernetes.io/docs/admin/authorization/rbac/) (`ClusterRoles` and `ClusterRoleBindings`) are available since Kubernetes 1.6 and OpenShift 1.3, but are available under different `apiVersion` prefixes:
+  * `rbac.authorization.k8s.io/v1` in Kubernetes 1.8+ (and OpenShift 3.9+), the default apiVersion we target
+  * `rbac.authorization.k8s.io/v1beta1` in Kubernetes 1.5 to 1.7 (and OpenShift 3.7)
+  * `v1` in Openshift 1.3 to 3.6
+
+You can apply our yaml manifests with the following `sed` invocations:
+```
+sed "s%authorization.k8s.io/v1%authorization.k8s.io/v1beta1%" clusterrole.yaml | kubectl apply -f -
+sed "s%authorization.k8s.io/v1%authorization.k8s.io/v1beta1%" clusterrolebinding.yaml | kubectl apply -f -
+```
+or for Openshift 1.3 to 3.6:
+```
+sed "s%rbac.authorization.k8s.io/v1%v1%" clusterrole.yaml | oc apply -f -
+sed "s%rbac.authorization.k8s.io/v1%v1%" clusterrolebinding.yaml | oc apply -f -
+```
+
+- The `kubelet` check retrieves metrics from the Kubernetes 1.7.6+ (OpenShift 3.7.0+) prometheus endpoint. You need to [enable cAdvisor port mode](https://github.com/DataDog/integrations-core/blob/41cb3c5164b4eebd01e250a0f322896493233813/kubelet/README.md#compatibility) for older versions.
+
+- Our default daemonset makes use of the [downward API](https://kubernetes.io/docs/tasks/inject-data-application/environment-variable-expose-pod-information/) to pass the kubelet's IP to the agent. This only works on versions 1.7 and up. For older versions, here are other ways to enable kubelet connectivity:
+
+  * On versions 1.6, use `fieldPath: spec.nodeName` and make sure your node name is resolvable and reachable from the pod
+  * If `DD_KUBERNETES_KUBELET_HOST` is unset, the agent will retrieve the node hostname from docker and try to connect there. See `docker info | grep "Name:"` and make sure the name is resolvable and reachable
+  * If the IP of the docker default gateway is constant across your cluster, you can directly pass that IP in the `DD_KUBERNETES_KUBELET_HOST` envvar. You can retrieve the IP with the `ip addr show | grep docker0` command.
+
+- Our default configuration relies on [bearer token authentication](https://kubernetes.io/docs/admin/authentication/#service-account-tokens) to the APIserver and kubelet. On 1.3, the kubelet does not support bearer token auth, you will need to setup client certificates for the `datadog-agent` serviceaccount and pass them to the agent.
+
 ## Log collection
 
 The Datadog Agent can collect logs from containers starting at the version 6. Two installations are possible:

releasenotes/notes/kubernetes-14-support-e8e0893b32fa960d.yaml

@@ -0,0 +1,11 @@
+---
+features:
+  - |
+    The agent has been tested on Kubernetes 1.4 & OpenShift 3.4. Refer to
+    https://github.com/DataDog/datadog-agent/blob/master/Dockerfiles/agent/README.md
+    for installation instructions    
+issues:
+  - |
+    Kubernetes 1.3 & OpenShift 3.3 are currently not fully supported: docker and kubelet
+    integrations work OK, but apiserver communication (event collection, `kube_service`
+    tagging) is not implemented