Guía incompleta para implementar KubeSphere 3.4.0 en Kylin V10 para ARM

Desde datos hasta aplicaciones de modelos grandes, el 25 de noviembre se celebró la Conferencia Hangzhou Yuanchuang para compartir consejos de desarrollo.

Prefacio

Puntos de conocimiento

Clasificación: nivel de entrada
KubeKey instala e implementa la versión ARM de KubeSphere y Kubernetes
Preguntas frecuentes sobre la instalación e implementación de KubeSphere y Kubernetes en Kirin V10 para ARM

Configuración real del servidor (servidor de prueba en la nube personal)

nombre de la CPU	IP	UPC	Memoria	disco del sistema	disco de datos	usar
ksp-master-1	172.16.33.16	8	dieciséis	50	200	KubeSphere/k8s-master/k8s-trabajador
ksp-master-2	172.16.33.22	8	dieciséis	50	200	KubeSphere/k8s-master/k8s-trabajador
ksp-master-3	172.16.33.23	8	dieciséis	50	200	KubeSphere/k8s-master/k8s-trabajador
total	3	24	48	150	600

El entorno de combate real implica información sobre la versión del software.

Chip de servidor: Kunpeng-920
Sistema operativo: Kirin V10 SP2 aarch64
KubeSphere: v3.4.0
Kubernetes: v1.26.5
En contenedor: 1.6.4
Clave de Kube: v3.0.13

1. Introducción a este artículo

Este artículo presenta cómo implementar clústeres de KubeSphere y Kubernetes en el servidor de arquitectura Kirin V10 aarch64 . Utilizaremos la herramienta KubeKey desarrollada por KubeSphere para implementar la implementación automatizada e implementar el modo de alta disponibilidad en tres servidores para minimizar la implementación de clústeres de Kubernetes y KubeSphere.

KubeSphere y Kubernetes se implementan en servidores de arquitectura ARM y arquitectura x86. La mayor diferencia radica en el tipo de arquitectura de imagen de contenedor utilizada por todos los servicios. El soporte predeterminado de la versión de código abierto de KubeSphere para la arquitectura ARM puede realizar la función KubeSphere-Core, que puede lograr minimización Implementación de KubeSphere y clústeres completos de Kubernetes. Cuando los componentes conectables de KubeSphere están habilitados, la implementación de componentes individuales fallará. Necesitamos reemplazar manualmente la imagen de la versión ARM proporcionada por el funcionario o un tercero o crear manualmente la imagen de la versión ARM basada en el código fuente oficial. Si necesita un funcionamiento listo para usar y más soporte técnico, debe comprar la versión empresarial de KubeSphere.

Este artículo es un documento de mi proceso experimental para investigar el soporte de la versión de código abierto de KubeSphere para servidores de arquitectura ARM. El artículo registra en detalle los diversos problemas y errores encontrados durante la implementación final y las soluciones correspondientes. Debido a las capacidades limitadas, la mayoría de los problemas de incompatibilidad arquitectónica encontrados en este artículo se resolvieron reemplazando manualmente los repositorios de terceros u otros repositorios oficiales con imágenes de versión ARM iguales o similares. Se recomienda que los lectores que planeen usarlo en producción tengan la capacidad de usar el código fuente oficial y DockerFile para construir la versión ARM de la imagen del contenedor que sea exactamente igual a la versión x86. No reemplace versiones similares ni use imágenes de terceros. Precisamente porque este artículo no utiliza completamente el código fuente oficial y Dockerfile para crear imágenes relacionadas con ARM, sino que solo reconstruye el componente ks-console relativamente simple , se denomina guía incompleta .

Dado que antes se han escrito muchos documentos de instalación e implementación relativamente detallados, este artículo no mostrará demasiados detalles de los resultados de la ejecución del comando, sino que solo proporcionará el resultado del comando clave.

1.1 Confirmar la configuración del sistema operativo

Antes de realizar las siguientes tareas, confirme las configuraciones relacionadas con el sistema operativo.

Tipo de sistema operativo

[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"

núcleo del sistema operativo

[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

Información de la CPU del servidor

[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. Configuración básica del sistema operativo

Tenga en cuenta que las siguientes operaciones deben realizarse en todos los servidores a menos que se especifique lo contrario. Este artículo solo selecciona el nodo Master-1 para demostración y asume que los otros servidores se han configurado de la misma manera.

2.1 Configurar el nombre del host

hostnamectl set-hostname ksp-master-1

2.2 Configurar DNS

echo "nameserver 114.114.114.114" > /etc/resolv.conf

2.3 Configurar la zona horaria del servidor

Configure la zona horaria del servidor en Asia/Shanghai .

timedatectl set-timezone Asia/Shanghai

2.4 Configurar la sincronización horaria

Instale chrony como software de sincronización horaria.

yum install chrony

Modifique el archivo de configuración /etc/chrony.conf y modifique la configuración del servidor 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

Nota: Este paso también se puede ignorar y se utiliza la configuración predeterminada del sistema.

Reinicie y configure el servicio chrony para que se inicie automáticamente al arrancar.

systemctl enable chronyd --now

Verificar el estado de sincronización de crony

# 执行查看命令
chronyc sourcestats -v

2.5 Deshabilitar SELinux

SELinux está habilitado de forma predeterminada en el sistema. Para reducir problemas, SELinux está deshabilitado en todos nuestros nodos.

# 使用 sed 修改配置文件，实现彻底的禁用
sed -i 's/^SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config

# 使用命令，实现临时禁用，这一步其实不做也行，KubeKey 会自动配置
setenforce 0

2.6 Configuración del cortafuegos

systemctl stop firewalld && systemctl disable firewalld

2.7 Instalar dependencias del sistema

En todos los nodos, inicie sesión en el sistema como usuario root y ejecute el siguiente comando para instalar los paquetes de dependencia básicos del sistema para Kubernetes.

# 安装 Kubernetes 系统依赖包
yum install curl socat conntrack ebtables ipset ipvsadm -y

3. Configuración del disco del sistema operativo

El servidor agrega un nuevo disco de datos /dev/vdb (el nombre específico depende del tipo de plataforma de virtualización), que se utiliza para el almacenamiento persistente de Containerd y Kubernetes Pod .

Tenga en cuenta que las siguientes operaciones deben realizarse en todos los nodos del clúster a menos que se especifique lo contrario. Este artículo solo selecciona el nodo Master-1 para demostración y asume que los otros servidores se han configurado de la misma manera.

3.1 Utilice LVM para configurar discos

Para satisfacer los deseos de algunos usuarios, se puede lograr una expansión dinámica cuando la capacidad del disco es insuficiente después de que la producción esté en línea. Este artículo usa LVM para configurar el disco ( de hecho, el entorno de producción que mantengo rara vez usa LVM ).

Crear PV

 pvcreate /dev/vdb

CrearVG

vgcreate data /dev/vdb

Crear VI

# 使用所有空间，VG 名字为 data，LV 名字为 lvdata
lvcreate -l 100%VG data -n lvdata

3.2 Formatear disco

mkfs.xfs /dev/mapper/data-lvdata

3.3 Montaje del disco

Montaje manual

mkdir /data
mount /dev/mapper/data-lvdata /data/

Montar automáticamente en el arranque

tail -1 /etc/mtab >> /etc/fstab

3.4 Crear directorio de datos

Crear el directorio raíz de datos local de OpenEBS

mkdir -p /data/openebs/local

Crear directorio de datos en contenedores

mkdir -p /data/containerd

Cree una conexión suave al directorio de datos de Containerd

ln -s /data/containerd /var/lib/containerd

Nota: Hasta la versión v3.0.13, KubeKey no admitía cambiar el directorio de datos de Containerd durante la implementación. Solo puede usar el enlace suave de este directorio como solución alternativa para aumentar el espacio de almacenamiento (también puede instalar Containerd manualmente con anticipación, recomendado ) .

3.5 Script de shell automatizado de configuración del disco

Todas las operaciones anteriores se pueden organizar en scripts de configuración automatizados.

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. Instalar e implementar KubeSphere y Kubernetes

4.1 Descargar KubeKey

Este artículo utiliza el nodo master-1 como nodo de implementación y descarga la última versión ( v3.0.13 ) del archivo binario de KubeKey (en lo sucesivo, kk) al servidor. El número de versión de kk específico se puede ver en la página de lanzamiento de kk .

Descargue la última versión de 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

Nota: El nombre del paquete de instalación de la versión ARM es kubekey-v3.0.13-linux-arm64.tar.gz

Vea la lista de versiones de Kubernetes compatibles con KubeKey

 ./kk version --show-supported-k8s

Nota: Los resultados de salida son los admitidos por KK, pero eso no significa que KubeSphere y otros Kubernetes también puedan admitirlo perfectamente. Se recomienda elegir v1.24 o v1.26 para el entorno de producción.

4.2 Crear archivos de configuración de implementación de Kubernetes y KubeSphere

Cree un archivo de configuración de clúster. En este ejemplo, seleccione KubeSphere v3.4.0 y Kubernetes v1.26.5. Por lo tanto, el nombre del archivo de configuración especificado es kubesphere-v340-v1265.yaml . Si no se especifica, el nombre del archivo predeterminado es config-sample.yaml .

./kk create config -f kubesphere-v340-v1265.yaml --with-kubernetes v1.26.5 --with-kubesphere v3.4.0

Una vez que el comando se ejecute correctamente, se generará un archivo de configuración llamado kubesphere-v340-v1265.yaml en el directorio actual.

Nota: El archivo de configuración predeterminado generado tiene mucho contenido, por lo que no lo mostraré en detalle aquí. Para parámetros de configuración más detallados, consulte el ejemplo de configuración oficial .

El ejemplo de este artículo utiliza tres nodos como plano de control, nodo etcd y nodo trabajador al mismo tiempo.

Edite el archivo de configuración kubesphere-v340-v1265.yaml, modifique principalmente las configuraciones relevantes en las dos secciones: tipo: Cluster y tipo: ClusterConfiguration.

Modifique la información de hosts y roleGroups en el tipo: sección Clúster . Las instrucciones de modificación son las siguientes.

hosts: especifique la IP del nodo, el usuario ssh, la contraseña ssh y el puerto ssh. Nota especial: asegúrese de especificar arch: arm64 manualmente ; de lo contrario, se instalarán paquetes de software de arquitectura X86 durante la implementación.
roleGroups: especifique 3 nodos etcd y de plano de control, y reutilice la misma máquina como 3 nodos trabajadores.
internalLoadbalancer: habilite el equilibrador de carga HAProxy integrado
dominio: personalizado un opsman.top
contenedorManager: se utiliza contenedord
Storage.openebs.basePath: Nueva configuración , especifique la ruta de almacenamiento predeterminada como /data/openebs/local

El ejemplo modificado es el siguiente:

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: []

Modifique el tipo: ClusterConfiguration para habilitar componentes conectables. Las instrucciones de modificación son las siguientes.

Habilitar el monitoreo de etcd

etcd:
    monitoring: true # 将 "false" 更改为 "true"
    endpointIps: localhost
    port: 2379
    tlsEnable: true

Habilitar tienda de aplicaciones

openpitrix:
  store:
    enabled: true # 将 "false" 更改为 "true"

Habilitar el sistema KubeSphere DevOps

devops:
  enabled: true # 将 "false" 更改为 "true"

Habilitar el sistema de registro de KubeSphere

logging:
  enabled: true # 将 "false" 更改为 "true"

Habilitar el sistema de eventos KubeSphere

events:
  enabled: true # 将 "false" 更改为 "true"

Nota: De forma predeterminada, KubeKey instalará Elasticsearch integrado si la función del sistema de eventos está habilitada. Para entornos de producción, no se recomienda habilitar el sistema de eventos al implementar un clúster. Una vez completada la implementación, consulte la documentación oficial de los componentes conectables para la configuración manual.

Habilitar el sistema de alarma KubeSphere

alerting:
  enabled: true # 将 "false" 更改为 "true"

Habilite los registros de auditoría de KubeSphere

auditing:
  enabled: true # 将 "false" 更改为 "true"

Nota: De forma predeterminada, KubeKey instalará Elasticsearch integrado si la función de registro de auditoría está habilitada. Para entornos de producción, no se recomienda habilitar la auditoría al implementar un clúster. Una vez completada la implementación, consulte la documentación oficial de los componentes conectables para la configuración manual.

Habilitar la malla de servicios de KubeSphere

servicemesh:
enabled: true # 将 "false" 更改为 "true"
istio:
  components:
    ingressGateways:
    - name: istio-ingressgateway # 将服务暴露至服务网格之外。默认不开启。
      enabled: false
    cni:
      enabled: false # 启用后，会在 Kubernetes pod 生命周期的网络设置阶段完成 Istio 网格的 pod 流量转发设置工作。

Habilitar servidor de métricas

metrics_server:
  enabled: true # 将 "false" 更改为 "true"

Nota: KubeSphere admite el programa de escalado elástico (HPA) del grupo de contenedores (Pod) para la implementación . En KubeSphere, Metrics Server controla si HPA está habilitado.

Habilite la política de red y el grupo de IP del grupo de contenedores, pero deshabilite el mapa de topología del servicio (ordenar por nombre, correspondiente a la ordenación de parámetros de configuración)

network:
  networkpolicy:
    enabled: true # 将 "false" 更改为 "true"
  ippool:
    type: calico # 将 "none" 更改为 "calico"
  topology:
    type: none # 将 "none" 更改为 "weave-scope"

ilustrar:

A partir de la versión 3.0.0, los usuarios pueden configurar políticas de red nativas de Kubernetes en KubeSphere.

El grupo de IP del grupo de contenedores se utiliza para planificar el espacio de direcciones de red del grupo de contenedores. Los espacios de direcciones entre cada grupo de IP del grupo de contenedores no pueden superponerse.

Habilite el mapa de topología del servicio para integrar Weave Scope (una herramienta de visualización y monitoreo para Docker y Kubernetes). El mapa de topología del servicio se muestra en su proyecto para visualizar las relaciones de conexión entre los servicios.

Debido a que la imagen de la arquitectura arm64 correspondiente a la versión weave-scope es difícil de encontrar, debe crearla usted mismo. Sin embargo, esta función en realidad es de poca utilidad. El proyecto dejó de mantenerse, por lo que este artículo finalmente abandonó la habilitación. esta función.

4.3 Implementar KubeSphere y Kubernetes

A continuación ejecutamos el siguiente comando para implementar KubeSphere y Kubernetes usando el archivo de configuración generado anteriormente.

export KKZONE=cn
./kk create cluster -f kubesphere-v340-v1265.yaml

Después de ejecutar el comando anterior, kk primero verificará las dependencias y otros requisitos detallados para implementar Kubernetes. Después de pasar la verificación, el sistema le pedirá que confirme la instalación. Ingrese sí y presione ENTRAR para continuar con la implementación.

[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]:

Hay muchos resultados de registro durante el proceso de instalación. Este artículo solo muestra los puntos importantes. Asegúrese de observar el paquete binario descargado, que está en formato arm64 ( limitado por espacio, solo se muestra una parte del resultado de registro).

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

Se necesitan entre 10 y 30 minutos para completar la implementación, dependiendo de la velocidad de la red y la configuración de la máquina (durante el proceso de implementación real, las anomalías de los componentes inevitablemente requerirán intervención manual debido a problemas con la arquitectura espejo ).

Si no hay intervención manual durante el despliegue real, inevitablemente ocurrirá la siguiente situación:

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

Nota: Cuando aparezca la barra de desplazamiento esperando que se complete la instalación, debe abrir inmediatamente una nueva terminal y usarla para kubectl get pod -Aseguir el estado de implementación de todos los Pods. De acuerdo con el mensaje de error, consulte la "Solución de componentes anormales" a continuación para solucionar y resolver rápidamente la creación y el inicio anormales del componente.

Una vez que se complete la implementación real, debería ver un resultado similar al siguiente en su terminal. Cuando se le solicite que la implementación se haya completado, el resultado también mostrará el usuario y la contraseña del administrador predeterminados para iniciar sesión en 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

Aviso:

La información anterior es complementaria. Inevitablemente habrá interrupciones en la implementación real. Después de resolver todas las excepciones de los componentes, elimine Pod ks-install y reconstruya la tarea de implementación. Una vez completada la tarea, use el último comando anterior para ver el resultado final kubectl logs.

Cuando se muestra la información de finalización de la implementación anterior, no significa que todos los componentes y servicios se puedan implementar normalmente y puedan proporcionar servicios. Consulte la **"Solución de componentes anormales"** a continuación para solucionar problemas y resolver la creación y el inicio de componentes anormales.

5. Componentes y soluciones anormales

Dado que el soporte de KubeSphere Community Edition para ARM no es perfecto, de forma predeterminada solo puede garantizar que KubeSphere-Core se pueda implementar con éxito bajo la arquitectura ARM. Cuando los complementos están habilitados, no todos los complementos tienen imágenes ARM. Cuando no hay Imagen de la versión ARM correspondiente. El sistema extrae la versión x86 de la imagen para crear e iniciar el servicio. Por lo tanto, provocará excepciones en el inicio del servicio causadas por diferentes arquitecturas. La excepción debe resolverse según el mensaje de error.

Las soluciones para resolver excepciones incluyen las siguientes:

Utilice el código fuente oficial del componente y Dockerfile para crear la imagen ARM usted mismo ( la mejor solución, debido a las capacidades limitadas, este artículo solo cubre ks-console y puede actualizarse más adelante)
Utilice otros repositorios oficiales de componentes anormales o la misma versión de la imagen ARM proporcionada por un tercero ( solución subóptima , primero busque la oficial, no es necesario buscar imágenes proporcionadas por usuarios de terceros)
Utilice otros repositorios oficiales de componentes anormales o versiones similares de imágenes ARM proporcionadas por terceros ( solución garantizada , limitada al entorno de prueba de I+D)

Esta sección solo se centra en registrar y describir los nuevos problemas encontrados en este artículo. Para los problemas resueltos en documentos anteriores, el proceso de procesamiento final simplemente se escribe aquí.

5.1 Resolver la excepción del servidor de métricas

Esta excepción es la primera que se maneja . Al final de la tarea de implementación de kk, debe prestar atención cuando aparece la barra de desplazamiento de las tareas que esperan que se complete la implementación. Si el Pod tiene una excepción, debe manejarse de inmediato.

Obtenga la imagen de la versión ARM adaptada ( la misma versión de la imagen de la versión ARM oficial de KubeSphere )

# 拉取 arm64 镜像
crictl pull registry.cn-beijing.aliyuncs.com/kubesphereio/metrics-server:v0.4.2-arm64  --platform arm64

La imagen se vuelve a etiquetar (~~no lo hagas~~）

# 删除 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

Redistribuir componentes

# 修改 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 Resolver excepciones de Argo CD

Obtenga la imagen de la versión ARM adaptada ( la misma versión de la imagen de la versión ARM oficial de KubeSphere )

# 找个相同版本的 ARM 架构的镜像
crictl pull kubespheredev/argocd-applicationset-arm64:v0.4.1

Vuelva a etiquetar la imagen ( para mantener coherente el nombre de la imagen )

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

Redistribuir componentes

# 修改 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

Verifique que el nuevo Pod se haya creado e iniciado correctamente

kubectl get pods -o wide -n argocd | grep applicationset-controller

5.3 Resolver excepciones de Istio

Obtenga la imagen de la versión ARM adaptada ( imagen ARM de la versión similar oficial de Istio )

# 找个相近版本的 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",

Reetiquetado espejo

ctr -n k8s.io images tag docker.io/istio/pilot:1.15.7 registry.cn-beijing.aliyuncs.com/kubesphereio/pilot:1.15.7

Redistribuir componentes

# 修改 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

Verifique que el nuevo Pod se haya creado e iniciado correctamente

kubectl get pods -o wide -n istio-system | grep istio

5.4 Resolver la excepción de copia de seguridad http

Obtenga la imagen de la versión ARM adaptada ( imagen ARM de terceros de la misma versión )

crictl pull mirrorgooglecontainers/defaultbackend-arm64:1.4

Vuelva a etiquetar la imagen ( para mantener coherente el nombre de la imagen )

ctr -n k8s.io images tag docker.io/mirrorgooglecontainers/defaultbackend-arm64:1.4 registry.cn-beijing.aliyuncs.com/kubesphereio/defaultbackend-arm64:1.4

Redistribuir componentes

# 修改 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

Verifique que el nuevo Pod se haya creado e iniciado correctamente

kubectl get pods -o wide -n kubesphere-controls-system | grep default-http-backend

5.5 Resolución de excepciones de Jenkins

Obtenga la imagen de la versión ARM adaptada ( versión similar de la imagen de la versión ARM oficial de KubeSphere )

# 没有找到同版本的，只能找了一个相近版本的 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",

Vuelva a etiquetar la imagen ( para mantener coherente el nombre de la imagen )

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

Redistribuir componentes

# 修改 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 Resolver la excepción del gobernante thanos

Ver pod anormal

[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>

Verifique la imagen utilizada por el Pod anormal

[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

Verifique la estructura anormal del espejo del Pod ( la estructura del espejo está bien )

[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",

Los siguientes detalles no se registraron a tiempo porque el servicio ks-apiserver era anormal. Después de reiniciar el contenedor coreDNS, thanos-ruler se creó automáticamente con éxito.

5.7 Resolver excepciones de Minio

Obtenga la imagen de la versión ARM adaptada ( versión similar imagen de la versión ARM oficial de Minio )

# 找个相近版本的 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

Reetiquetado espejo

# 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

Redistribuir componentes

# 重新部署,删除旧的 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 Resolver la excepción de ks-console

No hay ningún problema con ks-console en el entorno ARM de openEuler 22.03 SP2, pero ocurre una excepción en Kirin V10, lo que indica que las diferencias en los sistemas operativos también tienen un cierto impacto en la implementación del servicio.

Ver pod anormal

[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>

Verifique el registro del Pod anormal

[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 --->

Verifique la imagen utilizada por el Pod anormal

[root@ksp-master-3 ~]# crictl image ls | grep ks-console
registry.cn-beijing.aliyuncs.com/kubesphereio/ks-console                    v3.4.0                               42b2364bcafe3       38.7MB

Verifique la arquitectura de la imagen del Pod anormal ( se ve bien en la superficie, la arquitectura coincide )

[root@ksp-master-3 ~]# crictl inspecti registry.cn-beijing.aliyuncs.com/kubesphereio/ks-console:v3.4.0  | grep archite
      "architecture": "arm64",

solución

## 解决方案，网上说可以更换 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

Tira la nueva imagen nuevamente.

# 服务器拉取新镜像
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

Redistribuir

# 修改镜像拉取策略，并重新部署
kubectl patch deployment ks-console --patch '{"spec": {"template": {"spec": {"containers": [{"name": "ks-console","imagePullPolicy": "IfNotPresent"}]}}}}' -n kubesphere-system

5.9 Soluciones generales para resolver anomalías de componentes.

Al implementar los clústeres KubeSphere y Kubernetes de ARM, la mayoría de las excepciones encontradas se deben a una falta de coincidencia de las arquitecturas de imágenes. Cuando encuentre componentes anormales que no se tratan en este artículo, puede consultar el siguiente proceso para resolverlos.

Ver pod anormal
Verifique el registro del Pod anormal
Verifique la imagen utilizada por el Pod anormal
Verifique la estructura anormal del espejo Pod
Obtenga la imagen de la versión ARM adaptada
Reetiquetado espejo
Redistribuir componentes

Cuando se determina que no hay ningún problema con la arquitectura espejo, algunos problemas se pueden resolver eliminando y reconstruyendo varias veces.

6. Verificación de implementación

Una vez completadas las tareas de implementación anteriores, solo puede significar que se completa la implementación de los clústeres de KubeSphere y Kubernetes basados en la arquitectura ARM. Pero aún es necesario verificar si la función general está disponible.

Este artículo solo realiza una verificación básica y no una verificación detallada de todas las funciones. Amigos que lo necesiten, verifiquen y prueben ustedes mismos.

6.1 Consola de administración de KubeSphere para verificar el estado del clúster

Abrimos el navegador para acceder a la dirección IP y puerto 30880 del nodo master-1 , y podremos ver la página de inicio de sesión de la consola de administración de KubeSphere.

Ingrese el usuario predeterminado admin y la contraseña predeterminada P@88w0rd y luego haga clic en "Iniciar sesión".

Después de iniciar sesión, se le pedirá que cambie la contraseña predeterminada del administrador de usuarios predeterminado de KubeSphere, ingrese la nueva contraseña y haga clic en "Enviar".

Una vez completado el envío, el sistema saltará a la página del banco de trabajo del usuario administrador de KubeSphere, que muestra que la versión actual de KubeSphere es v3.4.0 y la cantidad de clústeres de Kubernetes disponibles es 1.

A continuación, haga clic en el menú "Administración de plataforma" en la esquina superior izquierda y seleccione "Administración de clústeres".

Ingrese a la interfaz de administración del clúster, donde puede ver la información básica del clúster, incluido el uso de recursos del clúster, el estado de Kubernetes, el uso de recursos del nodo superior, los componentes del sistema, la caja de herramientas, etc.

Haga clic en el menú "Nodo" a la izquierda y haga clic en "Nodo de clúster" para ver información detallada sobre los nodos disponibles del clúster de Kubernetes.

Haga clic en el menú "Componentes del sistema" a la izquierda para ver información detallada sobre los componentes instalados.

A continuación, echemos un vistazo general al estado de los complementos conectables habilitados cuando implementamos el clúster.

tienda de aplicaciones

Sistema de registro KubeSphere

Sistema de eventos KubeSphere

Registro de auditoría de KubeSphere

Sistema de alarma KubeSphere

Malla de servicios de KubeSphere ( la funcionalidad real no ha sido verificada ni probada )

Servidor de métricas ( sin página, es necesario verificarlo cuando HPA está habilitado )
Estrategia de red ( puede que no se utilice en la práctica )

Grupo de IP del grupo de contenedores

El sistema KubeSphere DevOps es el foco del uso real, lo hemos verificado especialmente a través de varias capturas de pantalla ( se omite el proceso de implementación, todos los componentes están en estado normal y la canalización también se puede crear normalmente durante la prueba real ) .

Componentes del sistema DevOps

Proyectos y canalizaciones de DevOps (Crear proyecto -> Crear canalización -> Editar canalización usando plantillas oficiales -> Ejecutar canalización)

Finalmente, observamos un conjunto de gráficos de seguimiento para finalizar nuestra verificación gráfica.

Descripción general

Monitoreo de recursos físicos

monitoreo etcd

Monitoreo del servidor API

Monitoreo del programador

Clasificación de uso de recursos

Monitoreo de pods

6.2 Línea de comando de Kubectl para verificar el estado del clúster

Esta sección solo analiza brevemente el estado básico, que no es completo. Debe experimentar y explorar más detalles usted mismo.

Ver información del nodo del clúster

Ejecute el comando kubectl en el nodo master-1 para obtener la lista de nodos disponibles en el clúster de Kubernetes.

kubectl get nodes -o wide

Como puede ver en el resultado, el clúster de Kubernetes actual tiene tres nodos disponibles: la IP interna del nodo, la función del nodo, el número de versión de Kubernetes del nodo, el tiempo de ejecución del contenedor y el número de versión, el tipo de sistema operativo, la versión del kernel y otra información.

[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

Ver lista de pods

Ingrese el siguiente comando para obtener una lista de Pods que se ejecutan en el clúster de Kubernetes, ordenados por distribución de carga de trabajo en NODE.

# 默认按 NAMESPACE 排序
# 按节点排序
kubectl get pods -A -o wide --sort-by='.spec.nodeName'

Como puede ver en el resultado, hay varios espacios de nombres disponibles kube-system, kubesphere-control-system, kubesphere-monitoring-system, kubesphere-system, argocd e istio-system en el clúster de Kubernetes, y todos los pods se están ejecutando.

Aviso:

Los resultados se omiten, compruébelo usted mismo o consulte el documento de implementación anterior basado en OpenEuler ARM

Si el estado del Pod no es En ejecución, compárelo y manéjelo de acuerdo con el contenido de la Sección 5 "Componentes y soluciones anormales" de este artículo. Los problemas que no se tratan en este artículo los puede resolver usted mismo consultando las ideas de solución de este artículo. .

Ver lista de imágenes

Ingrese el siguiente comando para obtener la lista de imágenes que se descargaron en el nodo del clúster de Kubernetes.

crictl images ls
# 结果略，请自行查看或是参考上一篇基于 OpenEuler ARM 的部署文档

Hasta ahora, hemos completado la implementación de 3 servidores, un clúster de Kubernetes minimizado y KubeSphere reutilizados como nodos maestros y nodos trabajadores. También verificamos el estado del clúster a través de la consola de administración y la interfaz de línea de comandos de KubeSphere.

A continuación, implementaremos un servidor web Nginx simple en el clúster de Kubernetes para probar y verificar si las funciones básicas de Kubernetes y KubeSphere son normales.

7. Implementar recursos de prueba

Este ejemplo utiliza herramientas de línea de comandos para implementar un servidor web Nginx en un clúster de Kubernetes y usa la consola de administración gráfica de KubeSphere para ver la información de los recursos implementados.

7.1 Crear implementación de Nginx

Ejecute el siguiente comando para crear una implementación que implemente el servidor web Nginx. En este ejemplo, crearemos un pod con dos réplicas basadas en la imagen nginx:alpine.

kubectl create deployment nginx --image=nginx:alpine --replicas=2

7.2 Crear servicio Nginx

Cree un nuevo servicio de Kubernetes, nombre de servicio nginx, tipo de servicio Nodeport, puerto de servicio externo 80.

kubectl create service nodeport nginx --tcp=80:80

7.3 Verificar la implementación y el pod de Nginx

Ejecute los siguientes comandos para ver los recursos de implementación y pod creados.

kubectl get deployment -o wide
kubectl get pods -o wide

Vea los resultados de la siguiente manera:

[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 Verificar la arquitectura espejo de Nginx

Ejecute el siguiente comando para ver el tipo de arquitectura de Nginx Image

crictl inspecti nginx:alpine | grep architecture

Vea los resultados de la siguiente manera:

[root@ks-master-1 ~]# crictl inspecti nginx:alpine | grep architecture
      "architecture": "arm64"

7.5 Verificar el servicio Nginx

Ejecute el siguiente comando para ver la lista de servicios disponibles. En la lista, podemos ver que el tipo de servicio nginx es Nodeport y el puerto 30563 está abierto en el host de Kubernetes.

kubectl get svc -o wide

Vea los resultados de la siguiente manera

[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 Servicio de verificación

Ejecute el siguiente comando para acceder al servicio Nginx implementado y verificar si el servicio se implementó correctamente.

Verificar el acceso directo al Pod

curl 10.233.84.73

Verificar acceso al Servicio

curl 10.233.62.164

Verificar acceso a Nodeport

curl 172.16.33.16:30792

7.7 Ver en la consola de administración

A continuación, volvemos a la consola de administración de KubeSphere y vemos los recursos que se han creado en la consola de administración.

Nota: La consola de administración de KubeSphere tiene la función de crear varios recursos de Kubernetes de una manera gráfica y amigable, principalmente porque tomar capturas de pantalla es demasiado problemático, por lo que este artículo utiliza la línea de comando para crear simplemente recursos de prueba.

Solo quiero demostrar las funciones básicas de la consola de administración de KubeSphere al verla. En el uso real, puede usar métodos gráficos para crear y administrar recursos de Kubernetes.

Inicie sesión en la consola de administración de KubeSphere, haga clic en "Administración de plataforma" y seleccione "Administración de clústeres".
Haga clic en "Carga de aplicaciones" en el lado izquierdo de la página de administración del clúster y haga clic en "Carga de trabajo". De forma predeterminada, verá todas las cargas de trabajo de tipo implementación .

Estamos usando la cuenta de administrador, por lo que podemos ver todas las cargas de trabajo. Si ingresamos nginx en el cuadro de búsqueda, solo se mostrará la carga de trabajo de implementación de nginx.

Haga clic en nginx en la lista de implementación para ver información más detallada y administrar la implementación de nginx (Implementación).

Haga clic en un contenedor nginx en el grupo de contenedores para ver el estado, el monitoreo y otra información del contenedor.

Regrese a la página "Administración de plataforma" - "Administración de clústeres", haga clic en "Carga de aplicaciones" en el lado izquierdo de la página de administración de clústeres y haga clic en "Servicio". De forma predeterminada, verá todas las cargas de trabajo de tipo servicio .

Estamos usando la cuenta de administrador, por lo que podemos ver todas las cargas de trabajo. Si ingresamos nginx en el cuadro de búsqueda, solo se mostrará la carga de trabajo del servicio nginx.

Haga clic en nginx en la lista de servicios para ver información más detallada y administrar el servicio nginx (Servicio).

En este punto, implementamos el servidor web Nginx en el clúster de Kubernetes y vimos y verificamos los detalles de la implementación, el pod y el servicio implementados a través de la consola de administración de KubeSphere.

Este artículo solo realiza la prueba de verificación más básica de la creación de recursos para KubeSphere y Kubernetes implementados bajo la arquitectura ARM. No se cubren pruebas más completas de componentes conectables. Se solicita a los lectores que verifiquen y prueben ellos mismos según sus necesidades.

La mayoría de los problemas encontrados durante la prueba de verificación deberían deberse a la falta de coincidencia de la arquitectura de la imagen. Consulte las ideas y procesos de resolución de problemas en la Sección 5 de este artículo , la mayoría de los problemas deberían resolverse.

8. Preguntas frecuentes

8.1 Pregunta 1

Fenómeno problemático

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.io\n", "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

solución

# 解决 metrics-server 异常后，重启 ks-install pod
kubectl delete pod ks-installer-6674579f54-cgxpk -n kubesphere-system

8.2 Pregunta 2

Fenómeno problemático

# 登陆 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

solución

# 销毁所有的 coredns pod，自动重建后恢复
kubectl delete pod  coredns-d9d84b5bf-fmm64 -n kube-system

8.3 Pregunta 3

Fenómeno problemático

[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.

solución

No se registraron más detalles, pero el resultado final fue que se reparó solo después de que se reinició el módulo coreDNS. Cuando ocurre una cápsula anormal, se puede reparar destruyéndola varias veces y esperando a que el sistema se reconstruya automáticamente.

8.4 Pregunta 4

Fenómeno problemático

Al verificar los registros, eventos y registros de auditoría, se encontró que no había datos. Después de la investigación, se encontró que el pod de bits fluidos era anormal y aparecieron una gran cantidad de los siguientes errores en los registros (este problema no ocurrió en 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.39µs expected=-1s

2023-11-09T12:05:00.922644408+08:00 level=info msg="Fluent bit started"

solución

# 一番搜索发现，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. Resumen

Este artículo demuestra principalmente el proceso detallado de uso de KubeKey v3.0.13 para implementar automáticamente un clúster mínimo de alta disponibilidad de KubeSphere 3.4.0 y Kubernetes 1.26.5 en la versión ARM del servidor Kirin V10 SP2.

Una vez completada la implementación, también utilizamos la consola de administración de KubeSphere y la línea de comandos de kubectl para ver y verificar el estado de los clústeres de KubeSphere y Kubernetes.

Finalmente, verificamos la disponibilidad del clúster de Kubernetes y KubeSphere implementando el servidor web Nginx en el clúster de Kubenetes y aprendimos el uso básico de KubeSphere viendo el pod de Nginx y el estado del servicio en la consola de administración de KubeSphere.

En resumen, el texto completo incluye principalmente los siguientes contenidos:

Configuración básica del sistema operativo Kirin V10 SP2 aarch64
Configuración del LVM del disco de datos del sistema operativo, montaje del disco y creación del directorio de datos
KubeKey descarga y crea archivos de configuración del clúster
Utilice KubeKey para implementar automáticamente clústeres de KubeSphere y Kubernetes
Resuelva el problema de los componentes de servicio anormales de la versión ARM de KubeSphere y Kubernetes
Verificación del estado del clúster de KubeSphere y Kubernetes después de la implementación
Implemente Nginx para verificar y probar las funciones básicas de KubeSphere y Kubernetes

El valor principal de este artículo es que se centra en los problemas comunes encontrados durante la implementación de clústeres de KubeSphere y Kubernetes y sus soluciones correspondientes . Al mismo tiempo, se señalaron diferentes problemas encontrados en dos sistemas operativos diferentes, Kirin V10 y openEuler 22.03.

Aunque el entorno de implementación en este artículo se basa en la versión aarch64 de Kirin V10 SP2 basado en el chip Kunpeng-920 , también tiene cierta importancia de referencia para los sistemas operativos de la versión ARM como CentOS, openEuler y chips como Feiteng (FT- 2500).

El contenido presentado en este artículo se puede utilizar directamente en entornos de prueba e I + D, y tiene cierta importancia de referencia para el entorno de producción, y no debe utilizarse directamente en el entorno de producción.

La conclusión de la prueba incompleta de este artículo: las funciones básicas de KubeSphere y Kubernetes están disponibles, y las funciones DevOps están disponibles, lo que puede cumplir con los escenarios comerciales más comunes.

¡Este artículo es publicado por OpenWrite, un blog que publica varios artículos !