k8s入坑之路(13)kubernetes重要资源(namespace隔离 resources资源管理 label)
Namespace --- 集群的共享与隔离
语言中namespace概念
namespace核心作用隔离
以上是隔离的代码。namespace隔离的是:
- 1.资源对象的隔离:Service、Deployment、Pod
- 2.资源配额的隔离:Cpu、Memory
创建命名空间
- kubectl create namespace dev
- apiVersion: v1
- kind: Namespace
- metadata:
- name: dev
kubectl create -f namespace.yaml
kubectl get all -n dev
yaml文件中指定namespace


- apiVersion: apps/v1
- kind: Deployment
- metadata:
- name: web-demo-new
- namespace: dev
- spec:
- selector:
- matchLabels:
- app: web-demo
- replicas: 1
- template:
- metadata:
- labels:
- app: web-demo
- spec:
- containers:
- - name: web-demo
- image: 172.17.166.217/kubenetes/k8s-web-demo:2021070520
- ports:
- - containerPort: 8080
- ---
- #service
- apiVersion: v1
- kind: Service
- metadata:
- name: web-demo
- namespace: dev
- spec:
- ports:
- - port: 80
- protocol: TCP
- targetPort: 8080
- selector:
- app: web-demo
- type: ClusterIP
- ---
- #ingress
- apiVersion: networking.k8s.io/v1
- kind: Ingress
- metadata:
- name: web-demo
- namespace: dev
- spec:
- rules:
- - host: www.csweb.com
- http:
- paths:
- - pathType: Prefix
- path: /
- backend:
- service:
- name: web-demo
- port:
- number: 80
web.yaml
####在metadata中指定namespace
不同命名空间下的service-ip是可以互相访问的,与命名空间无关。
不同命名空间下的pod名称与dns是访问不到的。pod-ip是不隔离的。
切换默认namespace
- kubectl config set-context ctx-dev \
- --cluster=kubernetes \
- --user=admin \
- --namespace=dev \
- --kubeconfig=/root/.kube/config
- 设置上下文 区分权限的话重新创建user并赋予对应权限
- kubectl config set-context ctx-dev --kubeconfig=/root/.kube/config
- 设置当前默认上下文
划分Namespace方式
- 1.按照环境划分:dev、test
- 2.按照团队来划分
- 3.自定义多级划分 #安装-划线名称作用等划分
Resources---多维度集群资源管理
限制namespace下资源
- 1.内存
- 2.cpu
- 3.gpu
- 4.持久化存储
kubelet会收集node硬件信息等上报给apiserver。
Resources核心设计
- 1.Requests(请求)
- 2.Limits(限制)
requests是希望容器被容器分配到的资源,可以完全保证的资源。scheduler会使用这个值来计算,从而得到最优节点。scheduler调度是不考虑limits的。
limits是容器使用的资源上限,当整个节点资源不足时,发生竞争会参考这个值从而做出进一步的决策。把某些pod驱逐。
deployment中对于pod限制


- apiVersion: apps/v1
- kind: Deployment
- metadata:
- name: web-demo
- namespace: dev
- spec:
- selector:
- matchLabels:
- app: web-demo
- replicas: 4
- template:
- metadata:
- labels:
- app: web-demo
- spec:
- containers:
- - name: web-demo
- image: 172.17.166.217/kubenetes/web:v1
- ports:
- - containerPort: 8080
- resources:
- requests:
- memory: 500Mi
- cpu: 100m
- limits:
- memory: 1000Mi
- cpu: 200m
resources-pod.yaml
#内存单位为Mi/Gi cpu为m/个数 1核心cpu=1000m
查看node节点中资源使用情况
- kubectl describe nodes node-3-172.17.166.219
对应传输给docker的值,查看容器详细信息
- docker inspect 容器id
CpuShares=requests中cpu的值 会先把requests中定义的cpu值转化为核数,然后乘以1024。等于其cpu权重。
Memory=requests中memory的值 会将memory定义的值*1024*1024转化为内存字节。
CpuQuota=limits中cpu的值,单位是minico需要*10万。CpuPeriod是docker中默认值10万纳秒,100毫秒。一起使用表示在100毫秒中最多分配的cpu量。
测试内存资源限制,进入容器编写脚本
- #!/bin/bash
- str="[sdfsofajpfjpfsajfs]"
- while true;
- do
- str="$str$str"
- echo "+++++"
- sleep 0.1
- done
###当资源耗尽(cpu/memory),会将容器中资源占用最多的进程杀掉。并不会杀掉容器。
测试cpu限制
查看cpu使用情况
- crictl stats d5c1df6d1561e
kubectl top命令需要第三方api metrics-server支持,可参考https://blog.csdn.net/wangmiaoyan/article/details/102868728
进入容器模拟cpu占用
- dd if=/dev/zero of=/dev/null &执行多次就会占用光cpu
###cpu占满后与内存不同的是进程不会杀掉,cpu是可压缩资源,内存不是。
设置pod container默认限制


- apiVersion: v1
- kind: LimitRange #范围的限制
- metadata:
- name: test-limits #策略名称
- spec:
- limits:
- - max:
- cpu: 4000m #最大cpu
- memory: 2Gi #最大内存
- min:
- cpu: 100m #最小cpu
- memory: 100Mi #最小内存
- maxLimitRequestRatio:
- cpu: 3 #cpu中limits最大比requests的倍数
- memory: 2 #memory中limits最大比requests的倍数
- type: Pod #类型pod
- - default:
- cpu: 300m #默认cpu
- memory: 200Mi #默认memory
- defaultRequest:
- cpu: 200m #默认requestcpu
- memory: 100Mi #默认request memory
- max:
- cpu: 2000m #最大值
- memory: 1Gi
- min:
- cpu: 100m #最小值
- memory: 100Mi
- maxLimitRequestRatio:
- cpu: 5 #limit最多比request比例的倍数
- memory: 4
- type: Container #类型container
pod-container.yaml
查看命名空间下资源限制
- kubectl describe limitranges --all-namespaces
namespace资源限制
资源限制
- apiVersion: v1
- kind: ResourceQuota #资源配额
- metadata:
- name: resource-quota
- namespace: wanger
- spec:
- hard:
- pods: 4 #最多允许pod个数
- requests.cpu: 2000m
- requests.memory: 4Gi
- limits.cpu: 4000m
- limits.memory: 8Gi
- apiVersion: v1
- kind: ResourceQuota
- metadata:
- name: object-counts
- spec:
- hard:
- configmaps: 10 #最多允许configmap
- persistentvolumeclaims: 4 #最多允许pvc
- replicationcontrollers: 20 #最多允许有replicat
- secrets: 10 #最多允许secret
- services: 10 #最多允许service
查看quota设置
- kubectl get quota -n test
- kubectl describe -n wanger quota
pod驱逐策略-Eviction
pod容器资源策略优先级
- requests == limits时优先级最高(绝对可靠)
- 不设置 (最为不可靠)
- limits > requests 优先级次之(相对可靠)
kubelet启动常用驱逐策略配置:
###当node内存小于1.5G持续1m30秒进行pod驱逐,如果node内存小于100M磁盘小于1G剩余inodes节点小于百分之五立刻进行驱逐。
kubelet配置驱逐策略:
- kubelet --eviction-hard=imagefs.available<10%,memory.available<500Mi,nodefs.available<5%,nodefs.inodesFree<5% --eviction-soft=imagefs.available<30%,nodefs.available<10% --eviction-soft-grace-period=imagefs.available=2m,nodefs.available=2m --eviction-max-pod-grace-period=600
#或者启动文件中配置
磁盘紧缺驱逐优先级
- 删除死掉的pod、容器
- 删除没用的镜像
- 按资源优先级、资源占用情况进行驱逐 ###如同一优先级下先驱逐占用资源多的
内存驱逐策略
- 驱逐不可靠的pod #按照资源占用情况驱逐
- 驱逐基本可靠的pod #limit大于request的pod limit比request占用值越大越先驱逐
- 驱逐可靠pod #按照资源占用
label小标签大作用
label本质是key=value键值对,可以贴到任意资源中。
deployment通过标签选择pod
- apiVersion: apps/v1
- kind: Deployment
- metadata:
- name: web-demo
- namespace: dev
- spec:
- selector:
- matchLabels:
- app: web-demo #选择pod label app=web-demo
- replicas: 1
- template:
- metadata:
- labels:
- app: web-demo #定义pod label app=web-demo
- spec:
- containers:
- - name: web-demo
- image: hub.mooc.com/kubernetes/web:v1
- ports:
- - containerPort: 8080
- ---
- #service
- apiVersion: v1
- kind: Service
- metadata:
- name: web-demo
- namespace: dev
- spec:
- ports:
- - port: 80
- protocol: TCP
- targetPort: 8080
- selector:
- app: web-demo #service 选择pod label app=web-demo
- type: ClusterIP
###1.6版本之前在pod之上还有rc概念,即replicas副本控制器。deployment将rc封装,deployment本质是操作副本控制器。selector与pod名称需一致,rc去调用pod。deployment label是可变的,多个同样名称的rc和pod是不冲突的,属于不同的deployment
pod通过group标签rc选中group
- apiVersion: apps/v1
- kind: Deployment
- metadata:
- name: web-demo
- namespace: dev
- spec:
- selector:
- matchLabels:
- app: web-demo
- matchExpressions:
- - {key: group, operator: In, values: [dev, test]}#定义选择组
- replicas: 1
- template:
- metadata:
- labels:
- group: dev #pod打上组标签
- app: web-demo
- spec:
- containers:
- - name: web-demo
- image: hub.mooc.com/kubernetes/web:v1
- ports:
- - containerPort: 8080
###校验pod是否是deployment需要的。
查看是否创建成功
- kubectl get pods -l app=web-demo -n dev
- kubectl get pods -l group=dev -n dev
- kubectl get pods -l app=web-demo group=dev -n dev
- kubectl get pods -l 'group in (dev, test)' -n dev
kubectl get pods -l 'group notin (dev, test) -n dev'
container通过标签选择node


- apiVersion: apps/v1
- kind: Deployment
- metadata:
- name: web-demo
- namespace: dev
- spec:
- selector:
- matchLabels:
- app: web-demo
- matchExpressions:
- - {key: group, operator: In, values: [dev, test]}
- replicas: 1
- template:
- metadata:
- labels:
- group: dev
- app: web-demo
- spec:
- containers:
- - name: web-demo
- image: hub.mooc.com/kubernetes/web:v1
- ports:
- - containerPort: 8080
- nodeSelector:
- disktype: ssd
selector-node.yaml
给node打上标签
- kubectl label node node-3-172.17.166.219 disktype=ssd
- kubectl get nodes node-3-172.17.166.219 --show-labels
k8s入坑之路(13)kubernetes重要资源(namespace隔离 resources资源管理 label)的更多相关文章
- k8s入坑之路(7)kubernetes设计精髓List/Watch机制和Informer模块详解
1.list-watch是什么 List-watch 是 K8S 统一的异步消息处理机制,保证了消息的实时性,可靠性,顺序性,性能等等,为声明式风格的API 奠定了良好的基础,它是优雅的通信方式,是 ...
- k8s入坑之路(16)kubernetes中CICD/基于宿主机jenkins
cicd的结合组件 需要代码仓库如gitlab.github.包构建工具Maven等,持续集成工具如jenkins,github/cicd.结合自己脚本实现重复式任务自动化. 传统服务发布流程: 提交 ...
- k8s入坑之路(14)scheduler调度 kubelet管理及健康检查 更新策略
kubelet 主要功能 Pod 管理 在 kubernetes 的设计中,最基本的管理单位是 pod,而不是 container.pod 是 kubernetes 在容器上的一层封装,由一组运行在同 ...
- k8s入坑之路(15)kubernetes共享存储与StatefulSet有状态
共享存储 docker默认是无状态,当有状态服务时需要用到共享存储 为什么需要共享存储: 1.最常见有状态服务,本地存储有些程序会把文件保存在服务器目录中,如果容器重新启停则会丢失. 2.如果使用vo ...
- k8s入坑之路(13)服务迁移(定时任务 微服务 传统服务)
定时任务迁移kubernetes 服务迁移步骤 1.安装好java 2.安装好maven 项目打包 mvn package 测试传参运行 java -cp cronjob-demo-1.0-SNAPS ...
- k8s入坑之路(10)kubernetes coredns详解
概述 作为服务发现机制的基本功能,在集群内需要能够通过服务名对服务进行访问,那么就需要一个集群范围内的DNS服务来完成从服务名到ClusterIP的解析. DNS服务在kubernetes中经历了三个 ...
- k8s入坑之路(2)kubernetes架构详解
每个微服务通过 Docker 进行发布,随着业务的发展,系统中遍布着各种各样的容器.于是,容器的资源调度,部署运行,扩容缩容就是我们要面临的问题. 基于 Kubernetes 作为容器集群的管理平 ...
- k8s入坑之路(11)kubernetes服务发现
kubernetes访问场景 1.集群内部访问 2.集群内部访问外部 3.集群外部访问内部 1.集群内部访问 1.pod之间直接ip通讯(利用calico通过路由表经过三层将ip流量转发)由于容器之间 ...
- 【转载】k8s入坑之路(2)kubernetes架构详解
每个微服务通过 Docker 进行发布,随着业务的发展,系统中遍布着各种各样的容器.于是,容器的资源调度,部署运行,扩容缩容就是我们要面临的问题. 基于 Kubernetes 作为容器集群的管理平台被 ...
随机推荐
- Spring Cloud Gateway 雪崩了,我 TM 人傻了
本系列是 我TM人傻了 系列第六期[捂脸],往期精彩回顾: 升级到Spring 5.3.x之后,GC次数急剧增加,我TM人傻了 这个大表走索引字段查询的 SQL 怎么就成全扫描了,我TM人傻了 获取异 ...
- Redis之品鉴之旅(六)
持久化 快照的方式(RDB) 文件追加方式(AOF) 快照形式: save和bgsave能快速的备份数据.但是.........., Save命令:将内存数据镜像保存为rdb文件,由于redis是单线 ...
- MyBatis 批量插入数据的 3 种方法!
批量插入功能是我们日常工作中比较常见的业务功能之一,之前我也写过一篇关于<MyBatis Plus 批量数据插入功能,yyds!>的文章,但评论区的反馈不是很好,主要有两个问题:第一,对 ...
- C#开发BIMFACE系列41 服务端API之模型对比
BIMFACE二次开发系列目录 [已更新最新开发文章,点击查看详细] 在建筑施工图审查系统中,设计单位提交设计完成的模型/图纸,审查专家审查模型/图纸.审查过程中如果发现不符合规范的地方,则流 ...
- redis两种持久化策略/存储模式
redis的持久化策略 RDB,即 Redis DataBase,以快照形式将数据写入一个临时文件,持久化结束后,用这个临时文件替换上次持久化的dump文件,达到数据恢复. 默认开启,见redis ...
- 某个buuctf的题(easy_tornado)
题目:http://88099f53-12b6-470a-9993-b73e4155940e.node3.buuoj.cn/ 1首先看三个文件的内容 2简单分析 如果出题人没整一些花里胡哨的,那么fl ...
- CF468C Hack it! 超详细解答
CF468C Hack it! 超详细解答 构造+数学推导 原文极简体验 CF468C Hack it! 题目简化: 令\(f(x)\)表示\(x\)在十进制下各位数字之和 给定一整数\(a\)构造\ ...
- MeteoInfo-Java解析与绘图教程(五)
MeteoInfo-Java解析与绘图教程(五) 最近太忙了,终于有时间继续写了,上文说到了基本上的绘图方法,但缺少色阶呈现,一般图叠加着地图上,后端不需要管色阶,但也要注意web页面色阶和我们的生成 ...
- java的加载与执行原理剖析
到目前为止,我们接触过的重点术语,总结一下: Java体系的技术被划分为三大块: JavaSE:标准版 JavaEE:企业版 JavaME:微型版 安装JDK之后: JDK:java开发工具箱 JRE ...
- csp-j 复赛感想
作者:博客园小蔡编程 这次是作者第一次参加csp-j的比赛 内心还是挺激动的 今天,作者就来和大家讨论一下这次csp-j的学习心得和感想 T1 分糖果 这题描述看似复杂 其实就是一道求最大取模的题 L ...