워크로드

워크로드는 클러스터의 규모 조정에 영향을 미칩니다. Kubernetes APIs를 많이 사용하는 워크로드는 단일 클러스터에서 보유할 수 있는 총 워크로드 양을 제한하지만 부하를 줄이기 위해 변경할 수 있는 몇 가지 기본값이 있습니다.

Kubernetes 클러스터의 워크로드는 Kubernetes API와 통합되는 기능(예: Secrets 및 ServiceAccounts)에 액세스할 수 있지만 이러한 기능이 항상 필요한 것은 아니며 사용되지 않는 경우 비활성화해야 합니다. Kubernetes 컨트롤 플레인에 대한 워크로드 액세스 및 종속성을 제한하면 클러스터에서 실행할 수 있는 워크로드 수가 증가하고 워크로드에 대한 불필요한 액세스를 제거하고 최소 권한 사례를 구현하여 클러스터의 보안이 향상됩니다. 자세한 내용은 보안 모범 사례를 참조하십시오.

포드 네트워킹에 IPv6 사용

VPC를 IPv4에서 IPv6로 전환할 수 없으므로 클러스터를 프로비저닝하기 전에 IPv6를 활성화하는 것이 중요합니다. VPC에서 IPv6를 활성화한다고 해서 IPv6를 사용해야 하는 것은 아니며 포드 및 서비스에서 IPv6를 사용하는 경우에도 IPv4 주소로 트래픽을 라우팅할 수 있습니다. 자세한 내용은 EKS 네트워킹 모범 사례를 참조하세요.

클러스터에서 IPv6를 사용하면 가장 일반적인 클러스터 및 워크로드 조정 제한 중 일부를 피할 수 있습니다. IPv6는 IP 주소를 사용할 수 없으므로 포드와 노드를 생성할 수 없는 IP 주소 소진을 방지합니다. 또한 노드당 ENI 연결 수를 줄여 포드가 IP 주소를 더 빠르게 수신하기 때문에 노드당 성능이 향상되었습니다. VPC CNI에서 IPv4 접두사 모드를 사용하여 유사한 노드 성능을 달성할 수 있지만 VPC에서 사용 가능한 IP 주소가 충분한지 확인해야 합니다.

네임스페이스당 서비스 수 제한

네임스페이스의 최대 서비스 수는 5,000개이고 클러스터의 최대 서비스 수는 10,000개입니다. 워크로드 및 서비스를 구성하고, 성능을 높이고, 네임스페이스 범위 리소스에 대한 계단식 영향을 방지하려면 네임스페이스당 서비스 수를 500개로 제한하는 것이 좋습니다.

kube-proxy를 사용하여 노드당 생성되는 IP 테이블 규칙 수는 클러스터의 총 서비스 수에 따라 증가합니다. 수천 개의 IP 테이블 규칙을 생성하고 이러한 규칙을 통해 패킷을 라우팅하면 노드에 성능 영향을 미치고 네트워크 지연 시간이 추가됩니다.

네임스페이스당 서비스 수가 500개 미만인 한 단일 애플리케이션 환경을 포함하는 Kubernetes 네임스페이스를 생성합니다. 이렇게 하면 서비스 검색 제한을 피할 수 있을 만큼 서비스 검색이 작게 유지되며 서비스 이름 충돌을 방지하는 데도 도움이 될 수 있습니다. 애플리케이션 환경(예: 개발, 테스트, 생산)은 네임스페이스 대신 별도의 EKS 클러스터를 사용해야 합니다.

Elastic Load Balancer 할당량 이해

서비스를 생성할 때 사용할 로드 밸런싱 유형(예: Network Load Balancer(NLB) 또는 Application Load Balancer(ALB))을 고려합니다. 각 로드 밸런서 유형은 서로 다른 기능을 제공하며 할당량이 다릅니다. 일부 기본 할당량은 조정할 수 있지만 변경할 수 없는 할당량 최대값이 있습니다. 계정 할당량 및 사용량을 보려면 AWS 콘솔에서 Service Quotas 대시보드를 확인합니다.

예를 들어 기본 ALB 대상은 1000입니다. 엔드포인트가 1,000개 이상인 서비스가 있는 경우 할당량을 늘리거나 서비스를 여러 ALBs로 분할하거나 Kubernetes Ingress를 사용해야 합니다. 기본 NLB 대상은 3000이지만 AZ당 500개의 대상으로 제한됩니다. 클러스터가 NLB 서비스에 대해 500개 이상의 포드를 실행하는 경우 여러 AZs 사용하거나 할당량 한도 증가를 요청해야 합니다.

서비스에 연결된 로드 밸런서를 사용하는 대신 수신 컨트롤러를 사용하는 것이 좋습니다. AWS Load Balancer 컨트롤러는 수신 리소스에 대한 ALBs 생성할 수 있지만 클러스터에서 전용 컨트롤러를 실행하는 것을 고려할 수 있습니다. 클러스터 내 수신 컨트롤러를 사용하면 클러스터 내에서 역방향 프록시를 실행하여 단일 로드 밸런서에서 여러 Kubernetes 서비스를 노출할 수 있습니다. 컨트롤러에는 Gateway API 지원과 같은 다양한 기능이 있으며, 이는 워크로드의 수와 크기에 따라 이점이 있을 수 있습니다.

Route 53, Global Accelerator 또는 CloudFront 사용

여러 로드 밸런서를 사용하는 서비스를 단일 엔드포인트로 사용하려면 Amazon CloudFront, AWS Global Accelerator 또는 Amazon Route 53를 사용하여 모든 로드 밸런서를 단일 고객 대상 엔드포인트로 노출해야 합니다. 각 옵션은 이점이 다르며 필요에 따라 개별적으로 또는 함께 사용할 수 있습니다.

Route 53는 여러 로드 밸런서를 공통 이름으로 노출하고 할당된 가중치에 따라 각 로드 밸런서에 트래픽을 전송할 수 있습니다. 설명서에서 DNS 가중치에 대한 자세한 내용을 읽고 AWS Load Balancer Controller 설명서에서 Kubernetes 외부 DNS 컨트롤러를 사용하여 이를 구현하는 방법을 읽을 수 있습니다.

Global Accelerator는 요청 IP 주소를 기반으로 워크로드를 가장 가까운 리전으로 라우팅할 수 있습니다. 이는 여러 리전에 배포된 워크로드에 유용할 수 있지만 단일 리전의 단일 클러스터로의 라우팅을 개선하지는 않습니다. Route 53를 Global Accelerator와 함께 사용하면 AZ를 사용할 수 없는 경우 상태 확인 및 자동 장애 조치와 같은 추가 이점이 있습니다. 이 블로그 게시물에서 Route 53과 함께 Global Accelerator를 사용하는 예를 볼 수 있습니다.

CloudFront는 Route 53 및 Global Accelerator와 함께 사용하거나 단독으로 트래픽을 여러 대상으로 라우팅하는 데 사용할 수 있습니다. CloudFront는 오리진 소스에서 제공되는 자산을 캐싱하므로 서비스 대상에 따라 대역폭 요구 사항이 줄어들 수 있습니다.

엔드포인트 대신 EndpointSlices 사용

서비스 레이블과 일치하는 포드를 검색할 때는 엔드포인트 대신 EndpointSlices를 사용해야 합니다. 엔드포인트는 소규모로 서비스를 노출하는 간단한 방법이지만 자동으로 확장되거나 업데이트가 있는 대규모 서비스는 Kubernetes 컨트롤 플레인에서 많은 트래픽을 발생시킵니다. EndpointSlices에는 토폴로지 인식 힌트와 같은 항목을 활성화하는 자동 그룹화가 있습니다.

모든 컨트롤러가 기본적으로 EndpointSlices를 사용하는 것은 아닙니다. 컨트롤러 설정을 확인하고 필요한 경우 활성화해야 합니다. AWS Load Balancer Controller의 경우 EndpointSlices를 사용하려면 --enable-endpoint-slices 선택적 플래그를 활성화해야 합니다.

가능하면 변경 불가능한 보안 암호 및 외부 보안 암호 사용

kubelet은 해당 노드의 포드 볼륨에 사용되는 보안 암호에 대한 현재 키 및 값의 캐시를 유지합니다. kubelet은 보안 암호에 대한 감시를 설정하여 변경 사항을 감지합니다. 클러스터가 확장됨에 따라 감시 수가 증가하면 API 서버 성능에 부정적인 영향을 미칠 수 있습니다.

Secrets의 시계 수를 줄이는 두 가지 전략이 있습니다.

• Kubernetes 리소스에 액세스할 필요가 없는 애플리케이션의 경우 automountServiceAccountToken: false를 설정하여 자동 탑재 서비스 계정 보안 암호를 비활성화할 수 있습니다.

• 애플리케이션의 보안 암호가 정적이고 향후 수정되지 않을 경우 보안 암호를 변경 불가능으로 표시합니다. kubelet은 변경할 수 없는 보안 암호에 대한 API 감시를 유지하지 않습니다.

서비스 계정을 포드에 자동으로 탑재하는 기능을 비활성화하려면 워크로드에서 다음 설정을 사용할 수 있습니다. 특정 워크로드에 서비스 계정이 필요한 경우 이러한 설정을 재정의할 수 있습니다.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: app
automountServiceAccountToken: true

10,000개 제한을 초과하기 전에 클러스터의 보안 암호 수를 모니터링합니다. 다음 명령을 사용하여 클러스터의 총 보안 암호 수를 확인할 수 있습니다. 클러스터 모니터링 도구를 통해이 제한을 모니터링해야 합니다.

kubectl get secrets -A | wc -l

이 한도에 도달하기 전에 클러스터 관리자에게 알리도록 모니터링을 설정해야 합니다. Secrets Store CSI 드라이버와 함께 AWS Key Management Service(AWS KMS) 또는 Hashicorp Vault와 같은 외부 보안 암호 관리 옵션을 사용하는 것이 좋습니다. https://secrets-store-csi-driver.sigs.k8s.io/

배포 기록 제한

이전 객체는 여전히 클러스터에서 추적되므로 생성, 업데이트 또는 삭제 시 포드 속도가 느려질 수 있습니다. 배포revisionHistoryLimit의를 줄여 이전 ReplicaSets를 정리할 수 있습니다. 그러면 Kubernetes Controller Manager에서 추적하는 총 객체 수가 줄어듭니다. 10의 배포에 대한 기본 기록 제한입니다.

클러스터가 CronJobs 또는 기타 메커니즘을 통해 많은 작업 객체를 생성하는 경우 ttlSecondsAfterFinished 설정을 사용하여 클러스터에서 이전 포드를 자동으로 정리해야 합니다. 이렇게 하면 지정된 시간 후에 작업 기록에서 성공적으로 실행된 작업이 제거됩니다.

기본적으로 enableServiceLinks 비활성화

포드가 노드에서 실행되면 kubelet은 각 활성 서비스에 대한 환경 변수 세트를 추가합니다. Linux 프로세스의 최대 환경 크기는 네임스페이스에 서비스가 너무 많으면 도달할 수 있습니다. 네임스페이스당 서비스 수는 5,000개를 초과해서는 안 됩니다. 그런 다음 서비스 환경 변수 수가 쉘 제한을 초과하여 시작 시 포드가 충돌합니다.

포드가 서비스 검색에 서비스 환경 변수를 사용해서는 안 되는 다른 이유가 있습니다. 환경 변수 이름 충돌, 누출되는 서비스 이름 및 총 환경 크기는 몇 가지입니다. 서비스 엔드포인트를 검색하려면 CoreDNS를 사용해야 합니다.

리소스당 동적 승인 웹후크 제한

동적 승인 웹후크에는 승인 웹후크와 변형 웹후크가 포함됩니다. 리소스가 Kubernetes API로 전송될 때 순차적으로 호출되는 Kubernetes 제어 플레인의 일부가 아닌 API 엔드포인트입니다. 각 웹후크의 기본 제한 시간은 10초이며 여러 웹후크가 있거나 제한 시간이 있는 경우 API 요청이 걸리는 시간을 늘릴 수 있습니다.

특히 AZ 인시던트 발생 시 웹후크의 가용성이 높고 리소스를 거부하거나 실패를 무시하도록 failurePolicy가 올바르게 설정되어 있는지 확인합니다. 필요하지 않은 경우 --dry-run kubectl 명령이 웹후크를 우회하도록 허용하여 웹후크를 호출하지 마십시오.

apiVersion: admission.k8s.io/v1
kind: AdmissionReview
request:
  dryRun: False

웹후크를 변경하면 리소스를 연속해서 수정할 수 있습니다. 변형 웹후크가 5개 있고 리소스 50개를 배포하는 경우 압축이 실행될 때까지 각 리소스의 모든 버전을 5분마다 저장하여 수정된 리소스의 이전 버전을 제거합니다. etcd가 대체된 리소스를 제거하는이 시나리오에서는 etcd에서 200개의 리소스 버전이 제거되며 리소스 크기에 따라 조각 모음이 15분마다 실행될 때까지 etcd 호스트에서 상당한 공간을 사용할 수 있습니다.

이 조각 모음으로 인해 etcd가 일시 중지되어 Kubernetes API 및 컨트롤러에 다른 영향을 미칠 수 있습니다. 대규모 리소스를 자주 수정하거나 수백 개의 리소스를 빠르게 연속적으로 수정하지 않아야 합니다.

여러 클러스터의 워크로드 비교

성능이 비슷해야 하지만 그렇지 않은 클러스터가 두 개 있는 경우 지표를 비교하여 이유를 식별해 보세요.

예를 들어 클러스터 지연 시간을 비교하는 것은 일반적인 문제입니다. 이는 일반적으로 API 요청 볼륨의 차이로 인해 발생합니다. 다음 CloudWatch LogInsight 쿼리를 실행하여 차이를 이해할 수 있습니다.

filter @logStream like "kube-apiserver-audit"
| stats count(*) as cnt by objectRef.apiGroup, objectRef.apiVersion, objectRef.resource, userAgent, verb, responseStatus.code
| sort cnt desc
| limit 1000

필터를 추가하여 범위를 좁힐 수 있습니다. 예를 들어의 모든 목록 요청에 집중할 수 있습니다foo.

filter @logStream like "kube-apiserver-audit"
| filter verb = "list"
| filter user.username like "foo"
| stats count(*) as cnt by objectRef.apiGroup, objectRef.apiVersion, objectRef.resource, responseStatus.code
| sort cnt desc
| limit 1000