Namespace --- 集群的共享与隔离

语言中namespace概念

  • namespace核心作用隔离

  以上是隔离的代码。namespace隔离的是:

  • 1.资源对象的隔离:Service、Deployment、Pod
  • 2.资源配额的隔离:Cpu、Memory

创建命名空间

  1. kubectl create namespace dev
  2.  
  3. apiVersion: v1
  4. kind: Namespace
  5. metadata:
  6. name: dev

    kubectl create -f namespace.yaml

    kubectl get all -n dev

yaml文件中指定namespace

  1. apiVersion: apps/v1
  2. kind: Deployment
  3. metadata:
  4. name: web-demo-new
  5. namespace: dev
  6. spec:
  7. selector:
  8. matchLabels:
  9. app: web-demo
  10. replicas: 1
  11. template:
  12. metadata:
  13. labels:
  14. app: web-demo
  15. spec:
  16. containers:
  17. - name: web-demo
  18. image: 172.17.166.217/kubenetes/k8s-web-demo:2021070520
  19. ports:
  20. - containerPort: 8080
  21. ---
  22. #service
  23. apiVersion: v1
  24. kind: Service
  25. metadata:
  26. name: web-demo
  27. namespace: dev
  28. spec:
  29. ports:
  30. - port: 80
  31. protocol: TCP
  32. targetPort: 8080
  33. selector:
  34. app: web-demo
  35. type: ClusterIP
  36.  
  37. ---
  38. #ingress
  39. apiVersion: networking.k8s.io/v1
  40. kind: Ingress
  41. metadata:
  42. name: web-demo
  43. namespace: dev
  44. spec:
  45. rules:
  46. - host: www.csweb.com
  47. http:
  48. paths:
  49. - pathType: Prefix
  50. path: /
  51. backend:
  52. service:
  53. name: web-demo
  54. port:
  55. number: 80

web.yaml

####在metadata中指定namespace

不同命名空间下的service-ip是可以互相访问的,与命名空间无关。

不同命名空间下的pod名称与dns是访问不到的。pod-ip是不隔离的。

切换默认namespace

  1. kubectl config set-context ctx-dev \
  2. --cluster=kubernetes \
  3. --user=admin \
  4. --namespace=dev \
  5. --kubeconfig=/root/.kube/config
  6. 设置上下文 区分权限的话重新创建user并赋予对应权限
  7.  
  8. kubectl config set-context ctx-dev --kubeconfig=/root/.kube/config
  9. 设置当前默认上下文
  • 划分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限制

  1. apiVersion: apps/v1
  2. kind: Deployment
  3. metadata:
  4. name: web-demo
  5. namespace: dev
  6. spec:
  7. selector:
  8. matchLabels:
  9. app: web-demo
  10. replicas: 4
  11. template:
  12. metadata:
  13. labels:
  14. app: web-demo
  15. spec:
  16. containers:
  17. - name: web-demo
  18. image: 172.17.166.217/kubenetes/web:v1
  19. ports:
  20. - containerPort: 8080
  21. resources:
  22. requests:
  23. memory: 500Mi
  24. cpu: 100m
  25. limits:
  26. memory: 1000Mi
  27. cpu: 200m

resources-pod.yaml

#内存单位为Mi/Gi cpu为m/个数 1核心cpu=1000m

查看node节点中资源使用情况

  1. kubectl describe nodes node-3-172.17.166.219

对应传输给docker的值,查看容器详细信息

  1. 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量。

测试内存资源限制,进入容器编写脚本

  1. #!/bin/bash
  2. str="[sdfsofajpfjpfsajfs]"
  3. while true;
  4. do
  5. str="$str$str"
  6. echo "+++++"
  7. sleep 0.1
  8. done

###当资源耗尽(cpu/memory),会将容器中资源占用最多的进程杀掉。并不会杀掉容器。

测试cpu限制

查看cpu使用情况

  1. crictl stats d5c1df6d1561e

kubectl top命令需要第三方api metrics-server支持,可参考https://blog.csdn.net/wangmiaoyan/article/details/102868728

进入容器模拟cpu占用

  1. dd if=/dev/zero of=/dev/null &执行多次就会占用光cpu

###cpu占满后与内存不同的是进程不会杀掉,cpu是可压缩资源,内存不是。

设置pod container默认限制

  1. apiVersion: v1
  2. kind: LimitRange #范围的限制
  3. metadata:
  4. name: test-limits #策略名称
  5. spec:
  6. limits:
  7. - max:
  8. cpu: 4000m #最大cpu
  9. memory: 2Gi #最大内存
  10. min:
  11. cpu: 100m #最小cpu
  12. memory: 100Mi #最小内存
  13. maxLimitRequestRatio:
  14. cpu: 3 #cpu中limits最大比requests的倍数
  15. memory: 2 #memory中limits最大比requests的倍数
  16. type: Pod #类型pod
  17. - default:
  18. cpu: 300m #默认cpu
  19. memory: 200Mi #默认memory
  20. defaultRequest:
  21. cpu: 200m #默认requestcpu
  22. memory: 100Mi #默认request memory
  23. max:
  24. cpu: 2000m #最大值
  25. memory: 1Gi
  26. min:
  27. cpu: 100m #最小值
  28. memory: 100Mi
  29. maxLimitRequestRatio:
  30. cpu: 5 #limit最多比request比例的倍数
  31. memory: 4
  32. type: Container #类型container

pod-container.yaml

查看命名空间下资源限制

  1. kubectl describe limitranges --all-namespaces

namespace资源限制

资源限制

  1. apiVersion: v1
  2. kind: ResourceQuota #资源配额
  3. metadata:
  4. name: resource-quota
  5. namespace: wanger
  6. spec:
  7. hard:
  8. pods: 4 #最多允许pod个数
  9. requests.cpu: 2000m
  10. requests.memory: 4Gi
  11. limits.cpu: 4000m
  12. limits.memory: 8Gi
  1. apiVersion: v1
  2. kind: ResourceQuota
  3. metadata:
  4. name: object-counts
  5. spec:
  6. hard:
  7. configmaps: 10 #最多允许configmap
  8. persistentvolumeclaims: 4 #最多允许pvc
  9. replicationcontrollers: 20 #最多允许有replicat
  10. secrets: 10 #最多允许secret
  11. services: 10 #最多允许service

查看quota设置

  1. kubectl get quota -n test
  2. kubectl describe -n wanger quota

pod驱逐策略-Eviction

  • pod容器资源策略优先级
  • requests == limits时优先级最高(绝对可靠)
  • 不设置 (最为不可靠)
  • limits > requests 优先级次之(相对可靠)

kubelet启动常用驱逐策略配置:

###当node内存小于1.5G持续1m30秒进行pod驱逐,如果node内存小于100M磁盘小于1G剩余inodes节点小于百分之五立刻进行驱逐。

kubelet配置驱逐策略:

  1. 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

  1. apiVersion: apps/v1
  2. kind: Deployment
  3. metadata:
  4. name: web-demo
  5. namespace: dev
  6. spec:
  7. selector:
  8. matchLabels:
  9. app: web-demo #选择pod label app=web-demo
  10. replicas: 1
  11. template:
  12. metadata:
  13. labels:
  14. app: web-demo #定义pod label app=web-demo
  15. spec:
  16. containers:
  17. - name: web-demo
  18. image: hub.mooc.com/kubernetes/web:v1
  19. ports:
  20. - containerPort: 8080
  21. ---
  22. #service
  23. apiVersion: v1
  24. kind: Service
  25. metadata:
  26. name: web-demo
  27. namespace: dev
  28. spec:
  29. ports:
  30. - port: 80
  31. protocol: TCP
  32. targetPort: 8080
  33. selector:
  34. app: web-demo #service 选择pod label app=web-demo
  35. type: ClusterIP

###1.6版本之前在pod之上还有rc概念,即replicas副本控制器。deployment将rc封装,deployment本质是操作副本控制器。selector与pod名称需一致,rc去调用pod。deployment label是可变的,多个同样名称的rc和pod是不冲突的,属于不同的deployment

pod通过group标签rc选中group

  1. apiVersion: apps/v1
  2. kind: Deployment
  3. metadata:
  4. name: web-demo
  5. namespace: dev
  6. spec:
  7. selector:
  8. matchLabels:
  9. app: web-demo
  10. matchExpressions:
  11. - {key: group, operator: In, values: [dev, test]}#定义选择组
  12. replicas: 1
  13. template:
  14. metadata:
  15. labels:
  16. group: dev #pod打上组标签
  17. app: web-demo
  18. spec:
  19. containers:
  20. - name: web-demo
  21. image: hub.mooc.com/kubernetes/web:v1
  22. ports:
  23. - containerPort: 8080

###校验pod是否是deployment需要的。

查看是否创建成功

  1. kubectl get pods -l app=web-demo -n dev
  2.  
  3. kubectl get pods -l group=dev -n dev
  4.  
  5. kubectl get pods -l app=web-demo group=dev -n dev
  6.  
  7. kubectl get pods -l 'group in (dev, test)' -n dev

    kubectl get pods -l 'group notin (dev, test) -n dev'

container通过标签选择node

  1. apiVersion: apps/v1
  2. kind: Deployment
  3. metadata:
  4. name: web-demo
  5. namespace: dev
  6. spec:
  7. selector:
  8. matchLabels:
  9. app: web-demo
  10. matchExpressions:
  11. - {key: group, operator: In, values: [dev, test]}
  12. replicas: 1
  13. template:
  14. metadata:
  15. labels:
  16. group: dev
  17. app: web-demo
  18. spec:
  19. containers:
  20. - name: web-demo
  21. image: hub.mooc.com/kubernetes/web:v1
  22. ports:
  23. - containerPort: 8080
  24. nodeSelector:
  25. disktype: ssd

selector-node.yaml

给node打上标签

  1. kubectl label node node-3-172.17.166.219 disktype=ssd
  2.  
  3. kubectl get nodes node-3-172.17.166.219 --show-labels

k8s入坑之路(13)kubernetes重要资源(namespace隔离 resources资源管理 label)的更多相关文章

  1. k8s入坑之路(7)kubernetes设计精髓List/Watch机制和Informer模块详解

    1.list-watch是什么 List-watch 是 K8S 统一的异步消息处理机制,保证了消息的实时性,可靠性,顺序性,性能等等,为声明式风格的API 奠定了良好的基础,它是优雅的通信方式,是 ...

  2. k8s入坑之路(16)kubernetes中CICD/基于宿主机jenkins

    cicd的结合组件 需要代码仓库如gitlab.github.包构建工具Maven等,持续集成工具如jenkins,github/cicd.结合自己脚本实现重复式任务自动化. 传统服务发布流程: 提交 ...

  3. k8s入坑之路(14)scheduler调度 kubelet管理及健康检查 更新策略

    kubelet 主要功能 Pod 管理 在 kubernetes 的设计中,最基本的管理单位是 pod,而不是 container.pod 是 kubernetes 在容器上的一层封装,由一组运行在同 ...

  4. k8s入坑之路(15)kubernetes共享存储与StatefulSet有状态

    共享存储 docker默认是无状态,当有状态服务时需要用到共享存储 为什么需要共享存储: 1.最常见有状态服务,本地存储有些程序会把文件保存在服务器目录中,如果容器重新启停则会丢失. 2.如果使用vo ...

  5. k8s入坑之路(13)服务迁移(定时任务 微服务 传统服务)

    定时任务迁移kubernetes 服务迁移步骤 1.安装好java 2.安装好maven 项目打包 mvn package 测试传参运行 java -cp cronjob-demo-1.0-SNAPS ...

  6. k8s入坑之路(10)kubernetes coredns详解

    概述 作为服务发现机制的基本功能,在集群内需要能够通过服务名对服务进行访问,那么就需要一个集群范围内的DNS服务来完成从服务名到ClusterIP的解析. DNS服务在kubernetes中经历了三个 ...

  7. k8s入坑之路(2)kubernetes架构详解

    每个微服务通过 Docker 进行发布,随着业务的发展,系统中遍布着各种各样的容器.于是,容器的资源调度,部署运行,扩容缩容就是我们要面临的问题.   基于 Kubernetes 作为容器集群的管理平 ...

  8. k8s入坑之路(11)kubernetes服务发现

    kubernetes访问场景 1.集群内部访问 2.集群内部访问外部 3.集群外部访问内部 1.集群内部访问 1.pod之间直接ip通讯(利用calico通过路由表经过三层将ip流量转发)由于容器之间 ...

  9. 【转载】k8s入坑之路(2)kubernetes架构详解

    每个微服务通过 Docker 进行发布,随着业务的发展,系统中遍布着各种各样的容器.于是,容器的资源调度,部署运行,扩容缩容就是我们要面临的问题. 基于 Kubernetes 作为容器集群的管理平台被 ...

随机推荐

  1. Spring Cloud Gateway 雪崩了,我 TM 人傻了

    本系列是 我TM人傻了 系列第六期[捂脸],往期精彩回顾: 升级到Spring 5.3.x之后,GC次数急剧增加,我TM人傻了 这个大表走索引字段查询的 SQL 怎么就成全扫描了,我TM人傻了 获取异 ...

  2. Redis之品鉴之旅(六)

    持久化 快照的方式(RDB) 文件追加方式(AOF) 快照形式: save和bgsave能快速的备份数据.但是.........., Save命令:将内存数据镜像保存为rdb文件,由于redis是单线 ...

  3. MyBatis 批量插入数据的 3 种方法!

    批量插入功能是我们日常工作中比较常见的业务功能之一,之前我也写过一篇关于<MyBatis Plus 批量数据插入功能,yyds!>的文章,但评论区的反馈不是很好,主要有两个问题:第一,对 ...

  4. C#开发BIMFACE系列41 服务端API之模型对比

    BIMFACE二次开发系列目录     [已更新最新开发文章,点击查看详细] 在建筑施工图审查系统中,设计单位提交设计完成的模型/图纸,审查专家审查模型/图纸.审查过程中如果发现不符合规范的地方,则流 ...

  5. redis两种持久化策略/存储模式

    redis的持久化策略   RDB,即 Redis DataBase,以快照形式将数据写入一个临时文件,持久化结束后,用这个临时文件替换上次持久化的dump文件,达到数据恢复. 默认开启,见redis ...

  6. 某个buuctf的题(easy_tornado)

    题目:http://88099f53-12b6-470a-9993-b73e4155940e.node3.buuoj.cn/ 1首先看三个文件的内容 2简单分析 如果出题人没整一些花里胡哨的,那么fl ...

  7. CF468C Hack it! 超详细解答

    CF468C Hack it! 超详细解答 构造+数学推导 原文极简体验 CF468C Hack it! 题目简化: 令\(f(x)\)表示\(x\)在十进制下各位数字之和 给定一整数\(a\)构造\ ...

  8. MeteoInfo-Java解析与绘图教程(五)

    MeteoInfo-Java解析与绘图教程(五) 最近太忙了,终于有时间继续写了,上文说到了基本上的绘图方法,但缺少色阶呈现,一般图叠加着地图上,后端不需要管色阶,但也要注意web页面色阶和我们的生成 ...

  9. java的加载与执行原理剖析

    到目前为止,我们接触过的重点术语,总结一下: Java体系的技术被划分为三大块: JavaSE:标准版 JavaEE:企业版 JavaME:微型版 安装JDK之后: JDK:java开发工具箱 JRE ...

  10. csp-j 复赛感想

    作者:博客园小蔡编程 这次是作者第一次参加csp-j的比赛 内心还是挺激动的 今天,作者就来和大家讨论一下这次csp-j的学习心得和感想 T1 分糖果 这题描述看似复杂 其实就是一道求最大取模的题 L ...