作者:许伟,航天网信研发工程师
K8s 是容器编排和分布式应用部署畛域的领导者,在 K8s 环境中,咱们只须要关怀利用的业务逻辑,加重了咱们服务器网络以及存储等方面的管理负担。对于一个用户而言,K8s 是一个很简单的容器编排平台,学习老本十分高。KubeSphere 形象了底层的 K8s,并进行了高度的产品化,构建了一个全栈的多租户容器云平台,为用户提供了一个强壮、平安、功能丰富、具备极致体验的 Web 控制台,解决了 K8s 应用门槛高和云原生生态工具庞杂等痛点,使咱们能够专一于业务的疾速迭代,其多维度的数据监控,对于问题的定位,提供了很大的帮忙。
为什么要在 KuberSphere 上实现分级管理
在 KubeSphere 中,资源能够在租户之间共享,依据调配的不同角色,能够对各种资源进行操作。租户与资源之间、资源与资源之间的自由度很高,权限粒度也比拟大。在咱们的零碎中,资源是有权限等级的,像是低等级用户能够通过邀请、赋予权限等操作来操作高等级资源,或者像是低等级我的项目中的 Pod 能够调度到高等级的节点上,对资源。诸如此类跨等级操作资源等问题,咱们在 KubeSphere 根底上来实现了分级管理。
什么是分级体系
分级,顾名思义就是依照既定的规范对整体进行合成、分类。咱们将其形象成一个金字塔模型,从地基到塔顶会有很多个层级,咱们将公共资源作为金字塔的地基,领有最高权限的 admin 作为塔顶,其余资源依照权限等级划分成不同等级。低层级资源是不能拜访高等级资源,高等级资源能够获取它等级之下的所有资源,构建了这样一个权利递加、层级间隔离的分级体系。
如何实现分级管理
咱们定义了一个代表等级的标签 kubernetes.io/level
。以一个多节点的集群为例,首先咱们会给用户、企业空间、节点等资源打上代表等级的标签。在邀请用户退出企业空间或者我的项目时,要求退出的企业空间或者我的项目的等级不得高于用户的等级,同样我的项目在绑定企业空间时,也要求我的项目的等级不得高于企业空间的等级,能力对资源进行纳管;咱们认为同一我的项目下的资源的等级是雷同的,基于我的项目创立的负载、Pod、服务等资源的等级跟我的项目保持一致;同时 Pod 中退出节点亲和性,以使 Pod 调度到不高于其权限等级的节点上。
例如这里,咱们创立了一个权限等级是 3 的用户 demo-user
,他能够退出权限等级不高于 3 的企业空间或者我的项目中。
kind: User
apiVersion: iam.kubesphere.io/v1alpha2
metadata:
name: demo-user
labels:
kubernetes.io/level: 3
spec:
email: demo-user@kubesphere.io
创立一个权限等级是 2 的我的项目 demo-ns
,那么基于我的项目创立的负载、Pod、存储等资源的权限等级也是 2。
apiVersion: v1
kind: Namespace
metadata:
name: demo-ns
labels:
kubernetes.io/level: 2
基于 demo-ns
我的项目创立了一个 nginx
的 Pod,他的权限等级也是 2,同时退出节点亲和性,要求其调度到权限等级不高于 2 的节点上。
apiVersion: apps/v1
kind: Pod
metadata:
labels:
kubernetes.io/level: 2
name: nginx
spec:
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
protocol: TCP
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/level
operator: Lt
values:
- 2
- matchExpressions:
- key: kubernetes.io/level
operator: In
values:
- 2
如何实现资源的升降级
在分级管理体系中,反对等级的有限划分,只须要定义一个两头值,就能够在两个等级之间插入一个新的等级,无需操作其余资源;在对资源进行升降级时,只须要批改对应资源的 label
标签,就能够对资源进行升降级操作。当然,在对资源进行升降级的时候,咱们须要对资源进行检测,保障降级时,其下层资源的权限等级不得低于指标等级;同时,降级时,其上层资源的权限等级不得高于指标等级。在不满足升降级操作条件时,须要将对应资源也做相应调整才能够。
不同层级间 Pod 的网络隔离
在分级体系中,咱们要求高等级的 Pod 能拜访低等级的 Pod,然而低等级的 Pod 不能拜访高等级的 Pod,那咱们须要如何保障不同层级间 Pod 的网络通信呢。
我的项目在不开启网络隔离的状况下,Pod 间的网络是互通的,所以这里会新增一个黑名单的网络策略。
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all
namespace: demo-ns
labels:
kubernetes.io/level: 2
spec:
podSelector: {}
policyTypes:
- Ingress
podSelector:{}
作用于我的项目中所有 Pod,阻止所有流量的流入。
而后放行标签等级大于指标等级(这里是 2)的流量流入(咱们对 Ingress 流量没有做限度)。
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: level-match-network-policy
namespace: demo-ns
labels:
kubernetes.io/level: 2
spec:
podSelector:
matchExpressions:
- key: kubernetes.io/level
operator: Gt
values:
- 2
policyTypes:
- Ingress
总结
KubeSphere 解决了用户构建、部署、治理和可观测性等方面的痛点,它的资源能够在多个租户之间共享。然而在资源有权限等级的场景中,低等级资源能够操作高等级资源,造成资源越权治理的问题。为解决这一问题,咱们在 KubeSphere 的根底上进行了革新,以适应租户与资源之间和资源与资源之间的分级管理,同时在我的项目的网络策略中,减少黑名单和白名单策略,加强了我的项目间的网络隔离,让资源的治理更平安。
本文由博客一文多发平台 OpenWrite 公布!