功能架构
主要组件特性和能力:
- 多集群管理和部署
独立:可以在 KubeSphere 容器平台中维护和管理独立部署的 Kubernetes 集群。
联邦:多个 Kubernetes 集群可以聚合在一起作为 Kubernetes 资源池。当用户部署应用程序时,副本可以部署在资源池中的不同 Kubernetes 集群上。由此,跨区域和多集群实现了高可用性。
- DevOps支持
KubeSphere 提供了基于 Jenkins 的可视化 CI/CD 流水线编辑,无需对 Jenkins 进行配置,同时内置丰富的 CI/CD 流水线插件,包括Binary-to-Image (B2I) 和Source-to-Image (S2I),用于将源代码或二进制文件打包到准备运行的容器映像中。
- 基于 Istio 的服务网络
KubeSphere 服务网络由一组生态系统项目组成,例如 Istio,Envoy 和 Jaeger。我们设计了一个统一的用户界面来使用和管理这些工具。大多数功能都是现成的,并且是从开发人员的角度进行设计的,这意味着 KubeSphere 可以帮助用户减少学习难度,因为不需要单独深入研究这些工具。
KubeSphere 服务网络为分布式应用程序提供细粒度的流量管理、可观测性、服务跟踪以及服务身份和安全性管理。因此,开发人员只需要专注于核心业务。通过 KubeSphere 的服务网络管理,用户可以更好地跟踪、查看路由和优化 Kubernetes 中用于云原生应用程序的通信。
- 多租户管理
在 KubeSphere 中,资源(例如集群)可以在租户之间共享。首先,管理员或运维人员需要使用不同的权限设置不同的帐户角色。可以将这些角色分配给平台中的成员,以对各种资源执行特定的操作。同时,由于 KubeSphere 完全隔离了租户,因此它们根本不会相互影响。
- AppCenter 应用运营平台
AppCenter 面向应用服务提供商和开发者提供一套完整的应用开发和交付平台,通过一整套云端应用编排和管理框架,帮助用户构建传统架构应用、分布式架构应用与微服务架构应用,实现一站式应用开发、部署、上线和运营计费。
- 多维度监控
KubeSphere 通过可视化界面操作监控、运维功能,可简化操作和维护的整个过程。它提供了对各种资源的自定义监控,并可以立即将发生的问题发送给用户。
- 多租户告警系统
支持基于多租户、多维度的监控指标告警。 该系统将发送与各种资源,如节点、网络和工作负载相关的告警。可自定义包含多个告警规则的告警策略,如重复间隔和时间,来定制自己的告警策略、阈值和告警级别。
- 日志查询与收集
提供多租户日志管理,在 KubeSphere 的日志查询系统中,不同的租户只能看到属于自己的日志信息,支持中文日志检索,支持日志导出。多级别的日志查询(项目/工作负载/容器组/容器以及关键字)、灵活方便的日志收集配置选项等。用户可以选择多种日志收集平台,例如 Elasticsearch,Kafka 和 Fluentd
- 应用商店
KubeSphere 提供了一个基于开源 OpenPitrix 的应用商店,支持应用上传、应用审核、应用上架与分类、应用部署,为用户提供应用全生命周期管理功能。
集群架构规划
青云容器云平台部署,关于集群的规划,一般包括包括以下几种。
集群架构 | 适用场景 | 备注 |
单集群 |
| |
单Hosts集群 多个Member 集群 |
| |
多个单集群 |
|
宿主机
宿主机可选择虚拟机和物理机均可, 也可选择物理机和虚拟机混合部署的方式,如:物理机节点承载GPU AI训练节点,虚拟机承载无状态应用服务。
物理机规格推荐
管理节点配置推荐
名称 | 规格描述 | 配件数量 | |
最低 | 推荐 | ||
CPU | Intel Xeon 4214 10 core 2.2GHz(以上) | 2 | 2 |
Memory | 16GB ECC DDR4 RDIMM(以上) | 2 | 4+ |
Raid | 缓存2GB NV 带电容保护 | 1 | |
无特别要求、支持raid1 | 1 | ||
系统盘 | 系统盘 600GB SAS 10K企业级硬盘 | 2 | 2 |
数据盘 | 600GB SAS 10K 企业级硬盘 (以上) 如etcd 融合部署,可考虑SSD 盘作为数据盘。 | 4 | 4+ |
工作节点配置建议
名称 | 规格描述 | 配件数量 | ||
最低 | 推荐 | |||
CPU | Intel Xeon 4214 10 core 2.2GHz(以上) | 2 | 2 | |
Memory | 16GB ECC DDR4 RDIMM(以上) | 4 | 8+ | |
Raid | 缓存2GB NV 带电容保护 | 1 | ||
无特别要求、支持raid1 | 1 | |||
系统盘 | 300GB SAS 10K企业级硬盘(以上) | 2 | 2 | |
数据盘 | SATA | 600GB SAS 10K 企业级硬盘 (以上) | 4 | 4+ |
SSD | 600GB SSD 企业级硬盘 | 4 | 4+ | |
GPU(可选) | NVIDIA Tesla P40、Tesla V100 与 T4 GPU卡 (根据业务场景选择) | 2 | 8 |
虚拟机规格推荐
管理节点配置建议
名称 | 最小配置 | 推荐配置 | |
CPU | 8 | 16 + | |
Memory | 16 | 64 + | |
系统盘 | 100G | 200G + | |
数据盘 | 200G | 500G+ |
工作节点配置建议
名称 | 最小配置 | 推荐配置 | |
CPU | 8 | 16 + | 如采用GPU,虚拟化CPU 需支持Broadwell cpu 体系架构 |
Memory | 32 | 64 + | |
系统盘 | 100G | 200G + | |
数据盘 | 500G | 1TB + | 主要考虑镜像、容器overlay2等数据量。 |
GPU (可选) | 2 | 4+ | 建议采用直通模式,直接挂载到虚拟机上。 |
操作系统
操作系统版本支持,系统内核由客户进行选择并部署好操作系统和内核版本。
注意:如果客户自己购买了商业版 OS (如redhat内核要求参考CentOS),首选客户自己的 OS。如果是国产操作系统为非标准实施,需要收集信息再评估。
操作系统 | 最低配置 | 推荐版本 |
CentOS | CentOS 7.6 kernel 4.4.x | CentOS 7.8 kernel 4.19.x |
Ubuntu | Ubuntu 16.04.5 4.4.0-131 | Ubuntu 18.04.5 4.15.0 |
操作系统为最小化安装,如离线环境客户可以提供yum 源和apt 源
其他配置:
- 关闭虚拟内存
- 关闭防火墙
- 关闭selinux
- 节点中/etc/resolv.cnf 地址可用
- 时间同步,默认集群可接受节点时间差为10s 以内,推荐配置
集群节点命名规划
节点命名应包含集群名称,节点名称,节点角色,此为固定格式,节点名称仅支持小写,集群名称部署完成后不能修改。
格式:集群名称 + 节点角色 + 节点名称
示例:zyjkdev1master01
具体解释如下:
命名 | 解释 |
zyjk | 客户名称 |
dev1 | 集群名称,开发1区 |
master | 代表master节点 |
01 | 代表master 第一个节点 |
存储
- 推荐采用青云Neonsan存储或青云IaaS 块存储。
- 存储建议是商用存储,并提供k8s 标准csi 插件,存储驱动和csi 插件由存储厂商进行安装和维护, 包含都不限于镜像、yaml文件以及安装手册。
- 客户采用开源存储,nfs 、ceph、glusterfs 等开源存储由客户进行维护。
- 不推荐采用本地存储方式。
- 有条件客户推荐可根据业务场景采购文件存储、对象存储、块存储来适应不同业务。
网络 CNI 选型
为了保证网络方案的标准化、扩展性和灵活性,Kubernetes 采用了 Container Networking Interface(CNI)规范。目前Kubernetes支持多种CNI 网络方案,推荐客户选择Flannel、Calico。CNI 一旦选型后,后期不支持修改。
防火墙
- 集群内部建议不设置防火墙。如设置防火墙可参考下表
- 多集群联邦模式部署,需要考虑hosts 集群可以访问member 集群的6443 端口。
服务 | 协议 | 操作 | 起始端口 | 结束端口 | 备注 |
ssh | TCP | allow | 22 | ||
etcd | TCP | allow | 2379 | 2380 | |
apiserver | TCP | allow | 6443 | ||
calico | TCP | allow | 9099 | 9100 | |
bgp | TCP | allow | 179 | ||
nodeport | TCP | allow | 30000 | 32767 | |
master | TCP | allow | 10250 | 10258 | |
dns | TCP | allow | 53 | ||
dns | UDP | allow | 53 | ||
local-registry | TCP | allow | 5000 | 离线环境安装 | |
local-apt | TCP | allow | 5080 | 离线环境安装 | |
rpcbind | TCP | allow | 111 | 使用 NFS 作为持久化存储 | |
ipip | IPIP | allow | Calico 需要允许 IPIP 协议 |
服务角色规划
节点角色说明
k8s 架构分为几种角色:
- Master 节点:Master是Kubernetes 的主节点。Master节点上面主要由四个模块组成:etcd、api server、controller manager、scheduler,高可用架构一般建议在3个节点,可以和etcd 融合部署。Master节点上不运行任何用户容器。
- Etcd节点:etcd 节点在集群规模大于25个节点的情况下,可以采用单独节点,推介采用SSD存储作为Etcd 存储数据。节点规模小可以采用和Master 节点融合部署。
- Node 节点:Node在每个节点上运行,为用户业务 Pod 提供 Kubernetes 运行环境。Node 节点一般包含:kube-proxy 、kubelet 两个组件。
- 镜像仓库节点: 推荐客户采购商用镜像仓库解决方案,如无镜像仓库方案,青云为客户提供主备镜像仓库。
- 集群内部负载节点:只作为集群内部管理, 主要用途为 K8S API 、KubeSphere API和对外暴露KubeSphere Web 界面,客户现有环境中有可用的负载均衡服务,比如硬件的 F5,或者某个公有云、私有云的 slb,尽量和客户申请使用他们的服务。如客户无LB节点,青云为客户提供haproxy + keepalive 节点配置软LB。
Master 节点包含服务:
服务 | 最小规模 | 用途 |
Master 节点 | 3 节点 | |
kube-apiserver | 3 副本 | Kubernetes REST API |
kube-controller-manager | 3 副本 | Kubernetes 管理控制中心 |
kube-scheduler | 3 副本 | Kubernetes 调度器,负责将 Pods 指派到节点上。 |
etcd | 3 副本 | 键值型数据库 主要用来记录K8s上所有资源的状态。 |
Node 节点包含服务
服务 | 最小规模 | 用途 |
Node 节点 | 3 节点 | |
coredns | 2 副本 | 高性能、易扩展的DNS服务端,用于集群内部service 域名访问等() |
nodelocaldns | 节点数(daemonset 方式运行) | 在集群的上运行一个dnsCache daemonset来提高clusterDNS性能和可靠性 |
kube-proxy | 节点数(daemonset 方式运行) | Kubernetes Service的通信与负载均衡机制的重要组件 |
kubelet | 节点(节点服务) | 每个节点上的主要的“节点代理”,每个节点都会启动 kubelet进程,用来处理 Master 节点下发到本节点的任务。 |
docker | 节点(节点服务) | 容器引擎 |
calico-kube-controller | 1 | Calico 控制节点 |
Calico-cni | 节点数(daemonset方式运行) | CNI插件,用于容器之间网络通信等。 |
镜像仓库节点
服务 | 最小规模 | 推荐 | 用途 | 架构 |
Harbor | 2 | 镜像仓库 | 主备架构,主对外提供服务。 | |
Harbor (kubesphere)可选 | 1 | 2 | 镜像仓库(用于保存kubesphere 系统镜像) | 推荐有条件的客户对kubesphere 的镜像仓库和用户业务仓库进行分离。如不能提供,可以将kubesphere 镜像推送到客户业务镜像仓库。 |
LB 负载均衡节点
服务 | 最小规模 | 推荐 | 用途 | 架构 |
Haproxy + keepalive (集群内部通信) | 2 + | 3+节点 | 集群内部负载均衡 | |
业务LB | 客户购买商用LB或采用QingCloud IaaS LB | 业务应用LB | 客户现有环境中有可用的负载均衡服务,比如硬件的 F5,或者某个公有云、私有云的 slb。如客户没有,青云不提供业务LB。 |
集群配比参考
Master 节点配置推荐:
Nodes 数量 | Master 数量 | Master 配置 | 数据盘挂载大小 |
25 | 3 | 8C16G | 500G以上 |
100 | 5 | 16C32G | 800G 以上 |
250 | 5-7 | 16C64G | 1T 以上 |
Etcd 节点配置推荐:
在25节点以内,可以将etcd 节点和Master 融合部署:
Nodes 数量 | Etcd 数量 | Etcd 配置 | 数据盘挂载SSD 大小 |
25 | 3 | 4核8 G | 200G |
100 | 3-5 | 8 核16G | 500G |
250 | 5-7 | 8 核 32G | 1T |
网络CIDR 配置推荐(以Calico 为例):
Nodes 数量 | KubePodsCIDR | KubeServiceCIDR | 备注 |
25 | 10.233.0.0/18 | 10.233.0.0/18 | 可提供16K IPs |
100 | 10.233.0.0/16 | 10.233.0.0/16 | 可提供64K IPs |
250 | 10.0.0.0/14 | 10.128.0.0/14 | 可提供256K IPs |
日志组件
Nodes 数量 | 是否外置 | 推荐 | 备注 |
5 | 内置 | Es master 1副本 es data 2副本 | |
10 | 内置 | Es master 3副本 es data 3副本 | 具体可参考客户日志量和集群存储IO和网络能力,决定是否需要外置。 |
10节点以上 | 外置 | eck 或购买日志易等商业日志方案 | |
日志保存期限 | 7-15天 | 如客户选要大量保存日志或导出日志,建议选择将日志导出或采用大规模日志方案。 |
集群配置推荐
选项 | 可选 | 推荐 | |
Kubesphere | 3.0.0,3.1.0 | 3.1.0 | |
网络代理模式 | IPvs,Iptables | ipvs | |
CNI网络插件 | Calico,Flannel | calico | 50个节点以上calico建议开启ypha |
ContainerRuntime | Docker CE 19.03 Docker CE 20.10 | Docker CE 20.10 | |
Kubernetes | 1.17.9 1.18.6 1.19.8 | 1.18.6 | |
Harbor 镜像仓库 | 1.7.x 1.9.x 2.1.x | 2.1.x | 2.1.x 兼容Dragonfly,部署建议打开helm 仓库 |
节点pod 最大数量 | 240以下 | 240以下 | |
KubeSphere组件
Kubesphere 组件在后期可以通过编辑配置文件来打开。
组件 | 名称 | 用途 | 备注 |
日志系统 | logging | 集群日志记录 | |
审计日志 | auditing | 记录了用户、管理人员或系统其他组件相关的活动 | |
Devops | devops | 基于 Jenkins 的 KubeSphere DevOps 系统是专为 Kubernetes 中的 CI/CD 工作流设计的 | |
事件 | events | 事件系统,记录和跟踪集群内部发生的事件。 | |
监控告警系统 | monitoring | 集群告警监控系统 | |
应用商店 | openpitrix | 基于 Helm 的应用商店,用于应用生命周期管理。 | |
服务网格 | servicemesh | 服务网格基于 Istio,将微服务治理和流量管理可视化。 | |
网络策略 | networkpolicy | 通过网络策略,用户可以在集群内实现网络隔离。 | |
边缘计算 | kubeedge | 一个开源系统,用于将容器化应用程序编排功能扩展到边缘的主机 | 3.1 以上支持 |
集群规模参考示例
场景一:最小规模
节点数量:3台Master + 3 Node
配置考虑:3Master 8核16G, Node 16核32G 。
未开启的功能(根据需求):devops,istio, kubeedge
场景二:次小规模
节点数量:3台Master节点 + 25台Nodes以内
配置考虑:3 台Master 8核16G ,25台Nodes 16核32G
未开启的功能(根据需求):devops,微服务
需要外置组件:日志
场景三:中型规模
节点数量:5台Master 节点 + 3台Etcd 节点 + 100台Node 节点
配置考虑:5台Master 节点考虑16核32G。
3 台Etcd 节点8核16G 数据盘挂载SSD。
未开启的功能(根据需求):devops,istio, kubeedge
需要外置组件: 日志
场景四:大型规模
节点数量:5台Master 节点 + 5台Etcd节点 + 250台Node节点
配置考虑:5台Master 节点考虑16核32G。
5台Etcd 节点8核16G 数据盘挂载SSD。
未开启的功能(根据需求):devops,istio, kubeedge
场景五:多集群模式
多集群联邦模式的架构,假设客户下有需要搭建两套kubesphere环境,两套环境需要实现统一控制台登录,应用有考虑多集群规模部署或开发、生产环境进行隔离。考虑单独搭建一套Hosts 管理集群将两套集群进行纳管,两套业务集群角色规划为Member。
部署多集群模式,确保hosts 和member 集群纳管完成后在交付给客户,避免Member 集群产生租户、集群数据,需要进行集群数据、租户信息迁移等。
角色规划如下:
Hosts 集群:后续根据集群Member 数量来进行扩容Hosts 节点
节点数量:3台Master节点 + 2台Nodes
配置考虑:3 台Master 8核16G ,2台Nodes 8核16G
未开启的功能(根据需求):devops,微服务
多集群联邦中的 Member 集群配置可参考前面
特殊组件说明
部署KubeSphere 节点达到一点规模,内置的组件会产生性能问题,建议规模较大的客户选购商用的方案。
名称 | 集群规模 | 建议说明 | |
日志组件 | 内置 | 15 Node 以内 | 客户对日志保存期限无特殊要求,保存7-15天足够,每天日志量在100G 以下,可持久化存储能支持日志读写要求 |
外置 | 15 Node 以上 | 对日志保存有要求,如需要保存半年以上,每天产生日志量在100G以上。建议采用青云IaaS Appcenter ELK或采购商用日志方案。 | |
镜像仓库 | 青云部署 | 默认部署为主备方案,因涉及安装、日后维护等,需增加人天评估。 | |
商用仓库方案 | 在大规模集群模式下,客户对仓库有特殊需求,如:多仓库推送同步、P2P 方案等。 | ||
负载均衡 | 集群内部通信 | 客户有条件下,建议如:青云IaaS LB、 F5、其他厂家的SLB。 客户不能提供的条件下,青云部署KeepAlive + Haproxy | |
业务LB |
|
特别说明:微服务拆分、为辅架构咨询、devops 流水线培训、流水线制作和迁移属于咨询范围,需单独进行评估人天和收费。
集群部署最佳实践
单集群部署
单集群: Master节点: 3台 8核16G 虚拟机,系统盘200G , 数据盘500G Node节点:8台 16 核 32 G 虚拟机,系统盘300G,数据盘500G LB 节点挂载EIP,集群内部采用私有网络VIP 通信。 镜像仓库节点: 以Appcenter Harbor 部署,并挂载QingStor对象存储。 日志节点: 以Appcenter ELK 部署,存储类型选择企业级分布式SAN(NeonSan) 可持久化数据卷: NeonSan、 QingCloud 块存储。 | |
拓扑示意图: |
多集群联邦最佳实践
Hosts 集群: Master管理节点: 3台 8核16G 虚拟机,系统盘200G , 数据盘500G Node节点:3 台 16 核 32 G 虚拟机,系统盘300G,数据盘500G LB 节点挂载EIP,集群内部采用私有网络VIP 通信。 可持久化数据卷: NeonSan、 QingCloud 块存储。 日志节点和Etcd 节点内置。 Member1 开发测试集群: Master节点: 3台 8核16G 虚拟机,系统盘200G , 数据盘500G Node节点:12台 16 核 32 G 虚拟机,系统盘300G,数据盘500G LB 节点挂载EIP(可选),集群内部采用私有网络VIP 通信。 镜像仓库节点: 以Appcenter Harbor 部署,并挂载QingStor对象存储。 可持久化数据卷: NeonSan、 QingCloud 块存储。 日志节点和Etcd 节点内置。 Member2 生产集群: Master节点: 3台 8核16G 虚拟机,系统盘200G , 数据盘500G Etcd 节点: 3台 8核16 G 以AppCenter Etcd 超高性能型部署。 Node节点:25台 16 核 32 G 虚拟机,系统盘300G,数据盘1TB GPU 节点: 8台48核 128G 虚拟机,系统盘300G, 数据盘1TB,GPU卡: Nvidia tesla T4 * 8,cpu 架构选择Broadwell。 LB 节点挂载EIP(可选),集群内部采用私有网络VIP 通信。 镜像仓库节点: 以Appcenter Harbor 部署,并挂载QingStor对象存储。 日志节点: 以Appcenter ELK 部署,存储类型选择企业级分布式SAN(NeonSan) 可持久化数据卷: NeonSan、 QingCloud 块存储。 用户业务LB: 通过青云插件cloud-controller-manager 进行对接IaaS 的负载均衡,实现发布应用。 部署架构为QingCloud 产品最佳推荐,如客户未使用QingCloud 云产品,可根据具体场景进行推荐选型。 如:业务LB 可推荐客户选用F5 硬件产品等。 集群规模达到25节点以上,推荐客户采购商用的日志系统等。 | |
拓扑示意图: |
Kubesphere 集群中,所有 pod 都应该设置 limit 和request 数值,否则资源利用率统计很不准。资源不够的时候,没有设置 request 和 limit 的 pod 最先被驱逐,最后是 request=limit 的 pod 被驱逐。集群在使用中,有的资源允许压缩使用,有的不成。CPU、网络I/O可以;内存和磁盘空间不建议。但很多时候 pod 并不是同时使用,因此稍有有一些超额分配是可以的,可以在 limitrange 中的 maxLimitRequestRatio 设置百分比。当然,这个百分比要通过测试实现。也就是说,当资源不够的时候,pod 会被驱逐,根据你能接受的驱 逐pod的 频率,设置评定当时的超分率。当然,超额使用的设置还和每个 namespace 的 qouta 的设置有关。从集群角度看,K8s 整体的 qouta 可以大于整体的可提资源。
K8s 节点会预留资源,主要分为两部分 Kube-reserved, system-reserved。当资源利用率超过的可分配资源时(开始侵占预留资源),K8s 开始驱逐内存。K8s 驱逐 pod 的阈值可以设置,也就是说,当节点的资源少于多少的时候,开始驱逐 pod。
容量规划主要是对比 request 资源和实际使用率。根据实际使用率的上浮下浮 20%,我们设定资源的上限、下限预估值。低估造成资源不够,高估造成资源浪费。如果出现高估,可以减少 request,limit 不变,让 request< limit。如果出现了低估,那降低 limit,让 request=limit。
扩容依据
当节点资源使用率超过70% ,建议增加kubesphere 集群节点或进行节点扩容。
平台规划信息收集
名称 | 选项 | 描述 | 规划 | 备注说明 |
多集群模式 | 是否为多集群模式 | 是,1 Hosts 集群 3master 3node | 多集群模式,需要单独划分一个hosts 集群做管理,最小为3master +2 node 此集群不做业务使用。 | |
CPU架构平台 | arm/amd | AMD X86_64 | Arm 架构需要评估。 | |
是否可以连接互联网 | 否,全部为网络隔离内网环境 | |||
操作系统kernel 版本 | 操作系统版本和kernel版本 | Ubuntu 18.04.3/4.15.0-55-generic | 支持 | |
容器服务地址 | kube service addresses | 10.43.0.0/16 | ||
容器pod地址 | kube_pods_subnet | 10.42.0.0/16 | ||
用户多登录 | false | |||
k8s代理模式 | kube_proxy_mode | ipvs | ipvs, iptables | |
dns 模式 | dns_mode | coredns | kubedns, coredns | |
网络插件 | kube_network_plugin | calico | 只支持calico 和flannel | |
部署组件 | 开启kubesphere 组件 | servicemesh\openpitrix\notification\networkpolicy\monitoring\metrics_server\logging\events | kubesphere 开启的组件 | |
告警邮箱 | 是否配置邮箱告警和告警策略 | MTP 服务器地址:smtp.kubesphere.com | 用户提供邮箱告警服务器配置,策略客户自己自定义配置。 | |
DNS服务器 | DNS 服务器 | 88.10.35.107 | 需提供可用的dns 服务 | |
NTP 同步服务器 | ntp 时间同步服务器 | 88.10.35.107 | 客户提前配置好在宿主机 | |
镜像仓库 | 镜像仓库使用软件和地址 | Harbor:https://repos.xxxxx.com:5000 | harbor nexus 等镜像仓库地址 | |
可持久化存储 | 可持久化使用软件和地址 | NFS:172.31.199.5:/mnt/kube_data | 本地盘不建议生产使用,存储确认需要支持k8s 官方csi 标准。 | |
负载均衡地址 | 负载均衡软件和地址 | F5 88.10.35.253 | 负载均衡软件和地址 | |
GPU | 是否需要支持GPU | 是, 每台节点 显卡nvidia Tesla T4 * 8 | ||
底层平台 | 底层平台 | QingCloud IaaS虚拟化平台 | 物理机、虚拟化平台:qingcloud、vmware、openstack等 | |
集群名称 | k8s 集群名称 | clusterName | cluster.local | 此参数暂时不支持修改,修改后,istio 会出现问题 |
安装方式 | 在线安装/离线安装/QKE | 离线安装 |
安全规范
- 如果平台直接暴露在公网环境下,遵循最小化开放原则,用白名单开放需要的网络连接;
- 禁用密码登陆,尤其是暴露在公网上的服务器,为便于维护,内网服务器只放开1-2台允许密码登陆。
- 如有条件,建议将所有服务器纳入堡垒机管理。
- 客户要求的其它安全规范。