• k8s集群部署方案

	二进制部署	kubeadmin	第三方工具
			kubespray	minikube	sealos
使用场景： （单master或多master）	单/多	单/多	单/多	单	单/多
使用场景	生产环境	生产环境	生产环境	个人测试环境	生产环境
系统要求	支持大多数 Linux 发行版，例如：Ubuntu、Debian、CentOS、Rocky linux。	支持大多数 Linux 发行版，例如：Ubuntu、Debian、CentOS、Rocky linux。	支持大多数 Linux 发行版，例如：Ubuntu、Debian、CentOS、Rocky linux。	Windows、MacOS 支持大多数 Linux 发行版，例如：Ubuntu、Debian、CentOS、Rocky linux。	支持大多数 Linux 发行版，例如：Ubuntu、Debian、CentOS、Rocky linux。
部署环境	1.系统初始化	1.系统初始化 2.安装docker 3.安装网络组件 4.多master：安装 haproxy+keepalived 需额外VIP+端口	需安装 Python+ansible		1.域名，非真实域名需手动配置hosts解析
部署时长	约12小时	约90分钟	约20分钟	约3分钟	约3分钟
部署技能要求	证书签发，k8s	Docker、Haproxy、keepalived	Ansible-playbook	minikube	sealos
部署难度	最高	高	较高	低	一般

系统初始化：

# 1、关闭防火墙

systemctl stop firewalld && systemctl disable firewalld

# 2、禁用selinux

setenforce 0 #临时关闭selinux

vim /etc/selinux/config #永久关闭selinux

SELINUX=disabled

# 3、关闭swap分区（必须，因为k8s官网要求）

swapoff -a #禁用所有swap交换分区

vim /etc/fstab #永久禁用swap,删除或注释掉/etc/fstab里的swap设备的挂载命令即可

#/dev/mapper/centos-swap swap         swap    defaults        0 0

# 4、设置主机名并写入配置文件

# 5、时间同步

yum install chrony -y && systemctl enable --now chronyd

# 6、将桥接的IPv4流量传递到iptables的链

cat >> /etc/sysctl.d/k8s.conf <<EOF

net.bridge.bridge-nf-call-ip6tables=1

net.bridge.bridge-nf-call-iptables=1

net.ipv4.ip_forward=1

vm.swappiness=0

EOF

sysctl -p

• k8s集群高可用方案

2.1、VIP方式

2.1.1、keepalived+haproxy方案

HAProxy的优点：专业的代理服务器

1、HAProxy是支持虚拟主机的，可以工作在4、7层(支持多网段)；

2、能够补充Nginx的一些缺点比如Session的保持，Cookie的引导等工作；

3、稳定性：经过严格测试和生产环境验证，具有极高的稳定性；

4、本身仅仅就只是一款负载均衡软件；单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度，在并发处理上也是优于Nginx的；

5、负载均衡算法：HAProxy的算法较多，达到8种。

7、双机热备方案：自身有完整的双机热备方案，Haproxy+ Keepalived。

8、配置简单：配置简单，不需要太多接触，减少了人为出错的几率。

缺点：

1、不支持正则处理：不能实现动静分离。

2、实施配置复杂：对于大型网站，实施配置可能较为复杂，维护成本相对较高。

3、对网络依赖较大：对网络的依赖比较大，稳定性很高。

4、应用范围限制：主要应用于对所有应用做负载均衡，但有些特殊应用可能不支持。

2.1.2、kube-vip方式

优点：Kubernetes 原生的 HA 负载均衡，并能提供网络功能

1、VIP 地址可以是 IPv4 或 IPv6

2、带有 ARP（第 2 层）或 BGP（第 3 层）的控制平面

3、使用领导选举或 raft 控制平面

4、带有 kubeadm（静态 Pod）的控制平面 HA

5、使用 ARP 领导者选举的 Service LoadBalancer（第 2 层）

6、通过 BGP 使用多个节点的 Service LoadBalancer

7、每个命名空间或全局的 Service LoadBalancer 地址池

8、Service LoadBalancer 地址通过 UPNP 暴露给网关

缺点：

1. 需要运行在k8s master节点里面，配置复杂；
2. 需要在k8s集群初始化之前配置；

2.2、域名方式

DNS域名，一般结合nginx使用

优点：

1、配置简单，成本低，将负载均衡的工作交给了DNS服务器；

2、相比与其他负载均衡策略，减少了网络链路层数，网络花销低。

缺点：

1、DNS会有一定的缓存时间，故障后切换时间长；

2、不能及时反映服务器的当前运行状态，对于后端服务器状态的感知能力较弱。

• k8s集群网络方案

3.1、Flanel网络

Flannel默认模式VXLAN跨机通信原理

1. 技术基础：Flannel主要依赖于UDP或VXLAN隧道进行节点间通信，它是一个轻量级的网络解决方案；

2. 性能：虽然Flannel通常提供良好的性能，但与Calico相比，它可能在某些情况下有更高的网络延迟；

3. 安全性和策略：Flannel默认不提供复杂的网络策略，但可以通过集成其他工具（如Cilium）来增强安全性；

4. 简单性：Flannel设计为易于部署和管理，特别适合小型或中型集群，或者对网络要求不高的环境；

5. 资源消耗：相比Calico，Flannel对系统资源的需求较低，更适合资源有限的环境；

6. 网络模型：Flannel支持Overlay模式（如VXLAN和UDP），以及Host-gateway模式，默认使用的是UDP封装。

3.2、Colico网络

Colico默认模式IPIP

1. 技术基础：Calico依赖于BGP（Border Gateway Protocol）路由协议来实现节点间通信，可以支持大规模的集群；

2. 性能：由于使用了IP-in-IP或VXLAN隧道以及基于路由的策略，Calico在大多数情况下提供了较高的网络性能；

3. 安全性和策略：Calico提供强大的网络安全策略，允许用户细粒度地控制容器间的流量，这在大型企业环境中非常有用；

4. 复杂性：由于其功能强大，Calico的配置可能比Flannel更复杂。对于没有经验的管理员来说，可能需要更多的时间来理解和管理；

5. 资源消耗：Calico需要更多的计算和内存资源来运行，特别是在处理大量网络规则时；

6. 网络模型：Calico支持多种网络模型，包括 HostGW、Overlay（如IPIP和VXLAN）以及直接路由模式。

两种网络各模式性能对比：

Flannel模式	效率	Calico模式
UDP	性能较差，封包解包涉及到多次用户态和内核态交互	无
VXLAN（默认）	性能较好，封包解包在内核态实现，内核转发数据，flanneld负责动态配置ARP和FDB（转发数据库）表项更新	IP IP（默认）
Host-gw	性能最好，不需要再次封包，正常发包，目的容器所在的主机充当网关，flanneld 负责主机上路由表的刷新	BGP

• k8s存储方案：

4.1、EmptyDir

一种临时性的卷，它的生命周期与 Pod 相同。emptyDir卷是在Pod被调度到节点上时创建的，并且在 Pod 被删除时一并删除。emptyDir 卷通常用于在容器之间共享文件或者缓存数据。

4.2、HostPath

一种本地存储卷，可以将宿主机目录映射到容器中，删除Pod后宿主机卷不会跟随删除，但是调用到不通节点，卷内容会不一致(MySQL数据在Node1节点存储,删除MySQL Pod后调度到Node2上了，导致数据不一致)。

4.3、NFS

一种共享卷，需要依赖于NFS服务端，所有Pod共享NFS卷内容，不需要考虑Pod调度在不同节点导致数据不一致问题，但是NFS基于网络传输，会占用带宽。

4.4、PVC

用来实现持久化存储，可以将存储资源独立出来，方便管理和共享。

4.4.1、静态

管理员手动创建PV对象，并将其绑定到一个具体的存储后端上，然后Pod可以通过PVC（Persistent Volume Claim）请求绑定到该PV上。

4.4.2、动态

管理员通过StorageClass定义一组存储后端，然后Pod可以通过PVC请求绑定到该StorageClass上，K8s会自动创建一个PV对象并将其绑定到一个可用的存储后端上。

A、openebs方案

1、对于本地卷：

OpenEBS 可以在 Hostpaths 上创建持久卷或使用子目录，或者使用本地附加的存储或稀疏文件，或者在现有的 LVM 或 ZFS 堆栈上。

本地卷直接挂载到 Stateful Pod 中，不会增加数据路径中 OpenEBS 的任何开销，从而减少延迟。

OpenEBS 为本地卷提供了额外的工具，用于监控、备份/恢复、灾难恢复、由 LVM 或 ZFS 堆栈支持的快照、基于容量的计划等。

2、对于复制卷：

OpenEBS 复制存储为每个持久卷创建一个可通过 TCP 访问的 NVMe 目标。

有状态 Pod 将数据写入 NVMe-TCP 目标，该目标将数据同步复制到集群中的多个节点。OpenEBS 引擎本身部署为 pod，并由 Kubernetes 编排。当运行有状态 Pod 的节点发生故障时，该 Pod 将被重新调度到集群中的另一个节点，OpenEBS 使用其他节点上的可用数据副本提供对数据的访问。

OpenEBS Replicated Storage 的设计目标是以持久性和性能为目标。它可以有效地管理计算（大页面和内核）和存储（NVMe 驱动器），以提供快速块存储。

B、csi-driver-nfs方案

优点：

1. 将现有的 NFS 服务器通过持久卷声明来支持 Kubernetes 持久卷的动态分配
2. 支持 NFSv3 和 NFSv4 协议
3. 支持快照（Snapshot）和卷克隆（Volume cloning）
4. 支持 fsGroupPolicy，可以在 Pod 中设置 fsGroup
5. 支持多种参数设置，包括 mountOptions，server，share，subPath，readOnly 等

缺点：

1、不保证预配的存储。您可以分配超过 NFS 共享的总大小。共享也可能没有足够的存储空间来实际容纳请求。

2、不强制执行预置的存储限制。无论预配的大小如何，应用程序都可以扩展以使用所有可用存储。

3、目前不支持任何形式的存储大小调整/扩展操作

目前主流存储方案对比：

功能特性		ROOK Ceph	OpenEBS	csi-driver-nfs
是否开源		是	部分	是
商业支持		本土Ceph商业化厂商	DataCore (中国本土无支持)	无
融合部署资源占用		磁盘越多，OSD消耗越大	Volume越多，消耗越大	Volume越多，消耗越大
存储访问模式支持		块、文件、对象	块、文件	块
高可用与数据保护 主要特性	节点内部	支持	不支持	不支持
	跨节点	副本	副本	无
	备份与容灾	支持	支持，通过Velero实现	支持，通过Velero实现
容器编排平台支持		任何CNCF认证的K8s发行版，版本需要v1.21以上	任何CNCF认证的K8s发行版，版本需要v1.18以上	任何CNCF认证的K8s发行版，版本需要v1.21以上
运维难度		高	中	低

• k8s集群访问方案

5.1、集群内相互访问

5.1.1、PodIP访问

每个 Pod 都会被分配一个 IP，Pod 之间可以通过 IP 直接访问，但 Pod 重启后，该 IP 会变化，并且无法对 PodB 多个服务同时访问

5.1.2、Service访问

DNS + ClusterIP，利用 K8S 的 DNS 和 Service，将 PodB 处理为 Service，例如叫做 SerB，此时 PodA 可直接访问 SerB 来实现访问，K8S 的 DNS 会将 SerB 解析到对应的 ClusterIP，并实现负载均衡

5.1.3、HeadlessService访问

将 PodC 处理为 HeadlessService, PodA 访问 HeadlessService 时，会拿到 PodC 的列表，然后自己进行负载均衡，例如指定访问其中的一个 Pod，此负载均衡由 PodA 自行控制。

5.2、集群内部访问集群外部

5.2.1、直接访问

直接访问外部服务的 IP 和端口

5.2.2、Service 访问

在集群中定义一个 ServiceMySQL，然后定义一个相同的 Endpoint ServiceMysql, Endpoint 中指定的是外部 MySQL 的具体地址，此时 K8S 的 DNS 此时会将 ServiceMysql 解析到 Endpoint 地址，即实现访问。若外部 MySQL 地址如果有变化，修改 ServiceMysql 的 Endpoint 地址即可；对于客户端 PodA 来说，跟访问内部 Service 没有区别。

5.3、集群外部访问集群内部

5.3.1、NodePort

通过NodePort的方式会在所有的Node节点上映射一个端口，端口范围默认是30000-32767。然后用户通过任意主机+映射端口来访问集群内部。

优点：

实现方式比较简单，操作简便

缺点：

1. 映射的端口太多不好管理，太多端口开放降低安全性；
2. 每一个端口只能提供一种服务；
3. 生成的iptables规则也很多；
4. 没有负载均衡。

5.3.2、LoadBanlancer

Load Balancer服务暴露服务非常直接，直接把服务暴露到Internet，通往指定端口的流量都会被转发到对于的服务，它没有过滤条件、没有规则等。

优点：

1、统一固定入口IP

2、流量分发负载均衡

缺点：

1. 每个LoadBalancer都需要一个固定的IP
2. 没有过滤条件、没有规则，安全性差
3. 非常依赖云产商的支持

5.3.3、Ingress

Ingress本身不提供服务，它依赖Ingress Controller，Ingress Controller以Pod的形式部署在Kubernetes集群内，实质上我们无法从外面直接访问，依然要将其暴露出来。Ingress的实现方式更智能、更友好，相对的配置就略微复杂，它一个IP可以暴露多个应用，支持同域名不同uri，支持证书等功能。

目前Ingress暴露集群内服务的Ingres Controller常见的有：

Nginx Ingress

Traefik Ingress

Istio Ingress

常用ingress对比

	NGINX Ingress	Traefik	Istio Ingress
协议	http/https、http2、grpc、tcp/udp	http/https、http2、grpc、tcp、tcp+tls	http/https、http2、grpc、tcp、tcp+tls、mongo、mysql、redis
基础平台	nginx/nginx plus	traefik	envoy
路由匹配	Host、path	Host、path、headers、query、path prefix、method	Host、path、method、headers
命名空间支持	-	共用或指定命名空间	共用或指定命名空间
部署策略	-	金丝雀部署 蓝绿部署 灰度部署	金丝雀部署 蓝绿部署 灰度部署 根据header白名单
upstream探测	重试、超时、心跳探测	重试、超时、心跳探测、熔断	重试、超时、心跳探测、熔断
负载均衡算法	RR、会话保持、最小连接、最短时间、一致性hash	WRR、动态RR、 会话保持	RR、会话保持、一致性hash、maglev负载均衡
鉴权方式	-	basic auth、auth-url、external auth	Basic、external auth、Oauth、OpenID
JWT	-	+	+
DDOS防护能力	rate-limit	limit-conn、limit-req、ip-writelist	limit-req、ip-writelist
全链路跟踪	-	+	+
协议转换	-	grpc	grpc、mongo、mysql、redis

• k8s集群监控方案

6.1、Prometheus监控

优点：

1、高度可扩展性：Prometheus 是一个高度可扩展的监控系统，可以轻松地添加更多的监控对象和指标。

2、灵活性：Prometheus 提供了丰富的查询语言和灵活的数据模型，可以根据需要进行自定义监控。

3、易于部署和维护：Prometheus 的部署和配置相对简单，维护成本较低。

4、社区支持：Prometheus 是一个开源项目，拥有活跃的社区支持和开发者社区，提供丰富的文档和资源。

缺点：

1、学习曲线陡峭：对于新手来说，学习 Prometheus 的查询语言和数据模型可能需要一定的时间和精力。

2、存储容量限制：Prometheus 使用本地存储来存储监控数据，可能会受到存储容量的限制，无法长期保存大量的监控数据。

3、不适用于大规模监控：虽然 Prometheus 支持高度可扩展性，但在大规模监控场景下可能会面临性能瓶颈。

4、缺乏一些高级功能：相比于一些商业监控解决方案，Prometheus 可能缺乏一些高级功能和扩展性。

监控指标	具体实现	举例
Pod性能	cAdvisor	容器CPU，内存利用率
Node性能	Node-exporter	节点CPU，内存利用率
K8S资源对象	Kube-state-metrics	Pod/Deployment/Service

6.2、Alertmanager告警

优点：

1、集成 Prometheus：Alertmanager 可以直接集成到 Prometheus 监控系统中，无需额外的脚本或服务。

2、通知路由：Alertmanager 支持复杂的通知路由策略，例如分组、混杂和静默规则。

通知方式多样：支持各种通知渠道，如电子邮件、短信、微信、钉钉等。

3、可扩展性：Alertmanager 是分布式和可扩展的，可以通过服务发现或静态配置添加更多的实例。

4、高可用性：运行多个 Alertmanager 实例并使用负载均衡和集群服务可以提供高可用性。

缺点：

1、配置复杂：Alertmanager 配置可能相当复杂，特别是在涉及通知路由和组的情况下。

2、通知可靠性：如果通知渠道出现问题或者网络故障，Alertmanager 不能保证所有的通知都能成功发出。

3、安全性：缺乏对通知载荷的加密或其他安全措施可能会导致安全隐患。

4、监控不充分：缺乏对 Alertmanager 本身性能和可用性的监控，可能会导致问题发现晚或者未发现。

5、维护成本：需要有专业知识的人来维护 Alertmanager 的配置和性能优化。

6.3、Grafana展示

优点：

1、界面友好：Grafana提供了直观和易于使用的用户界面，使用户能够轻松创建和定制各种仪表盘和图表。

3、多数据源支持：Grafana支持多种数据源，包括InfluxDB、Prometheus、Elasticsearch等，使用户能够从不同的数据源中获取数据，并将其可视化。

4、多种可视化选项：Grafana提供了丰富的可视化选项，包括折线图、柱状图、饼图等，用户可以根据自己的需求选择适合的图表类型。

5、插件生态系统：Grafana拥有丰富的插件生态系统，用户可以根据自己的需求安装和使用各种插件，扩展Grafana的功能。

6、跨平台支持：Grafana可以运行在多个操作系统上，包括Windows、Linux和MacOS，用户可以根据自己的需求选择适合的平台。

缺点：

1、学习曲线较陡：虽然Grafana具有友好的界面，但对于初学者来说，学习和掌握其各种功能可能需要一定的时间和精力。

2、配置复杂：配置Grafana可能需要一些复杂的步骤和操作，特别是在设置和管理数据源时，可能需要进行一些额外的配置和调整。

3、部署和维护成本较高：由于Grafana涉及到与其他数据源的集成和配置，所以在部署和维护Grafana时可能需要一些额外的成本和工作。

4、功能相对局限：尽管Grafana提供了丰富的可视化选项，但相比其他专业的商业数据可视化工具，其功能可能相对有限，特别是在高级分析和可视化方面。

• k8s集群日志方案

7.1、ELK日志系统：

优点：

1、该工具是众所周知的，并且拥有庞大的社区。

2、非常广泛的平台支持。

3、Kibana中丰富的分析和可视化功能。

4、需要手动定义的警报规则，日志分析复杂。

缺点：

1、维护困难

2、在大型环境中，需要调整很多属性

3、大量的资源需求

4、某些功能需要付费

7.2、loki日志系统

优点：

1、大型的生态系统。

2、丰富的可视化功能。

3、由于未索引日志内容而提高了效率

缺点：

1、未对Kubernetes日志管理进行优化。

2、大量的手工操作。

3、缺少内容索引可能会限制搜索性能。

对比项	ELK方案	Loki方案
数据存储成本	官方数据是通常可以将数据压缩20%~30%，实测下来在某些场景下可以达到50%，使用DEFLATE压缩算法，最低可以降低超过70%	10倍的压缩比,5G数据输入 存储实际增长0.5G
数据查询成本	500条并发查询大概消耗不到一个cpu core	500条并发查询大概0.1个CPU
查询速度	十亿条数据规模的文本数据下（单条260B），包括关键词检索、范围检索、组合检索、模糊查询等都可以在秒级完成。	1.13G总数据量，查询30天内数据,耗时21.9秒
特定字段检索	支持	支持
分析能力	支持多种分析方法，包括聚合分析，ML，自定义分析器等；	过滤关键词式查询分析
采集方式	可以支持filebeat -> es的轻量化采集，也可以支持大规模采集	Promtail，大规模场景未验证
采集速度	单个日志文件采集速度约4MB/s，2W条/s。	单文本1.2MB/s
吞吐量	3台的ES集群，吞吐数据最高可以达到100MB/s	单台，3MB/s
监控告警	Filebeat和es都有监控接口。可以通过prometheus相应的exporter进行监控告警。	支持集群本身监控告警和日志监控告警。原生集成grafana
	对日志做监控告警需要ElasticAlert,ES支持高可用。Filebeat支持数据重传。
高可用	副本方式，需要3台	副本方式，需要3台
大数据组件支持	全部支持	全部支持
支持审计日志采集	支持	支持
可扩展性	可动态扩展	支持
Manager纳管难度	ES已纳管，filebeat/logstash/kibana已具备纳管条件。	目前不支持

• k8s多集群管理方案

8.1、Rancher平台

优点：

1、简化容器部署：Rancher通过全栈化一键部署应用、多种编排调度工具、多租户、多种基础架构的能力，简化了容器的部署过程，使得用户能够更高效地进行容器化部署和管理。

2、易用性：Rancher采用图形化方式，提供易用的Web管理界面，进一步降低了使用容器技术部署容器应用的难度。它支持单主机、多主机和云平台等多种部署模式，满足不同的应用场景和需求。

3、多集群管理：Rancher能够集中管理多个Kubernetes集群，无论这些集群位于云上还是本地数据中心，提高了管理的效率和便利性。

4、资源弹性分配：Rancher内置应用负载均衡器，支持资源弹性分配，当负载不足或过剩时，用户可以轻松地增加或减少“服务”中容器的实例数，实现应用系统的弹性扩容。

5、社区支持：Rancher拥有一个活跃的社区，提供了大量的资源和支持，帮助用户解决问题。开源软件的特点使得用户可以自由地使用和修改源代码，同时也能从社区的贡献中受益。

缺点：

1、K8S部署问题：由于国内网络和国外网络访问的问题，在国内部署K8S集群可能会遇到一些不便。

2、应用商店问题：Rancher官方认证和社区贡献的应用商店内容有限，应用不够丰富。个别应用部署后，可能无法通过相同的操作再部署同样的另一套应用。

3、学习成本较高：Rancher是一个相对复杂的工具，用户需要花费一些时间来学习和理解其使用方法和原理。

8.2、kuboard平台

Kuboard是一个基于Kubernetes的开源仪表盘工具，它提供了丰富的功能，可以帮助用户管理和监控Kubernetes集群

优点：

1、功能丰富：Kuboard提供了多种功能，包括集群监控、资源管理、日志查看、应用部署等，可以满足用户大部分的需求。

2、可视化界面：Kuboard提供了直观的可视化界面，用户可以通过图表和图形化展示来了解集群的状态和性能。

3、易于使用：Kuboard提供了简单易用的操作界面，用户可以通过简单的操作完成复杂的任务。

缺点：

1、实施难度较大：由于 Kuboard 是基于 Kubernetes 的弹性伸缩解决方案，需要对 Kubernetes 的架构和概念有一定的了解。

2、不太适用非Kubernetes用户:Kuboard是基于Kubernetes的，对于没有使用Kubernetes的用户来说，可能无法充分发挥其功能。

3、非订阅用户只能添加3个k8s集群，只能查看当天的审计日志。

8.3、Kubeoperator平台

优点：

1、简化 Kubernetes 管理：KubeOperator 提供直观的用户界面来管理 Kubernetes 集群。

2、安装快速：KubeOperator 提供快速的 Kubernetes 集群部署。

3、高可用性：KubeOperator 支持高可用部署。

4、易于维护：KubeOperator 是开源的，因此社区支持和维护。

5、支持多云：KubeOperator 支持多种公有云、私有云和混合云。

缺点：

1、资源要求高：KubeOperator 需要较高的硬件资源来运行。

2、依赖复杂：KubeOperator 依赖于 Kubernetes 和其他相关软件，安装和维护较为复杂。

3、文档和支持：相比于其他管理工具，KubeOperator 的文档和支持可能较少。

4、社区活跃度：相比于其他知名的 Kubernetes 管理工具，KubeOperator 的社区活跃度可能较低。

• K8s集群镜像仓库

9.1、Harbor

优点：

1、多用户管理和基于角色的访问控制：支持多用户环境，允许创建不同的用户和组织，并为他们分配不同的权限，确保了资源的安全隔离和管理的灵活性。

2、基于角色控制：用户与Docker镜像仓库通过"项目"进行组织管理，一个用户可以对多个镜像仓库在统一命名空间(projec)里有不同的权限。

3、图形化用户界面：用户可以通过浏览器来浏览，检索当前Docker镜像仓库，管理项目和命名空间。

4、审计管理：所有这怒地镜像仓库的错都可以被记录追溯，用于审计管理。

基于镜像的复制策略：镜像可以在多个Harbor实例之间进行复制。

5、支持LDAP认证：Harbor的用户授权可以使用已经存在的用户。

镜像删除和垃圾回收：image可以被删除并且回收image占用的空间。

6、简单的部署功能：harbor提供了online、offline安装，此外还提供了virtualappliance安装。

7、提供分层传输机制：优化网络传输，Docker镜像是分层的，提供识别分层传输的机制，以层的UUID为标识，确定传输的对象。

缺点：

1、性能限制：在某些情况下，Harbor可能会遇到I/O带宽较低和读写延迟较高的问题，这可能会影响大规模部署时的性能。

2、稳定性问题：尽管Harbor是一个成熟的产品，但在特定的环境和负载下，可能会遇到稳定性方面的挑战。

3、配置和维护复杂度：Harbor的配置和管理可能相对复杂，需要对Docker和Kubernetes有一定的了解，以便有效地部署和维护。

4、缺少认证机制：任何人都可以随意拉取及上传镜像，安全性缺失。

5、缺乏镜像清理机制：镜像可以push却不能删除，日积月累，占用空间会越来越大。

6、缺乏相应的扩展机制：Harbor可能缺乏必要的扩展性，这可能限制了其适应不断变化的需求的能力。

9.2、Nexus3

优点：

1、与Jenkins集成无缝，提供高质量的持续集成和持续部署体验；

2、支持复杂的安全策略，包括LDAP、RBAC等；

3、提供强大的REST API，方便与其他系统集成；

4、支持多节点部署，提供高可用性；

5、即可以存放镜像，也可以代理镜像源。

缺点：

1、相对Harbor，Nexus 3的部署和配置更复杂。

2、Nexus Repository Manager对系统资源的要求较高。

• 公司适合可行性方案

10.1、方案选型

项目	技术选型	版本选型	备注
K8s集群部署方案	Sealos	v4.3.7
K8s高可用方案	域名	v1.27.7	K8s集群版本
K8s网络方案	Calico	v3.27.3
K8s存储方案	Csi-driver-nfs	v4.4.0
K8s访问方案	Nginx-ingress	v4.1.0
K8s监控方案	prometheus	v2.46.0
	Altermanager	v0.26.0
	Grafana	v10.0.3
	Node-exporter	v1.7.0
	cAdVisor	v0.45.0
	kube-state-metrics	v2.4.2
K8s日志方案	Filebeat	v8.5.1
	Logstash	v8.5.1
	Kibana	v8.5.1
	Elasticsearch	v8.5.1
K8s多集群管理方案	kuboard	v3
K8s镜像仓库方案	Harbor/nexus3	v3.68.1

10.2、资源规划

组件		规格	限制
K8s master		4C8G100G
K8s node		均可	不超过1000node，每个node不超过110个pod
Prometheus监控	prometheus	2C8G1T	50台机器
	Altermanager	0.1C0.1G	50台机器
	Grafana	0.1C0.2G	50台机器
	Node-exporter	5C 2.5G	50台机器 (0.1C0.05G/台)
	cAdVisor	12.5C25.6G	50台机器 (0.25C0.512G/台)
	kube-state-metrics	0.1C0.15G	50台机器
ELK监控	Filebeat	5C6.4G	50台机器 (0.1C0.128G/台)
	Logstash	2C4G	50台机器
	Kibana	1C2G	50台机器
	Elasticsearch	4C8G1T	50台机器 (ES不超过32G内存)
K8s集群管理	Kuboard	1C1G10GB	50台机器
K8s镜像仓库	Nexus3	2C4G1T	50台机器

10.2、实施计划

1、获取sealos命令行工具

wget https://github.com/labring/sealos/releases/download/v4.3.7/sealos_4.3.7_linux_amd64.tar.gz && tar zxvf sealos_4.3.7_linux_amd64.tar.gz sealos && chmod +x sealos && mv sealos /usr/bin

2、部署k8s可用集群

sealos run registry.cn-shanghai.aliyuncs.com/labring/kubernetes-docker:v1.27.7 registry.cn-shanghai.aliyuncs.com/labring/helm:v3.14.0 registry.cn-shanghai.aliyuncs.com/labring/calico:3.27.3 \

     --masters 192.168.1.2,192.168.1.3,192.168.1.4 \

     --nodes 192.168.1.5,192.168.1.6 -p [your-ssh-passwd]

3、部署nfs存储插件

sealos run registry.cn-shanghai.aliyuncs.com/labring/csi-driver-nfs:v4.4.0

4、部署ingress-nginx插件

sealos run registry.cn-shanghai.aliyuncs.com/labring/ingress-nginx:4.1.0

5、部署Prometheus监控

sealos run registry.cn-shanghai.aliyuncs.com/labring/kube-prometheus-stack:v0.71.0

sealos run registry.cn-shanghai.aliyuncs.com/labring/kube-state-metrics:v2.4.2

sealos run registry.cn-shanghai.aliyuncs.com/labring/prometheus-node-exporter:v1.7.0

kubectl apply -f cadvisor.yaml

cat cadvisor.yaml

apiVersion: apps/v1

kind: DaemonSet

metadata:

  name: cadvisor

  namespace: monitor

spec:

  selector:

    matchLabels:

      app: cAdvisor

  template:

    metadata:

      labels:

        app: cAdvisor

    spec:

      tolerations:

        - effect: NoSchedule

          key: node-role.kubernetes.io/master

      hostNetwork: true

      restartPolicy: Always

      containers:

      - name: cadvisor

        image: harbor.magedu.net/baseimages/cadvisor:v0.45.0

        imagePullPolicy: IfNotPresent

        ports:

        - containerPort: 8080

        volumeMounts:

          - name: root

            mountPath: /rootfs

          - name: run

            mountPath: /var/run

          - name: sys

            mountPath: /sys

          - name: docker

            mountPath: /var/lib/containerd

      volumes:

      - name: root

        hostPath:

          path: /

      - name: run

        hostPath:

          path: /var/run

      - name: sys

        hostPath:

          path: /sys

      - name: docker

        hostPath:

          path: /var/lib/containerd

6、部署ELK监控

sealos run registry.cn-shanghai.aliyuncs.com/labring/eck-operator:v2.6.1

sealos run registry.cn-shanghai.aliyuncs.com/labring/filebeat:v8.5.1

7、部署k8s集群管理工具kuboard

sealos run registry.cn-shanghai.aliyuncs.com/labring/kuboard:v3

8、部署nexus3镜像仓库

docker run -d --name=nexus3 --restart=always -p 8081:8081 -p 8082:8082 -p 8083:8083 -v /usr/local/src/nexus-data:/nexus-data sonatype/nexus3