Linux企业运维——Kubernetes(十六)容器资源监控

Posted 是大姚呀

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Linux企业运维——Kubernetes(十六)容器资源监控相关的知识,希望对你有一定的参考价值。

Linux企业运维——Kubernetes(十六)容器资源监控

1、Metrics-Server

1.1、Metrics-Server简介

Metrics-Server是集群核心监控数据的聚合器,用来替换之前的heapster。

容器相关的Metrics 主要来自于 kubelet 内置的 cAdvisor 服务,有了Metrics-Server之后,用户就可以通过标准的Kubernetes API 来访问到这些监控数据。

  • Metrics API 只可以查询当前的度量数据,并不保存历史数据。
  • Metrics API URI 为 /apis/metrics.k8s.io/,在 k8s.io/metrics 维护。
  • 必须部署metrics-server 才能使用该 API,metrics-server 通过调用 KubeletSummary API
    获取数据。

  • Metrics Server 并不是 kube-apiserver 的一部分,而是通过Aggregator
    这种插件机制,在独立部署的情况下同 kube-apiserver 一起统一对外服务的。
  • kube-aggregator 其实就是一个根据 URL 选择具体的 API 后端的代理服务器。

1.2、Metrics-Server部署

Metrics-Server部署:修改端口、分发证书、设置节点解析

真实主机将metrics-server.tar发送给server1

server1加载镜像,并将metrics-server上传至仓库

真实主机将components.yaml发送给server2

server2创建metrics-server目录并在该目录下编辑components.yaml

修改镜像路径

将安全端口和容器端口修改为4443

应用配置

查看kube-system命名空间的pod信息,可以看到metrics-server处于运行状态但并未就绪

server2、3、4都对/var/lib/kubelet//config.yaml配置文件进行编辑,将serverTLSBootstrap参数修改为true,启动证书授权,保存退出

server2、3、4重启kubelet服务



查看所有证书签名请求,三个证书签名请求都处于Pending状态,对三个请求进行授权后,再查看发现状态变为已接受,已发布

如果出现no such host错误提示,这是因为没有内网的DNS服务器,所以metrics-server无法解析节点名字。可以通过kubectl edit configmap coredns -n kube-system命令修改coredns的configmap,讲各个节点的主机名加入到hosts中,这样所有Pod都可以从CoreDNS中解析各个节点的名字。


修改完成后metrics-server正常运行

查看详细信息可以看到后端地址和端口

通过kubectl top node可以监控到所有节点的资源使用情况

2、Dashboard

Dashboard可以给用户提供一个可视化的 Web 界面来查看当前集群的各种信息。用户可以用 Kubernetes Dashboard 部署容器化的应用、监控应用的状态、执行故障排查任务以及管理 Kubernetes 各种资源。

2.1、Dashboard部署

server2清理前面实验的所有容器和配置

新建kubernetesui项目来管理镜像

真实主机将dashboard.tar发送给server1

server1加载镜像并将镜像上传至刚创建的kubernetesui仓库

server2创建dashboard目录,下载recommended.yaml配置文件

编辑recommended.yaml配置文件,修改镜像路径


应用配置,可以看到创建了新的命名空间和服务等

新创建的命名空间是kubernetes-dashboard

查看kubernetes-dashboard命名空间下的容器和服务是否正常运行
psp安全策略一定要禁掉,否则两个控制器起不来

使用kubectl -n kubernetes-dashboard edit svc kubernetes-dashboard命令修改服务配置,修改ClusterIP为LoadBalancer使外部可以访问


修改完成后查看其外部访问地址为172.25.19.11,查看metallb-system命名空间,4个pod正在运行

真实主机用浏览器访问dashboard服务地址,需要token认证

在server2中查看kubernetes-dashboard命名空间的secrets,查看token

查看详细信息,将token复制下来

在浏览器访问时将token粘贴进去

认证成功后进入界面,不过有红色报错信息,因为默认dashboard对集群没有操作权限,需要授权

通过查看dashboard的clusterrole详细信息可以看到只有读权限

修改rbac.yaml配置文件,在全局角色绑定中将cluster-admin的权限赋予kubernetes-dashboard,使其具有读写权限

应用配置

现在重新测试访问,可以看到正常运行

2.2、Dashboard可视化控制

(这里如果命名空间有资源配额、限制等设定,通过dashboard创建容器可能拉不起来)

在default命名空间下添加新的资源

按照要求填入参数来创建pod,测试功能是否正常

可以看到我们创建的pod正常运行并且被监控

进入server2命令行也可以查看到刚创建的pod,查看其ip并测试访问

在Deployments菜单中,可以进行编辑

将镜像的v1版本升级成v2,点击更新

server2通过命令行再次测试访问,可以看到版本成功修改成了v2

在Deployments菜单中还可以进行资源缩放

将副本数由1更改为3

查看pod信息,可以看到现在有3个pod正在运行

以上是关于Linux企业运维——Kubernetes(十六)容器资源监控的主要内容,如果未能解决你的问题,请参考以下文章

Linux企业运维——Kubernetes(十三)访问控制

Linux企业运维——Kubernetes(二十)Prometheus监控

Linux企业运维——Kubernetes(二十)Prometheus监控

Linux企业运维——Kubernetes(十四)PSP安全策略

Linux企业运维——Kubernetes控制器

Linux企业运维——Kubernetes(十五)容器资源限制