tencent cloud

Cloud Load Balancer

릴리스 정보 및 공지 사항
릴리스 노트
제품 공지
제품 소개
제품 개요
제품 장점
시나리오
기술 원리
Product Comparison
사용 제한
Service Regions and Service Providers
구매 가이드
과금 개요
비용 계산 항목
구매 방식
연체 안내
제품 속성 선택
시작하기
도메인 이름 기반 CLB 시작하기
CLB 시작하기
CentOS에서 Nginx 배포하기
CentOS에서 Java Web 배포하기
운영 가이드
CLB 인스턴스
CLB 리스너
리얼 서버
상태 확인
인증서 관리
로그 관리
모니터링 및 알람
액세스 관리
사례 튜토리얼
CLB에 인증서 배치(양방향 인증)
HTTPS 포워딩 구성
리얼 클라이언트 IP 가져오기
로드 밸런싱 구성 모니터링 및 알람에 대한 모범 사례
다중 가용존에서 HA 구현
로드 밸런싱 알고리즘 선택 및 가중치 구성 예시
CLB 수신 도메인 이름에 대한 WAF 보호 구성하기
OPS 가이드
과도한 TIME_WAIT 상태의 클라이언트에 대한 솔루션
CLB HTTPS 서비스 성능 테스트
스트레스 테스트 FAQ
CLB 인증서 작업 권한
문제 해결
UDP 상태 확인 예외 발생
API 참조
History
Introduction
API Category
Instance APIs
Listener APIs
Backend Service APIs
Target Group APIs
Redirection APIs
Other APIs
Classic CLB APIs
Load Balancing APIs
Making API Requests
Data Types
Error Codes
CLB API 2017
FAQ
과금 관련
CLB 구성
헬스체크 이상 점검
HTTPS
WS/WSS 프로토콜 지원
HTTP/2 프로토콜 지원
연락처
용어집
문서Cloud Load BalancerFAQ헬스체크 이상 점검헬스체크 이상 점검v2

헬스체크 이상 점검v2

PDF
포커스 모드
폰트 크기
마지막 업데이트 시간: 2024-12-20 12:13:13
Cloud Load Balancer(CLB)는 헬스체크를 통해 백엔드 서비스의 가용성을 판단합니다. 헬스체크 이상이 발생한 경우, 다음 방법을 참고하여 문제를 해결할 수 있습니다.
설명:
헬스체크에서 이상이 감지되면 CLB는 이상 백엔드 서비스로 트래픽을 더 이상 전달하지 않습니다.
모든 백엔드 서비스에서 이상이 감지되면, 요청은 모든 백엔드 서비스로 전달됩니다.
헬스체크 원리에 대해서는 헬스체크 개요를 참고하시기 바랍니다.

1. CVM 보안 그룹 및 ACL 차단 점검

주의:
보안 그룹이 기본적으로 허용되도록 설정되어 있는 경우 무시할 수 있습니다.

단계 1: 인스턴스 헬스체크 소스 IP 확인

1. CLB 콘솔에 로그인하여, 헬스체크 소스 IP를 확인하고자 하는 인스턴스 ID를 클릭하세요.
2. 인스턴스 상세 페이지에서 리스너 관리 탭을 클릭하고, 리스너를 클릭한 다음 오른쪽에서 펼치기를 클릭하여 리스너 상세정보를 확인합니다.
3. 리스너 상세정보 페이지에서 현재 헬스체크 소스 IP를 확인할 수 있으며, 위 예시의 헬스체크 소스 IP는 100.64.0.0/10 네트워크 세그먼트입니다.

단계 2: 보안 그룹이 헬스체크 소스 IP를 허용하는지 확인

1. CLB 콘솔에 로그인하고, CLB 인스턴스 ID를 클릭합니다.
2. CLB 인스턴스 상세 페이지에서 보안 그룹 탭 > 바인딩된 보안 그룹 ID를 클릭하여 보안 그룹 규칙 페이지로 이동합니다.
3. 인바운드 규칙 탭에서 규칙 추가를 클릭합니다.
4. 인바운드 규칙 추가 창에서 소스에 인스턴스 헬스체크 소스 IP 확인에서의 100.64.0.0/10 네트워크 세그먼트를 입력하고(첫 번째 단계에서 확인한 헬스체크 소스 IP가 CLB VIP인 경우 해당 VIP를 소스에 입력), 프로토콜 포트에는 백엔드 서버에서 사용하는 프로토콜 포트를 입력하고, 정책을 허용으로 선택한 다음 확인을 클릭하여 추가를 완료합니다.

단계 3: 서브넷의 네트워크 ACL이 헬스체크 소스 IP를 허용하는지 확인

1. CVM 콘솔에 로그인하여 CVM 인스턴스를 클릭하고 기본 정보 페이지로 이동합니다.
2. 기본 정보 페이지에서 네트워크 정보 모듈의 소속 서브넷을 클릭하면 서브넷 정보 페이지로 이동합니다.
3. ACL 규칙 탭을 클릭하고, 이 페이지에서 바인딩된 ACL을 클릭한 후 인바운드 규칙과 아웃바운드 규칙에서 헬스체크 소스 IP를 허용합니다.
4. 첫 번째 단계에서 확인한 헬스체크 소스 IP가 100.64.0.0/10 네트워크 세그먼트이면(확인한 헬스체크 소스 IP가 CLB VIP인 경우), 이를 소스 IP에 입력하고, 프로토콜 유형에는 헬스체크 방식에서 선택한 프로토콜을 입력하며, 포트는 ALL을 입력하고, 정책을 허용으로 선택한 후 저장을 클릭하여 추가를 완료합니다.
설명:
CLB가 COS, CDB, Redis, Ckafka 등의 공공 서비스를 바인딩한 경우, 서비스 바인딩된 보안 그룹 및 해당 서브넷의 네트워크 ACL이 CLB 헬스체크 소스 IP를 허용하는지 확인해야 합니다. 위의 세 단계를 참고하여 검사할 수 있습니다.

단계4: IDC에서 SNAT IP를 허용하는지 여부 확인

사용자가 Cloud Connect Network(CCN)이나 전용 제품을 통해 IDC 내의 머신을 CLB 인스턴스의 백엔드 서버로 바인딩한 경우, IDC에서 SNAT IP를 허용하는지 여부를 확인해야 합니다.
1. CLB 콘솔에 로그인하고, CLB의 인스턴스 ID를 클릭합니다.
2. 인스턴스 기본 정보 페이지에서, 백엔드 서비스 모듈에서 SNAT IP를 확인합니다.
3. 사용자는 IDC 내의 방화벽 장치 또는 머신의 iptables에서 해당 SNAT IP가 허용되는지 확인해야 합니다.

II. Cloud Virtual Machine(CVM) 점검

백엔드 서버가 CVM일 경우, 아래 단계를 참고하여 점검합니다.

단계 1: 머신 내부 자가 점검

1. CVM 콘솔에 로그인하여, 머신 내부로 들어가서 서버 측 프로세스와 포트를 점검합니다.
CLB 설정에서 백엔드 서버 포트를 점검합니다. 예시로 80 포트 점검 명령어입니다.
netstat -anltu | grep -w 80
2. 80 포트가 리스닝 상태인 경우 머신 내부의 이상을 배제할 수 있습니다.
주의:
리스닝 주소는 0.0.0.0 또는 CVM의 내부 IP여야 하며, 리스닝 주소가 127.0.0.1만 있는 경우 머신 내부의 이상을 배제할 수 없습니다.
tcp        0      0 0.0.0.0:80              0.0.0.0:*               
LISTEN      9/nginx: master pro 
tcp6       0      0 :::80                   :::*              
LISTEN      9/nginx: master pro

단계 2: CVM이 정상적으로 반환되는지 확인

1. 동일한 VPC의 다른 머신을 사용하여 목표 CLB 백엔드 CVM의 HTTP/HTTPS 포트가 정상적으로 반환되는지 확인합니다.
예를 들어 CLB 콘솔에 구성된 location 디렉토리가 "/"이고, HTTP 포트에서 백엔드 CVM의 인트라넷 IP를 점검합니다. IP 10.0.0.16, 포트 80을 예로 들 수 있습니다.
curl -I http://10.0.0.16:80/
2. 실제 응답 결과가 정상인지 판단하기 위해, 콘솔에 구성된 응답 상태 코드를 기준으로 합니다. 예를 들어 구성된 응답 상태 코드가 "200" 또는 "404"인 경우, 해당 응답 결과는 정상으로 간주되며 이 이상점을 배제할 수 있습니다.
HTTP/1.1 200 OK
Server: nginx/1.20.1
Date: Sat, 14 Sep 2024 07:07:01 GMT
Content-Type: text/html
HTTP/1.1 404 Not Found
Server: nginx/1.20.1
Date: Sat, 14 Sep 2024 07:08:51 GMT
Content-Type: text/html

3단계: iptables를 허용하는지 확인

1. 확인 방법은 방화벽 문제를 참고하시기 바랍니다. 검사 명령은 다음과 같습니다:
iptables -nvL
2. 차단된 것이 확인되면 헬스체크 소스 IP와 CLB 리스너 구성을 위한 백엔드 서버 포트를 허용하는 명령을 추가해야 합니다. 헬스체크 소스 IP가 100.64.0.0/10이며, 백엔드 서버 포트가 80과 443인 경우를 예로 들겠습니다.
iptables -A INPUT -p tcp -s 100.64.0.0/10 --dport 80 -j ACCEPT
iptables -A INPUT -p tcp -s 100.64.0.0/10 --dport 443 -j ACCEPT
iptables -A INPUT -p icmp -s 100.64.0.0/10 -j ACCEPT
다음 명령을 상이한 Linux 버전에 따라 실행하십시오:
#Centos/RHEL:
sudo systemctl enable iptables
sudo service iptables save
#Ubuntu/Debian:
sudo systemctl enable netfilter-persistent
sudo netfilter-persistent save
3. 허용 후 다시 점검 명령을 실행하여 문제를 해결하십시오.
설명:
백엔드 프로토콜이 HTTPS인 경우, 헬스체크가 실패하면 HTTP로 변경하는 것이 좋습니다.
백엔드에서 HTTPS 프로토콜을 사용해야 하는 경우, Nginx 서버 SSL 인증서 설치(Linux)를 참고하여 SSL을 구성하고 확인하십시오. 문제가 계속 발생하면, 티켓 제출하여 처리하십시오.
CLB에서 HTTPS 리스너를 구성하고 백엔드 프로토콜이 HTTPS인 경우에만 백엔드 서비스에 인증서를 구성해야 합니다.

3. 컨테이너 점검

백엔드 서버가 컨테이너인 경우, TKE 클러스터 바인딩을 예로 들면 다음 단계를 참고하여 점검합니다.
TKE 컨테이너 시나리오에서 CLB의 백엔드 서버는 pod 다이렉트 액세스와 비다이렉트 액세스(즉, CLB가 nodeport에 바인딩됨) 두 가지 시나리오로 나뉩니다. 직접 연결 여부를 판단하는 방법은 다음과 같으며, 자세한 내용은 LoadBalancer Pod 다이렉트 액세스 모드 Service 사용-TKE 표준 클러스터 가이드를 참고하십시오.
Service에 service.cloud.tencent.com/direct-access: "true" 주석이 구성되어 있으면 다이렉트 액세스입니다.
Ingress에 ingress.cloud.tencent.com/direct-access: "true" 주석이 구성되어 있으면 다이렉트 액세스입니다.

단계 1: CLB pod 다이렉트 액세스 시나리오

CLB pod 다이렉트 액세스 시나리오에서는 CLB 트래픽이 직접 백엔드 pod로 전달됩니다.
점검 경로는 다음과 같습니다:
1. 컨테이너 내 리스닝 포트 확인
컨테이너에 로그인한 후 머신 내부 자가 점검 을 참고하여 점검을 진행하세요.
컨테이너에 로그인하는 방법은 원격 단말기 기본 작업을 참고하시기 바랍니다.
2. 컨테이너 로컬 자가 액세스 정상인지 확인
컨테이너에 로그인한 후 CVM에서 정상적으로 반환되는지 확인을 참고하여 점검을 진행하세요.
컨테이너에 로그인하는 방법은 원격 단말기 기본 작업을 참고하시기 바랍니다.
3. Pod가 위치한 node에서 Pod 접근이 정상인지 확인
Pod가 슈퍼 노드에서 실행되지 않는 경우, node에 로그인한 후 수동 테스트를 참고하시기 바랍니다.
일반 노드 로그인의 경우 표준 로그인 방식으로 Linux 인스턴스에 액세스하기(추천)를 참고하시기 바랍니다.
네이티브 노드 로그인의 경우 네이티브 노드에서 SSH 키 로그인 활성화를 참고하시기 바랍니다.
4. node 내부 구성 확인
4.1 ip_forward 확인
점검 명령 입력(ipv6의 경우, 명령어 중 ipv4를 ipv6으로 변경해야 합니다):
sysctl net.ipv4.ip_forward
정상 결과:
net.ipv4.ip_forward = 1
비정상 결과:
net.ipv4.ip_forward = 0
비정상 결과 해결 명령:
sysctl -w "net.ipv4.ip_forward=1" && echo 'net.ipv4.ip_forward=1' >>/etc/sysctl.conf
4.2 ENI forward 확인
점검 명령어 입력:
sysctl -a 2>/dev/null | grep ipv4 | grep -w forwarding
정상 결과의 모든 매개변수 값은 1입니다. 예:
net.ipv4.conf.all.forwarding = 1
정상 결과 전체 예시:

비정상 결과는 매개변수 값이 0입니다. 예:
net.ipv4.conf.all.forwarding = 0
비정상 결과 처리 명령어, 예: (실제 비정상 발생 항목에 따라 net.xxx.forwarding 항목에 대해 다음 명령어를 실행합니다)
sysctl -w net.ipv4.conf.all.forwarding=1
4.3 node의 iptables가 forward를 차단하는지 확인
점검 명령어 입력:
iptables -nvL FORWARD
출력 결과:
policy 뒤의 전략은 ACCEPT이어야 합니다. DROP일 경우, forward 차단이 발생할 수 있습니다.
KUBE-FORWARD, KUBE-SERVICES, KUBE-EXTERNAL-SERVICES, DOCKER-USER 이 네 가지 규칙만 있어야 합니다. 다른 규칙이 있을 경우, forward 차단이 발생할 수 있습니다.
다음은 정상의 예시입니다.

4.4 보안 그룹 허용 여부 확인
pod가 vpc-cni 모드인 경우, node의 ENI 보안 그룹 허용 여부를 확인해야 합니다. 그렇지 않으면 node 자체의 보안 그룹 허용 여부를 확인해야 합니다.
CLB 기본 허용을 활성화하거나 보안 그룹의 헬스체크 소스 IP 허용 확인을 참고하여 허용할 수 있습니다.

단계 2: CLB 비다이렉트 액세스 시나리오

CLB 비다이렉트 액세스 시나리오에서는 CLB 트래픽이 먼저 클러스터 내 node의 nodeport 포트로 전달된 후 iptables/ipvs의 전달을 거쳐, nodeport로 입력된 트래픽은 실제 백엔드 pod로 전달되므로, 링크가 길어집니다.
점검 경로:
1. CLB pod 다이렉트 액세스 시나리오 관련 내용 확인
CLB pod 다이렉트 액세스 시나리오 관련 내용을 확인하고, 이를 기반으로 후속 점검 단계를 완료합니다.
2. node의 보안 그룹 허용 상태 확인
노드의 보안 그룹과 VPC-CNI 모드 pod의 보안 그룹이 TKE 보안 그룹 설정을 참고하여 허용되었는지 확인합니다.
일반 노드의 보안 그룹 설정은 보안 그룹 구성을 참고하시기 바랍니다.
네이티브 노드의 보안 그룹 설정은 네이티브 노드 수정을 참고하시기 바랍니다.
슈퍼 노드의 보안 그룹 설정은 슈퍼 노드 생성 및 슈퍼 노드의 스케줄링 가능한 Pod 설명을 참고하시기 바랍니다.
VPC-CNI 모드 pod의 보안 그룹 설정은 VPC-CNI 모드 보안 그룹 이용 안내를 참고하시기 바랍니다.
3. 건강 상태가 비정상인 노드에서 kube-proxy 컴포넌트가 정상적으로 실행되고 있는지 확인합니다
kube-proxy 컴포넌트는 iptables/ipvs 규칙을 전달하는 역할을 합니다. 확인 방법은 다음과 같습니다:
# 노드에서 kube-proxy pod를 받고, Ready 상태인지 확인합니다.
kubectl get pod -n kube-system -l k8s-app=kube-proxy -owide | grep <노드명>
# kube-proxy 실행 로그에 명확한 오류가 있는지 확인합니다.
kubectl logs -n kue-system <kube-proxy-xxxxx명>
이상이 있는 경우 클러스터 Kube-Proxy 문제 해결을 참고하시기 바랍니다.
4. 헬스체크에서 문제가 있는 CLB 백엔드 노드에 로그인하여 백엔드 pod에 순차적으로 접근합니다.
TCP 리스너는 telnet으로 연결성을 테스트할 수 있고, HTTP/HTTPS 리스너는 curl로 접근 결과를 테스트할 수 있습니다. 자세한 내용은 TCP 서비스 연결성 확인 및 HTTP/HTTPS 서비스 반환 확인을 참고하시기 바랍니다.

수동 테스트에 대한 보충 설명

단계 1: 포트 리스닝 상태 확인

netstat, ss 등의 명령어를 사용하여 포트 리스닝 상태를 확인할 수 있습니다. 반환되 리스닝 주소가 127.0.0.1만인 경우 이상을 배제할 수 없습니다.
1. netstat 명령어를 사용하여 포트 리스닝 상태를 확인합니다. 80 포트를 예로 들면:
netstat -tulnp | grep 80
출력에 다음과 같은 내용이 있으면 리스닝 상태로 간주합니다:
tcp        0      0 0.0.0.0:80              0.0.0.0:*               
LISTEN      9/nginx: master pro 
tcp6       0      0 :::80                   :::*              
LISTEN      9/nginx: master pro
2. ss 명령어를 사용하여 포트 리스닝 상태를 확인합니다. 80 포트를 예로 들면:
ss -tulnp | grep 80
출력에 다음과 같은 내용이 있으면 리스닝 상태로 간주합니다:
tcp    LISTEN     0      511       *:80                    *:*                   
users:(("nginx",pid=9,fd=6))
tcp    LISTEN     0      511    [::]:80                 [::]:*                   
users:(("nginx",pid=9,fd=8))

단계 2: TCP 서비스 연결 상태 확인

telnet 명령어를 통해 TCP 서비스의 연결 상태를 확인할 수 있습니다.
주의:
낮은 버전의 busybox telnet를 사용하여 테스트하지 마십시오. 연결 정상 여부와 상관없이 에코가 나타나지 않습니다.
IP 172.16.1.29의 80 포트를 확인하는 예:
echo "" |telnet 172.16.1.29 80
Connected로 출력되면 정상적으로 연결된 것입니다. Trying 상태에서 멈추면 네트워크가 원활하지 않으므로, 보안 그룹 등을 확인해야 합니다(구체적인 내용은 서브넷의 네트워크 ACL의 헬스체크 소스 IP 허용 여부 확인, iptables 허용 여부 확인 챕터를 참고하시기 바랍니다.). Connection refused가 반환되면 포트가 리스닝되지 않는 것입니다.
Trying 172.16.1.29...
Connected to 172.16.1.29.
Escape character is '^]'.
Connection closed by foreign host.

단계 3: HTTP/HTTPS 서비스 상태 확인

service의 HTTP 상태 코드를 curl 명령어로 확인할 수 있습니다.
요청 프로토콜이 HTTP, 메서드가 GET, 도메인이 mydomain.com, 경로가 /health, 포트가 8080, IP가 172.16.1.29인 경우를 예로 들 수 있습니다.
curl -X GET -H "Host: mydomain.com" http://172.16.1.29:8080/health -s -o /dev/null -w "\\nhttpcode: %{http_code}\\n"
응답 결과:
httpcode: 404
헬스체크 구성 정상 상태코드에서 1xx-4xx 반환 예상을 선택한 경우 위의 응답 결과가 404로 반환되면 예상과 일치합니다. 응답 결과가 헬스체크 구성 예상과 일치하지 않지만 실제로는 정상일 경우 예상 구성을 조정하는 것이 좋습니다.

위의 방법으로 고객님의 문제를 해결할 수 없다면 티켓 제출하여 처리하시기 바랍니다.






이전 주제: 상태 확인 문제 해결다음 주제: HTTPS

도움말 및 지원

문제 해결에 도움이 되었나요?

피드백