Прометей - Кубернетес RBAC

Question

Я обновляю свой GKE API-сервер до версии 1.6, и я нахожусь в процессе обновления узлов до версии 1.6, но столкнулся с проблемой...

У меня есть сервер Prometheus (версия 1.5.2), работающий в модуле, управляемом развертыванием Kubernetes с парой узлов, работающих под управлением версии 1.5.4 Kubelet, с одним новым узлом, работающим под управлением 1.6.

Прометей не может подключиться к новому узлу - конечная точка метрики возвращает 401 Несанкционированный.

Кажется, это проблема RBAC, но я не уверен, что делать дальше. Я не могу найти документы о том, какие роли нужны серверу Prometheus, или даже как предоставить их серверу.

Из репозитория coreos / prometheus-operator я смог собрать конфигурацию, которую я мог бы ожидать:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: prometheus
---

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: prometheus
rules:
- apiGroups: [""]
  resources:
  - nodes
  - services
  - endpoints
  - pods
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources:
  - configmaps
  verbs: ["get"]
- nonResourceURLs: ["/metrics"]
  verbs: ["get"]
---

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: prometheus
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: prometheus
subjects:
- kind: ServiceAccount
  name: prometheus
  namespace: default
---

apiVersion: v1
kind: ServiceAccount
metadata:
  name: prometheus
  namespace: default
secrets:
- name: prometheus-token-xxxxx

---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    app: prometheus-prometheus
    component: server
    release: prometheus
  name: prometheus-server
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: prometheus-prometheus
      component: server
      release: prometheus
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: prometheus-prometheus
        component: server
        release: prometheus
    spec:
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      serviceAccount: prometheus
      serviceAccountName: prometheus
      ...

Но Прометей все еще получает 401.

ОБНОВЛЕНИЕ: похоже на проблему аутентификации kubernetes, как сказал Джордан. Смотрите новый, более сфокусированный вопрос здесь; https://serverfault.com/questions/843751/kubernetes-node-metrics-endpoint-returns-401

Answer 1

В соответствии с обсуждением билета @JorritSalverda; https://github.com/prometheus/prometheus/issues/2606

Поскольку GKE не позволяет вам получать сертификаты клиентов, которые позволили бы вам аутентифицировать себя с помощью kubelet, лучшее решение для пользователей в GKE, по-видимому, использует сервер API kubernetes в качестве прокси-запросов к узлам.

Для этого (цитируя @JorritSalverda);

"Для моего сервера Prometheus, работающего внутри GKE, он теперь работает со следующей перемаркировкой:

relabel_configs:
- action: labelmap
  regex: __meta_kubernetes_node_label_(.+)
- target_label: __address__
  replacement: kubernetes.default.svc.cluster.local:443
- target_label: __scheme__
  replacement: https
- source_labels: [__meta_kubernetes_node_name]
  regex: (.+)
  target_label: __metrics_path__
  replacement: /api/v1/nodes/${1}/proxy/metrics

И следующее ClusterRole привязано к учетной записи службы, используемой Prometheus:

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: prometheus
rules:
- apiGroups: [""]
  resources:
  - nodes
  - nodes/proxy
  - services
  - endpoints
  - pods
  verbs: ["get", "list", "watch"]

Поскольку кластер GKE все еще имеет запасной вариант ABAC в случае сбоя RBAC, я не уверен на 100%, но это покрывает все необходимые разрешения.

Answer 2

401 означает неподтвержденный, что означает, что это не проблема RBAC. Я считаю, что GKE больше не разрешает анонимный доступ к kubelet в 1.6. Какие учетные данные вы используете для аутентификации в kubelet?

Answer 3

Это то, что я работаю для определения роли и связывания.

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: prometheus
rules:
- apiGroups: [""]
  resources:
  - nodes
  - services
  - endpoints
  - pods
  verbs: ["get", "list", "watch"]
- nonResourceURLs: ["/metrics"]
  verbs: ["get"]
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: prometheus
  namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: prometheus
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: prometheus
subjects:
- kind: ServiceAccount
  name: prometheus
  namespace: default