启用k8s metrics server监控

1、创建aggregator证书

方法一:直接使用二进制源码包安装

$ wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64
$ chmod +x cfssl_linux-amd64
$ mv cfssl_linux-amd64 /usr/local/bin/cfssl

$ wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
$ chmod +x cfssljson_linux-amd64
$ mv cfssljson_linux-amd64 /usr/local/bin/cfssljson

$ wget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64
$ chmod +x cfssl-certinfo_linux-amd64
$ mv cfssl-certinfo_linux-amd64 /usr/local/bin/cfssl-certinfo

$ export PATH=/usr/local/bin:$PATH

方式二:使用go命令安装

$ go get -u github.com/cloudflare/cfssl/cmd/...
$ls $GOPATH/bin/cfssl*
cfssl cfssl-bundle cfssl-certinfo cfssljson cfssl-newkey cfssl-scan

2、创建 CA (Certificate Authority)

创建 CA 配置文件

$ mkdir /root/ssl
$ cd /root/ssl
$ cfssl print-defaults config > config.json
$ cfssl print-defaults csr > csr.json
# 根据config.json文件的格式创建如下的ca-config.json文件
# 过期时间设置成了 87600h
$ cat > aggregator-ca-config.json <<EOF
{
  "signing": {
    "default": {
      "expiry": "87600h"
    },
    "profiles": {
      "aggregator": {
        "usages": [
            "signing",
            "key encipherment",
            "server auth",
            "client auth"
        ],
        "expiry": "87600h"
      }
    }
  }
}
EOF

字段说明:

  • profiles : 可以定义多个 profiles,分别指定不同的过期时间、使用场景等参数;后续在签名证书时使用某个 profile。
  • signing :表示该证书可用于签名其它证书;生成的 aggregator-ca.pem 证书中 CA=TRUE
  • server auth :表示 Client 可以用该 CA 对 Server 提供的证书进行验证。
  • client auth :表示 Server 可以用该 CA 对 Client 提供的证书进行验证。

创建 CA 证书签名请求

创建 aggregator-ca-csr.json 文件,内容如下:

{
  "CN": "aggregator",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "CN",
      "ST": "Shanghai",
      "L": "Shanghai",
      "O": "k8s",
      "OU": "System"
    }
  ],
    "ca": {
       "expiry": "87600h"
    }
}

字段说明:

  • “CN” :Common Name,kube-apiserver 从证书中提取该字段作为请求的用户名 (User Name);浏览器使用该字段验证网站是否合法。
  • “O” :Organization,kube-apiserver 从证书中提取该字段作为请求用户所属的组 (Group);

生成 CA 证书和私钥

$ cfssl gencert -initca aggregator-ca-csr.json | cfssljson -bare aggregator-ca
$ ls aggregator-ca*
aggregator-ca-config.json  aggregator-ca.csr  aggregator-ca-csr.json  aggregator-ca-key.pem

3、创建 kubernetes 证书

创建 aggregator 证书签名请求文件 aggregator-csr.json :

{
    "CN": "aggregator",
    "hosts": [
      "127.0.0.1",
      "192.168.123.250",
      "192.168.123.248",
      "192.168.123.249",
      "10.254.0.1",
      "kubernetes",
      "kubernetes.default",
      "kubernetes.default.svc",
      "kubernetes.default.svc.cluster",
      "kubernetes.default.svc.cluster.local"
    ],
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [
        {
            "C": "CN",
            "ST": "Shanghai",
            "L": "Shanghai",
            "O": "k8s",
            "OU": "System"
        }
    ]
}
  • 如果 hosts 字段不为空则需要指定授权使用该证书的 IP 或域名列表,由于该证书后续被 etcd 集群和 kubernetes master 集群使用,所以上面分别指定了 etcd 集群、kubernetes master 集群的主机 IP 和 kubernetes 服务的服务 IP(一般是 kube-apiserver 指定的 service-cluster-ip-range 网段的第一个 IP,如 10.254.0.1)。
  • 以上物理节点的 IP 也可以更换为主机名。

生成 aggregator 证书和私钥

$ cfssl gencert -ca=aggregator-ca.pem -ca-key=aggregator-ca-key.pem -config=aggregator-ca-config.json -profile=aggregator aggregator-csr.json | cfssljson -bare aggregator
$ ls aggregator*
aggregator.csr  aggregator-csr.json  aggregator-key.pem  aggregator.pem

4、分发证书

将生成的证书和秘钥文件(后缀名为.pem)拷贝到 Master 节点的 /etc/kubernetes/ssl 目录下备用。

cp *.pem /etc/kubernetes/ssl

5、开启聚合层 API

kube-apiserver 增加以下配置:

--requestheader-client-ca-file=/etc/kubernetes/ssl/aggregator-ca.pem
--requestheader-allowed-names=aggregator
--requestheader-extra-headers-prefix=X-Remote-Extra-
--requestheader-group-headers=X-Remote-Group
--requestheader-username-headers=X-Remote-User
--proxy-client-cert-file=/etc/kubernetes/ssl/aggregator.pem
--proxy-client-key-file=/etc/kubernetes/ssl/aggregator-key.pem

 注意:前面创建的证书的 CN 字段的值必须和参数 --requestheader-allowed-names 指定的值 aggregator 相同。

重启 kube-apiserver:

$ systemctl daemon-reload
$ systemctl restart kube-apiserver

  如果 kube-proxy 没有在 Master 上面运行,kube-proxy 还需要添加配置:

--enable-aggregator-routing=true

6、部署metrics server

git clone https://github.com/kubernetes-incubator/metrics-server
$ cd metrics-server
$ cat deploy/1.8+/metrics-server-deployment.yaml
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: metrics-server
namespace: kube-system
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: metrics-server
namespace: kube-system
labels:
k8s-app: metrics-server
spec:
selector:
matchLabels:
k8s-app: metrics-server
template:
metadata:
name: metrics-server
labels:
k8s-app: metrics-server
spec:
serviceAccountName: metrics-server
volumes:
# mount in tmp so we can safely use from-scratch images and/or read-only containers
- name: tmp-dir
emptyDir: {}
containers:
- name: metrics-server
image: k8s.gcr.io/metrics-server-amd64:v0.3.2
command:
- /metrics-server
- --kubelet-preferred-address-types=InternalIP
- --kubelet-insecure-tls
imagePullPolicy: IfNotPresent
volumeMounts:
- name: tmp-dir
mountPath: /tmp

$ kubectl create -f deploy/1.8+/

  注意:这里我修改了metrics-server的启动命令,增加了--kubelet-preferred-address-types=InternalIP和--kubelet-insecure-tls参数,否则metrics server可能会从kubelet拿不到监控数据。具体报错可以通过kubectl log metrics-server-5687578d67-tx8m4 -n kube-system命令查看

7、验证metrics server

[[email protected] 1.8+]# kubectl get --raw /apis/metrics.k8s.io/v1beta1/nodes
[[email protected] 1.8+]# kubectl top node
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
k8s-10-21-17-41 136m 13% 2131Mi 93%
k8s-10-21-17-42 167m 2% 8904Mi 28%
k8s-10-21-17-43 978m 13% 17733Mi 57%
k8s-10-21-17-56 707m 17% 16621Mi 51%
k8s-10-21-17-57 320m 8% 12478Mi 38%
k8s-10-21-17-58 442m 11% 13087Mi 40%
k8s-10-21-17-59 242m 8% 13838Mi 45%

[[email protected] 1.8+]# kubectl top pod
NAME CPU(cores) MEMORY(bytes)
eager-alpaca-zookeeper-0 6m 780Mi
eager-alpaca-zookeeper-1 5m 755Mi
eager-alpaca-zookeeper-2 7m 793Mi
filled-scorpion-minio-96595c48-bfwrd 1m 10Mi
filled-scorpion-redis-master-0 5m 28Mi
filled-scorpion-spinnake-halyard-0 1m 1365Mi
idolized-wallaby-nfs-client-provisioner-5dbcfc8c9-8kpwk 2m 11Mi
jaundiced-possum-gitlab-runner-64dcdccc4c-k5927 4m 7Mi
nginx-deployment-586f5f95f7-dvmw7 0m 1Mi
nginx-deployment-586f5f95f7-hpw5n 0m 2Mi
prometheus-operator-6c8d8456cd-ccfwx 2m 24Mi
prometheus-sample-metrics-prom-0 1m 30Mi
sample-metrics-app-5f67fcbc57-9ghxt 1m 9Mi
sample-metrics-app-5f67fcbc57-t9pzn 1m 9Mi

  

原文地址:https://www.cnblogs.com/edenlong/p/10773548.html

时间: 2024-10-28 19:27:44

启用k8s metrics server监控的相关文章

k8s Metrics Server 获取资源指标与 hpa 部署

使用 helm 部署 Metrics Server helm repo add bitnami https://charts.bitnami.com/bitnami helm install bitnami/metrics-server 会有报错,执行以下命令 helm upgrade loopy-saola bitnami/metrics-server --set apiService.create=true $ kubectl get pod 查看节点 loopy-saola-metrics

kubeadm1.14.1 安装Metrics Server

Metrics API 介绍Metrics-Server之前,必须要提一下Metrics API的概念 Metrics API相比于之前的监控采集方式(hepaster)是一种新的思路,官方希望核心指标的监控应该是稳定的,版本可控的,且可以直接被用户访问(例如通过使用 kubectl top 命令),或由集群中的控制器使用(如HPA),和其他的Kubernetes APIs一样. 官方废弃heapster项目,就是为了将核心资源监控作为一等公民对待,即像pod.service那样直接通过api-

Kubernetes1.15.2集群部署并部署Metrics Server插件

环境信息: 操作系统 主机名 IP地址 CentOS 7.6 k8s-master 192.168.31.61 CentOS 7.6 k8s-node1 192.168.31.62 CentOS 7.6 k8s-node2 192.168.31.63 1. 安装要求 在开始之前,部署Kubernetes集群机器需要满足以下几个条件: 操作系统 CentOS7.x-86_x64 硬件配置:2GB或更多RAM,2个CPU或更多CPU,硬盘30GB或更多 集群中所有机器之间网络互通 可以访问外网,需要

SQL Server 监控统计阻塞脚本信息

原文:SQL Server 监控统计阻塞脚本信息 数据库产生阻塞(Blocking)的本质原因 :SQL语句连续持有锁的时间过长 ,数目过多, 粒度过大.阻塞是事务隔离带来的副作用,它是不可避免的,而且是一个数据库系统常见的现象. 但是阻塞的时间和出现频率要控制在一定的范围内,阻塞持续的时间过长或阻塞出现过多(过于频繁),就会对数据库性能产生严重的影响. 很多时候,DBA需要知道数据库在出现性能问题时,有没有发生阻塞? 什么时候开始的?发生在那个数据库上? 阻塞发生在那些SQL语句之间? 阻塞的

SQL Server监控全解析

SQL Server监控全解析 在SQL Server的日常管理中,让SQL Server高效运行,且性能良好,是DBA需要做的事.DBA需要了解数据库的日常运行情况,对性能进行分析和调优,需要对线上环境部署监控.那我们都需要监控哪些方面呢? SQL Server服务器的CPU.内存.IO.网络流量.缓存等资源性能怎么样,各个相关服务如SQL Server服务.SQL Server代理服务等是否正常运行,这些一般使用开源的监控软件Zabbix来设置告警,当然针对数据库服务器的特性,添加一些SQL

0. SQL Server监控清单

原文:0. SQL Server监控清单 数据库服务器的监控可大致分为两类: (1) 状态监控:数据库服务器有没有在健康地运行? (2) 性能监控:健康运行的同时,有没有性能问题?可不可以更快些? 一. 服务器 1. 状态监控 (1) 服务器是否可访问? (2) 数据库服务是否启用? (3) 操作系统事件日志中的错误或告警 (4) 磁盘可用空间 2. 性能监控 (1) IO压力 (2) 内存使用 (3) CPU使用 (4) 网络带宽占用 这1,2,3,4是按照容易出现瓶颈的顺序排列的,由于磁盘的

如何启用Oracle EBS Form监控【Z】

前言: 有时候,因某些需要,必须知道Oracle的Form被使用的情况,以方面我们做出决策: 例如,如果某个Form被使用的次数非常多,那么,这个Form的相关SQL代码就应该优先处理,以减少服务器负荷,从而提供系统运行速度. 或者,(特别是)在系统要升级的时候,这些数据就显得非常重要了:决定哪个Form应该留,哪个Form应该拿掉. 当然,这个信息只是做出决策的参考数据而已.1. 在Oracle EBS上进行Form跟踪的技术方法:Oracle EBS的一个Profile 提供此功能: Use

高级DBA之路——《SQL Server 监控和诊断》

编写各大终端的程序员常常有"SQL语言很简单,DBA工作很轻松"的错觉,用惯了SQLite及其扩展框架OrmLite和GreenDAO的Android程序员更是如此,尤其当一个Android程序员看见自己上大学时又挂科又留级的损友从事DBA工作之后:"不好好学习也就只能用SQL增删改查了". 然而和各大终端编写SQL代码仅为了给界面做缓存不同,在服务器端的SQL Server的日常管理中,DBA需要考虑的是如何让SQL Server高效运行,且性能良好:DBA不仅需

k8s实践17:监控利器prometheus helm方式部署配置测试

监控利器prometheus helm方式部署配置测试 1.部署helm 部署helm参考方法 后面使用helm部署grafana和prometheus,因此首先需要部署helm,保证helm能正常使用. 部署helm客户端过程见下: [[email protected] helm]# curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 > get_helm.sh % Total % Receive