Rancher+longhorn运维手册

RKE

RKE 全称为 Rancher Kubernetes Engine，是一款经过 CNCF 认证的开源 Kubernetes 发行版，可以在 Docker 容器内部运行。它解决了 Kubernetes 社区中最常见的问题——安装十分复杂。借助 RKE，可以简化 Kubernetes 的安装和操作，并且用户可以在任何操作系统和平台上运行它。

1. 安装

2. 部署

nodes:
- address: 192.168.1.1
port: "22" # ssh 端口
internal_address: "" # 内网IP，如果是公有云的这种有公私网两个IP的，则address配置为公网IP
role:
- controlplane # 控制节点校色，等于k8s的master
- etcd
user: ubuntu # 服务器登陆账户
hostname_override: master-etcd-01
docker_socket: /var/run/docker.sock # docker sock所在路径，如果是用snap安装的dockers需要自行修改
ssh_key_path: "~/.ssh/id_rsa" # ssh key的路径，必须是免密登录，不能使用账户密码
labels: {} # 标签说明
- address: 192.168.1.2
port: "22"
internal_address: ""
role:
- controlplane
- etcd
user: ubuntu
hostname_override: master-etcd-02
docker_socket: /var/run/docker.sock
ssh_key_path: ~/.ssh/id_rsa
- address: 192.168.1.3
port: "22"
internal_address: ""
role:
- controlplane
- etcd
user: ubuntu
hostname_override: master-etcd-03
docker_socket: /var/run/docker.sock
ssh_key_path: ~/.ssh/id_rsa
- address: 192.168.1.4
port: "22"
internal_address: ""
role:
- worker
user: ubuntu
hostname_override: worker-1
docker_socket: /var/run/docker.sock
ssh_key_path: ~/.ssh/id_rsa
labels:
app: ingress # 标记后只有该标记节点会部署ingress
- address: 192.168.1.6
port: "22"
internal_address: ""
role:
- worker
user: ubuntu
hostname_override: worker-2
docker_socket: /var/run/docker.sock
ssh_key_path: ~/.ssh/id_rsa
labels:
app: ingress
- address: 192.168.1.7
port: "22"
internal_address: ""
role:
- worker
user: ubuntu
hostname_override: worker-3
docker_socket: /var/run/docker.sock
ssh_key_path: ~/.ssh/id_rsa
labels:
app: ingress
services:
# ETCD相关配置，另外备份是可以备份到s3的，这个配置见官方文档
etcd:
extra_args:
auto-compaction-retention: 240 #(单位小时)
# 修改空间配额为$((6*1024*1024*1024))，默认2G,最大8G
quota-backend-bytes: "6442450944"
backup_config:
enabled: true
interval_hours: 12
retention: 6
kube-api:
service_cluster_ip_range: 10.43.0.0/16
service_node_port_range: "20000-40000"
pod_security_policy: false
always_pull_images: false
# 控制器的一些配置，比如节点判断失联后多久开始迁移等
kube-controller:
extra_args:
## 当节点通信失败后，再等一段时间kubernetes判定节点为notready状态。
## 这个时间段必须是kubelet的nodeStatusUpdateFrequency(默认10s)的整数倍，
## 其中N表示允许kubelet同步节点状态的重试次数，默认40s。
node-monitor-grace-period: "20s"
## 再持续通信失败一段时间后，kubernetes判定节点为unhealthy状态，默认1m0s。
node-startup-grace-period: "30s"
## 再持续失联一段时间，kubernetes开始迁移失联节点的Pod，默认5m0s。
pod-eviction-timeout: "1m"
cluster_cidr: 10.42.0.0/16
service_cluster_ip_range: 10.43.0.0/16
# 集群的一些配置，包括资源预留，集群名字，dns等配置
kubelet:
extra_args:
serialize-image-pulls: "false"
registry-burst: "10"
registry-qps: "0"
# # 节点资源预留
# enforce-node-allocatable: 'pods'
# system-reserved: 'cpu=0.5,memory=500Mi'
# kube-reserved: 'cpu=0.5,memory=1500Mi'
# # POD驱逐，这个参数只支持内存和磁盘。
# ## 硬驱逐伐值
# ### 当节点上的可用资源降至保留值以下时，就会触发强制驱逐。强制驱逐会强制kill掉POD，不会等POD自动退出。
# eviction-hard: 'memory.available<300Mi,nodefs.available<10%,imagefs.available<15%,nodefs.inodesFree<5%'
# ## 软驱逐伐值
# ### 以下四个参数配套使用，当节点上的可用资源少于这个值时但大于硬驱逐伐值时候，会等待eviction-soft-grace-period设置的时长；
# ### 等待中每10s检查一次，当最后一次检查还触发了软驱逐伐值就会开始驱逐，驱逐不会直接Kill POD，先发送停止信号给POD，然后等待eviction-max-pod-grace-period设置的时长；
# ### 在eviction-max-pod-grace-period时长之后，如果POD还未退出则发送强制kill POD"
# eviction-soft: 'memory.available<500Mi,nodefs.available<50%,imagefs.available<50%,nodefs.inodesFree<10%'
# eviction-soft-grace-period: 'memory.available=1m30s'
# eviction-max-pod-grace-period: '30'
# eviction-pressure-transition-period: '30s'
cluster_domain: cluster.local
infra_container_image: ""
cluster_dns_server: 10.43.0.10
fail_swap_on: false
kubeproxy:
extra_args:
# 默认使用iptables进行数据转发，如果要启用ipvs，则此处设置为`ipvs`
proxy-mode: "ipvs"
# 配置集群的CNI网络模型
network:
plugin: canal
options:
flannel_backend_type: "vxlan"
ssh_key_path: ~/.ssh/id_rsa
ssh_agent_auth: false
authorization:
mode: rbac
ignore_docker_version: false
# k8s的版本，可以通过rke config --system-images --all 命令列出所有rke支持的版本
kubernetes_version: v1.15.4-rancher1-2
# 国内使用阿里云的镜像
private_registries:
- url: registry.cn-shanghai.aliyuncs.com
user:
password:
is_default: true
# 配置ingress，目前RKE支持nginx。
ingress:
provider: "nginx"
# 节点选择，和上面node配置结合的
node_selector:
app: ingress
options:
use-forwarded-headers: "true"
cluster_name: rancher
addon_job_timeout: 0
restore:
restore: false
snapshot_name: ""



大部分的配置都注释说明了，基本上需要用到的配置就这些了，更详细的配置需要查阅官方文档。文档链接：

https://docs.rancher.cn/rke/example-yamls.html配置完毕之后，就是开始部署了，rke 的启动非常简单，在配置文件目录使用./rke up 就可以了。

启动完毕之后，等待大约

部署的过程中，日志可能会显示

1. 创建定时快照etcd-snapshot在etcd容器之外的服务容器中运行。默认设置下，etcd-snapshot服务会为每一个具有etcd角色的节点创建快照，然后将这些快照储存在本地的/opt/rke/etcd-snapshots路径下。
   运行已经启用etcd-snapshot的集群时，您可以在命令行工具中输入docker logs etcd-rolling-snapshots，查看etcd-rolling-snapshots日志，确认集群是否开启定时快照功能。输入该命令后，返回的消息包含了创建时间、创建信息、快照名称和 runtime，与下方代码示例相似。
   #docker logs etcd-rolling-snapshots
2. 创建一次性快照打开命令行工具，输入rke etcd snapshot-save命令，运行后即可保存 cluster config 文件内每个 etcd 节点的快照。RKE 会将节点快照保存在/opt/rke/etcd-snapshots路径下。
   
   运行以下命令，在本地创建一个一次性快照：
   
   #rke etcd snapshot-save --config cluster.yml --name snapshot-name
   ./rke etcd snapshot-save --config rancher-cluster.yml --name k8s-snapshot

一次性快照会保存在/opt/rke/etcd-snapshots路径下（包括定时快照）。

在pod里写入数据：

1. 恢复集群如果您的
   警告：在运行rke etcd snapshot-restore之前，您应该备份集群中的任何重要数据，因为该命令会删除您当前的 Kubernetes 集群，并用新的集群替换。
   
   请运行以下命令，从本地快照中还原
   #rke etcd snapshot-restore --config cluster.yml --name mysnapshot

查看pod里面的数据，发现数据快照前后数据是不变的：

rancher容器平台

1. 
   
2. 同步镜像到私有镜像仓库
   以下脚本在http://mirror.rancher.cn/ 下载，并确认自己部署的版本。
   

3. 

4. 
   
   在外网的机器上拉取rancher相关镜像：
   #./rancher-save-images.sh --image-list ./rancher-images.txt
   
   推送镜像到私有镜像库：
   ./rancher-load-images.sh --image-list ./rancher-images.txt --registry <REGISTRY.YOURDOMAIN.COM:PORT>`
   
5. 高可用安装Rancher 建议在 Kubernetes 集群上安装 Rancher。高可用的 Kubernetes 安装包含三个节点。持久层（etcd）数据也可以在这三个节点上进行复制，以便在节点之一发生故障时提供冗余和数据复制。
   参考文档：
   https://docs.rancher.cn/docs/rancher2.5/installation/other-installation-methods/air-gap/install-rancher/_index
   
6. 生成自签名

1. 一键生成 ssl 自签名证书脚本#!/bin/bash -e
   
   help ()
   {
   echo ' ================================================================ '
   生成ssl证书需要的主域名，如不指定则默认为www.rancher.local，如果是ip访问服务，则可忽略；'
   一般ssl证书只信任域名的访问请求，有时候需要使用ip去访问server，那么需要给ssl证书添加扩展IP，多个IP用逗号隔开；'
   如果想多个域名访问，则添加扩展域名（SSL_TRUSTED_DOMAIN）,多个扩展域名用逗号隔开；'
   加密位数，默认2048；'
   国家代码(2个字母的代号),默认CN;'
   使用示例:'
   echo ' ./create_self-signed-cert.sh --ssl-domain=www.test.com --ssl-trusted-domain=www.test2.com \ '
   echo ' --ssl-trusted-ip=1.1.1.1,2.2.2.2,3.3.3.3 --ssl-size=2048 --ssl-date=3650'
   echo ' ================================================================'
   }
   
   case "$1" in
   -h|--help) help; exit;;
   esac
   
   if [[ $1 == '' ]];then
   help;
   exit;
   fi
   
   CMDOPTS="$*"
   for OPTS in $CMDOPTS;
   do
   key=$(echo ${OPTS} | awk -F"=" '{print $1}' )
   value=$(echo ${OPTS} | awk -F"=" '{print $2}' )
   case "$key" in
   --ssl-domain) SSL_DOMAIN=$value ;;
   --ssl-trusted-ip) SSL_TRUSTED_IP=$value ;;
   --ssl-trusted-domain) SSL_TRUSTED_DOMAIN=$value ;;
   --ssl-size) SSL_SIZE=$value ;;
   --ssl-date) SSL_DATE=$value ;;
   --ca-date) CA_DATE=$value ;;
   --ssl-cn) CN=$value ;;
   esac
   done
   
   # CA相关配置
   CA_DATE=${CA_DATE:-3650}
   CA_KEY=${CA_KEY:-cakey.pem}
   CA_CERT=${CA_CERT:-cacerts.pem}
   CA_DOMAIN=cattle-ca
   
   # ssl相关配置
   SSL_CONFIG=${SSL_CONFIG:-$PWD/openssl.cnf}
   SSL_DOMAIN=${SSL_DOMAIN:-'www.rancher.local'}
   SSL_DATE=${SSL_DATE:-3650}
   SSL_SIZE=${SSL_SIZE:-2048}
   
   ## 国家代码(2个字母的代号),默认CN;
   CN=${CN:-CN}
   
   SSL_KEY=$SSL_DOMAIN.key
   SSL_CSR=$SSL_DOMAIN.csr
   SSL_CERT=$SSL_DOMAIN.crt
   
   echo -e "\033[32m ---------------------------- \033[0m"
   echo -e "\033[32m | 生成 SSL Cert | \033[0m"
   echo -e "\033[32m ---------------------------- \033[0m"
   
   if [[ -e ./${CA_KEY} ]]; then
   发现已存在CA私钥，备份"${CA_KEY}"为"${CA_KEY}"-bak，然后重新创建 \033[0m"
   mv ${CA_KEY} "${CA_KEY}"-bak
   openssl genrsa -out ${CA_KEY} ${SSL_SIZE}
   else
   生成新的CA私钥 ${CA_KEY} \033[0m"
   openssl genrsa -out ${CA_KEY} ${SSL_SIZE}
   fi
   
   if [[ -e ./${CA_CERT} ]]; then
   发现已存在CA证书，先备份"${CA_CERT}"为"${CA_CERT}"-bak，然后重新创建 \033[0m"
   mv ${CA_CERT} "${CA_CERT}"-bak
   openssl req -x509 -sha256 -new -nodes -key ${CA_KEY} -days ${CA_DATE} -out ${CA_CERT} -subj "/C=${CN}/CN=${CA_DOMAIN}"
   else
   生成新的CA证书 ${CA_CERT} \033[0m"
   openssl req -x509 -sha256 -new -nodes -key ${CA_KEY} -days ${CA_DATE} -out ${CA_CERT} -subj "/C=${CN}/CN=${CA_DOMAIN}"
   fi
   
   echo -e "\033[32m ====> 3. 生成Openssl配置文件 ${SSL_CONFIG} \033[0m"
   cat > ${SSL_CONFIG} <<EOM
   [req]
   req_extensions = v3_req
   distinguished_name = req_distinguished_name
   [req_distinguished_name]
   [ v3_req ]
   basicConstraints = CA:FALSE
   keyUsage = nonRepudiation, digitalSignature, keyEncipherment
   extendedKeyUsage = clientAuth, serverAuth
   EOM
   
   if [[ -n ${SSL_TRUSTED_IP} || -n ${SSL_TRUSTED_DOMAIN} || -n ${SSL_DOMAIN} ]]; then
   cat >> ${SSL_CONFIG} <<EOM
   subjectAltName = @alt_names
   [alt_names]
   EOM
   IFS=","
   dns=(${SSL_TRUSTED_DOMAIN})
   dns+=(${SSL_DOMAIN})
   for i in "${!dns[@]}"; do
   echo DNS.$((i+1)) = ${dns[$i]} >> ${SSL_CONFIG}
   done
   
   if [[ -n ${SSL_TRUSTED_IP} ]]; then
   ip=(${SSL_TRUSTED_IP})
   for i in "${!ip[@]}"; do
   echo IP.$((i+1)) = ${ip[$i]} >> ${SSL_CONFIG}
   done
   fi
   fi
   
   echo -e "\033[32m ====> 4. 生成服务SSL KEY ${SSL_KEY} \033[0m"
   openssl genrsa -out ${SSL_KEY} ${SSL_SIZE}
   
   echo -e "\033[32m ====> 5. 生成服务SSL CSR ${SSL_CSR} \033[0m"
   openssl req -sha256 -new -key ${SSL_KEY} -out ${SSL_CSR} -subj "/C=${CN}/CN=${SSL_DOMAIN}" -config ${SSL_CONFIG}
   
   echo -e "\033[32m ====> 6. 生成服务SSL CERT ${SSL_CERT} \033[0m"
   openssl x509 -sha256 -req -in ${SSL_CSR} -CA ${CA_CERT} \
   -CAkey ${CA_KEY} -CAcreateserial -out ${SSL_CERT} \
   -days ${SSL_DATE} -extensions v3_req \
   -extfile ${SSL_CONFIG}
   
   echo -e "\033[32m ====> 7. 证书制作完成 \033[0m"
   echo
   echo -e "\033[32m ====> 8. 以YAML格式输出结果 \033[0m"
   echo "----------------------------------------------------------"
   echo "ca_key: |"
   cat $CA_KEY | sed 's/^/ /'
   echo
   echo "ca_cert: |"
   cat $CA_CERT | sed 's/^/ /'
   echo
   echo "ssl_key: |"
   cat $SSL_KEY | sed 's/^/ /'
   echo
   echo "ssl_csr: |"
   cat $SSL_CSR | sed 's/^/ /'
   echo
   echo "ssl_cert: |"
   cat $SSL_CERT | sed 's/^/ /'
   echo
   
   echo -e "\033[32m ====> 9. 附加CA证书到Cert文件 \033[0m"
   cat ${CA_CERT} >> ${SSL_CERT}
   echo "ssl_cert: |"
   cat $SSL_CERT | sed 's/^/ /'
   echo
   
   echo -e "\033[32m ====> 10. 重命名服务证书 \033[0m"
   echo "cp ${SSL_DOMAIN}.key tls.key"
   cp ${SSL_DOMAIN}.key tls.key
   echo "cp ${SSL_DOMAIN}.crt tls.crt"
   cp ${SSL_DOMAIN}.crt tls.crt
   
   
   2）脚本说明：
   复制以上代码另存为create_self-signed-cert.sh或者其他您喜欢的文件名。
   
   --ssl-domain: 生成ssl证书需要的主域名，如不指定则默认为www.rancher.local，如果是ip访问服务，则可忽略；
   --ssl-trusted-ip: 一般ssl证书只信任域名的访问请求，有时候需要使用ip去访问server，那么需要给ssl证书添加扩展IP，多个IP用逗号隔开；
   --ssl-trusted-domain: 如果想多个域名访问，则添加扩展域名（TRUSTED_DOMAIN）,多个TRUSTED_DOMAIN用逗号隔开；
   --ssl-size: ssl加密位数，默认2048；
   --ssl-cn: 国家代码(2个字母的代号),默认CN；
   使用示例:
   ./create_self-signed-cert.sh --ssl-domain=www.test.com --ssl-trusted-domain=www.test2.com \
   --ssl-trusted-ip=1.1.1.1,2.2.2.2,3.3.3.3 --ssl-size=2048 --ssl-date=3650
   
   
   
   
   3）验证证书
   通过：
   openssl verify -CAfile cacerts.pem tls.crt 应该返回状态为 ok
   
   openssl x509 -in tls.crt -noout -text执行后查看对应的域名和扩展 iP 是否正确
   

7. 添加只有当我们在
   将服务器证书和任何所需的中间证书合并到名为
   例如，acme.sh在fullchain.cer文件中提供了服务器证书和中间证书。在这种情况下，您应该将fullchain.cer文件重命名为tls.crt，将证书秘钥文件重命名为tls.key 。
   使用
   kubectl -n cattle-system create secret tls tls-rancher-ingress \
   --cert=tls.crt \
   --key=tls.key
   
   提示：
   
   使用私有
   如果您使用的是私有
   拷贝
   kubectl -n cattle-system create secret generic tls-ca \
   --from-file=cacerts.pem=./cacerts.pem

rancher备份恢复

1. 备份和恢复的工作原理rancher-backup operator 引入了三种自定义资源。Backups、Restores 和 ResourceSets。下列集群范围的自定义资源定义被添加到集群中：
   backups.resources.cattle.io
   resourcesets.resources.cattle.io
   restores.resources.cattle.io
   ResourceSet 定义了哪些 Kubernetes 资源需要备份。由于备份 Rancher 所需的值是预定义的，因此该 ResourceSet 无法在 Rancher UI 中进行配置。这个 ResourceSet 不应该被修改。
   当创建一个。
2. 使用

1. 在
2. 在右上角单击
3. 单击
4. 单击

安装后，信息如截图：

1. 备份rancher可以通过图形化界面创建一次备份，或者定时备份：

定时备份：

Schedule: @every 1h 表示每一个小时备份一次，Retention Count表示保留的备份数量。

此次备份的数据是放在longhorn存储上，

#kubectl exec -it rancher-backup-67f79f4c5f-944sl -n cattle-resources-system

#存放于目录为/var/lib/backupd/下

1. 恢复rancher根据已有的备份文件去恢复rancher：
   
   也可以通过命令行的方式恢复rancher。

rancher对下游k8s集群的管理

1. 创建自定义集群第一步：添加集群

第二步：选择自定义

第三步：填写相关参数：

第四步：节点节色分配，在待创建的节点执行相关命令即可。

第四步：创建成功后截图

1. 创建k8s失败场景案例1）rancher证书有问题，会导致创建集群失败
   #docker logs -f XXX

解决思路：重新制作rancher的证书，k8s集群时间和制作证书机器的时间不匹配。

1. 没有规划DNS和主机名，coreDNS理解不深入导致

解决思路：规划主机名

1. 备份与恢复除了可以做一次备份，还有在创建集群时选择定时备份集群：

针对集群的恢复，可以选择etcd，k8s版本，和RKE集群：

1. 证书更新支持图形化证书更新（自定义集群）：

1. 节点扩容选择Registration cmd，找到注册节点命令：

longhorn云原生存储

longhorn架构

Longhorn 为每个卷创建一个专用的存储控制器，并在多个节点上存储的多个副本之间同步复制该卷。Longhorn 在整体上分为两层：数据平面和控制平面，Longhorn Engine 是存储控制器，对应数据平面，Longhorn Manager 对应控制平面。

Longhorn Manager 会以 DaemonSet 的形式在 Longhorn 集群中的每个节点上运行，它负责在 Kubernetes 集群中创建和管理卷，并处理来自 UI 或 Kubernetes 卷插件的 API 调用，它是遵循 Kubernetes 控制器模式。

Longhorn Manager 通过与 Kubernetes APIServer 通信来创建新的 Longhorn volume CRD，然后 Longhorn Manager 会一直 Watch APIServer 的响应，当它看到发现创建了一个新的 Longhorn volume CRD 时，Longhorn Manager 就会去创建一个新的对应卷。当 Longhorn Manager 被要求创建一个卷时，它会在卷所连接的节点上创建一个 Longhorn Engine 实例，并在每个将放置副本的节点上创建一个副本，副本应放置在不同的主机上以确保最大可用性。副本的多条数据路径确保了 Longhorn 卷的高可用性，即使某个副本或引擎出现问题，也不会影响所有副本或 Pod 对卷的访问。

Longhorn Engine 始终与使用 Longhorn 卷的 Pod 在同一节点中运行，它在存储在多个节点上的多个副本之间同步复制卷。

如下图所示，描述了

1. 
   
2. ●上图中有3个longhorn卷实例
   ●每一个卷都有一个专用控制器，称为Longhorn Enginx,并作为linux进程运行
   ●每一个Longhorn卷有两个副本，每一个副本也是一个linux进程
   
   在
   因为每个卷都有自己的控制器，所以每个卷的控制器和副本实例也可以升级，而不会导致
   Longhorn 是通过 CSI 驱动在 Kubernetes 中管理的，CSI 驱动通过调用 Longhorn 来创建卷，为 Kubernetes 工作负载创建持久性数据，CSI 插件可以让我们创建、删除、附加、分离、挂载卷，并对卷进行快照操作，Kubernetes 集群内部使用 CSI 接口与Longhorn CSI 驱动进行通信，而 Longhorn CSI 驱动是通过使用 Longhorn API 与 Longhorn Manager 进行通信。
   此外。

最佳实践

1. 硬件

1. 3个节点
2. 每个节点
3. 每个节点
4. 节点上的
5. 由于SATA磁盘

2. 操作系统
3. 节点和磁盘设置①建议为
   ②可用存储空间和和超配空间
   
   If you need to use the root disk, use the default minimal available storage percentage setup which is 25%, and set overprovisioning percentage to 200% to minimize the chance of DiskPressure.
   If you’re using a dedicated disk for Longhorn, you can lower the setting minimal available storage percentage to 10%.
   For the Over-provisioning percentage, it depends on how much space your volume uses on average. For example, if your workload only uses half of the available volume size, you can set the Over-provisioning percentage to 200, which means Longhorn will consider the disk to have twice the schedulable size as its full size minus the reserved space.

③磁盘空间管理

由于LVM将

安装

1. 要求要在

1. 与
2. Kubernetes v1.18+
3. 安装open-iscsi，并且iscsid 守护程序在所有节点上运行，这是必要的，因为 Longhorn 依赖主机上的 iscsiadm 为 Kubernetes 提供持久卷
4. RWX 支持需要每个节点上都安装 NFSv4 客户端
5. 宿主机文件系统支持file extents 功能来存储数据，目前我们支持：ext4 与 XFS
6. bash、curl、findmnt、grep、awk、blkid、lsblk 等工具必须安装
7. Mount propagation 必须启用，它允许将一个容器挂载的卷与同一 pod 中的其他容器共享，甚至可以与同一节点上的其他 pod 共享

Longhorn workloads 必须能够以 root 身份运行才能正确部署和操作 Longhorn。

1. 依赖1）为了验证这些环境要求，Longhorn 官方提供了一个脚本来帮助我们进行检查，执行该脚本需要在本地安装 jq 工具，执行下面的命令即可运行脚本：
   #curl -sSfL https://raw.githubusercontent.com/longhorn/longhorn/v1.2.3/scripts/environment_check.sh | bash
   2）jq工具的安装
   #wget -o /etc/yum.repos.d/ http://mirrors.aliyun.com/repo/epel-7.repo#yum install jq -y
2. 部署官方支持使用 Rancher Catalog 应用、kubectl 与 helm 三种方式来进行安装，同样这里我们选择使用 Rancher Catalog 进行安装。
   注明：rancher在内网生产环境
   在应用商店中找到honghorn,如以下截图：

由于是离线环境，需要把镜像名字换成内网的镜像仓库，并配置相关参数：

点击启动即可：

部署后可以查看 Pod 的运行状态来确保安装正确：

1. 访问

1. 使用下面我们来测试使用 longhorn 提供一个存储卷，由于提供了默认的 StorageClass，所以直接创建 PVC 即可，创建一个如下所示的 PVC：
   创建deployment绑定PVC，部分yaml截图如下：

查看deployment和PVC情况：

扩容

1. Kubernetes节点扩容

注册命令，在待扩容服务器操作

sudo docker run -d --privileged --restart=unless-stopped --net=host -v /etc/kubernetes:/etc/kubernetes -v /var/run:/var/run 10.129.1.25:1603/rancher/rancher-agent:v2.5.12 --server https://www.rancher.com --token vknsftzd8fhmc6p4b7wkdz9zb6qp46qtzpkrn42pwdmwhh2lsqpq6j --ca-checksum f114de822d8c4ed60448b4933f670cccac069a4ac0f93bb5e5ada70b1e914173 --worker

1. 节点扩容失败分析从agent容器上看，以下日志扩容节点环境达不到要求，导致etcd没有回应
   ERROR: The environment variable CATTLE_CA_CHECKSUM is set but there is no CA certificate configured at https://www.rancher.com/v3/settings/cacerts
   INFO: Arguments: --server https://www.rancher.com --token REDACTED --ca-checksum f114de822d8c4ed60448b4933f670cccac069a4ac0f93bb5e5ada70b1e914173 --worker

修改linux主机hostsname后即可

扩容成功，截图以下：

1. 扩容后检查发现k8s节点扩容后，longhorn相关pod会自动扩容。

登录longhorn UI发现，longhron也会自动扩容。

1. 硬盘扩容初始化硬盘，为了节约成本raid选择raid 0。(longhorn有副本机制，可以保障数据安全)

编辑Edit Node and Disks，选择add Disk选择相关参数即可。

1. PVC扩容第一步：

第二步：expand PVC

第三步：Attach PVC

1. 驱逐禁用磁盘或节点上的副本

高可用性

1. 副本自动平衡disabled.这是默认选项，不会进行副本自动平衡
   least-effort. 此选项指示 Longhorn 平衡副本以获得最小冗余
   best-effort. 此选项指示 Longhorn 尝试平衡副本以实现均匀冗余
2. 数据局部性Data locality can also be useful for distributed applications (e.g. databases), in which high availability is achieved at the application level instead of the volume level. In that case, only one volume is needed for each pod, so each volume should be scheduled on the same node as the pod that uses it. In addition, the default Longhorn behavior for volume scheduling could cause a problem for distributed applications. The problem is that if there are two replicas of a pod, and each pod replica has one volume each, Longhorn is not aware that those volumes have the same data and should not be scheduled on the same node. Therefore Longhorn could schedule identical replicas on the same node, therefore preventing them from providing high availability for the workload.
   
   
   Longhorn 目前支持两种数据位置设置模式：
   disabled. 这是默认选项。在与附加卷（工作负载）相同的节点上可能有也可能没有副本。
   best-effort. 此选项指示 Longhorn 尝试将副本保留在与附加卷（工作负载）相同的节点上。Longhorn 不会停止该卷，即使由于环境限制（例如磁盘空间不足、磁盘标签不兼容等）而无法将副本保留在附加卷（工作负载）的本地。
   
   更改默认全局设置：
3. 节点宕机时的选择delete-both-statefulset-and-deployment-pod，表示当节点宕机pod会在其他节点重建。

关键设置

1. 存储最小可用百分比默认设置为 25，Longhorn 管理器仅在可用磁盘空间（可用存储空间）减去磁盘空间量且可用磁盘空间仍超过实际磁盘容量（存储空间）的 25%后才允许调度新副本最大）。否则磁盘将变得不可调度，直到释放更多空间。
2. 存储超配置百分比默认设置为 200，Longhorn 管理器仅在已将磁盘空间量添加到已用磁盘空间（已调度存储）且已用磁盘空间（存储最大值-保留存储）未超过之后才允许调度新副本实际可用磁盘容量的 200%。

备份还原

1. 集群恢复针对我们的生产集群，由于用户环境数量较多我们无法做到备份用户的数据（基于成本考虑）。在集群发生故障情况下，我们会用rancher恢复集群，前提前提条件是主机数据和底层磁盘在恢复前仍然存在于集群中，可以直接复用。
   具体参考：
   https://longhorn.io/docs/1.3.1/advanced-resources/cluster-restore/restore-to-a-cluster-contains-data-using-rancher-snapshot/
2. 快照对vloume PVC atp325执行快照动作，截图如下：

第一次快照后，往PVC写入数据echo “222”>2.txt ,截图如下：

继续做第二次快照，截图如下：

PVC 325数据截图：

快照恢复到第一次快照：

1. 定时快照可以通过web界面或者yaml文件创建定时快照：
   参考：https://longhorn.io/docs/1.3.1/snapshots-and-backups/scheduling-backups-and-snapshots/

1. CSI 卷克隆支持

1. 部署过程常见错误
   1）etcd 健康检查不通过，出现证书错误的情况，这个报错一般是因为时间不同步导致的。
   
   2）无法访问到
   
   3）Failed to set up SSH tunneling for host，这个报错一般是使用了 root 用户或者 docker sock 配置错误
   
   4）Failed to dial ssh using address，ssh-key 配置错误
   
   5）部署成功之后，有三个文件需要特别保存。
   
   cluster.yml：RKE 集群配置文件。
   kube_config_cluster.yml：集群的 Kubeconfig 文件，此文件包含完全访问集群的凭据。
   cluster.rkestate：Kubernetes 集群状态文件，此文件包含访问集群的重要凭据。
   
   有了以上三个文件，就可以对集群做新增、删除节点、升级集群版本的操作，所以必须要保存好。
   
2. RKE的备份与恢复
   RKE 集群可以自动备份 etcd 节点的快照。在灾难场景下，您可以使用这些快照恢复集群。RKE 将快照保存本地/opt/rke/etcd-snapshots路径下。
   
3. 产品介绍Rancher 是为使用容器的公司打造的容器管理平台。Rancher 简化了使用 Kubernetes 的流程，开发者可以随处运行 Kubernetes（Run Kubernetes Everywhere），满足 IT 需求规范，赋能 DevOps 团队。
4. 产品架构

rancher高可用部署

从，为减少学习成本,我们计划通过helm方式部署在RKE引擎。

这是PVC atp327，是测试部的现货测试环境，计划通过csi卷克隆技术克隆一个相同的测试环境。

编写克隆PVC，#kubectl apply -f cloned-atp327.yaml ,预计需要等待3-5分钟即可完成克隆。

结果截图，cloned-atp327是atp327的克隆卷：

业务测试

现货业务测试

拉取现货的镜像，测试现货业务，用户使用过程中，没有发现异常（测试人员文雪莲）。

deployment迁移测试

资源deployment atp327在node 10.128.8.201上

通过修改nodeSelector参数,让deployment atp327迁移到节点10.128.8.202上。

迁移后，发现atp327一直处于containerCreating状态，查看描述事件，表明PVC处于冲突状态。

从资源类型deployment重建原理上分析，PVC冲突的可能是PVC的访问模式为ReadWriteOnce导致的，ReadWriteOnce仅允许一个deployment挂载PVC，而deployment在重建的过程短暂处于2个（正常运行一个，重建一个）。

kind: PersistentVolumeClaim

apiVersion: v1

metadata:

name: atp326

spec:

accessModes:

- ReadWriteOnce

storageClassName: longhorn

resources:

requests:

storage: 100Gi

把PVC的访问模式为ReadWriteMany模式，再去验证，能正常迁移。

kind: PersistentVolumeClaim

apiVersion: v1

metadata:

name: atp326

spec:

accessModes:

- ReadWriteMany

storageClassName: longhorn

resources:

requests:

storage: 100Gi

尽管PVC的访问模式为ReadWriteMany可以解决PVC冲突的问题，但是针对我们的使用场景，以及考虑到ReadWriteMany技术不太成熟，我们尽量使用ReadWriteOnce访问模式。

这时候需要深入了解应用变更以及升级的原理，增加以下字段就可以解决PVC冲突的问题。（选择停机发布的方式）

1. 停机发布- 把老版的应用实例完全停止，再发布新的版本。

1. 这种发布模式主要为了解决新老版本互不兼容、无法共存的问题，
2. 缺点：是一段时间内服务完全不可用。
3. 优点：资源消耗小，升级速度快

2. 滚动发布 - 分批次逐步替换应用实例。

1. 这种发布模式不会中断服务，同时也不会消耗过多额外的资源，
2. 但由于新老版本实例同时在线，可能导致来自相同客户端的请求在新老版中切换而产生兼容性问题。

3. 蓝绿发布 - 在线上同时部署相同数量的新老版本应用实例。待新版本测试通过后，将流量一次性地切到新的服务实例上来。
4. 这种发布模式解决了停机发布中存在的服务完全不可用问题
5. 但会造成比较大的资源消耗。

节点重启测试

deployment全部运行在node01上，现重启node01,deployment会迁移到node02上：

常见异常问题

PV数据损坏，导致挂载失败

PVC挂载失败，截图如下：

处理过程：

使用 e2fsck 修复错误

下载

wget https://distfiles.macports.org/e2fsprogs/e2fsprogs-1.45.6.tar.gz

tar -zxvf e2fsprogs-1.45.6.tar.gz

安装

cd e2fsprogs-1.45.6

mkdir build && cd build

../configure

make && make install

修复PVC（选择挂载点）：
fsck.ext4 -y /dev/longhorn/pvc-6561339a-6111-481c-a674-b4889c755299

备注：如果e2fsck安装失败，请安装gcc即可

副本数据不可用

异常：数据副本丢失，单个副本failed状态

解决思路：通过界面的salvage挽救副本，发生无法解决，最后在副本所在目录删除无效的其他副本，则恢复正常。

PVC无法重新挂载

故障提示PVC已经附加在rke01,无法重新挂载rke03

解决思路：目前临时的处理办法是按照提示附件到rke03，后续需要找到根本原因

容器无法创建更多进程

故障：ATP在运行过程报错，无法创建更多进程

解决思路：最开始认为系统的进程做了限制，但是我们的容器运行的权限是root，root默认情况下不会限制进程数量，最后定位到是docker版本过低导致的问题，更新docker版本后解决问题。（docker版本更新有报错，百度解决）