Faq

faq.md# 자주 묻는 질문

1 최초 설치 중 문제가 발생하여 정리 후 재설치해야 하는 경우¶

참고: 최초 설치 중 문제가 발생하여 모두 제거하고 재설치해야 하는 경우에만 해당됩니다. 아래 정리 단계를 신중히 확인한 후 실행하세요!

설치 문제가 발생하여 모두 제거하고 재설치해야 하는 경우, 다음 세 곳을 정리한 후 Launcher에서 Guance 재설치를 시작할 수 있습니다.

1.1 설치된 Guance 애플리케이션 서비스 정리¶

Kubernetes에 설치된 다양한 Guance 애플리케이션 서비스를 정리하려면 운영 작업 머신에서 Launcher 컨테이너에 접속하여 Launcher에 포함된 정리 스크립트를 실행합니다.

kubectl exec -it launcher-xxxxxxxx-xxx -n launcher /bin/bash

launcher-xxxxxxxx-xxx는 launcher 서비스 pod 이름입니다! 컨테이너에 접속하면 Launcher 서비스에 포함된 k8s-clear.sh 스크립트(1.47.103 이후 버전에서는 /config/tools 디렉터리에 있음)를 확인할 수 있습니다. 이 스크립트를 실행하면 모든 Guance 애플리케이션 서비스 및 k8s 리소스가 정리됩니다.

1.2 MySQL에서 자동 생성된 데이터베이스 정리¶

Launcher 컨테이너에 접속하면 Launcher 컨테이너에 mysql 클라이언트 도구가 포함되어 있습니다. 다음 명령어를 사용하여 Guance MySQL 인스턴스에 연결합니다.

mysql -h <mysql 인스턴스 host> -u root -P <mysql 포트> -p

MySQL 관리자 계정으로 연결해야 합니다. 연결 후 다음 6개의 MySQL 데이터베이스 및 사용자 정리 명령어를 실행합니다.

drop database df_core;
drop user df_core;
drop database df_message_desk;
drop user df_message_desk;
drop database df_func;
drop user df_func;
drop database df_dialtesting;
drop user df_dialtesting;

1.3 InfluxDB에서 자동 생성된 사용자 정리¶

시계열 엔진으로 InfluxDB를 사용하는 경우 influx 클라이언트 도구를 사용하여 InfluxDB에 연결하고 다음 두 사용자 정리 명령어를 실행합니다.

drop user user_wr;
drop user user_ro;

2 배포 시 주의사항¶

2.1 배포 완료 후 설치 프로그램이 자동 생성한 Kubernetes 리소스를 수동으로 수정할 수 있나요?¶

수동으로 수정할 수 없습니다. 이후 새 버전이 출시되어 Launcher로 업그레이드 설치 시, 설치 시 입력한 구성 정보를 기반으로 Deployment, Service, Ingress 등의 리소스가 다시 생성되기 때문입니다(Configmap 제외. Configmap 구성 항목의 정보는 수동으로 수정할 수 있지만, 임의로 수정하면 프로그램 실행에 문제가 발생할 수 있습니다).

3 독립 컨테이너 Rancher Server 인증서 갱신¶

3.1 인증서가 만료되지 않은 경우 처리 방법¶

Rancher Server가 정상적으로 실행됩니다. Rancher v2.0.14+, v2.1.9+, v2.2.2+로 업그레이드하면 인증서 유효 기간을 자동으로 확인하고, 만료가 임박한 경우 자동으로 새 인증서를 생성합니다. 따라서 독립 컨테이너로 실행되는 Rancher Server는 인증서 만료 전에 Rancher 버전을 SSL 인증서 자동 갱신을 지원하는 버전으로 업그레이드하기만 하면 되며, 다른 작업은 필요하지 않습니다.

3.2 인증서가 이미 만료된 경우 처리 방법¶

Rancher Server가 정상적으로 실행되지 않습니다. Rancher v2.0.14+, v2.1.9+, v2.2.2+로 업그레이드해도 인증서 오류가 발생할 수 있습니다. 이 경우 다음 절차를 통해 처리할 수 있습니다.

Rancher 버전을 v2.0.14+, v2.1.9+, v2.2.2+로 정상 업그레이드합니다.
다음 명령어를 실행합니다.
2.0 또는 2.1 버전

docker exec -ti <rancher_server_id> mv /var/lib/rancher/management-state/certs/bundle.json /var/lib/rancher/management-state/certs/bundle.json-bak

2.2+ 버전

docker exec -ti <rancher_server_id> mv /var/lib/rancher/management-state/tls/localhost.crt /var/lib/rancher/management-state/tls/localhost.crt-bak

2.3+ 버전

 docker exec -ti <rancher_server_id> mv /var/lib/rancher/k3s/server/tls /var/lib/rancher/k3s/server/tlsbak

 # 두 번 실행: 첫 번째는 인증서 요청, 두 번째는 인증서 로드 및 시작
 docker restart <rancher_server_id>

2.4+ 버전

a. Rancher Server에 exec로 접속

kubectl --insecure-skip-tls-verify -n kube-system delete secrets k3s-serving
kubectl --insecure-skip-tls-verify delete secret serving-cert -n cattle-system
rm -f /var/lib/rancher/k3s/server/tls/dynamic-cert.json

b. Rancher Server 재시작

docker restart <rancher_server_id>

c. 다음 명령어로 매개변수 새로고침

curl --insecure -sfL https://server-url/v3

Rancher Server 컨테이너 재시작

docker restart <rancher_server_id>

4 Rancher Server 인증서 만료로 k8s 클러스터 관리 불가 처리¶

클러스터 인증서가 이미 만료된 경우 Rancher v2.0.14, v2.1.9 이상 버전으로 업그레이드해도 인증서를 갱신할 수 없습니다. Rancher는 Agent를 통해 인증서를 갱신하며, 인증서가 만료되면 Agent와 연결할 수 없습니다.

4.1 해결 방법¶

노드의 시간을 수동으로 설정하여 시간을 약간 뒤로 조정할 수 있습니다. Agent는 K8S Master 및 Rancher Server와만 통신하므로, Rancher Server 인증서가 만료되지 않은 경우 K8S Master 노드 시간만 조정하면 됩니다. 조정 명령어:

# ntp 동기화를 비활성화합니다. 그렇지 않으면 시간이 자동으로 업데이트됩니다.
timedatectl set-ntp false
# 노드 시간 수정
timedatectl set-time '2019-01-01 00:00:00'

그런 다음 Rancher Server를 업그레이드하고, 인증서 갱신이 완료된 후 시간을 다시 동기화합니다.

timedatectl set-ntp true

인증서 유효 기간 확인

openssl x509 -in /etc/kubernetes/ssl/kube-apiserver.pem -noout -dates

5 DataWay를 생성했지만 화면에서 보이지 않는 이유¶

5.1 일반적인 원인 분석¶

Dataway 서비스가 서버에 배포된 후 정상적으로 실행되지 않았습니다.
Dataway 서비스 구성 파일이 잘못되었습니다. 올바른 수신 포트, 워크스페이스 토큰 정보가 구성되지 않았습니다.
Dataway 서비스 실행 구성이 잘못되었습니다. 자세한 내용은 Dataway 로그를 확인하여 파악할 수 있습니다.
Dataway를 배포한 서버가 kodo 서비스와 통신할 수 없습니다(dataway 서버의 hosts에 df-kodo 서비스의 올바른 해석이 추가되지 않은 경우 포함).
kodo 서비스에 이상이 있습니다. 자세한 내용은 kodo 서비스 로그를 확인하여 확인할 수 있습니다.
df-kodo ingress 서비스가 올바르게 구성되지 않았습니다. http|https://df-kodo.<xxxx>:<port>에 접근할 수 없는 경우가 이에 해당합니다.

6 신서틱 테스트 서비스를 사용할 수 없는 이유¶

6.1 원인 분석¶

배포된 Guance 애플리케이션이 오프라인 환경이며, 물리 노드 네트워크 환경이 외부로 나갈 수 없습니다(비교적 흔함).
자체 호스팅 탐지 노드 네트워크에 이상이 있습니다.
지역 공급업체 네트워크에 이상이 있습니다.
신서틱 테스트 생성이 잘못되었습니다.

7 배포 시 자주 발생하는 문제 및 해결 방법¶

7.1 `describe pods` 시 `unbound immediate PersistentVolumeClaims` 오류 발생¶

pvc 확인

NAMESPACE    NAME                                     STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS       AGE
default      opensearch-single-opensearch-single-0    Bound     pvc-0da2cb6f-1cb9-4630-b0ab-512ce57743a8   16Gi       RWO            openebs-hostpath   19d
launcher     persistent-data                          Pending                                                                        df-nfs-storage     6m3s
middleware   data-es-cluster-0                        Bound     pvc-36e48f5a-37b3-4c28-ad14-059265ee3009   50Gi       RWO            openebs-hostpath   18d

persistent-data의 상태가 Pending인 것을 확인할 수 있습니다.

nfs-subdir-external-provisioner 컨테이너 상태 확인

kubectl get pods -n kube-system  | grep nfs-subdir-external-provisioner
nfs-provisioner-nfs-subdir-external-provisioner-58b7cdf6f5dr5vr   0/1     ContainerCreating   0             7h7m

nfs-provisioner-nfs-subdir-external-provisioner-58b7cdf6f5dr5vr 정보 확인

kubectl describe  -n kube-system pods nfs-provisioner-nfs-subdir-external-provisioner-58b7cdf6f5dr5vr
....
  Type     Reason       Age                     From     Message
  ----     ------       ----                    ----     -------
  Warning  FailedMount  30m (x49 over 6h53m)    kubelet  Unable to attach or mount volumes: unmounted volumes=[nfs-subdir-external-provisioner-root], unattached volumes=[kube-api-access-5p4qn nfs-subdir-external-provisioner-root]: timed out waiting for the condition
  Warning  FailedMount  5m27s (x136 over 7h4m)  kubelet  Unable to attach or mount volumes: unmounted volumes=[nfs-subdir-external-provisioner-root], unattached volumes=[nfs-subdir-external-provisioner-root kube-api-access-5p4qn]: timed out waiting for the condition
  Warning  FailedMount  74s (x217 over 7h6m)    kubelet  MountVolume.SetUp failed for volume "nfs-subdir-external-provisioner-root" : mount failed: exit status 32
Mounting command: mount
Mounting arguments: -t nfs 10.200.14.112:/nfsdata /var/lib/kubelet/pods/3970ff5f-5dbf-419e-a6af-3080508d2524/volumes/kubernetes.io~nfs/nfs-subdir-external-provisioner-root
Output: mount: wrong fs type, bad option, bad superblock on 10.200.14.112:/nfsdata,
       missing codepage or helper program, or other error
       (for several filesystems (e.g. nfs, cifs) you might
       need a /sbin/mount.<type> helper program)

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

wrong fs type, bad option 원인은 nfs-utils가 설치되지 않았기 때문입니다.

nfs-utils 설치

호스트에서 다음 명령어를 실행합니다.

yum install nfs-utils

Faq