《Kubernetes集群在企业内部多租户共享场景下的管理.docx》由会员分享,可在线阅读,更多相关《Kubernetes集群在企业内部多租户共享场景下的管理.docx(10页珍藏版)》请在优知文库上搜索。
1、随着容器编排技术的成熟,KUbemeteS也逐渐成为云计算的标准,但其使用的场景也各不相同。在KUberneteS集群环境下实现多租户场景下,仍然面临着诸如:权限管理,资源隔离,平台内部网络安全,资源调度等问题。本文主要介绍在公司内部多租户场景下,Kubernetes集群的管理。RBAC权限管理企业内部容器平台:业务可控,组织架构复杂,更加注重权限的细粒度管理。Kubemetes提供namespace作为基础的资源隔离单位和基于RBAC的权限管理方式,可以说Kubernetes多租户的实现离不开这两个核心内容。RBAC作为一种基于角色的并且灵活的访问控制机制且相较于其他的权限管理插件更加广泛,
2、在Kubernetes集群中默认强制开启。RBAC中的核心概念:基于单个名称空间:Role,RoleBinding整个集群级别:ClusterRole,ClusterRoleBinding尊于角色的访问控制as权限,/jJ读get诵I写Write11定义角色赋予权限角色绑定角色,CIusterRoIe更新UPdate列出IiSt监视WatCh绑定角色I-I用户账户服务账户1. Role2. CIusterRoIe3. RoIeBinding4. CIusterRoIeBinding接下来说下RBAC的授权过程:创建Role(角色)。Role可理解对资源对象拥有的权限,就是给定对资源可以对做什么
3、。例如:公司信息部经理,可以管理公司的信息部。创建绑定角色的用户。例如:李四绑定角色。例如:李四能力强,让他担任信息部部门经理。用下面两个集群来说明Role,RoleBinding和ClusterRole,ClusterRoleBinding。NamespacelNamespace4roleBinding*IolelK一一Iadminro2JlXolelroleBindingadminrole2Namcspacc2roleBindingNamespc3roleBinding*yadminrole2roleladminrole2espacel,roleBindingrBurstable和Best
4、Effort三个服务质量。对于QoS类为Guaranteed的Pod:Pod中的每个容器必须指定内存请求和内存限制,并且两者要相等。Pod中的每个容器必须指定CPU请求和CPU限制,并且两者要相等。这类Pod资源具有最高优先级。如果满足下面条件,将会指定Pod的QoS类为Burstable:当Pod设置的CPU或者内存限制资源与请求资源不相等时,此类Pod具有中等优先级。对于QoS类为BestEffort的Pod:Pod中的容器必须没有设置内存和CPU限制或请求。此类Pod优先级别为最低级别。requests和IimitS没看设置requests小于IimitSrequests等于Iirnit
5、S内存资源紧缺时,BeStEffort类别的POd将首当其冲地被终止,因为系统不为其提供任何级别的资源保证,换来的好处是在用时做到尽可能的占用资源。当BestEffort类别的Pod不存在时,Burstable类别的Pod将会被终止。Guaranteed类别的Pod拥有最高优先级,它们不会被杀死,除非其内存资源需求超限,或者OOM时没有其他更低优先级的Pod资源存在。每个运行状态容器都有其OoM得分,得分越高越会被优先杀死。OOM得分主要根据两个维度来计算:由QoS类别继承而来的默认分值和容器可用内存资源比例。同等级优先级的Pod资源在OOM时,与自身的requests属性相比,其内存占用比例最大的POd对象将首先被杀死。OoM是内存耗尽时的处理机制,与可压缩资源CPU无关,CPU资源无法获得保证时,Pod仅仅时暂时获取不到相应资源而已。因此,在针对POd的QoS等级,调整部署时Pod相应的