다른 Kubernetes 클러스터와 마찬가지로 Google Distributed Cloud 클러스터 확장성에는 여러 가지 상호 관련된 측정기준이 포함됩니다. 이 문서는 워크로드를 중단하지 않고 클러스터를 확장하기 위해 조정할 수 있는 주요 측정기준을 이해하는 데 도움이 됩니다.
한도 이해
Google Distributed Cloud는 대규모 통합 영역이 있는 복잡한 시스템입니다. 클러스터 확장성에 영향을 미치는 측정기준에는 여러가지가 있습니다. 예를 들어 노드 수는 Google Distributed Cloud가 확장될 수 있는 여러 측정기준 중 하나일 뿐입니다. 다른 측정기준에는 포드 및 서비스의 총 개수가 있습니다. 노드당 포드 수, 클러스터당 노드 수와 같은 이러한 여러 측정기준은 상호 관련이 있습니다. 확장성에 영향을 미치는 측정기준에 대한 자세한 내용은 GitHub의 Kubernetes 커뮤니티 저장소의 확장성 Special Interest Group(SIG) 섹션에서 Kubernetes 확장성 임곗값을 참조하세요.
확장성 한도는 또한 클러스터가 실행되는 하드웨어 및 노드 구성의 영향을 받습니다. 이 문서에서 설명하는 한도는 사용자 환경과 다를 수 있는 환경에서 확인됩니다. 따라서 기본 환경이 제한 요인인 경우 동일한 수치가 재현되지 않을 수 있습니다.
Google Distributed Cloud 클러스터에 적용되는 한도에 대한 자세한 내용은 할당량 및 한도를 참조하세요.
확장 준비
Google Distributed Cloud 클러스터 확장을 준비할 때는 다음 섹션에 설명된 요구사항과 제한사항을 고려하세요.
컨트롤 플레인 노드 CPU 및 메모리 요구사항
다음 표에서는 프로덕션 워크로드를 실행 중인 클러스터의 컨트롤 플레인 노드에 권장되는 CPU 및 메모리 구성을 보여줍니다.
| 클러스터 노드 수 | 권장 컨트롤 플레인 CPU | 권장 컨트롤 플레인 메모리 |
|---|---|---|
| 1-50 | 코어 8개 | 32GiB |
| 51~100명 | 코어 16개 | 64GiB |
포드 및 서비스 수
클러스터에 포함 가능한 포드 및 서비스 수는 다음 설정에 따라 제어됩니다.
clusterNetwork.pods.cidrBlocks는 클러스터에 허용되는 포드 수를 지정합니다.nodeConfig.podDensity.maxPodsPerNode는 단일 노드에서 실행할 수 있는 최대 포드 수를 지정합니다.clusterNetwork.services.cidrBlocks는 클러스터에 허용되는 서비스 수를 지정합니다.
포드 CIDR 및 최대 노드 수
클러스터의 포드에 예약된 총 IP 주소 수는 클러스터 확장을 제한하는 요소 중 하나입니다. 이 설정은 노드별 최대 포드 수 설정과 함께 포드의 IP 주소가 소진될 위험이 발생하기 전 클러스터에 포함할 수 있는 최대 노드 수를 결정합니다.
다음 사항을 고려하세요.
클러스터의 포드에 예약된 총 IP 주소 수는
clusterNetwork.pods.cidrBlocks로 지정되며 CIDR 표기법으로 지정된 IP 주소 범위를 사용합니다. 예를 들어 미리 채워진 값192.168.0.0/16은192.168.0.0에서192.168.255.255까지 IP 주소 범위를 65,536개 지정합니다.단일 노드에서 실행될 수 있는 최대 포드 수는
nodeConfig.podDensity.maxPodsPerNode로 지정됩니다.노드당 최대 포드 수 설정에 따라 Google Distributed Cloud는 노드에 약 두 배의 IP 주소를 프로비저닝합니다. 추가 IP 주소는 짧은 시간 동안 포드 IP를 실수로 재사용하는 것을 방지하는 데 도움이 됩니다.
총 포드 IP 주소 수를 각 노드에 프로비저닝된 포드 IP 주소 수로 나누면 클러스터에 포함할 수 있는 총 노드 수를 얻을 수 있습니다.
예를 들어 포드 CIDR이 192.168.0.0/17인 경우 총 IP 주소는 32,768개입니다(2(32-17) = 215 = 32,768). 노드당 최대 포드 수를 250개로 설정하면 Google Distributed Cloud는 약 500개의 IP 주소 범위를 프로비저닝하며, 이는 약 /23 CIDR 블록(2(32-23) = 29 = 512)과 동일합니다
따라서 이 경우 최대 노드 수는 64개입니다(주소/클러스터 215개를 주소/노드 29개로 나눈 값 = 2(15-9) 노드/클러스터 = 26 = 64개 노드/클러스터).
clusterNetwork.pods.cidrBlocks 및 nodeConfig.podDensity.maxPodsPerNode는 변경할 수 없습니다. 따라서 노드 용량 부족 문제를 방지하기 위해 앞으로 클러스터 성장에 맞게 신중하게 계획하세요. 테스트에 기반한 클러스터당 포드 수, 노드당 포드 수, 클러스터당 노드 수에 권장되는 최댓값은 한도를 참조하세요.
서비스 CIDR
클러스터 확장 시 서비스를 더 추가하도록 서비스 CIDR을 업데이트할 수 있습니다. 하지만 서비스 CIDR 범위는 줄일 수 없습니다. 자세한 내용은 서비스 네트워크 범위 늘리기를 참조하세요.
시스템 데몬용으로 예약된 리소스
기본적으로 Google Distributed Cloud는 sshd 또는 udev와 같이 시스템 데몬용으로 노드에서 리소스를 자동으로 예약합니다. CPU 및 메모리 리소스는 이러한 데몬에 필요한 리소스가 포함되도록 시스템 데몬용으로 노드에 예약됩니다. 이 기능을 사용하지 않으면 포드가 노드에서 잠재적으로 대부분의 리소스를 소비하여 시스템 데몬이 태스크를 완료하지 못할 수 있습니다.
특히 Google Distributed Cloud는 시스템 데몬용으로 각 노드에서 80밀리코어 CPU(80mCPU) 및 280메비바이트(280MiB) 메모리를 예약합니다. CPU 단위인 mCPU는 코어의 1/1000을 의미합니다. 따라서 각 노드에서 80/1000 또는 코어 8%가 시스템 데몬용으로 예약됩니다. 예약된 리소스 양은 적으며 포드 성능에 큰 영향을 주지 않습니다. 그러나 해당 CPU 또는 메모리 사용이 할당된 양을 초과하면 노드에서 kubelet이 포드를 제거할 수 있습니다.
MetalLB를 사용한 네트워킹
다음 문제를 해결하기 위해서는 MetalLB 스피커 수를 늘려야 할 수 있습니다.
대역폭: 서비스 부하 분산을 위한 전체 클러스터 대역폭은 스피커 수 및 각 스피커 노드의 대역폭에 따라 달라집니다. 네트워크 트래픽이 증가하면 더 많은 스피커가 필요합니다.
내결함성: 스피커가 증가하면 단일 스피커 오류로 인한 전반적인 영향이 감소합니다.
MetalLB에는 부하 분산 노드 사이에 레이어 2 연결이 필요합니다. 여기에서는 MetalLB 스피커를 배치할 수 있는 레이어 2 연결을 지원하는 노드 수로 제한될 수 있습니다.
클러스터에 포함하려는 MetalLB 스피커 수를 신중하게 계획하고 필요한 레이어 2 노드 수를 결정하세요. 자세한 내용은 MetalLB 확장성 문제를 참조하세요.
또한 번들 부하 분산 모드를 사용할 때는 컨트롤 플레인 노드도 동일한 레이어 2 네트워크에 있어야 합니다. 수동 부하 분산에는 이러한 제한이 없습니다. 자세한 내용은 수동 부하 분산기 모드를 참조하세요.
여러 노드, 포드, 서비스 실행
노드, 포드, 서비스 추가는 클러스터를 확장하는 한 가지 방법입니다. 다음 섹션에서는 클러스터에서 노드, 포드, 서비스 수를 늘릴 때 고려해야 하는 몇 가지 추가적인 설정 및 구성에 대해 설명합니다. 이러한 측정기준의 한도와 상호 연관성에 대한 자세한 내용은 한도를 참조하세요.
kube-proxy 없이 클러스터 만들기
많은 수의 서비스 및 엔드포인트를 사용하도록 확장할 수 있는 고성능 클러스터를 만들려면 kube-proxy 없이 클러스터를 만드는 것이 좋습니다. kube-proxy가 없으면 클러스터는 kube-proxy-replacement 모드에서 GKE Dataplane V2를 사용합니다. 이 모드에서는 대량의 iptables 규칙 집합을 유지하는 데 필요한 리소스 소비가 방지됩니다.
기존 클러스터에 대해서는 kube-proxy 사용을 사용 중지할 수 없습니다. 이 구성은 클러스터를 만들 때 설정해야 합니다. 안내 및 자세한 내용은 kube-proxy 없이 클러스터 만들기를 참조하세요.
CoreDNS 구성
이 섹션에서는 클러스터의 확장성에 영향을 주는 CoreDNS 측면에 대해 설명합니다.
포드 DNS
기본적으로 Google Distributed Cloud 클러스터는 다음과 같이 보이는 resolv.conf를 사용하여 포드를 삽입합니다.
nameserver KUBEDNS_CLUSTER_IP
search <NAMESPACE>.svc.cluster.local svc.cluster.local cluster.local c.PROJECT_ID.internal google.internal
options ndots:5
ndots:5 옵션은 점이 5개 미만인 호스트 이름이 정규화된 도메인 이름(FQDN)으로 간주되지 않음을 의미합니다. 대신 DNS 서버는 원래 요청된 호스트 이름에 지정된 모든 검색 도메인을 추가하고 이를 해결하려고 시도합니다. 예를 들어 google.com을 해결할 때 다음 순서로 검색을 수행합니다.
google.com.NAMESPACE.svc.cluster.localgoogle.com.svc.cluster.localgoogle.com.cluster.localgoogle.com.c.PROJECT_ID.internalgoogle.com.google.internalgoogle.com
각 조회는 IPv4(A 레코드) 및 IPv6(AAAA 레코드)에 대해 수행되며, 각 비FQDN 쿼리에 대해 12개의 DNS 요청이 발생하며, 이는 DNS 트래픽을 크게 증폭시킵니다. 이 문제를 완화하려면 후행 점(google.com.)을 추가하여 조회할 호스트 이름을 FQDN으로 선언하는 것이 좋습니다. 이러한 선언은 애플리케이션 워크로드 수준에서 수행되어야 합니다. 자세한 내용은 resolv.conf 설명 페이지를 참조하세요.
IPv6
클러스터에 IPv6가 사용되지 않는 경우 업스트림 DNS 서버에 대한 AAAA 레코드 조회를 없애서 DNS 요청을 절반으로 줄일 수 있습니다. AAAA 조회 사용 중지에 대한 지원이 필요하면 Cloud Customer Care에 문의하세요.
전용 노드 풀
애플리케이션 수명 주기에서 DNS 쿼리의 중요한 특성으로 인해 coredns 배포에 전용 노드를 사용하는 것이 좋습니다. 이 배포는 일반 애플리케이션과 다른 장애 도메인에 포함됩니다. coredns 배포 전용 노드를 설정하는 데 도움이 필요하면 Cloud Customer Care에 문의하세요.
MetalLB 확장성 문제
MetalLB는 활성-수동 모드로 실행됩니다. 즉, 어느 시점에서나 특정 LoadBalancer VIP를 서빙하는 MetalLB 스피커는 하나만 존재합니다.
장애 조치
Google Distributed Cloud 출시 버전 1.28.0 이전에서는 대규모인 경우 MetalLB의 장애 조치에 시간이 오래 걸리고 클러스터에 안정성 위험을 초래할 수 있습니다.
연결 한도
인그레스 서비스와 같은 특정 LoadBalancer VIP가 30,000개에 가깝거나 그 이상의 동시 연결을 예상하는 경우 VIP를 처리하는 스피커 노드가 사용 가능한 포트를 소진할 가능성이 높습니다. 아키텍처 제한으로 인해 MetalLB에는 이 문제의 해결 방안이 없습니다. 클러스터를 만들기 전에 BGP를 사용하는 번들 부하 분산으로 전환하거나 다른 인그레스 클래스를 사용하세요. 자세한 내용은 인그레스 구성을 참조하세요.
부하 분산기 스피커
기본적으로 Google Distributed Cloud는 컨트롤 플레인 및 데이터 플레인에 대해 동일한 부하 분산기 노드 풀을 사용합니다. 부하 분산기 노드 풀(loadBalancer.nodePoolSpec)을 지정하지 않으면 제어 영역 노드 풀(controlPlane.nodePoolSpec)이 사용됩니다.
부하 분산을 위해 컨트롤 플레인 노드 풀을 사용할 때 스피커 수를 늘리려면 컨트롤 플레인 머신 수를 늘려야 합니다. 프로덕션 배포의 경우 고가용성을 위해 3개의 컨트롤 플레인 노드를 사용하는 것이 좋습니다. 추가 스피커를 수용하기 위해 제어 영역 노드 수를 3개 이상으로 늘리는 것은 리소스를 제대로 사용하지 못하는 것일 수 있습니다.
인그레스 구성
하나의 LoadBalancer 서비스 VIP에 동시 연결이 30,000개에 근접할 것으로 예상되는 경우 MetalLB에서 이를 지원하지 못할 수 있습니다.
F5 BIG-IP와 같은 다른 메커니즘을 통해 VIP를 노출하도록 고려할 수 있습니다. 또는 동일한 제한이 없는 BGP 번들 부하 분산을 사용해서 새 클러스터를 만들 수 있습니다.
Cloud Logging 및 Cloud Monitoring 구성요소 미세 조정
대규모 클러스터에서는 애플리케이션 프로필 및 트래픽 패턴에 따라 Cloud Logging 및 Cloud Monitoring 구성요소에 대한 기본 리소스 구성만으로 충분하지 않을 수 있습니다. 관측 가능성 구성요소의 리소스 요청 및 한도를 조정하는 방법은 Stackdriver 구성요소 리소스 구성을 참조하세요.
특히 클러스터에서 많은 수의 서비스 및 엔드포인트가 포함된 kube-state-metrics는 kube-state-metrics 자체 및 동일 노드의 gke-metrics-agent에서 과도한 메모리 사용량을 일으킬 수 있습니다. metrics-server의 리소스 사용량도 노드, 포드, 서비스 측면에서 수평 축소될 수 있습니다. 이러한 구성요소에서 리소스 문제가 발생할 경우 Cloud Customer Care에 문의하세요.
sysctl을 사용하여 운영체제 구성
워크로드 사용 사례에 가장 적합하도록 노드의 운영체제 구성을 미세 조정하는 것이 좋습니다. inotify 리소스 수를 제어하는 fs.inotify.max_user_watches 및 fs.inotify.max_user_instances 매개변수는 조정이 필요한 경우가 많습니다. 예를 들어 다음과 같은 오류 메시지가 표시되면 이러한 매개변수를 조정해야 하는지 확인할 수 있습니다.
The configured user limit (128) on the number of inotify instances has been reached
ENOSPC: System limit for number of file watchers reached...
조정은 일반적으로 워크로드 유형 및 하드웨어 구성에 따라 다양합니다. 특정 OS별 권장사항은 해당 OS 공급업체에 문의하세요.
권장사항
이 섹션에서는 클러스터를 확장하기 위한 권장사항을 설명합니다.
한 번에 하나의 측정기준 확장
문제를 최소화하고 변경사항을 쉽게 롤백할 수 있도록 하려면 측정기준을 한 번에 2개 이상 조정하지 마세요. 여러 측정기준을 동시에 확장하면 작은 클러스터에서도 문제가 발생할 수 있습니다. 예를 들어 노드당 예약된 포드 수를 110개로 늘리는 동시에 클러스터의 노드 수를 250개로 늘리려고 하면 포드의 수, 노드당 포드 수, 노드 수가 너무 많이 늘어나기 때문에 성공하지 못할 가능성이 높습니다.
단계별 클러스터 확장
클러스터 확장에는 리소스가 많이 소모될 수 있습니다. 클러스터 운영이 실패하거나 클러스터 워크로드가 중단되는 위험을 줄이려면 한 번의 작업으로 여러 노드가 포함된 대규모 클러스터를 만들지 않는 것이 좋습니다.
워커 노드 없이 하이브리드 또는 독립형 클러스터 만들기
워커 노드가 50개가 넘는 대규모 하이브리드 또는 독립형 클러스터를 만드는 경우 먼저 제어 영역 노드가 있는 고가용성(HA) 클러스터를 만든 후 점진적으로 확장하는 것이 좋습니다. 클러스터 만들기 작업에는 HA가 아니어서 안정성이 낮은 부트스트랩 클러스터가 사용됩니다. HA 하이브리드 또는 독립형 클러스터를 만든 후에는 이를 사용해서 추가 노드로 확장할 수 있습니다.
일괄 워커 노드 수 늘리기
클러스터를 더 많은 워커 노드로 확장하는 경우 단계별로 확장하는 것이 좋습니다. 노드는 한 번에 20개 이하로 추가하는 것이 좋습니다. 중요한 워크로드를 실행하는 클러스터의 경우에 특히 그렇습니다.
병렬 이미지 가져오기 사용 설정
기본적으로 kubelet은 한 번에 하나씩 순차적으로 이미지를 가져옵니다. 이미지 레지스트리 서버에 대해 업스트림 연결이 잘못된 경우 잘못된 이미지 가져오기로 인해 지정된 노드 풀의 전체 큐가 멈출 수 있습니다.
이 문제를 해결하기 위해서는 커스텀 kubelet 구성에서 serializeImagePulls를 false로 설정하는 것이 좋습니다. 자세한 내용 및 안내는 kubelet 이미지 가져오기 설정 구성을 참조하세요.
병렬 이미지 가져오기를 사용 설정하면 네트워크 대역폭 또는 디스크 I/O 소비가 급증할 수 있습니다.
애플리케이션 리소스 요청 및 한도 미세 조정
밀집된 환경에서는 애플리케이션 워크로드가 제거될 수 있습니다. Kubernetes는 참조된 메커니즘을 사용하여 제거 시 포드 순위를 지정합니다.
컨테이너 리소스를 설정하기 위한 좋은 방법은 요청 및 한도에 대해 동일한 양의 메모리를 사용하고, 더 크거나 결합되지 않은 CPU 한도를 사용하는 것입니다. 자세한 내용은 Cloud 아키텍처 센터에서 클라우드 기반 Kubernetes 애플리케이션 준비를 참조하세요.
스토리지 파트너 사용
대규모 배포의 경우 GDC 지원 스토리지 파트너 중 하나를 사용하는 것이 좋습니다. 특정 스토리지 파트너에 대해 다음 정보를 확인해야 합니다.
- 스토리지 배포는 고가용성, 우선순위 설정, 노드 어피니티, 리소스 요청 및 한도와 같은 스토리지 특성에 대한 권장사항을 따라야 합니다.
- 스토리지 버전은 특정 Google Distributed Cloud 버전에 적격합니다.
- 스토리지 공급업체에서 사용자가 원하는 대규모 배포를 지원할 수 있습니다.
고가용성을 위한 클러스터 구성
대규모 배포를 감사하고 가능한 경우 중요 구성요소가 HA용으로 구성되었는지 확인하는 것이 중요합니다. Google Distributed Cloud는 모든 클러스터 유형에 대해 HA 배포 옵션을 지원합니다. 자세한 내용은 배포 모델 선택을 참조하세요. HA 배포의 클러스터 구성 파일 예시는 클러스터 구성 샘플을 참조하세요.
또한 다음과 같은 다른 구성요소를 감사하는 것도 중요합니다.
- 스토리지 공급업체
- 클러스터 웹훅
리소스 사용 모니터링
이 섹션에서는 대규모 클러스터에 대한 몇 가지 기본 모니터링 권장사항을 보여줍니다.
사용량 측정항목 집중 모니터링
노드 및 개별 시스템의 사용량을 모두 모니터링하고 안전 마진이 적절한지 확인해야 합니다. 기본적으로 사용 가능한 표준 모니터링 기능을 보려면 사전 정의된 대시보드 사용을 참조하세요.
대역폭 소비 모니터링
네트워크가 포화되어 클러스터의 성능 저하가 발생하지 않는지 대역폭 소비를 자세히 모니터링합니다.
etcd 성능 개선
디스크 속도는 etcd 성능과 안정성에서 매우 중요합니다. 느린 디스크에서는 etcd 요청 지연 시간이 증가하여 클러스터 안정성 문제가 발생할 수 있습니다. 클러스터 성능을 개선하기 위해 Google Distributed Cloud는 별개의 전용 etcd 인스턴스에 이벤트 객체를 저장합니다. 표준 etcd 인스턴스는 /var/lib/etcd를 데이터 디렉터리로 사용하고 클라이언트 요청에 포트 2379를 사용합니다. etcd 이벤트 인스턴스는 /var/lib/etcd-events를 데이터 디렉터리로 사용하고 클라이언트 요청의 포트 2382를 사용합니다.
etcd 저장소에는 솔리드 스테이트 디스크(SSD)를 사용하는 것이 좋습니다. 최적 성능을 위해서는 /var/lib/etcd 및 /var/lib/etcd-events에 별개의 디스크를 마운트합니다. 전용 디스크를 사용하면 2개의 etcd 인스턴스가 디스크 I/O를 공유하지 않게 됩니다.
etcd 문서는 프로덕션에서 클러스터를 실행할 때 최상의 etcd 성능을 보장하는 추가 하드웨어 권장사항을 제공합니다.
etcd 및 디스크 성능을 확인하려면 측정항목 탐색기에서 다음 etcd I/O 지연 시간 측정항목을 사용합니다.
etcd_disk_backend_commit_duration_seconds: 기간이 99번째 백분위수(p99)에 대해 25밀리초 이내여야 합니다.etcd_disk_wal_fsync_duration_seconds: 기간이 99번째 백분위수(p99)에 대해 10밀리초 이내여야 합니다.
etcd 성능에 대한 자세한 내용은 etcd 경고 '항목 적용이 너무 오래 걸림'은 무슨 의미인가요? 및 etcd 경고 '정시에 하트비트를 전송하지 못함'은 무슨 의미인가요?를 참조하세요.
추가 지원이 필요하면 Cloud Customer Care에 연락합니다.