모든 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 스피커를 설정할 수 있는 Layer 2 연결의 노드 수에 제한이 있을 수 있습니다.
클러스터에 포함할 MetalLB 스피커 수를 신중하게 계획하고 필요한 Layer 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 권장사항을 문의할 수 있습니다.
권장사항
이 섹션에서는 클러스터를 확장하기 위한 권장사항을 설명합니다.
한 번에 하나의 측정기준 확장
문제를 최소화하고 변경사항을 쉽게 롤백하려면 한 번에 둘 이상의 측정기준을 조정하지 마세요. 작은 클러스터에서도 여러 측정기준을 동시에 확장하면 문제가 발생할 수 있습니다. 예를 들어 노드당 예약된 포드 수를 110개로 늘리는 동시에 클러스터의 노드 수를 250개로 늘리려고 하면 포드의 수, 노드당 포드 수, 노드 수가 너무 많이 늘어나기 때문에 성공하지 못할 가능성이 높습니다.
단계별로 클러스터 확장
클러스터 확장에는 리소스가 많이 소모될 수 있습니다. 클러스터 작업이 실패하거나 클러스터 워크로드가 중단될 위험을 줄이려면 단일 작업에서 많은 노드가 포함된 대규모 클러스터를 만들지 않는 것이 좋습니다.
워커 노드 없이 하이브리드 또는 독립형 클러스터 만들기
워커 노드가 50개가 넘는 대규모 하이브리드 또는 독립형 클러스터를 만드는 경우 먼저 제어 영역 노드가 있는 고가용성(HA) 클러스터를 만든 후 점진적으로 확장하는 것이 좋습니다. 클러스터 만들기 작업에서 HA가 아닌 부트스트랩 클러스터를 사용하므로 안정성이 낮습니다. HA 하이브리드 또는 독립형 클러스터가 생성된 다음에는 이를 사용하여 더 많은 노드로 확장할 수 있습니다.
일괄 워커 노드 수 늘리기
클러스터를 더 많은 워커 노드로 확장할 경우 단계별로 확장하는 것이 좋습니다. 한 번에 20개 이하의 노드를 추가하는 것이 좋습니다. 중요한 워크로드를 실행하는 클러스터의 경우에 특히 그렇습니다.
병렬 이미지 가져오기 사용 설정
기본적으로 kubelet은 이미지를 순차적으로 가져옵니다. 이미지 레지스트리 서버에 대한 업스트림 연결이 잘못된 경우 잘못된 이미지 가져오기로 인해 지정된 노드 풀의 전체 큐가 중단될 수 있습니다.
이 문제를 완화하려면 커스텀 kubelet 구성에서 serializeImagePulls를 false로 설정하는 것이 좋습니다. 자세한 내용 및 안내는 kubelet 이미지 가져오기 설정 구성을 참조하세요.
병렬 이미지 가져오기를 사용 설정하면 네트워크 대역폭 또는 디스크 I/O 소비가 급증할 수 있습니다.
애플리케이션 리소스 요청 및 한도 미세 조정
밀집된 환경에서는 애플리케이션 워크로드가 제거될 수 있습니다. Kubernetes는 제거 시 참조된 메커니즘을 사용하여 포드의 순위를 지정합니다.
컨테이너 리소스를 설정하기 위한 좋은 방법은 요청 및 한도에 대해 동일한 양의 메모리를 사용하고, 더 크거나 결합되지 않은 CPU 한도를 사용하는 것입니다. 자세한 내용은 클라우드 아키텍처 센터의 클라우드 기반 Kubernetes 애플리케이션 준비를 참조하세요.
스토리지 파트너 사용
대규모 배포에는 GDCV Ready 스토리지 파트너 중 하나를 사용하는 것이 좋습니다. 특정 스토리지 파트너에게 다음 정보를 확인하는 것이 중요합니다.
- 스토리지 배포는 고가용성, 우선순위 설정, 노드 어피니티, 리소스 요청, 한도와 같은 스토리지 측면에 대한 권장사항을 따릅니다.
- 스토리지 버전은 특정 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에 별도의 디스크를 마운트하세요. 전용 디스크를 사용하면 두 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에 연락합니다.