2. 클러스터 목록 페이지에서 대상 클러스터의 ID를 클릭하여 클러스터 관리 페이지로 이동합니다.
3. 클러스터 관리 페이지의 왼쪽 사이드바에서 서비스 및 라우팅 > Service를 선택합니다.
4. Service 페이지에서 CLB 인스턴스 ID와 해당 VIP를 찾을 수 있습니다.
Service의 ClusterIP가 유효하지 않거나(정상적으로 액세스할 수 없음) ClusterIP가 없는 이유는 무엇인가요?
spec.type이 LoadBalancer인 Service의 경우 현재 TKE Serverless는 기본적으로 ClusterIP를 할당하지 않거나 할당된 ClusterIP가 유효하지 않습니다(정상적으로 액세스할 수 없음). 사용자가 ClusterIP를 사용하여 Service에 액세스해야 하는 경우 annotations에 다음 키-값 쌍을 추가하여 TKE Serverless가 사설망 CLB를 기반으로 ClusterIP를 구현함을 나타낼 수 있습니다.
service.kubernetes.io/qcloud-clusterip-loadbalancer-subnetid: Service CIDR 서브넷 ID
클러스터를 생성할 때 지정하는 Service CIDR 서브넷 ID는 subnet-******** 형식의 문자열입니다. CLB 기본 정보 페이지에서 서브넷 ID를 확인할 수 있습니다.
주의사항:
수정된 버전의 K8S(kubectl version에서 반환된 Server GitVersion에는 "eks." 또는 "tke." 접미사가 있음)를 사용하는 TKE Serverless 클러스터만 이 기능을 지원합니다. 수정되지 않은 K8S(kubectl version에서 반환된 Server GitVersion에는 "eks." 또는 "tke." 접미사가 없음)버전을 사용하는 이전에 생성된 TKE Serverless 클러스터의 경우 이 기능을 사용하려면 K8S 버전을 업그레이드해야 합니다.
CLB 인스턴스 유형(공중망 또는 사설망)을 어떻게 지정합니까?
TKE 콘솔 또는 Kubectl 명령 라인 툴을 통해 CLB 인스턴스 유형을 지정할 수 있습니다.
TKE 콘솔을 통해 지정
kubectl 명령 라인 툴을 통해 지정
Ingress의 경우 ‘네트워크 유형’에서 ‘공중망’ 또는 ‘사설망’를 선택하여 CLB 인스턴스 유형을 지정합니다.
‘사설망’ 유형의 CLB 인스턴스를 생성하려면 해당 annotation을 Service 또는 Ingress에 추가해야 합니다.
리소스 유형
annotations에 추가할 키-값 쌍
Service
service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: 서브넷 ID
Ingress
kubernetes.io/ingress.subnetId: 서브넷 ID
주의사항:
서브넷 ID는 subnet-******** 형식의 문자열이며, 이 서브넷은 클러스터를 생성 시 ‘클러스터 네트워크’에 지정된 VPC에 있어야 하며, 이 VPC 정보는 Tencent Cloud 콘솔 클러스터 ‘기본 정보’에서 확인할 수 있습니다.
기존 CLB 인스턴스를 어떻게 지정합니까?
TKE 콘솔 또는 Kubectl 명령 라인 툴을 통해 기존 CLB 인스턴스를 지정할 수 있습니다.
TKE 콘솔을 통해 지정
kubectl 명령 라인 툴을 통해 지정
Service 또는 Ingress를 생성할 때 기존 CLB 인스턴스를 사용하려면 ‘기존 사용’을 선택할 수 있습니다. Service는 Service 생성 후 ‘액세스 방식 업데이트’를 통해 기존 CLB 인스턴스를 사용하기 위해 ‘기존 사용’으로 전환할 수 있습니다.
Service/Ingress를 생성하거나 Service를 수정할 때 Service 또는 Ingress에 해당하는 annotation을 추가하면 됩니다.
리소스 유형
annotations에 추가할 키-값 쌍
Service
service.kubernetes.io/tke-existed-lbid: CLB 인스턴스 ID
Ingress
kubernetes.io/ingress.existLbId: CLB 인스턴스 ID
주의사항:
‘기존 CLB 인스턴스’는 ‘TKE Serverless for Service 또는 Ingress에 의해 생성된 CLB 인스턴스’일 수 없으며, TKE Serverless는 동일한 기존 CLB 인스턴스를 공유하기 위해 여러 Service/Ingress를 지원하지 않습니다.
CLB 인스턴스의 액세스 로그는 어떻게 확인하나요?
레이어 7 CLB 인스턴스만 액세스 로그 구성을 지원하지만 TKE Serverless for Ingress에서 생성한 레이어 7 CLB 인스턴스의 액세스 로그는 기본적으로 활성화되어 있지 않습니다. 아래와 같이 CLB 인스턴스의 세부 정보 페이지에서 CLB 인스턴스의 액세스 로그를 활성화할 수 있습니다.
TKE Serverless 클러스터의 경우 여러 Service가 기본적으로 동일한 CLB 인스턴스를 공유할 수 없습니다. Service가 다른 Service가 차지하는 CLB를 사용하기를 원하는 경우 이 annotation을 추가하고 value을 "true"로 지정하십시오. service.kubernetes.io/qcloud-share-existed-lb: true. 이 annotation에 대한 자세한 내용은 Annotation을 참고하십시오.
왜 CLB VIP 액세스에 실패하나요?
분석하려면 아래 단계를 따르십시오.
CLB 인스턴스 유형 보기
1. ‘Service’ 또는 ‘Ingress’ 페이지에서 CLB 인스턴스 ID를 클릭하면 CLB 기본 정보 페이지로 이동합니다.
2. CLB 기본 정보 페이지에서 상기 CLB 인스턴스의 ‘인스턴스 유형’을 확인할 수 있습니다.
CLB VIP 액세스 환경 정상 여부 확인
CLB 인스턴스의 ‘인스턴스 유형’이 사설망인 경우 해당 VIP는 자신이 속한 VPC에서만 액세스할 수 있습니다.
TKE Serverless 클러스터에 있는 Pods의 IP는 VPC에 있는 ENI IP이므로 Pods에서 클러스터에 있는 Service 또는 Ingress의 CLB 인스턴스 VIP에 액세스할 수 있습니다.
참고
LoadBalancer 시스템에는 항상 루프백 문제(예시: AzureLoad Balancer 문제 해결)가 있습니다. 이 워크로드가 속한 Pods에서 자체적으로(Service 또는 Ingress를 통해) 열린 VIP를 통해 워크로드가 제공하는 서비스에 액세스하지 마십시오. 즉, Pods는 VIP를 통해 자체적으로 제공되는 서비스(‘사설망’ 및 ‘공중망’ 포함)에 액세스해서는 안 됩니다. 그렇지 않으면 VIP에 해당하는 규칙에 따라 RS/Pod가 하나만 있는 경우 액세스 지연이 증가하거나 액세스가 차단될 수 있습니다.
CLB 인스턴스의 ‘인스턴스 유형’이 공중망인 경우 공중망 액세스가 활성화 된 환경에서 VIP에 액세스 할 수 있습니다.
클러스터에서 공중망 VIP에 액세스하려면 NAT 게이트웨이 또는 기타 방법을 구성하여 클러스터에 대한 공개 네트워크 액세스가 활성화되었는지 확인하십시오.
예상되는 Pods의 IP + 포트를 포함하여(및 포함) CLB에서 RS 보기
CLB 관리 페이지에서 리스너 관리 탭을 선택하여 포워딩 규칙(레이어 7 프로토콜) 및 바인딩된 백엔드 서비스(레이어 4 프로토콜)를 봅니다. IP 주소는 각 Pod의 IP로 예상됩니다. Ingress에 대해 TKE Serverless에서 생성한 CLB의 예시는 다음과 같습니다.
해당 Endpoints 정상 여부 확인
워크로드(Workload)의 레이블(Labels) 및 Service 리소스의 선택기(Selector)를 올바르게 설정한 경우, 워크로드의 Pods가 성공적으로 실행되면 K8S에 의해 Pods가 Service에 해당하는 Endpoints의 준비된 IP 목록으로 추가되는 것을 kubectl get endpoints 명령을 통해 확인할 수 있습니다. 예시는 다음과 같습니다.
생성되었지만 비정상 상태인 Pods는 Service에 해당하는 Endpoints의 준비되지 않은 IP 목록에 K8S에 의해 추가됩니다. 예는 다음과 같습니다.
주의사항:
비정상적인 Pods의 원인을 볼 수 있도록 kubectl describe 명령을 실행할 수 있습니다. 명령은 다음과 같습니다.
kubectl describe pod nginx-7c7c647ff7-4b8n5 -n demo
Pods가 정상적으로 서비스를 제공할 수 있는지 확인
Running 상태의 Pods조차도 일부 예외로 인해 일반적으로 서비스를 제공하지 못할 수 있습니다. 예를 들어, 지정된 프로토콜+포트는 미수신, Pods의 내부 로직 오류, 프로세스 차단 등이 있습니다. kubectl exec 명령을 실행하여 Pod에 로그인하고 telnet/wget/curl 명령을 실행하거나 사용자 지정 클라이언트 툴을 사용하여 Pod IP+포트에 직접 액세스 할 수 있습니다. Pod에서 직접 액세스가 실패하면 Pod가 정상적으로 서비스를 제공할 수 없는 이유를 추가로 분석해야 합니다.
Pod에 바인딩 된 보안 그룹이 Pods가 제공하는 서비스의 프로토콜과 포트를 허용하는지 확인
보안 그룹은 Linux 서버의 IPTables 규칙과 마찬가지로 Pods의 네트워크 액세스 정책을 제어합니다. 실제 상황에 따라 확인하십시오.
TKE 콘솔을 통해 워크로드 생성
kubectl 명령을 실행하여 워크로드 생성
인터랙티브 프로세스는 보안 그룹을 지정해야 하며 TKE Serverless는 이 보안 그룹을 사용하여 Pods의 네트워크 액세스 정책을 제어합니다. 지정된 보안 그룹은 워크로드의 spec.template.metadata.annotations에 저장되고 마지막으로 Pods의 annotations에 추가됩니다. 예시는 다음과 같습니다.
kubectl 명령을 통해 워크로드를 생성하고 Pods에 대한 보안 그룹을 지정하지 않는 경우(annotations 추가를 통해) TKE Serverless는 계정 아래 리전 내에 있는 기본 프로젝트의 default 보안 그룹을 사용합니다. 단계는 다음과 같습니다.
