1.kubernetes容器资源限制

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为换算标准的。

1.1.内存 CPU限制

在本博客有体现
2.4 内存与限制

1.2namespace设置资源限制

vi limitrang.yaml

apiVersion: v1
kind: LimitRange
metadata:
  name: limitrange-demo
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

执行清单limitrange.yaml,查看信息：

kubectl apply -f limitrange.yaml kubectl apply -f limitrange.yaml 
kubectl describe limitranges limitrange
kubectl apply -f limitrange.yaml 
kubectl describe limitranges limitrange
kubectl apply -f limitrange.yaml 
kubectl describe limitranges limitrange
kubectl describe limitranges limitrange

在这里插入图片描述

vi deploy..yaml 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-nginx
spec:
  replicas: 6
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx

执行清单,并查看deploy的信息：
可以看到会使用limitrange.yaml的内存和cpu限制
kubectl describe pod deployment-nginx-6799fc88d8-
在这里插入图片描述
添加内存限制

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-nginx
spec:
  replicas: 6
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        resources:
          requests:
            cpu: 0.1
            memory: 50Mi
          limits:
            memory: 300Mi

再次执行deploy.yaml 清单。会发现报错了：
因为namespace的限制最小为100M，而内存限制最小为50M，所以冲突了！

kubectl delete -f deploy.yaml
kubectl apply -f deploy.yaml
kubectl describe rs deployment-nginx-5f9bd8b44c

在这里插入图片描述

1.3namespace设置资源配额

再次将namespace设置资源配额

vi quota.yaml

apiVersion: v1 
kind: ResourceQuota 
metadata:  
  name: mem-cpu-demo 
spec:  
  hard:    
    requests.cpu: "1"    ##所有容器的cpu请求总额不能超过1核
    requests.memory: 1Gi    ##所有容器的内存请求总额不能超过1GIB
    limits.cpu: "2"    	##所有容器的cpu限额总额不能超过2核
    limits.memory: 2Gi##所有容器的内存限额总额不能超过2GIB

执行配额清单quota.yaml
并将其中的资源限制清除

kubectl apply -f quota.yaml
kubectl delete -f  deploy.yaml 
kubectl describe resourcequotas mem-cpu-demo

在这里插入图片描述
将内存限制注释

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
       # resources:
       #   requests:
       #     cpu: 0.1
       #     memory: 50Mi
       #   limits:
       #     memory: 300Mi

执行查看
kubectl describe resourcequotas
在这里插入图片描述
若将replicas改成6则并删除在重新执行时会报错

kubectl describe rs deployment-nginx-6799fc88d8

在这里插入图片描述

1.4 Namespace 配置Pod配额

vi quota.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: mem-cpu-demo
spec:
  hard:
    requests.cpu: "1"
    requests.memory: 1Gi
    limits.cpu: "2"
    limits.memory: 2Gi
---
apiVersion: v1
kind: ResourceQuota 
metadata:  
  name: pod-demo 
spec:  
  hard:    
    pods: "3"     #最多3个

执行清单quota.yaml，查看配额信息，可以看到配置Pod配额出现：

kubectl describe resourcequotas

在这里插入图片描述

将deploy的replicas改成4后重新执行后查看rs也会有报错

kubectl describe rs deployment-nginx-6799fc88d8

在这里插入图片描述

2. kubernetes资源监控

2.1.Metrics-Server介绍

Metrics-Server是集群核心监控数据(cpu、内存)的聚合器，用来替换之前的heapster。

容器相关的 Metrics 主要来自于 kubelet 内置的 cAdvisor 服务，有了MetricsServer之后，用户就可以通过标准的 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等组件来完成。

2.2Metrics-Server安装部署

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

在server5上：
接下来将需要的镜像拉取下来上传到私有仓库中：
在这里插入图片描述

接下来将刚才wget下来的components.yaml文件编辑：
修改镜像名：

vim components.yaml

 image: metrics-server/metrics-server:v0.5.1

执行文件components.yaml，查看节点信息：

kubectl apply -f components.yaml 
kubectl get pod -n kube-system

发现没有就绪
在这里插入图片描述

2.3.解决报错

2.3.1 错误一

查看日志的报错，解决问题：

kubectl -n kube-system logs  metrics-server-758d676578-b8xxm

在这里插入图片描述

需要再次修改清单配置：
将两处的端口改为4443

vi components.yaml

--secure-port=4443
- containerPort: 4443

在这里插入图片描述执行后重新查看日志
在这里插入图片描述

2.3.2 错误二

解决报错：
报错：x509: certificate signed by unknown authority

启用TLS Bootstrap 证书签发(在master和各个节点中)

在server123都需要修改
添加参数：

vi /var/lib/kubelet/config.yaml

serverTLSBootstrap: true

添加之后，重启服务
systemctl restart kubelet

kubectl get csr
kubectl certificate approve csr-7rhv9
kubectl certificate approve csr-qczmb
kubectl certificate approve csr-ld2xk

kubectl get csr
在这里插入图片描述

2.3.3 错误三

报错：dial tcp: lookup server2 on 10.96.0.10:53: no such host
这是因为没有内网的DNS服务器，所以metrics-server无法解析节点名字。可以直接修改 coredns的configmap，将各个节点的主机名加入到hosts中，这样所有Pod都可以从 CoreDNS中解析各个节点的名字。

kubectl -n kube-system edit cm coredns

apiVersion: v1
data:
  Corefile: |
    .:53 {
        errors
        health {
           lameduck 5s
        }
        ready
        hosts {
           172.25.76.1 server1
           172.25.76.2 server2
           172.25.76.3 server3
           fallthrough
        }

再次查看pod节点信息，发现恢复运行了！

kubectl -n kube-system get pod   ##查看是否running
kubectl -n kube-system describe svc metrics-server

在这里插入图片描述
发现endpoints后端IP地址出现

2.4.测试

测试：
#查看pod分配情况

kubectl top node ##查看pod分配情况
在这里插入图片描述

或者用 kubectl -n kube-system top pod
在这里插入图片描述

3.Dashboard部署(可视化)

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

首先拉取需要的 拉取镜像

docker pull kubernetesui/dashboard:v2.4.0
docker tag kubernetesui/dashboard:v2.2.0 reg.westos.org/library/kubernetesui/dashboard:v2.4.0
docker push reg.westos.org/library/kubernetesui/dashboard:v2.4.0

创建目录dashboard用来存放关于它的文件：
下载所需要的配置文件：recommended.yaml

cd 
mkdir dashboard
cd dashboard/
wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.4.0/aio/deploy/recommended.yaml

下载之后，需要将文件中的镜像地址和版本写对.

vi recommended.yaml

image: kubernetesui/dashboard:v2.4.0
image: kubernetesui/metrics-scraper:v1.0.7

执行文件

kubectl apply -f recommended.yaml 
kubectl get ns

此时查看节点，发现没有IP地址

kubectl -n kubernetes-dashboard get svc

在这里插入图片描述

更改svc kubernetes-dashboard的网络类型为loadbalancer

kubectl -n kubernetes-dashboard edit svc kubernetes-dashboard

type: LoadBalancer

再次查看svc ，可以看到分配的vip

 kubectl -n kubernetes-dashboard get svc

在这里插入图片描述

访问刚才查看的svc出现的外部IP地址：

https://172.25.76.12

点击允许访问，之后登陆会需要token
我们可以查看刚才生成的tocken

在这里插入图片描述

 kubectl -n kubernetes-dashboard get secrets 
  kubectl -n kubernetes-dashboard describe secrets kubernetes-dashboard-token-***

复制它 粘贴进去

还需授权

vi rbac.yaml 

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

执行rbac.yaml 清单：

kubectl apply -f rbac.yaml

再次访问网页 进入成功
在这里插入图片描述

4.集群管理工具 K9S

通常情况下，我们自行部署 k8s 集群之后，要么使用 kubectl 命令做集群管理，要么使用 bashbroad 的 UI 管理界面来管理集群。最近，发现了一个基于终端且比较好用的项目，可以让我们快速查看、导航、观察并解决日常我们使用 Kubernetes 中的一些问题，这就是 k9s 项目.
工具介绍

日常使用终端的你，可谓是一件利器！

k9s 是一个基于 curses 的全屏终端 UI 管理工具，可以与 Kubernetes 集群进行交互，可以观察系统资源，在各种资源之间切换，检查清单、日志、监控事件并执行 Pod 等，从而确保桌面空间不至于被大量终端窗格所占据。

k9s 会以特定时间间隔监控 Kubernetes 资源，默认为 2 秒，并允许查看自己集群中的内容。它可以一目了然地提供了运行中 Pod、日志和部署的可视化视图，以及对 Shell 的快速访问。以下是该工具的主要特性：

信息触手可及

    跟踪 Kubernetes 集群中运行的资源的实时活动

    处理 Kubernetes 标准资源和自定义资源定义

集群指标

    跟踪与 Pod，容器和节点等资源关联的实时指标

高级特性

    提供标准的集群管理命令，例如日志，扩展，端口转发，重启

    定义自己的命令快捷方式，以通过命令别名和热键快速导航

    支持插件扩展 k9s 来创建属于自己的集群操作管理命令

    强大的过滤模式，允许用户向下钻取并查看与工作负载相关的资源

外观可定制

    通过 K9s 皮肤定义自己的外观

    自定义/安排要按资源显示的列

4.1安装

docker pull  derailed/k9s:latest
docker tag derailed/k9s:latest reg.westos.org/library/k9s:latest
docker push reg.westos.org/library/k9s:latest

Docker

# 指定k8s的配置文件路径
$ docker run --rm -it -v $KUBECONFIG:/root/.kube/config derailed/k9s
 
# k8s配置文件的默认路径
$ docker run --rm -it -v ~/.kube/config:/root/.kube/config derailed/k9s

docker save -o **** 可以将docker上的镜像搞到本地

# 容器 # 运维
Logo
K8S/Kubernetes

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐

【深度】阿里巴巴万级规模 K8s 集群全局高可用体系之美

作者 |  韩堂、柘远、沉醉来源 | 阿里巴巴云原生公众号​前言台湾作家林清玄在接受记者采访的时候，如此评价自己 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的美丽相得益彰；进入第三个十年，繁华落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。​长夜有穷，真水无香。领略过了 K8s“身在江

avatar K8S/Kubernetes

如何基于 K8s 构建下一代 DevOps 平台？

作者 | 孙健波（天元）导读：当前云原生 DevOps 体系现状如何？面临哪些挑战？如何通过 OAM 解决云原生 DevOps 场景下的诸多问题？云原生开发应用模型 OAM(Open Application Model) 社区核心成员孙健波将为大家一一解答，并分享如何基于 OAM 和 Kubernetes 打造无限能力的下一代 DevOps 平台。什么是 DevOps？为什么基于 Kub

avatar K8S/Kubernetes

k8s 火了！

2020，上云之年，产品云端化成为一种趋势。在一线城市，很多公司都已经构建了自己的私有云环境，比如阿里云、网易云、华为云等。而Kubernetes 作为基于容器编排领域的王者，具备扩展...

avatar K8S/Kubernetes