Elastic 및 OpenTelemetry를 이용한 Kubernetes에서의 현대적 Observability 및 보안

Kubernetes는 그 구조화된 특성 덕분에 서비스와 애플리케이션 배포 및 관리를 위한 반복 가능하고 확장 가능한 수단이 될 수 있습니다. 이에 따라 온프레미스 및 클라우드 배포 모델 양쪽 모두에 대해 수직적인 시장 전반에 걸쳐 광범위하게 채택되고 있습니다. 그러나 Kubernetes 운영의 자율성은 포괄적이고 완전히 수렴된 Observability와 보안을 요구합니다. 이는 현재 Elastic 플랫폼을 사용하여 고유하게 가능합니다.

이 글에서는 Elasticsearch 및 OpenTelemetry를 사용하여 Kubernetes에서 애플리케이션 및 서비스 워크플로우를 관찰하고 보호하기 위한 모범 사례에 대해 설명합니다. 여러분은 다음과 같은 방법을 배우시게 됩니다.

• Kubernetes 클러스터에서 Elastic Agent 배포 및 구성
• Elastic Agent를 사용하여 OpenTelemetry 애플리케이션 추적, 메트릭 및 이벤트 수집
• Elastic Agent를 사용하여 Kubernetes 컨테이너 로그, 클러스터 메트릭 및 네트워크 트래픽 패턴 수집
• Elastic Defend를 사용하여 Kubernetes 클러스터에 보안 중심 모니터링 및 위협 보호 기능 추가
• Elastic의 기본 제공 대시보드를 숙지하여 운영 문제 관찰, 상관 관계 분석 및 근본 원인 분석

데이터 사일로로 인한 Kubernetes 배포 문제 해결의 어려움

지금까지 업계에서는 애플리케이션 Observability, 인프라 Observability 및 인프라 보안을 별개의 도메인으로 간주했으며, 각 도메인은 별도의 팀에서 관리하는 별도의 e도구로 처리되었습니다. 이 모델은 종종 조직적으로 편리하지만, 다음과 같은 공통적인 문제점과 유리 천장이 빠르게 드러납니다.

분석가(사람 또는 컴퓨터)는 애플리케이션 Observability, 인프라 Observability 및 인프라 보안 전반에 걸쳐 수집된 데이터를 활용하여 해당 운영 문제가 인프라의 문제인지, 애플리케이션의 결함인지 또는 보안 위반인지 여부를 판단해야 합니다. 또한, 전문가들은 해당 문제의 근본 원인을 파악하기 위해 이 세 가지 소스 모두의 충실도가 높은 데이터에 액세스해야 합니다.

해결 방법으로, 고객은 선별된 Observability 데이터를 여러 데이터 플랫폼에서 복제하는 경우가 많습니다. 데이터 저장 공간, 지원 및 교육 비용은 기껏해야 두 배 또는 세 배입니다. 최악의 경우, 분석가들은 문제의 근본 원인을 적절히 파악하는 데 필요한 중요한 데이터를 놓치고 있습니다. 이것은 Kubernetes의 역동적이고 확장 가능한 특성에 의해 더욱 악화됩니다. 논란의 여지가 있지만, Observability와 보안 플랫폼을 분리하는 것은 Kubernetes가 제공하는 기대와 다른 서비스 배포 통합 모델에 대한 안티패턴입니다. 

Observability를 위한 적절한 시간

궁극적으로 개발자, 운영자 및 보안 분석가 모두 애플리케이션 및 인프라 전반에 걸쳐 시스템에 대한 통합된 엔드 투 엔드 뷰가 필요합니다. 인프라 배포 팀은 이러한 가시성을 제공하고 클러스터를 보호하기 위해 통합된 Kubernetes 네이티브 배포 패턴이 필요합니다.

이를 위해서는 다음과 같은 세 가지 활성화 요소가 필요합니다.

1. 애플리케이션, 서비스 및 인프라 로그, 추적, 이벤트 및 메트릭을 포함한 모든 Observability 및 보안 데이터는 검색(상관 관계 및 대기 시간)과 저장 공간(비용) 양쪽 모두에 최적화된 방식으로 통합된 데이터 플랫폼에 저장되어야 합니다.
2. 또한 통합된 데이터 플랫폼은 데이터를 상호 연결하고 역할 기반 방식으로 제공할 수 있어야 합니다. 예를 들어, 분석가가 문제의 근본 원인을 파악하려고 하는 경우, 플랫폼은 분석가가 발생 가능한 문제를 파악하도록 안내하고, 데이터의 기본 형식이나 소스에 신경 쓰지 않고 데이터와 원활하게 상호 작용할 수 있도록 지원해야 합니다.
3. 애플리케이션 및 인프라를 계측하려면 맞춤형 구성 없이 반복 가능하고 확장 가능한 배포라는 Kubernetes의 요구 사항에 부합해야 합니다.

Kubernetes를 위한 Elastic

Elastic, OpenTelemetry, Kubernetes 및 최신 컴퓨팅 하드웨어에 의해 구동되는 기술의 결합으로 오늘날 본격적인 Kubernetes 네이티브 Observability와 보안이 가능해졌습니다.

• OpenTelemetry는 개발자(사내 및 서드파티 모두)가 APM 공급업체 선택을 APM 구현에서 분리하여 모든 애플리케이션과 서비스를 완전히 구현할 수 있는 촉매제입니다
• CPU와 RAM이 풍부한 최신 컴퓨팅 하드웨어를 사용하면 실시간 애플리케이션에서도 성능에 영향을 미치지 않고 "상시 작동" 추적이 실용적입니다
• 검색 가능한 스냅샷과 새로운 시계열 데이터 스트림을 포함하는 최신 Elastic 아키텍처는 Elastic APM의 지능형 테일 기반 샘플링과 결합되어 포괄적인 Observability 및 보안 데이터의 다년간 운영되는 온라인 저장 공간을 실용적이고 경제적으로 제공합니다
• 각 Kubernetes 노드의 DaemonSet에 Elastic Agent를 배포하면 원격으로 제어되는 통합 데이터 수집기를 반복적으로 배포하고 확장할 수 있습니다. 배포한 후에는 Elastic Agent를 Fleet으로 관리하여 데이터 통합을 사소한 수준으로 추가, 구성 또는 제거할 수 있습니다.
• Elastic 플랫폼은 완벽하게 통합된 Kubernetes 보안 솔루션을 제공하여 보호, 관찰 및 태세 관리 기능을 확장합니다
• Elasticsearch는 기본 제공 대시보드, 이상 징후 탐지 및 경보를 사용하여 수집된 모든 데이터 소스 간의 상관 관계 및 지침을 제공합니다

데이터 수집 모델

다음 다이어그램에서 볼 수 있듯이, Observability 및 보안 데이터 수집을 위한 하이브리드 모델을 권장합니다. 애플리케이션 추적, 추적 이벤트 및 메트릭을 얻기 위한 OpenTelemetry APM 에이전트와 함께 Kubernetes 인프라 메트릭 및 애플리케이션 컨테이너 로그를 얻기 위해 Elastic Agent를 사용합니다. 이 접근법의 근거는 아래에 자세히 설명되어 있습니다.

애플리케이션 추적, 이벤트 및 메트릭 데이터

애플리케이션 추적 및 메트릭을 생성하려면 일반적으로 애플리케이션 코드에 APM 라이브러리를 직접 주입해야 합니다. 그러나 OpenTelemetry APM 에이전트를 사용하면 APM 채택에 문제가 되는 벤더 종속을 제거할 수 있습니다. 지금까지 OpenTelemetry는 애플리케이션 메트릭에 대한 새로운 지원과 함께 애플리케이션 추적 및 이벤트 추적을 캡처하기 위한 강력하고 표준화된 에이전트 구현에 대부분의 노력을 기울였습니다. 오늘날 거의 모든 인기 있는 프로그래밍 언어에 대해 상당히 성숙한 에이전트가 존재합니다. 대부분의 경우, 자동 계측을 사용하여 코딩 작업을 거의 또는 전혀 하지 않고 애플리케이션을 계측할 수 있습니다. 애플리케이션이 .NET, Java, NodeJS 또는 Python으로 작성되고 일반적인 프레임워크를 사용하는 경우, OpenTelemetry Kubernetes 운영자를 사용하여 런타임에 APM 라이브러리를 주입할 수도 있습니다!

근본 원인 분석을 위해서는 애플리케이션 로그 및 인프라 메트릭과 관련된 APM 데이터가 필요합니다. 이러한 상관 관계를 활성화하려면, 애플리케이션 추적 및 로그, 인프라 메트릭 간에 공통적으로 식별할 수 있는 특정 메타데이터 또는 리소스 속성이 필요합니다. Elastic 플랫폼은 service.name, pod.uid와 container.id를 사용하여 Kubernetes에서 실행되는 애플리케이션의 Observability 데이터를 함께 연결합니다. 과거에는, APM 라이브러리가 이 메타데이터를 얻기 위해 자체의 벽 밖을 "간섭"했습니다. 일부 OpenTelemetry APM 라이브러리는 현재 이 기능(예: Java)을 지원하는 반면 다른 라이브러리는 지원하지 않습니다(Rust). 배포를 단순화하면서도, 이 접근 방식은 이상적인 것과는 거리가 먼 것이 분명합니다. (애플리케이션의 컨텍스트에서 실행되는) APM 에이전트는 런타임 환경(Docker, Kubernetes 등)을 결정할 뿐만 아니라 이러한 식별자에 대한 충분한 권한(예: /proc/self/cgroup 또는 Kubernetes API에 대한 액세스 권한)이 필요합니다. 후자는 분명히 잠재적인 보안 문제입니다. 따라서 외부 엔티티에 의존하여 이러한 메타데이터(환경 변수)를 전달하거나 추적 데이터가 생성된 후 이러한 메타데이터를 추가하는 것이 이상적입니다. 사용 중인 OpenTelemetry APM 라이브러리에 관계없이 데이터를 추가하기 위해 container.id를 안정적으로 추가하려면, 노드의 DaemonSet에서 실행되는 k8sattribute processor로 구성된 OpenTelemetry Collector를 배포합니다.

APM 데이터에 연관된 Kubernetes 메타데이터가 태그되면, OpenTelemetry Collector에서 노드의 DaemonSet에서도 실행되는 Elastic Agent로 전달됩니다. Elastic Agent는 APM 통합과 함께 Fleet를 통해 구성되었습니다. APM 통합을 각 노드 DaemonSet에 배포하면 APM 수집 부하를 분산하는 데 도움이 되며 그 가용성을 지원하는 애플리케이션과 더욱 밀접하게 연결할 수 있습니다. 또한 GRPC/HTTP2 트래픽은 DaemonSet 자체에 로컬로 유지되며, GRPC/HTTP2 로드 밸런싱 복잡성을 옆으로 비켜갑니다. 마지막으로, 보안이 단순화됩니다. OTLP는 노드와 Elasticsearch 클러스터 간에 Fleet 관리형 Elastic Agent TLS 보안을 사용하여 노드에서 안전하지 않은 상태로 유지될 수 있습니다. Elastic APM 통합은 OpenTelemetry 추적, 메트릭 및 이벤트 데이터를 Elasticsearch Common Schema(ECS)로 변환합니다. 그런 다음, 결과 문서가 수집 및 색인되도록 Elasticsearch로 전송됩니다.

컨테이너 로그 및 Kubernetes 인프라 메트릭

OpenTelemetry 표준은 로깅을 지원하지만, 구현은 여전히 초안 작업 중입니다. 따라서 사용 가능한 에이전트 중 상당수는 아직 로깅 프레임워크를 후크하는 기능을 지원하지 않습니다. 실제로, 컨테이너 로그 파일을 수집하는 것이 애플리케이션 로그 데이터를 캡처하는 유일한 실질적인 방법입니다. OpenTelemetry Collector filelogreceiver를 사용하면 이 작업이 가능하지만, 현재 알파 품질이므로 프로덕션 사용 사례에는 아직 권장되지 않습니다. Kubernetes 인프라 메트릭을 캡처하기 위한 k8sclusterreceiver도 마찬가지입니다.

이에 비해, Elastic Kubernetes 통합은 강력하고 입증되었으며 애플리케이션 로그 및 Kubernetes 인프라 메트릭의 충실도 높은 수집 기능을 제공합니다. 또한 Kubernetes 통합은 Kibana에서 원격으로 Fleet 수준에서 관리할 수 있어 구성을 크게 간소화할 수 있습니다. 애플리케이션 추적 및 메트릭과 달리, Elastic Kubernetes 통합은 애플리케이션 코드 외부에서 작동하므로 벤더 종속 문제를 완화합니다.

또한 각 노드의 DaemonSet에 Elastic Agent가 존재하는 것은 Kubernetes 통합 이상의 가치를 가집니다. 이 글의 뒷부분에서 볼 수 있듯이, 이 동일한 Elastic Agent 인스턴스를 활용하여 Elastic Defend를 배포하여 Kubernetes 노드를 모니터링하고 보호할 것입니다.

보안 이벤트 및 호스트 데이터

분석가들이 특정 문제의 근본 원인을 파악할 수 있도록 현대적인 Kubernetes Observability 및 보안 워크플로우가 함께 진행되어야 합니다. Elastic의 보안 솔루션은 엔드포인트 보호를 비롯하여 완벽하게 통합된 모든 기능을 갖춘 Kubernetes 인식 SIEM, SOAR 및 XDR 솔루션을 제공합니다.

특히 Elastic의 Defend 통합은 본질적으로 Kubernetes의 Observability를 크게 향상시킵니다. Elastic의 Kubernetes 보안 태세 관리 통합을 통해 애플리케이션의 잠재적인 구성 문제를 보안 팀이 파악하기 전에 개발, DevOps 및 DevSecOps 팀에 미리 통보할 수 있습니다. 분석가는 Kubernetes 보안 대시보드를 사용하여 Kubernetes 노드에서 실행된 프로세스의 내용, 실행 시간, 런타임 매개 변수 내용 및 해당 계정을 정확하게 파악할 수 있습니다! 전례 없는 수준의 런타임 가시성을 통해 컨테이너화된 애플리케이션에서 종속성으로 사용되는 컨테이너 계층에 유입되는 예기치 않은 보안 위협을 탐지할 수 있습니다.

Elastic의 APM 통합과 마찬가지로, 이러한 보안 통합은 Fleet를 통해 추가, 구성 및 제거되며 Kubernetes 클러스터의 각 노드에 있는 DaemonSet의 Elastic Agent 내부에서 실행됩니다.

본격적인 작업 시작!

요건

앱, Elastic Agent 및 OpenTelemetry Collector를 배포할 Kubernetes 클러스터가 필요합니다. 개인적으로는 kOps를 사용하여 하이퍼스케일러에서 테스트 클러스터를 쉽게 생성, 관리 및 삭제하는 것을 좋아합니다. 참고로, 단일 AWS EC2 t3.xlarge는 OpenTelemetry 데모와 Elastic Agent를 배포하기에 충분합니다. 여기에 나온 예는 주요 하이퍼스케일러 또는 온프레미스(예: OpenShift)에 있는 모든 자체 관리형 또는 관리형(예: EKS, GKE) Kubernetes 클러스터와 함께 사용해야 합니다. 또한 이론적으로 데스크톱 Kubernetes 클러스터(MicroK8s 또는 Docker의 기본 제공 Kubernetes 엔진 등)와 함께 작동해야 합니다. 이러한 환경에 충분한 RAM과 CPU(예: vCPU 4개 및 16GB RAM)를 제공한다고 가정합니다. 또한 기본적인 Kubernetes 관리 지식(예: yaml 배포, 포드 상태 확인, 포드 로그 파일 보기)이 필요합니다. 시작하기 전에, Kubernetes 컨텍스트가 올바른 클러스터를 가리키고 있는지 확인합니다.

물론 OpenTelemetry를 사용하여 계측할 수 있는 애플리케이션이나 서비스도 필요합니다. 시작하려면, OpenTelemetry 데모의 포크를 사용하세요. 여기서 Elastic의 모범 사례를 따라 여러분의 애플리케이션과 서비스를 계측할 수 있습니다.

마지막으로, Kubernetes 애플리케이션 클러스터에서 액세스할 수 있는 최신(8.5 이상) Elasticsearch 배포(Elastic 클라우드에서 무료로 만들 수 있습니다!)에 액세스해야 합니다.

도구

이 튜토리얼에서는 Linux 또는 MacOS 기반 호스트를 사용하여 Kubernetes 클러스터를 구성하고 있다고 가정합니다. 다음 도구가 설치되어 있는지 확인해야 합니다.

• Helm
• curl
• patch

Elasticsearch 클러스터 만들기

이미 최신 Elasticsearch 배포 환경을 사용하고 계시다면, 아주 좋습니다! 그렇지 않다면, cloud.elastic.co에서 무료 체험판 클러스터를 만들어 설정해 보겠습니다!

1. cloud.elastic.co로 이동하여 무료 체험판에 가입합니다(신용 카드 필요 없음)
2. 예를 들어, Elasticsearch 클러스터의 이름을 "o11y"로 지정하고 다른 설정은 기본값으로 유지합니다
3. [배포 생성하기]를 클릭합니다
4. Elasticseearch Cloud에서 "배포 준비가 완료되었습니다!"라는 메시지가 뜨기를 기다립니다
5. [계속]을 클릭하여 Kibana에 로그인합니다

DaemonSet에 Elastic Agent 배포

Kubernetes 클러스터의 각 노드에 있는 DaemonSet에 설치된 Elastic Agent(통합 포함)를 사용하여 Elasticsearch에 데이터를 수집합니다.

1. 다음 YAML(여기 참조)을 로컬 컴퓨터에 다운로드합니다. 이 YAML을 사용하여 Kubernetes 노드의 DaemonSet에 Elastic Agent(Elastic Defend 포함)를 배포합니다.

curl -L -O https://raw.githubusercontent.com/elastic/endpoint/main/releases/8.5.0/kubernetes/deploy/elastic-defend.yaml 

2. 다음 패치를 로컬 컴퓨터에 다운로드합니다. 이 패치는 설치할 모든 통합을 편안하게 수용할 수 있도록 기본 Elastic Agent 컨테이너 RAM 및 CPU 할당을 높여줍니다. 프로덕션에서 아래의 통합의 하위 집합만 배포하도록 결정할 수 있으며, 이 경우 수정 사항이 문제가 될 수 있습니다.

curl -L -O https://raw.githubusercontent.com/ty-elastic/elastic-otel-k8s/main/agent/8.5.0/elastic-defend.yaml.patch 

3. 패치를 제자리에 적용합니다

patch elastic-defend.yaml elastic-defend.yaml.patch 

4. Elasticsearch 클러스터의 Kibana에 로그인했는지 확인합니다

5. [관리/Fleet]로 이동합니다

6. [에이전트 추가]를 클릭합니다

7. 새 정책의 이름을 예를 들어 "k8s-apps"로 지정합니다 

• "k8s-apps" 정책은 여기에서 애플리케이션 Kubernetes 클러스터의 DaemonSet 노드에 통합을 배포하는 데 사용됩니다

8. [고급 옵션]에서 [등록 취소 시간 초과]를 "3600"초로 설정합니다 

• Kubernetes는 노드를 동적으로 만들고 삭제할 수 있습니다 - 이 설정을 사용하면 삭제된 노드에 배포된 Elastic Agent가 자동으로 제거됩니다

9. [정책 만들기]를 클릭합니다

10. [호스트에 Elastic Agent 설치]에서 "Kubernetes"를 선택합니다

11. "FLEET_URL" 변수의 값을 찾아 이전에 다운로드하여 패치한 "elastic-defend.yaml" 파일의 "FLEET_URL" 값으로 복사합니다

12. "FLEET_ENROLLMENT_TOKEN" 변수 값을 찾아 이전에 다운로드하여 패치한 "elastic-defend.yaml" 파일의 "FLEET_ENROLLMENT_TOKEN" 값으로 복사합니다

13. 다음을 통해 elastic-defend.yaml을 클러스터에 적용합니다

kubectl apply -f elastic-defend.yaml 

14. [에이전트 등록 확인]에서 "에이전트 1명이 등록되었습니다"라고 표시될 때까지 기다립니다

15. [수신 데이터 확인됨]에서 "최근에 등록된 에이전트 1개 중 1개로부터 수신 데이터 수신됨"이라고 표시할 때까지 기다립니다

16. “닫기”를 클릭합니다

Kubernetes 호스트 옵션을 선택하면 Elastic이 사전 구성된 Elastic Agent 배포 YAML을 제공한다는 사실을 알고 계셨을 수도 있습니다. 이 배포 YAML에는 아직 Elastic Defend 이미지가 포함되어 있지 않습니다.

Elastic Agent 통합 설정

이제 쉬운 부분이 나옵니다! DaemonSet에 배포된 Fleet 관리형 Elastic Agent를 사용하면, Kibana 통합 인터페이스를 사용하여 원격으로 통합을 추가/구성/삭제하는 것이 간단합니다.

APM

Elastic APM 통합은 OpenTelemetry APM 데이터를 Elastic으로 가져오는 데 사용됩니다.

1. Kibana에서 [관리/통합]으로 이동합니다
2. "APM"을 검색합니다
3. [APM]을 클릭합니다
4. [Fleet에서 APM 통합 관리]를 클릭합니다
5. [Elastic APM 추가]를 클릭합니다
6. [일반/서버 구성/호스트]를 "0.0.0:8200"으로 설정합니다(이렇게 하면 APM 통합 수집이 노드의 다른 포드(DaemonSet에서도 실행되는 OpenTelemetry Collector 포함)에 노출됩니다.)
7. [에이전트 인증/익명 에이전트 액세스]를 비활성화합니다(이 단순화를 통해 OpenTelemetry Collector는 인증 토큰 없이 OTEL 데이터를 Elastic APM 통합으로 전송할 수 있습니다(특히, APM 통합은 노드 외부에 노출되지 않습니다).)
8. 선택적으로 [테일 기반 샘플링]을 활성화합니다(이를 통해 추적 데이터의 지능형 서브샘플링으로 저장 공간 요건을 줄이면서 이상 징후와 전체 성능을 캡처할 수 있습니다.)
9. [이 통합을 추가할 위치]를 "기존 호스트"로 설정하고 [에이전트 정책]을 "k8s-apps"로 설정합니다
10. [저장 후 계속]을 클릭합니다
11. [변경 사항 저장 및 배포]를 클릭합니다

Kubernetes

Kube 상태 메트릭 배포

기본 제공 Kubernetes 대시보드를 사용하려면 Kubernetes 통합이 Kubernetes 클러스터에서 kube-state-metrics를 사용할 수 있어야 합니다.

1. kube-state-metrics helm 리포지토리를 추가합니다

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts 

helm repo update 

2. Kubernetes 클러스터에 Elastic Agent와 동일한 네임스페이스로 kube-state-metrics를 설치합니다(제공된 Elastic Agent용 배포 yaml을 사용하며 기본적으로 "kube-system"으로 설정)

helm install --set namespaceOverride=kube-system kube-state-metrics prometheus-community/kube-state-metrics 

Kubernetes 통합 설치

Elastic Kubernetes 통합은 Kubernetes 메트릭 및 로그를 Elasticsearch로 가져오는 데 사용됩니다.

1. Kibana에서 [관리/통합]으로 이동합니다
2. "Kubernetes"를 검색합니다
3. [Kubernetes]를 선택합니다
4. [Kubernetes 추가]를 클릭합니다
5. 아직 설정되지 않은 경우 [Kube-state-metrics에서 Kubernetes 메트릭 수집]을 활성화합니다
6. [이 통합을 추가할 위치]를 "기존 호스트"로 설정하고 [에이전트 정책]을 "k8s-apps"로 설정합니다
7. [저장 후 계속]을 클릭합니다
8. [변경 사항 저장 및 배포]를 클릭합니다

Elastic Defend

Elastic Defend 통합은 Kubernetes 노드를 보호하고 추가적인 보안 중심 Observability 데이터를 수집하는 데 사용됩니다.

1. Kibana에서 [관리/통합]으로 이동합니다
2. "Elastic Defend"를 검색합니다
3. [Elastic Defend]를 선택합니다
4. [Elastic Defend 추가]를 클릭합니다
5. [통합 이름]을 "defend-1"로 설정합니다
6. [구성 설정 선택]으로 이동한 후 [보호할 환경 유형 선택]을 "클라우드 워크로드(Linux 서버 또는 Kubernetes 환경)"로 설정하고 [데이터 수집 볼륨을 줄이려면 대화형만 선택]을 "모든 이벤트"로 설정합니다
7. [이 통합을 추가할 위치]를 "기존 호스트"로 설정하고 [에이전트 정책]을 "k8s-apps"로 설정합니다
8. Kubernetes 클러스터가 GKE 또는 EKS에서 실행되고 있지 않은 경우, [고급 옵션]에서 [네임스페이스]를 "k8sapps"로 설정합니다. 여기서 "k8sapps"는 애플리케이션 Kubernetes 클러스터를 식별합니다(이는 적용되는 Kubernetes 클러스터의 이름으로 Elastic Defend 원격 측정에 태그를 지정하는 데 필요합니다.)
9. [저장 후 계속]을 클릭합니다
10. [설정]을 선택합니다
11. [Elastic Defend 버전]으로 이동하여 "통합 정책을 자동으로 최신 상태로 유지"를 활성화합니다
12. [통합 정책]을 선택하고 [defend-1]을 클릭합니다
13. [유형: 운영 체제/이벤트 수집: Linux]로 이동하여 [터미널 출력 캡처]를 활성화합니다
14. [저장 후 계속]을 클릭합니다
15. [변경 사항 저장 및 배포]를 클릭합니다

특정 Elasticsearch Kubernetes 대시보드에는 Kubernetes 클러스터 이름 및 ID에 대한 지식이 필요합니다. 클러스터가 GKE 또는 EKS에서 실행 중인 경우, Elastic Agent는 이 메타데이터를 자동으로 가져옵니다. 자체 관리형 Kubernetes 클러스터를 실행 중인 경우, 이전에 정의한 정책 네임스페이스에서 자동으로 설정된 orchestrator.cluster.name 및 orchestrator.cluster.id 필드로 보안 이벤트를 표시하는 수집 파이프라인을 만들 수 있습니다.

1. [관리/개발 도구]로 이동합니다
2. 다음을 실행합니다

Kubernetes 보안 태세 관리

Elastic Kubernetes 보안 태세 관리 통합은 인터넷 보안 센터(CIS)에서 정의한 보안 Kubernetes 구성 모범 사례에 따라 Kubernetes 클러스터 및 애플리케이션의 유효성을 검사하는 데 사용됩니다. 이를 통해 개발 및 배포 팀은 잘못된 구성이 보안 침해로 이어지기 전에 문제를 발견할 수 있습니다.

1. Kibana에서 [관리/통합]으로 이동합니다
2. "Kubernetes 보안 태세 관리"를 검색합니다
3. [Kubernetes 보안 태세 관리]를 선택합니다
4. [Kubernetes 보안 태세 관리 추가]를 클릭합니다
5. Kubernetes 애플리케이션 클러스터가 AWS EKS에서 특별히 실행 중인 경우 [Kubernetes 배포]를 "관리되지 않는 Kubernetes"(자체 관리형 Kubernetes를 위한) 또는 "EKS(Elastic Kubernetes Service)"로 설정합니다
6. [이 통합을 추가할 위치]를 "기존 호스트"로 설정하고 [에이전트 정책]을 "k8s-apps"로 설정합니다
7. [저장 후 계속]을 클릭합니다
8. [변경 사항 저장 및 배포]를 클릭합니다

네트워크 패킷 캡처

Elastic 네트워크 패킷 캡처 통합은 Kubernetes 노드로 들어오고 나가는 네트워크 트래픽에 대한 인사이트를 얻는 데 사용됩니다.

1. Kibana에서 [관리/통합]으로 이동합니다
2. "네트워크 패킷 캡처"를 검색합니다
3. [네트워크 패킷 캡처]를 선택합니다
4. [네트워크 패킷 캡처 추가]를 클릭합니다
5. [이 통합을 추가할 위치]를 "기존 호스트"로 설정하고 [에이전트 정책]을 "k8s-apps"로 설정합니다
6. [저장 후 계속]을 클릭합니다
7. [변경 사항 저장 및 배포]를 클릭합니다

OpenTelemetry로 계측

Elastic Observability를 위해 OpenTelemetry 데모 및 OpenTelemetry Helm 차트를 최적화했습니다(변경된 내용과 이유에 대한 자세한 내용은 자체 애플리케이션 계측 참조). Elastic이 Kubernetes Observability와 보안에 제공하는 가치를 이해하기 위해 OpenTelemetry 데모의 애플리케이션을 사용하려면, OpenTelemetry 데모 설정부터 시작하세요. 그렇지 않은 경우, 자체 애플리케이션과 서비스를 관찰하려면 자체 애플리케이션 계측에 설명된 지침부터 시작하세요.

OpenTelemetry 데모 설정

이 섹션에서는 OpenTelemetry 데모에 이미 계측된 애플리케이션을 배포하고 관찰할 것이라고 가정합니다. 데모 애플리케이션과 OpenTelemetry Collector 인스턴스를 양쪽 모두 배포하는 수정된 OpenTelemetry Helm 차트를 사용하겠습니다.

1. helm 리포지토리를 추가합니다

helm repo add elastic-open-telemetry https://ty-elastic.github.io/opentelemetry-helm-charts 

helm repo update 

2. 데모 앱 및 Collector를 Kubernetes 클러스터에 설치합니다

helm install elastic-otel elastic-open-telemetry/opentelemetry-demo 

3. 실행 중인 포드를 나열하여 설치를 확인합니다

kubectl get pods 

OpenTelemetry Collector 인스턴스 외에 모든 OpenTelemetry 데모 포드가 표시되어야 합니다

4. 검증 및 관찰로 건너뛰어 애플리케이션 추적, 메트릭 및 이벤트가 Elasticsearch에 유입되고 있는지 확인합니다

OpenTelemetry를 사용하여 자체 애플리케이션 계측

이 섹션에서는 여러분이 자체 애플리케이션을 OpenTelemetry로 계측할 것으로 가정합니다. 애플리케이션이 이 글에서 제시된 배포 모델과 함께 작동하도록 하려면, 다음과 같은 작업이 필요합니다

1. 안정적인 OpenTelemetry APM 에이전트 릴리즈로 계측되어야 합니다
2. 특정 OpenTelemetry 환경 변수로 인스턴스화합니다
3. 수동 계측을 사용하는 경우, 특정 스팬 속성을 적절하게 설정해야 합니다
4. 선택적으로 특정 메타데이터를 로그 줄에 추가합니다
5. 로그 데이터를 Elastic Kubernetes 통합으로 캡처할 stdout와 stderr로 내보냅니다

컨테이너 환경 변수

Elastic의 기본 제공 APM 대시보드를 활성화하려면, 애플리케이션 추적, 메트릭 및 이벤트가 적절한 컨텍스트의 메타데이터를 전달하는지 확인해야 합니다. 이 메타데이터는 Kubernetes 다운워드 API에서 얻을 수 있으며, OTEL_RESOURCE_ATTRIBUTES 환경 변수를 통해 애플리케이션에 전달됩니다.

또한 OTEL_EXPORTER_OTLP_ENDPOINT를 설정하여 애플리케이션이 OTLP를 통해 OpenTelemetry 데이터를 나중에 노드의 DaemonSet에 배포할 OpenTelemetry Collector 인스턴스로 전송하도록 해야 합니다.

다음 Kubernetes 컨테이너 구성 코드 조각은 배포 YAML에서 애플리케이션에 적용해야 하는 환경 변수를 설정합니다.

k8s.container.restart_count=0을 리소스 속성으로 설정하고 있는 이유가 궁금할 수 있습니다. 현재 OpenTelemetry Collector k8sattrribute 프로세서에서 container.id를 얻기 위해 실행 중인 컨테이너 인스턴스와 컨테이너를 (k8s.container.name를 통해) 일치시키려면 이 힌트가 필요합니다. k8s.container.restart_count=0 설정은 단순화됩니다. 특정 컨테이너가 포드에서 Kubernetes에 의해 다시 시작된 횟수를 추적하고 어떻게든 환경 변수로 가져오는 것은 어려울 것입니다. 일반적인 시나리오에서, 컨테이너는 일반적으로 해당 포드 수명 동안 한 번만 시작됩니다. 그러나 컨테이너가 포드에 의해 다시 시작되면, 이 단순화는 실패합니다.

스팬 특성

Elastic APM은 스팬 데이터를 적절하게 특성화, 분류 및 시각화하기 위해 특정 스팬 속성을 명시적으로 설정해야 합니다. 대부분의 OpenTelemetry APM 자동 계측 라이브러리는 이러한 필드를 설정합니다. 그러나 애플리케이션을 수동으로 계측하고 있는 경우, SpanKind 속성을 명시적으로 설정해야 합니다. Elastic APM이 스팬을 올바르게 분류하려면, SpanKind(예: INTERNAL, SERVER, CLIENT)를 알아야 합니다. 대부분의 OpenTelemetry APM 자동 계측 라이브러리는 이 필드를 설정합니다. 그러나 애플리케이션을 수동으로 설치 중인 경우, RPC 또는 REST 호출을 허용하는 스팬은 SERVER, RPC 또는 REST 또는 데이터베이스 호출을 시작하는 스팬은 CLIENT, 서비스 내 함수 호출은 INTERNAL(기본값)로 설정해야 합니다. 예를 들어, Java에서 다음과 같은 방법을 사용하여 gRPC 호출을 수신하는 스팬 동안 SpanKind를 SERVER로 설정합니다.

RpcSystem/DbSystem: Elastic APM이 스팬을 올바르게 분류하려면, 스팬이 RPC 트랜잭션인지 데이터베이스 트랜잭션인지, 그리고 사용 중인 RPC 또는 DB 시스템의 유형이 무엇인지 알아야 합니다. 대부분의 OpenTelemetry APM 자동 계측 라이브러리는 이 필드를 설정합니다. 애플리케이션을 수동으로 계측 중인 경우, RpcSystem 또는 DbSystem 범위 속성을 설정해야 합니다. 예를 들어, Rust에서 다음과 같은 방법을 사용하여 gRPC 호출을 수신하는 스팬 동안 RpcSystem을 'grpc'로 설정합니다.

NetPeerHost & NetPeerPort: Elastic APM이 서비스 간의 종속성을 적절하게 매핑하려면, SpanKind가 CLIENT(즉, 발신 gRPC 또는 데이터베이스 호출)로 설정된 경우 NetPeerName 및 NetPeerPort 스팬 속성이 의도된 호출 수신자를 나타내도록 설정되어야 합니다. 일부 OpenTelemetry APM 자동 계측 라이브러리는 이 필드를 설정합니다. 애플리케이션을 수동으로 계측 중인 경우, 이러한 속성을 명시적으로 설정해야 합니다. 예를 들어, JavaScript에서 다음과 같은 방법을 사용하여 gRPC 호출을 보내는 스팬에 NetPeerName 및 NetPeerPort를 설정할 수 있습니다.

로그 속성

Elastic APM은 특정 로그 줄을 특정 추적과 상관시킬 수 있습니다. 이 기능을 활성화하려면, 애플리케이션에서 생성되는 로그 줄을 해당하는 경우 span.id 및 trace.id 키/값 쌍으로 태그 지정해야 합니다. 일부 Elastic APM 에이전트(예: Java 에이전트)는 로깅 템플릿을 자동으로 수정하여 이 컨텍스트의 메타데이터를 추가합니다.

DaemonSet에 OpenTelemetry Collector 배포

OpenTelemetry 데모 및 Elastic의 수정된 OpenTelemetry Helm 차트를 사용하여 작업 중인 경우, 각 노드의 DaemonSet에 최적화된 OpenTelemetry Collector가 이미 설치되어 있습니다.

자체 애플리케이션을 계측 중인 경우, 다음 YAML을 기반으로 클러스터의 노드에 있는 DaemonSet에 OpenTelemetry Collector를 구성하고 배포할 수 있습니다. 예제 구성(ConfigMap을 사용하여 배포됨)은 TCP port 4317(grpc) 및 4318(http)의 애플리케이션에서 OTLP 추적, 메트릭 및 이벤트 데이터를 수집합니다. Collector는 DaemonSet에서 실행되고 있으므로, 노드의 IP를 통해 동일한 노드에서 실행되는 다른 포드로부터 해당 포트에 연결할 수 있습니다. 수신 OTLP 데이터는 k8sattributes 프로세서를 통해 실행되어 container.id를 추가합니다. 수신될 수 있는 모든 로그 데이터를 폐기하고(Elastic Kubernetes 통합을 통해 이 데이터를 얻고 있음을 기억하세요) 추적, 이벤트 및 메트릭을 통해 DaemonSet에서도 실행되는 Elastic APM 통합으로 전달합니다. Elastic APM 통합은 노드의 IP를 통해 연결할 수 있는 port 8200에서 수신 중입니다(Kubernetes 다운워드 API에서 얻은 환경 변수로 여기에 전달됨).

1. 이 예제의 OpenTelemetry Collector 배포 YAML을 다운로드합니다

curl -L -O https://raw.githubusercontent.com/ty-elastic/elastic-otel-k8s/main/collector/otel-collector.yaml 

2. 배포를 위해 적절하게 편집합니다

3. Kubernetes 클러스터에 이를 적용합니다

kubectl apply -f otel-collector.yaml 

검증 및 관찰

이 섹션에서는, 위에서 구성한 Observability 및 보안 데이터가 예상대로 Elasticsearch 클러스터로 들어오고 있는지 확인합니다. 또한 이 연습에서는 Elasticsearch 내에서 사용할 수 있는 일부 기본 제공 Observability 및 보안 대시보드에 대한 간략한 개요를 제공합니다. Elastic의 풍부한 시각화 및 분석 제품을 살펴볼 수 있는 발판으로 활용하시기 바랍니다.

APM 서비스 지도

APM 서비스 지도는 서비스와 서비스 간의 관계를 시각화합니다. 특정 유형의 서비스 오류 및 경보가 이 지도에서 적절히 강조 표시됩니다. 이 지도에서, OpenTelemetry(또는 Elastic의 자체 APM 에이전트)로 계측된 모든 서비스의 상세 보기로 피벗할 수 있습니다.

1. Kibana의 탐색 사이드바에서, [Observability] 아래에서 [APM]을 선택합니다
2. [APM] 아래에서 [서비스 지도]를 선택합니다

APM 서비스

APM 서비스 보기는 지정된 서비스의 개요를 제공합니다. 이 대시보드에서, 추적, 로그 및 관련 인프라 메트릭을 쉽게 드릴다운할 수 있습니다. 과거에는, 이러한 데이터 소스 간의 대략적인 상관 관계를 유지하려면 격리된 Observability 플랫폼에서 타임스탬프와 서비스 식별자를 수동으로 변환해야 했습니다. Elastic과 OpenTelemetry를 사용하면, 이러한 상관 관계가 자동으로 발생하므로 분석가, 운영자 및 개발자는 Observability 도구의 뉘앙스보다는 근본 원인 분석에 집중할 수 있습니다.

1. Kibana의 탐색 사이드바에서, [Observability] 아래에서 [APM]을 선택합니다
2. [APM] 아래에서 [서비스 지도]를 선택합니다
3. 지도에서 서비스를 마우스 오른쪽 버튼으로 클릭합니다
4. [서비스 세부 정보]를 선택합니다

이러한 동일한 보기에서, 사용자를 서비스에 연결하고 서비스를 서로 연결하는 트랜잭션 및 스팬의 검토를 쉽게 피벗할 수 있습니다.

1. 헤더에서 [트랜잭션]을 선택합니다
2. [트랜잭션] 하위 섹션에서 관심 있는 트랜잭션을 선택합니다

Kubernetes 클러스터 메트릭

Elastic Kubernetes 대시보드는 Kubernetes 클러스터의 작동에 대한 개요와 세부 정보를 모두 제공합니다. 내부에서 클러스터, 노드, 포드, DaemonSet, 서비스 등의 메트릭을 모니터링할 수 있습니다.

1. Kibana의 탐색 사이드바에서, [분석] 아래에서 [대시보드]를 선택합니다
2. [태그] 메뉴에서 [Kubernetes]를 선택합니다
3. [클러스터 개요] 대시보드를 선택합니다

Kubernetes 프로세스 모니터링

Elastic Defend 통합은 Kubernetes 리소스 전반에 걸쳐 보안 중심의 Observability 기능을 제공합니다. 분석가는 Kubernetes 보안 대시보드를 사용하여 Kubernetes 노드에서 실행된 프로세스의 내용, 실행 시간, 런타임 매개 변수 내용 및 해당 계정을 정확하게 파악할 수 있습니다.

1. Kibana의 탐색 사이드바에서, [보안] 아래에서 [대시보드]를 선택합니다
2. [Kubernetes]를 선택합니다

Kubernetes 보안 태세 관리

Kubernetes 보안 태세 관리(KSPM) 대시보드는 안전한 배포를 위한 다양한 Kubernetes 모범 사례에 걸쳐 자동 분석 및 문제 해결 권장 사항을 제공합니다. 개발자와 DevOps 담당자의 경우, 이 대시보드를 통해 잠재적인 구성 문제가 프로덕션에서 문제가 되기 전에 이에 대한 귀중한 통보를 제공할 수 있습니다.

1. Kibana의 탐색 사이드바에서, [보안] 아래에서 [대시보드]를 선택합니다
2. [클라우드 태세]를 선택합니다

네트워크 트래픽 분석

네트워크 패킷 캡처 통합을 통해 Kubernetes 노드로 들어오고 나가는 IP 트래픽을 자세히 조사하여 제대로 작동하지 않는 서비스나 보안 위반을 찾을 수 있습니다.

1. Kibana의 탐색 사이드바에서, [보안] 아래에서 [탐색]을 선택합니다
2. [네트워크]를 선택합니다

Elastic: Kubernetes를 위해 구축된 Observability 및 보안!

Kubernetes는 많은 기업을 위한 그린필드 애플리케이션 배포 모델입니다. 그린필드 배포 모델에는 Observability와 보안에 대해 똑같이 개방적이고 현대적이며 전체적인 접근 방식이 필요합니다. 여기에 나와 있는 것처럼, Elastic 플랫폼은 업계에서 유일하게 Kubernetes를 위한 완전한 통합, 완전한 기능 및 완전한 충실도의 Observability와 보안을 제공합니다.

관심이 있으신가요? Elastic과 함께 구축을 시작하려면 프리세일즈 팀에 문의해 주세요!