이 페이지에서는 Google Kubernetes Engine(GKE)에서 사용할 수 있는 로깅 옵션을 간략하게 설명합니다.
개요
Cloud Logging으로 전송된 GKE 로그는 전용 영구 데이터 스토어에 저장됩니다. GKE는 자체적으로 로그를 저장하지만 이러한 로그는 영구적으로 저장되지 않습니다. 예를 들어 GKE 컨테이너 로그는 호스트 포드가 제거될 때, 로그가 저장된 디스크 공간이 부족할 때 또는 로그가 새 로그로 교체될 때 제거됩니다. 시스템 로그는 새 로그 공간을 확보하기 위해 주기적으로 제거됩니다. 클러스터 이벤트는 1시간 후에 제거됩니다.
GKE 로깅 에이전트
컨테이너 로그와 시스템 로그의 경우, GKE는 기본적으로 컨테이너 로그를 읽고 유용한 메타데이터를 추가한 다음 Cloud Logging에 저장하는 노드별 로깅 에이전트를 배포합니다. GKE 로깅 에이전트는 다음 소스에서 컨테이너 로그를 확인합니다.
컨테이너화된 프로세스의 표준 출력 및 표준 오류 로그
kubelet 및 컨테이너 런타임 로그
VM 시작 스크립트 등 시스템 구성요소의 로그
이벤트의 경우, GKE는 이벤트를 자동으로 수집해 Logging으로 전송하는 kube-system 네임스페이스의 배포를 사용합니다.
수집되는 로그
기본적으로 GKE는 클러스터에서 여러 유형의 로그를 수집하고 Cloud Logging에 저장합니다.
감사 로그에는 관리자 활동 로그, 데이터 액세스 로그, 이벤트 로그가 포함됩니다. GKE의 감사 로그에 대한 자세한 내용은 GKE의 감사 로그 문서를 참조하세요. GKE의 감사 로그는 사용 중지할 수 없습니다.
시스템 로그에는 다음 소스의 로그가 포함됩니다.
네임스페이스
kube-system,istio-system,knative-serving,gke-system,config-management-system에서 실행되는 모든 포드docker/containerd런타임,kubelet,kubelet-monitor,node-problem-detector,kube-container-runtime-monitor등 컨테이너화되지 않은 키 서비스VM 인스턴스 메타데이터
serial-port-logging-enable이 true로 설정된 경우 노드의 직렬 포트 출력 GKE 1.16-13-gke.400부터 노드의 직렬 포트 출력이 Logging 에이전트에 의해 수집됩니다. 직렬 포트 출력 로깅을 사용 중지하려면 클러스터 생성 시--metadata serial-port-logging-enable=false를 설정합니다. 직렬 포트 출력은 GKE 노드의 비정상 종료, 부팅 실패, 시작 문제, 종료 문제 해결에 유용합니다. 이 로그를 중지하면 문제를 해결하기가 더 어려울 수 있습니다.
애플리케이션 로그는 사용자 노드에서 실행되는 비시스템 컨테이너로 생성되는 모든 로그를 포함합니다.
선택적으로 GKE는 특정 Kubernetes 제어 영역 구성요소에서 더 많은 유형의 로그를 수집하여 Cloud Logging에 저장할 수 있습니다.
API 서버 로그는 Kubernetes API 서버(
kube-apiserver)에서 생성된 모든 로그를 포함합니다.스케줄러 로그는 Kubernetes 스케줄러(
kube-scheduler)에서 생성된 모든 로그를 포함합니다.컨트롤러 관리자 로그는 Kubernetes 컨트롤러 관리자(
kube-controller-manager)에서 생성된 모든 로그를 포함합니다.
이러한 각 제어 영역 구성요소에 대해 자세히 알아보려면 GKE 클러스터 아키텍처를 참조하세요.
로그 수집
새 GKE 클러스터를 만들면 Cloud Logging과의 통합이 기본적으로 사용 설정됩니다.
시스템 및 애플리케이션 로그는 Cloud Logging의 로그 라우터에 전달됩니다.
여기에서 로그가 Cloud Logging으로 수집되거나, 제외되거나, BigQuery, Pub/Sub, Cloud Storage로 내보내질 수 있습니다.
GKE 버전 1.15.7부터 Standard 클러스터는 시스템 로그만 캡처하고 애플리케이션 로그는 수집하지 않도록 구성할 수 있습니다. Autopilot과 Standard 클러스터 모두 제외 필터를 사용하면 Cloud Logging으로 전송되는 로그의 볼륨을 줄일 수 있습니다.
Logging 처리량
시스템 로깅이 사용 설정되면 전용 Cloud Logging 에이전트가 자동으로 배포되고 관리됩니다. 클러스터의 모든 GKE 노드에서 실행되어 로그를 수집하고, 컨테이너, 포드, 클러스터에 대한 유용한 메타데이터를 추가한 후, fluentbit 기반 에이전트를 사용하여 Cloud Logging에 로그를 전송합니다.
GKE 노드에 초당 기본 로그 처리량 이상이 필요하고 GKE Standard 클러스터가 제어 영역 버전 1.23.13-gke.1000 이상을 사용하는 경우 로깅 처리량을 극대화하도록 설계된 Logging 에이전트의 대체 구성을 배포하도록 GKE를 구성할 수 있습니다.
자세한 내용은 로그 처리량 조정을 참조하세요.
커스텀 fluentd 또는 fluentbit를 사용한 로그 수집
GKE의 기본 로깅 에이전트는 클러스터의 로그를 Cloud Logging으로 보내는 에이전트를 배포하고 관리하는 관리형 솔루션을 제공합니다. GKE 제어 영역 버전에 따라 fluentd 또는 fluentbit가 로그를 수집하는 데 사용됩니다. GKE 1.17부터 fluentbit 기반 에이전트를 사용하여 로그가 수집됩니다.
GKE 1.17 이전의 버전을 사용하는 GKE 클러스터는 fluentd 기반 에이전트를 사용합니다. fluentd 에이전트의 기본 동작을 변경하려면 맞춤설정된 fluentd 에이전트를 실행하면 됩니다.
일반적인 사용 사례는 다음과 같습니다.
로그에서 민감한 정보 삭제
STDOUT또는STDERR에 기록되지 않은 추가 로그 수집특정 성능 관련 설정 사용
맞춤설정된 로그 형식
GKE 노드의 Linux auditd 로그 수집
Container-Optimized OS를 실행하는 GKE 노드에서 상세 운영체제 감사 로그를 사용 설정할 수 있습니다. 노드의 운영체제 로그는 오류 메시지, 로그인 시도, 바이너리 실행과 같은 클러스터 및 워크로드 상태의 중요한 정보를 제공합니다. 이 정보를 사용하여 문제를 디버깅하거나 보안 이슈를 조사할 수 있습니다.
자세한 내용은 GKE 노드에서 Linux 감사 로그 사용 설정을 참조하세요.
GKE 감사 로그
Kubernetes 클러스터 및 GKE 클러스터 작업 리소스 유형에 적용되는 로그 항목에 대한 자세한 내용은 감사 로깅을 참조하세요.
액세스 제어 로깅
액세스 제어 로깅에는 애플리케이션 액세스와 사용자 액세스의 두 가지 측면이 있습니다. Cloud Logging은 적절한 액세스 권한을 부여하는 데 사용할 수 있는 Identity and Access Management(IAM) 역할을 제공합니다.
애플리케이션 액세스
애플리케이션에는 Cloud Logging에 로그를 작성할 수 있는 권한이 필요합니다. 이 권한은 기본 노드 풀에 연결된 서비스 계정에 IAM 역할 roles/logging.logWriter를 할당하여 부여됩니다.
사용자 보기 액세스
프로젝트에서 로그를 보려면 roles/logging.viewer 역할이 있어야 합니다. 데이터 액세스 로그에 액세스해야 하는 경우 logging.privateLogViewer IAM 권한이 있어야 합니다.
권한 및 역할에 대한 자세한 내용은 액세스 제어 가이드를 참조하세요. 일반적으로 Cloud Logging에 적용되는 Cloud 감사 로그 권장사항을 검토할 수도 있습니다.
사용자 관리자 액세스
IAM 역할 roles/logging.configWriter 및 roles/logging.admin은 관리 기능을 제공합니다. 로그를 특정 또는 중앙 프로젝트로 전달하는 데 일반적으로 사용되는 로깅 싱크를 만들려면 roles/logging.configWriter 역할이 필요합니다. 예를 들어 로깅 싱크와 로깅 필터를 함께 사용하여 네임스페이스의 모든 로그를 중앙 집중식 로깅 버킷으로 전달할 수 있습니다.
자세한 내용은 Cloud Logging용 액세스 제어 가이드를 참조하세요.
권장사항
- 구조화된 로깅: GKE와 통합된 로깅 에이전트는 한 줄의 문자열로 직렬화되고 표준 출력 또는 표준 오류로 기록된 JSON 문서를 읽고 이를 Google Cloud Observability에 구조화된 로그 항목으로 전송합니다.
- 심각도: 기본적으로 표준 출력에 쓰이는 로그는
INFO수준이고, 표준 오류에 쓰이는 로그는ERROR수준입니다. 구조화된 로그에는 로그의 심각도를 정의하는severity필드가 포함될 수 있습니다. - BigQuery로 내보내기: 추가 분석을 위해서는 BigQuery 또는 Pub/Sub와 같은 외부 서비스로 로그를 내보낼 수 있습니다. BigQuery로 내보낸 로그는 형식과 구조를 유지합니다. 자세한 내용은 라우팅 및 스토리지 개요를 참조하세요.
- 알림: Logging이 예상치 않은 동작을 로깅할 때는 로그 기반 측정항목을 사용하여 알림 정책을 설정할 수 있습니다. 예시는 카운터 측정항목의 알림 정책 만들기를 참조하세요. 로그 기반 측정항목에 대한 자세한 내용은 로그 기반 측정항목 개요를 참조하세요.
- 오류 보고: 클러스터에서 실행되는 애플리케이션에서 오류를 수집하려면 Error Reporting을 사용할 수 있습니다.
제어 영역 로그
Kubernetes API 서버, 스케줄러, 컨트롤러 관리자에서 발생한 로그를 Cloud Logging으로 보내도록 GKE 클러스터를 구성할 수 있습니다.
요구사항
Kubernetes 제어 영역 구성요소에서 발생한 로그를 Cloud Logging으로 전송하려면 GKE 제어 영역 버전 1.22.0 이상이 필요하며 시스템 로그 수집이 사용 설정되어 있어야 합니다.
제어 영역 로그 수집 구성
새 클러스터 또는 기존 클러스터의 로깅 지원을 구성하는 방법에 대한 안내를 참조하세요.
가격 책정
GKE 제어 영역 로그를 Cloud Logging으로 내보냅니다. Cloud Logging 가격 책정이 적용됩니다.
할당량
제어 영역 로그는 Cloud Logging API의 '분당 쓰기 요청' 할당량을 사용합니다. 제어 영역 로그를 사용 설정하기 전에 해당 할당량의 최근 최고 사용량을 확인하세요. 동일한 프로젝트에 클러스터가 많거나 이미 할당량 한도에 도달한 경우 제어 영역 로그를 사용 설정하기 전에 할당량 한도 상향 조정을 요청할 수 있습니다.
액세스 제어
조직 내에서 Kubernetes 제어 영역 로그에 대한 액세스를 제한하려는 경우 더 제한된 액세스 제어로 별도의 로그 버킷을 만들 수 있습니다.
액세스 권한이 제한되는 별도의 로그 버킷에 저장하면 프로젝트에 대한 roles/logging.viewer 액세스 권한이 있는 사용자가 로그 버킷의 제어 영역 로그에 자동으로 액세스할 수 없습니다. 또한 개인 정보 보호 또는 보안 문제로 인해 특정 제어 영역 로그를 삭제하기로 결정한 경우, 액세스 권한이 제한되는 별도의 로그 버킷에 저장하면 다른 구성요소나 서비스의 로그에 영향을 주지 않으면서 해당 로그를 삭제할 수 있습니다.