前语
知识点
- 定级：入门级
- KubeKey 装置布置 ARM 版 KubeSphere 和 Kubernetes
- ARM 版麒麟 V10 装置布置 KubeSphere 和 Kubernetes 常见问题
实战服务器装备 (个人云上测验服务器)
| 主机名 | IP | CPU | 内存 | 体系盘 | 数据盘 | 用途 |
|---|---|---|---|---|---|---|
| ksp-master-1 | 172.16.33.16 | 8 | 16 | 50 | 200 | KubeSphere/k8s-master/k8s-worker |
| ksp-master-2 | 172.16.33.22 | 8 | 16 | 50 | 200 | KubeSphere/k8s-master/k8s-worker |
| ksp-master-3 | 172.16.33.23 | 8 | 16 | 50 | 200 | KubeSphere/k8s-master/k8s-worker |
| 算计 | 3 | 24 | 48 | 150 | 600 |
实战环境触及软件版别信息
-
服务器芯片：Kunpeng-920
-
操作体系：麒麟 V10 SP2 aarch64
-
KubeSphere：v3.4.0
-
Kubernetes：v1.26.5
-
Containerd：1.6.4
-
KubeKey: v3.0.13
1. 本文简介
本文介绍了如何在 麒麟 V10 aarch64 架构服务器上布置 KubeSphere 和 Kubernetes 集群。咱们将运用 KubeSphere 开发的 KubeKey 东西完结主动化布置，在三台服务器上完结高可用形式最小化布置 Kubernetes 集群和 KubeSphere。
KubeSphere 和 Kubernetes 在 ARM 架构 和 x86 架构的服务器上布置，最大的区别在于一切服务运用的容器镜像架构类型的不同，KubeSphere 开源版关于 ARM 架构的默许支撑能够完结 KubeSphere-Core 功用，即能够完结最小化的 KubeSphere 和完好的 Kubernetes 集群的布置。当启用了 KubeSphere 可插拔组件时，会遇到个别组件布置失利的状况，需求咱们手艺替换官方或是第三方供给的 ARM 版镜像或是依据官方源码手艺构建 ARM 版镜像。假如需求完结开箱即用及更多的技术支撑，则需求购买企业版的 KubeSphere。
本文是我调研 KubeSphere 开源版对 ARM 架构服务器支撑程度的实验进程文档。文中具体的记载了在完结终究布置的进程中，遇到的各种问题报错及相应的处理计划。由于才能有限，本文中所遇到的架构不兼容的问题，大部分采用了手艺替换第三方仓库或是官方其他仓库相同或是相似 ARM 版别镜像的计划。主张计划在出产中运用的读者最好能具备运用官方源码及 DockerFile 构建与 x86 版别完全相同的 ARM 版容器镜像的才能，不要替换附近版别或是运用第三方镜像。也正是由于本文并没有完全运用官方源码及 Dockerfile 构建 ARM 相关镜像，仅仅从头构建了比较简略的 ks-console 组件，所以才取名为不完全攻略。
由于之前现已写过多篇比较具体的装置布置文档，因而，本文不会过多展现指令履行成果的细节，只供给要害的指令输出。
1.1 承认操作体系装备
在履行下文的使命之前，先承认操作体系相关装备。
- 操作体系类型
[root@ks-master-1 ~]# cat /etc/os-release
NAME="Kylin Linux Advanced Server"
VERSION="V10 (Sword)"
ID="kylin"
VERSION_ID="V10"
PRETTY_NAME="Kylin Linux Advanced Server V10 (Sword)"
ANSI_COLOR="0;31"
- 操作体系内核
[root@ks-master-1 ~]# uname -a
Linux KP-Kylin-ZH-01 4.19.90-24.4.v2101.ky10.aarch64 #1 SMP Mon May 24 14:45:37 CST 2021 aarch64 aarch64 aarch64 GNU/Linux
- 服务器 CPU 信息
[root@ksp-master-1 ~]# lscpu
Architecture: aarch64
CPU op-mode(s): 64-bit
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 1
Core(s) per socket: 1
Socket(s): 8
NUMA node(s): 1
Vendor ID: HiSilicon
Model: 0
Model name: Kunpeng-920
Stepping: 0x1
BogoMIPS: 200.00
L1d cache: 512 KiB
L1i cache: 512 KiB
L2 cache: 4 MiB
L3 cache: 256 MiB
NUMA node0 CPU(s): 0-7
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf: Not affected
Vulnerability Mds: Not affected
Vulnerability Meltdown: Not affected
Vulnerability Spec store bypass: Not affected
Vulnerability Spectre v1: Mitigation; __user pointer sanitization
Vulnerability Spectre v2: Not affected
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort: Not affected
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma d
cpop asimddp asimdfhm
2. 操作体系根底装备
请留意，以下操作无特殊阐明时需在一切服务器上履行。本文只选取 Master-1 节点作为演示，并假定其余服务器都已依照相同的方法进行装备和设置。
2.1 装备主机名
hostnamectl set-hostname ksp-master-1
2.2 装备 DNS
echo "nameserver 114.114.114.114" > /etc/resolv.conf
2.3 装备服务器时区
装备服务器时区为 Asia/Shanghai。
timedatectl set-timezone Asia/Shanghai
2.4 装备时间同步
- 装置 chrony 作为时间同步软件。
yum install chrony
- 修正装备文件 /etc/chrony.conf，修正 ntp 服务器装备。
vi /etc/chrony.conf
# 删去或注释一切的 pool 装备
pool pool.ntp.org iburst
# 添加国内的 ntp 服务器，或是指定其他常用的时间服务器
pool cn.pool.ntp.org iburst
# 上面的手艺操作，也能够运用 sed 主动替换
sed -i 's/^pool pool.*/pool cn.pool.ntp.org iburst/g' /etc/chrony.conf
留意：这一步也能够疏忽，运用体系默许装备。
- 重启并设置 chrony 服务开机自发动。
systemctl enable chronyd --now
- 验证 chrony 同步状况
# 履行查看指令
chronyc sourcestats -v
2.5 禁用 SELinux
体系默许启用了 SELinux，为了减少费事，咱们一切的节点都禁用 SELinux。
# 运用 sed 修正装备文件，完结彻底的禁用
sed -i 's/^SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config
# 运用指令，完结暂时禁用，这一步其实不做也行，KubeKey 会主动装备
setenforce 0
2.6 防火墙装备
systemctl stop firewalld && systemctl disable firewalld
2.7 装置体系依靠
在一切节点上，以 root 用户登陆体系，履行下面的指令为 Kubernetes 装置体系根本依靠包。
# 装置 Kubernetes 体系依靠包
yum install curl socat conntrack ebtables ipset ipvsadm -y
3. 操作体系磁盘装备
服务器新增一块数据盘 /dev/vdb（具体姓名取决于虚拟化渠道类型），用于 Containerd 和 Kubernetes Pod 的持久化存储。
请留意，以下操作无特殊阐明时需在集群一切节点上履行。本文只选取 Master-1 节点作为演示，并假定其余服务器都已依照相同的方法进行装备和设置。
3.1 运用 LVM 装备磁盘
为了满足部分用户期望在出产上线后，磁盘容量不足时能够完结动态扩容。本文采用了 LVM 的方法装备磁盘（实践上，本人保护的出产环境，简直不用 LVM）。
- 创立 PV
pvcreate /dev/vdb
- 创立 VG
vgcreate data /dev/vdb
- 创立 LV
# 运用一切空间，VG 姓名为 data，LV 姓名为 lvdata
lvcreate -l 100%VG data -n lvdata
3.2 格局化磁盘
mkfs.xfs /dev/mapper/data-lvdata
3.3 磁盘挂载
- 手艺挂载
mkdir /data
mount /dev/mapper/data-lvdata /data/
- 开机主动挂载
tail -1 /etc/mtab >> /etc/fstab
3.4 创立数据目录
- 创立 OpenEBS 本地数据根目录
mkdir -p /data/openebs/local
- 创立 Containerd 数据目录
mkdir -p /data/containerd
- 创立 Containerd 数据目录软衔接
ln -s /data/containerd /var/lib/containerd
阐明：KubeKey 到 v3.0.13 版停止，一向不支撑在布置的时分更改 Containerd 的数据目录，只能用这种目录软链接到变通方法来添加存储空间（也能够提早手艺装置 Containerd，主张）。
3.5 磁盘装备主动化 Shell 脚本
上述一切操作，都能够整理成主动化装备脚本。
pvcreate /dev/vdb
vgcreate data /dev/vdb
lvcreate -l 100%VG data -n lvdata
mkfs.xfs /dev/mapper/data-lvdata
mkdir /data
mount /dev/mapper/data-lvdata /data/
tail -1 /etc/mtab >> /etc/fstab
mkdir -p /data/openebs/local
mkdir -p /data/containerd
ln -s /data/containerd /var/lib/containerd
4. 装置布置 KubeSphere 和 Kubernetes
4.1 下载 KubeKey
本文将 master-1 节点作为布置节点，把 KubeKey (下文简称 kk) 最新版 (v3.0.13) 二进制文件下载到该服务器。具体 kk 版别号能够在 kk 发行页面 查看。
- 下载最新版的 KubeKey
cd ~
mkdir kubekey
cd kubekey/
# 挑选中文区下载(拜访 GitHub 受限时运用)
export KKZONE=cn
curl -sfL https://get-kk.kubesphere.io | sh -
# 正确的履行效果如下
[root@ksp-master-1 ~]# cd ~
[root@ksp-master-1 ~]# mkdir kubekey
[root@ksp-master-1 ~]# cd kubekey/
[root@ksp-master-1 kubekey]# export KKZONE=cn
[root@ksp-master-1 kubekey]# curl -sfL https://get-kk.kubesphere.io | sh -
Downloading kubekey v3.0.13 from https://kubernetes.pek3b.qingstor.com/kubekey/releases/download/v3.0.13/kubekey-v3.0.13-linux-arm64.tar.gz ...
Kubekey v3.0.13 Download Complete!
[root@ksp-master-1 kubekey]# ll
total 107012
-rwxr-xr-x 1 root root 76357877 Oct 30 16:56 kk
-rw-r--r-- 1 root root 33215241 Nov 7 16:11 kubekey-v3.0.13-linux-arm64.tar.gz
留意： ARM 版的装置包称号为 kubekey-v3.0.13-linux-arm64.tar.gz
- 查看 KubeKey 支撑的 Kubernetes 版别列表
./kk version --show-supported-k8s
留意：输出成果为 KK 支撑的成果，但不代表 KubeSphere 和其他 Kubernetes 也能完美支撑。出产环境主张挑选 v1.24 或是 v1.26。
4.2 创立 Kubernetes 和 KubeSphere 布置装备文件
创立集群装备文件，本示例中，挑选 KubeSphere v3.4.0 和 Kubernetes v1.26.5。因而，指定装备文件称号为 kubesphere-v340-v1265.yaml，假如不指定，默许的文件名为 config-sample.yaml。
./kk create config -f kubesphere-v340-v1265.yaml --with-kubernetes v1.26.5 --with-kubesphere v3.4.0
指令履行成功后，在当前目录会生成文件名为 kubesphere-v340-v1265.yaml 的装备文件。
留意：生成的默许装备文件内容较多，这儿就不做过多展现了，更多具体的装备参数请参阅 官方装备示例。
本文示例采用 3 个节点一起作为 control-plane、etcd 节点和 worker 节点。
修改装备文件 kubesphere-v340-v1265.yaml，首要修正 kind: Cluster 和 kind: ClusterConfiguration 两末节的相关装备
修正 kind: Cluster 末节中 hosts 和 roleGroups 等信息，修正阐明如下。
- hosts：指定节点的 IP、ssh 用户、ssh 暗码、ssh 端口。特别留意： 必定要手艺指定 arch: arm64，否则布置的时分会装置 X86 架构的软件包。
- roleGroups：指定 3 个 etcd、control-plane 节点，复用相同的机器作为 3 个 worker 节点，。
- internalLoadbalancer： 启用内置的 HAProxy 负载均衡器
- domain：自定义了一个 opsman.top
- containerManager：运用了 containerd
- storage.openebs.basePath：新增装备，指定默许存储路径为 /data/openebs/local
修正后的示例如下：
apiVersion: kubekey.kubesphere.io/v1alpha2
kind: Cluster
metadata:
name: sample
spec:
hosts:
- {name: ksp-master-1, address: 172.16.33.16, internalAddress: 172.16.33.16, user: root, password: "P@88w0rd", arch: arm64}
- {name: ksp-master-2, address: 172.16.33.22, internalAddress: 172.16.33.22, user: root, password: "P@88w0rd", arch: arm64}
- {name: ksp-master-3, address: 172.16.33.23, internalAddress: 172.16.33.23, user: root, password: "P@88w0rd", arch: arm64}
roleGroups:
etcd:
- ksp-master-1
- ksp-master-2
- ksp-master-3
control-plane:
- ksp-master-1
- ksp-master-2
- ksp-master-3
worker:
- ksp-master-1
- ksp-master-2
- ksp-master-3
controlPlaneEndpoint:
## Internal loadbalancer for apiservers
internalLoadbalancer: haproxy
domain: lb.opsman.top
address: ""
port: 6443
kubernetes:
version: v1.26.5
clusterName: opsman.top
autoRenewCerts: true
containerManager: containerd
etcd:
type: kubekey
network:
plugin: calico
kubePodsCIDR: 10.233.64.0/18
kubeServiceCIDR: 10.233.0.0/18
## multus support. https://github.com/k8snetworkplumbingwg/multus-cni
multusCNI:
enabled: false
storage:
openebs:
basePath: /data/openebs/local # base path of the local PV provisioner
registry:
privateRegistry: ""
namespaceOverride: ""
registryMirrors: []
insecureRegistries: []
addons: []
修正 kind: ClusterConfiguration 启用可插拔组件，修正阐明如下。
- 启用 etcd 监控
etcd:
monitoring: true # 将 "false" 更改为 "true"
endpointIps: localhost
port: 2379
tlsEnable: true
- 启用运用商店
openpitrix:
store:
enabled: true # 将 "false" 更改为 "true"
- 启用 KubeSphere DevOps 体系
devops:
enabled: true # 将 "false" 更改为 "true"
- 启用 KubeSphere 日志体系
logging:
enabled: true # 将 "false" 更改为 "true"
- 启用 KubeSphere 事件体系
events:
enabled: true # 将 "false" 更改为 "true"
留意：默许状况下，假如启用了事件体系功用，KubeKey 将装置内置 Elasticsearch。关于出产环境，不主张在布置集群时启用事件体系。请在布置完结后，参阅 可插拔组件官方文档 手艺装备。
- 启用 KubeSphere 告警体系
alerting:
enabled: true # 将 "false" 更改为 "true"
- 启用 KubeSphere 审计日志
auditing:
enabled: true # 将 "false" 更改为 "true"
留意：默许状况下，假如启用了审计日志功用，KubeKey 将装置内置 Elasticsearch。关于出产环境，不主张在布置集群时启用审计功用。请在布置完结后，参阅 可插拔组件官方文档 手艺装备。
- 启用 KubeSphere 服务网格
servicemesh:
enabled: true # 将 "false" 更改为 "true"
istio:
components:
ingressGateways:
- name: istio-ingressgateway # 将服务暴露至服务网格之外。默许不开启。
enabled: false
cni:
enabled: false # 启用后，会在 Kubernetes pod 生命周期的网络设置阶段完结 Istio 网格的 pod 流量转发设置作业。
- 启用 Metrics Server
metrics_server:
enabled: true # 将 "false" 更改为 "true"
阐明：KubeSphere 支撑用于 布置 的容器组（Pod）弹性伸缩程序 (HPA)。在 KubeSphere 中，Metrics Server 控制着 HPA 是否启用。
- 启用网络战略、容器组 IP 池，服务拓扑图不启用（姓名排序，对应装备参数排序）
network:
networkpolicy:
enabled: true # 将 "false" 更改为 "true"
ippool:
type: calico # 将 "none" 更改为 "calico"
topology:
type: none # 将 "none" 更改为 "weave-scope"
阐明：
- 从 3.0.0 版别开端，用户能够在 KubeSphere 中装备原生 Kubernetes 的网络战略。
- 容器组 IP 池用于规划容器组网络地址空间，每个容器组 IP 池之间的地址空间不能重叠。
- 启用服务拓扑图以集成 Weave Scope (Docker 和 Kubernetes 的可视化和监控东西)，服务拓扑图显现在您的项目中，将服务之间的衔接联系可视化。
- 由于对应版别 weave-scope 的 arm64 架构的镜像不好找，需求自己构建，可是该功用实践上用途不大了，该项目都现已停止保护了，所以本文终究放弃了启用该功用。
4.3 布置 KubeSphere 和 Kubernetes
接下来咱们履行下面的指令，运用上面生成的装备文件布置 KubeSphere 和 Kubernetes。
export KKZONE=cn
./kk create cluster -f kubesphere-v340-v1265.yaml
上面的指令履行后，首要 kk 会查看布置 Kubernetes 的依靠及其他具体要求。查看合格后，体系将提示您承认装置。输入 yes 并按 ENTER 持续布置。
[root@ksp-master-1 kubekey]# export KKZONE=cn
[root@ksp-master-1 kubekey]# ./kk create cluster -f kubesphere-v340-v1265.yaml
_ __ _ _ __
| | / / | | | | / /
| |/ / _ _| |__ ___| |/ / ___ _ _
| | | | | '_ / _ / _ | | |
| | |_| | |_) | __/ | __/ |_| |
_| _/__,_|_.__/ ____| _/___|__, |
__/ |
|___/
16:25:51 CST [GreetingsModule] Greetings
16:25:51 CST message: [ksp-master-3]
Greetings, KubeKey!
16:25:51 CST message: [ksp-master-1]
Greetings, KubeKey!
16:25:52 CST message: [ksp-master-2]
Greetings, KubeKey!
16:25:52 CST success: [ksp-master-3]
16:25:52 CST success: [ksp-master-1]
16:25:52 CST success: [ksp-master-2]
16:25:52 CST [NodePreCheckModule] A pre-check on nodes
16:25:53 CST success: [ksp-master-1]
16:25:53 CST success: [ksp-master-2]
16:25:53 CST success: [ksp-master-3]
16:25:53 CST [ConfirmModule] Display confirmation form
-------------- ------ ------ --------- ---------- ------- ------- --------- ----------- -------- -------- ------------ ------------ ------------- ------------------ --------------
| name | sudo | curl | openssl | ebtables | socat | ipset | ipvsadm | conntrack | chrony | docker | containerd | nfs client | ceph client | glusterfs client | time |
-------------- ------ ------ --------- ---------- ------- ------- --------- ----------- -------- -------- ------------ ------------ ------------- ------------------ --------------
| ksp-master-1 | y | y | y | y | y | y | y | y | y | | | y | | | CST 16:25:53 |
| ksp-master-2 | y | y | y | y | y | y | y | y | y | | | y | | | CST 16:25:53 |
| ksp-master-3 | y | y | y | y | y | y | y | y | y | | | y | | | CST 16:25:53 |
-------------- ------ ------ --------- ---------- ------- ------- --------- ----------- -------- -------- ------------ ------------ ------------- ------------------ --------------
This is a simple check of your environment.
Before installation, ensure that your machines meet all requirements specified at
https://github.com/kubesphere/kubekey#requirements-and-recommendations
Continue this installation? [yes/no]:
装置进程日志输出比较多，本文只展现重要的一点，必定要调查下载的二进制包，格局为 arm64（篇幅所限，只展现了部分日志输出）。
Continue this installation? [yes/no]: yes
16:26:32 CST success: [LocalHost]
16:26:32 CST [NodeBinariesModule] Download installation binaries
16:26:32 CST message: [localhost]
downloading arm64 kubeadm v1.26.5 ...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 43.3M 100 43.3M 0 0 1016k 0 0:00:43 0:00:43 --:--:-- 1065k
布置完结需求大约 10-30 分钟左右，具体看网速和机器装备（实践布置进程中，必定会由于镜像架构的问题导致组件反常需求手艺干预）。
实践布置时假如不手艺干预，必定会呈现下面的状况 :
clusterconfiguration.installer.kubesphere.io/ks-installer created
18:13:51 CST skipped: [ksp-master-3]
18:13:51 CST skipped: [ksp-master-2]
18:13:51 CST success: [ksp-master-1]
Please wait for the installation to complete: <---<<
20:13:51 CST skipped: [ksp-master-3]
20:13:51 CST skipped: [ksp-master-2]
20:13:51 CST failed: [ksp-master-1]
error: Pipeline[CreateClusterPipeline] execute failed: Module[CheckResultModule] exec failed:
failed: [ksp-master-1] execute task timeout, Timeout=2h
留意：当呈现等候装置完结的滚动条后，应该立即新开终端，运用
kubectl get pod -A关注一切 Pod 的布置状况。依据报错信息，参阅下文的「反常组件处理计划」及时排查处理创立和发动反常的组件。
真正的布置完结后，您应该会在终端上看到类似于下面的输出。提示布置完结的一起，输出中还会显现用户登陆 KubeSphere 的默许办理员用户和暗码。
clusterconfiguration.installer.kubesphere.io/ks-installer created
17:35:03 CST skipped: [ksp-master-3]
17:35:03 CST skipped: [ksp-master-2]
17:35:03 CST success: [ksp-master-1]
#####################################################
### Welcome to KubeSphere! ###
#####################################################
Console: http://172.16.33.16:30880
Account: admin
Password: P@88w0rd
NOTES：
1. After you log into the console, please check the
monitoring status of service components in
"Cluster Management". If any service is not
ready, please wait patiently until all components
are up and running.
2. Please change the default password after login.
#####################################################
https://kubesphere.io 2023-11-07 17:43:50
#####################################################
17:43:53 CST skipped: [ksp-master-3]
17:43:53 CST skipped: [ksp-master-2]
17:43:53 CST success: [ksp-master-1]
17:43:53 CST Pipeline[CreateClusterPipeline] execute successfully
Installation is complete.
Please check the result using the command:
kubectl logs -n kubesphere-system $(kubectl get pod -n kubesphere-system -l 'app in (ks-install, ks-installer)' -o jsonpath='{.items[0].metadata.name}') -f
留意：
- 上面的信息是后补的，实践布置中必定会有中止，需求处理一切组件反常问题后，删去 Pod ks-install，重建布置使命，使命完结后，经过上面终究的
kubectl logs指令查看终究成果。- 当显现上面的布置完结信息后，也不代表一切组件和服务都能正常布置且能供给服务，请查看下文的**「反常组件处理计划」** 排查处理创立和发动反常的组件。
5. 反常组件及处理计划
由于 KubeSphere 社区版对 ARM 的支撑并不完美，默许仅能保证 KubeSphere-Core 在 ARM 架构下能布置成功，当启用了插件后，并不是一切插件都有 ARM 镜像，当没有对应 ARM 版别镜像时，体系拉取 x86 版别的镜像创立并发动服务，因而会导致架构不同引发的服务发动反常，需求依据报错信息处理反常。
处理反常的计划有以下几种：
- 运用官方组件源代码和 Dockerfile 自己构建 ARM 镜像（最优计划，因才能有限，所以本文只触及 ks-console，后续可能会有更新）
- 运用反常组件官方其他仓库或是第三方供给的相同版别的 ARM 镜像（次优计划，优先在官方找，真实没有再找第三方用户供给的镜像）
- 运用反常组件官方其他仓库或是第三方供给的附近版别的 ARM 镜像（保底计划，仅限于研制测验环境）
本末节只要点记载描述了本文新遇到的问题，之前文档中处理过的问题在这儿仅仅简略写了终究的处理进程。
5.1 处理 metrics-server 反常
这个反常是第一个要处理的，在 kk 布置使命的终究，呈现等候布置完结的使命滚动条时就要关注，假如该 Pod 呈现反常需求立即处理。
- 获取适配的 ARM 版镜像（相同版别 KubeSphere 官方 ARM 版镜像）
# 拉取 arm64 镜像
crictl pull registry.cn-beijing.aliyuncs.com/kubesphereio/metrics-server:v0.4.2-arm64 --platform arm64
- 镜像从头打 tag（
可不做）
# 删去 amd64 镜像
#crictl rmi registry.cn-beijing.aliyuncs.com/kubesphereio/metrics-server:v0.4.2
# 从头打 tag
# ctr -n k8s.io images tag registry.cn-beijing.aliyuncs.com/kubesphereio/metrics-server:v0.4.2-arm64 registry.cn-beijing.aliyuncs.com/kubesphereio/metrics-server:v0.4.2
- 从头布置组件
# 修正 Deployment 运用的镜像，并重启
kubectl set image deployment/metrics-server metrics-server=registry.cn-beijing.aliyuncs.com/kubesphereio/metrics-server:v0.4.2-arm64 -n kube-system
kubectl rollout restart deployment/metrics-server -n kube-system
5.2 处理 Argo CD 反常
- 获取适配的 ARM 版镜像（相同版别 KubeSphere 官方 ARM 版镜像）
# 找个相同版别的 ARM 架构的镜像
crictl pull kubespheredev/argocd-applicationset-arm64:v0.4.1
- 镜像从头打 tag（为了坚持镜像称号风格一致）
ctr -n k8s.io images tag docker.io/kubespheredev/argocd-applicationset-arm64:v0.4.1 registry.cn-beijing.aliyuncs.com/kubesphereio/argocd-applicationset-arm64:v0.4.1
- 从头布置组件
# 修正 Deployment 运用的镜像，并重启
kubectl set image deployment/devops-argocd-applicationset-controller applicationset-controller=registry.cn-beijing.aliyuncs.com/kubesphereio/argocd-applicationset-arm64:v0.4.1 -n argocd
kubectl rollout restart deployment/devops-argocd-applicationset-controller -n argocd
- 验证新的 Pod 创立并发动成功
kubectl get pods -o wide -n argocd | grep applicationset-controller
5.3 处理 Istio 反常
- 获取适配的 ARM 版镜像 (Istio 官方附近版别 ARM 镜像)
# 找个附近版别的 ARM 架构的镜像（官方没有 1.14.6 的 ARM 镜像，从 1.15 开端才原生支撑 ARM，所以用了 1.15.7 替代，出产环境能够尝试用 1.14.6 版别的源码编译构建）
crictl pull istio/pilot:1.15.7 --platform arm64
# 保证镜像架构是 arm64
[root@ks-master-2 ~]# crictl inspecti registry.cn-beijing.aliyuncs.com/kubesphereio/pilot:1.15.7 | grep arch
"architecture": "arm64",
- 镜像从头打 tag
ctr -n k8s.io images tag docker.io/istio/pilot:1.15.7 registry.cn-beijing.aliyuncs.com/kubesphereio/pilot:1.15.7
- 从头布置组件
# 修正 Deployment 运用的镜像，并重启
kubectl set image deployment/istiod-1-14-6 discovery=registry.cn-beijing.aliyuncs.com/kubesphereio/pilot:1.15.7 -n istio-system
kubectl rollout restart deployment/istiod-1-14-6 -n istio-system
- 验证新的 Pod 创立并发动成功
kubectl get pods -o wide -n istio-system | grep istio
5.4 处理 http-backupend 反常
- 获取适配的 ARM 版镜像（第三方相同版别 ARM 镜像）
crictl pull mirrorgooglecontainers/defaultbackend-arm64:1.4
- 镜像从头打 tag（为了坚持镜像称号风格一致）
ctr -n k8s.io images tag docker.io/mirrorgooglecontainers/defaultbackend-arm64:1.4 registry.cn-beijing.aliyuncs.com/kubesphereio/defaultbackend-arm64:1.4
- 从头布置组件
# 修正 Deployment 运用的镜像，并重启
kubectl set image deployment/default-http-backend default-http-backend=registry.cn-beijing.aliyuncs.com/kubesphereio/defaultbackend-arm64:1.4 -n kubesphere-controls-system
kubectl rollout restart deployment/default-http-backend -n kubesphere-controls-system
- 验证新的 Pod 创立并发动成功
kubectl get pods -o wide -n kubesphere-controls-system | grep default-http-backend
5.5 处理 Jenkins 反常
- 获取适配的 ARM 版镜像（附近版别 KubeSphere 官方 ARM 版镜像）
# 没有找到同版别的，只能找了一个附近版别的 ARM 架构的镜像
crictl pull docker.io/kubesphere/ks-jenkins:v3.4.1-2.319.3 --platform arm64
# 保证 image 架构是 arm64
[root@ksp-master-1 ~]# crictl inspecti docker.io/kubesphere/ks-jenkins:v3.4.1-2.319.3 | grep arch
"architecture": "arm64",
- 镜像从头打 tag（为了坚持镜像名风格一致）
ctr -n k8s.io images tag docker.io/kubesphere/ks-jenkins:v3.4.1-2.319.3 registry.cn-beijing.aliyuncs.com/kubesphereio/ks-jenkins:v3.4.1-2.319.3
- 从头布置组件
# 修正 Deployment 运用的镜像及镜像拉取战略，并从头布置
kubectl set image deployment/devops-jenkins devops-jenkins=registry.cn-beijing.aliyuncs.com/kubesphereio/ks-jenkins:v3.4.1-2.319.3 -n kubesphere-devops-system
kubectl set image deployment/devops-jenkins copy-default-config=registry.cn-beijing.aliyuncs.com/kubesphereio/ks-jenkins:v3.4.1-2.319.3 -n kubesphere-devops-system
kubectl patch deployment devops-jenkins --patch '{"spec": {"template": {"spec": {"containers": [{"name": "devops-jenkins","imagePullPolicy": "IfNotPresent"}]}}}}' -n kubesphere-devops-system
kubectl patch deployment devops-jenkins --patch '{"spec": {"template": {"spec": {"initContainers": [{"name": "copy-default-config","imagePullPolicy": "IfNotPresent"}]}}}}' -n kubesphere-devops-system
# 删去 pod，体系会主动重建
kubectl delete pod devops-jenkins-774fdb948b-fmmls -n kubesphere-devops-system
# 也能够用 rollout（可选，视状况而定）
kubectl rollout restart deployment/devops-jenkins -n kubesphere-devops-system
5.6 处理 thanos-ruler 反常
- 查看反常 Pod
[root@ksp-master-1 ~]# kubectl get pods -A -o wide | grep -v Runn | grep -v Com
NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
kubesphere-monitoring-system thanos-ruler-kubesphere-0 1/2 CrashLoopBackOff 200 (2m49s ago) 17h 10.233.116.19 ksp-master-2 <none> <none>
kubesphere-monitoring-system thanos-ruler-kubesphere-1 1/2 Error 203 (5m21s ago) 17h 10.233.89.23 ksp-master-3 <none> <none>
- 查看反常 Pod 运用的镜像
[root@ksp-master-1 kubekey]# kubectl describe pod thanos-ruler-kubesphere-0 -n kubesphere-monitoring-system | grep Image:
Image: registry.cn-beijing.aliyuncs.com/kubesphereio/thanos:v0.31.0
Image: registry.cn-beijing.aliyuncs.com/kubesphereio/prometheus-config-reloader:v0.55.1
- 查看反常 Pod 镜像架构（镜像架构没问题）
[root@ksp-master-1 ~]# crictl inspecti registry.cn-beijing.aliyuncs.com/kubesphereio/thanos:v0.31.0 | grep arch
"architecture": "arm64",
[root@ksp-master-1 ~]# crictl inspecti registry.cn-beijing.aliyuncs.com/kubesphereio/prometheus-config-reloader:v0.55.1 | grep arch
"architecture": "arm64",
后边的细节没来的及记载，由于 ks-apiserver 服务反常，重启 coreDNS 容器后，thanos-ruler 也主动创立成功。
5.7 处理 Minio 反常
- 获取适配的 ARM 版镜像（附近版别 Minio 官方 ARM 版镜像）
# 找个附近版别的 ARM 架构的镜像
# minio
crictl pull minio/minio:RELEASE.2020-11-25T22-36-25Z-arm64
# mc
crictl pull minio/mc:RELEASE.2020-11-25T23-04-07Z-arm64
- 镜像从头打 tag
# minio
crictl rmi registry.cn-beijing.aliyuncs.com/kubesphereio/minio:RELEASE.2019-08-07T01-59-21Z
ctr -n k8s.io images tag docker.io/minio/minio:RELEASE.2020-11-25T22-36-25Z-arm64 registry.cn-beijing.aliyuncs.com/kubesphereio/minio:RELEASE.2019-08-07T01-59-21Z
# mc
crictl rmi registry.cn-beijing.aliyuncs.com/kubesphereio/mc:RELEASE.2019-08-07T23-14-43Z
ctr -n k8s.io images tag --force docker.io/minio/mc:RELEASE.2020-11-25T23-04-07Z-arm64 registry.cn-beijing.aliyuncs.com/kubesphereio/mc:RELEASE.2019-08-07T23-14-43Z
- 从头布置组件
# 从头布置,删去旧的 Pod，体系会主动重建（此步的操作也能够运用修正 minio 对应的 deployment 运用的镜像称号的方法）
kubectl delete pod minio-757c8bc7f-tlnts -n kubesphere-system
kubectl delete pod minio-make-bucket-job-fzz95 -n kubesphere-system
5.8 处理 ks-console 反常
ks-console 在 openEuler 22.03 SP2 的 ARM 环境并没有呈现问题，可是在麒麟 V10 上却呈现了反常，阐明操作体系的差异关于服务的布置也有必定的影响。
- 查看反常 Pod
[root@ksp-master-2 ~]# kubectl get pods -A -o wide | grep -v Runn | grep -v Com
NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
kubesphere-system ks-console-6f77f6f49d-wgd94 0/1 CrashLoopBackOff 5 (10s ago) 3m18s 10.233.89.25 ksp-master-3 <none> <none>
- 查看反常 Pod 的日志
[root@ksp-master-2 ~]# kubectl logs ks-console-6f77f6f49d-wgd94 -n kubesphere-system
#
# Fatal process OOM in insufficient memory to create an Isolate
#
<--- Last few GCs --->
<--- JS stacktrace --->
- 查看反常 Pod 运用的镜像
[root@ksp-master-3 ~]# crictl image ls | grep ks-console
registry.cn-beijing.aliyuncs.com/kubesphereio/ks-console v3.4.0 42b2364bcafe3 38.7MB
- 查看反常 Pod 的镜像架构（表面上看着没问题，架构匹配）
[root@ksp-master-3 ~]# crictl inspecti registry.cn-beijing.aliyuncs.com/kubesphereio/ks-console:v3.4.0 | grep archite
"architecture": "arm64",
- 处理计划
## 处理计划，网上说能够替换 node14 来处理，也能够在 node 12 的根底上添加装备参数 --max-old-space-size=xxx， 修正成 node 14 比较简略，先试试
# 处理思路：从头构建镜像，推送到自己的镜像仓库
# Clone 源代码
git clone https://github.com/kubesphere/console.git
cd console
git checkout -b v3.4.0 v3.4.0
# 修正 Dockerfile
vi build/Dockerfile
将 FROM node:12-alpine3.14 统一换成 FROM node:14-alpine3.14
# 从头构建（docker.io/zstack 是自己的镜像仓库地址）
REPO=docker.io/zstack make container
# 从头 tag 并推送到 镜像仓库
docker tag zstack/ks-console:heads-v3.4.0 zstack/ks-console:v3.4.0
docker push zstack/ks-console:v3.4.0
- 从头拉取新的镜像
# 服务器拉取新镜像
crictl pull docker.io/zstack/ks-console:v3.4.0
crictl rmi registry.cn-beijing.aliyuncs.com/kubesphereio/ks-console:v3.4.0
ctr -n k8s.io images tag --force docker.io/zstack/ks-console:v3.4.0 registry.cn-beijing.aliyuncs.com/kubesphereio/ks-console:v3.4.0
- 从头布置
# 修正镜像拉取战略，并从头布置
kubectl patch deployment ks-console --patch '{"spec": {"template": {"spec": {"containers": [{"name": "ks-console","imagePullPolicy": "IfNotPresent"}]}}}}' -n kubesphere-system
5.9 处理组件反常通用计划
在布置 ARM 的 KubeSphere 和 Kubernetes 集群时，遇到的反常大都都是由于镜像架构不匹配形成的，当遇到本文没有触及的反常组件时，能够参阅以下流程处理。
-
查看反常 Pod
-
查看反常 Pod 的日志
-
查看反常 Pod 运用的镜像
-
查看反常 Pod 镜像架构
-
获取适配的 ARM 版镜像
-
镜像从头打 tag
-
从头布置组件
当确认镜像架构没问题时，有些问题能够经过多次删去重建的方法处理。
6. 布置验证
上面的布置使命完结今后，只能阐明根据 ARM 架构的 KubeSphere 和 Kubernetes 集群布置完结了。 可是全体功用是否可用，还需求做一个验证。
本文只做根本验证，不做具体全功用验证，有需求的朋友请自行验证测验。
6.1 KubeSphere 办理控制台验证集群状况
咱们打开浏览器拜访 master-1 节点的 IP 地址和端口 30880，能够看到 KubeSphere 办理控制台的登录页面。
输入默许用户 admin 和默许暗码 P@88w0rd，然后点击「登录」。
登录后，体系会要求您更改 KubeSphere 默许用户 admin 的默许暗码，输入新的暗码并点击「提交」。
提交完结后，体系会跳转到 KubeSphere admin 用户作业台页面，该页面显现了当前 KubeSphere 版别为 v3.4.0，可用的 Kubernetes 集群数量为 1。
接下来，单击左上角的「渠道办理」菜单，挑选「集群办理」。
进入集群办理界面，在该页面能够查看集群的根本信息，包括集群资源用量、Kubernetes 状况、节点资源用量 Top、体系组件、东西箱等内容。
单击左侧「节点」菜单，点击「集群节点」能够查看 Kubernetes 集群可用节点的具体信息。
单击左侧「体系组件」菜单，能够查看已装置组件的具体信息。
接下来咱们粗略的看一下咱们布置集群时启用的可插拔插件的状况。
- 运用商店
- KubeSphere 日志体系
- KubeSphere 事件体系
- KubeSphere 审计日志
- KubeSphere 告警体系
- KubeSphere 服务网格（实践功用未验证测验）
- Metrics Server（页面没有，需求启用 HPA 时验证）
- 网络战略（实践中也不必定能用到）
- 容器组 IP 池
KubeSphere DevOps 体系是实践运用中的要点，咱们经过几张截图专项验证（完结进程略，一切组件状况正常，实践测验中流水线也能正常创立）
- DevOps 体系组件
- DevOps 项目及流水线（创立项目 -> 创立流水线 -> 运用官方供给的模板修改流水线 -> 运转流水线）
终究看一组监控图表来完毕咱们的图形验证。
- 概览
- 物理资源监控
- etcd 监控
- API Server 监控
- 调度器监控
- 资源用量排行
- Pod 监控
6.2 Kubectl 指令行验证集群状况
本末节仅仅简略的看了一下根本状况，并不全面，更多的细节需求咱们自己体验探究。
- 查看集群节点信息
在 master-1 节点运转 kubectl 指令获取 Kubernetes 集群上的可用节点列表。
kubectl get nodes -o wide
在输出成果中能够看到，当前的 Kubernetes 集群有三个可用节点、节点的内部 IP、节点人物、节点的 Kubernetes 版别号、容器运转时及版别号、操作体系类型及内核版别等信息。
[root@ksp-master-1 ~]# kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
ksp-master-1 Ready control-plane,worker 18h v1.26.5 172.16.33.16 <none> Kylin Linux Advanced Server V10 (Sword) 4.19.90-24.4.v2101.ky10.aarch64 containerd://1.6.4
ksp-master-2 Ready control-plane,worker 18h v1.26.5 172.16.33.22 <none> Kylin Linux Advanced Server V10 (Sword) 4.19.90-24.4.v2101.ky10.aarch64 containerd://1.6.4
ksp-master-3 Ready control-plane,worker 18h v1.26.5 172.16.33.23 <none> Kylin Linux Advanced Server V10 (Sword) 4.19.90-24.4.v2101.ky10.aarch64 containerd://1.6.4
- 查看 Pod 列表
输入以下指令获取在 Kubernetes 集群上运转的 Pod 列表，按作业负载在 NODE 上的分布排序。
# 默许按 NAMESPACE 排序
# 按节点排序
kubectl get pods -A -o wide --sort-by='.spec.nodeName'
在输出成果中能够看到， Kubernetes 集群上有多个可用的命名空间 kube-system、kubesphere-control-system、kubesphere-monitoring-system、kubesphere-system、argocd 和 istio-system 等，一切 pod 都在运转。
留意：
- 成果略，请自行查看或是参阅上一篇根据 OpenEuler ARM 的布置文档
- 假如 Pod 状况不是 Running 请依据本文的第 5 末节「反常组件及处理计划」中的内容进行比对处理，文中未触及的问题能够参阅本文的处理思路自行处理。
- 查看 Image 列表
输入以下指令获取在 Kubernetes 集群节点上现已下载的 Image 列表。
crictl images ls
# 成果略，请自行查看或是参阅上一篇根据 OpenEuler ARM 的布置文档
至此，咱们现已完结了布置 3 台 服务器，复用为 Master 节点 和 Worker 节点的最小化的 Kubernetes 集群和 KubeSphere。咱们还经过 KubeSphere 办理控制台和指令行界面查看了集群的状况。
接下来咱们将在 Kubernetes 集群上布置一个简略的 Nginx Web 服务器，测验验证 Kubernetes 和 KubeSphere 根本功用是否正常。
7. 布置测验资源
本示例运用指令行东西在 Kubernetes 集群上布置一个 Nginx Web 服务器并运用 KubeSphere 图形化办理控制台查看布置的资源信息。
7.1 创立 Nginx Deployment
运转以下指令创立一个布置 Nginx Web 服务器的 Deployment。此示例中，咱们将创立具有两个副本根据 nginx:alpine 镜像的 Pod。
kubectl create deployment nginx --image=nginx:alpine --replicas=2
7.2 创立 Nginx Service
创立一个新的 Kubernetes 服务，服务称号 nginx，服务类型 Nodeport，对外的服务端口 80。
kubectl create service nodeport nginx --tcp=80:80
7.3 验证 Nginx Deployment 和 Pod
- 运转以下指令查看创立的 Deployment 和 Pod 资源。
kubectl get deployment -o wide
kubectl get pods -o wide
- 查看成果如下：
[root@ksp-master-1 ~]# kubectl get deployment -o wide
NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
nginx 2/2 2 2 26s nginx nginx:alpine app=nginx
[root@ksp-master-1 ~]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-6c557cc74d-bz6qd 1/1 Running 0 26s 10.233.84.73 ksp-master-1 <none> <none>
nginx-6c557cc74d-z2w9b 1/1 Running 0 26s 10.233.116.50 ksp-master-2 <none> <none>
7.4 验证 Nginx 镜像架构
- 运转以下指令查看 Nginx Image 的架构类型
crictl inspecti nginx:alpine | grep architecture
- 查看成果如下：
[root@ks-master-1 ~]# crictl inspecti nginx:alpine | grep architecture
"architecture": "arm64"
7.5 验证 Nginx Service
运转以下指令查看可用的服务列表，在列表中咱们能够看到 nginx 服务类型 为 Nodeport，并在 Kubernetes 主机上开放了 30563 端口。
kubectl get svc -o wide
查看成果如下
[root@ksp-master-1 ~]# kubectl get svc -o wide
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
kubernetes ClusterIP 10.233.0.1 <none> 443/TCP 19h <none>
nginx NodePort 10.233.62.164 <none> 80:30792/TCP 97s app=nginx
7.6 验证服务
运转以下指令拜访布置的 Nginx 服务，验证服务是否成功布置。
- 验证直接拜访 Pod
curl 10.233.84.73
- 验证拜访 Service
curl 10.233.62.164
- 验证拜访 Nodeport
curl 172.16.33.16:30792
7.7 在办理控制台查看
接下来咱们回到 KubeSphere 办理控制台，在办理控制台查看现已创立的资源。
阐明： KubeSphere 的办理控制台具有友爱地、图形化创立 Kubernetes 各种资源的功用，首要是截图太费事了，所以本文采用了指令行的方法简略的创立了测验资源。
仅仅在查看的时分给咱们演示一下 KubeSphere 办理控制台的根本功用，实践运用中，咱们能够运用图形化方法创立和办理 Kubernetes 资源。
- 登录 KubeSphere 办理控制台，点击「渠道办理」，挑选「集群办理」。
- 单击集群办理页面左侧的「运用负载」，点击「作业负载」。默许会看到一切类型为布置的作业负载。
咱们运用的是 admin 账户，因而能够看到一切的作业负载，在查找框输入 nginx，只显现 nginx 布置作业负载。
- 单击布置列表中的 nginx，能够查看更具体的信息，而且办理 nginx 布置 (Deployment)。
- 单击容器组中的一个 nginx 容器，能够查看容器的状况、监控等信息。
- 回到「渠道办理」-「集群办理」页面，单击集群办理页面左侧的「运用负载」，点击「服务」。默许会看到一切类型为服务的作业负载。
咱们运用的是 admin 账户，因而能够看到一切的作业负载，在查找框输入 nginx，只显现 nginx 服务作业负载。
- 单击服务列表中的 nginx，能够查看更具体的信息，而且办理 nginx 服务 (Service)。
至此，咱们完结了将 Nginx Web 服务器布置到 Kubernetes 集群，并经过 KubeSphere 办理控制台查看、验证了布置的 Deployment、Pod、Service 的具体信息。
本文仅对 ARM 架构下布置的 KubeSphere 和 Kubernetes 做了最根本的资源创立的验证测验，更多的完好的可插拔组件的测验并未触及，请读者依据需求自己验证、测验。
在验证测验进程中遇到的问题大都都应该是镜像架构不匹配形成的，参阅本文第 5 末节中处理问题的思路和流程，应该能处理大部分问题。
8. 常见问题
8.1 问题 1
- 问题现象
TASK [metrics-server : Metrics-Server | Waitting for metrics.k8s.io ready] *****
FAILED - RETRYING: Metrics-Server | Waitting for metrics.k8s.io ready (60 retries left).
FAILED - RETRYING: Metrics-Server | Waitting for metrics.k8s.io ready (59 retries left).
FAILED - RETRYING: Metrics-Server | Waitting for metrics.k8s.io ready (58 retries left).
......
fatal: [localhost]: FAILED! => {"attempts": 60, "changed": true, "cmd": "/usr/local/bin/kubectl get apiservice | grep metrics.k8s.ion", "delta": "0:00:00.077617", "end": "2023-11-07 16:50:27.274329", "rc": 0, "start": "2023-11-07 16:50:27.196712", "stderr": "", "stderr_lines": [], "stdout": "v1beta1.metrics.k8s.io kube-system/metrics-server False (MissingEndpoints) 10m", "stdout_lines": ["v1beta1.metrics.k8s.io kube-system/metrics-server False (MissingEndpoints) 10m"]}
PLAY RECAP *********************************************************************
localhost : ok=6 changed=4 unreachable=0 failed=1 skipped=3 rescued=0 ignored=0
- 处理计划
# 处理 metrics-server 反常后，重启 ks-install pod
kubectl delete pod ks-installer-6674579f54-cgxpk -n kubesphere-system
8.2 问题 2
- 问题现象
# 登陆 console 提示
request to http://ks-apiserver/oauth/token failed, reason: getaddrinfo EAI_AGAIN ks-apiserver
# 查看 coredns pod 日志
kubectl logs coredns-d9d84b5bf-fmm64 -n kube-system
....
[ERROR] plugin/errors: 2 1393460958862612009.7706119398981012766.ip6.arpa. HINFO: read tcp 10.88.0.3:52062->114.114.114.114:53: i/o timeout
[ERROR] plugin/errors: 2 1393460958862612009.7706119398981012766.ip6.arpa. HINFO: read tcp 10.88.0.3:52086->114.114.114.114:53: i/o timeout
- 处理计划
# 毁掉一切的 coredns pod，主动重建后康复
kubectl delete pod coredns-d9d84b5bf-fmm64 -n kube-system
8.3 问题 3
- 问题现象
[root@ksp-master-1 kubekey]# kubectl get pod -A | grep -v Run
NAMESPACE NAME READY STATUS RESTARTS AGE
kubesphere-logging-system opensearch-logging-curator-opensearch-curator-28322940-zsvl5 0/1 Error 0 8h
[root@ksp-master-1 kubekey]# kubectl logs opensearch-logging-curator-opensearch-curator-28322940-zsvl5 -n kubesphere-logging-system
2023-11-07 17:00:52,595 INFO Preparing Action ID: 1, "delete_indices"
2023-11-07 17:00:52,595 INFO Creating client object and testing connection
2023-11-07 17:00:52,598 WARNING Use of "http_auth" is deprecated. Please use "username" and "password" instead.
2023-11-07 17:00:52,598 INFO kwargs = {'hosts': ['opensearch-cluster-data.kubesphere-logging-system.svc'], 'port': 9200, 'use_ssl': True, 'ssl_no_validate': True, 'http_auth': 'admin:admin', 'client_cert': None, 'client_key': None, 'aws_secret_key': None, 'ssl_show_warn': False, 'aws_key': None, 'url_prefix': '', 'certificate': None, 'aws_token': None, 'aws_sign_request': False, 'timeout': 30, 'connection_class': <class 'opensearchpy.connection.http_requests.RequestsHttpConnection'>, 'verify_certs': False, 'aws_region': False, 'api_key': None}
2023-11-07 17:00:52,598 INFO Instantiating client object
2023-11-07 17:00:52,598 INFO Testing client connectivity
2023-11-07 17:00:52,852 WARNING GET https://opensearch-cluster-data.kubesphere-logging-system.svc:9200/ [status:503 request:0.253s]
2023-11-07 17:00:52,856 WARNING GET https://opensearch-cluster-data.kubesphere-logging-system.svc:9200/ [status:503 request:0.004s]
2023-11-07 17:00:52,861 WARNING GET https://opensearch-cluster-data.kubesphere-logging-system.svc:9200/ [status:503 request:0.004s]
2023-11-07 17:00:52,865 WARNING GET https://opensearch-cluster-data.kubesphere-logging-system.svc:9200/ [status:503 request:0.003s]
2023-11-07 17:00:52,865 ERROR HTTP 503 error: OpenSearch Security not initialized.
2023-11-07 17:00:52,865 CRITICAL Curator cannot proceed. Exiting.
- 处理计划
没记载更多细节，终究成果是在 coreDNS 的 pod 重启后，自行修正了。 在呈现反常 pod 的时分都能够经过多次毁掉，等体系主动重建的方法修正。
8.4 问题 4
- 问题现象
验证日志，事件、审计日志时，发现没有数据，经排查发现是 fluent-bit pod 反常，日志中呈现很多的如下过错（这个问题在 OpenEuler 上没有呈现）。
2023-11-09T12:05:00.921862916 08:00 <jemalloc>: Unsupported system page size
2023-11-09T12:05:00.921866296 08:00 Error in GnuTLS initialization: ASN1 parser: Element was not found.
2023-11-09T12:05:00.921868756 08:00 <jemalloc>: Unsupported system page size
2023-11-09T12:05:00.921871256 08:00 <jemalloc>: Unsupported system page size
2023-11-09T12:05:00.921881196 08:00 <jemalloc>: Unsupported system page size
2023-11-09T12:05:00.921884556 08:00 malloc: Cannot allocate memory
2023-11-09T12:05:00.922208611 08:00 level=error msg="Fluent bit exited" error="exit status 1"
2023-11-09T12:05:00.922214631 08:00 level=info msg=backoff delay=-1s
2023-11-09T12:05:00.922228062 08:00 level=info msg="backoff timer done" actual=18.39s expected=-1s
2023-11-09T12:05:00.922644408 08:00 level=info msg="Fluent bit started"
- 处理计划
# 一番查找发现，fluent-bit jmalloc 调用 pagesize 大小问题引起的，导致 fluent-bit 不能正常作业
# https://github.com/jemalloc/jemalloc/issues/467
# arm 架构上面:
# 在 debian ubuntu 等操作体系，默许的 pagesize 是 4KB
# 可是在 centos rhel 系列，默许的 pagesize 是 64KB
# 银河麒麟 v10的 太大，导致 fluent-bit 不能正常作业
# 查看 麒麟 V10 PAGESIZE 设置
[root@ksp-master-2 ~]# getconf PAGESIZE
65536
## 处理计划：换个版别，v1.9.9 经测验不可用，终究挑选 v2.0.6
# 删去 amd64 镜像并重打 Tag（受限于 fluentbit-operator，会主动变更任何手改的装备，就不改 deployment 的装备了）
crictl pull kubesphere/fluent-bit:v2.0.6 --platform arm64
crictl rmi registry.cn-beijing.aliyuncs.com/kubesphereio/fluent-bit:v1.9.4
ctr -n k8s.io images tag --force docker.io/kubesphere/fluent-bit:v2.0.6 registry.cn-beijing.aliyuncs.com/kubesphereio/fluent-bit:v1.9.4
# 毁掉 pod 重建（每个节点的都要毁掉）
kubectl delete pod fluent-bit-l5lx4 -n kubesphere-logging-system
9. 总结
本文首要实战演示了在 ARM 版麒麟 V10 SP2 服务器上，运用 KubeKey v3.0.13 主动化布置最小化 KubeSphere 3.4.0 和 Kubernetes 1.26.5 高可用集群的具体进程。
布置完结后，咱们还运用 KubeSphere 办理控制台和 kubectl 指令行，查看并验证了 KubeSphere 和 Kubernetes 集群的状况。
终究咱们经过在 Kubenetes 集群上布置 Nginx Web 服务器验证了 Kubernetes 集群和 KubeSphere 的可用性，并经过在 KubeSphere 办理控制台查看 Nginx Pod 和服务状况的操作，了解了 KubeSphere 的根本用法。
归纳总结全文首要触及以下内容：
- 麒麟 V10 SP2 aarch64 操作体系根底装备
- 操作体系数据盘 LVM 装备、磁盘挂载、数据目录创立
- KubeKey 下载及创立集群装备文件
- 运用 KubeKey 主动化布置 KubeSphere 和 Kubernetes 集群
- 处理 ARM 版 KubeSphere 和 Kubernetes 服务组件反常的问题
- 布置完结后的 KubeSphere 和 Kubernetes 集群状况验证
- 布置 Nginx 验证测验 KubeSphere 和 Kubernetes 根本功用
本文的核心价值在于，要点介绍了在 KubeSphere 和 Kubernetes 集群布置进程中遇到的常见问题及对应的处理计划。一起，指出了在麒麟 V10 和 openEuler 22.03 两种不同操作体系上遇到的不同的问题。
本文布置环境虽然是根据 Kunpeng-920 芯片的 aarch64 版 麒麟 V10 SP2，可是关于 CentOS、openEuler 等 ARM 版操作体系以及飞扬（FT-2500）等芯片也有必定的借鉴含义。
本文介绍的内容可直接用于研制、测验环境，关于出产环境有必定的参阅含义，绝对不能直接用于出产环境。
本文的不完全测验结论： KubeSphere 和 Kubernetes 根本功用可用，DevOps 功用可用，现已能满足大部分的普通业务场景。
本文由博客一文多发渠道 OpenWrite 发布！
