Ponto de extremidade de métricas do nó do Kubernetes retorna 401

Question

Eu tenho um cluster GKE que, por uma questão de simplicidade, executa apenas o Prometheus, monitorando cada nó do membro. Recentemente, atualizei recentemente o servidor da API para 1.6 (que apresenta o RBAC) e não tive problemas. Eu adicionei um novo nó, rodando a versão 1.6 do kubelet. O Prometheus não pôde acessar a API de métricas desse novo nó.

Porisso,adicioneiClusterRole,ClusterRoleBindingeServiceAccountaomeunamespaceeconfigureiaimplantaçãoparausaranovaServiceAccount.Euentãodeleteiopodporumaboamedida:

apiVersion:v1kind:ServiceAccountmetadata:name:prometheus---apiVersion:rbac.authorization.k8s.io/v1beta1kind:ClusterRolemetadata:name:prometheusrules:-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
      ...

Mas a situação permanece inalterada.

O ponto de extremidade de métricas retorna HTTP/1.1 401 Unauthorized e, quando modifico a Implantação para incluir outro contêiner com o bash + curl instalado e faço a solicitação manualmente, recebo:

# curl -vsSk -H "Authorization: Bearer $(</var/run/secrets/kubernetes.io/serviceaccount/token)" https://$NODE_IP:10250/metrics
*   Trying $NODE_IP...
* Connected to $NODE_IP ($NODE_IP) port 10250 (#0)
* found XXX certificates in /etc/ssl/certs/ca-certificates.crt
* found XXX certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
*    server certificate verification SKIPPED
*    server certificate status verification SKIPPED
*    common name: node-running-kubelet-1-6@000000000 (does not match '$NODE_IP')
*    server certificate expiration date OK
*    server certificate activation date OK
*    certificate public key: RSA
*    certificate version: #3
*    subject: CN=node-running-kubelet-1-6@000000000
*    start date: Fri, 07 Apr 2017 22:00:00 GMT
*    expire date: Sat, 07 Apr 2018 22:00:00 GMT
*    issuer: CN=node-running-kubelet-1-6@000000000
*    compression: NULL
* ALPN, server accepted to use http/1.1
> GET /metrics HTTP/1.1
> Host: $NODE_IP:10250
> User-Agent: curl/7.47.0
> Accept: */*
> Authorization: Bearer **censored**
>
< HTTP/1.1 401 Unauthorized
< Date: Mon, 10 Apr 2017 20:04:20 GMT
< Content-Length: 12
< Content-Type: text/plain; charset=utf-8
<
* Connection #0 to host $NODE_IP left intact

• Por que esse token não permite que eu acesse esse recurso?
• Como se verifica o acesso concedido a uma conta de serviço?

Answer 1

Como por discussão no ingresso @ JorritSalverda; link

Como o GKE não permite que você obtenha certificados de cliente que permitem que você se autentique com o kubelet, a melhor solução para os usuários no GKE parece usar o servidor da API do kubernetes como um proxy para os nós.

Para fazer isso (citando @JorritSalverda);

"Para o meu servidor Prometheus em execução dentro do GKE, agora ele está sendo executado com a seguinte reclassificação:

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

E o seguinte ClusterRole vinculado à conta de serviço usada pelo 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"]

Como o cluster GKE ainda tem um fallback do ABAC no caso de o RBAC falhar, ainda não tenho 100% de certeza de que isso abrange todas as permissões necessárias.

    

Answer 2

Eu me deparei com o mesmo problema e criei um link para este e fora de sua discussão atualizou os exemplos de configuração via PR link .

Você pode ver a reclassificação atualizada para a tarefa kubernetes-nodes em link

Copiado para referência:

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

Para o próprio RBAC, você precisa executar o Prometheus com sua própria conta de serviço que você cria com

apiVersion: v1
kind: ServiceAccount
metadata:
  name: prometheus
  namespace: default

Certifique-se de passar essa conta de serviço para o pod com a seguinte especificação de conjunto:

spec:
  serviceAccount: prometheus

E, em seguida, o Kubernetes se manifesta para configurar a função e vinculação RBAC apropriadas para fornecer acesso à conta do serviço prometheus aos endpoints da API necessários em link

copiado para referência

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: prometheus
rules:
- apiGroups: [""]
  resources:
  - nodes
  - nodes/proxy
  - 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

Substitua o namespace em todos os manifestos para corresponder àquele em que você executa o Prometheus e, em seguida, aplique o manifesto com uma conta com direitos de Administrador de Cluster.

Eu não testei isso em um cluster sem o fallback do ABAC, então a função RBAC ainda pode estar faltando algo essencial.