velero的使用​

文档：https://velero.io/

注意使用1.24的k8s​

1.25的k8s暂时会有coredns的pod起不来的问题，导致不能备份

kubectl get pod -A
kube-system        coredns-565d847f94-5b2wt                   0/1     CrashLoopBackOff   2271 (4m1s ago)   8d
kube-system        coredns-565d847f94-jtw9f                   0/1     CrashLoopBackOff   2271 (88s ago)    8d

以aws作为存储举例​

1、安装aws cli​

apt install awscli
aws configure  #登陆aws

创建bucket

BUCKET=<YOUR_BUCKET>
REGION=<YOUR_REGION>
aws s3api create-bucket \
    --bucket $BUCKET \
    --region $REGION \
    --create-bucket-configuration LocationConstraint=$REGION

2、安装velero​

wget https://github.com/vmware-tanzu/velero/releases/download/v1.9.2/velero-v1.9.2-linux-amd64.tar.gz
tar -xvf velero-v1.9.2-linux-amd64.tar.gz
mv velero-v1.9.2-linux-amd64/velero /usr/local/bin/

3、把aws作为备份存储​

创建一个credentials-velero文件

[default]
aws_access_key_id=<AWS_ACCESS_KEY_ID>
aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>

export BUCKET=xxxx
export REGION=xxxx
velero install \
    --provider aws \
    --plugins velero/velero-plugin-for-aws:v1.5.0 \
    --bucket $BUCKET \
    --backup-location-config region=$REGION \
    --snapshot-location-config region=$REGION \
    --secret-file ./credentials-velero

查看是否安装成功，availabe就是成功了

root@yyj-master1:/home/ubuntu# kubectl get pod -n velero
NAME                      READY   STATUS    RESTARTS   AGE
velero-7dd66cfb94-pbf47   1/1     Running   0          12m
root@yyj-k8s124-test-master1:/home/ubuntu# velero backup-location get
NAME      PROVIDER   BUCKET/PREFIX   PHASE       LAST VALIDATED                  ACCESS MODE   DEFAULT
default   aws        sealos-test     Available   2022-11-10 02:43:28 +0000 UTC   ReadWrite     true

4、Quick Start​

git clone https://github.com/vmware-tanzu/velero.git
cd velero

Basic example (without PersistentVolumes)​

1. Start the sample nginx app:

   kubectl apply -f examples/nginx-app/base.yaml
   

2. Create a backup:

   velero backup create nginx-backup --include-namespaces nginx-example
   

   然后bucket里面就出现backup

   

3. Simulate a disaster:

   kubectl delete namespaces nginx-example
   

   Wait for the namespace to be deleted.

4. Restore your lost resources:

   velero restore create --from-backup nginx-backup
   

5、集群备份​

每一个小时全部内容备份一次

velero schedule create full-cluster-backup --schedule="0 * * * *"

使用 multipass 虚拟出虚拟机然后基于 sealos 快速构建一主一从的 k8s 集群，​

前置条件​

1、安装好multipass 如果需要虚拟机把ip暴露出来，需要配置一下网桥 multipass配置教程

2、~/.ssh必要创建好，使用本地ssh来作为虚拟机的ssh

创建命令`ssh-keygen -t rsa` or `ssh-keygen -t rsa -C "xxxxx@xxx.com"`

使用教程​

./start_vm.sh 
./start_vm.sh name #指定集群名字

脚本内容

#!/usr/bin/env sh
# requirement
# ~/.ssh must have id_rsa.pub,id_rsa

# Usage:
# - sh start_vm.sh
# - sh start_vm.sh  Name

NAME="laf-test"
# if set first param in command line
if [ -n "$1" ]; then
    NAME="$1"
fi

# check if multipass is installed
if ! command -v multipass; then
    echo "multipass is not installed, please install it first"
    exit 1
fi


MASTER_NAME="$NAME""-master1"
NODE_NAME="$NAME""-node1"
# delete the vm if it already exists
if multipass list | grep -e "^$MASTER_NAME"; then
    echo "existing vm $MASTER_NAME"
   echo "Deleting the existing vm $MASTER_NAME"
   multipass delete -p "$MASTER_NAME"
fi

if multipass list | grep -e "^$NODE_NAME "; then
    echo "existing vm $NODE_NAME"
   echo "Deleting the existing vm $NODE_NAME"
   multipass delete -p "$NODE_NAME"
fi

echo "Creating VM..."
#multipass launch --name "$NAME" --cpus 2 --mem 4G --disk 100G 
echo "\tmultipass launch --name $MASTER_NAME --cpus 2 --mem 4G --disk 100G "
multipass launch --name $MASTER_NAME --cpus 2 --mem 4G --disk 100G 

echo "\tmultipass launch --name $NODE_NAME --cpus 2 --mem 4G --disk 100G "
multipass launch --name $NODE_NAME --cpus 2 --mem 4G --disk 100G 

if [ $? -eq 0 ]; then
    echo "vm is created"
else
    echo "ERROR: failed to create vm, please retry"
    exit 1
fi

# shellcheck disable=SC2139
alias vm_root_exec="multipass exec $MASTER_NAME -- sudo -u root"
alias vm_node_exec="multipass exec $NODE_NAME -- sudo -u root"
echo "Installing sealos..."
set -x
vm_root_exec -s << EOF
echo "deb [trusted=yes] https://apt.fury.io/labring/ /" | tee /etc/apt/sources.list.d/labring.list
apt update
apt install sealos=4.1.3 -y
EOF
set +x

set -x
vm_node_exec -s << EOF
echo "deb [trusted=yes] https://apt.fury.io/labring/ /" | tee /etc/apt/sources.list.d/labring.list
apt update
apt install sealos=4.1.3 -y
EOF
set +x

set -x
cp -r ~/.ssh ~/vm_ssh

vm_root_exec rm -rf /root/.ssh
vm_root_exec mkdir /root/.ssh
multipass transfer ~/vm_ssh/id_rsa $MASTER_NAME:/home/ubuntu/
multipass transfer ~/vm_ssh/id_rsa.pub $MASTER_NAME:/home/ubuntu/
vm_root_exec cp -r /home/ubuntu/id_rsa /root/.ssh/id_rsa
vm_root_exec chmod 600 /root/.ssh/id_rsa
vm_root_exec cp -r /home/ubuntu/id_rsa.pub /root/.ssh/id_rsa.pub

vm_node_exec rm -rf /root/.ssh
vm_node_exec mkdir /root/.ssh
multipass transfer ~/vm_ssh/id_rsa.pub $NODE_NAME:/home/ubuntu
vm_node_exec cp -r /home/ubuntu/id_rsa.pub /root/.ssh/authorized_keys

rm -rf ~/vm_ssh

set +x

master_ip=$(multipass info "$MASTER_NAME" | grep IPv4: | awk '{print $2}')
node_ip=$(multipass info "$NODE_NAME" | grep IPv4: | awk '{print $2}')

echo master_ip: $master_ip
echo node_ip: $node_ip

echo "Installing k8s..."
set -x
vm_root_exec sealos run labring/kubernetes:v1.24.0 labring/helm:v3.8.2 labring/calico:v3.22.1 --masters $master_ip --nodes $node_ip
#vm_root_exec kubectl taint node $NAME node-role.kubernetes.io/master-
#vm_root_exec kubectl taint node $NAME node-role.kubernetes.io/control-plane-
set +x
set +e

echo "k8s cluster is ready."

sealos 与 helm​

• helm 并不关心 kubernetes 集群生命周期的管理，但是 sealos 关心，sealos boot 模块整个云操作系统启动伸缩升级清理都会处理.
• helm 关心编排不关心打包，helm 里面依赖的 docker 镜像如何交付 helm 不关心，sealos 是把分布式应用的所有依赖打包.
• helm 不会内嵌一个 kuberentes, 但是 sealos 会，这样保证整个集群整体的一致性.
• helm 如果你的分布式应用里面依赖一些非容器化的二进制，helm 不会打包这些依赖而 sealos 会.
• sealos 内嵌一个私有镜像仓库来存放集群中所有需要用到的 docker 镜像，helm 并没有.

Best Practise: 最佳实践是配合 helm 与 sealos 使用，用 helm 编排 用 sealos 打包整个集群, 和应用所有的依赖. Example: Building an ingress cluster images

sealos 与 kubeadm​

严格来说应该是 sealos 的 boot 模块与 kubeadm, boot 模块和 kubedam 都是用户管理集群生命周期的.

boot 的底层调用了 kubeadm 的能力，两者是相互配合的关系， sealos boot 也可以扩展其它的方式安装集群，如 二进制实现，boot 还

可以扩展其它运行时的能力，如支持 k3s k0s 这样的其它 kubernetes 轻量级发行版。

kubeadm 的能力：

• 安装 kubernetes 集群
• 增删节点、升级、清理集群等

为什么在此基础之上还需要封装一层 sealos boot:

1. kubeadm 没有给默认的 LB方案解决 HA 问题，所以 sealos 实现了 lvscare 让集群高可用
2. kubeadm 更适合在线安装，没有处理好依赖，特别是二进制和依赖镜像，而 sealos 所有东西都放到集群镜像中了
3. kubeadm 整个安装步骤是面向过程的，基本是 环境预设->安装二进制和kubelet->kubeadm init->kubeadm join 这个过程，而 sealos 一条命令面向结果
4. kubeadm 的证书写死在源码中，还是需要额外组件续期等，sealos 重写这部分逻辑彻底解决这个问题
5. sealos 封装了 ssh scp 等操作，不再需要登录到各机器上
6. sealos 适合超大规模集群的快速安装，kubeadm 直接使用会不太方便，有过多手工操作

所以 sealos boot 是在 kubeadm 基础上让安装体验做到极致.

sealos 与 rancher kubesphere

rancher 和 kubesphere 是非常优秀的基于 kubernetes 的 PaaS 平台，或者 kubernetes 的管理器，

这类产品的主要特性：

• kubernetes 的可视化管理，暴露原生大量的 kubernetes 的概念，如 service deployment pod 等
• 集成 CI/CD 能力，如 kubesphere 继承 jenkins
• 集成微服务能力，如 rancher 继承 istio
• 集成监控系统能力
• 也有应用市场，是一些生态中其它的云原生化组件

特点是大而全，一站式服务，对使用人员的专业性要求比较高，基本定位给熟悉云原生的开发与运维人员使用。

是把 kubernetes 当成目的设计思路，产品功能与能力非常具体。

sealos 的设计理念是 "化整为零，自由组装，大道至简"，利用 kubernetes 的能力使用非常简单的方式提供给用户真正想要的东西。

如何理解这句话：

可大可小，可简单可强大

• sealos 可以非常简单，可以简单到只安装最干净的 kubernetes, 其它什么也不带，非常干净。
• sealos 简单不意味着功能弱，可以通过 sealos run 几十款应用来组装一个能力非常强的云。
• sealos 可以在小到2C4G的机器上跑测试，也可以在大到数千台的数据中心中运行。

用户真正需要的是什么？

操作系统的特点是用户需要什么它就是什么，极其灵活，不会给用户带来额外负担。

如 windows 对于一个游戏玩家来说就是个游戏机, 对于程序员来说就是用来写代码的工具，对于美工来说就是用来修图的。 操作系统的形态取决于使用者是谁，装了什么应用。

那 sealos 云操作系统也一样，sealos 本身通过 sealos core, sealos hub, sealos desktop 把分布式应用管理好即可， 剩下一切能力让应用层去扩展。

• sealos core: 实现一个多租户的内核，相当于给 kubernetes patch 管理好租户和应用
• sealos hub: 应用的提供者和使用者相互协作的地方，提供者发布应用，使用者使用应用
• sealos CLI API desktop: 一些应用使用入口，如图形界面入口

再看用户群体：

大众用户

随便做个开发者调查，你会发现懂 kubernetes 的不会超过 5%，即便是在大厂撑死也不会超过 10%，所以可以认为大众用户是不懂 kubernetes 的

但是他们又特别需要云原生的能力，比如绝大多数应用开发者都绕不开一个需求：提供一个高可用的数据库给他们。

此时：sealos run mysql-HA:v8.0 搞定了，再告诉用户访问地址和密码，整个过程完全感知不到 kubernetes 内核的存在，这才是友好体验。

有 sealos desktop 就更简单了，像安装微信一样安装 mysql 集群.

云原生用户

很多人就会问了，sealos 屏蔽了 kubernetes 细节是不是就对 kubernetes 专业人士不友好了，其实一样的道理，专业人士只需要

安装一个 kuberentes dashboard 或者安装一个 cloud terminal 应用所有原生的体验都一点问题没有，kubectl 这样的命令也

可以直接用。他们用起来一样会很舒服，甚至 rancher 和 kubesphere 也可以是 sealos 上的一款云管应用。

未来 sealos 的用户群体

你发现一个有意思的点，全球 70 亿人，手机操作系统却只需要两款主流的，为什么，就是因为系统是抽象的，系统之上的应用是具体的，

生产关系一定要是 n 对 n 才能满足 70 亿人的需求，rancher kubesphere 的生产关系显然是 1 对 n.

sealos 系统上分布式应用是一等公民，未来有十万级应用满足企业方方面面对云和数字化的诉求。

当前 B 端企业都有定制化需求，因为云操作系统标准化与生产力没有达到安卓这样的级别，导致生产关系没被改变。

所以 sealos 上会跑各种应用，数据库/消息/AI 能力/甚至 SaaS软件

sealos 当前应用覆盖(20+ 款)：

• 函数计算 laf (自研)
• 数据库 mysql clickhouse redis
• 消息队列 kafka
• GPU
• 监控 prometheus

更多应用

sealos 本身要做的最核心的事情就是管理好这些应用，这些分布式应用本身也是 sealos 的一部分，不过都可以自由的安装卸载.

sealos 的应用与 rancher kubesphere 应用市场应用的差异​

• sealos 标准完全兼容 OCI, 能完全和 docker hub 兼容
• sealos 应用所有依赖基于集群镜像方式打包
• sealos desktop 注重应用本身"自管理"，而其它应用市场安装完会以 kubernetes 原生对象透出
• sealos 的产品体验，一切皆应用，而其它工具是 kubernetes 管理界面中嵌套应用市场使用上会有很多干扰
• 不懂 kubernetes 也能很方便的使用 sealos 分布式应用，而其它工具都是需要懂才能使用

早期单机操作系统也是分层架构，后面才演化成今天的如 linux windows 的宏内核微内核架构，云操作系统也会有类似发展趋势

以前都是单机应用，而现代应用几乎都是分布式应用，kubernetes 已经成为事实上的“云操作系统内核”，能让云内核普及的发型版呼之欲出

你会发现现在 IaaS PaaS SaaS 在云原生技术普及的浪潮中已经名存实亡，比如容器运行在裸机上就已经拥有非常好的性能了，是否还需要 IaaS 这一层，PaaS SaaS 本质都是容器是否还需要去可以区分，这三层架构已经被击穿！

程序员很认“鸭式辩型”，就是会游泳长了翅膀的就是鸭子，这种抽象思维是极重要的，这也就是为啥 linux 一切皆文件的设计哲学了。而一个运行的 mysql 集群与一个 crm 软件其实也没有本质区别，所以在云操作系统中，“内核之上皆为应用”。

云计算三次浪潮​

基于云内核的云操作系统未来会引发云计算的巨大变革。

先来看看有意思的 web1 web2 web3, 再把互联网的变革套用到云计算中，你会发现，生产关系有非常类似的地方。

【1 对 n 关系】

• web1 : 门户网站生产内容，用户查看内容
• 云计算 1.0 : 公有云厂商开发服务，企业和开发者使用

这个阶段生产关系是 1 对多的，你会发现云厂商几十款云产品是无法满足市场上体量庞大偏好各异的需求的，就像 web1 用户只能看小编写的一些新闻一样。

【n 对 1 对 n 关系】

• web2 : UGC 用户生产内容，用户之间产生链接
• 云计算 2.0 : 开发者生产云计算应用，给用户使用

渐渐的云厂商开始弄 markting place, 一定程度想通过开放市场来连接云计算的生产者与消费者，这就是云计算朝着 2.0 过度的信号, 但是缺乏标准就意味着难以协作，这个阶段想要彻底爆发必须要有“实际上的标准”出现。

Docker 镜像算是非常好的标准，但是可惜难以覆盖分布式软件，但是大家通过 docker hub 协作就是一个非常好的协作模型了。

kubernetes 的 API 的标准是真正有潜力成为云计算 2.0 事实标准的。未来大家都通过这个系统来相互协作，就像安卓生态蓬勃的应用爆炸一样，这样才能诞生越来越多优质的云服务出来。

【n 对 n 关系】

• web 3 : 网络所有权属于网络的所有参与者，数据回归用户自己手中
• 云计算 3.0 : 算力属于所有计算的参与者，一台分布式超级计算机诞生

整个过程其实是让计算和服务更民主，任何组织个人都可以贡献自己的算力，发布和使用应用的人也不用关心应用到底运行在哪个地方，整个计算的使用像使用一台虚拟计算机一样。 和现在很多大的公链一样，不过目前的智能合约还是场景过于局限，计算成本过高，形式上很像超级计算机，效果上还是差了好几个鸿沟。

基于云内核设计的云计算会更便宜​

当前公有云提供的云服务还是极其昂贵的, 在某云厂商官网查到的价格和 IDC 托管硬件相比，如果是存储类型的机器，价格相差十倍！（不过云厂商对大B都有非常大的折扣，小B没有这种福利）

很多公有云厂商妖魔化私有云，说私有云就不叫云，我想问私有云怎么就不叫云了，是因为私有云太便宜还是私有云动了谁的蛋糕？

这个价格对比小学生都能算的清楚。其实在云内核设计的云操作系统出现之前公有云确实会便宜，因为软件成本很高，企业想云在自己机房玩一套如 openstack 这样的 IaaS 几乎每年会花费上千万成本，而现在开源生态逐渐成熟让软件成本变得便宜和稳定，私有云的成本便宜逻辑又开始成立了。

那还有个问题就是“传统公有云为什么贵？”

• 第一，因为基于的还是 IaaS PaaS SaaS 的架构，每一层都意味着成本，软件的复杂度直接决定成本，所谓的一切自研的优势现在反而会变成成本劣势，这是最主要的原因。
• 第二，谈边际成本，这个不是按照公有云的用户体量去计算的，而是按照每个可用区的建设成本去计算的，如果软件体系复杂，每个机房需要大量管理节点，需要大量交付人员配合，那成本就无法降下来。但是基于内核设计的云操作系统管理节点只需三台，实习生都能在半个小时以内交付，就像装 centos 一样简单。
• 第三，次要原因是因为公有云的弹性都是要预留资源的，这部分成本都会摊到消费者头上。

很多企业的业务资源使用都是相对固定，半年一年作一次扩容等，托管或者自建肯定会更便宜，促销活动什么的一年也就几次，在促销时使用公有云即可，这样成本可以大幅度降低。

云计算会走向开源开放​

封闭的云服务对于企业来说是灾难，最简单的一个场景是应对云厂商的涨价行为，如果强绑定就意味着失去了议价权，近期某云厂商云开发就提价十倍，有些小企业的利润直接就被云服务吃光了。

第二个原因是云厂商的云产品如果发展的不好是有可能被下架的，如果企业不幸使用了这类产品，下架时又需要付出巨大迁移成本，有些与代码耦合的甚至需要重写代码。

开源自然是开放的最好实现方式，不仅对上面几种场景有比较好的应对措施，关键还可以自由按照自己的需求进行定制。

所以未来开源与云是左右腿，像 vercel supabase sealos 这样的产品是云计算的大势所趋。

基于内核架构的云计算会变得更简单​

复杂的东西无法普及，复杂的软件要么走向腐烂和消亡，要么重构变得简单，云计算也是如此，你会发现 centos ubuntu 这样的 linux 发行版普及了，但是现在的一些公有云能力很难到处运行和做到普及，即便是开源了，像 openstack 一直未能普及，原因很简单，需要几十个人的团队才能在生产环境玩起来的话绝大多数企业都会放弃。

什么叫“内聚”，就是功能不是以牺牲复杂度来换取的，像 linux 的 core 很内聚，驱动即使扩展了一万个系统复杂度也没增加，虽然代码在一直增加。所以软件设计时的抽象能力就变得极重要，基于云内核架构设计的云操作系统也是高“内聚”的，通过扩展应用来扩展能力，而各应用之间是低耦合的。

内核架构云操作系统爆发时机​

基于开源技术的云服务在侵蚀昂贵且强绑定的公有云的服务

现在可以发现公有云云原生领域提供的服务商业化做的好的几乎都是开源强相关的， 如基于 kubernetes 的云服务，基于 prometheus grafana 的可观测服务等。

用户越来越聪明了，便宜还是贵按按计算器就能算出来，而且绑定意味着认人鱼肉，技术选型明显往开源技术倾斜。

云原生侵蚀传统 IaaS 服务

基于虚拟机的业务增长速度已经远远赶不上云原生生态的发展速度了，基于 kubernetes 的云原生生态每年几倍甚至有些产品每年几十倍的增长，大量企业在从虚拟机架构往云原生架构迁移。

前几年市场被教育的很好，越来越多企业知道云原生降本增效不是一点点，该填的坑也被填的差不多了，开始考虑从观望状态变成实践了。

市场需要一款云操作系统进一步降低云原生门槛与成本

现状是企业在实践云原生的时候还是容易迷失，生态过于庞大复杂，上千款生态软件让很多企业无从下手，而且真要落地至少得有个专家能把云原生计算存储网络都玩的明白，所以这个生态依然还是缺乏好用的开箱即用的发行版。

其实这个发行版的要求还是很高的，要非常简单不多不少的去满足客户的需求，还不能给用户带来负担，这就必须得非常好的设计理念和实现机制。

如何实现这样一个云操作系统​

如何去设计这样一个操作系统，首先一定需要有非常好的设计理念

1. 化整为零，这意味着如果你不装应用，这个系统就是空的，就是 nothing,就是 void*,就和你买了一台新电脑里面除了操作系统什么也没装一样。
2. 自由组装，所有用户的需求都是通过具体应用实现的而这些应用都是按需求从应用市场中下载，不会硬塞给用户不需要的东西，未能得到满足的需求也是通过应用去扩展。云操作系统不会去追求各种应用风格的统一，就像 macOS 上的微信和飞书不会有统一的风格和账户系统一样，只有这样各应用才能在自己的场景尽情发挥出最大优势。

实现层面，core 是非常内聚的意味它向下仅提供云内核生命周期管理，如安装/伸缩/升级/清理，向上做好应用的打包与管理即可。

应用市场方面很重要，一定要有好的标准，这涉及到应用的提供者与消费者之间的协作，OCI registry 仓库就是个非常好的已有事实标准，兼容它是最好的选择。

User interface 一定要简单极致，这是用户直接使用你东西的地方，API > CLI > GUI, Desktop 是产品化的终极形态，真的做到用云像用 PC 操作系统一样简单。

剩下一切都在于扩展应用的宽度和深度：

1. 广度，常用分布式软件如 mysql 集群，redis 集群，消息队列等逐步覆盖，不断扩展常用分布式应用数量
2. 深度，基本安装->高可用->可监控->自运维->高性能/安全性->产品化，几个阶段衡量一个分布式应用成熟度

那 sealos 就是使用这样的思维去设计的，laf 就是 sealos 上的第一款杀手级应用。

总结​

未来的云会更便宜 更开放 更简单，最终会有一款优秀的发行版本实现云原生的普及，而 sealos 诞生之日起就朝着这个目标不断进步~

相信未来云计算属于所有算力的提供者，云的价值也会属于所有云计算的参与者，不再受任何厂商绑定之苦，更便宜的享受云计算带来的便利。开源开放带给大家简单/便宜的云计算！

作者：fanux.方海涛.中弈 sealos 作者, CNCF sealer 项目发起人。曾就职阿里云，现任环界云计算 CEO, 环界获得陆奇博士奇绩创坛种子轮投资