tencent cloud

Tencent Kubernetes Engine

문서Tencent Kubernetes Engine

LoadBalancer Pod 다이렉트 액세스 모드 Service 사용

Download
포커스 모드
폰트 크기
마지막 업데이트 시간: 2023-04-26 18:43:22

작업 시나리오

네이티브 LoadBalancer 모드의 Service의 경우 CLB(Cloud Load Balancer)가 자동으로 생성될 수 있습니다. 먼저 클러스터의 Nodeport를 통해 트래픽을 클러스터로 포워딩한 다음 iptable 또는 ipvs를 통해 다시 포워딩합니다. 이 모드의 Service는 대부분의 시나리오에서 사용자의 요구를 충족할 수 있지만 다음 시나리오에는 CLB-to-Pod 다이렉트 액세스 모드의 Service가 권장됩니다.
소스 IP를 가져와야 합니다(비다이렉트 액세스 모드의 경우 Local 포워딩이 활성화되어야 함).
더 높은 포워딩 성능이 요구됩니다(CLB와 Service가 비다이렉트 액세스 모드일 때 CLB는 2 레이어이므로 성능 손실이 불가피함).
Pod 레이어에는 완전한 상태 확인 및 세션 지속성이 필요합니다(CLB와 Service가 비다이렉트 액세스 모드일 때 CLB는 2 레이어이므로 상태 확인 및 세션 지속성을 구성하기 어려움).
설명
클러스터가 Serverless인 경우 기본적으로 CLB-Pod 다이렉트 액세스 모드로 설정되며 아무 작업도 수행할 필요가 없습니다.
현재 CLB-to-Pod 다이렉트 액세스 모드는 GlobalRouter 및 VPC-CNI 컨테이너 네트워크 모드 모두에서 사용할 수 있습니다. 클러스터 목록에서 클러스터 ID를 클릭하면 클러스터 세부 정보 페이지로 이동합니다. ‘기본 정보’ 페이지에서 현재 클러스터에서 사용하는 컨테이너 네트워크 애드온을 찾을 수 있습니다.

VPC-CNI 모드

사용 제한

클러스터의 Kubernetes 버전은 1.12 이상이어야 합니다.
클러스터 네트워크 모드에 대해 VPC-CNI ENI 모드를 활성화해야 합니다.
다이렉트 액세스 모드의 Service에서 사용하는 워크로드는 VPC-CNI ENI 모드를 채택해야 합니다.
기본적으로 최대 200개의 워크로드 복제본을 CLB 백엔드에 바인딩할 수 있습니다. 더 많은 복제본을 바인딩해야 하는 경우 티켓 제출하여 할당량을 늘립니다.
ENI에 바인딩된 CLB의 기능 제한을 충족해야 합니다. 자세한 내용은 ENI 바인딩을 참고하십시오.
CLB-to-Pod 다이렉트 액세스 모드의 워크로드가 업데이트되면 CLB의 상태 확인 상태에 따라 롤링 업데이트가 수행되어 업데이트 속도에 영향을 미칩니다.
HostNetwork 유형 워크로드는 지원되지 않습니다.

작업 단계

콘솔
YAML
1. TKE 콘솔에 로그인합니다.
2. 콘솔에서 Service 생성 단계를 참고하여 Service 생성 페이지로 이동하고 필요에 따라 Service 매개변수를 설정합니다. 일부 주요 매개변수는 다음과 같이 설정해야 합니다.


서비스 액세스 방식: 공중망 CLB 액세스 또는 사설망 CLB 액세스를 선택합니다.
네트워크 모드: CLB-Pod 다이렉트 액세스 활성화를 선택합니다.
Workload 바인딩: 참조 Workload를 선택합니다.
3. 서비스 생성을 클릭합니다.
CLB-to-Pod 다이렉트 액세스 모드의 Service에 대한 YAML 구성은 일반 Service의 경우와 동일합니다. 이 예시에서 annotation은 CLB-to-Pod 다이렉트 액세스 모드 활성화 여부를 나타냅니다.
kind: Service
apiVersion: v1
metadata:
  annotations:
    service.cloud.tencent.com/direct-access: "true" ##CLB-Pod 다이렉트 액세스 활성화
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376
  type: LoadBalancer

annotation 확장

CLB 구성에 대해서는 TkeServiceConfig를 참고하십시오. annotation 구성은 다음과 같습니다.
service.cloud.tencent.com/tke-service-config: [tke-service-configName]

주의 사항

롤링 업데이트 중 가용성 보장

공식 Kubernetes에서 제공하는 ReadinessGate는 주로 Pod의 상태를 제어하는 데 사용되며 클러스터 버전이 1.12 이상이어야 합니다. 기본적으로 Pod에는 PodScheduled, Initialized, ContainersReady의 Condition이 있습니다. 이러한 상태가 모두 Ready되면 Pod Ready가 Condition을 통과합니다. 그러나 클라우드 네이티브 시나리오에서는 Pod의 상태를 다른 요소와 결합하여 판단해야 합니다. ReadinessGate는 타사에서 판단하고 제어하는 Pod의 상태 판단을 위한 펜스를 추가할 수 있는 메커니즘을 제공합니다. 이러한 방식으로 Pod의 상태는 타사와 연결됩니다.

CLB-to-Pod 다이렉트 액세스 모드의 롤링 업데이트 변경 사항

사용자가 애플리케이션의 롤링 업데이트를 시작하면 Kubernetes는 업데이트 정책에 따라 롤링 업데이트를 수행합니다. 그러나 Pod 배치가 시작 여부를 판단하는 데 사용하는 식별에는 Pod 자체의 상태만 포함되며 Pod가 CLB에서 상태 확인으로 구성되고 통과 여부는 고려하지 않습니다. 액세스 레이어 컴포넌트의 부하가 높을 때 이러한 Pod를 제 시간에 스케쥴링할 수 없는 경우 성공적인 롤링 업데이트가 있는 Pod가 외부 사용자에게 서비스를 제공하지 않아 서비스가 중단될 수 있습니다. CLB의 백엔드 상태와 롤링 업데이트를 연결하기 위해 TKE 액세스 레이어 컴포넌트는 Kubernetes 1.12에서 도입된 새로운 기능인 ReadinessGate를 도입했습니다. TKE 액세스 레이어 컴포넌트가 백엔드 바인딩이 성공하고 상태 확인이 통과되었음을 확인하는 경우에만 ReadinessGate 상태를 구성하여 Pod가 Ready 상태에 도달하고 전체 워크로드의 롤링 업데이트를 용이하게 할 수 있습니다.

클러스터에서 ReadinessGate 사용

Kubernetes 클러스터는 서비스 등록 메커니즘을 제공합니다. MutatingWebhookConfigurations 리소스 형식으로 클러스터에 서비스를 등록하기만 하면 됩니다. Pod가 생성되면 클러스터는 구성된 콜백 경로에 따라 알림을 전달합니다. 이때 Pod에 대해 사전 생성 작업을 수행할 수 있습니다. 즉, Pod에 ReadinessGate를 추가할 수 있습니다. 이 콜백 프로세스는 HTTPS를 기반으로 해야 합니다. 즉, 요청을 발행하는 CA는 MutatingWebhookConfigurations에 구성되어야 하며, CA에서 발행하는 인증서는 서버에 구성되어야 합니다.

ReadinessGate 메커니즘의 재해 복구

사용자 클러스터의 서비스 등록 또는 인증서는 사용자가 삭제할 수 있지만 이러한 시스템 컴포넌트 리소스는 사용자가 수정하거나 폐기해서는 안 됩니다. 그러나 이러한 문제는 사용자의 클러스터 탐색이나 오작동으로 인해 필연적으로 발생합니다. 따라서 상기 리소스에 대한 무결성은 액세스 레이어 컴포넌트 시작 시 확인하고, 무결성이 훼손된 경우 리소스를 재구축하여 시스템의 견고성을 강화합니다. 자세한 내용은 Kubernetes Pods ReadinessGate 특징을 참고하십시오.

GlobalRouter 컨테이너 네트워크 모드

사용 제한

워크로드는 하나의 네트워크 모드에서만 실행할 수 있습니다. 다이렉트 액세스 모드에서 서비스가 사용하는 워크로드의 VPC-CNI ENI 모드 또는 GlobalRoute 모드를 선택할 수 있습니다.
IP별 과금 계정만 지원됩니다.
기본적으로 최대 200 개의 워크로드 복제품을 CLB 백엔드에 바인딩 할 수 있습니다. 더 많은 복제본을 바인딩하려면 티켓 제출하여 할당량을 늘리십시오.
CLB-to-Pod 다이렉트 액세스 모드를 사용하면 네트워크 연결은 CVM의 보안 그룹에 의해 제한됩니다. 보안 그룹 구성이 해당 프로토콜과 포트를 열어 있는지 확인하십시오. CVM의 워크로드에 해당하는 포트를 열어야 합니다.
CLB-to-Pod 다이렉트 액세스 모드가 활성화되면 기본적으로 ReadinessGate(준비 점검)가 활성화됩니다. Pod 롤 업데이트 중에 로드 밸런서의 트래픽이 정상인지 확인합니다. 또한 애플리케이션에 대한 올바른 상태 확인 구성을 구성해야합니다. 자세한 내용은 TkeServiceConfig를 참고하십시오.
Globalrouter 모드에서 CLB-to-Pod 다이렉트 액세스는 베타 테스트입니다. 다음 두 가지 방법을 통해 사용할 수 있습니다.
CCN을 통해 사용할 수 있습니다(권장). CCN은 바인딩 오류 및 주소 루프백과 같은 일반적인 IP 바인딩 문제를 방지하기 위해 바인딩 IP 주소를 확인할 수 있습니다. 작업 단계는 다음과 같습니다.
a. CCN 인스턴스를 생성합니다. CCN 인스턴스 생성을 참고하십시오.
b. 클러스터가 생성 된 CCN 인스턴스에있는 VPC를 추가합니다.
c. 관련 클러스터의 컨테이너 네트워크 CIDR 블록을 CCN에 등록합니다. 클러스터의 기본 정보 페이지에서 CCN을 활성화합니다. CLB-to-Pod 다이렉트 액세스는 티켓 제출을 통해 신청할 수 있습니다. 하지만 CCN에서 제공되는 IP 확인 기능이 제공되지 않으므로 권장하지 않습니다.

YAML

CLB-to-Pod 다이렉트 액세스 모드의 Service에 대한 YAML 구성은 일반 Service와 동일합니다. 이 예에서, annotation은 CLB-to-Pod 다이렉트 액세스 모드 활성화 여부를 나타냅니다.

전제 조건

kube-system/tke-service-controller-config ConfigMap에 GlobalRouteDirectAccess: "true"를 추가하여 GlobalRoute의 다이렉트 액세스 기능을 활성화하십시오.

Service의 YAML에서 다이렉트 액세스 모드 활성화

kind: Service
apiVersion: v1
metadata:
  annotations:
    service.cloud.tencent.com/direct-access: "true" ##CLB-to-Pod 다이렉트 액세스 활성화
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376
  type: LoadBalancer

annotation 확장

CLB 구성은 TkeServiceConfig를 참고하십시오. annotation 구성은 다음과 같습니다.
service.cloud.tencent.com/tke-service-config: [tke-service-configName]

다음 주제: TKE Serverless 클러스터 업데이트(2023년)

도움말 및 지원

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

피드백