Skip to content

Commit

Permalink
Merge remote-tracking branch 'upstream/master' into upstream_sync
Browse files Browse the repository at this point in the history
* upstream/master:
  pkg/alertmanager: change podManagement policy to parallel to prevent statefulset reconciliation from hanging
  support KUBECONFIG environment
  fix namespaceSelector: any
  Adjust thanos doc accordinly to prometheus-operator#2629
  regenerate
  Add more recent prometheus versions to compatibility matrix
  make --always-make vendor
  Adding label selector for AlertManager objects discovery filtering
  Create docuementation for ingress monitoring
  pkg/alertmanager: increase terminationGracePeriod to 120
  Update Kubernetes client libraries to 1.15.0
  alertmanager/statefulset: move gossip port to 9094
  • Loading branch information
paulfantom committed Jul 22, 2019
2 parents ab4b3b1 + 14d447f commit adcafc9
Show file tree
Hide file tree
Showing 28 changed files with 906 additions and 124 deletions.
4 changes: 4 additions & 0 deletions Documentation/compatibility.md
Expand Up @@ -44,6 +44,10 @@ The versions of Prometheus compatible to be run with the Prometheus Operator are
* v2.6.1
* v2.7.0
* v2.7.1
* v2.7.2
* v2.8.1
* v2.9.2
* v2.10.0

## Alertmanager

Expand Down
27 changes: 15 additions & 12 deletions Documentation/network-policies.md
Expand Up @@ -5,7 +5,7 @@

# Network policies

[Network policies](https://kubernetes.io/docs/user-guide/networkpolicies/) allow you easily restrict the ingress traffic between pods using [k8s labels](https://kubernetes.io/docs/user-guide/labels/).
[Network policies](https://kubernetes.io/docs/user-guide/networkpolicies/) allow you easily restrict the ingress traffic between pods using [k8s labels](https://kubernetes.io/docs/user-guide/labels/).
To keep your cluster safer, it's strongly recommended to enable network policies into prometheus namespace.

# Example
Expand All @@ -16,14 +16,14 @@ This example will close all inbound communication on the namespace monitoring, a
First, follow the instructions to [add Calico to an existing Kubernetes cluster](http://docs.projectcalico.org/v1.5/getting-started/kubernetes/installation/).

Next, use the following configuration to deny all the ingress (inbound) traffic.
```yaml
```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
namespace: monitoring
spec:
podSelector:
podSelector:
matchLabels:
```
Save the config file as default-deny-all.yaml and apply the configuration to the cluster using
Expand All @@ -35,7 +35,7 @@ kubectl apply -f <path to config file>/default-deny-all.yaml
Apply the following network policies to allow the necessary traffic to access ports in the pod:

```
$ kubectl apply -n monitoring -f example/networkpolicies/
$ kubectl apply -n monitoring -f example/networkpolicies/
networkpolicy "alertmanager-web" configured
networkpolicy "alertmanager-mesh" configured
Expand All @@ -48,9 +48,9 @@ networkpolicy "prometheus" configured

#### Alertmanager

* Allow inbound tcp dst port 9093 from any source to alertmanager
* Allow inbound tcp dst port 6783 from only alertmanager to alertmanager
* Allow inbound tcp dst port 9093 from any source to alertmanager
* Allow inbound tcp & udp dst port 9094 from only alertmanager to alertmanager

[embedmd]:# (../example/networkpolicies/alertmanager.yaml)
```yaml
apiVersion: networking.k8s.io/v1
Expand Down Expand Up @@ -86,17 +86,20 @@ spec:
values:
- main
ports:
- port: 6783
- port: 9094
protocol: TCP
- port: 9094
protocol: UDP
podSelector:
matchLabels:
alertmanager: main
app: alertmanager

```

#### Grafana

* Allow inbound tcp dst port 3000 from any source to grafana
* Allow inbound tcp dst port 3000 from any source to grafana

[embedmd]:# (../example/networkpolicies/grafana.yaml)
```yaml
Expand All @@ -116,7 +119,7 @@ spec:

#### Prometheus

* Allow inbound tcp dst port 9090 from any source to prometheus
* Allow inbound tcp dst port 9090 from any source to prometheus

[embedmd]:# (../example/networkpolicies/prometheus.yaml)
```yaml
Expand All @@ -137,7 +140,7 @@ spec:

#### Node-exporter

* Allow inbound tcp dst port 9100 from only prometheus to node-exporter
* Allow inbound tcp dst port 9100 from only prometheus to node-exporter

[embedmd]:# (../example/networkpolicies/node-exporter.yaml)
```yaml
Expand Down Expand Up @@ -168,7 +171,7 @@ spec:

#### Kube-state-metrics

* Allow inbound tcp dst port 8080 from only prometheus to kube-state-metrics
* Allow inbound tcp dst port 8080 from only prometheus to kube-state-metrics

[embedmd]:# (../example/networkpolicies/kube-state-metrics.yaml)
```yaml
Expand Down
9 changes: 2 additions & 7 deletions Documentation/thanos.md
Expand Up @@ -54,14 +54,10 @@ kubectl -n monitoring create secret generic thanos-objstore-config --from-file=t
### Prometheus Custom Resource with Thanos Sidecar

The `Prometheus` CRD has support for adding a Thanos sidecar to the Prometheus
Pod. To enable the sidecar, reference the following examples. These examples
assume that the Thanos components have been configured to use the
`thanos-peers.monitoring.svc:10900` service for querier peers to connect to,
which is important for getting high availability to work with Thanos.
Pod. To enable the sidecar, reference the following examples.

This is the simplest configuration change that needs to be made to your
Prometheus Custom Resource, after creating the secret, and is the only configuration needed to
provide high availability benefits.
Prometheus Custom Resource, after creating the secret.

```
...
Expand All @@ -70,7 +66,6 @@ spec:
thanos:
baseImage: improbable/thanos
version: v0.2.1
peers: thanos-peers.monitoring.svc:10900
objectStorageConfig:
key: thanos.yaml
name: thanos-objstore-config
Expand Down
197 changes: 197 additions & 0 deletions Documentation/user-guides/monitoring-kubernetes-ingress.md
@@ -0,0 +1,197 @@
<br>
<div class="alert alert-info" role="alert">
<i class="fa fa-exclamation-triangle"></i><b> Note:</b> Starting with v0.12.0, Prometheus Operator requires use of Kubernetes v1.7.x and up.<br><br>
This documentation is for an alpha feature. For questions and feedback on the Prometheus OCS Alpha program, email <a href="mailto:tectonic-alpha-feedback@coreos.com">tectonic-alpha-feedback@coreos.com</a>.
</div>

# Monitoring Kubernetes Ingress with Ambassador
[Ambassador](https://www.getambassador.io/) is a popular open-source API gateway for Kubernetes. Built on [Envoy Proxy](https://www.envoyproxy.io), Ambassador natively exposes statistics that give you better insight to what is happening at the edge of your Kubernetes cluster. In this guide we will:

* Create a simple Kubernetes application
* Deploy Ambassador as your Kubernetes ingress controller
* Use the Prometheus Operator to deploy and manage our Prometheus instance
* Examine some metrics related to the performance of Kubernetes application at the edge

## Prerequisites
* A Kubernetes Cluster
* The [Kubernetes command line tool](https://kubernetes.io/docs/tasks/tools/install-kubectl/)

## Deploy and Expose an Application on Kubernetes
First, we need an application running on Kubernetes for our users to access. You can deploy any application you would like but, for simplicity, we will use a [sample application](https://www.getambassador.io/user-guide/getting-started#3-creating-your-first-service) provided by the Ambassador team.

We can quickly deploy this application using `kubectl`:

```
kubectl apply -f https://getambassador.io/yaml/tour/tour.yaml
```

Check the application's status and wait for it to start running:

```
$ kubectl get po --selector=app=tour
NAME READY STATUS RESTARTS AGE
tour-6df995489d-lc9hs 2/2 Running 0 1m
```

Now that we have an application running in Kubernetes, we need to expose it to the outside world. We will do this with Ambassador to take advantage of Envoy's robust metrics generation.

1. Deploy Ambassador to your cluster with `kubectl`:

```
kubectl apply -f https://getambassador.io/yaml/ambassador/ambassador-rbac.yaml
```
Ambassador is now running in your cluster and is ready to start routing traffic to your application.

2. Expose Ambassador to the internet.

```
kubectl apply -f https://getambassador.io/yaml/ambassador/ambassador-service.yaml
```
This will create a `LoadBalancer` service in Kubernetes which will automatically create a cloud load balancer if you are running in cloud-managed Kubernetes.

Kubernetes will automatically assign the load balancer's IP address as the `EXTERNAL_IP` of the service. You can view this with `kubectl`:

```
$ kubectl get svc ambassador
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
ambassador LoadBalancer 10.96.110.170 34.233.165.XXX 80:33241/TCP 87m
```
**Note:** If you are running in a different Kubernetes environment that does not automatically create a load balancer (like minikube), you can still access Ambassador using the `NodePort` of the service (33241 in this example).

3. Route traffic to your application

You configure Ambassador to expose your application using [annotations](https://www.getambassador.io/reference/configuration/) on the Kubernetes service of the application like the one below.

```yaml
---
apiVersion: v1
kind: Service
metadata:
name: tour
annotations:
getambassador.io/config: |
---
apiVersion: ambassador/v1
kind: Mapping
name: tour-ui_mapping
prefix: /
service: tour:5000
spec:
ports:
- name: ui
port: 5000
targetPort: 5000
selector:
app: tour
```

The example application above was deployed with a pre-configured annotation to expose it. You can can now access this application using the `EXTERNAL_IP` above and going to http://{AMBASSADOR_EXTERNAL_IP}/ from a web-browser.

You now have an application running in Kubernetes and exposed to the internet.

## Deploy Prometheus
Now that we have an application running and exposed by Ambassador, we need to configure Prometheus to scrape the metrics from Ambassador. The Prometheus Operator gives us a way to deploy and manage Prometheus deployments using Kubernetes-style resources

The Prometheus Operator creates Kubernetes Custom Resource Definitions (CRDs) so we can manage our Prometheus deployment using Kubernetes-style declarative YAML manifests. To deploy the Prometheus Operator, you can clone the [repository](https://github.com/coreos/prometheus-operator) and follow the instructions in the README. You can also just create it with `kubectl`:

```
kubectl apply -f https://raw.githubusercontent.com/coreos/prometheus-operator/master/bundle.yaml
```

Once the Prometheus operator is running, we need to create a Prometheus instance. The Prometheus Operator manages Prometheus deployments with the `Prometheus` CRD. To create a Prometheus instance and Kubernetes service, copy the following YAML to a file called `prometheus.yaml` and deploy it with `kubectl`:

```yaml
---
apiVersion: v1
kind: Service
metadata:
name: prometheus
annotations:
getambassador.io/config: |
---
apiVersion: ambassador/v1
kind: Mapping
name: prometheus_mapping
prefix: /prometheus/
service: prometheus:9090
spec:
type: ClusterIP
ports:
- name: web
port: 9090
protocol: TCP
targetPort: 9090
selector:
prometheus: prometheus
---
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
name: prometheus
spec:
externalUrl: http://{AMBASSADOR_EXTERNAL_IP}/prometheus
routePrefix: /prometheus
ruleSelector:
matchLabels:
app: prometheus-operator
serviceAccountName: prometheus-operator
serviceMonitorSelector:
matchLabels:
app: ambassador
resources:
requests:
memory: 400Mi
```

**Note:** The `externalUrl` and `routePrefix` fields allows for you to route requests to Prometheus through Ambassador on the `/prometheus` path. Replace `{AMBASSADOR_EXTERNAL_IP}` with the value from above.

```
kubectl apply -f prometheus.yaml
```
We now have Prometheus running in the cluster and exposed through Ambassador. View the Prometheus UI by going to http://{AMBASSADOR_EXTERNAL_IP}/prometheus/graph from a web browser.

Finally, we need tell Prometheus where to scrape metrics from. The Prometheus Operator easily manages this using a `ServiceMonitor` CRD. To tell Prometheus to scrape metrics from Ambassador's `/metrics` endpoint, we will use the Ambassador admin service and port `ambassador-admin`(8877). Copy the following YAML to a file called `ambassador-monitor.yaml` and apply it with `kubectl`:

```yaml
---
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: ambassador-monitor
namespace: monitoring
labels:
app: ambassador
spec:
namespaceSelector:
matchNames:
- default
selector:
matchLabels:
service: ambassador-admin
endpoints:
- port: ambassador-admin
```

```
kubectl apply -f ambassador-monitor.yaml
```

Prometheus will now be configured to collect metrics from the `ambassadr-admin` Kubernetes service with the internal address: `http://ambassador-admin:8877/metrics`.

## Examining Ingress Metrics

If you go to `http://{AMBASSADOR_EXTERNAL_IP}/prometheus/targets` from a web browser you will now see `ambassador-monitor` as a target for Prometheus to scrape metrics from Ambassador. Clicking on the drop down menu at `http://{AMBASSADOR_EXTERNAL_IP}/prometheus/graph`, you can see the various ingress-related metrics output by Envoy.

Envoy's metrics data model is remarkably similar to that of Prometheus and uses the same three kinds of statistics (`Counters`, `Gauges`, and `Histograms`). This allows for Envoy to export dynamic and data-rich statistics that are immediately useable by Prometheus's analytical functions.

**Notable Metrics:**

| Metric Category | Notable Metrics | Description |
| --------------- | --------------- | ----------- |
| envoy_http_downstream_rq | envoy_http_downstream_rq_http1_total <br></br> envoy_http_downstream_rq_http1_total <br></br> envoy_http_downstream_rq_total <br></br> envoy_http_downstream_rq_xx | Statistics regarding traffic from the internet, to each Ambassador instance. Tracking this will give you insight into how each pod is performing for various requests. |
| envoy_cluster_upstream_rq | envoy_cluster_upstream_rq <br></br> envoy_cluster_upstream_rq_xx <br></br> envoy_cluster_upstream_rq_total <br></br> envoy_cluster_upstream_rq_retry | Statistics regarding traffic from Envoy to each upstream service. Tracking this will give you insight to how the request is performing after reaching Ambassador. It will help you pinpoint whether failures are happening in Ambassador or the upstream service. |


Envoy collects many more statistics including some regarding rate limiting, circuit breaking, and distributed tracing. See the [Envoy's documentation](https://www.envoyproxy.io/docs/envoy/latest/configuration/http_conn_man/stats) for more information on the metrics envoy collects.
1 change: 1 addition & 0 deletions cmd/operator/main.go
Expand Up @@ -149,6 +149,7 @@ func init() {
flagset.StringVar(&cfg.LogFormat, "log-format", logFormatLogfmt, fmt.Sprintf("Log format to use. Possible values: %s", strings.Join(availableLogFormats, ", ")))
flagset.BoolVar(&cfg.ManageCRDs, "manage-crds", true, "Manage all CRDs with the Prometheus Operator.")
flagset.StringVar(&cfg.PromSelector, "prometheus-instance-selector", "", "Label selector to filter Prometheus CRDs to manage")
flagset.StringVar(&cfg.AlertManagerSelector, "alertmanager-instance-selector", "", "Label selector to filter AlertManager CRDs to manage")
flagset.Parse(os.Args[1:])
cfg.Namespaces = ns.asSlice()
}
Expand Down
7 changes: 5 additions & 2 deletions example/networkpolicies/alertmanager.yaml
Expand Up @@ -31,9 +31,12 @@ spec:
values:
- main
ports:
- port: 6783
- port: 9094
protocol: TCP
- port: 9094
protocol: UDP
podSelector:
matchLabels:
alertmanager: main
app: alertmanager
app: alertmanager

0 comments on commit adcafc9

Please sign in to comment.