kubernetes资源监控

目录

一、资源限制

1、limitrange

2、ResourceQuota

二、metrics-server

三、图形化监控和代码行监控

1、dashboard

2、k9s

四、hpa


一、资源限制

  • Kubernetes采用request和limit两种限制类型来对资源进行分配。
  • request(资源需求):即运行Pod的节点必须满足运行Pod的最基本需求才能运行Pod
  • limit(资源限额):即运行Pod期间,可能内存使用量会增加,那最多能使用多少内存,这就是资源限额
  • 资源类型:
  • CPU 的单位是核心数,内存的单位是字节。
  • 一个容器申请0.5个CPU,就相当于申请1个CPU的一半,你也可以加个后缀m 表示千分之一的概念。比如说100m的CPU,100豪的CPU和0.1个CPU都是一样的。
  • 内存单位
  • K、M、G、T、P、E           #通常是以1000为换算标准的。
  • Ki、Mi、Gi、Ti、Pi、Ei        #通常是以1024为换算标准的。

 上传镜像

vim limit.yaml

apiVersion: v1
kind: Pod
metadata:
  name: memory-demo
spec:
  containers:
  - name: memory-demo
    image: stress
    args:
    - --vm
    - "1"
    - --vm-bytes
    - 200M
    resources:
      requests:
        memory: 50Mi
      limits:
        memory: 100Mi

kubectl apply -f limit.yaml
kubectl get pod

  • 如果容器超过其内存限制,则会被终止。如果可重新启动,则与所有其他类型的运行时故障一样,kubelet 将重新启动它。
  • 如果一个容器超过其内存请求,那么当节点内存不足时,它的 Pod 可能被逐出。

1、limitrange

vim range.yaml

apiVersion: v1
kind: LimitRange
metadata:
  name: limitrange-memory
spec:
  limits:
  - default:
      cpu: 0.5
      memory: 512Mi
    defaultRequest:
      cpu: 0.1
      memory: 256Mi
    max:
      cpu: 1
      memory: 1Gi
    min:
      cpu: 0.1
      memory: 100Mi
    type: Container

kubectl apply -f range.yaml

LimitRange 在 namespace 中施加的最小和最大内存限制只有在创建和更新 Pod 时才会被应用。改变 LimitRange 不会对之前创建的 Pod 造成影响。       

创建的pod自动添加限制

kubectl run demo --image nginx

 

自定义限制的pod也需要在limitrange定义的区间内

2、ResourceQuota

  • 创建的ResourceQuota对象将在default名字空间中添加以下限制
  • 每个容器必须设置内存请求(memory request),内存限额(memory limit),cpu请求(cpu request)和cpu限额(cpu limit)。
  • 所有容器的内存请求总额不得超过1 GiB。
  • 所有容器的内存限额总额不得超过2 GiB。
  • 所有容器的CPU请求总额不得超过1 CPU。
  • 所有容器的CPU限额总额不得超过2 CPU。
vim range.yaml

添加进
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: mem-cpu-demo
spec:
  hard:
    requests.cpu: "1"
    requests.memory: 1Gi
    limits.cpu: "2"
    limits.memory: 2Gi
    pods: "2"

kubectl apply -f range.yaml
kubectl describe  resourcequotas

 

  1. 配额是针对namespace施加的总限额,命名空间内的所有pod资源总和不能超过此配额
  2. 创建的pod必须定义资源限制

二、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 通过调用 Kubelet Summary API 获取数据
  • Metrics Server 并不是 kube-apiserver 的一部分,而是通过 Aggregator 这种插件机制,在独立部署的情况下同 kube-apiserver 一起统一对外服务的
  • kube-aggregator 其实就是一个根据 URL 选择具体的 API 后端的代理服务器。

  • Metrics-server属于Core metrics(核心指标),提供API metrics.k8s.io,仅提供Node和Pod的CPU和内存使用情况。而其他Custom Metrics(自定义指标)由Prometheus等组件来完成 

 官网:https://github.com/kubernetes-sigs/metrics-server

下载部署文件

wget https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

修改部署文件

上传镜像到harbor

kubectl apply -f components.yaml
kubectl -n kube-system logs metrics-server-

三、图形化监控和代码行监控

1、dashboard

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

官网:https://github.com/kubernetes/dashboard

下载部署文件
wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.7.0/aio/deploy/recommended.yaml

上传所需镜像到harbor

部署

kubectl apply -f recommended.yaml

修改svc

kubectl -n kubernetes-dashboard edit svc kubernetes-dashboard

集群需要部署metallb-system,如果没有可以使用NodePort方式

访问:

 授权  获取token

vim rbac.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: admin-user
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: kubernetes-dashboard
  namespace: kubernetes-dashboard

kubectl apply -f rbac.yaml
kubectl -n kubernetes-dashboard create token kubernetes-dashboard

 使用token登录网页

使用图像化创建

2、k9s

四、hpa

vim hpa.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: php-apache
spec:
  selector:
    matchLabels:
      run: php-apache
  replicas: 1
  template:
    metadata:
      labels:
        run: php-apache
    spec:
      containers:
      - name: php-apache
        image: hpa-example
        ports:
        - containerPort: 80
        resources:
          limits:
            cpu: 500m
          requests:
            cpu: 200m
---
apiVersion: v1
kind: Service
metadata:
  name: php-apache
  labels:
    run: php-apache
spec:
  ports:
  - port: 80
  selector:
    run: php-apache

kubectl apply -f hpa.yaml

kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10

kubectl get hpa
压测
kubectl run -i --tty load-generator --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"

 pod负载上升触发hpa扩容pod

结束压测后,默认等待5分钟冷却时间,pod会被自动回收

 多项量度指标

kubectl get hpa php-apache -o yaml > hpa-v2.yaml

修改文件,增加内存指标
  - resource:
      name: memory
      target:
        averageValue: 50Mi
        type: AverageValue
    type: Resource


kubectl apply -f hpa-v2.yaml
kubectl get hpa

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Kubernetes监控中扮演着以下角色: 1. 集群监控Kubernetes可以监控整个集群的健状态,包括节点、Pod、容器等的状态。它可以测节点故障、容器崩溃等异常情况,并采取相应的措施来保证集群的稳定运行。 2. 资源监控Kubernetes可以监控集群中各个节点和Pod的资源使用情况,包括CPU、内存、存储等。它可以提供实时的资源利用率信息,帮助运维人员了解集群的负载情况和资源瓶颈。 3. 应用程序监控Kubernetes提供了与多种监控工具集成的能力,可以监控应用程序的运行状态和性能指标。它可以与Prometheus、Grafana等工具集成,收集应用程序的指标数据,并进行可视化展示和报警通知。 4. 日志管理:Kubernetes提供了日志收集和管理的功能,可以方便地获取容器和Pod的日志信息。它可以与工具如ELK(Elasticsearch、Logstash、Kibana)等集成,帮助运维人员进行日志分析和故障排查。 5. 健康检查:Kubernetes可以定期对容器和Pod进行健康检查,以确保它们正常运行。它可以根据预设的健康检查规则,检测容器的存活状态、应用程序的可用性等,并根据检查结果进行自动修复或重新调度。 总结而言,Kubernetes监控中的角色是监控集群的健康状态、资源利用情况,收集和分析应用程序的指标和日志信息,并进行健康检查和自动修复。这些功能可以帮助运维人员及时发现和解决问题,保证集群的可靠性和稳定性。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值