Seesaw를 사용한 번들 부하 분산

Anthos clusters on VMware(GKE on-prem)는 통합, 수동, 번들의 세 가지 부하 분산 모드 중 하나로 실행될 수 있습니다. 이 주제에서는 번들 부하 분산 모드에서 실행되도록 Anthos clusters on VMware를 구성하는 방법을 보여줍니다.

여기에는 전체 안내가 나와 있습니다. Seesaw 부하 분산기 사용에 대한 간략한 소개는 Seesaw 부하 분산기(빠른 시작)를 참조하세요.

번들 부하 분산 모드에서 Anthos clusters on VMware는 부하 분산기를 제공하고 관리합니다. 부하 분산기의 라이선스를 가져올 필요가 없으며 설정해야 하는 양이 최소화됩니다.

Anthos clusters on VMware가 제공하는 번들 부하 분산기는 Seesaw 부하 분산기입니다.

번들 부하 분산 모드의 장점

번들 부하 분산 모드는 수동 부하 분산 모드와 비교하여 다음과 같은 이점을 제공합니다.

  • 단일 팀이 클러스터 생성 및 부하 분산기 구성을 모두 관리할 수 있습니다. 예를 들어 클러스터 관리 팀은 부하 분산기를 사전에 확보, 실행, 구성하기 위해 별도의 네트워킹 팀에 의존할 필요가 없습니다.

  • Anthos clusters on VMware는 부하 분산기에서 가상 IP 주소(VIP)를 자동으로 구성합니다. 클러스터 생성 시 Anthos clusters on VMware는 Kubernetes API 서버, 인그레스 서비스, 클러스터 부가기능에 대한 VIP로 부하 분산기를 구성합니다. 클라이언트가 LoadBalancer 유형의 서비스를 만들면 Anthos clusters on VMware는 부하 분산기에서 서비스 VIP를 자동으로 구성합니다.

  • 조직, 그룹, 관리자 간의 종속 항목이 줄어듭니다. 특히 클러스터를 관리하는 그룹은 네트워크를 관리하는 그룹에 덜 의존합니다.

번들 부하 분산 모드에서는 vSphere 6.7 및 가상 분산 스위치(VDS) 6.6을 사용하는 것이 좋습니다.

원하는 경우 이전 버전을 사용할 수 있지만 설치 보안 수준이 저하됩니다. 이 주제의 남은 섹션에서는 vSphere 6.7 및 VDS 6.6을 사용할 때의 보안 이점에 대해 더 자세히 설명합니다.

VLAN 계획

Anthos clusters on VMware 설치에는 관리자 클러스터와 하나 이상의 사용자 클러스터가 있습니다. 번들 부하 분산 모드에서는 클러스터를 별도의 VLAN에 두고 특히 관리자 클러스터는 자체 VLAN에 있는 것이 좋습니다.

관리자 클러스터가 자체 VLAN에 있는 경우 제어 영역 트래픽은 데이터 영역 트래픽과 분리됩니다. 이렇게 분리된 덕분에 관리자 클러스터와 사용자 클러스터 제어 영역이 의도치 않은 구성 실수로부터 보호됩니다. 예를 들어 이러한 실수로 인해 동일한 VLAN의 Layer 2 루프에 의한 브로드캐스트 스톰이나, 데이터 영역과 제어 영역의 원하는 분리를 제거하는 충돌 IP 주소와 같은 문제로 이어질 수 있습니다.

번들 부하 분산을 위한 VM 리소스 프로비저닝(Seesaw)

번들 부하 분산을 사용하면 발생이 예상되는 네트워크 트래픽에 따라 VM CPU 및 메모리 리소스를 프로비저닝합니다.

번들 부하 분산기는 메모리를 많이 사용하지 않으며 1GB의 메모리를 사용하는 VM에서 실행할 수 있습니다. 하지만 네트워크 패킷 속도가 증가하는 경우 더 많은 CPU가 필요합니다.

다음 표에서는 VM 프로비저닝에 대한 스토리지, CPU 및 메모리 가이드라인을 보여줍니다. 패킷 속도는 네트워크 성능의 일반적인 측정값이 아니므로 이 표에는 최대 활성 네트워크 연결 수에 대한 가이드라인도 표시됩니다. 이 가이드라인에서는 VM에 10Gbps 링크가 있고 CPU가 70% 미만 용량에서 실행되는 환경이라고 가정합니다.

번들 부하 분산기가 고가용성(HA) 모드로 실행되면 활성 및 백업 쌍이 실행되므로 모든 트래픽이 단일 VM을 통해 전달됩니다.

실제 사용 사례는 다양하므로 실제 트래픽에 따라 이 가이드라인을 수정해야 합니다. CPU 및 패킷 속도 측정항목을 모니터링하여 필요한 사항을 변경합니다.

Seesaw VM의 CPU 및 메모리를 변경해야 할 경우에는 부하 분산기 업그레이드 안내를 따라야 합니다. 번들 부하 분산기의 동일한 버전을 유지할 수 있으며 CPU 수와 메모리 할당만 변경할 수 있습니다.

소규모 관리자 클러스터의 경우 CPU 2개, 대규모 관리자 클러스터의 경우 CPU 4개를 사용하는 것이 좋습니다.

스토리지 CPU 메모리 패킷 속도(pps) 최대 활성 연결 수
20GB 1(비프로덕션 환경) 1GB 250k 100
20GB 2 3GB 450k 300
20GB 4 3GB 850k 6,000
20GB 6 3GB 1,000k 10,000

비프로덕션 환경에서는 단일 CPU만 프로비저닝해야 합니다.

가상 IP 주소 따로 설정

부하 분산 모드를 선택하든 관계없이 부하 분산에 사용할 가상 IP 주소(VIP)를 별도로 설정해야 합니다. 이러한 VIP를 사용하면 외부 클라이언트가 Kubernetes API 서버, 인그레스 서비스, 부가기능 서비스에 연결할 수 있습니다.

관리자 클러스터의 VIP 집합과 만들려는 각 사용자 클러스터의 VIP 집합을 별도로 설정해야 합니다. 특정 클러스터의 경우 이러한 VIP는 클러스터 노드 및 해당 클러스터의 Seesaw VM과 동일한 VLAN에 있어야 합니다.

VIP를 따로 설정하는 방법 안내는 가상 IP 주소 따로 설정을 참조하세요.

노드 IP 주소 따로 설정

번들 부하 분산 모드에서는 클러스터 노드에 고정 IP 주소를 지정하거나 클러스터 노드가 DHCP 서버에서 IP 주소를 가져올 수 있습니다.

클러스터 노드에 고정 IP 주소가 포함되도록 하려면 관리자 클러스터의 노드와 만들려는 모든 사용자 클러스터의 노드에 충분한 주소를 따로 설정하세요. 따로 설정할 노드 IP 주소 수에 대한 자세한 내용은 고정 IP 주소 구성을 참조하세요.

Seesaw VM의 IP 주소 별도로 설정

그런 다음 Seesaw 부하 분산기를 실행할 VM에 대해 IP 주소를 따로 설정합니다.

따로 설정하는 주소 개수는 고가용성(HA) Seesaw 부하 분산기를 만들지, 비HA Seesaw 부하 분산기를 만들지에 따라 다릅니다.

사례 1: HA Seesaw 부하 분산기

관리자 클러스터의 경우, Seesaw VM 쌍에 대해 2개의 IP 주소를 따로 설정합니다. 또한 관리 클러스터의 경우 Seesaw VM 쌍에 대해 단일 기본 IP를 따로 설정합니다. 이 3개 주소는 모두 클러스터 노드와 동일한 VLAN에 있어야 합니다.

만들려는 각 사용자 클러스터의 경우 Seesaw VM 쌍에 대해 2개의 IP 주소를 따로 설정합니다. 또한 각 사용자 클러스터의 경우 Seesaw VM 쌍에 대해 단일 기본 IP를 따로 설정합니다. 특정 사용자 클러스터의 경우 이 3개 주소는 모두 사용자 클러스터 노드와 동일한 VLAN에 있어야 합니다.

사례 2: 비HA Seesaw 부하 분산기

관리자 클러스터의 경우 Seesaw VM에 하나의 IP 주소를 따로 설정합니다. 또한 관리자 클러스터의 경우 Seesaw 부하 분산기의 기본 IP를 따로 설정합니다. 두 주소는 모두 관리자 클러스터 노드와 동일한 VLAN에 있어야 합니다.

만들려는 각 사용자 클러스터의 경우 Seesaw VM에 대해 하나의 IP 주소를 따로 설정합니다. 또한 각 사용자 클러스터의 경우 Seesaw 부하 분산기의 기본 IP를 따로 설정합니다. 두 주소는 모두 사용자 클러스터 노드와 동일한 VLAN에 있어야 합니다.

포트 그룹 계획

각 Seesaw VM에는 두 가지 네트워크 인터페이스가 포함됩니다. 이러한 네트워크 인터페이스 중 하나는 서비스 VIP로 구성됩니다. 다른 네트워크 인터페이스는 VM 자체의 IP 주소로 구성됩니다.

개별 Seesaw VM의 경우 2개의 네트워크 인터페이스를 동일한 vSphere 포트 그룹에 연결하거나 별도의 포트 그룹에 연결할 수 있습니다. 포트 그룹이 별개인 경우 동일한 VLAN에 있어야 합니다.

이 주제는 다음 2개의 포트 그룹을 참조합니다.

  • 부하 분산기 포트 그룹: Seesaw VM의 경우 서비스 VIP로 구성된 네트워크 인터페이스가 이 포트 그룹에 연결됩니다.

  • 클러스터 노드 포트 그룹: Seesaw VM의 경우 VM 자체의 IP 주소로 구성된 네트워크 인터페이스가 이 포트 그룹에 연결됩니다. Anthos clusters on VMware 클러스터 노드도 이 포트 그룹에도 연결됩니다.

부하 분산기 포트 그룹과 클러스터 노드 포트 그룹은 하나이면서 동일할 수 있습니다. 단, 이 두 그룹은 서로 구분하는 것이 좋습니다.

IP 블록 파일 만들기

만들려는 각 클러스터의 경우 IP 블록 파일에서 Seesaw VM에 대해 선택한 주소를 지정합니다. 이 IP 블록 파일은 클러스터 노드가 아닌 부하 분산기 VM용입니다. 클러스터 노드에 고정 IP 주소를 사용하려면 해당 주소에 대해 별도의 IP 블록 파일을 만들어야 합니다. 다음은 Seesaw VM에 두 개의 IP 주소를 지정하는 IP 블록 파일의 예시입니다.

blocks:
  - netmask: "255.255.255.0"
    gateway: "172.16.20.1"
    ips:
    - ip: "172.16.20.18"
      hostname: "seesaw-vm"

구성 파일 작성

각 클러스터의 구성 파일(admin clusteruser cluster)을 준비합니다.

각 클러스터의 구성 파일에서 loadBalancer.kind"Seesaw"로 설정합니다.

구성 파일의 각 클러스터에 대해 loadBalancer 섹션에서 seesaw 섹션을 채웁니다.

loadBalancer:
  kind: Seesaw
  seesaw:
    ipBlockFilePath::
    vrid:
    masterIP:
    cpus:
    memoryMB:
    vCenter:
      networkName:
    enableha:
    antiAffinityGroups:
      enabled:

seesaw.ipBlockFilePath

문자열. Seesaw VM의 IP 블록 파일 경로로 설정합니다. 예를 들면 다음과 같습니다.

loadBalancer:
  seesaw:
    ipBlockFilePath: "admin-seesaw-ipblock.yaml"

seesaw.vrid

정수. Seesaw VM의 가상 라우터 식별자입니다. 이 ID는 VLAN 내에서 고유해야 합니다. 유효한 범위는 1~255입니다. 예를 들면 다음과 같습니다.

loadBalancer:
  seesaw:
    vrid: 125

seesaw.masterIP

문자열. Seesaw의 기본 IP입니다. 예를 들면 다음과 같습니다.

loadBalancer:
  seesaw:
    masterIP: 172.16.20.21

seesaw.cpus

정수. Seesaw VM의 CPU 수입니다. 예를 들면 다음과 같습니다.

loadBalancer:
  seesaw:
    cpus: 4

seesaw.memoryMB

정수. Seesaw VM의 메모리 용량(MB)입니다. 예를 들면 다음과 같습니다.

loadBalancer:
  seesaw:
    memoryMB: 3072

seesaw.vCenter.networkName

문자열. Seesaw VM이 포함된 네트워크의 이름입니다. 설정되지 않은 경우 클러스터와 동일한 네트워크를 사용합니다. 예를 들면 다음과 같습니다.

loadBalancer:
  seesaw:
    vCenter:
      networkName: "my-seesaw-network"

seesaw.enableHA

부울. 고가용성 Seesaw 부하 분산기를 만들려면 true로 설정합니다. 그렇지 않으면 false로 설정합니다. 예를 들면 다음과 같습니다.

loadBalancer:
  seesaw:
    enableHA: true

enablehatrue로 설정하는 경우 MAC 학습을 사용 설정해야 합니다.

seesaw.antiAffinityGroups.enabled

Seesaw VM에 안티어피니티 규칙을 적용하려면 seesaw.antiAffinityGroups.enabled 값을 true로 설정합니다. 그렇지 않은 경우 값을 false로 설정합니다. 기본값은 true입니다. 권장되는 값은 true이므로 가능한 경우 Seesaw VM이 서로 다른 물리적 호스트에 배치됩니다. 예를 들면 다음과 같습니다.

loadBalancer:
  seesaw
    antiAffinityGroups:
      enabled: true

MAC 학습 또는 무차별 모드 사용 설정(HA만 해당)

HA Seesaw 부하 분산기를 설정하는 경우 이 섹션을 건너뛸 수 있습니다.

HA Seesaw 부하 분산기를 설정하는 경우 부하 분산기 포트 그룹에서 MAC 학습, 위조 전송, 무차별 모드의 조합을 사용 설정해야 합니다.

이 기능을 사용 설정하는 방법은 사용 중인 스위치 유형에 따라 다릅니다.

전환 유형기능 사용 설정보안에 미치는 영향
vSphere 6.7(VDS 6.6 포함)

gkectl prepare network --config [CONFIG_FILE] 명령어를 실행하여 부하 분산기에 MAC 학습 및 위조 전송을 사용 설정합니다. 여기서 [CONFIG_FILE]은 Anthos clusters on VMware 구성 파일의 경로입니다. 이를 수행하려면 dvPort group.Modify 권한이 필요합니다.

최소. 부하 분산기 포트 그룹이 Seesaw VM에만 연결된 경우 MAC 학습을 신뢰할 수 있는 Seesaw VM으로 제한할 수 있습니다.

vSphere 6.5 또는

vSphere 6.7(VDS 버전 6.6 미만 포함)

부하 분산기 포트 그룹에 대해 무차별 모드와 위조 전송을 사용 설정합니다. 네트워킹 탭의 포트 그룹 페이지에 있는 vSphere 사용자 인터페이스를 사용합니다. 설정 수정 -> 보안을 클릭합니다. 부하 분산기 포트 그룹의 모든 VM은 무차별 모드입니다. 따라서 부하 분산기 포트 그룹의 모든 VM에서는 모든 트래픽을 볼 수 있습니다. 부하 분산기 포트 그룹이 Seesaw VM에만 연결된 경우 모든 트래픽을 볼 수 있는 VM으로 제한됩니다.
NSX-T 논리 스위치 논리 스위치에서 MAC 학습을 사용 설정합니다. vSphere는 동일한 layer-2 도메인에서 두 개의 논리 스위치 만들기를 지원하지 않습니다. 따라서 Seesaw VM과 클러스터 노드는 동일한 논리적 스위치에 있어야 합니다. 즉, 모든 클러스터 노드에 MAC 학습이 사용 설정됩니다. 공격자가 클러스터에서 권한이 있는 pod를 실행하여 MAC 스푸핑을 할 수도 있습니다.
vSphere 표준 스위치 부하 분산기 포트 그룹에 대해 무차별 모드와 위조 전송을 사용 설정합니다. 각 ESXI 호스트에 있는 vSphere 사용자 인터페이스를 사용합니다. 구성 -> 가상 스위치 -> 표준 스위치 -> 포트 그룹의 설정 수정 -> 보안을 클릭합니다. 부하 분산기 포트 그룹의 모든 VM은 무차별 모드입니다. 따라서 부하 분산기 포트 그룹의 모든 VM에서는 모든 트래픽을 볼 수 있습니다. 부하 분산기 포트 그룹이 Seesaw VM에만 연결된 경우 모든 트래픽을 볼 수 있는 VM으로 제한됩니다.

구성 파일에서 실행 전 검사 실행

IP 블록 파일과 관리자 클러스터 구성 파일을 만든 후 구성 파일에서 실행 전 검사를 실행합니다.

gkectl check-config --config [ADMIN_CONFIG_FILE]

여기서 [ADMIN_CONFIG_FILE]은 Anthos clusters on VMware 관리자 클러스터 구성 파일의 경로입니다.

사용자 클러스터 구성 파일의 경우 다음 명령어에 관리자 클러스터의 kubeconfig 파일을 포함해야 합니다.

gkectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] check-config --config [USER_CONFIG_FILE]

여기서 [ADMIN_CLUSTER_KUBECONFIG]는 관리자 클러스터의 kubeconfig 파일 경로입니다.

실행 전 검사가 실패하면 필요에 따라 Anthos clusters on VMware 구성 파일과 IP 블록 파일을 조정합니다. 그런 다음 실행 전 검사를 다시 실행합니다.

OS 이미지 업로드

다음 명령어를 실행하여 vSphere 환경에 OS 이미지를 업로드합니다.

gkectl prepare --config [ADMIN_CONFIG_FILE]

여기서 [ADMIN_CONFIG_FILE]은 Anthos clusters on VMware 관리자 클러스터 구성 파일의 경로입니다.

번들 부하 분산 모드를 사용하는 관리자 클러스터 만들기

관리자 클러스터의 부하 분산기에 대해 VM을 만들고 구성합니다.

gkectl create loadbalancer --config [CONFIG_FILE]

여기서 [CONFIG_FILE]은 관리자 클러스터의 Anthos clusters on VMware 구성 파일의 경로입니다.

관리자 클러스터를 만듭니다.

gkectl create admin --config [CONFIG_FILE]

여기서 [CONFIG_FILE]은 Anthos clusters on VMware 관리자 클러스터 구성 파일의 경로입니다.

번들 부하 분산 모드를 사용하는 사용자 클러스터 만들기

사용자 클러스터의 부하 분산기에 대해 VM을 만들고 구성합니다.

gkectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] create loadbalancer --config [CONFIG_FILE]

사용자 클러스터 만들기

gkectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] create cluster --config [CONFIG_FILE]

여기서 [ADMIN_CLUSTER_KUBECONFIG]는 관리자 클러스터의 kubeconfig 파일 경로이며 [CONFIG_FILE]은 Anthos clusters on VMware 사용자 클러스터 구성 파일의 경로입니다.

성능 및 부하 테스트

애플리케이션의 다운로드 처리량은 백엔드 수에 따라 선형적으로 확장됩니다. 이는 백엔드가 직접 서버 반환을 사용하여 부하 분산기를 우회함으로써 클라이언트에 직접 응답을 보내기 때문입니다.

반면에 애플리케이션의 업로드 처리량은 부하 분산을 수행하는 하나의 Seesaw VM의 용량으로 제한됩니다.

애플리케이션은 CPU 및 메모리 필요량에 따라 달라지므로 많은 클라이언트를 제공하기 전에 부하 테스트를 수행하는 것이 중요합니다.

테스트 결과, 6개의 CPU와 3GB의 메모리를 사용하는 단일 Seesaw VM은 10K의 동시 TCP 연결로 10GB/초(회선 속도)의 트래픽을 업로드할 수 있는 것으로 나타났습니다. 그러나 많은 수의 동시 TCP 연결을 지원하려면 자체 부하 테스트를 실행해야 합니다.

확장 한도

번들 부하 분산에는 클러스터가 확장될 수 있는 크기에 대한 한도가 있습니다. 클러스터의 노드 수에 한도가 있고 부하 분산기에 구성할 수 있는 서비스 수에 한도가 있습니다. 상태 확인에도 한도가 있습니다. 상태 확인 수는 노드 수 및 서비스 수에 따라 다릅니다.

버전 1.3.1부터 상태 확인 수는 노드 수와 트래픽 로컬 서비스 수에 따라 다릅니다. 트래픽 로컬 서비스는 externalTrafficPolicy"Local"로 설정된 서비스입니다.

버전 1.3.0버전 1.3.1 이상
최대 서비스 수(S)100500
최대 노드 수(N)100100
최대 상태 확인S * N <= 10KN + L * N <= 10K, L은 트래픽 로컬 서비스 수

예: 버전 1.3.1에서 노드 100개와 트래픽 로컬 서비스 99개가 있다고 가정해 보겠습니다. 그러면 상태 확인 수가 100 + 99 * 100 = 10,000개이며, 이는 10K 한도 이내입니다.

관리자 클러스터의 부하 분산기 업그레이드

v1.4부터는 클러스터를 업그레이드할 때 부하 분산기가 업그레이드됩니다. 부하 분산기를 개별적으로 업그레이드하기 위해 다른 명령어를 실행할 필요가 없습니다. 하지만 아래의 gkectl upgrade loadbalancer를 사용하여 일부 매개변수를 업데이트할 수 있습니다.

Seesaw VM의 CPU 및 메모리를 업데이트할 수 있습니다. 아래 예시와 같이 새 구성 파일을 만들고 Seesaw VM의 CPU와 메모리를 설정합니다. 변경하지 않으려면 그대로 둡니다. bundlePath가 설정되면 번들에 지정된 부하 분산기로 부하 분산기를 업그레이드합니다.

예를 들면 다음과 같습니다.

apiVersion: v1
kind: AdminCluster
bundlePath:
loadBalancer:
  kind: Seesaw
  seesaw:
    cpus: 3
    memoryMB: 3072

그런 다음 이 명령어를 실행하여 부하 분산기를 업그레이드합니다.

gkectl upgrade loadbalancer --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config [ADMIN_CLUSTER_CONFIG] --admin-cluster

각 항목의 의미는 다음과 같습니다.

  • [ADMIN_CLUSTER_KUBECONFIG]는 관리자 클러스터의 kubeconfig 파일입니다.

  • [ADMIN_CLUSTER_CONFIG]는 생성된 관리자 클러스터 구성 파일입니다.

부하 분산기 업그레이드 중에는 다운타임이 발생합니다. 부하 분산기에 HA가 사용 설정된 경우 최대 다운타임은 2초입니다.

사용자 클러스터의 부하 분산기 업그레이드

v1.4부터는 클러스터를 업그레이드할 때 부하 분산기가 업그레이드됩니다. 부하 분산기를 개별적으로 업그레이드하기 위해 다른 명령어를 실행할 필요가 없습니다. 하지만 아래의 gkectl upgrade loadbalancer를 사용하여 일부 매개변수를 업데이트할 수 있습니다.

Seesaw VM의 CPU 및 메모리를 업데이트할 수 있습니다. 아래 예시와 같이 새 구성 파일을 만들고 Seesaw VM의 CPU와 메모리를 설정합니다. 변경하지 않으려면 그대로 둡니다. gkeOnPremVersion이 설정되면 부하 분산기를 이 버전으로 지정된 항목으로 업그레이드합니다.

예를 들면 다음과 같습니다.

apiVersion: v1
kind: UserCluster
name: cluster-1
gkeOnPremVersion:
loadBalancer:
  kind: Seesaw
  seesaw:
    cpus: 4
    memoryMB: 3072

그런 다음 이 명령어를 실행하여 부하 분산기를 업그레이드합니다.

gkectl upgrade loadbalancer --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config [USER_CLUSTER_CONFIG]

각 항목의 의미는 다음과 같습니다.

  • [ADMIN_CLUSTER_KUBECONFIG]는 관리자 클러스터의 kubeconfig 파일입니다.

  • [USER_CLUSTER_CONFIG]는 생성된 사용자 구성 파일입니다.

Seesaw 로그 보기

Seesaw 번들 부하 분산기는 Seesaw VM의 로그 파일을 /var/log/seesaw/에 저장합니다. 가장 중요한 로그 파일은 seesaw_engine.INFO입니다.

v1.6부터 Stackdriver가 사용 설정되면 로그도 Cloud에 업로드됩니다. 'anthos_l4lb' 리소스에서 볼 수 있습니다. 로그 업로드를 사용 중지하려면 VM에 SSH로 연결하여 다음 명령어를 실행합니다.

sudo systemctl disable --now docker.fluent-bit.service

Seesaw VM에 대한 정보 보기

클러스터의 Seesaw VM에 대한 정보는 SeesawGroup 커스텀 리소스에서 가져올 수 있습니다.

클러스터에 대해 SeesawGroup 커스텀 리소스를 확인합니다.

kubectl --kubeconfig [CLUSTER_KUBECONFIG] get seesawgroups -n kube-system -o yaml

여기서 [CLUSTER_KUBECONFIG]는 클러스터의 kubeconfig 파일 경로입니다.

출력에는 VM에서 트래픽 처리가 준비되었는지 여부를 나타내는 isReady 필드가 포함됩니다. 또한 Seesaw VM의 이름 및 IP 주소와 기본 VM이 출력에 표시됩니다.

apiVersion: seesaw.gke.io/v1alpha1
kind: SeesawGroup
metadata:
  ...
  name: seesaw-for-cluster-1
  namespace: kube-system
  ...
spec: {}
status:
  machines:
  - hostname: cluster-1-seesaw-1
    ip: 172.16.20.18
    isReady: true
    lastCheckTime: "2020-02-25T00:47:37Z"
    role: Master
  - hostname: cluster-1-seesaw-2
    ip: 172.16.20.19
    isReady: true
    lastCheckTime: "2020-02-25T00:47:37Z"
    role: Backup

Seesaw 측정항목 보기

Seesaw 번들 부하 분산기는 다음 측정항목을 제공합니다.

  • 서비스 또는 노드당 처리량
  • 서비스 또는 노드당 패킷 속도
  • 서비스 또는 노드당 활성 연결
  • CPU 및 메모리 사용량
  • 서비스당 정상 백엔드 pod 수
  • 기본 VM 및 백업 VM
  • 업타임

v1.6부터 이러한 측정항목은 Stackdriver를 사용하여 Cloud에 업로드됩니다. 'anthos_l4lb'의 모니터링 리소스에서 확인할 수 있습니다.

Prometheus 형식을 지원하는 모든 모니터링 및 대시보드 솔루션을 사용할 수도 있습니다.

부하 분산기 삭제

번들 부하 분산을 사용하는 클러스터를 삭제하면 해당 클러스터의 Seesaw VM을 삭제해야 합니다. 이렇게 하려면 vSphere 사용자 인터페이스에서 Seesaw VM을 삭제합니다.

대안으로 1.4.2에서 시작하면 gkectl와 전달 구성 파일을 실행하여 번들 부하 분산기와 그 그룹 파일을 삭제할 수 있습니다.

관리자 클러스터의 경우 다음 명령어를 실행합니다.

gkectl delete loadbalancer --config [ADMIN_CONFIG_FILE] --seesaw-group-file [GROUP_FILE]

사용자 클러스터의 경우 다음 명령어를 실행합니다.

gkectl delete loadbalancer --config [CLUSTER_CONFIG_FILE] --seesaw-group-file [GROUP_FILE] --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]

각 항목의 의미는 다음과 같습니다.

  • [ADMIN_CONFIG_FILE]는 관리자 클러스터 구성 파일입니다.

  • [CLUSTER_CONFIG_FILE]은 사용자 클러스터 구성 파일입니다.

  • [ADMIN_CLUSTER_KUBECONFIG]는 관리자 클러스터 kubeconfig 파일입니다.

  • [GROUP_FILE]은 Seesaw 그룹 파일입니다. 그룹 파일 이름의 형식은 seesaw-for-[CLUSTER_NAME]-[IDENTIFIER].yaml입니다.

1.4.2 이전 버전

1.4.2 이전 버전에서는 대신 이 명령어를 실행하여 Seesaw VM과 Seesaw 그룹 파일을 삭제할 수 있습니다.

gkectl delete loadbalancer --config vsphere.yaml --seesaw-group-file [GROUP_FILE]

각 항목의 의미는 다음과 같습니다.

  • [GROUP_FILE]은 Seesaw 그룹 파일입니다. 그룹 파일은 config.yaml 옆의 관리 워크스테이션에 있습니다. 그룹 파일 이름의 형식은 seesaw-for-[CLUSTER_NAME]-[IDENTIFIER].yaml입니다.

  • vsphere.yaml은 vCenter 서버에 대한 다음 정보가 포함된 파일입니다.

vcenter:
  credentials:
    address:
    username:
    password:
  datacenter:
  cacertpath:

문제 해결

Seesaw VM에 SSH로 연결

경우에 따라 문제 해결 또는 디버깅을 위해 Seesaw VM에 SSH로 연결해야 할 수 있습니다.

SSH 키 가져오기

클러스터를 이미 만든 경우 다음 단계에 따라 SSH 키를 가져옵니다.

  1. 클러스터에서 seesaw-ssh 보안 비밀을 가져옵니다. 보안 비밀에서 SSH 키를 가져와 base64로 디코딩합니다. 디코딩된 키를 임시 파일에 저장합니다.

    kubectl --kubeconfig [CLUSTER_KUBECONFIG] get -n  kube-system secret seesaw-ssh -o \
    jsonpath='{@.data.seesaw_ssh}' | base64 -d | base64 -d > /tmp/seesaw-ssh-key

    여기서 [CLUSTER_KUBECONFIG]는 클러스터의 kubeconfig 파일입니다.

  2. 키 파일에 대한 적절한 권한을 설정합니다.

    chmod 0600 /tmp/seesaw-ssh-key

클러스터를 아직 만들지 않았으면 다음 단계에 따라 SSH 키를 가져옵니다.

  1. 이름이 seesaw-for-[CLUSTER_NAME]-[IDENTIFIER].yaml인 파일을 찾습니다.

    이 파일은 그룹 파일이라고 하며 config.yaml 옆에 있습니다.

    또한 gkectl create loadbalancer는 그룹 파일의 위치를 출력합니다.

  2. 파일에서 credentials.ssh.privateKey 값을 가져와 base64로 디코딩합니다. 디코딩된 키를 임시 파일에 저장합니다.

    cat seesaw-for-[CLUSTER_NAME]-[IDENTIFIER].yaml  | grep privatekey | sed 's/    privatekey: //g' \
    | base64 -d > /tmp/seesaw-ssh-key
    
  3. 키 파일에 대한 적절한 권한을 설정합니다.

    chmod 0600 /tmp/seesaw-ssh-key

이제 Seesaw VM에 SSH로 연결할 수 있습니다.

ssh -i /tmp/seesaw-ssh-key ubuntu@[SEESAW_IP]

여기서 [SEESAW_IP]는 Seesaw VM의 IP 주소입니다.

스냅샷 가져오기

--scenario 플래그와 함께 gkectl diagnose snapshot 명령어를 사용하여 Seesaw VM의 스냅샷을 캡처할 수 있습니다.

--scenarioall 또는 all-with-logs로 설정하면 Seesaw 스냅샷이 다른 스냅샷과 함께 결과에 포함됩니다.

--scenarioseesaw로 설정하면 결과에 Seesaw 스냅샷만 포함됩니다.

예:

gkectl diagnose snapshot --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --scenario seesaw

여기서 [ADMIN_CLUSTER_KUBECONFIG]는 관리자 클러스터의 kubeconfig 파일입니다.

gkectl diagnose snapshot --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --cluster-name [CLUSTER_NAME] --scenario seesaw
gkectl diagnose snapshot --seesaw-group-file [GROUP_FILE] --scenario seesaw

여기서 [GROUP_FILE]은 클러스터의 그룹 파일 경로입니다. 예를 들면 seesaw-for-gke-admin-xxxxxx.yaml입니다.

알려진 문제

v1.3.x의 부하 분산기를 업그레이드할 수 없음

여기서 Seesaw 부하 분산기에서 antiaffinitygroups가 사용 중지되면 v1.3.x에서 v1.3.x+로 부하 분산기를 업그레이드할 때 오류가 발생하며 실패합니다.

업데이트된 Seesaw 그룹이 유효하지 않음: Seesaw 구성이 잘못되었습니다. 사용자가 제공하지 않은 경우에는 AntiAffinityGroups를 기본값으로 설정해야 합니다.

v1.4에서 수정되었으므로 v1.3.x+를 건너뛰고 v1.4로 업그레이드할 수 있습니다.