ARM용 Kylin V10에 KubeSphere 3.4.0을 배포하기 위한 불완전한 가이드

데이터부터 대형 모델 적용까지, 개발 팁을 공유하기 위해 11월 25일 항저우 위안추앙 컨퍼런스가 개최되었습니다.

머리말

지식 포인트

• 등급: 입문자 수준
• KubeKey는 KubeSphere 및 Kubernetes의 ARM 버전을 설치하고 배포합니다.
• ARM용 Kirin V10에 KubeSphere 및 Kubernetes를 설치 및 배포하는 방법에 대해 자주 묻는 질문(FAQ)

실제 서버 구성(퍼스널 클라우드의 테스트 서버)

CPU 이름	IP	CPU	메모리	시스템 디스크	데이터 디스크	사용
ksp-마스터-1	172.16.33.16	8	16	50	200	KubeSphere/k8s-master/k8s-worker
ksp-마스터-2	172.16.33.22	8	16	50	200	KubeSphere/k8s-master/k8s-worker
ksp-마스터-3	172.16.33.23	8	16	50	200	KubeSphere/k8s-master/k8s-worker
총	삼	24	48	150	600

실제 전투 환경에는 소프트웨어 버전 정보가 포함됩니다.

• 서버 칩: Kunpeng-920

• 운영 체제: Kirin V10 SP2 aarch64

• KubeSphere: v3.4.0

• 쿠버네티스: v1.26.5

• 컨테이너: 1.6.4

• KubeKey: v3.0.13

1. 이 글의 소개

이 문서에서는 Kirin V10 aarch64 아키텍처 서버 에 KubeSphere 및 Kubernetes 클러스터를 배포하는 방법을 소개합니다 . KubeSphere에서 개발한 KubeKey 도구를 사용하여 자동화된 배포를 구현하고 3개의 서버에 고가용성 모드를 구현하여 Kubernetes 클러스터 및 KubeSphere의 배포를 최소화하겠습니다.

KubeSphere와 Kubernetes는 ARM 아키텍처와 x86 아키텍처 서버에 배포됩니다. 가장 큰 차이점은 모든 서비스에서 사용되는 컨테이너 이미지 아키텍처 유형 에 있습니다. KubeSphere 오픈 소스 버전의 ARM 아키텍처에 대한 기본 지원은 KubeSphere-Core 기능을 실현할 수 있습니다. KubeSphere 및 전체 Kubernetes 클러스터 배포를 최소화합니다. KubeSphere 플러그 가능 구성 요소가 활성화되면 개별 구성 요소의 배포가 실패하므로 공식 또는 타사에서 제공하는 ARM 버전 이미지를 수동으로 교체하거나 공식 소스 코드를 기반으로 ARM 버전 이미지를 수동으로 빌드해야 합니다. 즉시 사용 가능한 운영 및 추가 기술 지원이 필요한 경우 KubeSphere의 엔터프라이즈 버전을 구입해야 합니다.

이 기사는 ARM 아키텍처 서버에 대한 KubeSphere 오픈 소스 버전의 지원을 조사하기 위한 실험 프로세스에 대한 문서입니다. 이 문서에는 최종 배포 중에 발생한 다양한 문제와 오류 및 해당 해결 방법이 자세히 기록되어 있습니다. 제한된 기능으로 인해 이 기사에서 발생한 대부분의 아키텍처 비호환성 문제는 타사 리포지토리 또는 기타 공식 리포지토리를 동일하거나 유사한 ARM 버전 이미지로 수동으로 교체하여 해결되었습니다. 프로덕션에서 사용하려는 독자는 공식 소스 코드 및 DockerFile을 사용하여 x86 버전과 정확히 동일한 ARM 버전의 컨테이너 이미지를 빌드할 수 있는 기능을 갖추고 있어야 합니다. 유사한 버전을 교체하거나 사용하지 마십시오. 타사 이미지. 이 기사에서는 ARM 관련 이미지를 빌드하는 데 공식 소스 코드와 Dockerfile을 완전히 사용하지 않고 상대적으로 간단한 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

• 크로니 동기화 상태 확인

# 执行查看命令
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 시스템 종속성 설치

모든 노드에서 루트 사용자 로 시스템에 로그인 하고 다음 명령을 실행하여 Kubernetes용 기본 시스템 종속성 패키지를 설치합니다.

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

3. 운영 체제 디스크 구성

서버는 Containerd 및 Kubernetes Pod 의 영구 저장 에 사용되는 새 데이터 디스크 /dev/vdb (구체적인 이름은 가상화 플랫폼 유형에 따라 다름)를 추가합니다.

별도로 지정하지 않는 한 클러스터의 모든 노드에서 다음 작업을 수행해야 합니다. 본 글에서는 시연을 위해 Master-1 노드 만 선택했으며 , 다른 서버도 동일한 방식으로 구성 및 설정되었다고 가정합니다.

3.1 LVM을 사용하여 디스크 구성

일부 사용자의 요구를 충족시키기 위해 생산이 온라인으로 전환된 후 디스크 용량이 부족한 경우 동적 확장을 달성할 수 있습니다. 이 기사에서는 LVM을 사용하여 디스크를 구성합니다( 사실 제가 유지 관리하는 프로덕션 환경에서는 LVM을 거의 사용하지 않습니다 ).

• PV 생성

 pvcreate /dev/vdb

• CreateVG

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

참고: 버전 v3.0.13까지 KubeKey는 배포 중 Containerd의 데이터 디렉터리 변경을 지원하지 않았습니다. 이 디렉터리 소프트 링크를 사용하여 저장 공간을 늘리는 문제를 해결할 수 있습니다( Containerd를 미리 수동으로 설치할 수도 있습니다. 권장) .

3.5 디스크 구성 자동 쉘 스크립트

위의 모든 작업은 자동화된 구성 스크립트로 구성될 수 있습니다.

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 이라는 구성 파일이 현재 디렉터리에 생성됩니다 .

참고: 생성된 기본 구성 파일에는 내용이 많아 여기서는 자세히 보여주지 않겠습니다. 자세한 구성 매개변수는 공식 구성 예제를 참조하세요 .

이 문서의 예에서는 세 개의 노드를 제어 평면, etcd 노드 및 작업자 노드로 동시에 사용합니다.

구성 파일을 편집하고 kubesphere-v340-v1265.yaml주로 종류: 클러스터 및 종류: ClusterConfiguration의 두 섹션에서 관련 구성을 수정합니다 .

종류: 클러스터 섹션 에서 호스트 및 roleGroups 정보를 수정합니다 . 수정 지침은 다음과 같습니다.

• 호스트: 노드의 IP, SSH 사용자, SSH 비밀번호 및 SSH 포트를 지정합니다. 특별 참고 사항: arch: arm64를 수동으로 지정해야 합니다 . 그렇지 않으면 배포 중에 X86 아키텍처 소프트웨어 패키지가 설치됩니다.
• roleGroups: etcd 및 제어 영역 노드 3개를 지정하고 동일한 머신을 작업자 노드 3개로 재사용합니다.
• InternalLoadbalancer: 내장 HAProxy 로드 밸런서를 활성화합니다.
• 도메인: opsman.top을 사용자 정의했습니다.
• 컨테이너 관리자: 컨테이너d가 사용됩니다.
• 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: []

수정 종류: 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:
  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 Community Edition의 ARM 지원은 완벽하지 않기 때문에 기본적으로 KubeSphere-Core가 ARM 아키텍처에서 성공적으로 배포될 수 있다는 것만 보장할 수 있습니다. 플러그인이 활성화되면 모든 플러그인에 ARM 이미지가 있는 것은 아닙니다. 해당 ARM 버전 이미지, 시스템은 서비스를 생성하고 시작하기 위해 x86 버전의 이미지를 가져옵니다. 따라서 다른 아키텍처로 인해 서비스 시작 예외가 발생하므로 오류 메시지에 따라 예외를 해결해야 합니다.

예외를 해결하는 솔루션에는 다음이 포함됩니다.

• 공식 구성 요소 소스 코드와 Dockerfile을 사용하여 ARM 이미지를 직접 빌드합니다 . ( 제한된 기능으로 인해 최상의 솔루션입니다. 이 문서에서는 ks-console만 다루고 나중에 업데이트될 수 있습니다.)
• 비정상적인 구성 요소에 대한 다른 공식 저장소 또는 제3자가 제공하는 동일한 버전 의 ARM 이미지를 사용하십시오 ( 최적의 솔루션이 아닌 경우 먼저 공식 저장소를 찾으십시오. 제3자 사용자가 제공한 이미지를 찾을 필요가 없습니다).
• 비정상적인 구성 요소 또는 타사에서 제공하는 유사한 버전 의 ARM 이미지에 대한 다른 공식 저장소 사용 ( 솔루션 보장 , R&D 테스트 환경으로 제한)

이 섹션에서는 본 기사에서 발생한 새로운 문제를 기록하고 설명하는 데 중점을 두고 있으며, 이전 문서에서 해결된 문제에 대해서는 최종 처리 과정을 여기에 간단히 기록합니다.

5.1 메트릭 서버 예외 해결

이 예외는 가장 먼저 처리해야 할 예외이며, kk 배포 작업이 끝나면 배포가 완료되기를 기다리는 작업의 스크롤 막대가 나타날 때 주의해야 하며, Pod에 예외가 발생하면 즉시 처리해야 합니다.

• 적응된 ARM 버전 이미지 얻기( KubeSphere 공식 ARM 버전 이미지와 동일한 버전 )

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

• 이미지가 다시 태그되었습니다(하지 마세요)

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

• 이미지에 태그를 다시 지정합니다( 이미지 이름을 일관되게 유지하기 위해 ).

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

• 새 포드가 생성되고 성공적으로 시작되었는지 확인

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

• 미러 태그 재지정

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

• 새 포드가 생성되고 성공적으로 시작되었는지 확인

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

5.4 http-backupend 예외 해결

• 적응된 ARM 버전 이미지 얻기( 동일 버전의 타사 ARM 이미지 )

crictl pull mirrorgooglecontainers/defaultbackend-arm64:1.4

• 이미지에 태그를 다시 지정합니다( 이미지 이름을 일관되게 유지하기 위해 ).

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

• 새 포드가 생성되고 성공적으로 시작되었는지 확인

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

• 이미지에 태그를 다시 지정합니다( 이미지 이름을 일관되게 유지하기 위해 ).

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 예외 해결

• 비정상적인 포드 보기

[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

• 미러 태그 재지정

# 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 예외 해결

openEuler 22.03 SP2의 ARM 환경에서는 ks-console에서는 문제가 없으나, Kirin V10에서는 예외가 발생하는데, 이는 운영 체제의 차이도 서비스 배포에 일정한 영향을 미친다는 것을 나타냅니다.

• 비정상적인 포드 보기

[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 미러 구조 확인

• 적응된 ARM 버전 이미지 가져오기

• 미러 태그 재지정

• 구성 요소 재배포

미러 아키텍처에 문제가 없다고 판단되면 여러 번 삭제하고 다시 빌드하면 일부 문제를 해결할 수 있습니다.

6. 배포 확인

위 배포 작업이 완료되면 ARM 아키텍처 기반 KubeSphere 및 Kubernetes 클러스터 배포가 완료되었음을 의미할 수 있습니다. 하지만 전체적인 기능이 사용 가능한지는 아직 확인이 필요합니다.

본 글은 기본적인 검증만 하고, 상세한 전체 기능 검증은 하지 않았으니, 도움이 필요한 친구들은 직접 검증하고 테스트해보시기 바랍니다.

6.1 클러스터 상태를 확인하기 위한 KubeSphere 관리 콘솔

브라우저를 열어 master-1 노드의 IP 주소와 포트 30880 에 액세스 하면 KubeSphere 관리 콘솔의 로그인 페이지가 표시됩니다.

기본 사용자 admin 및 기본 비밀번호 P@88w0rd 를 입력 한 후 "로그인"을 클릭하세요.

로그인하면 KubeSphere 기본 사용자 admin의 기본 비밀번호를 변경하라는 메시지가 표시됩니다. 새 비밀번호를 입력하고 "제출"을 클릭하세요.

제출이 완료되면 시스템은 KubeSphere 관리자 워크벤치 페이지로 이동하며 현재 KubeSphere 버전은 v3.4.0 이고 사용 가능한 Kubernetes 클러스터 수가 1임을 보여줍니다.

그런 다음 왼쪽 상단의 "플랫폼 관리" 메뉴를 클릭하고 "클러스터 관리"를 선택합니다.

클러스터 리소스 사용량, Kubernetes 상태, 최상위 노드 리소스 사용량, 시스템 구성 요소, 도구 상자 등을 포함하여 클러스터의 기본 정보를 볼 수 있는 클러스터 관리 인터페이스에 들어갑니다.

왼쪽의 "노드" 메뉴를 클릭한 후 "클러스터 노드"를 클릭하면 쿠버네티스 클러스터에서 사용 가능한 노드에 대한 자세한 정보를 확인할 수 있습니다.

설치된 구성요소에 대한 자세한 정보를 보려면 왼쪽의 "시스템 구성요소" 메뉴를 클릭하세요.

다음으로 클러스터를 배포할 때 활성화된 플러그형 플러그인의 상태를 대략적으로 살펴보겠습니다.

• 앱 스토어

• KubeSphere 로깅 시스템

• KubeSphere 이벤트 시스템

• KubeSphere 감사 로그

• KubeSphere 경보 시스템

• KubeSphere 서비스 메시( 실제 기능은 검증 및 테스트되지 않음 )

• Metrics Server( 페이지 없음, HPA가 활성화된 경우 확인 필요 )
• 네트워크 전략( 실제로 사용되지 않을 수 있음 )

• 컨테이너 그룹 IP 풀

실제 사용이 중심이 되는 KubeSphere DevOps 시스템을 여러 스크린샷을 통해 특별히 검증하였습니다. ( 구현 과정은 생략되었으며, 모든 구성 요소는 정상 상태이며, 실제 테스트 중에 파이프라인도 정상적으로 생성 가능합니다. )

• DevOps 시스템 구성요소

• DevOps 프로젝트 및 파이프라인(프로젝트 생성 -> 파이프라인 생성 -> 공식 템플릿을 사용하여 파이프라인 편집 -> 파이프라인 실행)

마지막으로 모니터링 차트를 살펴보고 그래픽 검증을 마무리합니다.

• 개요

• 물리적 자원 모니터링

• etcd 모니터링

• API 서버 모니터링

• 스케줄러 모니터링

• 자원 사용량 순위

• 포드 모니터링

6.2 클러스터 상태를 확인하기 위한 Kubectl 명령줄

이 섹션에서는 기본 상태에 대해 간략하게 설명할 뿐 포괄적이지 않으며 자세한 내용은 직접 경험하고 탐색해야 합니다.

• 클러스터 노드 정보 보기

master-1 노드에서 kubectl 명령을 실행하여 Kubernetes 클러스터에서 사용 가능한 노드 목록을 가져옵니다.

kubectl get nodes -o wide

출력에서 볼 수 있듯이 현재 Kubernetes 클러스터에는 3개의 사용 가능한 노드, 즉 노드의 내부 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

• 포드 목록 보기

NODE의 워크로드 분포를 기준으로 정렬된 Kubernetes 클러스터에서 실행 중인 Pod 목록을 가져오려면 다음 명령을 입력합니다.

# 默认按 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절 "비정상적인 구성 요소 및 해결방법" 내용에 따라 비교하여 처리하시기 바랍니다. 본 글에서 다루지 않은 문제는 본 글의 해결 방법을 참고하여 스스로 해결하실 수 있습니다. .

• 이미지 목록 보기

Kubernetes 클러스터 노드에 다운로드된 이미지 목록을 얻으려면 다음 명령을 입력하십시오.

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

지금까지 3개의 서버, 최소화된 Kubernetes 클러스터 배포를 완료했으며 KubeSphere를 마스터 노드와 워커 노드로 재사용했습니다. 또한 KubeSphere 관리 콘솔과 명령줄 인터페이스를 통해 클러스터 상태를 확인했습니다.

다음으로 Kubernetes 클러스터에 간단한 Nginx 웹 서버를 배포하여 Kubernetes와 KubeSphere의 기본 기능이 정상인지 테스트하고 검증하겠습니다.

7. 테스트 리소스 배포

이 예에서는 명령줄 도구를 사용하여 Kubernetes 클러스터에 Nginx 웹 서버를 배포하고 KubeSphere 그래픽 관리 콘솔을 사용하여 배포된 리소스 정보를 확인합니다.

7.1 Nginx 배포 생성

다음 명령을 실행하여 Nginx 웹 서버를 배포하는 배포를 생성합니다. 이 예에서는 nginx:alpine 이미지를 기반으로 두 개의 복제본이 있는 Pod를 생성합니다.

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

7.2 Nginx 서비스 생성

새 Kubernetes 서비스, 서비스 이름 nginx, 서비스 유형 Nodeport, 외부 서비스 포트 80을 만듭니다.

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

7.3 Nginx 배포 및 Pod 확인

• 생성된 배포 및 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 이미지의 아키텍처 유형을 보려면 다음 명령을 실행하십시오.

crictl inspecti nginx:alpine | grep architecture

• 다음과 같이 결과를 확인하세요.

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

7.5 Nginx 서비스 확인

사용 가능한 서비스 목록을 보려면 다음 명령을 실행하세요. 목록에서 nginx 서비스 유형이 Nodeport이고 포트 30563 이 Kubernetes 호스트에 열려 있음을 확인할 수 있습니다.

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

• 서비스에 대한 액세스 확인

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 컨테이너를 클릭하면 컨테이너의 상태, 모니터링 및 기타 정보를 볼 수 있습니다.

• "플랫폼 관리" - "클러스터 관리" 페이지로 돌아가서 클러스터 관리 페이지 왼쪽의 "애플리케이션 로드"를 클릭한 후 "서비스"를 클릭합니다. 기본적으로 service 유형 의 모든 워크로드가 표시됩니다 .

우리는 admin 계정을 사용하고 있기 때문에 모든 워크로드를 볼 수 있으며, 검색창에 nginx를 입력하면 nginx 서비스 워크로드만 표시됩니다.

• 서비스 목록에서 nginx를 클릭하면 nginx 서비스(Service)에 대한 자세한 정보를 확인하고 관리할 수 있습니다.

이제 Kubernetes 클러스터에 Nginx 웹 서버를 배포하고 KubeSphere 관리 콘솔을 통해 배포된 배포, Pod, 서비스의 세부 정보를 확인하고 확인했습니다.

본 글에서는 ARM 아키텍처에 배포된 KubeSphere 및 Kubernetes에 대한 리소스 생성에 대한 가장 기본적인 검증 테스트만 수행하며, 플러그형 구성 요소에 대한 보다 완전한 테스트는 다루지 않습니다. 독자는 필요에 따라 스스로 검증하고 테스트해야 합니다.

검증 테스트에서 발생하는 대부분의 문제는 이미지 아키텍처의 불일치로 인해 발생하며, 본 문서 의 5절 에 나와 있는 문제 해결 아이디어와 프로세스 를 참조하면 대부분의 문제가 해결됩니다.

8. FAQ

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

• 해결책

# 解决 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 포드를 다시 시작한 후 자체적으로 복구되었다는 것입니다. 비정상적인 포드가 발생하면 이를 여러 번 파괴하고 시스템이 자동으로 재구축될 때까지 기다리면 복구할 수 있습니다.

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.39µs 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. 요약

이 기사에서는 주로 KubeKey v3.0.13을 사용하여 Kirin V10 SP2 서버의 ARM 버전에 최소 KubeSphere 3.4.0 및 Kubernetes 1.26.5 고가용성 클러스터를 자동으로 배포하는 자세한 프로세스를 보여줍니다.

배포가 완료된 후 KubeSphere 관리 콘솔과 kubectl 명령줄을 사용하여 KubeSphere 및 Kubernetes 클러스터의 상태를 보고 확인했습니다.

마지막으로 Kubenetes 클러스터에 Nginx 웹 서버를 배포하여 Kubernetes 클러스터와 KubeSphere의 가용성을 확인하고, KubeSphere 관리 콘솔에서 Nginx Pod 및 서비스 상태를 확인하여 KubeSphere의 기본 사용법을 배웠습니다.

요약하자면, 전문은 주로 다음과 같은 내용을 담고 있습니다.

• Kirin V10 SP2 aarch64 운영 체제 기본 구성
• 운영 체제 데이터 디스크 LVM 구성, 디스크 마운트 및 데이터 디렉터리 생성
• KubeKey는 클러스터 구성 파일을 다운로드하고 생성합니다.
• KubeKey를 사용하여 KubeSphere 및 Kubernetes 클러스터를 자동으로 배포
• ARM 버전 KubeSphere 및 Kubernetes의 서비스 구성 요소 비정상 문제 해결
• 배포 후 KubeSphere 및 Kubernetes 클러스터 상태 확인
• Nginx를 배포하여 KubeSphere 및 Kubernetes의 기본 기능을 확인하고 테스트합니다.

이 기사의 핵심 가치는 KubeSphere 및 Kubernetes 클러스터와 해당 솔루션을 배포하는 동안 발생하는 일반적인 문제에 초점을 맞춘다는 것입니다 . 동시에 두 가지 다른 운영 체제인 Kirin V10과 openEuler 22.03에서 발생하는 서로 다른 문제가 지적되었습니다.

이 기사의 배포 환경은 Kunpeng-920 칩을 기반으로 하는 Kirin V10 SP2의 aarch64 버전을 기반으로 하지만 CentOS, openEuler와 같은 ARM 버전 운영 체제 및 Feiteng(FT- 2500).

본 글에 소개된 내용은 R&D 및 테스트 환경에서 직접 사용할 수 있으며, 프로덕션 환경에 대한 특정 참조 의미가 있으므로 프로덕션 환경에서 직접 사용할 수 없습니다 .

이 기사의 불완전한 테스트 결론: KubeSphere 및 Kubernetes의 기본 기능을 사용할 수 있으며, 가장 일반적인 비즈니스 시나리오를 충족할 수 있는 DevOps 기능도 사용할 수 있습니다.

이 기사는 여러 기사를 게시하는 블로그인 OpenWrite 에서 게시되었습니다 !

Microsoft는 새로운 "Windows App" .NET 8 공식 GA를 출시하고 최신 LTS 버전 Xiaomi는 Xiaomi Vela가 완전 오픈 소스이며 기본 커널은 NuttX Alibaba Cloud 11.12라고 공식 발표했습니다. 실패 원인이 노출되었습니다: 액세스 키 서비스(Access Key Service) 핵심) 예외 Vite 5 공식적으로 GitHub 보고서 발표: TypeScript가 Java를 대체하고 세 번째로 가장 인기 있는 언어가 됨 Rust에서 Prettier를 다시 작성하는 데 수십만 달러의 보상 제공 오픈 소스 작성자에게 "프로젝트가 아직 살아 있나요?"라고 묻는 매우 무례하고 무례한 바이트댄스: AI를 사용하여 Linux 커널 매개 변수 연산자를 자동으로 조정하는 마법 작업: 백그라운드에서 네트워크 연결을 끊고 광대역 계정을 비활성화하고 사용자가 광 모뎀을 강제로 변경하도록 합니다.

{{o.이름}}

{{이름}}