클러스터 서비스

클러스터 서비스는 EKS 클러스터 내에서 실행되지만 사용자 워크로드는 아닙니다. Linux 서버가 있는 경우 워크로드를 지원하기 위해 NTP, syslog 및 컨테이너 런타임과 같은 서비스를 실행해야 하는 경우가 많습니다. 클러스터 서비스는 비슷하며 클러스터를 자동화하고 운영하는 데 도움이 되는 지원 서비스입니다. Kubernetes에서는 일반적으로 kube 시스템 네임스페이스에서 실행되며 일부는 DaemonSets로 실행됩니다.

클러스터 서비스는 가동 시간이 길 것으로 예상되며 중단 및 문제 해결에 매우 중요한 경우가 많습니다. 코어 클러스터 서비스를 사용할 수 없는 경우 데이터 액세스 권한을 잃어 중단을 복구하거나 방지하는 데 도움이 될 수 있습니다(예: 높은 디스크 사용률). 별도의 노드 그룹 또는 AWS Fargate와 같은 전용 컴퓨팅 인스턴스에서 실행해야 합니다. 이렇게 하면 클러스터 서비스가 확장 중이거나 더 많은 리소스를 사용하고 있을 수 있는 워크로드의 공유 인스턴스에 영향을 받지 않습니다.

CoreDNS 규모 조정

CoreDNS 조정에는 두 가지 기본 메커니즘이 있습니다. CoreDNS 서비스에 대한 호출 수를 줄이고 복제본 수를 늘립니다.

ndots를 줄여 외부 쿼리 감소

ndots 설정은 DNS 쿼리를 방지하기에 충분한 것으로 간주되는 도메인 이름의 마침표(일명 "점") 수를 지정합니다. 애플리케이션의 ndots 설정이 5(기본값)이고 api.example.com(점 2개)과 같은 외부 도메인에서 리소스를 요청하는 경우 더 구체적인 도메인에 대해 /etc/resolv.conf에 정의된 각 검색 도메인에 대해 CoreDNS가 쿼리됩니다. 기본적으로 외부 요청을 하기 전에 다음 도메인이 검색됩니다.

api.example.<namespace>.svc.cluster.local
api.example.svc.cluster.local
api.example.cluster.local
api.example.<region>.compute.internal

namespace 및 region 값은 워크로드 네임스페이스 및 컴퓨팅 리전으로 대체됩니다. 클러스터 설정에 따라 추가 검색 도메인이 있을 수 있습니다.

워크로드의 ndots 옵션을 낮추거나 후행를 포함하여 도메인 요청을 완전히 검증하여 CoreDNS에 대한 요청 수를 줄일 수 있습니다(예: api.example.com. ). 워크로드가 DNS를 통해 외부 서비스에 연결하는 경우 워크로드로 인해 불필요한 클러스터 내 DNS 쿼리가 발생하지 않도록 ndots를 2로 설정하는 것이 좋습니다. 워크로드가 클러스터 내의 서비스에 액세스할 필요가 없는 경우 다른 DNS 서버 및 검색 도메인을 설정할 수 있습니다.

spec:
  dnsPolicy: "None"
  dnsConfig:
    options:
      - name: ndots
        value: "2"
      - name: edns0

ndots를 너무 낮은 값으로 낮추거나 연결하려는 도메인에 충분한 특이도(후행 포함)가 포함되어 있지 않으면 DNS 조회가 실패할 수 있습니다. 이 설정이 워크로드에 미치는 영향을 테스트해야 합니다.

CoreDNS 수평 확장

CoreDNS 인스턴스는 배포에 복제본을 추가하여 확장할 수 있습니다. NodeLocal DNS 또는 클러스터 비례 오토스케일러를 사용하여 CoreDNS를 조정하는 것이 좋습니다.

NodeLocal DNS는 클러스터에 더 많은 컴퓨팅 리소스가 필요한 DaemonSet로 노드당 하나의 인스턴스를 실행해야 하지만 실패한 DNS 요청을 방지하고 클러스터의 DNS 쿼리에 대한 응답 시간을 줄입니다. 클러스터 비례 오토스케일러는 클러스터의 노드 또는 코어 수에 따라 CoreDNS를 조정합니다. 이는 요청 쿼리와 직접적인 상관 관계가 아니지만 워크로드 및 클러스터 크기에 따라 유용할 수 있습니다. 기본 비례 규모는 클러스터의 코어 256개 또는 노드 16개 중 먼저 발생하는 것에 대해 추가 복제본을 추가하는 것입니다.

Kubernetes 지표 서버를 수직으로 확장

Kubernetes 지표 서버는 수평 및 수직 조정을 지원합니다. 지표 서버를 수평적으로 확장하면 가용성이 높아지지만 더 많은 클러스터 지표를 처리하기 위해 수평적으로 확장되지는 않습니다. 노드와 수집된 지표가 클러스터에 추가되면 권장 사항에 따라 지표 서버를 수직으로 조정해야 합니다.

지표 서버는 수집, 집계 및 서비스하는 데이터를 메모리에 보관합니다. 클러스터가 증가하면 지표 서버가 저장하는 데이터의 양이 증가합니다. 대규모 클러스터에서 지표 서버는 기본 설치에 지정된 메모리 및 CPU 예약보다 더 많은 컴퓨팅 리소스를 필요로 합니다. Vertical Pod Autoscaler(VPA) 또는 Addon Resizer를 사용하여 지표 서버를 조정할 수 있습니다. Addon Resizer는 작업자 노드에 비례하여 수직으로 확장되며, VPA는 CPU 및 메모리 사용량에 따라 확장됩니다.

CoreDNS lameduck 기간

포드는 이름 확인에 kube-dns 서비스를 사용합니다. Kubernetes는 대상 NAT(DNAT)를 사용하여 노드에서 CoreDNS 백엔드 포드로 kube-dns 트래픽을 리디렉션합니다. CoreDNS 배포를 확장하면는 노드의 iptables 규칙 및 체인을 kube-proxy 업데이트하여 DNS 트래픽을 CoreDNS 포드로 리디렉션합니다. 스케일 업 시 새 엔드포인트를 전파하고 스케일 다운 시 규칙을 삭제하려면 클러스터 크기에 따라 1~10초가 걸릴 CoreDNS 수 있습니다.

이 전파 지연으로 인해 CoreDNS 포드가 종료되었지만 노드의 iptables 규칙이 업데이트되지 않은 경우 DNS 조회에 실패할 수 있습니다. 이 시나리오에서 노드는 종료된 CoreDNS 포드에 DNS 쿼리를 계속 전송할 수 있습니다.

CoreDNS 포드에서 lameduck 기간을 설정하여 DNS 조회 실패를 줄일 수 있습니다. lameduck 모드에서 CoreDNS는 진행 중인 요청에 계속 응답합니다. lameduck 기간을 설정하면 CoreDNS 종료 프로세스가 지연되어 노드가 iptables 규칙 및 체인을 업데이트하는 데 필요한 시간을 확보할 수 있습니다.

CoreDNS lameduck 기간을 30초로 설정하는 것이 좋습니다.

CoreDNS 준비 프로브

CoreDNS의 준비 프로브/health에는 /ready 대신를 사용하는 것이 좋습니다.

lameduck 기간을 30초로 설정하는 이전 권장 사항에 따라 포드 종료 전에 노드의 iptables 규칙을 업데이트할 수 있는 충분한 시간을 제공하고 CoreDNS 준비 프로브 /ready 대신 /health를 사용하면 시작 시 CoreDNS 포드가 DNS 요청에 즉시 응답할 수 있도록 완전히 준비될 수 있습니다.

readinessProbe:
  httpGet:
    path: /ready
    port: 8181
    scheme: HTTP

CoreDNS Ready 플러그인에 대한 자세한 내용은 https://coredns.io/plugins/ready/ 참조하십시오.

에이전트 로깅 및 모니터링

에이전트가 API 서버를 쿼리하여 워크로드 메타데이터로 로그 및 지표를 보강하기 때문에 로깅 및 모니터링 에이전트는 클러스터 컨트롤 플레인에 상당한 부하를 추가할 수 있습니다. 노드의 에이전트는 로컬 노드 리소스에만 액세스하여 컨테이너 및 프로세스 이름과 같은 것을 볼 수 있습니다. API 서버를 쿼리하면 Kubernetes 배포 이름 및 레이블과 같은 세부 정보를 추가할 수 있습니다. 이는 문제 해결에는 매우 유용하지만 규모 조정에는 해로울 수 있습니다.

로깅 및 모니터링에는 매우 다양한 옵션이 있기 때문에 모든 공급자에 대한 예를 표시할 수는 없습니다. fluentbit에서는 Use_Kubelet을 활성화하여 Kubernetes API 서버 대신 로컬 kubelet에서 메타데이터를 가져오고 데이터를 캐시Kube_Meta_Cache_TTL할 수 있을 때 반복 호출을 줄이는 숫자로 설정하는 것이 좋습니다(예: 60).

조정 모니터링 및 로깅에는 두 가지 일반 옵션이 있습니다.

• 통합 비활성화

• 샘플링 및 필터링

로그 메타데이터가 손실되므로 통합을 비활성화하는 것은 종종 옵션이 아닙니다. 이렇게 하면 API 조정 문제가 제거되지만 필요할 때 필요한 메타데이터가 없어 다른 문제가 발생합니다.

샘플링 및 필터링은 수집되는 지표 및 로그 수를 줄입니다. 이렇게 하면 Kubernetes API에 대한 요청 양이 줄어들고 수집된 지표 및 로그에 필요한 스토리지 양이 줄어듭니다. 스토리지 비용을 줄이면 전체 시스템의 비용이 절감됩니다.

샘플링을 구성하는 기능은 에이전트 소프트웨어에 따라 달라지며 다양한 수집 지점에서 구현할 수 있습니다. API 서버 호출이 발생할 가능성이 있으므로 에이전트에 최대한 가깝게 샘플링을 추가하는 것이 중요합니다. 샘플링 지원에 대해 자세히 알아보려면 공급자에게 문의하세요.

CloudWatch 및 CloudWatch Logs를 사용하는 경우 설명서에 설명된 패턴을 사용하여 에이전트 필터링을 추가할 수 있습니다.

로그 및 지표가 손실되지 않도록 수신 엔드포인트에서 중단이 발생할 경우 데이터를 버퍼링할 수 있는 시스템으로 데이터를 전송해야 합니다. fluentbit을 사용하면 Amazon Kinesis Data Firehose를 사용하여 데이터를 일시적으로 유지하여 최종 데이터 스토리지 위치에 과부하가 걸릴 가능성을 줄일 수 있습니다.