企业级容器云PaaS解决方案【厚PaaS+轻应用+微服务】---（2）

---

二.资源管理

1.计算资源管理

• 多集群资源管理
• 资源分区管理
• 资源配额+资源限制
• 服务端口号管理

2.网络资源管理

• 跨主机容器网络方案
• 网络策略管理
• 集群边界路由器Ingress管理
• 集群DNS域名服务器管理

3.存储资源管理

• k8s支持的Volume类型
• 共享存储管理
• CSI（Container Storage Interface）
• 存储资源应用场景

4.镜像资源管理

• 镜像生命周期管理
• 镜像库多租户权限管理
• 镜像库远程复制管理
• 镜像库操作审计管理
• 开源容器镜像库

---

1.计算资源管理

计算资源在云平台上指：应用程序运行所需要的资源，包括cpu+memory。

多租户=》资源共享+资源隔离

k8s体系中，对计算资源的管理可以在如下三个级别进行：

• namespace
• pod
• container

同时根据应用计算资源的需求和限制，提供不同级别的服务质量（QoS）管理。

多集群资源管理

大型企业中，将企业各个数据中心的服务器全部纳入一个k8s集群中进行管理是不切实际的，主要要考虑到如下问题：

• 需要容灾备份的DC提供服务，保证业务的高可用性
• 多个DC之间分布在不同的地区，DC之间的网络时延较长
• 服务器由不同的云服务商托管，互相之间无法直接互联互通
• 多个DC之间的安全策略和安全等级不同

基于以上原因，通常需要部署多个k8s集群，来共同完成应用的发布和运行。

在容器云平台上，对资源的管理首先是将多个k8s集群纳入管理，以便能够对所有资源进行统一分配和管理。

将多个k8s集群纳入统一管理方案：

1. 通过对接每个k8s集群的master，来完成集群内的资源管理和应用部署管理
   实现：容器云平台需要通过k8s master提供的restful api去控制整个集群，包括对各种资源的CURD操作；还需完成应用的多集群部署管理、跨集群水平扩展、集群的服务发现和自动灾难切换等多集群管理；并设置相应的网络策略，以保护各集群的master不被攻击。
2. 使用统一的Federation控制平面（k8s的一个子项目）来对多个k8s集群进行他同意管理
   实现：https://jimmysong.io/kubernetes-handbook/practice/federation.html
   Federation的设计目标是对多个k8s集群进行统一管理，将用户的应用部署到不同地域的DC或是云环境中，通过动态优化部署来节约运营成本。
   federation架构中，引入一个位于所有k8s集群之上的Federation控制平面，屏蔽了后端的各k8s子集群，向客户提供了一个统一的管理入口。
   Federation控制平面封装了多个k8s集群的master角色，提供了一个统一的master，包括Federation API Server、Federation Controller Manager，用户可以像操作单个集群一样操作Federation；还统一管理了全部k8s集群的DNS、ConfigMap，并将数据保存在集中的etcd数据库中。
   问题：

• 为确保所有集群的运行状态符合预期，Federation控制平面会持续监控所有集群，导致网络开销和成本增加
• Federation控制平面是“中心化”的总控节点，一旦出现问题，就可能会影响到所有集群。
• Federation出现较晚，不是很成熟，目前k8s中的资源对象只有一部分在Federation中是可用的。

资源分区管理

在容器云平台纳管所有k8s集群之后，平台管理员就可以进行资源分配的工作，为多个租户提供应用部署运行环境了。

在一个k8s集群中，提供计算资源的的实体被称为Node，即工作节点。
Node可为物理机服务器，也可为虚拟机服务器。
每个Node都提供了计算（cpu+memory）+网络+存储三大资源，应用系统则是这些资源的使用者。

为了支持多租户模型，k8s使用namespace机制将一个集群划分为多个虚拟分区，进而实现资源隔离。类似互联网的域名，ns的名称可以看做是一级域名，在ns中部署的服务名则可看做是二级域名。
如：

• myweb.default.svc
• myweb.test.svc

ns的“分区”是逻辑上的，ns并不与特定的物理资源进行绑定。
多个ns下的应用可以共享相同的Node资源，将“小而轻”的容器应用以更加合理的方式在物理资源中进行调度。

对于某些独享资源的用户，则需为其划分固定的Node范围。
k8s使用【标签label+标签选择器label selector】来实现所有资源对象的角色划分及选择。
通过给Node设置特定的Label，就可以标注该Node属于哪个租户。
在总体资源不够充分的情况下，也可将一个Node设置多个Label，让多个租户共享。

资源配额+资源限制

在共享资源的环境下，管理员需要为租户设置更精细的资源配额和资源限制的管理。
各租户在自己的资源分区上部署应用时，将只能使用被分配到的总资源数量。
容器云平台应该将持续监控和统计各租户对资源的使用情况，为未来是否应该为租户增加资源或是减少资源提供依据。

在k8s集群中，为了完成【资源的配额管理+资源限制管理】，可从ns、pod、container三个级别进行管理。

1. container级别：type=container=>kind: LimitRanger(ns)
   可对计算资源cpu+memory进行管理。
   对他们的配置项包括两种：
   资源请求ResourceRequest【defaultRequest】，表示容器希望被分配到的可完全保证的资源量，Requests的值会被提供给k8s调度器scheduler，以便于优化基于资源请求的容器调度。
   资源限制ResourceLimits【default】，Limits是容器能用的资源上限，这个上限的值会影响在节点上发生资源竞争是的解决策略。
   max+min+maxLimitReauestRatio
2. pod级别：type=pod=>kind: LimitRanger(ns)
   由于一个pod可以包含多个container，所以可以对pod所含的全部容器所需的cpu+memory进行管理。
   在k8s中，可以通过创建LimitRange资源对象完成设置，LimitRange对象作用于namespace。
   max+min+maxLimitReauestRatio
3. namespace级别：kind: ResourceQuota
   可对ResourceQuota资源对象配置，提供一个总体上的资源使用量限制：
   一方面可以设置该ns中pod可以使用到的计算资源(cpu+memory)的总量上限；
   另一方面可以限制该ns中，某种类型对象的总数量上限（包括可以创建的pod、rc、svc、secret、configmap、pvc等对象的数量限制）
   在compute-resources.yaml中设置了ns为default的所有容器的cpu request综合不超过1，上限为2等。

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
  namespace: default
spec:
  hard: