2023年1月21日 更新支持最新版rancher，版本号为v2.7.1。k3s依赖版本也从1.22升级到1.24，以下教程内容已经更新，部分信息没有更新不影响部署，已在Oracle上验证通过。
申请Oracle甲骨文的Arm实例已经很久了，甲骨文的配置相当的高，4核24G内存100G硬盘5TB流量，但一直没有正儿八经地用起来，属实是有些浪费资源了。于是前些天就把手上有的这些机子组了一个跨区ARM集群，分属三个区域，分别为：春川(Chuncheon)、东京(Tokyo)、首尔(Seoul)。由于三个机房是物理隔离开的，没有直接组在一起的链路，于是除了使用甲骨文官方的VPN之外，我们还可以直接使用Wireguard将这三台机子组到一个局域网内，这样就方便组建集群了。
先来看看夸张的ARM 12核心，70G内存，158G可用存储的k3s集群。
OK～前情交待完毕，以下是这次部署所需达成的目标：
- 前面提到，三个机器不是一个区域的，所以需要将三台主机使用Wireguard组成一个局域网
- 先不考虑高可用问题，由首尔作为master控制节点，与春川和东京共为工作节点提供服务
- 不使用甲骨文的LB，由主机自行提供服务，域名指向其中任意一台都可以访问，也可搭配智能解析系统
- 需要在lb位置集成modsecurity，过滤一些恶意请求
- 不使用traefik作为前端暴露组件，而是使用更容易理解的nginx ingress(也因为里面自带集成了modsecurity)
- 需要一个好用的控制面板，kubectl操作起来还得连接服务器，稍显麻烦。这里直接使用rancher，主要是习惯了。
- 需要使用分布式存储，这里直接使用rancher的Longhorn进行部署
- 需要部署数据备份组件，这里使用开源的velero，可以定期备份到远程的S3存储服务器，作为最后的灾备恢复选项。（鬼知道什么时候会被k掉）
以下为实操步骤：
注意：这里统一使用ubuntu 20.04的发行版，最低版本为18.04，但眼下不适合用最新版的 22.04 发行版，kubernetes使用v1.24稳定版，版本太新会有其他问题的
注意2：这里有两个概念，一个是公网IP，一个是网卡IP，在甲骨文、阿里云等等的云服务厂商那里，公网IP是不会直接给到实例中的系统的，而是给一个nat后的IP，这个IP在外部是不能访问的。因此，在进行接下来的配置中，要注意这点，在本例中，我是直接使用各自节点的ipv6公网地址。
使用Wireguard组局域网
在本例中，我们需要组建一个局域网，但与网上搜索到的直接使用wireguard不同，我们需要借助Kilo对wireguard进行管理和连接，因此在这里只需要安装好wireguard即可，后续操作在k3s中进行。
安装wireguard
直接在终端内分别为三个区域的主机安装wireguard即可，使用命令：
apt update
apt install wireguard安装部署 k3s server 节点
curl -sfL https://get.k3s.io | K3S_CLUSTER_INIT=true \
INSTALL_K3S_EXEC="server" \
INSTALL_K3S_CHANNEL=v1.24 \
sh -s - --node-label "topology.kubernetes.io/region=seoul" \
--node-label "master-node=true" \
--tls-san {{ server_public_ip }} \
--advertise-address {{ server_public_ip }} \
--disable traefik \
--flannel-backend none \
--kube-proxy-arg "metrics-bind-address=0.0.0.0" \
--kube-apiserver-arg "feature-gates=EphemeralContainers=true"简要说明：
- K3S_CLUSTER_INIT=true : 集群模式，会安装内置的 etcd，而不是 sqlite3；
- INSTALL_K3S_EXEC=”server” : 指定为server节点
- INSTALL_K3S_CHANNEL=v1.24 : 安装的K3S版本，这里选择1.24 稳定版本，最新的rancher v2.7的版本推荐1.23以上的版本，这里选择1.24稳定版；
- –node-label “topology.kubernetes.io/region=seoul” : 设置当前服务器的label为首尔区域；
- –node-label “master-node=true” : 设置为主节点；
- –tls-san {{ server_public_ip }}: {{ server_public_ip }} 改为当前服务器公网 IPv4地址，–tls-san
这个选项在 TLS 证书中增加了一个额外的主机名或 IP 作为备用名称，如果你想通过 IP 和主机名访问，可以多次指定，多个值之间用英文半角逗号分隔。注意：如果不指定 –tls-san {{ server_public_ip }}，可能会导致 kubectl 无法通过 server_public_ip 来访问集群； - –advertise-address {{ server_public_ip }}：{{ server_public_ip }} 改为当前服务器公网 IPv4地址，用于agent连接K3S Server的API，但是注意不要指定 –node-external-ip {{ server_public_ip }}，会导致无法获得用户真实IP；
- –disable traefik : 关闭traefik，后面安装nginx-ingress
- –flannel-backend none : 关闭默认的flannel CNI，后面安装Kilo
- –kube-proxy-arg “metrics-bind-address=0.0.0.0” : kube-proxy 参数，这个参数直接影响 Metrics 的获取；
- –kube-apiserver-arg “feature-gates=EphemeralContainers=true” : （可选）启用 feature-gates：EphemeralContainers，方便在不重启 pod 的情况下附加 sidecar 进行调试。
执行后，检查安装结果，可以看到节点已经可以找到了：
# kubectl get node
NAME STATUS ROLES AGE VERSION
instance-20190921-1325 NotReady control-plane,etcd,master 0h01m v1.22.12+k3s1可以看到节点状态为 NotReady ，这是正常的，因为我们还没有添加网络CNI网络组件，接下来就开始安装它。
安装Kilo CNI网络组件
网络拓扑
然后我们需要指定第一台节点的拓扑，后续添加上来的agent节点会自动添加进来，但仍然建议对其网络进行拓扑定义，现在先定义第一台：
kubectl annotate nodes instance-20190921-1325 kilo.squat.ai/location="seoul"
kubectl annotate nodes instance-20190921-1325 kilo.squat.ai/force-endpoint="{{ server_public_ipv6 }}:51820"
kubectl annotate nodes instance-20190921-1325 kilo.squat.ai/persistent-keepalive=20简单说明：
- location : 对节点进行位置定义，方便维护
- force-endpoint : 自动发现节点时，会有endpoint的定义，这个地址如果你是用内网ipv4，就容易变成不可路由的地址，所以这里建议直接用绑定到网卡上的
IPv6地址，进行覆盖定义 - persistent-keepalive : 是wireguard的配置选项，保活
安装Kilo CNI组件
kubectl apply -f https://raw.githubusercontent.com/squat/kilo/main/manifests/crds.yaml
wget https://raw.githubusercontent.com/squat/kilo/main/manifests/kilo-k3s.yaml在第二步使用wget，是因为需要对Kilo的DaemonSet进行修改，在我们案例中，各区没有直接的网络连接，最好使用fullmesh模式，这部分的说明，参考：https://kilo.squat.ai/docs/topology/#full-mesh，添加–mesh-granularity=full到kilo-k3s.yaml守护程序pod模板中：
- name: kilo
image: squat/kilo
args:
- --kubeconfig=/etc/kubernetes/kubeconfig
- --hostname=$(NODE_NAME)
- --mesh-granularity=full
env:
- name: NODE_NAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName然后执行安装
kubectl apply -f kilo-k3s.yaml验证Kilo安装
- 在 kube-system 命名空间下的 pod 中，可以找到koli的pod已经成功运行，状态为 RUNNING
- 执行 kubectl get node 时查看到的节点状态由 NotReady 变为 Ready
- 在 k3s server 节点上，已经有 kilo 的相关 annotations，示例如下：
apiVersion: v1 kind: Node metadata: annotations: k3s.io/external-ip: {{ server_public_ip }} k3s.io/hostname: instance-20190921-1325 k3s.io/internal-ip: 10.0.0.170 ... kilo.squat.ai/discovered-endpoints: '{"{{ public_key_1 }}":{"IP":"{{ agent_public_ip_1 }}","Port":51820,"Zone":""},"{{ public_key_2 }}":{"IP":"{{ agent_public_ip_2 }}","Port":51820,"Zone":""}}' kilo.squat.ai/endpoint: '{{ server_public_ipv6 }}:51820' kilo.squat.ai/force-endpoint: '{{ server_public_ipv6 }}:51820' kilo.squat.ai/granularity: location kilo.squat.ai/internal-ip: 10.0.0.170/24 kilo.squat.ai/key: {{ private_key }} kilo.squat.ai/last-seen: "1658647061" kilo.squat.ai/location: seoul kilo.squat.ai/persistent-keepalive: "20" kilo.squat.ai/wireguard-ip: 10.4.0.2/16 ...可以看到 wireguard-ip，这个是节点的wg ip地址，后面新增agent节点进来之后，也会自动分配到地址。
安装部署 k3s agent节点
部署agent节点前，需要在server节点先获取到token，后面添加agent节点时都需要带上，可以添加多台agent节点，这里以添加两台为例子。
获取token：
cat /var/lib/rancher/k3s/server/node-token执行命令添加agent节点
curl -sfL https://get.k3s.io | K3S_URL=https://{{ server_public_ip }}:6443 \
K3S_TOKEN={{ server_token }} \
INSTALL_K3S_EXEC="agent" \
INSTALL_K3S_CHANNEL=v1.24 \
sh -s - --node-label "topology.kubernetes.io/region=chuncheon" \
--node-label "worker-node=true" \
--kube-proxy-arg "metrics-bind-address=0.0.0.0"简要说明：
- INSTALL_K3S_EXEC=”agent” : 定义添加的是agent节点，将只作为工作节点加入集群，没有etcd；
- INSTALL_K3S_CHANNEL=v1.24 : 安装的K3S版本，这里选择1.24 稳定版本，与server节点要一致；
- K3S_URL=https://{{ server_public_ip }}:6443 : 指定server节点api访问地址
- K3S_TOKEN={{ server_token }} : 使用上一步获取到的token值
- –node-label “topology.kubernetes.io/region=chuncheon” : 设置当前服务器的label为春川区域；
- –node-label “worker-node=true” : 设置为工作节点；
- –kube-proxy-arg “metrics-bind-address=0.0.0.0” : kube-proxy 参数，这个参数直接影响 Metrics 的获取；
执行后等待1分钟左右，回到k3s server节点，执行kubectl get node，即可看到新添加的节点，同样，这里我们对添加进来的节点进行拓扑定义
kubectl annotate nodes instance-20190931-1637 kilo.squat.ai/location="chuncheon"
kubectl annotate nodes instance-20190931-1637 kilo.squat.ai/persistent-keepalive=20Kilo CNI的网卡说明
网卡列表
- kilo0：WireGuard VPN 网络，用以 Node 间组建 VPN 内网；如果同一个区域内存在VPC，内网连接则优先使用VPC内网，只有走外部其他区域的链路才会走WireGuard 加密网络；
- kube-bridge: 桥接网络，Node内 Pod 的网卡与宿主机的网卡进行连接，如需跨网通信，则会路由到WireGuard VPN 网络共享通信；
- tunl0：Bridge 模式下，多主机网络通信需要额外配置主机路由，或使用 overlay 网络。通过 Kilo 来自动配置。引用网上的一张图：
路由表
首尔机器上的路由表：
# ip r
default via 10.0.0.1 dev enp0s3 proto dhcp src 10.0.0.170 metric 100
10.0.0.0/24 dev enp0s3 proto kernel scope link src 10.0.0.170
10.0.0.98 via 10.4.0.1 dev kilo0 proto static onlink
10.0.0.246 via 10.4.0.3 dev kilo0 proto static onlink
10.4.0.0/16 dev kilo0 proto kernel scope link src 10.4.0.2
10.42.0.0/24 dev kube-bridge proto kernel scope link src 10.42.0.1
10.42.1.0/24 via 10.4.0.1 dev kilo0 proto static onlink
10.42.2.0/24 via 10.4.0.3 dev kilo0 proto static onlink
169.254.0.0/16 dev enp0s3 proto dhcp scope link src 10.0.0.170 metric 100春川的路由表：
# ip r
default via 10.0.0.1 dev enp0s3 proto dhcp src 10.0.0.98 metric 100
10.0.0.0/24 dev enp0s3 proto kernel scope link src 10.0.0.98
10.0.0.170 via 10.4.0.2 dev kilo0 proto static onlink
10.0.0.246 via 10.4.0.3 dev kilo0 proto static onlink
10.4.0.0/16 dev kilo0 proto kernel scope link src 10.4.0.1
10.42.0.0/24 via 10.4.0.2 dev kilo0 proto static onlink
10.42.1.0/24 dev kube-bridge proto kernel scope link src 10.42.1.1
10.42.2.0/24 via 10.4.0.3 dev kilo0 proto static onlink
169.254.0.0/16 dev enp0s3 proto dhcp scope link src 10.0.0.98 metric 100东京的路由表：
# ip r
default via 10.0.0.1 dev enp0s3 proto dhcp src 10.0.0.246 metric 100
10.0.0.0/24 dev enp0s3 proto kernel scope link src 10.0.0.246
10.0.0.98 via 10.4.0.1 dev kilo0 proto static onlink
10.0.0.170 via 10.4.0.2 dev kilo0 proto static onlink
10.4.0.0/16 dev kilo0 proto kernel scope link src 10.4.0.3
10.42.0.0/24 via 10.4.0.2 dev kilo0 proto static onlink
10.42.1.0/24 via 10.4.0.1 dev kilo0 proto static onlink
10.42.2.0/24 dev kube-bridge proto kernel scope link src 10.42.2.1
169.254.0.0/16 dev enp0s3 proto dhcp scope link src 10.0.0.246 metric 100在这里可以看到，这三台机器，已经通过各自的路由，分别都找到了对方。
以下操作都只在主节点上进行了，两台agent节点可以退出终端了。
安装helm部署软件
helm常用于k8s里的软件部署，在k3s里同样需要安装，执行命令：
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash安装部署nginx-ingress
nginx-ingress 直接使用helm进行安装，执行命令：
helm upgrade --install ingress-nginx ingress-nginx \
--repo https://kubernetes.github.io/ingress-nginx \
--namespace ingress-nginx --create-namespace \
--set controller.service.type=LoadBalancer \
--set controller.ingressClassResource.default=true \
--set controller.watchIngressWithoutClass=true安装部署rancher控制面板
新版本rancher 2.7的安装与2.6一样，都是直接用helm安装就好，不要再用2.6以下的版本啦，区别很大。直接运行以下命令进行安装，需要提前准备的是管理后台域名的证书
首先添加helm的repo
helm repo add rancher-latest https://releases.rancher.com/server-charts/latest
helm repo update接着将域名证书放在/etc/rancher/cert路径中
# cd /tmp
# tar -zxf cert.tgz
# mkdir -p /etc/rancher/cert
# mv fullchain.pem /etc/rancher/cert
# mv private.pem /etc/rancher/cert然后创建cattle-system的命名空间和tls密钥
kubectl create namespace cattle-system
kubectl -n cattle-system create secret tls tls-rancher-ingress \
--cert=/etc/rancher/cert/fullchain.pem \
--key=/etc/rancher/cert/private.pem最后安装rancher面板
helm install rancher rancher-latest/rancher \
--namespace cattle-system \
--set hostname=cluster.domain.com \
--set replicas=3 \
--set ingress.tls.source=secret说明：
- –set replicas= 这个值，如果为1，则部署后是随机在集群中的任意节点的，这里一般取值数是你的node数，本例是三台，因此取值为3
等待2分钟后，执行命令获取登录信息，复制粘贴到浏览器打开进行初始化，访问前请先对域名进行解析。
echo https://cluster.domain.com/dashboard/?setup=$(kubectl get secret --namespace cattle-system bootstrap-secret -o go-template='{{.data.bootstrapPassword|base64decode}}')安装部署Longhorn分布式存储
完成上步对rancher部署后，进入左下角带齿轮图标的 Cluster Tools，找到 Longhorn 点击安装，一路默认点下一步就好，等待安装完成就好。
安装部署velero备份还原组件
velero是k8s下用于备份命名空间下容器的最佳利器，同样也适用于k3s，以下为安装步骤
安装velero
首先从官方github上下载软件进行安装，注意选择arm64的软件架构
# cd /tmp
# wget https://github.com/vmware-tanzu/velero/releases/download/v1.9.0/velero-v1.9.0-linux-arm64.tar.gz
# tar xvf velero-*-linux-*.tar.gz
# cd velero-*-linux-*复制到运行环境中，检查版本是否为目标版本
# cp velero /usr/local/bin/
# velero version --client-only
Client:
Version: v1.9.0
Git commit: 6021f148c4d7721285e815a3e1af761262bff029配置命令行自动补全
# echo 'source <(velero completion bash)' >> ~/.bashrc
# velero completion bash > /etc/bash_completion.d/velero配置velero
velero一般使用是搭配s3存储，然后定义好备份时间后，就会在时间到达的时候，自动备份到指定的s3存储，所以在配置velero之前，请先准备一个s3存储服务，可以说aws的s3，也可以是自己搭建的minio服务，首先定义好access_key和secret_key：
cat > credentials-velero << EOF
[default]
aws_access_key_id = fsjDhferKQCZnYtA9h8F
aws_secret_access_key = Fw1Wch7fkS2iKS3S55j1LOxHindEllpOnjUIet2N
EOF然后定义环境变量，为该s3存储的位置信息和存储桶信息(以下值根据你的服务情况而定)
export S3_CONFIG_BUCKET=velero
export S3_CONFIG_REGION=eu-sto-1
export S3_CONFIG_S3URL=https://s3.amaaws.com然后开始安装，在这里需要定义k3s的kubeconfig文件，我遵从k8s的使用习惯，是将rancher k3s的配置信息写进本地家路径下的.kube/config中，实际情况你需要根据情况而进行修改
velero --kubeconfig /root/.kube/config install \
--provider aws \
--plugins=velero/velero-plugin-for-aws:v1.5.0 \
--bucket ${S3_CONFIG_BUCKET} \
--secret-file ./credentials-velero \
--use-volume-snapshots=false \
--use-restic \
--backup-location-config region=${S3_CONFIG_REGION},s3ForcePathStyle="true",s3Url=${S3_CONFIG_S3URL} \
--prefix velero验证安装结果，如果有报错，可以在日志中看到的，执行命令：
kubectl logs deployment/velero -n velero卸载velero
如果配置出错或不想使用velero进行备份了，可以非常方便地进行卸载操作，执行命令：
velero uninstall使用velero进行单次备份
velero backup create app-1 \
--include-namespaces app \
--default-volumes-to-restic简要说明：
- app-1 为本次备份的名称，方便后续查找和恢复，唯一
- –include-namespaces app : velero遵从按命名空间进行备份，所有位于该命名空间下的资料都会被当成一个备份条件进行备份
- –default-volumes-to-restic : 开启这个选项后，就可以备份到 pvc 里面的内容了，就不仅仅是yaml配置信息，是完整的备份。
tips：可以随时查看备份的详情，例如在备份进行中时，可以使用命令查看进度
velero backup describe app-1使用velero进行循环定时备份
velero schedule create app-12h \
--include-namespaces app \
--default-volumes-to-restic \
--schedule="@every 12h"简要说明：
- 与单次备份不同，这里使用schedule create，创建一个计划任务的方式创建备份任务
- –schedule : 定义了间隔时间，例如 @every 12h，代表间隔12小时备份一次，例如 @daily ，则为每日备份一次
使用velero进行还原
还原操作适用于回档或进行迁移，首先在集群b安装好运行环境和velero后，配置好s3的信息，就可以执行命令获取备份列表：
# velero backup get执行恢复：
velero restore create --from-backup app-1配置ModSecurity
在nginx-ingress中，默认已经包含ModSecurity的库，并也有OWASP的规则，只是默认情况下没有开启，我们可以在ingress-nginx的configmaps里，添加配置开启这部分的功能，其他功能可以参考这个网址，酌情开启。
kubectl patch configmaps -n ingress-nginx ingress-nginx-controller -p '{"data":{ "brotli-level": "4","compute-full-forwarded-for": "true","enable-brotli": "true","enable-modsecurity": "true","enable-ocsp": "true","enable-owasp-modsecurity-crs": "true","enable-real-ip": "true","forwarded-for-header": "X-Forwarded-For","gzip-level": "4","max-worker-connections": "65535","modsecurity-snippet": "SecRuleEngine On\n","proxy-add-original-uri-header": "true","proxy-body-size": "0","ssl-buffer-size": "16k","use-forwarded-headers": "true","use-gzip": "true","worker-cpu-affinity": "auto","worker-processes": "auto","worker-rlimit-nofile": "300000"}}'这里开启后会对所有ingress都起作用，如果不需要modsecurity的，注意可以不用理会这条，不必修改就好
开启modsecurity之后的朋友，还需要对rancher的ingress，关闭功能，防止一些莫名其妙的控制面板报错
kubectl patch ingress -n cattle-system rancher -p '{"metadata": {"annotations": {"nginx.ingress.kubernetes.io/enable-modsecurity": "false","nginx.ingress.kubernetes.io/enable-owasp-core-rules": "false","nginx.ingress.kubernetes.io/modsecurity-snippet": "SecRuleEngine Off\n"}}}'安装Cert-manager管理证书
直接kubectl 一把梭了，执行：
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.8.2/cert-manager.yaml然后给需要分配证书的ns分配发行者，这里我们直接用letsencrypt提供的证书，太方便了
kubectl -n icodex create -f - <<EOF
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: letsencrypt-prod
namespace: icodex
spec:
acme:
email: icodex@msn.com
privateKeySecretRef:
name: letsencrypt-prod
server: https://acme-v02.api.letsencrypt.org/directory
solvers:
- http01:
ingress:
class: nginx
EOF然后给域名分配证书
kubectl -n icodex create -f - <<EOF
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: web-domain-com
namespace: icodex
spec:
secretName: web-domain-com-tls
duration: 2160h
renewBefore: 360h
commonName: web.domain.com
isCA: false
privateKey:
algorithm: RSA
encoding: PKCS1
size: 2048
dnsNames:
- web.domain.com
- app.domain.com
issuerRef:
name: letsencrypt-prod
EOF等待数分钟后，或者通过命令查询证书分配情况，当看到Type: Ready时，即代表证书已经申请成功，回到ingress那里，给域名指定一个证书就可以了。
至此安装完毕，所有pod如下：
# kubectl get po -A
NAMESPACE NAME READY STATUS RESTARTS AGE
cattle-fleet-local-system fleet-agent-57497ff7dc-b8kl5 1/1 Running 0 3h12m
cattle-fleet-system fleet-controller-5746685958-szdjn 1/1 Running 0 3h13m
cattle-fleet-system gitjob-cc9948fd7-xzb75 1/1 Running 0 3h13m
cattle-monitoring-system alertmanager-rancher-monitoring-alertmanager-0 2/2 Running 0 3h7m
cattle-monitoring-system prometheus-rancher-monitoring-prometheus-0 3/3 Running 0 3h7m
cattle-monitoring-system pushprox-k3s-server-client-5gck9 1/1 Running 0 3h7m
cattle-monitoring-system pushprox-k3s-server-client-hhfj8 1/1 Running 0 3h7m
cattle-monitoring-system pushprox-k3s-server-client-pgrbh 1/1 Running 0 3h7m
cattle-monitoring-system pushprox-k3s-server-proxy-f4f5d4874-gfkmc 1/1 Running 0 3h7m
cattle-monitoring-system rancher-monitoring-grafana-57777cc795-2pzs6 3/3 Running 0 3h7m
cattle-monitoring-system rancher-monitoring-kube-state-metrics-5bc8bb48bd-jmb2j 1/1 Running 0 3h7m
cattle-monitoring-system rancher-monitoring-operator-f79dc4944-lg8m8 1/1 Running 0 3h7m
cattle-monitoring-system rancher-monitoring-prometheus-adapter-8846d4757-qcjcd 1/1 Running 0 3h7m
cattle-monitoring-system rancher-monitoring-prometheus-node-exporter-hq82r 1/1 Running 0 3h7m
cattle-monitoring-system rancher-monitoring-prometheus-node-exporter-mmp8n 1/1 Running 0 3h7m
cattle-monitoring-system rancher-monitoring-prometheus-node-exporter-z99jt 1/1 Running 0 3h7m
cattle-system rancher-7649d589ff-gj894 1/1 Running 0 3h14m
cattle-system rancher-7649d589ff-mm5jx 1/1 Running 0 3h14m
cattle-system rancher-7649d589ff-xfcm7 1/1 Running 0 3h14m
cattle-system rancher-webhook-6958cfcddf-xhqwk 1/1 Running 0 3h12m
cert-manager cert-manager-66b646d76-qmxms 1/1 Running 0 165m
cert-manager cert-manager-cainjector-59dc9659c7-tzhzm 1/1 Running 0 165m
cert-manager cert-manager-webhook-7d8f555998-kh5zl 1/1 Running 0 165m
icodex nginx-6dd7b9db9b-79rdp 1/1 Running 0 178m
icodex nginx-6dd7b9db9b-cs2tm 1/1 Running 0 178m
icodex nginx-6dd7b9db9b-w94d8 1/1 Running 0 178m
icodex php-fpm-5c5758b88-7tcqx 1/1 Running 0 178m
icodex php-fpm-5c5758b88-kw4pp 1/1 Running 0 178m
icodex php-fpm-5c5758b88-pgg7n 1/1 Running 0 178m
ingress-nginx ingress-nginx-controller-5b7cf87848-dnbt8 1/1 Running 0 3h31m
ingress-nginx svclb-ingress-nginx-controller-9fdqg 2/2 Running 0 3h31m
ingress-nginx svclb-ingress-nginx-controller-dglh6 2/2 Running 0 3h31m
ingress-nginx svclb-ingress-nginx-controller-szs9s 2/2 Running 0 3h31m
kube-system coredns-7796b77cd4-b5gwb 1/1 Running 0 5h16m
kube-system kilo-5khs9 1/1 Running 0 5h5m
kube-system kilo-8574c 1/1 Running 0 5h3m
kube-system kilo-jqw5f 1/1 Running 0 5h12m
kube-system local-path-provisioner-84bb864455-85dtg 1/1 Running 0 5h16m
kube-system metrics-server-ff9dbcb6c-jk5v2 1/1 Running 0 5h16m
longhorn-system csi-attacher-8b4cc9cf6-dj55n 1/1 Running 0 3h8m
longhorn-system csi-attacher-8b4cc9cf6-mj78z 1/1 Running 0 3h8m
longhorn-system csi-attacher-8b4cc9cf6-n8v7v 1/1 Running 0 3h8m
longhorn-system csi-provisioner-59b7b8b7b8-5skdn 1/1 Running 0 3h8m
longhorn-system csi-provisioner-59b7b8b7b8-tddz2 1/1 Running 0 3h8m
longhorn-system csi-provisioner-59b7b8b7b8-xqzjp 1/1 Running 0 3h8m
longhorn-system csi-resizer-68ccff94-gh9fx 1/1 Running 0 3h8m
longhorn-system csi-resizer-68ccff94-lxlst 1/1 Running 0 3h8m
longhorn-system csi-resizer-68ccff94-rkftz 1/1 Running 0 3h8m
longhorn-system csi-snapshotter-6d7d679c98-477s4 1/1 Running 0 3h8m
longhorn-system csi-snapshotter-6d7d679c98-bt9ww 1/1 Running 0 3h8m
longhorn-system csi-snapshotter-6d7d679c98-qkcff 1/1 Running 0 3h8m
longhorn-system engine-image-ei-d474e07c-2nk6r 1/1 Running 0 3h8m
longhorn-system engine-image-ei-d474e07c-jqsgl 1/1 Running 0 3h8m
longhorn-system engine-image-ei-d474e07c-vh48h 1/1 Running 0 3h8m
longhorn-system instance-manager-e-8b411f4a 1/1 Running 0 3h8m
longhorn-system instance-manager-e-da92c7e5 1/1 Running 0 3h8m
longhorn-system instance-manager-e-fb0588b7 1/1 Running 0 3h8m
longhorn-system instance-manager-r-5c615480 1/1 Running 0 3h8m
longhorn-system instance-manager-r-9e4dac9d 1/1 Running 0 3h8m
longhorn-system instance-manager-r-cfd922a1 1/1 Running 0 3h8m
longhorn-system longhorn-csi-plugin-fmc6b 2/2 Running 0 3h8m
longhorn-system longhorn-csi-plugin-g62hj 2/2 Running 0 3h8m
longhorn-system longhorn-csi-plugin-k7mlz 2/2 Running 0 3h8m
longhorn-system longhorn-driver-deployer-7ffd665594-2q8rm 1/1 Running 0 3h9m
longhorn-system longhorn-manager-55hjs 1/1 Running 1 (3h8m ago) 3h9m
longhorn-system longhorn-manager-mdtn2 1/1 Running 1 (3h8m ago) 3h9m
longhorn-system longhorn-manager-twg2m 1/1 Running 0 3h9m
longhorn-system longhorn-ui-556866b6bb-6wpb7 1/1 Running 0 3h9m
longhorn-system share-manager-pvc-7a347acd-b8e8-44df-a2c0-4b4ec54d84fc 1/1 Running 0 3h4m
velero restic-8qkjv 1/1 Running 0 156m
velero restic-b9nfn 1/1 Running 0 156m
velero restic-jmt9n 1/1 Running 0 156m
velero velero-79fd55b75d-q68lm 1/1 Running 0 156m最后是完成后的一些图片，目前已经稳定运行半个月。
后记：Arm架构的服务器在几个大厂的推动下，取得不错的成绩，在程序方面也有许多开发者做了这部分的兼容，使用起来是没有问题的。未来以arm为代表的精简指令集的soc必将在服务器领域取得不错的成绩的。
创作不易，转载请著名出处，谢谢！
相关推荐: 使用OpenLiteSpeed后如何开启HTTP/3的支持
本文为DirectAdmin面板如何使用OpenLiteSpeed系列的第三章：第一章：DirectAdmin面板如何使用OpenLiteSpeed替代默认的Apache第二章：如果OpenLiteSpeed使用了CloudFlare等CDN如何显示访客的真实…
© 版权声明
本站所有文章，仅代表文章作者个人观点，如对观点有疑义时不用怀疑，您绝对是对的。
您也可以联系文章作者本人进行修改，若内容侵权或非法，可以联系我们进行处理。
任何个人或组织，转载、发布本站文章到任何网站、书籍等各类媒体平台，必须在文末署名文章出处并链接到本站相应文章的URL地址。
本站文章如转载自其他网站，会在文末署名原文出处及原文URL的跳转链接，如有遗漏，烦请告知修正。
如若本站文章侵犯了原著者的合法权益，亦可联系我们进行处理。
您也可以联系文章作者本人进行修改，若内容侵权或非法，可以联系我们进行处理。
任何个人或组织，转载、发布本站文章到任何网站、书籍等各类媒体平台，必须在文末署名文章出处并链接到本站相应文章的URL地址。
本站文章如转载自其他网站，会在文末署名原文出处及原文URL的跳转链接，如有遗漏，烦请告知修正。
如若本站文章侵犯了原著者的合法权益，亦可联系我们进行处理。
THE END
hi6个月前0
请问有详细一点的自己搭建的教程吗你好7个月前0
你好，可以再帮我看看吗？ 我已经按照你的方法设定了，还是一样，wordpress后台的 Purge Varnish Cache 插件还是清除不到cache，依旧显示 the varnish control terminal is not responding at。谢谢https://mjj.today/i/Srk2Tz https://mjj.today/i/Srkcoi你好7个月前0
对，你说的没错，我配置的时候改了一些东西，现在我按照你的教学，可以启动了，网页可以缓存了，不过wordpress 清除cache 那个插件没用的，我输入本地回环地址127.0.0.1 :6082 ，再输入API key ，插件显示the varnish control terminal is not responding at 127.0.0.1:6082，就你图片那样，然后试一下点击清除cache 那里，他显示error，研究了一天，还是没有不行。你好7个月前1
你好，为啥我按照你的方法，到第三部分，去到真正后源的服务器设定Varnish 部分，我填了真正后源的IP跟端口跟域名，然后重启 Varnish ，就出现这样了？ 这是怎么回事？ 谢谢[Linux] AMH 7.1 https://amh.sh[varnish-6.6 start] ================================================== =========== [OK] varnish-6.6 is already installed. Could not delete 'vcl_boot.1713549650.959259/vgc.sym': No such file or directory Error: Message from VCC-compiler: VCL version declaration missing Update your VCL to Version 4 syntax, and add vcl 4.1; on the first line of the VCL files. ('/home/usrdata/varnish/default.conf' Line 1 Pos 1) ...#---Running VCC-compiler failed, exited with 2 VCL compilation failedchu7个月前0
很完善的教程‘hu7个月前0
我用gmail EMAIL_SERVER="smtp://********@gmail.com:bpyfv*********chry@smtp.gmail.com:587"叽喳7个月前0
MAIL_SERVER="smtp://no-reply@vort.me:password123@wednesday.mxrouting.net:587"大佬 这个使用outlook 或者gmail 是什么样子的格式？ 邮寄已经开启smtp了hu7个月前0
输入框的问题解决了，我没有设置反代，NEXTAUTH_URL改为域名+端口就好了