Kubernetes集群在企业内部多租户共享场景下的管理.docx

随着容器编排技术的成熟，KUbemeteS也逐渐成为云计算的标准，但其使用的场景也各不相同。在KUberneteS集群环境下实现多租户场景下，仍然面临着诸如：权限管理，资源隔离，平台内部网络安全，资源调度等问题。本文主要介绍在公司内部多租户场景下，Kubernetes集群的管理。RBAC权限管理企业内部容器平台：业务可控，组织架构复杂，更加注重权限的细粒度管理。Kubemetes提供namespace作为基础的资源隔离单位和基于RBAC的权限管理方式，可以说Kubernetes多租户的实现离不开这两个核心内容。RBAC作为一种基于角色的并且灵活的访问控制机制且相较于其他的权限管理插件更加广泛，在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可理解对资源对象拥有的权限，就是给定对资源可以对做什么。例如：公司信息部经理，可以管理公司的信息部。创建绑定角色的用户。例如：李四绑定角色。例如：李四能力强，让他担任信息部部门经理。用下面两个集群来说明Role,RoleBinding和ClusterRole,ClusterRoleBinding。NamespacelNamespace4roleBinding*I<olelK一一Iadminro2JlXolelroleBindingadminrole2Namcspacc2roleBindingNamespc3roleBinding*yadminrole2roleladminrole2espacel,roleBindingr<oleNamespace2ClUSterR,IeBindinq4roleBindingfoleyroleBinding，K8s集群1NameSPaCe4roleBindingrole1.K8s集群2adminroleNamcspacc5.JroleBindingrolel集群1：为每个名称空间(NameSPaCe)中，定义都定义了一个名称空间的管理员的角色，然后使用R。IeBinding将AdminRole关联到用户上，来让指定用户成为此名称空间中的管理员。这样做很显然，非常繁琐。集群2：在Kubernetes集群级别创建一个AdminROIe,然后在使用RoleBinding来引用它，并将它和自己名称空间中的用户关联，这样该用户就成功的拥有了对当前名称空间的管理员权限。总的来说：RoleBinding即可以绑定名称空间内部的Role,又可以绑定ClUSterROle,但RoleBinding绑定后，具体化的Role是具体化成本名称空间的RoleoClusterRoleBinding仅可绑定ClusterRole,它具体化的Role,就可访问整个集群中所有的资源。由于RBAC的灵活的权限管理能力，更加适用于复杂的多租户厂家下用户的权限管理中，针对不同的需求制定不同的权限管理策略。如：集群管理员权限具有集群的管理权限为租户创建和分配命名空间各类策略(RAMRBACNetWOrkPoliCy/quota)的CRUD租户管理员权限拥有管理其在Kubernetes的namespace以及namespace中运行程序的管理权限普通租户权限拥有管理其在Kubernetes的namespace中运行的所有资源的只读权限Pod资源调度APIServer接受客户端提交Pod对象创建的请求后，会由调度器程(kube-scheduler),在当前集群中选择一最佳可用的节点接收并运行，并不是指定的节点。如需要将POd资源按照需求调度，则就需要指定相关的调度策略。KUbemeteS集群的调度器：Scheduler(默认调度器)。其核心目标是基于资源的可用性将各Pod资源公平地分布于集群节点之上。完成调度的操作步骤：节点预选节点优先级排序节点优选与6'J5三pod节点预选策略预选策略就是节点过滤器，执行预选操作时，调度器将对每个节点基于配置适用的预选策略以特定的次序逐一筛查，并根据一票否决制进行节点淘汰，如若预选后不存在任何一个满足条件的节点，则Pod处于Pending状态，直至至少一个节点可用为止。预选策略根据其是否可以接受配置参数，又将预选策略为可配置策略和静态策略，可以配置策略可以在预选过程中结合用户自定义调度逻辑。如何让Pod在部署时调度至指定的Kubernetes集群中具体Node节点或者带着某一类标签的节点，可以通过节点亲和调度来实现。节点亲和调度硬亲和调度，硬亲和度的实现时强制性的，Pod调度时必须要满足的条件，不存满足条件节点时，Pod则处于pending状态。软亲和调度，软亲和调度是一种柔性调度，倾向于将Pod调度到某类特定节点上运行，调度器尽量满足调度到满足条件的节点，在无法满足需求时，退而求次选择不满足条件的节点上运行。权重Weight定义优先级，1-100值越大优先级越局。requiredDuringSchedulinglgnoredDuringExecution和PreferredDuringschedulinglgnoredDuringExecution名字中的后半段IgnOredDUringEXeCUtiOn隐藏含义所指，在Pod资源基于节点亲和性规则调度至某节点之后，节点标签发生了改变而不在符合此类节点亲和性规则时，调度器不会将Pod对象从此节点移除，因为它仅对新建的Pod对象生效。在选择节点调度的策略时一般建议选择节点软亲和调度，不会因为目标节点资源不存在导致，适用非特殊的Pod,不会因Pod无法启动，从而导致无法对外提供服务。而在运行特殊的Pod需要运行在特定的计算资源的情况时，此时选择节点硬亲和策略进行调度将Pod调度至特定的节点运行。Pod资源亲和调度在出于高效通信的需求,有时需要将一些Pod调度到相近甚至是同一区域位置（比如同一节点、机房）等等，比如业务的前端Pod和后端Pod,此时这些POd对象之间的关系可以叫做亲和性。同时出于安全性的考虑，也会把一些POd之间进行隔离，此时这些POd对象之间的关系叫做反亲和性（anti-affinity）o调度器把第一个Pod放到任意位置，然后和该Pod有亲和或反亲和关系的Pod根据该动态完成位置编排，这就是Pod亲和性和反亲和性调度的作用。Pod的亲和性定义也存在硬亲和性和软亲和性的区别，其约束的意义和节点亲和性类似。Pod的亲和性调度要求各相关的POd对象运行在同一位置，而反亲和性则要求它们不能运行在同一位置。这里的位置实际上取决于节点的位置拓扑，拓扑的方式不同，Pod是否在同一位置的判定结果也会有所不同。如果基于各个节点的kubernetes.io/hostname标签作为评判标准，那么会根据节点的hostname去判定是否在同一位置区域。污点和容忍度污点（taints）是定义在节点上的一组键值型属性数据，其作用与节点亲和调度恰恰相反，用来让节点拒将特定的Pod调度到该节点上，除非该Pod对象具有容纳节点污点的容忍度。而容忍度（tolerations）是定义在Pod对象上的键值型数据，用来配置让Pod对象可以容忍节点的污点。Kubernetes使用PodToleratesNodeTaints预选策略和TaintTolerationPriority优选函数来完成这种调度方式。污点容忍度：NoScheduIe:不能容忍此污点的新Pod对象不能调度到该节点上，属于强制约束，节点现存的Pod对象不受影响。PreferNoSchedule：NOSChedUIe属于柔性约束，即不能容忍此污点的Pod对象尽量不要调度到该节点，不过无其他节点可以调度时也可以允许接受调度。NoExecute：不能容忍该污点的新POd对象不能调度该节点上，强制约束，节点现存的Pod对象因为节点污点变动或Pod容忍度的变动导致无法匹配规则，Pod对象就会被从该节点上去除。优选函数（节点优选）预选策略筛选出一个节点列表就会进入优选阶段，在这个过程调度器会向每个通过预选的节点传递一系列的优选函数来计算其优先级分值，优先级分值介于O-Io之间，其中0表示不适用，10表示最适合托管该POd对象。另外，调度器还支持给每个优选函数指定一个简单的值，表示权重，进行节点优先级分值计算时，它首先将每个优选函数的计算得分乘以权重，然后再将所有优选函数的得分相加，从而得出节点的最终优先级分值。权重可以让管理员定义优选函数倾向性的能力，其计算优先级的得分公式如下：finalScoreNode=(weight1*priorityFunc1)+(weight2*priorityFunc2)+实际上我们大多数的时候做的Pod资源调度都是在节点预选策略中的可配置预选策略来实现完成。Pod服务质量Kubernetes允许节点资源对limits的过载使用，意味着节点可能无法同时满足其上面所有Pod对象以资源满载的方式运行。在节点内存资源紧张时，是通过Pod的优先来决定Pod对象终止的顺序。根据Pod对象的limits和request属性，Kubernetes将Pod对象归类Guaranteed>Burstable和BestEffort三个服务质量。对于QoS类为Guaranteed的Pod：Pod中的每个容器必须指定内存请求和内存限制，并且两者要相等。Pod中的每个容器必须指定CPU请求和CPU限制，并且两者要相等。这类Pod资源具有最高优先级。如果满足下面条件,将会指定Pod的QoS类为Burstable：当Pod设置的CPU或者内存限制资源与请求资源不相等时，此类Pod具有中等优先级。对于QoS类为BestEffort的Pod：Pod中的容器必须没有设置内存和CPU限制或请求。此类Pod优先级别为最低级别。requests和IimitS没看设置requests小于IimitSrequests等于IirnitS内存资源紧缺时，BeStEffort类别的POd将首当其冲地被终止，因为系统不为其提供任何级别的资源保证，换来的好处是在用时做到尽可能的占用资源。当BestEffort类别的Pod不存在时，Burstable类别的Pod将会被终止。Guaranteed类别的Pod拥有最高优先级，它们不会被杀死，除非其内存资源需求超限，或者OOM时没有其他更低优先级的Pod资源存在。每个运行状态容器都有其OoM得分，得分越高越会被优先杀死。OOM得分主要根据两个维度来计算：由QoS类别继承而来的默认分值和容器可用内存资源比例。同等级优先级的Pod资源在OOM时，与自身的requests属性相比，其内存占用比例最大的POd对象将首先被杀死。OoM是内存耗尽时的处理机制，与可压缩资源CPU无关，CPU资源无法获得保证时，Pod仅仅时暂时获取不到相应资源而已。因此，在针对POd的QoS等级，调整部署时Pod相应的