네트워크 관찰 기능


OpenShift Container Platform 4.21

OpenShift Container Platform에서 Network Observability Operator 구성 및 사용

초록

Network Observability Operator를 사용하여 OpenShift Container Platform 클러스터의 네트워크 트래픽 흐름을 관찰하고 분석합니다.

1장. Network Observability Operator 릴리스 노트

Network Observability Operator의 새로운 기능, 보안 권고, 수정된 문제 및 알려진 문제에 대한 정보를 찾고 OpenShift Container Platform Operator의 최신 버전의 변경 및 성능 개선 사항에 대해 알아보십시오.

Network Observability Operator를 사용하면 관리자가 OpenShift Container Platform 클러스터의 네트워크 트래픽 흐름을 관찰하고 분석할 수 있습니다.

이 릴리스 노트에서는 OpenShift Container Platform의 Network Observability Operator의 개발을 추적합니다.

1.1. Network Observability Operator 1.11.2 권고

Network Observability Operator 1.11.2 릴리스에 대한 권고를 검토할 수 있습니다.

1.2. Network Observability Operator 1.11.1 권고

Network Observability Operator 1.11.1 릴리스에 대한 권고를 검토할 수 있습니다.

1.3. Network Observability Operator 1.11.1 문제 해결

Network Observability Operator 1.11.1 릴리스에는 eBPF 에이전트 성능 및 OpenShift Container Platform 웹 콘솔의 사용자 환경을 개선하는 몇 가지 수정된 문제가 포함되어 있습니다.

eBPF 에이전트 메모리 사용 최적화

이번 업데이트 이전에는 eBPF 에이전트의 회귀 문제로 인해 비활성화된 기능에 대해 커널 메모리가 의도치 않게 예약되었습니다. 이로 인해 에이전트에 대한 메모리 사용량보다 많은 메모리 사용량이 증가했습니다.

이번 업데이트를 통해 eBPF 에이전트는 기능이 비활성화될 때 예약된 커널 메모리가 최소로 유지되도록 합니다. 결과적으로 에이전트의 메모리 공간이 줄어들고 리소스 할당이 향상됩니다.

NETOBSERV-2656

Prometheus 전용 모드에서 DNS 그래프 가용성 개선

이번 업데이트 이전에는 Loki가 비활성화되고 DNS 추적이 활성화되면 OpenShift Container Platform 콘솔 플러그인에서 DNS 그래프를 표시하지 못했습니다. 대신 유효한 Prometheus 데이터가 있는 그래프에도 Prometheus 지표를 사용하여 요청을 수행할 수 없다는 오류가 표시되었습니다.

이번 업데이트를 통해 구성된 메트릭이 없는 특정 그래프에만 오류가 표시됩니다. 결과적으로 모든 유효한 DNS 그래프가 이제 웹 콘솔에 올바르게 표시됩니다.

NETOBSERV-2621

토폴로지 보기에서 오류 처리 개선

이번 업데이트 이전에는 Loki가 없는 설치에서 Topology 뷰에 특정 쿼리로 인해 누락된 Prometheus 지표로 인해 오류가 발생할 수 있었습니다. 이러한 오류는 브라우저 캐시를 삭제할 때까지 유지되는 경우가 있습니다.

이번 업데이트를 통해 콘솔에서 누락된 메트릭으로 인한 잘못된 범위가 표시되지 않습니다. 또한 콘솔의 오류 처리가 업데이트되어 더 많은 실행 가능한 정보를 제공하도록 업데이트되어 이러한 시나리오에서 수동 캐시 지우기가 필요하지 않습니다.

NETOBSERV-2477

1.4. Network Observability Operator 1.11 권고

Network Observability Operator 1.11 릴리스에 대한 권고를 검토할 수 있습니다.

1.5. Network Observability Operator 1.11 새로운 기능 및 개선 사항

FlowCollectorSlice 리소스의 계층 거버넌스, 새로운 서비스 배포 모델 및 상태 규칙의 일반 가용성을 포함하여 Network Observability Operator 1.11 릴리스의 새로운 기능 및 개선 사항에 대해 알아보십시오.

FlowCollectorSlice 리소스를 사용한 테넌트별 계층 거버넌스

이번 릴리스에서는 FlowCollectorSlice API가 도입되어 계층 거버넌스를 지원하므로 프로젝트 관리자가 특정 네임스페이스에 대한 샘플링 및 서브넷 레이블을 독립적으로 관리할 수 있습니다.

이 기능은 글로벌 처리 오버헤드를 줄이고 클러스터 전체 구성 변경 없이 개별 팀에 셀프 서비스 가시성이 필요한 대규모 환경에서 테넌트 자동성을 제공하기 위해 구현되었습니다. 따라서 조직은 중앙 클러스터 제어를 유지하면서 선택적으로 트래픽을 수집하고 데이터 강화 작업을 프로젝트 수준에 위임할 수 있습니다.

FlowCollector 리소스에 대한 새로운 서비스 배포 모델

이번 릴리스에서는 FlowCollector 사용자 지정 리소스에 새로운 서비스 배포 모델이 도입되었습니다. 이 모델은 DirectKafka 모델 간의 중간 옵션을 제공합니다. 서비스 모델에서 eBPF 에이전트는 데몬 세트로 배포되고 flowlogs-pipeline 구성 요소는 확장 가능한 서비스로 배포됩니다.

이 모델은 구성 요소 인스턴스의 캐시 중복을 줄임으로써 대규모 클러스터에서 성능이 향상됩니다.

일반적으로 건강 규칙을 사용할 수 있습니다.

이전 버전에서 기술 프리뷰 기능으로 도입된 상태 경고 기능은 Network Observability Operator 1.11 릴리스에서 상태 규칙으로 완전히 지원됩니다.

중요

네트워크 Observability 상태 규칙은 OpenShift Container Platform 4.16 이상에서 사용할 수 있습니다.

이 eBPF 기반 시스템은 네트워크 메트릭과 인프라 메타데이터의 상관관계를 제공하여 트래픽 급증 또는 대기 시간 추세와 같은 클러스터 상태에 대한 사전 예방적 알림 및 자동화된 인사이트를 제공합니다. 결과적으로 OpenShift Container Platform 웹 콘솔에서 Network Health 대시보드를 사용하여 분류된 경고를 관리하고 임계값을 사용자 지정하고, 시각화 성능을 개선하기 위한 기록 규칙을 생성할 수 있습니다.

네트워크 트래픽 시각화 및 필터링 강화

이번 릴리스에서는 OpenShift Container Platform 웹 콘솔에서 향상된 시각화 및 필터링 도구가 도입되었습니다.

  • 인라인 필터 편집: 필터 입력 필드 내에서 직접 필터 칩을 편집할 수 있습니다. 이번 개선된 기능을 통해 이전에 잘린 긴 필터 값을 수정하기 위한 보다 효율적인 방법을 제공하여 수동으로 값을 복사하고 붙여넣을 필요가 없습니다. 이번 업데이트에서는 저장 필터 기능과 일치하는 인라인 편집 규칙을 채택합니다.
  • 외부 트래픽 빠른 필터: 새로운 빠른 필터를 사용하면 외부 수신 및 송신 트래픽을 적극적으로 모니터링할 수 있습니다. 이번 개선된 기능을 통해 네트워크 관리가 간소화되어 외부 네트워크 통신과 관련된 문제를 신속하게 식별하고 해결할 수 있습니다.
  • 직관적인 리소스 아이콘: OpenShift Container Platform 콘솔은 이제 Kubernetes 종류, 그룹 및 필터에 특정 아이콘을 사용합니다. 이러한 아이콘은 보다 직관적이고 시각적으로 일관된 환경을 제공하여 네트워크 토폴로지를 탐색하고 적용된 필터를 한 눈에 쉽게 식별할 수 있습니다.
DNS 확인 분석

이 릴리스에는 도메인 이름으로 네트워크 흐름 레코드를 보강하기 위해 eBPF 기반 DNS 추적이 포함되어 있습니다.

이 기능은 관리자가 NXDOMAIN 오류와 같은 네트워크 라우팅 실패와 서비스 검색 문제를 즉시 구분할 수 있도록 하여 식별(MTTI)이라는 평균 시간을 줄이기 위해 구현되었습니다.

게이트웨이 API와 통합

이번 릴리스에서는 GatewayClass 리소스가 생성될 때 Network Observability Operator와 Gateway API 간의 자동 통합이 도입되었습니다. 이 기능은 FlowCollector 리소스를 수동으로 구성하지 않고도 클러스터 수신 및 송신 트래픽에 대한 높은 수준의 트래픽을 제공합니다.

중요

OpenShift Container Platform 4.19 이상에서 게이트웨이 API와의 통합을 사용할 수 있습니다.

OpenShift Container Platform 웹 콘솔의 Observe → 네트워크 트래픽 보기에서 네트워크 흐름의 자동 매핑을 확인할 수 있습니다. Owner 열에는 게이트웨이 이름이 표시되고 연결된 게이트웨이 리소스 페이지에 대한 직접 링크가 제공됩니다.

개요 및 토폴로지 보기에서 데이터 복원력 개선

이번 릴리스에서는 일부 백그라운드 쿼리가 실패하더라도 개요토폴로지 보기에 기능 데이터가 계속 표시됩니다. 이번 개선된 기능을 통해 부분적인 서비스 중단 중에 토폴로지 보기의 범위 및 그룹 드롭다운 메뉴에 액세스할 수 있습니다.

또한 개요 페이지에 문제 해결을 지원하기 위해 활성 오류 메시지가 표시되어 모니터링 워크플로를 중단하지 않고 시스템 상태를 보다 효과적으로 파악할 수 있습니다.

알 수 없는 네트워크 흐름 분류 개선

이번 릴리스에서는 알 수 없는 소스의 네트워크 흐름이 외부, 알 수 없는 서비스, 알 수 없는 노드 및 알 수 없는 Pod의 네 가지 그룹으로 분류됩니다.

이번 개선된 기능을 통해 서브넷 레이블을 사용하여 알 수 없는 IP 서브넷을 분리하여 더 명확한 네트워크 토폴로지를 제공합니다. 개선된 가시성은 잠재적인 보안 위협을 식별하는 데 도움이 되며 클러스터 내에서 알 수 없는 요소에 대한 대상 분석을 허용합니다.

새로운 네트워크 Observability 설치를 위한 성능 개선

새 설치를 위해 Network Observability Operator의 기본 성능이 향상되었습니다. cacheActiveTimeout 의 기본값은 5초에서 15초로 증가하며 cacheMaxFlows 값은 더 높은 흐름 볼륨을 수용하기 위해 100,000에서 120,000으로 증가합니다.

중요

이러한 새 기본값은 새 설치에만 적용되며 기존 설치는 현재 구성을 유지합니다.

이러한 변경으로 CPU 부하를 최대 40%까지 줄일 수 있습니다.

LokiStack 상태 모니터링 및 보고 개선

이번 릴리스에서는 Network Observability Operator가 LokiStack 리소스의 상태를 모니터링하고 오류 또는 구성 문제를 보고합니다. Network Observability Operator는 보류 중 또는 실패한 Pod 및 특정 경고 조건을 포함하여 LokiStack 조건을 확인합니다.

이번 개선된 기능을 통해 FlowCollector 상태에서 더 많은 실행 가능한 정보가 제공되어 네트워크 관찰 기능 내에서 LokiStack 구성 요소를 보다 효과적으로 해결할 수 있습니다.

필터 메뉴에서 Loki 인덱싱된 필드에 대한 시각적 표시

이번 릴리스에서는 일부 백그라운드 쿼리가 실패하더라도 개요토폴로지 보기에 기능 데이터가 계속 표시됩니다. 이번 개선된 기능을 통해 부분적인 서비스 중단 중에 토폴로지 보기의 범위 및 그룹 드롭다운 메뉴에 액세스할 수 있습니다.

이번 개선된 기능을 통해 더 빠른 데이터 검색을 위해 인덱싱되는 필드를 표시하여 쿼리 성능이 향상됩니다. 데이터를 필터링할 때 인덱싱된 필드를 사용하면 콘솔 내에서 네트워크 흐름을 검색하고 분석하는 데 필요한 시간이 줄어듭니다.

1.6. Network Observability Operator 1.11 알려진 문제

다음 알려진 문제는 Network Observability Operator 1.11 릴리스에 영향을 미칩니다.

lowVolumeThreshold로 인해 샘플링 속도가 증가할 때 상태 규칙이 트리거되지 않음

높은 샘플링 속도로 인해 볼륨이 lowVolumeThreshold 필터 미만인 경우 네트워크 관찰 기능 경고가 트리거되지 않을 수 있습니다. 이로 인해 평가되거나 표시되는 경고가 줄어듭니다.

이 문제를 해결하려면 샘플링 속도와 일치하도록 lowVolumeThreshold 값을 조정하여 일관된 경고 평가를 보장합니다.

NETOBSERV-2613

Loki가 비활성화된 경우 DNS 메트릭을 사용할 수 없음

"Loki-less" 설치에서 DNSTracking 기능이 활성화되면 DNS 그래프에 필요한 지표를 사용할 수 없습니다. 결과적으로 대시보드에서 DNS 대기 시간 및 응답 코드를 볼 수 없습니다.

이 문제를 해결하려면 spec.loki.enable 을 true로 설정하여 DNSTracking 옵션을 비활성화하거나 FlowCollector 리소스에서 Loki를 활성화해야 합니다.

NETOBSERV-2621

1.7. Network Observability Operator 1.11 문제 해결

Network Observability Operator 1.11 릴리스에는 성능 및 사용자 환경을 개선하는 몇 가지 수정된 문제가 포함되어 있습니다.

차트에서 누락된 날짜

이번 업데이트 이전에는 종속성 변경으로 인해 차트 툴팁 날짜가 의도한 대로 표시되지 않았습니다. 결과적으로 OpenShift Container Platform 웹 콘솔 플러그인의 개요 탭 차트에서 데이터 컨텍스트에 영향을 미치는 날짜 정보가 누락되었습니다.

이번 릴리스에서는 차트 툴팁 날짜 표시가 복원됩니다.

NETOBSERV-2518

확장 후 직접 모드에 대한 경고 메시지가 새로 고쳐지지 않음

이번 업데이트 이전에는 스케일링 후 클러스터 정보가 새로 고쳐지지 않아 변경 사항으로 업데이트되지 않고 대규모 클러스터에서 경고 메시지가 유지되었습니다.

이번 릴리스에서는 변경 시 클러스터 정보가 새로 고쳐 클러스터 크기가 변경되어 사용자 가시성을 개선할 수 있는 직접 모드의 대규모 클러스터에 대한 경고 메시지가 표시됩니다.

NETOBSERV-2494

풍부한 OVN IP

이번 업데이트 이전에는 OVN-Kubernetes에서 선언한 일부 IP가 보강되지 않아 100.64.0.x 와 같은 불충분한 IP가 머신 네트워크에 표시되지 않았습니다. 그 결과 IP가 강화되지 않아 사용자에게 잘못된 네트워크 가시성이 발생했습니다.

이번 릴리스에서는 OVN-Kubernetes에서 누락된 IP가 강화되었습니다. 결과적으로 OVN-Kubernetes에서 선언한 IP는 올바르게 보강되고 머신 네트워크에 표시되고 머신 네트워크의 네트워크 트래픽 소스 가시성이 향상됩니다.

NETOBSERV-2484

Operator API 검색 안정성 개선

이번 업데이트 이전에는 Network Observability Operator 시작 중에 경쟁 조건으로 인해 API 검색이 자동으로 실패할 수 있었습니다. 결과적으로 Operator가 OpenShift Container Platform 클러스터를 인식하지 못하여 필수 ClusterRoleBinding 리소스가 누락되어 구성 요소가 제대로 작동하지 않을 수 있었습니다.

이번 릴리스에서는 Network Observability Operator에서 시간이 지남에 따라 API 가용성을 계속 확인하고 검색에 실패하면 조정이 차단됩니다. 결과적으로 Operator는 환경을 올바르게 식별하고 필요한 모든 역할이 생성되었는지 확인합니다.

NETOBSERV-2574

IPFIX 내보내기에 누락된 변환 필드 추가

이번 업데이트 이전에는 IPFIX 내보내기 프로세스 중에 일부 네트워크 흐름 필드에 번역이 누락되었습니다. 그 결과 내보낸 IPFIX 데이터가 불완전하거나 외부 수집기에서 해석하기 어려웠습니다.

이번 릴리스에서는 flowlogs-pipeline IPFIX 내보내기에 누락된 변환 필드(xlat)가 추가되었습니다. IPFIX 내보내기에서는 일관된 네트워크 관찰 기능을 위해 번역된 전체 필드 세트를 제공합니다.

NETOBSERV-2553

수정된 FlowMetric 양식 생성 링크 및 기본값

이번 업데이트 이전에는 FlowMetric 사용자 정의 리소스를 생성하는 링크가 의도한 양식 뷰 대신 YAML 편집기로 잘못 전달되었습니다. 또한 편집기가 잘못된 기본값으로 미리 입력되었습니다.

이번 릴리스에서는 링크가 예상되는 기본 설정으로 FlowMetric 리소스 생성 양식으로 올바르게 연결됩니다. 결과적으로 사용자 인터페이스를 통해 FlowMetric 리소스를 쉽게 생성할 수 있습니다.

NETOBSERV-2520

토폴로지 보기의 가상 머신 리소스 유형 아이콘

이번 업데이트 이전에는 VM(가상 머신) 소유자 유형에 토폴로지 보기에 일반 물음표(?) 아이콘이 잘못 표시되었습니다.

이번 릴리스에서는 사용자 인터페이스에 이제 VM 리소스에 대한 특정 아이콘이 포함됩니다. 결과적으로 사용자는 네트워크 토폴로지 내에서 VM 트래픽을 보다 쉽게 식별하고 구분할 수 있습니다.

NETOBSERV-2487

DNS 최적화, DNS 경고 업데이트

이번 업데이트 이전에는 네트워크 관찰 기능에서 사용되는 모호한 URL로 인해 많은 DNS "NXDOMAIN" 오류가 반환되었습니다.

이번 릴리스에서는 이러한 URL을 모호하게 하여 DNS를 보다 효과적으로 사용합니다.

NETOBSERV-2485

2장. Network Observability Operator 릴리스 노트 아카이브

2.1. Network Observability Operator 릴리스 노트 아카이브

이 릴리스 노트에서는 OpenShift Container Platform의 Network Observability Operator에 대한 과거 개발을 추적합니다. 이는 참조 목적으로만 사용됩니다.

Network Observability Operator를 사용하면 관리자가 OpenShift Container Platform 클러스터의 네트워크 트래픽 흐름을 관찰하고 분석할 수 있습니다.

2.1.1. Network Observability Operator 1.10.1 권고

Network Observability Operator 1.10.1 릴리스에 대한 권고를 검토할 수 있습니다.

2.1.2. Network Observability Operator 1.10.1 CVE

Network Observability Operator 1.10.1 릴리스의 CVE를 검토할 수 있습니다.

2.1.3. Network Observability Operator 1.10.1 문제 해결

Network Observability Operator 1.10.1 릴리스에는 성능 및 사용자 환경을 개선하는 몇 가지 해결된 문제가 포함되어 있습니다.

15개 노드 초과 클러스터의 직접 모드에 대해 경고 생성

이번 업데이트 이전에는 대규모 클러스터에서 Direct 배포 모델을 사용하기 위한 권장 사항은 문서에서만 사용할 수 있었습니다.

이번 릴리스에서는 15개의 노드를 초과하는 클러스터에서 직접 배포 모드를 사용할 때 Network Observability Operator에서 경고가 생성됩니다.

NETOBSERV-2460

OpenShiftSDN에서 비활성화된 네트워크 정책 배포

이번 업데이트 이전에는 OpenShift SDN이 클러스터 네트워크 플러그인인 경우 FlowCollector 네트워크 정책을 활성화하면 네트워크 관찰 기능 Pod 간 통신이 중단되었습니다. 이 문제는 기본 지원되는 네트워크 플러그인인 OVN-Kubernetes에서는 발생하지 않습니다.

이번 릴리스에서는 OpenShift SDN이 감지될 때 Network Observability Operator가 더 이상 네트워크 정책을 배포하지 않습니다. 대신 경고가 표시됩니다. 또한 네트워크 정책 활성화의 기본값이 수정됩니다. 이제 OVN-Kubernetes가 클러스터 네트워크 플러그인으로 탐지된 경우에만 활성화됩니다.

NETOBSERV-2450

서브넷 레이블 문자에 대한 검증 추가

이번 업데이트 이전에는 서브넷 레이블 "name" 구성에 허용되는 문자에 대한 제한이 없었습니다. 즉, 사용자가 공백 또는 특수 문자가 포함된 텍스트를 입력할 수 있었습니다. 이로 인해 사용자가 필터를 적용하려고 할 때 웹 콘솔 플러그인에서 오류가 발생하고 서브넷 레이블의 필터 아이콘을 클릭하는 경우가 많습니다.

이번 릴리스에서는 FlowCollector 사용자 정의 리소스에서 구성된 경우 구성된 서브넷 레이블 이름이 즉시 검증됩니다. 검증은 이름에 영숫자만 포함되어 있는지 확인합니다. :, _, 및 -. 결과적으로 웹 콘솔 플러그인에서 서브넷 레이블을 필터링하는 것이 예상대로 작동합니다.

NETOBSERV-2438

Network Observability CLI는 실행당 고유한 임시 디렉터리를 사용합니다.

이번 업데이트 이전에는 Network Observability CLI가 현재 작업 디렉터리에 단일 임시(tmp) 디렉터리를 생성하거나 재사용합니다. 이로 인해 별도의 실행 간의 충돌 또는 데이터 손상이 발생할 수 있습니다.

이번 릴리스에서는 Network Observability CLI에서 각 실행에 대해 고유한 임시 디렉터리를 생성하여 잠재적인 충돌을 방지하고 파일 관리 하이퍼바이저를 개선합니다.

NETOBSERV-2481

2.1.4. Network Observability Operator 1.10 권고

Network Observability Operator 1.10 릴리스에 대한 권고를 검토할 수 있습니다.

2.1.5. Network Observability Operator 1.10 새로운 기능 및 개선 사항

Network Observability Operator 1.10 릴리스는 보안을 강화하고 성능을 개선하고 새로운 CLI UI 툴을 도입하여 네트워크 흐름 관리를 개선합니다.

2.1.5.1. 네트워크 정책 업데이트

Network Observability Operator는 이제 Pod 트래픽을 제어하기 위해 수신 및 송신 네트워크 정책 구성을 지원합니다. 이러한 개선은 보안을 강화합니다.

기본적으로 spec.NetworkPolicy.enable 사양이 true 로 설정됩니다. 즉 Loki 또는 Kafka를 사용하는 경우 Loki Operator 및 Kafka 인스턴스를 전용 네임스페이스에 배포하는 것이 좋습니다. 이렇게 하면 모든 구성 요소 간 통신을 허용하도록 네트워크 정책을 올바르게 구성할 수 있습니다.

2.1.5.2. Network Observability Operator CLI UI 업데이트

이번 릴리스에서는 다음과 같은 새로운 기능 및 업데이트를 Network Observability Operator CLI(oc netobserv) 사용자 인터페이스(UI)에 제공합니다.

테이블 보기 개선 사항

  • 사용자 지정 가능한 열: 열 관리를 클릭하여 표시할 열을 선택하고 필요에 맞게 테이블을 조정합니다.Customizing columns: click Manage Columns to select which columns to display, and tailor the table to your needs.
  • 스마트 필터링: 이제 라이브 필터에 자동 제안이 포함되어 올바른 키와 값을 더 쉽게 선택할 수 있습니다.
  • 패킷 프리뷰: 패킷을 캡처할 때 행을 클릭하여 pcap 콘텐츠를 직접 검사합니다.

터미널 기반 라인 차트 기능 개선

  • 메트릭 시각화: 실시간 그래프는 CLI에서 직접 렌더링됩니다.
  • 패널 선택: 사전 정의된 보기에서 선택하거나 패널 관리 팝업 메뉴를 사용하여 특정 메트릭의 차트를 선택적으로 확인하여 보기를 사용자 지정합니다.
2.1.5.3. 네트워크 관찰 콘솔 개선 사항

네트워크 관찰 콘솔 플러그인에는 FlowCollector CR(사용자 정의 리소스)을 구성하는 새 보기가 포함되어 있습니다. 이 보기에서 다음 작업을 완료할 수 있습니다.

  • FlowCollector CR을 구성합니다.
  • 리소스 공간 계산.
  • 구성 경고 또는 높은 메트릭 카디널리티와 같은 문제가 증가했습니다.
2.1.5.4. 성능 개선

Network Observability Operator 1.10은 특히 대규모 클러스터에서 볼 수 있는 Operator의 성능 및 메모리 공간을 개선했습니다.

2.1.6. Network Observability Operator 1.10 기술 프리뷰 기능

Network Observability Operator 1.10 릴리스의 기술 프리뷰 기능을 검토할 수 있습니다.

2.1.6.1. Network Observability Operator 사용자 정의 경고 (기술 프리뷰)

이번 릴리스에서는 새로운 경고 기능 및 사용자 지정 경고 구성이 도입되었습니다. 이러한 기능은 기술 프리뷰 기능이며 명시적으로 활성화해야 합니다.

새 경고를 보려면 OpenShift Container Platform 웹 콘솔에서 모니터링 → 경고경고 규칙을 클릭합니다.

2.1.6.2. Network Observability Operator Network Health Dashboard (기술 프리뷰)

Network Observability Operator에서 기술 프리뷰 경고 기능을 활성화하면 Observe 를 클릭하여 OpenShift Container Platform 웹 콘솔에서 새 Network Health 대시보드를 볼 수 있습니다.

네트워크 상태 대시보드는 위험, 경고 및 마이너 문제를 구분하여 트리거된 경고에 대한 요약을 제공하며 보류 중인 경고도 표시합니다.

2.1.7. Network Observability Operator 1.10의 제거된 기능

Network Observability Operator 1.10 릴리스의 사용에 영향을 줄 수 있는 제거된 기능을 검토하십시오.

2.1.7.1. FlowCollector API 버전 v1beta1이 제거되었습니다.

FlowCollector CR(사용자 정의 리소스) API 버전 v1beta1 이 제거되었으며 더 이상 지원되지 않습니다. v1beta2 버전을 사용합니다.

2.1.8. Network Observability Operator 1.10 알려진 문제

Network Observability Operator 1.10 릴리스 사용에 영향을 미칠 수 있는 다음 알려진 문제와 권장 해결 방법(사용 가능한 경우)을 검토하십시오.

OpenShift Container Platform 4.14 및 이전 버전에서 Network Observability Operator 1.10으로 업그레이드하면 소프트웨어 카탈로그의 FlowCollector CRD(사용자 정의 리소스 정의) 검증 오류로 인해 실패할 수 있습니다.

이 문제를 해결하려면 다음을 수행해야 합니다.

  1. OpenShift Container Platform 웹 콘솔의 소프트웨어 카탈로그에서 Network Observability Operator의 두 버전을 모두 설치 제거합니다.

    1. 흐름 수집 프로세스가 중단되지 않도록 FlowCollector CRD를 계속 설치합니다.
  2. 다음 명령을 실행하여 FlowCollector CRD의 현재 이름을 확인합니다.

    $ oc get crd flowcollectors.flows.netobserv.io -o jsonpath='{.spec.versions[0].name}'

    예상 출력:

    v1beta1
  3. 다음 명령을 실행하여 FlowCollector CRD의 현재 제공 상태를 확인합니다.

    $ oc get crd flowcollectors.flows.netobserv.io -o jsonpath='{.spec.versions[0].served}'

    예상 출력:

    true
  4. 다음 명령을 실행하여 v1beta1 버전에 대해 제공된 플래그를 false 로 설정합니다.

    $ oc patch crd flowcollectors.flows.netobserv.io --type='json' -p "[{'op': 'replace', 'path': '/spec/versions/0/served', 'value': false}]"
  5. 다음 명령을 실행하여 제공된 플래그가 false 로 설정되어 있는지 확인합니다.

    $ oc get crd flowcollectors.flows.netobserv.io -o jsonpath='{.spec.versions[0].served}'

    예상 출력:

    false
  6. Network Observability Operator 1.10을 설치합니다.

OCPBUGS-63208, NETOBSERV-2451

2.1.8.2. eBPF 에이전트 이전 OpenShift Container Platform 버전과의 호환성

CLI(Network Observability Command Line Interface) 패킷 캡처 기능에 사용된 eBPF 에이전트는 OpenShift Container Platform 버전 4.16 이상과 호환되지 않습니다.

이러한 제한으로 인해 eBPF 기반 패킷 캡처 에이전트(PCA)가 이전 클러스터에서 올바르게 작동하지 않습니다.

이 문제를 해결하려면 호환되는 이전 eBPF 에이전트 컨테이너 이미지를 사용하도록 PCA를 수동으로 구성해야 합니다. 자세한 내용은 Network Observability CLI 1.10+의 이전 Openshift 버전과의 Red Hat Knowledgebase 솔루션 eBPF 에이전트 호환성 을 참조하십시오.

NETOBSERV-2358

OpenShiftSDN CNI 플러그인을 사용하는 OpenShift Container Platform 4.14 클러스터에서 Network Observability Operator 1.10을 실행하는 경우 eBPF 에이전트는 flowlogs-pipeline 구성 요소에 흐름 레코드를 보낼 수 없습니다. 이는 NetworkPolicy 를 사용하여 FlowCollector 사용자 정의 리소스가 생성될 때 발생합니다(spec.networkPolicy.enable: true).

결과적으로 흐름 데이터는 flowlogs-pipeline 구성 요소에서 처리되지 않으며 네트워크 트래픽 대시보드 또는 구성된 스토리지(Loki)에 표시되지 않습니다. eBPF 에이전트 Pod 로그에 수집기에 연결을 시도할 때 i/o 시간 초과 오류가 표시됩니다.

time="2025-10-17T13:53:44Z" level=error msg="couldn't send flow records to collector" collector="10.0.68.187:2055" component=exporter/GRPCProto error="rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing: dial tcp 10.0.68.187:2055: i/o timeout\""

이 문제를 해결하려면 spec.networkPolicy.enablefalse 로 설정하여 Network Observability Operator 1.10의 FlowCollector 리소스에서 NetworkPolicy 를 비활성화합니다.

그러면 eBPF 에이전트가 자동으로 배포된 네트워크 정책의 간섭 없이 flowlogs-pipeline 구성 요소와 통신할 수 있습니다.

NETOBSERV-2450

2.1.9. Network Observability Operator 1.10 문제 해결

Network Observability Operator 1.10 릴리스에는 성능 및 사용자 환경을 개선하는 몇 가지 수정된 문제가 포함되어 있습니다.

2.1.9.1. MetricName 및 Remap 필드의 유효성 검사

이번 업데이트 이전에는 잘못된 메트릭 이름으로 FlowMetric CR(사용자 정의 리소스)을 생성할 수 있었습니다. FlowMetric CR이 성공적으로 생성되었지만 사용자에게 오류 피드백을 제공하지 않고 기본 메트릭이 자동으로 실패합니다.

이번 릴리스에서는 생성 전에 FlowMetric,metricName, remap 필드의 유효성이 검사되므로 사용자는 잘못된 이름을 입력하면 즉시 알림을 받습니다.

NETOBSERV-2348

2.1.9.2. html-to-image 내보내기 성능 개선

이번 업데이트 이전에는 기본 라이브러리의 성능 문제로 인해 html-to-image 내보내기 기능이 오랜 시간이 소요되어 브라우저 정지가 발생했습니다.

이번 릴리스에서는 html-to-image 라이브러리의 성능이 개선되어 내보내기 대기 시간을 줄이고 이미지 생성 중에 브라우저 정지를 제거합니다.

NETOBSERV-2314

2.1.9.3. eBPF 권한 모드에 대한 경고 개선

이번 업데이트 이전에는 권한이 있는 모드가 필요한 eBPF 기능을 선택한 경우 사용자에게 권한 있는 모드가 없거나 활성화되어야 함을 명확히 알리지 않고 기능이 실패하는 경우가 많습니다.

이번 릴리스에서는 구성이 일치하지 않는 경우 검증 후크가 사용자에게 즉시 경고합니다. 이렇게 하면 사용자 이해가 향상되고 잘못된 구성이 발생하지 않습니다.

NETOBSERV-2268

2.1.9.4. OpenTelemetry 내보내기에 서브넷 레이블 추가

이번 업데이트 이전에는 OpenTelemetry 메트릭 내보내기에 네트워크 흐름 라벨 SrcSubnetLabelDstSubnetLabel 이 누락되어 빈 것으로 표시되었습니다.

이번 릴리스에서는 내보내기에서 이러한 레이블을 올바르게 제공합니다. 또한 OpenTelemetry 표준의 명확성과 일관성을 개선하기 위해 source.subnet.labeldestination.subnet.label 로 이름이 변경되었습니다.

NETOBSERV-2405

2.1.9.5. 네트워크 관찰 기능 구성 요소의 기본 허용 오차 감소

이번 업데이트 이전에는 NoSchedule.를 사용하여 테인트를 포함하여 모든 노드에서 예약할 수 있도록 모든 네트워크 관찰 구성 요소에 기본 허용 오차가 설정되었습니다. 이로 인해 클러스터 업그레이드가 차단될 수 있습니다.

이번 릴리스에서는 이제 직접 모드로 구성된 경우 eBPF 에이전트 및 Flowlogs-Pipeline 에만 기본 허용 오차가 유지 관리됩니다. Kafka 모드에서 구성할 때 OpenShift Container Platform 웹 콘솔 플러그인과 Flowlogs-Pipeline 에서 허용 오차가 제거되었습니다.

또한 FlowCollector CR(사용자 정의 리소스)에서 허용 오차를 항상 구성할 수 있었지만 이전에는 허용 오차를 빈 목록으로 교체할 수 없었습니다. 이제 허용 오차를 빈 목록으로 교체할 수 있습니다.

NETOBSERV-2434

2.1.10. Network Observability Operator 1.9.3 권고

Network Observability Operator 1.9.3 릴리스에 대한 권고를 검토할 수 있습니다.

2.1.11. Network Observability Operator 1.9.2 권고

Network Observability Operator 1.9.2 릴리스에 대한 권고를 검토할 수 있습니다.

2.1.12. Network observability 1.9.2 버그 수정

Network Observability Operator 1.9.1 릴리스의 수정된 문제를 검토할 수 있습니다.

  • 이번 업데이트 이전에는 OpenShift Container Platform 버전 4.15 및 이전 버전에서 TC_ATTACH_MODE 구성을 지원하지 않았습니다. 이로 인해 CLI(명령줄 인터페이스) 오류가 발생하여 패킷 및 흐름을 관찰할 수 없었습니다. 이번 릴리스에서는 이전 버전에 대해 TCX( Traffic Control eXtension) 후크 연결 모드가 조정되었습니다. 이렇게 하면 tcx 후크 오류가 제거되고 흐름 및 패킷 관찰이 활성화됩니다.

2.1.13. Network Observability Operator 1.9.1 권고

Network Observability Operator 1.9.1 릴리스에 대한 권고를 검토할 수 있습니다.

Network Observability Operator 1.9.1에 대해 다음 권고를 사용할 수 있습니다.

2.1.14. Network Observability Operator 1.9.1 문제 해결

Network Observability Operator 1.9.1 릴리스의 수정된 문제를 검토할 수 있습니다.

  • 이번 업데이트 이전에는 잘못된 연결 모드 설정으로 인해 OpenShift Container Platform 4.15에서 네트워크 흐름이 확인되지 않았습니다. 이로 인해 특히 특정 카탈로그에서 네트워크 흐름을 올바르게 모니터링하는 사용자가 중지되었습니다. 이번 릴리스에서는 4.16.0 이전의 OpenShift Container Platform 버전의 기본 연결 모드가 tc 로 설정되어 있으므로 OpenShift Container Platform 4.15에서 흐름이 관찰됩니다. (NETOBSERV-2333)
  • 이번 업데이트 이전에는 IPFIX 수집기가 다시 시작되면 IPFIX 내보내기를 구성하면 연결이 손실되고 수집기로 네트워크 흐름 전송을 중지할 수 있습니다. 이번 릴리스에서는 연결이 복원되고 네트워크 흐름이 수집기로 계속 전송됩니다. (NETOBSERV-2315)
  • 이번 업데이트 이전에는 IPFIX 내보내기를 구성할 때 포트 정보(예: ICMP 트래픽) 없이 흐름으로 인해 로그에 오류가 발생했습니다. IPFIX 내보내기에서는 TCP 플래그 및 ICMP 데이터도 누락되었습니다. 이번 릴리스에서는 이러한 세부 정보가 포함됩니다. 누락된 필드(예: 포트)는 더 이상 오류가 발생하지 않으며 내보낸 데이터의 일부입니다. (NETOBSERV-2307)
  • 이번 업데이트 이전에는 OpenShift 버전이 코드에 잘못 설정되어 있었기 때문에 UDN(User Defined Networks) 매핑 기능에 OpenShift Container Platform 4.18에 구성 문제 및 경고가 표시되었습니다. 이는 사용자 경험에 영향을 미쳤습니다. 이번 릴리스에서는 UDN 매핑이 경고 없이 OpenShift Container Platform 4.18을 지원하여 사용자 환경을 원활하게 수행할 수 있습니다. (NETOBSERV-2305)
  • 이번 업데이트 이전에는 네트워크 트래픽 페이지의 확장 기능에 OpenShift Container Platform 콘솔 4.19와 호환성 문제가 있었습니다. 이로 인해 확장 및 일관되지 않은 사용자 인터페이스를 확장할 때 메뉴 공간이 비어 있었습니다. 이번 릴리스에서는 NetflowTraffic 부분 및 주제 후크 의 호환성 문제가 해결되었습니다. 이제 네트워크 트래픽 보기의 사이드 메뉴가 올바르게 관리되어 사용자 인터페이스와 상호 작용하는 방식이 개선되었습니다. (NETOBSERV-2304)

2.1.15. Network Observability Operator 1.9.0 권고

Network Observability Operator 1.9.0 릴리스에 대한 권고를 검토할 수 있습니다.

2.1.16. Network Observability Operator 1.9.0 새로운 기능 및 개선 사항

Network Observability Operator 1.9.0 릴리스의 새로운 기능 및 개선 사항을 검토할 수 있습니다.

2.1.16.1. 네트워크 관찰 기능이 있는 사용자 정의 네트워크

이번 릴리스에서는 UDN(사용자 정의 네트워크) 기능을 일반적으로 네트워크 관찰 기능을 사용할 수 있습니다. UDNMapping 기능이 네트워크 관찰 기능에서 활성화되면 트래픽 흐름 테이블에 UDN 레이블 열이 있습니다. 소스 네트워크 이름 및 대상 네트워크 이름 정보에서 로그를 필터링할 수 있습니다.

2.1.16.2. 수집 시 필터 흐름 로그

이번 릴리스에서는 필터를 생성하여 생성된 네트워크 흐름 수와 네트워크 관찰 기능 구성 요소의 리소스 사용량을 줄일 수 있습니다. 다음 필터를 구성할 수 있습니다.

  • eBPF 에이전트 필터
  • FlowLogs-pipeline 필터
2.1.16.3. IPsec 지원

이번 업데이트에서는 OpenShift Container Platform에서 IPsec이 활성화된 경우 네트워크 관찰 기능에 다음과 같은 향상된 기능이 제공됩니다.

  • IPsec Status 라는 새 열이 네트워크 관찰 기능 트래픽 흐름 뷰에 표시되어 흐름이 IPsec 암호화되었는지 또는 암호화/암호 해독 중에 오류가 있는지 여부를 표시합니다.
  • 암호화된 트래픽의 백분율을 보여주는 새 대시보드가 생성됩니다.
2.1.16.4. Network Observability CLI

이제 패킷, 흐름 및 메트릭 캡처에 다음 필터링 옵션을 사용할 수 있습니다.

  • --sampling 옵션을 사용하여 샘플링되는 패킷의 비율을 구성합니다.
  • --query 옵션을 사용하여 사용자 정의 쿼리를 사용하여 흐름을 필터링합니다.
  • --interfaces 옵션을 사용하여 모니터링할 인터페이스를 지정합니다.
  • --exclude_interfaces 옵션을 사용하여 제외할 인터페이스를 지정합니다.
  • --include_list 옵션을 사용하여 생성할 메트릭 이름을 지정합니다.

자세한 내용은 다음을 참조하세요.

2.1.17. Network Observability Operator 릴리스 노트 1.9.0 주요 기술 변경 사항

Network Observability Operator 1.6.0 릴리스에 대한 주요 기술 변경 사항을 검토할 수 있습니다.

  • 네트워크 관찰 기능 1.9의 NetworkEvents 기능이 OpenShift Container Platform 4.19의 최신 Linux 커널에서 작동하도록 업데이트되었습니다. 이번 업데이트에서는 이전 커널과의 호환성이 중단됩니다. 결과적으로 NetworkEvents 기능은 OpenShift Container Platform 4.19에서만 사용할 수 있습니다. 네트워크 관찰 기능 1.8 및 OpenShift Container Platform 4.18과 함께 이 기능을 사용하는 경우 네트워크 관찰 기능 업그레이드를 방지하거나 네트워크 관찰 기능 1.9 및 OpenShift Container Platform을 4.19로 업그레이드하지 않는 것이 좋습니다.
  • netobserv-reader 클러스터 역할의 이름이 netobserv-loki-reader 로 변경되었습니다.
  • eBPF 에이전트의 CPU 성능 향상.

2.1.18. Network Observability Operator 1.9.0 기술 프리뷰 기능

Network Observability Operator 1.9.0 릴리스의 기술 프리뷰 기능을 검토할 수 있습니다.

이 릴리스의 일부 기능은 현재 기술 프리뷰 단계에 있습니다. 이러한 실험적 기능은 프로덕션용이 아닙니다. 해당 기능은 Red Hat Customer Portal의 지원 범위를 참조하십시오.

기술 프리뷰 기능 지원 범위

2.1.18.1. 네트워크 관찰 기능이 있는 eBPF Manager Operator

eBPF Manager Operator는 모든 eBPF 프로그램을 관리하여 공격 면적을 줄이고 규정 준수, 보안 및 충돌 방지를 보장합니다. Network observability는 eBPF Manager Operator를 사용하여 후크를 로드할 수 있습니다. 이를 통해 eBPF 에이전트에 권한 있는 모드 또는 CAP_BPFCAP_PERFMON 과 같은 추가 Linux 기능을 제공할 필요가 없습니다. 네트워크 관찰 기능이 있는 eBPF Manager Operator는 64비트 AMD 아키텍처에서만 지원됩니다.

2.1.19. Network Observability Operator 1.9.0 CVE

Network Observability Operator 1.9.0 릴리스의 CVE를 검토할 수 있습니다.

2.1.20. Network Observability Operator 1.9.0 문제 해결

Network Observability Operator 1.9.0 릴리스의 수정된 문제를 검토할 수 있습니다.

  • 이전 버전에서는 콘솔 플러그인에서 소스 또는 대상 IP로 필터링할 때 10.128.0.0/24 와 같은 CIDR(Classless Inter-Domain Routing) 표기법을 사용하여 필터링해야 하는 결과를 반환했습니다. 이번 업데이트를 통해 CIDR 표기법을 사용할 수 있으며 결과가 예상대로 필터링됩니다. (NETOBSERV-2276)
  • 이전에는 네트워크 흐름에서 eth0ens5 를 혼합할 위험이 있어 사용 중인 네트워크 인터페이스를 잘못 식별할 수 있었습니다. 이 문제는 eBPF 에이전트가 Privileged 로 구성된 경우에만 발생했습니다. 이번 업데이트를 통해 부분적으로 수정되었으며 거의 모든 네트워크 인터페이스가 올바르게 식별됩니다. 자세한 내용은 아래의 알려진 문제를 참조하세요. ( NETOBSERV-2257)
  • 이전 버전에서는 Operator에서 동작을 조정하기 위해 사용 가능한 Kubernetes API를 선택하면 오래된 API가 있는 경우 Operator가 정상적으로 시작되지 않는 오류가 발생했습니다. 이번 업데이트를 통해 Operator는 관련이 없는 API에서 오류를 무시하고 관련 API에 대한 오류를 기록하며 정상적으로 계속 실행됩니다. (NETOBSERV-2240)
  • 이전 버전에서는 사용자가 Console 플러그인의 트래픽 흐름 보기에서 Cryostat 또는 Packets 기준으로 흐름을 정렬할 수 없었습니다. 이 업데이트를 통해 사용자는 BytesPackets 별로 흐름을 정렬할 수 있습니다. (NETOBSERV-2239)
  • 이전에는 IPFIX 내보내기를 사용하여 FlowCollector 리소스를 구성할 때 IPFIX 흐름의 MAC 주소가 첫 번째 바이트 2로 잘랐습니다. 이번 업데이트를 통해 MAC 주소는 IPFIX 흐름에 완전히 표시됩니다. (NETOBSERV-2208)
  • 이전에는 Operator 검증 웹훅에서 보낸 일부 경고에 수행해야 할 작업에 대한 명확한 설명이 부족했습니다. 이번 업데이트를 통해 일부 메시지가 검토되고 수정되어 더욱 실행 가능하게 되었습니다. (NETOBSERV-2178)
  • 이전에는 입력 오류의 경우와 같이 FlowCollector 리소스에서 LokiStack 을 참조할 때 문제가 있음을 파악하지 못했습니다. 이번 업데이트를 통해 FlowCollector 상태는 이러한 경우 참조된 LokiStack 을 찾을 수 없음을 명확하게 표시합니다. (NETOBSERV-2174)
  • 이전 버전에서는 콘솔 플러그인 트래픽 흐름 보기에서 텍스트 오버플로의 경우 텍스트를 표시할 많은 텍스트가 중단되는 경우가 있었습니다. 이번 업데이트를 통해 가능한 한 많은 텍스트가 표시됩니다. (NETOBSERV-2119)
  • 이전에는 네트워크 관찰 기능 1.8.1 및 이전 버전의 콘솔 플러그인이 OpenShift Container Platform 4.19 웹 콘솔에서 작동하지 않아 네트워크 트래픽 페이지에 액세스할 수 없었습니다. 이번 업데이트를 통해 콘솔 플러그인이 호환되며 네트워크 트래픽 페이지는 네트워크 관찰 기능 1.9.0에서 액세스할 수 있습니다. (NETOBSERV-2046)
  • 이전 버전에서는 대화 추적(logTypes: Conversations 또는 logTypes:All in the FlowCollector 리소스에서)을 사용할 때 대시보드에 표시되는 트래픽 비율 지표가 결함이 있어 트래픽의 제어 부족 증가가 잘못 표시되었습니다. 이제 메트릭에 더 정확한 트래픽 속도가 표시됩니다. 그러나 ConversationsEndedConversations 모드에서는 이러한 측정 항목이 오랫동안 지속된 연결을 포함하지 않으므로 여전히 완전히 정확하지는 않습니다. 이 정보가 문서에 추가되었습니다. 이러한 부정확성을 피하기 위해 기본 모드 logTypes: Flows를 사용하는 것이 좋습니다. (NETOBSERV-1955)

2.1.21. Network Observability Operator 1.9.0 알려진 문제

Network Observability Operator 1.9.0 릴리스의 알려진 문제를 검토할 수 있습니다.

  • UDN(사용자 정의 네트워크) 기능은 지원되는 경우에도 OpenShift Container Platform 4.18과 함께 사용할 때 구성 문제와 경고를 표시합니다. 이 경고는 무시할 수 있습니다. (NETOBSERV-2305)
  • 드물지만, 여러 네트워크 네임스페이스가 있는 privileged 모드에서 실행할 때 eBPF 에이전트가 관련 인터페이스와 흐름을 적절하게 연관시키지 못하는 경우가 있습니다. 이러한 문제 중 상당 부분은 이번 릴리스에서 확인되어 해결되었지만, 특히 ens5 인터페이스와 관련하여 일부 불일치 사항은 여전히 남아 있습니다. (NETOBSERV-2287)

2.1.22. Network Observability Operator 1.8.1 권고

Network Observability Operator 1.8.1 릴리스에 대한 권고를 검토할 수 있습니다.

Network Observability Operator 1.8.1

2.1.23. Network Observability Operator 1.8.1 CVE

Network Observability Operator 1.8.1 릴리스의 CVE를 검토할 수 있습니다.

2.1.24. Network Observability Operator 1.8.1 문제 해결

Network Observability Operator 1.8.1 릴리스에 대한 수정된 문제를 검토할 수 있습니다.

  • 이번 수정을 통해 Observe 메뉴가 향후 OpenShift Container Platform 버전에서 한 번만 표시됩니다. (NETOBSERV-2139)

2.1.25. Network Observability Operator 1.8.0 권고

Network Observability Operator 1.8.0 릴리스에 대한 권고를 검토할 수 있습니다.

2.1.26. Network Observability Operator 1.8.0 새로운 기능 및 개선 사항

Network Observability Operator 1.8.0 릴리스의 새로운 기능 및 개선 사항을 검토할 수 있습니다.

2.1.26.1. 패킷 변환

이제 번역된 엔드포인트 정보를 사용하여 네트워크 흐름을 강화하여 서비스뿐만 아니라 특정 백엔드 Pod도 표시할 수 있으므로 요청 시 어떤 Pod를 확인할 수 있습니다.

자세한 내용은 다음을 참조하세요.

2.1.26.2. OVN-Kubernetes 네트워킹 이벤트 추적
중요

OVN-Kubernetes 네트워킹 이벤트 추적은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

이제 네트워크 관찰 기능에서 네트워크 이벤트 추적을 사용하여 네트워크 정책, 관리 네트워크 정책, 송신 방화벽을 포함하여 OVN-Kubernetes 이벤트에 대한 통찰력을 얻을 수 있습니다.

자세한 내용은 다음을 참조하세요.

2.1.26.3. 1.8의 eBPF 성능 개선
  • 네트워크 관찰 기능에서는 CPU당 맵 대신 해시 맵을 사용합니다. 즉, 이제 네트워크 흐름 데이터가 커널 공간에서 추적되고 새 패킷도 집계됩니다. 이제 네트워크 흐름의 중복 제거가 커널에서 발생할 수 있으므로 커널과 사용자 공간 간의 데이터 전송 크기가 향상될 수 있습니다. 이러한 eBPF 성능이 개선됨에 따라 eBPF 에이전트의 40%에서 57% 사이의 CPU 리소스 감소를 확인할 수 있습니다.
2.1.26.4. Network Observability CLI

이 릴리스에 대해 다음과 같은 새로운 기능, 옵션 및 필터가 Network Observability CLI에 추가됩니다.

  • oc netobserv metrics 명령을 실행하여 활성화된 필터를 사용하여 메트릭을 캡처합니다.
  • --background 옵션과 함께 플로우 및 패킷 캡처를 사용하여 백그라운드에서 CLI를 실행하고, oc netobserv follow를 실행하여 백그라운드 실행의 진행 상황을 확인하고, oc netobserv copy를 실행하여 생성된 로그를 다운로드합니다.
  • --get-subnets 옵션을 사용하여 머신, Pod 및 서비스 서브넷을 사용하여 흐름 및 메트릭 캡처를 제공합니다.
  • 패킷, 흐름 및 메트릭 캡처와 함께 사용할 수 있는 새로운 필터링 옵션:

    • IP, 포트, 프로토콜, 동작, TCP 플래그 등에 대한 eBPF 필터
    • --node-selector를 사용하는 사용자 정의 노드
    • drops only using --drops
    • --regexes를 사용하는 모든 필드

자세한 내용은 다음을 참조하세요.

2.1.27. Network Observability Operator 릴리스 노트 1.8.0 문제 해결

Network Observability Operator 1.8.0 릴리스에 대한 수정된 문제를 검토할 수 있습니다.

  • 이전에는 Network Observability Operator에 메트릭 서버의 RBAC를 관리하는 "kube-rbac-proxy" 컨테이너가 제공되었습니다. 이 외부 구성 요소는 더 이상 사용되지 않으므로 제거해야 했습니다. 이제 사이드카 프록시 없이도 Kubernetes controller-runtime을 통해 직접 TLS 및 RBAC 관리로 교체됩니다. (NETOBSERV-1999)
  • 이전 버전에서는 OpenShift Container Platform 콘솔 플러그인에서 여러 값과 일치하지 않은 키를 필터링하면 아무 것도 필터링하지 않았습니다. 이번 수정을 통해 필터링된 값이 없는 모든 흐름인 예상 결과가 반환됩니다. (NETOBSERV-1990)
  • 이전에는 Loki가 비활성화된 OpenShift Container Platform 콘솔 플러그인에서 호환되지 않는 필터 및 집계 세트를 선택했기 때문에 "빌드 쿼리할 수 없음" 오류가 발생했습니다. 이제 이 오류는 사용자가 필터 비호환성을 인식하면서 호환되지 않는 필터를 자동으로 비활성화하여 방지할 수 있습니다. (NETOBSERV-1977)
  • 이전 버전에서는 콘솔 플러그인에서 흐름 세부 정보를 볼 때 ICMP 정보가 항상 측면 패널에 표시되어 비ICMP 흐름에 대한 "정정되지 않은" 값이 표시되었습니다. 이번 수정으로 비ICMP 흐름에 대해 ICMP 정보가 표시되지 않습니다. (NETOBSERV-1969)
  • 이전에는 트래픽 흐름 보기에서 "Export data" 링크가 의도한 대로 작동하지 않아 빈 CSV 보고서가 생성되었습니다. 이제 내보내기 기능이 복원되어 비어 있지 않은 CSV 데이터가 생성됩니다. (NETOBSERV-1958)
  • 이전에는 Loki가 활성화된 경우에만 대화 로그가 유용하더라도 processor.logTypes Conversations,EndedConversations 또는 All with loki.enablefalse 로 설정하여 FlowCollector 를 구성할 수 있었습니다. 이로 인해 리소스 사용량 낭비가 발생했습니다. 이제 이 구성이 유효하지 않으며 검증 Webhook에서 거부됩니다. (NETOBSERV-1957)
  • processor.logTypes모두 로 설정하여 FlowCollector 를 구성하면 다른 옵션보다 CPU, 메모리 및 네트워크 대역폭과 같은 훨씬 더 많은 리소스가 사용됩니다. 이는 이전에 문서화되지 않았습니다. 이제 문서화되어 검증 Webhook에서 경고를 트리거합니다. (NETOBSERV-1956)
  • 이전에는 높은 부하에서 eBPF 에이전트가 생성한 일부 흐름이 실수로 해제되어 트래픽 대역폭이 과소 평가되었습니다. 이제 생성된 흐름이 해제되지 않습니다. (NETOBSERV-1954)
  • 이전에는 FlowCollector 구성에서 네트워크 정책을 활성화할 때 Operator Webhook에 대한 트래픽이 차단되어 FlowMetrics API 유효성 검사가 중단되었습니다. 이제 Webhook에 대한 트래픽이 허용됩니다. (NETOBSERV-1934)
  • 이전 버전에서는 기본 네트워크 정책을 배포할 때 네임스페이스 openshift-consoleopenshift-monitoring추가Namespaces 필드에 기본적으로 설정되어 복제된 규칙이 생성되었습니다. 이제 기본적으로 설정된 추가 네임스페이스가 없으므로 중복되는 규칙을 방지하는 데 도움이 됩니다.(NETOBSERV-1933)
  • 이전에는 OpenShift Container Platform 콘솔 플러그인에서 TCP 플래그 필터링이 원하는 플래그만 있는 흐름과 일치했습니다. 이제 원하는 플래그를 갖는 모든 흐름이 필터링된 흐름에 표시됩니다. (NETOBSERV-1890)
  • eBPF 에이전트가 권한 있는 모드에서 실행되고 Pod가 지속적으로 추가되거나 삭제되면 파일 설명자(FD) 누출이 발생합니다. 이 수정을 통해 네트워크 네임스페이스가 삭제될 때 FD가 올바르게 분류됩니다. (NETOBSERV-2063)
  • 이전에는 CLI 에이전트 DaemonSet 이 마스터 노드에 배포되지 않았습니다. 이제 테인트가 설정된 경우 모든 노드에서 예약할 수 있도록 에이전트 DaemonSet 에 허용 오차가 추가됩니다. 이제 CLI 에이전트 DaemonSet Pod가 모든 노드에서 실행됩니다. (NETOBSERV-2030)
  • 이전에는 Prometheus 스토리지만 사용할 때 Source ResourceSource Destination 필터가 자동 완성되지 않았습니다. 이제 이 문제가 해결되었으며 제안 사항이 예상대로 표시됩니다. (NETOBSERV-1885)
  • 이전에는 토폴로지 보기에 여러 IP를 사용하는 리소스가 별도로 표시되었습니다. 이제 리소스가 뷰의 단일 토폴로지 노드로 표시됩니다. (NETOBSERV-1818)
  • 이전에는 마우스 포인터가 열 위에 있을 때 콘솔이 네트워크 트래픽 테이블 뷰 콘텐츠를 새로 고칩니다. 이제 디스플레이가 고정되어 있으므로 행 높이는 마우스 가리키기와 일정하게 유지됩니다. (NETOBSERV-2049)

2.1.28. Network Observability Operator 릴리스 노트 1.8.0 알려진 문제

Network Observability Operator 1.8.0 릴리스의 알려진 문제를 검토할 수 있습니다.

  • 클러스터에 중복된 서브넷을 사용하는 트래픽이 있는 경우 eBPF 에이전트가 중복된 IP의 흐름을 혼합할 위험이 적습니다. 이는 서로 다른 연결이 정확히 동일한 소스 및 대상 IP가 있고 포트와 프로토콜이 5초 내에 있고 동일한 노드에서 발생하는 경우 발생할 수 있습니다. 보조 네트워크 또는 UDN을 구성하지 않으면 이 작업을 수행할 수 없습니다. 이 경우에도 소스 포트가 일반적으로 좋은 차이점이기 때문에 일반적인 트래픽에서는 여전히 매우 어려울 수 있습니다. (NETOBSERV-2115)
  • OpenShift Container Platform 웹 콘솔 양식 보기의 FlowCollector 리소스 spec.exporters 섹션에 구성할 내보내기 유형을 선택하면 해당 유형에 대한 자세한 구성이 나타나지 않습니다. 해결방법은 YAML을 직접 구성하는 것입니다. (NETOBSERV-1981)

2.1.29. Network Observability Operator 1.7.0 권고

Network Observability Operator 1.7.0 릴리스에 대한 권고를 검토할 수 있습니다.

2.1.30. Network Observability Operator 1.7.0 새로운 기능 및 개선 사항

Network Observability Operator 1.7.0 릴리스의 새로운 기능 및 개선 사항을 검토할 수 있습니다.

2.1.30.1. OpenTelemetry 지원

이제 OpenTelemetry의 Red Hat 빌드와 같은 호환되는 OpenTelemetry 엔드포인트로 보강된 네트워크 흐름을 내보낼 수 있습니다.

자세한 내용은 다음을 참조하세요.

2.1.30.2. 네트워크 관찰 기능 개발자 화면

이제 개발자 화면에서 네트워크 관찰 기능을 사용할 수 있습니다.

자세한 내용은 다음을 참조하세요.

2.1.30.3. TCP 플래그 필터링

이제 tcpFlags 필터를 사용하여 eBPF 프로그램에서 처리하는 패킷의 볼륨을 제한할 수 있습니다.

자세한 내용은 다음을 참조하세요.

2.1.30.4. OpenShift Virtualization의 네트워크 관찰 기능

OVN(Open Virtual Network)-Kubernetes와 같이 보조 네트워크에 연결된 VM에서 제공되는 eBPF가 풍부한 네트워크 흐름을 확인하여 OpenShift Virtualization 설정에서 네트워킹 패턴을 확인할 수 있습니다.

자세한 내용은 다음을 참조하세요.

2.1.30.5. 네트워크 정책은 FlowCollector CR(사용자 정의 리소스)에 배포

이번 릴리스에서는 FlowCollector CR(사용자 정의 리소스)을 구성하여 네트워크 관찰 기능에 대한 네트워크 정책을 배포할 수 있습니다. 이전에는 네트워크 정책이 필요한 경우 수동으로 생성해야 했습니다. 네트워크 정책을 수동으로 생성하는 옵션은 계속 사용할 수 있습니다.

자세한 내용은 다음을 참조하세요.

2.1.30.6. FIPS 컴플라이언스
  • FIPS 모드에서 실행되는 OpenShift Container Platform 클러스터에서 Network Observability Operator를 설치하고 사용할 수 있습니다.

    중요

    클러스터의 FIPS 모드를 활성화하려면 FIPS 모드에서 작동하도록 구성된 RHEL(Red Hat Enterprise Linux) 컴퓨터에서 설치 프로그램을 실행해야 합니다. RHEL에서 FIPS 모드를 구성하는 방법에 대한 자세한 내용은 RHEL을 FIPS 모드로 전환 을 참조하십시오.

    FIPS 모드로 부팅된 Red Hat Enterprise Linux(RHEL) 또는 Red Hat Enterprise Linux CoreOS(RHCOS)를 실행할 때 OpenShift Container Platform 핵심 구성 요소는 x86_64, ppc64le 및 s390x 아키텍처에서만 FIPS 140-2/140-3 검증을 위해 NIST에 제출된 RHEL 암호화 라이브러리를 사용합니다.

2.1.30.7. eBPF 에이전트 개선 사항

eBPF 에이전트에 대해 다음과 같은 향상된 기능을 사용할 수 있습니다.

  • DNS 서비스가 53 이 아닌 다른 포트에 매핑되는 경우 spec.agent.ebpf.advanced.env.DNS_TRACKING_PORT 를 사용하여 이 DNS 추적 포트를 지정할 수 있습니다.
  • 이제 전송 프로토콜(TCP, UDP 또는 SCTP) 필터링 규칙에 두 개의 포트를 사용할 수 있습니다.
  • 이제 protocol 필드를 비워 두어 와일드카드 프로토콜을 사용하여 전송 포트를 필터링할 수 있습니다.

자세한 내용은 다음을 참조하세요.

2.1.30.8. Network Observability CLI

이제 Network Observability CLI(oc netobserv)를 일반적으로 사용할 수 있습니다. 1.6 기술 프리뷰 릴리스 이후 다음과 같은 향상된 기능이 추가되었습니다.

  • 이제 흐름 캡처와 유사한 패킷 캡처를 위한 eBPF 강화 필터가 있습니다.
  • 이제 흐름 및 패킷 캡처와 함께 filter tcp_flags 를 사용할 수 있습니다.
  • max-bytes 또는 max-time에 도달하면 auto-teardown 옵션을 사용할 수 있습니다.

자세한 내용은 다음을 참조하세요.

2.1.31. Network Observability Operator 1.7.0 수정 문제

Network Observability Operator 1.7.0 릴리스에 대한 다음 수정된 문제를 검토할 수 있습니다.

  • 이전에는 RHEL 9.2 실시간 커널을 사용할 때 일부 Webhook가 작동하지 않았습니다. 이제 RHEL 9.2 실시간 커널이 사용 중인지 확인할 수 있는 수정 사항이 적용되어 있습니다. 커널을 사용하는 경우 패킷 드롭과 s390x 아키텍처를 사용할 때 Round-trip Time과 같이 작동하지 않는 기능에 대한 경고가 표시됩니다. 수정 사항은 OpenShift 4.16 이상에서 참조하십시오. (NETOBSERV-1808)
  • 이전에는 개요 탭의 패널 관리 대화 상자에서 ,bar,donut 또는 줄에서 필터링에 결과가 표시되지 않았습니다. 이제 사용 가능한 패널이 올바르게 필터링됩니다. (NETOBSERV-1540)
  • 이전에는 높은 응력 하에서 eBPF 에이전트는 많은 수의 작은 흐름을 생성했으며 거의 집계되지 않은 상태로 전환 할 수 없었습니다. 이번 수정을 통해 집계 프로세스가 여전히 높은 부하에서 유지 관리되어 흐름이 덜 생성됩니다. 이번 수정을 통해 eBPF 에이전트뿐만 아니라 flowlogs-pipeline 및 Loki에서도 리소스 소비가 향상됩니다. (NETOBSERV-1564)
  • 이전 버전에서는 namespace_flows_total 메트릭 대신 workload_flows_total 메트릭을 활성화하면 상태 대시보드가 네임스페이스 흐름 차트로 표시되지 않았습니다. 이번 수정으로 workload_flows_total 이 활성화된 경우 상태 대시보드에 흐름 차트가 표시됩니다. (NETOBSERV-1746)
  • 이전 버전에서는 FlowMetrics API를 사용하여 사용자 지정 지표를 생성하고 나중에 새 레이블을 추가하여 레이블을 수정할 때 지표가 중지되고 error가 flowlogs-pipeline 로그에 표시되었습니다. 이번 수정을 통해 레이블을 수정할 수 있으며 flowlogs-pipeline 로그에서 오류가 더 이상 발생하지 않습니다. (NETOBSERV-1748)
  • 이전에는 기본 Loki WriteBatchSize 구성이 있는 불일치가 있었습니다. 이는 FlowCollector CRD 기본값에서 100KB로 설정되었으며 OLM 샘플 또는 기본 구성에서 10MB로 설정되었습니다. 이제 둘 다 10MB에 맞게 조정되어 일반적으로 더 나은 성능과 리소스 공간을 줄일 수 있습니다. (NETOBSERV-1766)
  • 이전에는 프로토콜을 지정하지 않은 경우 포트의 eBPF 흐름 필터가 무시되었습니다. 이번 수정을 통해 포트 및 또는 프로토콜에 따라 eBPF 흐름 필터를 독립적으로 설정할 수 있습니다. (NETOBSERV-1779)
  • 이전에는 Pod에서 서비스로의 트래픽이 토폴로지 보기에서 숨겨져 있었습니다. 서비스에서 Pod로의 반환 트래픽만 표시되었습니다. 이번 수정으로 해당 트래픽이 올바르게 표시됩니다. (NETOBSERV-1788)
  • 이전에는 네임스페이스와 같이 자동 완료를 트리거한 항목을 필터링하려고 할 때 네트워크 Observability에 액세스할 수 있는 비 클러스터 관리자 사용자가 콘솔 플러그인에서 오류가 발생했습니다. 이번 수정을 통해 오류가 표시되지 않고 자동 완성이 예상되는 결과를 반환합니다. (NETOBSERV-1798)
  • 보조 인터페이스 지원이 추가되면 인터페이스 알림을 확인하려면 네트워크 네임스페이스를 netlink에 등록하기 위해 여러 번 반복해야 했습니다. 동시에 실패한 핸들러로 인해 TCX 후크와 달리 인터페이스가 중단될 때 핸들러를 명시적으로 제거해야 하므로 파일 설명자가 누출되었습니다. 또한 네트워크 네임스페이스가 삭제되면 netlink goroutine 소켓을 종료하는 Go close 채널 이벤트가 없으므로 스레드가 누출되었습니다. 이제 Pod를 생성하거나 삭제할 때 파일 설명자를 유출하거나 스레드를 이동하지 않습니다. (NETOBSERV-1805)
  • 이전에는 흐름 JSON에서 관련 데이터를 사용할 수 있는 경우에도 ICMP 유형과 값이 트래픽 흐름 테이블에 'n/a'를 표시했습니다. 이번 수정으로 ICMP 열에 흐름 테이블에 예상대로 관련 값이 표시됩니다. (NETOBSERV-1806)
  • 이전에는 콘솔 플러그인에서 설정되지 않은 DNS 대기 시간과 같은 설정되지 않은 필드를 필터링할 수 없었습니다. 이번 수정을 통해 설정되지 않은 필드를 필터링할 수 있습니다. (NETOBSERV-1816)
  • 이전 버전에서는 OpenShift 웹 콘솔 플러그인에서 필터를 지우면 다른 페이지로 이동하여 필터가 있는 페이지로 돌아간 후 필터가 다시 발생하는 경우가 있었습니다. 이번 수정을 통해 필터가 지워진 후 예기치 않게 다시 나타나지 않습니다. (NETOBSERV-1733)

2.1.32. Network Observability Operator 1.7.0 알려진 문제

Network Observability Operator 1.7.0 릴리스에 대한 다음 알려진 문제를 검토할 수 있습니다.

  • must-gather 툴을 네트워크 관찰 기능과 함께 사용하면 클러스터에 FIPS가 활성화된 경우 로그가 수집되지 않습니다. (NETOBSERV-1830)
  • netobserv 네임스페이스에 네트워크 정책을 설치하는 FlowCollector 에서 spec.networkPolicy 가 활성화되면 FlowMetrics API를 사용할 수 없습니다. 네트워크 정책 블록은 검증 Webhook에 대한 호출을 차단합니다. 이 문제를 해결하려면 다음 네트워크 정책을 사용하십시오.

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: allow-from-hostnetwork
      namespace: netobserv
    spec:
      podSelector:
        matchLabels:
          app: netobserv-operator
      ingress:
        - from:
            - namespaceSelector:
                matchLabels:
                  policy-group.network.openshift.io/host-network: ''
      policyTypes:
        - Ingress

    (NETOBSERV-193)

2.1.33. Network Observability Operator 릴리스 노트 1.6.2 권고

Network Observability Operator 1.6.2 릴리스에 대한 권고를 검토할 수 있습니다.

2.1.34. Network Observability Operator 릴리스 노트 1.6.2 CVE

Network Observability Operator 1.6.2 릴리스의 CVE를 검토할 수 있습니다.

2.1.35. Network Observability Operator 릴리스 노트 1.6.2 수정 문제

Network Observability Operator 1.6.2 릴리스의 수정된 문제를 검토할 수 있습니다.

  • 보조 인터페이스 지원이 추가되면 인터페이스 알림을 보려면 네트워크 네임스페이스를 netlink에 등록하기 위해 여러 번 반복해야 했습니다. 동시에 실패한 핸들러로 인해 TCX 후크와 달리 인터페이스가 중단될 때 핸들러를 명시적으로 제거해야 하므로 파일 설명자가 누출되었습니다. 이제 Pod를 생성하고 삭제할 때 파일 설명자를 더 이상 유출하지 않습니다. (NETOBSERV-1805)

2.1.36. Network Observability Operator 릴리스 노트 1.6.2 알려진 문제

Network Observability Operator 1.6.2 릴리스의 알려진 문제를 검토할 수 있습니다.

  • 네트워크 관찰 기능이 향후 OpenShift Container Platform 클러스터에 설치되지 않도록 하는 콘솔 플러그인에 호환성 문제가 있었습니다. 1.6.2로 업그레이드하면 호환성 문제가 해결되고 네트워크 관찰 기능을 예상대로 설치할 수 있습니다. (NETOBSERV-1737)

2.1.37. Network Observability Operator 릴리스 노트 1.6.1 권고

Network Observability Operator 1.6.1 릴리스에 대한 권고를 검토할 수 있습니다.

2.1.38. Network Observability Operator 릴리스 노트 1.6.1 CVE

Network Observability Operator 1.6.1 릴리스의 CVE를 검토할 수 있습니다.

2.1.39. Network Observability Operator 릴리스 노트 1.6.1 수정 문제

Network Observability Operator 1.6.1 릴리스에 대한 수정된 문제를 검토할 수 있습니다.

  • 이전 버전에서는 원인 및 TCP 상태와 같은 패킷 드롭에 대한 정보는 Loki 데이터 저장소에서만 사용할 수 있었으며 Prometheus에서는 사용할 수 없었습니다. 이러한 이유로 OpenShift 웹 콘솔 플러그인 개요 의 드롭 통계는 Loki에서만 사용할 수 있었습니다. 이번 수정을 통해 패킷 삭제에 대한 정보도 메트릭에 추가되므로 Loki가 비활성화될 때 삭제 통계를 볼 수 있습니다. (NETOBSERV-1649)
  • eBPF 에이전트 PacketDrop 기능이 활성화되고 샘플링이 1 보다 큰 값으로 구성되면 삭제된 바이트와 삭제된 패킷이 샘플링 구성을 무시했습니다. 이는 목적에 따라 수행되었으며, 드롭 다운을 놓지 않기 위해 수행되었지만 부작용은 non-drops와 비교하여 보고된 드롭의 비율이 유도되었다는 것입니다. 예를 들어 1:1000 과 같은 매우 높은 샘플링 속도로 콘솔 플러그인에서 관찰하면 거의 모든 트래픽이 삭제되는 것처럼 보였습니다. 이번 수정을 통해 드롭된 바이트 및 패킷으로 샘플링 구성이 적용됩니다. (NETOBSERV-1676)
  • 이전에는 인터페이스가 먼저 생성되고 eBPF 에이전트가 배포되었는지 SR-IOV 보조 인터페이스가 탐지되지 않았습니다. 에이전트가 먼저 배포된 후 SR-IOV 인터페이스가 생성된 경우에만 탐지되었습니다. 이번 수정을 통해 배포 순서에 관계없이 SR-IOV 보조 인터페이스가 감지됩니다. (NETOBSERV-1697)
  • 이전 버전에서는 Loki가 비활성화되면 OpenShift 웹 콘솔의 토폴로지 보기에 관련 기능이 활성화되지 않은 경우에도 네트워크 토폴로지 다이어그램 옆에 클러스터영역 집계 옵션이 표시되었습니다. 이번 수정으로 슬라이더는 활성화된 기능에 따라 옵션만 표시합니다. (NETOBSERV-1705)
  • 이전에는 Loki가 비활성화되고 OpenShift 웹 콘솔을 처음 로드할 때 상태 코드 400 Loki를 사용하여 요청이 실패했습니다. 이번 수정을 통해 더 이상 오류가 발생하지 않습니다. (NETOBSERV-1706)
  • 이전 버전에서는 OpenShift 웹 콘솔의 토폴로지 보기에서 그래프 노드 옆에 있는 Step into 아이콘을 클릭하면 선택한 그래프 노드에 중점을 두기 위해 필요에 따라 필터가 적용되지 않아 OpenShift 웹 콘솔에 토폴로지 보기가 표시되었습니다. 이번 수정을 통해 필터가 올바르게 설정되어 토폴로지 가 효과적으로 축소됩니다. 이 변경 사항의 일환으로 이제 노드 에서 단계별 실행 아이콘을 클릭하면 네임스페이스 범위 대신 리소스 범위로 이동합니다. (NETOBSERV-1720)
  • 이전에는 Loki가 비활성화되었을 때 OpenShift 웹 콘솔의 토폴로지 뷰에서 범위소유자 로 설정된 상태에서 그래프 노드 옆에 있는 단계별 실행 아이콘을 클릭하면 범위리소스 로 전환되었습니다. 이는 Loki가 없으면 사용할 수 없으므로 오류 메시지가 표시되었습니다. 이번 수정을 통해 Loki가 비활성화 되면 Owner 범위에서 단계별 아이콘이 숨겨져 있으므로 이 시나리오는 더 이상 발생하지 않습니다. (NETOBSERV-1721)
  • 이전 버전에서는 Loki가 비활성화되면 그룹을 설정할 때 OpenShift 웹 콘솔의 토폴로지 보기에 오류가 표시되었지만 그룹이 유효하지 않도록 범위가 변경되었습니다. 이번 수정을 통해 잘못된 그룹이 제거되어 오류가 발생하지 않습니다. (NETOBSERV-1722)
  • YAML 보기와 달리 OpenShift 웹 콘솔 양식 보기에서 FlowCollector 리소스를 생성할 때 웹 콘솔에서 다음 설정을 잘못 관리했습니다. agent.ebpf.metrics.enableprocessor.subnetLabels.openShiftAutoDetect. 이러한 설정은 양식 보기가 아닌 YAML 보기 에서만 비활성화할 수 있습니다. 혼동을 피하기 위해 양식 보기에서 이러한 설정이 제거되었습니다. YAML 보기에서 계속 액세스할 수 있습니다. (NETOBSERV-1731)
  • 이전에는 eBPF 에이전트가 비정상적인 충돌(예: SIGTERM 신호로 인한 충돌) 전에 설치된 트래픽 제어 흐름을 정리할 수 없었습니다. 이로 인해 이전 항목이 제거되지 않았기 때문에 이름이 동일한 여러 트래픽 제어 흐름 필터가 생성되었습니다. 이번 수정을 통해 에이전트가 시작될 때 새 트래픽을 설치하기 전에 이전에 설치한 모든 트래픽 제어 흐름이 정리됩니다. (NETOBSERV-1732)
  • 이전 버전에서는 사용자 지정 서브넷 레이블을 구성하고 OpenShift 서브넷을 자동으로 감지할 때 OpenShift 서브넷이 사용자 지정 것보다 우선하여 클러스터 서브넷의 사용자 지정 레이블 정의가 없었습니다. 이번 수정을 통해 사용자 정의 정의된 서브넷이 우선하므로 클러스터 서브넷에서 사용자 지정 레이블을 정의할 수 있습니다. (NETOBSERV-1734)

2.1.40. Network Observability Operator 릴리스 노트 1.6.0 권고

Network Observability Operator 1.6.0 릴리스에 대한 권고를 검토할 수 있습니다.

2.1.41. Network Observability Operator 1.6.0 새로운 기능 및 개선 사항

Network Observability Operator 1.6.0의 새로운 기능 및 개선 사항을 검토할 수 있습니다.

2.1.41.1. Loki 없이 Network Observability Operator 사용 개선

이제 Network Observability Operator를 사용할 때 Prometheus 지표를 사용하고 스토리지의 Loki에 더 적게 사용할 수 있습니다.

자세한 내용은 다음을 참조하세요.

2.1.41.2. 사용자 정의 메트릭 API

FlowMetrics API를 사용하여 flowlogs 데이터에서 사용자 지정 메트릭을 생성할 수 있습니다. FlowLogs 데이터는 Prometheus 라벨과 함께 사용하여 대시보드에 대한 클러스터 정보를 사용자 지정할 수 있습니다. 흐름 및 메트릭에서 식별할 모든 서브넷에 대한 사용자 지정 레이블을 추가할 수 있습니다. 이 향상된 기능을 사용하여 흐름 로그와 메트릭 모두에 존재하는 새 라벨 SrcSubnetLabelDstSubnetLabel 을 사용하여 외부 트래픽을 보다 쉽게 식별할 수 있습니다. 이러한 필드는 외부 트래픽이 있을 때 비어 있으므로 이를 식별하는 방법이 제공됩니다.

자세한 내용은 다음을 참조하세요.

2.1.41.3. eBPF 성능 향상

다음과 같은 업데이트로 CPU 및 메모리 측면에서 eBPF 에이전트의 성능이 향상되었습니다.

  • eBPF 에이전트는 이제 TC 대신 TCX Webhook를 사용합니다.
  • NetObserv / Health 대시보드에는 eBPF 메트릭이 표시되는 새 섹션이 있습니다.

    • 새로운 eBPF 메트릭을 기반으로 eBPF 에이전트가 흐름을 삭제하는 경우 경고에 알립니다.
  • Loki 스토리지 수요는 중복된 흐름이 제거되도록 크게 감소합니다. 네트워크 인터페이스당 여러 개별 중복된 흐름을 보유하는 대신 관련 네트워크 인터페이스 목록이 포함된 중복된 하나의 흐름이 있습니다.
중요

중복된 흐름 업데이트를 사용하면 네트워크 트래픽 테이블의 InterfaceInterface Direction 필드가 InterfacesInterface Directions 로 이름이 변경되므로 이러한 필드를 사용하여 북마크된 빠른 필터 쿼리를 인터페이스ifdirections 로 업데이트해야 합니다.

자세한 내용은 다음을 참조하세요.

2.1.41.4. eBPF 컬렉션 규칙 기반 필터링

규칙 기반 필터링을 사용하여 생성된 흐름의 볼륨을 줄일 수 있습니다. 이 옵션이 활성화되면 eBPF 에이전트 통계의 Netobserv / Health 대시보드에는 필터링된 흐름 속도 보기가 있습니다.

자세한 내용은 다음을 참조하세요.

2.1.42. Network Observability Operator 1.6.0 문제 해결

Network Observability Operator 1.6.0의 다음 수정된 문제를 검토할 수 있습니다.

  • 이전 버전에서는 FlowMetrics API 생성의 OLM(Operator Lifecycle Manager) 양식에 대한 종료된 OpenShift Container Platform 설명서의 링크가 표시되었습니다. 이제 유효한 페이지를 가리키도록 링크가 업데이트되었습니다. (NETOBSERV-1607)
  • 이전에는 Operator Hub의 Network Observability Operator 설명에 문서에 대한 손상된 링크가 표시되었습니다. 이번 수정으로 이 링크가 복원됩니다. (NETOBSERV-1544)
  • 이전 버전에서는 Loki가 비활성화되었으며 Loki 모드가 LokiStack 으로 설정되었거나 Loki 수동 TLS 구성이 구성된 경우 Network Observability Operator에서 Loki CA 인증서를 읽으려고 했습니다. 이번 수정을 통해 Loki가 비활성화되면 Loki 구성에 설정이 있더라도 Loki 인증서를 읽지 않습니다. (NETOBSERV-1647)
  • 이전에는 Network Observability Operator의 oc must-gather 플러그인이 amd64 아키텍처에서만 작동했으며, 플러그인이 oc 바이너리에 amd64 를 사용했기 때문에 다른 아키텍처에서만 작동했습니다. 이제 Network Observability Operator oc must-gather 플러그인은 모든 아키텍처 플랫폼에서 로그를 수집합니다.
  • 이전 버전에서는 을 사용하여 IP 주소를 필터링 때 Network Observability Operator에서 요청 오류를 반환했습니다. 이제 IP 필터링은 IP 주소 및 범위에 대해 동일하거나 동일하지 않은 경우 모두에서 작동합니다. (NETOBSERV-1630)
  • 이전에는 사용자가 관리자가 아닌 경우 웹 콘솔에서 네트워크 트래픽 보기의 선택한 탭과 오류 메시지가 일치하지 않았습니다. 이제 개선된 디스플레이가 있는 탭에 사용자가 관리자하지 않음 오류가 표시됩니다.(NETOBSERV-1621)

2.1.43. Network Observability Operator 1.6.0 알려진 문제

Network Observability Operator 1.6.0에 대해 다음과 같은 알려진 문제를 검토할 수 있습니다.

  • eBPF 에이전트 PacketDrop 기능이 활성화되고 샘플링이 1 보다 큰 값으로 구성되면 삭제된 바이트와 드롭된 패킷은 샘플링 구성을 무시합니다. 이는 드롭 다운을 놓지 않기 위한 목적으로 수행되는 반면, 부작용은 비드롭과 비교하여 보고된 드롭율이 유해된다는 것입니다. 예를 들어 1:1000 과 같은 매우 높은 샘플링 속도로 콘솔 플러그인에서 관찰하면 거의 모든 트래픽이 삭제되는 것처럼 보일 수 있습니다. (NETOBSERV-1676)
  • 개요 탭의 패널 관리 창의 ,bar,donut 또는 line 에서 필터링해도 결과가 표시되지 않습니다. (NETOBSERV-1540)
  • SR-IOV 보조 인터페이스는 인터페이스가 먼저 생성되고 eBPF 에이전트가 배포되었는지 감지되지 않습니다. 에이전트가 먼저 배포된 후 SR-IOV 인터페이스가 생성되는 경우에만 탐지됩니다. (NETOBSERV-1697)
  • Loki가 비활성화되면 OpenShift 웹 콘솔의 토폴로지 보기에 관련 기능이 활성화되지 않은 경우에도 네트워크 토폴로지 다이어그램 옆에 있는 클러스터영역 집계 옵션이 항상 표시됩니다. 이러한 슬라이더 옵션을 무시하는 것 외에도 구체적인 해결방법은 없습니다. (NETOBSERV-1705)
  • Loki가 비활성화되고 OpenShift 웹 콘솔을 처음 로드할 때 상태 코드 400 Loki로 인해 Request failed가 비활성화될 수 있습니다. 이 문제를 해결하려면 토폴로지개요 탭을 클릭하는 등 네트워크 트래픽 페이지에서 콘텐츠를 계속 전환할 수 있습니다. 오류가 사라질 것입니다. (NETOBSERV-1706)

2.1.44. Network Observability Operator 1.5.0 권고

Network Observability Operator 1.5 릴리스에 대한 다음 권고를 볼 수 있습니다.

Network Observability Operator 1.5.0

2.1.45. Network Observability Operator 1.5.0 새로운 기능 및 개선 사항

Network Observability Operator 1.5 릴리스의 새로운 기능 및 개선 사항을 볼 수 있습니다.

2.1.45.1. DNS 추적 개선 사항

1.5에서는 이제 UDP 외에도 TCP 프로토콜이 지원됩니다. 새 대시보드는 네트워크 트래픽 페이지의 개요 보기에도 추가됩니다.

자세한 내용은 다음을 참조하세요.

2.1.45.2. Round-trip Time (RTT)

fentry/tcp_rcv_ established ed Extended Berkeley Packet Filter (eBPF) 후크 포인트에서 캡처된 TCP 핸드셰이크 Round-Trip Time(RTT)을 사용하여 원활한 SRTT(Round-trip time)를 읽고 네트워크 흐름을 분석할 수 있습니다. 웹 콘솔의 개요,네트워크 트래픽 및 토폴로지 페이지에서 RTT 메트릭, 필터링 및 에지 레이블을 사용하여 네트워크 트래픽을 모니터링하고 문제를 해결할 수 있습니다.

자세한 내용은 다음을 참조하세요.

2.1.45.3. 메트릭, 대시보드 및 경고 개선

ObserveDashboardsNetObserv 의 네트워크 관찰 메트릭 대시보드에는 Prometheus 경고를 생성하는 데 사용할 수 있는 새로운 메트릭 유형이 있습니다. 이제 includeList 사양에 사용 가능한 메트릭을 정의할 수 있습니다. 이전 릴리스에서는 이러한 지표가 ignoreTags 사양에 정의되어 있습니다.

이러한 메트릭의 전체 목록은 다음을 참조하십시오.

2.1.45.4. Loki 없이 네트워크 관찰 기능 개선

Loki를 사용하지 않는 경우에도 DNS, Packet drop 및 RTT 지표를 사용하여 Netobserv 대시보드에 대한 Prometheus 경고를 생성할 수 있습니다. 이전 버전의 네트워크 관찰 기능 1.4에서는 이러한 메트릭을 Loki 없이 사용할 수 없는 네트워크 트래픽,개요토폴로지 보기의 쿼리 및 분석에만 사용할 수 있었습니다.

자세한 내용은 다음을 참조하세요.

2.1.45.5. 가용성 영역

클러스터 가용성 영역에 대한 정보를 수집하도록 FlowCollector 리소스를 구성할 수 있습니다. 이 구성은 노드에 적용된 topology.kubernetes.io/zone 레이블 값을 사용하여 네트워크 흐름 데이터를 강화합니다.

자세한 내용은 다음을 참조하세요.

2.1.45.6. 주요 개선 사항

Network Observability Operator의 1.5 릴리스는 OpenShift Container Platform 웹 콘솔 플러그인 및 Operator 구성에 개선 사항 및 새로운 기능을 추가합니다.

2.1.45.7. 성능 개선
  • spec.agent.ebpf.kafkaBatchSize 기본값은 Kafka를 사용할 때 eBPF 성능을 개선하기 위해 10MB 에서 1MB 로 변경됩니다.

    중요

    기존 설치에서 업그레이드할 때 이 새 값은 구성에 자동으로 설정되지 않습니다. 업그레이드 후 eBPF 에이전트 메모리 사용을 사용하여 성능 회귀를 모니터링하는 경우 kafkaBatchSize 를 새 값으로 줄이는 것이 좋습니다.

2.1.45.8. 웹 콘솔 개선 사항:
  • DNS 및 RTT에 대한 개요 보기에 새 패널이 추가되었습니다: Min, Max, P90, P99.
  • 새로운 패널 디스플레이 옵션이 추가되었습니다.

    • 하나의 패널에 중점을 두고 다른 패널은 볼 수 있지만 더 작은 집중을 유지합니다.
    • 그래프 유형을 전환합니다.
    • topOverall 을 표시합니다.
  • 컬렉션 대기 시간 경고가 사용자 정의 시간 범위 창에 표시됩니다.
  • 패널 관리열 관리 팝업 창의 내용에 대한 가시성이 향상됩니다.
  • 송신 QoS의 DSCP(Differentiated Services Code Point) 필드는 웹 콘솔 네트워크 트래픽 페이지에서 QoS DSCP를 필터링하는 데 사용할 수 있습니다.
2.1.45.9. 구성 개선 사항:
  • spec.loki.mode 사양의 LokiStack 모드는 URL, TLS, 클러스터 역할 및 클러스터 역할 바인딩과 authToken 값을 자동으로 설정하여 설치를 간소화합니다. 수동 모드를 사용하면 이러한 설정 구성을 보다 효과적으로 제어할 수 있습니다.
  • API 버전은 flows.netobserv.io/v1beta1 에서 flows.netobserv.io/v1beta2 로 변경합니다.

2.1.46. Network Observability Operator 1.5.0 수정 문제

Network Observability Operator 1.5 릴리스에 대한 다음과 같은 수정된 문제를 볼 수 있습니다.

  • 이전에는 콘솔 플러그인의 자동 등록이 비활성화된 경우 웹 콘솔 인터페이스에서 콘솔 플러그인을 수동으로 등록할 수 없었습니다. FlowCollector 리소스에서 spec.console.register 값이 false 로 설정된 경우 Operator는 플러그인 등록을 재정의하고 지웁니다. 이번 수정으로 spec.console.register 값을 false 로 설정하면 콘솔 플러그인 등록 또는 등록 제거에 영향을 미치지 않습니다. 따라서 플러그인을 수동으로 안전하게 등록할 수 있습니다. (NETOBSERV-1134)
  • 이전 버전에서는 기본 메트릭 설정을 사용하여 NetObserv/Health 대시보드에 Flows Overhead 라는 빈 그래프가 표시되었습니다. 이 메트릭은 ignoreTags 목록에서 "namespaces-flows" 및 "namespaces"를 제거하는 경우에만 사용할 수 있었습니다. 이번 수정으로 기본 메트릭 설정을 사용할 때 이 메트릭이 표시됩니다. (NETOBSERV-1351)
  • 이전에는 eBPF 에이전트가 실행 중인 노드가 특정 클러스터 구성으로 확인되지 않았습니다. 이로 인해 일부 트래픽 메트릭을 제공하지 못했기 때문에 계단식 결과가 발생했습니다. 이번 수정을 통해 Operator에서 eBPF 에이전트의 노드 IP를 안전하게 제공하여 Pod 상태에서 유추합니다. 이제 누락된 메트릭이 복원됩니다. (NETOBSERV-1430)
  • 이전에는 Loki Operator에 대한 Loki 오류 '입력 크기 너무 긴' 오류에 문제를 해결하기 위한 추가 정보가 포함되지 않았습니다. 이번 수정을 통해 자세한 지침은 직접 링크와 함께 오류 옆에 웹 콘솔에 도움말이 직접 표시됩니다. (NETOBSERV-1464)
  • 이전에는 콘솔 플러그인 읽기 시간 초과가 30s로 강제되었습니다. FlowCollector v1beta2 API 업데이트를 사용하면 spec.loki.readTimeout 사양을 구성하여 Loki Operator queryTimeout 제한에 따라 이 값을 업데이트할 수 있습니다. (NETOBSERV-1443)
  • 이전에는 Operator 번들에 features.operators.openshift.io/…​ 과 같이 CSV 주석에서 지원되는 일부 기능이 예상대로 표시되지 않았습니다. (NETOBSERV-1305)
  • 이전에는 조정 중에 FlowCollector 상태가 DeploymentInProgressReady 상태 간에 발생하는 경우가 있었습니다. 이번 수정을 통해 모든 기본 구성 요소가 완전히 준비된 경우에만 상태가 Ready 됩니다. (NETOBSERV-1293)

2.1.47. Network Observability Operator 1.5.0 알려진 문제

Network Observability Operator 1.5 릴리스에 대해 다음과 같은 알려진 문제를 볼 수 있습니다.

  • 웹 콘솔에 액세스하려고 할 때 OCP 4.14.10의 캐시 문제로 인해 모니터링 보기에 액세스할 수 없습니다. 웹 콘솔에 오류 메시지가 표시됩니다. Failed to get a valid plugin manifest from /api/plugins/monitoring-plugin/. 권장되는 해결 방법은 클러스터를 최신 마이너 버전으로 업데이트하는 것입니다. 이 방법이 작동하지 않는 경우 이 Red Hat 지식베이스 문서에 설명된 해결 방법을 적용해야 합니다.(NETOBSERV-1493)
  • Network Observability Operator의 1.3.0 릴리스 이후 Operator를 설치하면 경고 커널 테인트가 표시됩니다. 이 오류의 원인은 네트워크 관찰 기능 eBPF 에이전트에 전체 해시맵 테이블의 사전 할당을 방지하는 메모리 제약 조건이 있기 때문입니다. Operator eBPF 에이전트는 해시맵이 너무 많은 경우 사전 할당이 비활성화되도록 BPF_F_NO_PREALLOC 플래그를 설정합니다.

2.1.48. Network Observability Operator 1.4.2 권고

Network Observability Operator 1.4.2에서 다음 권고를 사용할 수 있습니다.

2.1.49. Network Observability Operator 1.4.2 CVE

Network Observability Operator 1.4.2 릴리스에서 다음 CVE를 검토할 수 있습니다.

2.1.50. Network Observability Operator 1.4.1 권고

Network Observability Operator 1.4.1에 대한 다음 권고를 검토할 수 있습니다.

2.1.51. Network Observability Operator 릴리스 1.4.1 CVE

Network Observability Operator 1.4.1 릴리스에서 다음 CVE를 검토할 수 있습니다.

2.1.52. Network Observability Operator 릴리스 노트 1.4.1 수정 문제

Network Observability Operator 1.4.1 릴리스에서 다음의 수정된 문제를 검토할 수 있습니다.

  • 1.4에서는 Kafka로 네트워크 흐름 데이터를 전송할 때 알려진 문제가 있었습니다. Kafka 메시지 키가 무시되어 연결 추적에 오류가 발생했습니다. 이제 키를 분할하는 데 사용되므로 동일한 연결의 각 흐름이 동일한 프로세서로 전송됩니다. (NETOBSERV-926)
  • 1.4에서는 동일한 노드에서 실행되는 포드 간 흐름을 고려하기 위해 Inner 흐름 방향이 도입되었습니다. Inner 방향이 있는 흐름은 흐름에서 파생된 생성된 Prometheus 메트릭에서 고려하지 않아 바이트와 패킷 비율이 거의 발생하지 않았습니다. 이제 파생 메트릭에 Inner 방향이 있는 흐름이 포함되어 올바른 바이트 및 패킷 비율이 제공됩니다. (NETOBSERV-1344)

2.1.53. Network observability 릴리스 노트 1.4.0 권고

Network Observability Operator 1.4.0 릴리스에 대한 다음 권고를 검토할 수 있습니다.

2.1.54. Network observability 릴리스 노트 1.4.0 새로운 기능 및 개선 사항

Network Observability Operator 1.4.0 릴리스에서 다음과 같은 새로운 기능 및 개선 사항을 검토할 수 있습니다.

2.1.54.1. 주요 개선 사항

Network Observability Operator의 1.4 릴리스는 OpenShift Container Platform 웹 콘솔 플러그인 및 Operator 구성에 개선 사항 및 새로운 기능을 추가합니다.

2.1.54.2. 웹 콘솔 개선 사항:
  • 쿼리 옵션에서 중복된 흐름을 표시할지 여부를 선택하기 위해 중복된 흐름 확인란이 추가됩니다.In the Query Options, the Duplicate flows check is added to choose whether or not to show duplicated flows.
  • arrow up long solid One-way, arrow up long solid arrow down long solid Back-and-forth, 스왑 필터를 사용하여 소스 및 대상 트래픽을 필터링할 수 있습니다.
  • ObserveDashboardsNetObservNetObserv / Health 의 네트워크 관찰 기능 지표 대시보드는 다음과 같이 수정됩니다.

    • NetObserv 대시보드에는 노드, 네임스페이스 및 워크로드별로 수신된 상위 바이트, 패킷, 패킷이 표시됩니다. 이 대시보드에서 흐름 그래프가 제거됩니다.
    • NetObserv / Health 대시 보드에는 노드, 네임스페이스 및 워크로드당 최고 흐름률뿐만 아니라 흐름 오버헤드가 표시됩니다.
    • 인프라 및 애플리케이션 메트릭은 네임스페이스 및 워크로드에 대한 분할 보기에 표시됩니다.

자세한 내용은 다음을 참조하세요.

2.1.54.3. 구성 개선 사항:
  • 이제 인증서 구성과 같이 구성된 ConfigMap 또는 Secret 참조에 대해 다른 네임스페이스를 지정하는 옵션이 있습니다.
  • spec.processor.clusterName 매개변수가 추가되어 클러스터 이름이 flows 데이터에 표시됩니다. 이는 다중 클러스터 컨텍스트에서 유용합니다. OpenShift Container Platform을 사용하는 경우 자동으로 결정되도록 비워 둡니다.

자세한 내용은 다음을 참조하세요.

2.1.54.4. Loki가 없는 네트워크 관찰 기능

이제 Network Observability Operator가 Loki 없이 작동하고 사용할 수 있습니다. Loki가 설치되지 않은 경우 KAFKA 또는 IPFIX 형식으로만 내보내기하고 네트워크 관찰 기능 지표 대시보드에 메트릭을 제공할 수 있습니다.

자세한 내용은 다음을 참조하세요.

2.1.54.5. DNS 추적

1.4에서 Network Observability Operator는 eBPF 추적 후크를 사용하여 DNS 추적을 활성화합니다. 웹 콘솔의 네트워크 트래픽개요 페이지에서 네트워크를 모니터링하고 보안 분석을 수행하고 DNS 문제를 해결할 수 있습니다.

자세한 내용은 다음을 참조하세요.

2.1.54.6. SR-IOV 지원

SR-IOV(Single Root I/O Virtualization) 장치를 사용하여 클러스터에서 트래픽을 수집할 수 있습니다.

자세한 내용은 다음을 참조하세요.

2.1.54.7. IPFIX 내보내기 지원

이제 eBPF-enriched 네트워크 흐름을 IPFIX 수집기로 내보낼 수 있습니다.

자세한 내용은 다음을 참조하세요.

2.1.54.8. 패킷 드롭

Network Observability Operator의 1.4 릴리스에서는 eBPF 추적을 활성화하는 데 사용됩니다. 이제 패킷 드롭의 원인을 감지하고 분석하여 네트워크 성능을 최적화할 수 있습니다. OpenShift Container Platform 4.14 이상에서는 호스트 드롭과 OVS 드롭이 모두 감지됩니다. OpenShift Container Platform 4.13에서는 호스트 삭제만 탐지됩니다.

자세한 내용은 다음을 참조하세요.

2.1.54.9. s390x 아키텍처 지원

Network Observability Operator는 이제 s390x 아키텍처에서 실행할 수 있습니다. 이전에는 amd64, ppc64le, arm64에서 실행되었습니다.

2.1.55. Network observability 릴리스 노트 1.4.0 제거 기능

Network Observability Operator 1.4.0 릴리스에서 제거된 다음 기능을 검토할 수 있습니다.

2.1.55.1. 채널 제거

최신 Operator 업데이트를 받으려면 채널을 v1.0.x 에서 stable 로 전환해야 합니다. 이제 v1.0.x 채널이 제거되었습니다.

2.1.56. Network observability 릴리스 노트 1.4.0 수정 문제

Network Observability Operator 1.4.0 릴리스에서 다음의 수정된 문제를 검토할 수 있습니다.

  • 이전에는 네트워크 관찰 기능에서 내보낸 Prometheus 지표가 잠재적으로 중복된 네트워크 흐름에서 계산되었습니다. 관련 대시보드에서 ObserveDashboards 의 경우 이로 인해 잠재적으로 두 배가 될 수 있습니다. 네트워크 트래픽 보기의 대시보드는 영향을 받지 않습니다. 이제 지표 계산 전에 중복을 제거하도록 네트워크 흐름이 필터링되어 대시보드에 올바른 트래픽 속도가 표시됩니다. (NETOBSERV-1131)
  • 이전에는 Network Observability Operator 에이전트가 기본이 아닌 네트워크 네임스페이스인 Multus 또는 SR-IOV로 구성된 경우 네트워크 인터페이스에서 트래픽을 캡처할 수 없었습니다. 이제 사용 가능한 모든 네트워크 네임스페이스가 인식되고 흐름 캡처에 사용되어 SR-IOV에 대한 트래픽을 캡처할 수 있습니다. flowCollectorSRIOVnetwork 사용자 정의 리소스에는 트래픽을 수집하는 구성이 필요합니다. (NETOBSERV-1283)
  • 이전에는 Network Observability Operator에서 Operators설치된 Operators의 세부 정보에서 FlowCollector Status 필드에 배포 상태에 대한 잘못된 정보가 보고되었을 수 있었습니다. 이제 status 필드에 더 나은 메시지와 함께 적절한 조건이 표시됩니다. 이벤트 기록은 이벤트 날짜별로 정렬됩니다. (NETOBSERV-1224)
  • 이전에는 네트워크 트래픽 로드가 급증하는 동안 특정 eBPF Pod가 OOM 인증되어 CrashLoopBackOff 상태가 되었습니다. 이제 eBPF 에이전트 메모리 공간이 개선되어 Pod가 OOM이 지정되지 않고 CrashLoopBackOff 상태가 됩니다. (NETOBSERV-975)
  • 이전에는 processor.metrics.tlsPROVIDED 로 설정된 경우 insecureSkipVerify 옵션 값이 true 로 강제되었습니다. 이제 insecureSkipVerifytrue 또는 false 로 설정하고 필요한 경우 CA 인증서를 제공할 수 있습니다. (NETOBSERV-1087)

2.1.57. Network observability 릴리스 노트 1.4.0 알려진 문제

Network Observability Operator 1.4.0 릴리스에서 다음과 같은 알려진 문제를 검토할 수 있습니다.

  • Loki Operator 5.6을 사용하여 Network Observability Operator의 1.2.0 릴리스 이후 Loki 인증서 변경은 flowlogs-pipeline Pod에 주기적으로 영향을 미치며 Loki에 작성된 흐름 대신 중단된 흐름이 발생합니다. 문제는 일정 시간 후에도 자체 수정되지만 Loki 인증서 변경 중에 임시 흐름 데이터 손실이 발생합니다. 이 문제는 120 노드의 대규모 환경에서만 관찰되었습니다. (NETOBSERV-980)
  • 현재 spec.agent.ebpf.features 에 DNSTracking이 포함된 경우, 대규모 DNS 패킷을 사용하려면 eBPF 에이전트가 1st 소켓 버퍼(SKB) 세그먼트 외부에서 DNS 헤더를 찾아야 합니다. 이를 지원하기 위해 새로운 eBPF 에이전트 도우미 기능을 구현해야 합니다. 현재 이 문제에 대한 해결방법이 없습니다. (NETOBSERV-1304)
  • 현재 spec.agent.ebpf.features 에서 DNSTracking이 포함된 경우, TCP 패킷을 통한 DNS를 사용하려면 eBPF 에이전트가 첫 번째 SKB 세그먼트 외부에서 DNS 헤더를 찾아야 합니다. 이를 지원하기 위해 새로운 eBPF 에이전트 도우미 기능을 구현해야 합니다. 현재 이 문제에 대한 해결방법이 없습니다. (NETOBSERV-1245)
  • 현재 KAFKA 배포 모델을 사용할 때 대화 추적이 구성된 경우 Kafka 소비자에 걸쳐 대화 이벤트가 복제되어 대화 추적이 일관되지 않을 수 있으며 잘못된 볼륨 관련 데이터를 추적할 수 있습니다. 따라서 deploymentModelKAFKA 로 설정할 때 대화 추적을 구성하지 않는 것이 좋습니다. (NETOBSERV-926)
  • 현재 processor.metrics.server.tls.typePROVIDED 인증서를 사용하도록 구성된 경우 Operator는 성능 및 리소스 사용량에 영향을 줄 수 있는 unsteady 상태를 입력합니다. 이 문제가 해결될 때까지 PROVIDED 인증서를 사용하지 않는 것이 좋습니다. 대신 자동 생성된 인증서를 사용하여 processor.metrics.server.tls.typeAUTO 로 설정합니다. (NETOBSERV-1293
  • Network Observability Operator의 1.3.0 릴리스 이후 Operator를 설치하면 경고 커널 테인트가 표시됩니다. 이 오류의 원인은 네트워크 관찰 기능 eBPF 에이전트에 전체 해시맵 테이블의 사전 할당을 방지하는 메모리 제약 조건이 있기 때문입니다. Operator eBPF 에이전트는 해시맵이 너무 많은 경우 사전 할당이 비활성화되도록 BPF_F_NO_PREALLOC 플래그를 설정합니다.

2.1.58. Network Observability Operator 1.3.0 권고

Network Observability Operator 1.3.0 릴리스에서 다음 권고를 검토할 수 있습니다.

2.1.59. Network Observability Operator 1.3.0 새로운 기능 및 개선 사항

Network Observability Operator 1.3.0 릴리스에서 다음과 같은 새로운 기능 및 개선 사항을 검토할 수 있습니다.

2.1.59.1. 네트워크 관찰 기능 다중 테넌시
  • 시스템 관리자는 Loki에 저장된 흐름에 대해 개별 사용자 액세스 또는 그룹 액세스를 허용 및 제한할 수 있습니다. 자세한 내용은 "Network observability의 다중 테넌시"를 참조하십시오.
2.1.59.2. 흐름 기반 메트릭 대시보드
  • 이번 릴리스에서는 OpenShift Container Platform 클러스터의 네트워크 흐름에 대한 개요를 제공하는 새 대시보드가 추가되었습니다. 자세한 내용은 "네트워크 관찰 메트릭 대시보드"를 참조하십시오.
2.1.59.3. must-gather 툴 문제 해결
  • Network Observability Operator에 대한 정보를 이제 문제 해결을 위해 must-gather 데이터에 포함할 수 있습니다. 자세한 내용은 "Network observability must-gather"를 참조하십시오.
2.1.59.4. 여러 아키텍처 지원
  • Network Observability Operator는 이제 amd64, ppc64le, 또는 arm64 아키텍처에서 실행할 수 있습니다. 이전에는 amd64 에서만 실행되었습니다.

2.1.60. Network Observability Operator 1.3.0 더 이상 사용되지 않는 기능

Network Observability Operator 1.3.0 릴리스에서 더 이상 사용되지 않는 다음과 같은 기능을 검토할 수 있습니다.

2.1.60.1. 채널 사용 중단

향후 Operator 업데이트를 받으려면 채널을 v1.0.x 에서 stable 로 전환해야 합니다. v1.0.x 채널은 더 이상 사용되지 않으며 다음 릴리스에서 제거될 예정입니다.

2.1.60.2. 더 이상 사용되지 않는 구성 매개변수 설정

Network Observability Operator 1.3 릴리스는 spec.Loki.authToken HOST 설정을 사용하지 않습니다. Loki Operator를 사용하는 경우 이제 FORWARD 설정만 사용해야 합니다.

2.1.61. Network Observability Operator 1.3.0의 문제 해결

Network Observability Operator 1.3.0 릴리스에서 다음 수정된 문제를 검토할 수 있습니다.

  • 이전에는 CLI에서 Operator를 설치할 때 Cluster Monitoring Operator에서 메트릭을 읽는 데 필요한 RoleRoleBinding 이 예상대로 설치되지 않았습니다. 웹 콘솔에서 Operator를 설치할 때 문제가 발생하지 않았습니다. 이제 Operator를 설치하는 방법 중 하나가 필요한 RoleRoleBinding 을 설치합니다. (NETOBSERV-1003)
  • 버전 1.2부터는 흐름 수집에 문제가 발생할 때 Network Observability Operator에서 경고를 발생시킬 수 있습니다. 이전 버전에서는 버그로 인해 경고를 비활성화하는 관련 구성이 spec.processor.metrics.disableAlerts 가 예상대로 작동하지 않고 경우에 따라 영향을 미치지 않았습니다. 이제 이 구성이 수정되어 경고를 비활성화할 수 있습니다. (NETOBSERV-976)
  • 이전에는 spec.loki.authTokenDISABLED 로 설정하여 네트워크 관찰 기능을 구성할 때 kubeadmin 클러스터 관리자만 네트워크 흐름을 볼 수 있었습니다. 다른 유형의 클러스터 관리자에게 권한 부여 오류가 발생했습니다. 이제 클러스터 관리자가 네트워크 흐름을 볼 수 있습니다. (NETOBSERV-972)
  • 이전 버전에서는 버그로 인해 사용자가 spec.consolePlugin.portNaming.enablefalse 로 설정할 수 없었습니다. 이제 이 설정을 false 로 설정하여 포트 투 서비스 이름 변환을 비활성화할 수 있습니다. (NETOBSERV-971)
  • 이전 버전에서는 콘솔 플러그인에서 노출하는 메트릭이 잘못된 구성으로 인해 Cluster Monitoring Operator(Prometheus)에 의해 수집되지 않았습니다. 이제 콘솔 플러그인 메트릭이 올바르게 수집되고 OpenShift Container Platform 웹 콘솔에서 액세스할 수 있도록 구성이 수정되었습니다. (NETOBSERV-765)
  • 이전에는 FlowCollector 에서 processor.metrics.tlsAUTO 로 설정된 경우 flowlogs-pipeline servicemonitor 가 적절한 TLS 체계를 적용하지 않았으며 웹 콘솔에서 메트릭이 표시되지 않았습니다. 이제 AUTO 모드에 대한 문제가 해결되었습니다. (NETOBSERV-1070)
  • 이전 버전에서는 Kafka 및 Loki에 사용된 인증서 구성에서 namespace 필드를 지정할 수 없으므로 인증서가 네트워크 관찰 기능이 배포된 동일한 네임스페이스에 있어야 했습니다. 또한 TLS/mTLS와 함께 Kafka를 사용할 때 사용자는 인증서 교체의 경우와 같이 eBPF 에이전트 Pod가 배포된 권한 있는 네임스페이스에 인증서를 수동으로 복사해야 했습니다. 이제 FlowCollector 리소스에서 인증서에 대한 네임스페이스 필드를 추가하여 네트워크 관찰 기능 설정이 간소화됩니다. 결과적으로 네트워크 관찰 네임스페이스에서 인증서를 수동으로 복사할 필요 없이 다른 네임스페이스에 Loki 또는 Kafka를 설치할 수 있습니다. 원본 인증서는 필요한 경우 복사본이 자동으로 업데이트되도록 감시됩니다. (NETOBSERV-773)
  • 이전에는 SCTP, ICMPv4 및 ICMPv6 프로토콜이 네트워크 관찰 에이전트의 적용을 받지 않아 네트워크 흐름이 줄어들었습니다. 이러한 프로토콜은 이제 흐름 범위를 개선하기 위해 인식됩니다. (NETOBSERV-934)

2.1.62. Network Observability Operator 1.3.0의 알려진 문제

사용 가능한 경우 다음 문제와 해결 방법을 검토하여 Network Observability Operator 1.3.0 릴리스의 문제를 해결할 수 있습니다.

  • FlowCollector 에서 processor.metrics.tlsPROVIDED 로 설정된 경우 flowlogs-pipeline 서비스monitor 가 TLS 체계에 적용되지 않습니다. (NETOBSERV-1087)
  • Loki Operator 5.6을 사용하여 Network Observability Operator의 1.2.0 릴리스 이후 Loki 인증서 변경은 flowlogs-pipeline Pod에 주기적으로 영향을 미치며 Loki에 작성된 흐름 대신 중단된 흐름이 발생합니다. 문제는 일정 시간 후에도 자체 수정되지만 Loki 인증서 변경 중에 임시 흐름 데이터 손실이 발생합니다. 이 문제는 120 노드의 대규모 환경에서만 관찰되었습니다. (NETOBSERV-980)
  • Operator를 설치하면 경고 커널 테인트가 표시될 수 있습니다. 이 오류의 원인은 네트워크 관찰 기능 eBPF 에이전트에 전체 해시맵 테이블의 사전 할당을 방지하는 메모리 제약 조건이 있기 때문입니다. Operator eBPF 에이전트는 해시맵이 너무 많은 경우 사전 할당이 비활성화되도록 BPF_F_NO_PREALLOC 플래그를 설정합니다.

2.1.63. Network observability 릴리스 노트 1.2.0 다음 업데이트를 위한 준비

Network Observability Operator의 업데이트 채널을 더 이상 사용되지 않는 v1.0.x 에서 stable 채널로 전환하여 향후 릴리스 및 업데이트를 계속 받습니다.

설치된 Operator의 서브스크립션은 Operator를 추적하고 업데이트를 수신하는 업데이트 채널을 지정합니다. Network Observability Operator의 1.2 릴리스까지 사용 가능한 유일한 채널은 v1.0.x 였습니다. Network Observability Operator의 1.2 릴리스에서는 업데이트를 추적하고 수신하기 위한 안정적인 업데이트 채널을 도입했습니다. 향후 Operator 업데이트를 받으려면 채널을 v1.0.x 에서 stable 로 전환해야 합니다. v1.0.x 채널은 더 이상 사용되지 않으며 다음 릴리스에서 제거될 예정입니다.

2.1.64. Network Observability Operator 1.2.0 권고

Network Observability Operator 1.2.0 릴리스에 대한 다음 권고를 볼 수 있습니다.

2.1.65. Network Observability Operator 1.2.0 새로운 기능 및 개선 사항

Network Observability Operator 1.2.0 릴리스에 대한 다음과 같은 새로운 기능 및 개선 사항을 볼 수 있습니다.

2.1.65.1. 트래픽 흐름 보기의 히스토그램

이제 시간이 지남에 따라 흐름의 히스토그램을 표시하도록 선택할 수 있습니다. 히스토그램을 사용하면 Loki 쿼리 제한에 도달하지 않고 흐름 기록을 시각화할 수 있습니다. 자세한 내용은 "히스토그램 사용"을 참조하십시오.

2.1.65.2. 대화 추적

이제 로그 유형 별로 흐름을 쿼리하여 동일한 대화의 일부인 네트워크 흐름을 그룹화할 수 있습니다. 자세한 내용은 "경고 작업"을 참조하십시오.

2.1.65.3. 네트워크 관찰 기능 상태 경고

이제 Network Observability Operator가 쓰기 단계에서 오류 또는 Loki ingestion 속도 제한에 도달한 경우 flowlogs-pipeline 이 흐름을 삭제하는 경우 자동 경고를 생성합니다. 자세한 내용은 "Health dashboards"를 참조하십시오.

2.1.66. Network Observability Operator 1.2.0 버그 수정

Network Observability Operator 1.2.0 릴리스에 대한 다음 수정된 문제를 볼 수 있습니다.

  • 이전에는 FlowCollector 사양에서 네임스페이스 값을 변경한 후 이전 네임스페이스에서 실행되는 eBPF 에이전트 Pod가 적절하게 삭제되지 않았습니다. 이제 이전 네임스페이스에서 실행 중인 Pod가 적절하게 삭제됩니다. (NETOBSERV-774)
  • 이전에는 FlowCollector 사양(예: Loki 섹션)에서 caCert.name 값을 변경한 후 FlowLogs-Pipeline Pod 및 콘솔 플러그인 Pod가 재시작되지 않아 구성 변경을 인식하지 못했습니다. 이제 Pod가 다시 시작되어 구성 변경이 수행됩니다. (NETOBSERV-772)
  • 이전에는 다른 노드에서 실행 중인 Pod 간 네트워크 흐름이 다른 네트워크 인터페이스에서 캡처되므로 중복으로 올바르게 식별되지 않은 경우가 있었습니다. 이로 인해 콘솔 플러그인에 초과 평가 지표가 표시되었습니다. 이제 흐름이 중복으로 올바르게 확인되고 콘솔 플러그인에 정확한 지표가 표시됩니다. (NETOBSERV-755)
  • 콘솔 플러그인의 "reporter" 옵션은 소스 노드 또는 대상 노드의 관찰 지점을 기반으로 흐름을 필터링하는 데 사용됩니다. 이전에는 이 옵션이 노드 관찰 지점과 관계없이 흐름을 혼합했습니다. 이는 네트워크 흐름이 노드 수준에서 Ingress 또는 Egress로 잘못 보고되었기 때문입니다. 이제 네트워크 흐름 방향 보고가 올바르게 수행됩니다. "reporter" 옵션은 예상대로 소스 관찰 지점 또는 대상 관찰 지점에 대해 필터링합니다. (NETOBSERV-696)
  • 이전 버전에서는 gRPC+protobuf 요청으로 흐름을 직접 전송하도록 구성된 에이전트의 경우 제출된 페이로드가 너무 클 수 있으며 프로세서의 GRPC 서버에서 거부되었습니다. 이는 매우 높은 로드 시나리오와 에이전트의 일부 구성에서만 발생했습니다. 에이전트가 max보다 큰 오류 메시지(예: grpc: received message)를 기록했습니다. 그 결과 이러한 흐름에 대한 정보가 손실되었습니다. 이제 gRPC 페이로드가 크기가 임계값을 초과하면 여러 메시지로 나뉩니다. 결과적으로 서버는 연결을 유지합니다. (NETOBSERV-617)

2.1.67. Network Observability Operator 1.2.0 알려진 문제

사용 가능한 경우 다음 문제와 해결 방법을 검토하여 Network Observability Operator 1.2.0 릴리스의 문제를 해결할 수 있습니다.

  • Loki Operator 5.6을 사용하여 Network Observability Operator의 1.2.0 릴리스에서 Loki 인증서 전환은 flowlogs-pipeline Pod에 주기적으로 영향을 미치며 Loki에 작성된 흐름 대신 중단된 흐름이 발생합니다. 문제는 일정 시간 후에도 자체 수정되지만 Loki 인증서 전환 중에 임시 흐름 데이터 손실이 발생합니다. (NETOBSERV-980)

2.1.68. Network Observability Operator 1.2.0 주요 기술 변경

Network Observability Operator 1.2.0 릴리스에서는 새로운 기술 변경으로 인해 openshift-netobserv-operator 네임스페이스에 설치해야 합니다. 이전에 사용자 정의 네임스페이스를 사용한 사용자는 이전 인스턴스를 삭제하고 Operator를 다시 설치해야 합니다.

이전에는 사용자 정의 네임스페이스를 사용하여 Network Observability Operator를 설치할 수 있었습니다. 이번 릴리스에서는 ClusterServiceVersion 을 변경하는 변환 Webhook 가 도입되었습니다. 이러한 변경으로 인해 사용 가능한 모든 네임스페이스가 더 이상 나열되지 않습니다. 또한 Operator 지표 컬렉션을 활성화하려면 openshift-operators 네임스페이스와 같이 다른 Operator와 공유하는 네임스페이스를 사용할 수 없습니다.

이제 Operator를 openshift-netobserv-operator 네임스페이스에 설치해야 합니다.

이전에 사용자 정의 네임스페이스를 사용하여 Network Observability Operator를 설치한 경우 새 Operator 버전으로 자동 업그레이드할 수 없습니다. 이전에 사용자 정의 네임스페이스를 사용하여 Operator를 설치한 경우 설치된 Operator 인스턴스를 삭제하고 openshift-netobserv-operator 네임스페이스에 Operator를 다시 설치해야 합니다. 일반적으로 사용되는 netobserv 네임스페이스와 같은 사용자 정의 네임스페이스는 FlowCollector, Loki, Kafka 및 기타 플러그인에 계속 사용할 수 있습니다.

2.1.69. Network Observability Operator 1.1.0 개선 사항

Network Observability Operator 1.1.0에 대한 다음 권고를 볼 수 있습니다.

Network Observability Operator가 안정되어 릴리스 채널이 v1.1.0 으로 업그레이드되었습니다.

2.1.70. Network Observability Operator 1.1.0 문제 해결

Network Observability Operator 1.1.0 릴리스에 대한 다음 수정된 문제를 볼 수 있습니다.

  • 이전 버전에서는 Loki authToken 구성이 FORWARD 모드로 설정되지 않은 경우 인증이 적용되지 않아 권한이 없는 사용자가 흐름을 검색할 수 있었습니다. 이제 Loki authToken 모드에 관계없이 클러스터 관리자만 흐름을 검색할 수 있습니다. (BZ#2169468)

3장. 네트워크 관찰 기능 정보

Network Observability Operator를 사용하여 eBPF 기술을 통해 네트워크 트래픽을 관찰하여 Prometheus 지표 및 Loki 로그를 통해 문제 해결 통찰력을 제공합니다.

자세한 정보 및 문제 해결을 위해 OpenShift Container Platform 콘솔에서 이러한 저장된 정보를 보고 분석할 수 있습니다.

3.1. Network Observability Operator

Network Observability Operator는 Loki 또는 Prometheus에서 네트워크 흐름을 수집, 강화 및 저장하는 eBPF 에이전트 및 서비스의 파이프라인을 관리하는 클러스터 범위 FlowCollector API 사용자 정의 리소스를 제공합니다.

FlowCollector 인스턴스는 모니터링 파이프라인을 구성하는 Pod 및 서비스를 배포합니다.

eBPF 에이전트는 데몬 세트 오브젝트로 배포되고 네트워크 흐름을 생성합니다. 파이프라인은 Loki에 저장하거나 Prometheus 지표를 생성하기 전에 Kubernetes 메타데이터로 네트워크 흐름을 수집하고 강화합니다.

3.2. Network Observability Operator의 선택적 종속 항목

탄력적이고 대규모 데이터 처리 및 확장성을 위해 flow 스토리지 및 AMQ Streams(Kafka)용 Loki Operator와 같은 선택적 종속 항목과 Network Observability Operator를 통합합니다.

지원되는 선택적 종속 항목에는 흐름 스토리지에 대해 Loki Operator와 Kafka를 사용한 대규모 데이터 처리를 위한 AMQ Streams가 포함됩니다.

Loki Operator
Loki를 백엔드로 사용하여 수집된 모든 흐름을 최대 수준의 세부 정보로 저장할 수 있습니다. Red Hat 지원 Loki Operator를 사용하여 Loki를 설치하는 것이 좋습니다. Loki 없이 네트워크 관찰 기능을 사용하도록 선택할 수도 있지만 몇 가지 요소를 고려해야 합니다. 자세한 내용은 " Loki가 없는 네트워크 관찰 기능"을 참조하십시오.
AMQ Streams Operator

Kafka는 대규모 배포를 위해 OpenShift Container Platform 클러스터에서 확장성, 복원력 및 고가용성을 제공합니다.

참고

Kafka를 사용하도록 선택하는 경우 Red Hat 지원 AMQ Streams Operator를 사용하는 것이 좋습니다.

3.3. OpenShift Container Platform 콘솔 통합

Network Observability Operator는 OpenShift Container Platform 콘솔과 통합되어 개요, 토폴로지 보기 및 트래픽 흐름 테이블을 제공합니다.

모니터링 → 대시보드의 네트워크 관찰 기능 지표 대시보드 는 관리자 액세스 권한이 있는 사용자만 사용할 수 있습니다.

참고

개발자 액세스 및 네임스페이스에 대한 제한된 액세스 권한이 있는 관리자의 멀티 테넌시를 활성화하려면 역할을 정의하여 권한을 지정해야 합니다. 자세한 내용은 "Network observability에서 멀티 테넌시 활성화"를 참조하십시오.

3.3.1. 네트워크 관찰 기능 지표 대시보드

Operator 상태를 모니터링하기 위해 전체 트래픽 흐름 집계, 필터링 옵션 및 전용 대시보드를 제공하는 OpenShift Container Platform 콘솔의 네트워크 관찰 기능 지표 대시보드를 검토합니다.

개요 탭의 OpenShift Container Platform 콘솔에서 클러스터의 네트워크 트래픽 흐름에 대한 전체 집계 메트릭을 볼 수 있습니다. 클러스터, 노드, 네임스페이스, 소유자, Pod 및 서비스별로 정보를 표시하도록 선택할 수 있습니다. 필터 및 표시 옵션은 메트릭을 추가로 구체화할 수 있습니다. 자세한 내용은 "개요 보기에서 네트워크 트래픽 예약"을 참조하십시오.

ObserveDashboards 에서 Netobserv 대시보드는 OpenShift Container Platform 클러스터의 네트워크 흐름에 대한 간략한 개요를 제공합니다. Netobserv/Health 대시보드는 Operator의 상태에 대한 지표를 제공합니다. 자세한 내용은 "네트워크 관찰 메트릭" 및 "상태 정보 보기"를 참조하십시오.

3.3.2. 네트워크 관찰 기능 토폴로지 보기

OpenShift Container Platform 콘솔의 네트워크 관찰 기능 토폴로지 보기에는 구성 요소 간 트래픽 흐름의 그래픽 표시가 표시되어 다양한 필터 및 표시 옵션을 사용하여 구체화할 수 있습니다.

OpenShift Container Platform 콘솔은 OpenShift Container Platform 구성 요소 간 트래픽을 네트워크 그래프로 표시하는 토폴로지 탭을 제공합니다. 필터 및 표시 옵션을 사용하여 그래프를 구체화할 수 있습니다. 클러스터, 영역, udn, 노드, 네임스페이스, 소유자, Pod 및 서비스에 대한 정보에 액세스할 수 있습니다.

3.3.3. 트래픽 흐름 테이블

OpenShift Container Platform 웹 콘솔의 트래픽 흐름 테이블에는 원시 네트워크 흐름에 대한 자세한 보기를 제공하므로 심층적인 분석을 위해 강력한 필터링 옵션과 구성 가능한 열을 제공합니다.

OpenShift Container Platform 웹 콘솔의 트래픽 흐름 탭에는 네트워크 흐름의 데이터 및 트래픽 양이 표시됩니다.

3.4. Network Observability CLI

Network Observability CLI(oc netobserv)는 전체 Network Observability Operator를 설치할 필요 없이 빠르고 실시간 네트워킹 문제에 대한 흐름 및 패킷 데이터를 스트리밍하는 경량 툴입니다.

Network Observability CLI는 수집된 데이터를 임시 수집기 Pod로 스트리밍하기 위해 eBPF 에이전트를 사용하는 흐름 및 패킷 시각화 툴입니다. 캡처하는 동안 영구 스토리지가 필요하지 않습니다. 실행 후 출력이 로컬 시스템으로 전송됩니다. 이를 통해 Network Observability Operator를 설치하지 않고도 패킷 및 흐름 데이터에 대한 빠른 실시간 통찰력을 얻을 수 있습니다.

4장. Network Observability Operator 설치

Network Observability Operator를 사용하기 전에 Loki Operator를 설치하는 것이 좋습니다. Loki 없이 네트워크 관찰 기능을 사용할 수 있지만 메트릭 또는 외부 내보내기만 필요한 경우에만 특별한 고려 사항이 적용됩니다.

Loki Operator는 데이터 흐름 스토리지를 위해 Loki와 멀티 테넌시 및 인증을 구현하는 게이트웨이를 통합합니다. LokiStack 리소스는 확장 가능하고 가용성이 높은 다중 테넌트 로그 집계 시스템 및 OpenShift Container Platform 인증을 사용하는 웹 프록시인 Loki를 관리합니다. LokiStack 프록시는 OpenShift Container Platform 인증을 사용하여 멀티 테넌시를 적용하고 Loki 로그 저장소에서 데이터 저장 및 인덱싱을 용이하게 합니다.

4.1. Loki가 없는 네트워크 관찰 기능

Loki Operator를 설치하지 않고 네트워크 관찰 기능과 사용 가능한 기능을 비교합니다.

흐름만 Kafka 소비자 또는 IPFIX 수집기로 내보내거나 대시보드 메트릭만 필요한 경우 Loki를 설치하거나 Loki에 스토리지를 제공할 필요가 없습니다. 다음 표에서는 Loki와 사용 가능한 기능을 비교합니다.

Expand
표 4.1. Loki와의 기능 가용성 비교
 Loki 사용Loki 없이

내보내기

X

X

Multi-tenancy

X

X

완전한 필터링 및 집계 기능 [1]

X

 

부분 필터링 및 집계 기능 [2]

X

X

흐름 기반 메트릭 및 대시보드

X

X

트래픽 흐름 보기 개요 [3]

X

X

트래픽 흐름 보기 테이블

X

 

Topology view

X

X

OpenShift Container Platform 콘솔 네트워크 트래픽 탭 통합

X

X

  1. 예를 들면 per pod입니다.
  2. 워크로드 또는 네임스페이스별.
  3. 패킷 드롭의 통계는 Loki에서만 사용할 수 있습니다.

4.2. Loki Operator 설치

소프트웨어 카탈로그에서 지원되는 Loki Operator 버전을 설치하여 네트워크 관찰 기능에 대한 클러스터 내 인증 및 권한 부여를 제공하는 보안 LokiStack 인스턴스를 활성화합니다.

Loki Operator 버전 6.0+ 는 네트워크 관찰 기능을 위해 지원되는 Loki Operator 버전입니다. 이러한 버전은 openshift-network 테넌트 구성 모드를 사용하여 LokiStack 인스턴스를 생성하고 네트워크 관찰 기능에 대한 완전한 자동 인증 및 권한 부여 지원을 제공하는 기능을 제공합니다.

사전 요구 사항

  • 관리자 권한이 있습니다.
  • OpenShift Container Platform 웹 콘솔에 액세스할 수 있습니다.
  • 지원되는 오브젝트 저장소에 액세스할 수 있습니다. 예를 들어 AWS S3, Google Cloud Storage, Azure, Swift, Minio 또는 OpenShift Data Foundation입니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에서 에코시스템소프트웨어 카탈로그 를 클릭합니다.
  2. 사용 가능한 Operator 목록에서 Loki Operator 를 선택하고 설치를 클릭합니다.
  3. 설치 모드에서 클러스터의 모든 네임스페이스를 선택합니다.

검증

  1. Loki Operator를 설치했는지 확인합니다. Ecosystem설치된 Operator 페이지를 방문하여 Loki Operator 를 찾습니다.
  2. Loki Operator 가 모든 프로젝트에 Succeeded 상태로 나열되어 있는지 확인합니다.
중요

Loki를 설치 제거하려면 Loki를 설치하는 데 사용한 방법과 일치하는 제거 프로세스를 참조하십시오. 나머지 ClusterRolesClusterRoleBindings, 오브젝트 저장소에 저장된 데이터 및 제거해야 하는 영구 볼륨이 있을 수 있습니다.

4.2.1. Loki 스토리지의 시크릿 생성

Loki Operator가 로그 지속성을 위해 필요한 오브젝트 저장소에 액세스할 수 있도록 AWS(Amazon Web Services)와 같은 클라우드 스토리지 인증 정보를 사용하여 시크릿을 생성합니다.

Loki Operator는 AWS S3, Google Cloud Storage, Azure, Swift, Minio, OpenShift Data Foundation과 같은 몇 가지 로그 스토리지 옵션을 지원합니다. 다음 예제에서는 AWS S3 스토리지에 대한 보안을 생성하는 방법을 보여줍니다. 이 예에서 loki-s3 에서 생성된 보안은 " LokiStack 사용자 정의 리소스 생성"에서 참조됩니다. 웹 콘솔 또는 CLI에서 이 시크릿을 생성할 수 있습니다.

프로세스

  1. 웹 콘솔을 사용하여 프로젝트모든 프로젝트 드롭다운으로 이동하여 프로젝트 생성을 선택합니다.
  2. 프로젝트 이름을 netobserv 로 지정하고 생성 을 클릭합니다.
  3. 오른쪽 상단에 있는 가져오기 아이콘 + 로 이동합니다. YAML 파일을 편집기에 붙여넣습니다.

    다음은 S3 스토리지에 대한 시크릿 YAML 파일의 예입니다.

    apiVersion: v1
    kind: Secret
    metadata:
      name: loki-s3
      namespace: netobserv-loki
    stringData:
      access_key_id: QUtJQUlPU0ZPRE5ON0VYQU1QTEUK
      access_key_secret: d0phbHJYVXRuRkVNSS9LN01ERU5HL2JQeFJmaUNZRVhBTVBMRUtFWQo=
      bucketnames: s3-bucket-name
      endpoint: https://s3.eu-central-1.amazonaws.com
      region: eu-central-1

    다음과 같습니다.

    metadata.namespace
    Loki S3 시크릿의 네임스페이스를 지정합니다. 이 예제에서는 netobserv-loki 를 사용하지만 다른 구성 요소에 다른 네임스페이스를 사용할 수 있습니다.
    stringData.access_key_id
    S3 버킷의 액세스 키 ID를 지정합니다.
    stringData.access_key_secret
    S3 버킷의 시크릿 액세스 키를 지정합니다.
    stringData.bucketnames
    S3 버킷의 이름을 지정합니다.
    stringData.endpoint
    S3 서비스의 끝점 URL을 지정합니다.
    stringData.region
    버킷이 있는 AWS 리전을 지정합니다.

검증

  • 보안을 생성한 후 웹 콘솔의 워크로드 → 보안에 나열된 보안을 확인합니다.

4.2.2. LokiStack 사용자 정의 리소스 생성

웹 콘솔 또는ocCLI(OpenShift CLI)를 사용하여 LokiStack 사용자 정의 리소스를 배포하여 Loki 오브젝트 스토리지에 대한 올바른 네임스페이스, 배포 크기, 시크릿 이름을 구성합니다.

LokiStack CR(사용자 정의 리소스)을 배포하여 네임스페이스 또는 새 프로젝트를 생성할 수 있습니다.

프로세스

  1. Ecosystem설치된 Operators 로 이동하여 프로젝트 드롭다운의 모든 프로젝트를 확인합니다.
  2. Loki Operator 를 찾습니다. 세부 정보에서 제공된 API에서 LokiStack 을 선택합니다.
  3. LokiStack 생성을 클릭합니다.
  4. 다음 필드가 양식 보기 또는 YAML 보기에 지정되었는지 확인합니다.

    apiVersion: loki.grafana.com/v1
    kind: LokiStack
    metadata:
      name: loki
      namespace: netobserv-loki
    spec:
      size: 1x.small
      storage:
        schemas:
        - version: v13
          effectiveDate: '2022-06-01'
        secret:
          name: loki-s3
          type: s3
      storageClassName: gp3
      tenants:
        mode: openshift-network

    다음과 같습니다.

    metadata.namespace
    LokiStack 리소스의 네임스페이스를 지정합니다. 이 예제에서는 netobserv-loki 를 사용하지만 다른 구성 요소에 다른 네임스페이스를 사용할 수 있습니다.
    spec.size

    배포 크기를 지정합니다. Loki Operator 5.8 이상 버전에서 Loki의 프로덕션 인스턴스에 지원되는 크기 옵션은 1x.extra- #159 ,1x. tekton 또는 1x.medium 입니다.

    중요

    배포 크기에 대해 숫자 1x 를 변경할 수 없습니다.

    spec.storageClassName

    ReadWriteOnce 액세스 모드에서 클러스터에서 사용할 수 있는 스토리지 클래스 이름을 지정합니다. 최상의 성능을 위해서는 블록 스토리지를 할당하는 스토리지 클래스를 지정합니다. oc get storageclasses 명령을 사용하여 클러스터에서 사용 가능한 스토리지 클래스를 확인합니다.

    중요

    로깅에 사용되는 동일한 LokiStack 사용자 정의 리소스를 재사용해서는 안 됩니다.

  5. 생성을 클릭합니다.

4.2.3. cluster-admin 사용자 역할의 새 그룹 생성

중요

cluster-admin 사용자로 여러 네임스페이스에 대한 애플리케이션 로그를 쿼리합니다. 여기서 클러스터의 모든 네임스페이스 합계는 5120보다 큰 오류입니다: 입력 크기가 너무 긴 (XXXX > 5120) 오류가 발생했습니다. LokiStack의 로그에 대한 액세스를 보다 효과적으로 제어하려면 cluster-admin 사용자를 cluster-admin 그룹의 멤버로 설정합니다. cluster-admin 그룹이 없는 경우 해당 그룹을 생성하고 원하는 사용자를 추가합니다.

다음 절차에 따라 cluster-admin 권한이 있는 사용자를 위한 새 그룹을 생성합니다.

프로세스

  1. 다음 명령을 입력하여 새 그룹을 생성합니다.

    $ oc adm groups new cluster-admin
  2. 다음 명령을 입력하여 원하는 사용자를 cluster-admin 그룹에 추가합니다.

    $ oc adm groups add-users cluster-admin <username>
  3. 다음 명령을 입력하여 cluster-admin 사용자 역할을 그룹에 추가합니다.

    $ oc adm policy add-cluster-role-to-group cluster-admin cluster-admin

4.2.4. 사용자 정의 관리자 그룹 액세스

반드시 관리자 없이 클러스터 전체 로그를 확인해야 하거나 여기에서 사용하려는 그룹이 이미 정의되어 있는 경우 adminGroup 필드를 사용하여 사용자 지정 그룹을 지정할 수 있습니다. LokiStack CR(사용자 정의 리소스)의 adminGroups 필드에 지정된 그룹의 멤버인 사용자는 관리자와 동일한 읽기 액세스 권한을 갖습니다.

관리자 사용자는 클러스터 전체의 모든 네트워크 로그에 액세스할 수 있습니다.

LokiStack CR의 예

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: loki
  namespace: netobserv
spec:
  tenants:
    mode: openshift-network 
1

    openshift:
      adminGroups: 
2

      - cluster-admin
      - custom-admin-group 
3

1
사용자 지정 관리 그룹은 이 모드에서만 사용할 수 있습니다.
2
이 필드에 빈 목록 [] 값을 입력하면 관리자 그룹이 비활성화됩니다.
3
기본 그룹 덮어쓰기(system:cluster-admins,cluster-admin,dedicated-admin)

4.2.5. Loki 배포 크기 조정

Loki의 크기 조정은 1x.<size> 형식을 따릅니다. 여기서 1x 값은 인스턴스 수이고 < size >는 성능 기능을 지정합니다.

중요

배포 크기에 대해 숫자 1x 를 변경할 수 없습니다.

Expand
표 4.2. Loki 크기 조정
 1x.demo1x.extra-small1x.small1x.medium

데이터 전송

데모만 사용

100GB/day

500GB/day

2TB/일

초당 쿼리(QPS)

데모만 사용

200ms에서 1-25 QPS

25-50 QPS (200ms)

25-75 QPS (200ms)

복제 요인

없음

2

2

2

총 CPU 요청

없음

14 vCPUs

34 vCPUs

54 vCPUs

총 메모리 요청

없음

31Gi

67Gi

139Gi

총 디스크 요청

40Gi

430Gi

430Gi

590Gi

4.2.6. LokiStack 수집 제한 및 상태 경고

LokiStack 인스턴스에는 관리자가 성능을 관리하고 시스템 경고 또는 오류를 방지하기 위해 덮어쓸 수 있는 기본 수집 및 쿼리 제한이 포함되어 있습니다.

참고

Loki 오류가 콘솔 플러그인 또는 flowlogs-pipeline 로그에 표시되면 ingestion 및 쿼리 제한을 업데이트할 수 있습니다.

다음은 구성된 제한의 예입니다.

spec:
  limits:
    global:
      ingestion:
        ingestionBurstSize: 40
        ingestionRate: 20
        maxGlobalStreamsPerTenant: 25000
      queries:
        maxChunksPerQuery: 2000000
        maxEntriesLimitPerQuery: 10000
        maxQuerySeries: 3000

이러한 설정에 대한 자세한 내용은 "LokiStack API 참조"를 참조하십시오.

4.3. Network Observability Operator 설치

Network Observability Operator를 설치하고 설정 마법사를 사용하여 FlowCollector CRD(사용자 정의 리소스 정의)를 생성하여 초기 구성을 완료합니다.

FlowCollector 를 만들 때 웹 콘솔에서 사양을 설정할 수 있습니다.

중요

Operator의 실제 메모리 사용은 클러스터 크기 및 배포된 리소스 수에 따라 달라집니다. 그에 따라 메모리 사용을 조정해야 할 수 있습니다. 자세한 내용은 "중요 흐름 수집기 구성 고려 사항" 섹션의 "네트워크 Observability 컨트롤러 관리자 Pod가 메모리 부족"을 참조하십시오.

사전 요구 사항

  • Loki를 사용하도록 선택하는 경우 Loki Operator 버전 5.7+ 를 설치합니다.
  • cluster-admin 권한이 있어야 합니다.
  • 지원되는 아키텍처 중 하나는 amd64, ppc64le, arm64, 또는 s390x입니다.
  • RHEL(Red Hat Enterprise Linux) 9에서 지원하는 모든 CPU.
  • OVN-Kubernetes를 기본 네트워크 플러그인으로 구성하고 필요한 경우 Multus 및 SR-IOV와 함께 보조 인터페이스를 사용해야 합니다.
참고

또한 이 설치 예제에서는 모든 구성 요소에서 사용되는 netobserv 네임스페이스를 사용합니다. 선택적으로 다른 네임스페이스를 사용할 수 있습니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에서 에코시스템소프트웨어 카탈로그 를 클릭합니다.
  2. 소프트웨어 카탈로그의 사용 가능한 Operator 목록에서 Network Observability Operator 를 선택하고 설치를 클릭합니다.
  3. 이 네임스페이스에서 Operator 권장 클러스터 모니터링 활성화 확인란을 선택합니다.
  4. Operators설치된 Operator로 이동합니다. 네트워크 Observability용 제공된 API에서 흐름 수집기 링크를 선택합니다.
  5. 네트워크 Observability FlowCollector 설정 마법사를 따릅니다.
  6. 생성을 클릭합니다.

검증

이 작업이 성공했는지 확인하려면 Observe 로 이동할 때 옵션에 네트워크 트래픽이 표시되어야 합니다.

OpenShift Container Platform 클러스터 내에 애플리케이션 트래픽이 없으면 기본 필터에 "결과가 없음"이 표시되어 시각적 흐름이 발생하지 않을 수 있습니다. 필터 선택 옆에 있는 모든 필터 지우기 를 선택하여 흐름을 확인합니다.

4.3.1. 중요한 FlowCollector 구성 고려 사항

이후 재구성으로 인한 Pod 중단을 방지하기 위해 초기 배포 전에 필수 FlowCollector 구성 옵션을 검토하십시오. 주요 설정에는 Kafka 통합, 보강된 흐름 데이터 내보내기, SR-IOV 트래픽 모니터링 및 DNS 및 패킷 드롭에 대한 고급 추적이 포함됩니다.

FlowCollector 인스턴스를 생성하면 재구성할 수 있지만 Pod가 종료되고 다시 생성되어 손상될 수 있습니다.

따라서 처음으로 FlowCollector 를 만들 때 다음 옵션을 구성할 수 있습니다.

4.3.2. 삭제된 버전의 FlowCollector CRD 마이그레이션

업그레이드 오류를 방지하고 Network Observability Operator 1.6으로 성공적으로 마이그레이션하려면 FlowCollector CRD(사용자 정의 리소스 정의) storedVersion 목록에서 더 이상 사용되지 않는 v1alpha1 버전을 수동으로 제거합니다.

저장된 버전을 제거하는 방법은 다음 두 가지가 있습니다.

  1. 스토리지 버전 Migrator Operator를 사용합니다.
  2. Network Observability Operator를 설치 제거하고 다시 설치하여 설치가 정리되었는지 확인합니다.

사전 요구 사항

  • 이전 버전의 Operator가 설치되어 있으며 최신 버전의 Operator를 설치할 클러스터를 준비하려고 합니다. 또는 Network Observability Operator 1.6을 설치하고 오류 발생: 데이터 손실 위험 "flowcollectors.flows.netobserv.io": 새 CRD는 기존 CRD에 저장된 버전으로 나열된 버전 v1alpha1을 제거합니다.

프로세스

  1. 이전 FlowCollector CRD 버전이 storedVersion 에서 계속 참조되는지 확인합니다.

    $ oc get crd flowcollectors.flows.netobserv.io -ojsonpath='{.status.storedVersions}'
  2. 결과 목록에 v1alpha1 이 표시되면 Step a 를 진행하여 Kubernetes Storage Version Migrator 또는 Step b 를 사용하여 CRD와 Operator를 설치 제거하고 다시 설치합니다.

    1. 옵션 1: Kubernetes Storage 버전 Migrator : StorageVersion Migration 오브젝트를 정의하는 YAML을 만듭니다(예: migrate-flowcollector-v1alpha1.yaml ).

      apiVersion: migration.k8s.io/v1alpha1
      kind: StorageVersionMigration
      metadata:
        name: migrate-flowcollector-v1alpha1
      spec:
        resource:
          group: flows.netobserv.io
          resource: flowcollectors
          version: v1alpha1
      1. 파일을 저장합니다.
      2. 다음 명령을 실행하여 StorageVersionMigration 을 적용합니다.

        $ oc apply -f migrate-flowcollector-v1alpha1.yaml
      3. storedVersion 에서 v1alpha1 을 수동으로 제거하도록 FlowCollector CRD를 업데이트합니다.

        $ oc edit crd flowcollectors.flows.netobserv.io
    2. 옵션 2: Reinstall: FlowCollector CR의 Network Observability Operator 1.5 버전을 파일에 저장합니다(예: flowcollector-1.5.yaml ).

      $ oc get flowcollector cluster -o yaml > flowcollector-1.5.yaml
      1. Operator를 제거하고 기존 FlowCollector CRD를 제거하는 "Network Observability Operator 제거"의 단계를 따릅니다.
      2. Network Observability Operator 최신 버전 1.6.0을 설치합니다.
      3. b 단계에 저장된 백업을 사용하여 FlowCollector 를 만듭니다.

검증

  • 다음 명령을 실행합니다.

    $ oc get crd flowcollectors.flows.netobserv.io -ojsonpath='{.status.storedVersions}'

    결과 목록에 더 이상 v1alpha1 이 표시되지 않아야 하며 최신 버전 v1beta1 만 표시되어야 합니다.

4.4. 네트워크 관찰 기능 활성화

프로젝트 관리자와 개발자에게 Loki 및 Prometheus의 흐름 및 메트릭에 대한 제한된 액세스 권한을 세부적으로 부여하도록 클러스터 역할 및 네임스페이스 역할을 구성하여 네트워크 관찰 기능을 활성화합니다.

프로젝트 관리자에 대한 액세스 권한이 활성화됩니다. 일부 네임스페이스에 대한 액세스 권한이 제한된 프로젝트 관리자는 해당 네임스페이스의 흐름에만 액세스할 수 있습니다.

개발자의 경우 멀티 테넌시는 Loki 및 Prometheus 모두에 사용할 수 있지만 다른 액세스 권한이 필요합니다.

사전 요구 사항

  • Loki를 사용하는 경우 최소 Loki Operator 버전 5.7 을 설치했습니다.
  • 프로젝트 관리자로 로그인해야 합니다.

프로세스

  • 테넌트당 액세스의 경우 개발자 화면을 사용하려면 netobserv-loki-reader 클러스터 역할과 netobserv-metrics-reader 네임스페이스 역할이 있어야 합니다. 이 액세스 수준에 대해 다음 명령을 실행합니다.

    $ oc adm policy add-cluster-role-to-user netobserv-loki-reader <user_group_or_name>
    $ oc adm policy add-role-to-user netobserv-metrics-reader <user_group_or_name> -n <namespace>
  • 클러스터 전체 액세스의 경우 비cluster-administrators에는 netobserv-loki-reader,cluster-monitoring-viewnetobserv-metrics-reader 클러스터 역할이 있어야 합니다. 이 시나리오에서는 관리자 화면 또는 개발자 화면을 사용할 수 있습니다. 이 액세스 수준에 대해 다음 명령을 실행합니다.

    $ oc adm policy add-cluster-role-to-user netobserv-loki-reader <user_group_or_name>
    $ oc adm policy add-cluster-role-to-user cluster-monitoring-view <user_group_or_name>
    $ oc adm policy add-cluster-role-to-user netobserv-metrics-reader <user_group_or_name>

4.5. Kafka 설치 (선택 사항)

Kafka Operator는 대규모 환경에서 지원됩니다. Kafka는 보다 탄력적이고 확장 가능한 방식으로 네트워크 흐름 데이터를 전달하기 위해 높은 처리량과 대기 시간이 짧은 데이터 피드를 제공합니다.

Loki Operator 및 Network Observability Operator가 설치된 것처럼 Operator Hub에서 Kafka Operator를 Red Hat AMQ Streams로 설치할 수 있습니다. Kafka를 스토리지 옵션으로 구성하려면 " FlowCollector 리소스 구성"을 참조하십시오.

참고

Kafka를 설치 제거하려면 설치하는 데 사용한 방법과 일치하는 제거 프로세스를 참조하십시오.

4.6. Network Observability Operator 설치 제거

OpenShift Container Platform 웹 콘솔 Operator Hub를 사용하여 Network Observability Operator를 설치 제거하고 EcosystemInstalled Operators 영역에서 작동합니다.

프로세스

  1. FlowCollector 사용자 지정 리소스를 제거합니다.

    1. 제공된 API 열에서 Network Observability Operator 옆에 있는 흐름 수집기 를 클릭합니다.
    2. 클러스터 의 옵션 메뉴 kebab 를 클릭하고 FlowCollector 삭제 를 선택합니다.
  2. Network Observability Operator를 설치 제거합니다.

    1. EcosystemInstalled Operators 영역으로 돌아갑니다.
    2. Network Observability Operator 옆에 있는 옵션 메뉴 kebab 를 클릭하고 Operator 설치 제거를 선택합니다.
    3. 프로젝트openshift-netobserv-operator선택
    4. 작업으로 이동하여 프로젝트 삭제를 선택합니다.
  3. FlowCollector CRD(사용자 정의 리소스 정의)를 제거합니다.

    1. 관리클러스터 리소스 정의로 이동합니다.
    2. FlowCollector 를 찾고 kebab 옵션 메뉴를 클릭합니다.
    3. Delete CustomResourceDefinition 을 선택합니다.

      중요

      Loki Operator 및 Kafka는 설치된 경우 그대로 유지되며 별도로 제거해야 합니다. 또한 오브젝트 저장소에 남아 있는 데이터와 제거해야 하는 영구 볼륨이 있을 수 있습니다.

5장. OpenShift Container Platform의 Network Observability Operator

OpenShift Container Platform용 Network Observability Operator는 모니터링 파이프라인을 배포합니다. 이 파이프라인은 eBPF 에이전트가 생성한 네트워크 트래픽 흐름을 수집하고 강화합니다.

5.1. 상태 보기

oc get 명령을 사용하여 FlowCollector 리소스 상태 및 eBPF 에이전트,flowlogs-pipeline 및 콘솔 플러그인 포드를 확인하여 Network Observability Operator의 작동 상태를 확인합니다.

Network Observability Operator는 Flow Collector API를 제공합니다. 흐름 수집기 리소스가 생성되면 Pod 및 서비스를 배포하여 Loki 로그 저장소에 네트워크 흐름을 생성 및 저장하고 OpenShift Container Platform 웹 콘솔에서 대시보드, 메트릭 및 흐름을 표시합니다.

프로세스

  1. 다음 명령을 실행하여 FlowCollector 의 상태를 확인합니다.

    $ oc get flowcollector/cluster

    출력 예

    NAME      AGENT   SAMPLING (EBPF)   DEPLOYMENT MODEL   STATUS
    cluster   EBPF    50                DIRECT             Ready

  2. 다음 명령을 입력하여 netobserv 네임스페이스에서 실행 중인 Pod의 상태를 확인합니다.

    $ oc get pods -n netobserv

    출력 예

    NAME                              READY   STATUS    RESTARTS   AGE
    flowlogs-pipeline-56hbp           1/1     Running   0          147m
    flowlogs-pipeline-9plvv           1/1     Running   0          147m
    flowlogs-pipeline-h5gkb           1/1     Running   0          147m
    flowlogs-pipeline-hh6kf           1/1     Running   0          147m
    flowlogs-pipeline-w7vv5           1/1     Running   0          147m
    netobserv-plugin-cdd7dc6c-j8ggp   1/1     Running   0          147m

    flowlogs-pipeline 포드는 흐름을 수집하여 수집된 흐름을 강화한 다음 Loki 스토리지로 흐름을 보냅니다. NetObserv-plugin Pod는 OpenShift Container Platform 콘솔의 시각화 플러그인을 생성합니다.

  3. 다음 명령을 입력하여 네임스페이스 netobserv-privileged 에서 실행 중인 Pod의 상태를 확인합니다.

    $ oc get pods -n netobserv-privileged

    출력 예

    NAME                         READY   STATUS    RESTARTS   AGE
    netobserv-ebpf-agent-4lpp6   1/1     Running   0          151m
    netobserv-ebpf-agent-6gbrk   1/1     Running   0          151m
    netobserv-ebpf-agent-klpl9   1/1     Running   0          151m
    netobserv-ebpf-agent-vrcnf   1/1     Running   0          151m
    netobserv-ebpf-agent-xf5jh   1/1     Running   0          151m

    netobserv-ebpf-agent Pod는 노드의 네트워크 인터페이스를 모니터링하여 흐름을 가져오고 flowlogs-pipeline pod로 보냅니다.

  4. Loki Operator를 사용하는 경우 다음 명령을 입력하여 netobserv 네임스페이스에서 LokiStack 사용자 지정 리소스의 component pod 상태를 확인하세요.

    $ oc get pods -n netobserv

    출력 예

    NAME                                                READY   STATUS    RESTARTS   AGE
    lokistack-compactor-0                               1/1     Running   0          18h
    lokistack-distributor-654f87c5bc-qhkhv              1/1     Running   0          18h
    lokistack-distributor-654f87c5bc-skxgm              1/1     Running   0          18h
    lokistack-gateway-796dc6ff7-c54gz                   2/2     Running   0          18h
    lokistack-index-gateway-0                           1/1     Running   0          18h
    lokistack-index-gateway-1                           1/1     Running   0          18h
    lokistack-ingester-0                                1/1     Running   0          18h
    lokistack-ingester-1                                1/1     Running   0          18h
    lokistack-ingester-2                                1/1     Running   0          18h
    lokistack-querier-66747dc666-6vh5x                  1/1     Running   0          18h
    lokistack-querier-66747dc666-cjr45                  1/1     Running   0          18h
    lokistack-querier-66747dc666-xh8rq                  1/1     Running   0          18h
    lokistack-query-frontend-85c6db4fbd-b2xfb           1/1     Running   0          18h
    lokistack-query-frontend-85c6db4fbd-jm94f           1/1     Running   0          18h

5.2. Network Observablity Operator 아키텍처

Network Observability Operator 아키텍처를 검토하여 FlowCollector 리소스에서 흐름을 수집하고 보강하는 eBPF 에이전트 를 관리하고 메트릭을 위해 Loki로 데이터를 전송하는 방법을 자세히 설명합니다.

Network Observability Operator는 설치 시 인스턴스화되고 eBPF 에이전트, flowlogs-pipelinenetobserv-plugin 구성 요소를 조정하도록 구성된 FlowCollector API를 제공합니다. 클러스터당 하나의 FlowCollector 만 지원됩니다.

eBPF 에이전트 는 네트워크 흐름을 수집할 수 있는 일부 권한이 있는 각 클러스터 노드에서 실행됩니다. flowlogs-pipeline 은 네트워크 흐름 데이터를 수신하고 Kubernetes 식별자를 사용하여 데이터를 보강합니다. Loki를 사용하도록 선택하는 경우 flowlogs-pipeline 은 저장 및 인덱싱을 위해 흐름 로그 데이터를 Loki로 보냅니다. 동적 OpenShift Container Platform 웹 콘솔 플러그인인 netobserv-plugin 은 Loki를 쿼리하여 네트워크 흐름 데이터를 가져옵니다. cluster-admins는 웹 콘솔에서 데이터를 볼 수 있습니다.

Loki를 사용하지 않는 경우 Prometheus를 사용하여 지표를 생성할 수 있습니다. 해당 메트릭 및 관련 대시보드는 웹 콘솔에서 액세스할 수 있습니다. 자세한 내용은 "Network Observability without Loki"를 참조하십시오.

Network Observability eBPF 내보내기 아키텍처

Network Observability Operator에는 세 가지 배포 모델 옵션이 있습니다.

참고

Network Observability Operator는 Loki 또는 기타 데이터 저장소를 관리하지 않습니다. Loki Operator를 사용하여 Loki를 별도로 설치해야 합니다. Kafka를 사용하는 경우 Kafka Operator를 사용하여 별도로 설치해야 합니다.

서비스 배포 모델
FlowCollector 리소스의 spec.deploymentModel 필드가 Service 로 설정되면 노드별로 데몬 세트로 배포됩니다. flowlogs-pipeline 은 서비스가 포함된 표준 배포입니다. spec.processor.consumerReplicas 필드를 사용하여 flowlogs-pipeline 구성 요소를 확장할 수 있습니다.
직접 배포 모델
spec.deploymentModel 필드가 Direct 로 설정되면 agent 및 flowlogs-pipeline 이 둘 다 노드당 데몬 세트로 배포됩니다. 이 모델은 기술 평가 및 소규모 클러스터에 적합합니다. 그러나 flowlogs-pipeline 의 각 인스턴스가 동일한 클러스터 정보를 캐시하므로 대규모 클러스터에서 메모리 효율이 줄어듭니다.
Kafka 배포 모델 (선택 사항)

Kafka 옵션을 사용하는 경우 eBPF 에이전트 는 네트워크 흐름 데이터를 Kafka로 보냅니다. spec.processor.consumerReplicas 필드를 사용하여 flowlogs-pipeline 구성 요소를 확장할 수 있습니다. flowlogs-pipeline 구성 요소는 다음 다이어그램에 표시된 대로 데이터를 Loki로 보내기 전에 Kafka 주제에서 읽습니다.

Kafka를 사용한 네트워크 Observability

5.3. Network Observability Operator 상태 및 구성 보기

oc describe flowcollector/cluster 명령을 사용하여 Network Observability Operator의 현재 상태, 구성 세부 정보 및 생성된 리소스를 검사합니다.

프로세스

  1. 다음 명령을 실행하여 Network Observability Operator의 상태 및 구성을 확인합니다.

    $ oc describe flowcollector/cluster

6장. Network Observability Operator 구성

구성 요소 구성 및 흐름 컬렉션 설정을 관리하도록 클러스터 전체 FlowCollector API 리소스(클러스터)를 업데이트하여 Network Observability Operator를 구성합니다.

설치 중에 FlowCollector 가 명시적으로 생성됩니다. 이 리소스는 클러스터 전체에서 작동하기 때문에 단일 FlowCollector 만 허용되며 cluster 라는 이름을 지정해야 합니다. 자세한 내용은 "FlowCollector API 참조"를 참조하십시오.

6.1. FlowCollector 리소스 보기

통합 설정, 고급 양식을 통해 OpenShift Container Platform 웹 콘솔에서 FlowCollector 리소스를 보고 수정하거나 YAML을 직접 편집하여 Network Observability Operator를 구성합니다.

프로세스

  1. 웹 콘솔에서 EcosystemInstalled Operators 로 이동합니다.
  2. NetObserv Operator제공된 API 제목에서 흐름 수집기 를 선택합니다.
  3. 클러스터를 선택한 다음 YAML 탭을 선택합니다. 여기에서 FlowCollector 리소스를 수정하여 Network Observability Operator를 구성할 수 있습니다.

6.1.1. FlowCollector 리소스의 예

eBPF 샘플링, 대화 추적, Loki 통합 및 콘솔 빠른 필터에 대한 구성을 보여주는 FlowCollector 사용자 정의 리소스의 포괄적인 주석이 있는 예를 검토합니다.

6.1.1.1. 샘플 FlowCollector 리소스
apiVersion: flows.netobserv.io/v1beta2
kind: FlowCollector
metadata:
  name: cluster
spec:
  namespace: netobserv
  deploymentModel: Service
  networkPolicy:
    enable: true
  agent:
    type: eBPF
    ebpf:
      sampling: 50
      privileged: false
      features: []
  processor:
    addZone: false
    subnetLabels:
      openShiftAutoDetect: true
      customLabels: []
    consumerReplicas: 3
  loki:
    enable: true
    mode: LokiStack
    lokiStack:
      name: loki
      namespace: netobserv-loki
  consolePlugin:
    enable: true
  exporters: []

다음과 같습니다.

spec.agent.type
eBPF 가 지원되는 유일한 OpenShift Container Platform 옵션이므로 eBPF여야 합니다.
spec.agent.ebpf.sampling
샘플링 간격을 지정합니다. 기본적으로 eBPF 샘플링은 50 으로 설정되므로 패킷은 샘플링될 가능성이 50개에서 1입니다. 더 낮은 샘플링 간격 값에는 더 많은 계산, 메모리 및 스토리지 리소스가 필요합니다. 값이 0 또는 1 이면 모든 패킷이 샘플링됩니다. 기본값으로 시작하고 클러스터의 최적 설정을 결정하려면 경험적으로 구체화하는 것이 좋습니다.
spec.agent.ebpf.privileged
eBPF 에이전트 Pod가 권한으로 실행되는지 여부를 지정합니다. 기본이 아닌 네트워크 모니터링 및 패킷 추적과 같은 여러 기능에는 privileged를 실행해야 합니다. 보안을 위해 최소 권한 원칙에 따라 이러한 기능 중 일부가 필요한 경우에만 활성화해야 합니다. true로 설정하지 않고 권한 있는 모드를 활성화한 경우 경고가 표시됩니다.
spec.processor.addZone
네트워크 흐름에 클라우드 가용성 영역을 삽입하는 데 사용됩니다.
spec.processor.subnetLabels
일치하는 CIDR에 따라 네트워크 흐름에 삽입할 사용자 지정 라벨 목록을 지정합니다.
spec.processor.consumerReplicas
프로세서 포드의 복제본 수(flowlogs-pipeline)를 지정합니다. 클러스터 크기에 따른 권장 사항은 리소스 관리 및 성능 고려 사항을 참조하십시오.
spec.loki.mode
설치 모드에 따라 Loki에 대한 연결을 구성하는 방법을 지정합니다. " Loki Operator 설치"에 설명된 설치 경로를 사용하는 경우 모드를 LokiStack 으로 설정하고 spec.loki.lokiStack 은 설치된 LokiStack 리소스 이름과 네임스페이스를 참조해야 합니다.
spec.loki.lokistack.namespace
LokiStack 리소스의 네임스페이스를 지정합니다. 이 값은 LokiStack 사용자 정의 리소스에 정의된 metadata.namespace 와 일치해야 합니다. 이 예제에서는 netobserv-loki 를 사용하지만 다른 구성 요소에 다른 네임스페이스를 사용할 수 있습니다.

6.2. Kafka를 사용하여 FlowCollector 리소스 구성

처리량이 높고 대기 시간이 짧은 데이터 피드에 Kafka를 사용하도록 FlowCollector 리소스를 구성합니다.

실행 중인 Kafka 인스턴스가 있어야 하며 OpenShift Container Platform 네트워크 Observability 전용 해당 인스턴스에 Kafka 주제를 생성해야 합니다. 자세한 내용은 AMQ Streams를 사용한 Kafka 문서를 참조하십시오.

사전 요구 사항

  • Kafka를 설치했습니다. Red Hat은 AMQ Streams Operator를 사용하여 Kafka를 지원합니다.

프로세스

  1. 웹 콘솔에서 EcosystemInstalled Operators 로 이동합니다.
  2. Network Observability Operator의 제공된 API 제목에서 흐름 수집기 를 선택합니다.
  3. 클러스터를 선택한 다음 YAML 탭을 클릭합니다.
  4. 다음 샘플 YAML에 표시된 대로 OpenShift Container Platform Network Observability Operator의 FlowCollector 리소스를 변경하여 Kafka를 사용합니다.

    FlowCollector 리소스의 Kafka 구성 샘플

    apiVersion: flows.netobserv.io/v1beta2
    kind: FlowCollector
    metadata:
      name: cluster
    spec:
      deploymentModel: Kafka
      kafka:
        address: "kafka-cluster-kafka-bootstrap.netobserv"
        topic: network-flows
        tls:
          enable: false

    다음과 같습니다.

    spec.deploymentModel
    배포 모델을 지정합니다. Kafka 배포 모델을 활성화하려면 Service 대신 Kafka로 설정합니다.
    spec.kafka.address
    Kafka 부트스트랩 서버 주소를 지정합니다. 필요한 경우 포트 9093에서 TLS를 사용하기 위해 kafka-cluster-kafka-bootstrap.netobserv:9093 과 같이 포트를 지정할 수 있습니다.
    spec.kafka.topic
    Kafka에서 생성된 주제의 이름을 지정합니다. Kafka에서 생성된 주제의 이름과 일치해야 합니다.
    spec.kafka.tls
    통신 암호화를 지정합니다. 이 설정을 사용하여 TLS 또는 mTLS를 사용하여 Kafka로의 모든 통신을 암호화합니다. 활성화된 경우 Kafka CA 인증서를 ConfigMap 또는 두 네임스페이스에서 Secret으로 사용할 수 있어야 합니다. flowlogs-pipeline 프로세서 구성 요소(기본값: netobserv)를 배포하는 네임스페이스와 eBPF 에이전트(기본값: netobserv-privileged)를 배포하는 네임스페이스입니다. spec.kafka.tls.caCert 를 사용하여 인증서를 참조합니다. mTLS를 사용하는 경우 이러한 네임스페이스에서 클라이언트 시크릿을 사용할 수 있도록 합니다. Red Hat AMQ Streams User Operator를 사용하여 시크릿을 생성할 수 있습니다. spec.kafka.tls.userCert 를 사용하여 시크릿을 참조합니다.

6.3. 보강된 네트워크 흐름 데이터 내보내기

Splunk 또는 Prometheus와 같은 툴을 통해 외부 소비를 위해 보강된 네트워크 흐름 데이터를 Kafka, IPFIX 또는 OpenTelemetry 엔드포인트에 동시에 내보내도록 FlowCollector 리소스를 구성합니다.

Kafka 또는 IPFIX의 경우 Splunk, Elasticsearch 또는 Fluentd와 같은 입력을 지원하는 모든 프로세서 또는 스토리지에서 보강된 네트워크 흐름 데이터를 사용할 수 있습니다.

OpenTelemetry의 경우 네트워크 흐름 데이터 및 메트릭은 OpenTelemetry 또는 Prometheus의 Red Hat 빌드와 같은 호환 가능한 OpenTelemetry 엔드포인트로 내보낼 수 있습니다.

구성 후 네트워크 흐름 데이터를 사용 가능한 출력으로 전송할 수 있습니다. 자세한 내용은 "네트워크 흐름 형식 참조"를 참조하십시오.

사전 요구 사항

  • Kafka, IPFIX 또는 OpenTelemetry 수집기 끝점은 네트워크 Observability flowlogs-pipeline Pod에서 사용할 수 있습니다.

프로세스

  1. 웹 콘솔에서 EcosystemInstalled Operators 로 이동합니다.
  2. NetObserv Operator제공된 API 제목에서 흐름 수집기 를 선택합니다.
  3. 클러스터를 선택한 다음 YAML 탭을 선택합니다.
  4. 다음과 같이 FlowCollector 를 편집하여 spec.exporters 를 구성합니다.

    apiVersion: flows.netobserv.io/v1beta2
    kind: FlowCollector
    metadata:
      name: cluster
    spec:
      exporters:
      - type: Kafka
          kafka:
            address: "kafka-cluster-kafka-bootstrap.netobserv"
            topic: netobserv-flows-export
            tls:
              enable: false
      - type: IPFIX
          ipfix:
            targetHost: "ipfix-collector.ipfix.svc.cluster.local"
            targetPort: 4739
            transport: tcp
     -  type: OpenTelemetry
          openTelemetry:
            targetHost: my-otelcol-collector-headless.otlp.svc
            targetPort: 4317
            type: grpc
            logs:
              enable: true
            metrics:
              enable: true
              prefix: netobserv
              pushTimeInterval: 20s
              expiryTime: 2m
       #    fieldsMapping:
       #      input: SrcAddr
       #      output: source.address

    다음과 같습니다.

    spec.exporters.type
    내보내기 유형을 지정합니다. IPFIX,OpenTelemetryKafka 로 개별적으로 또는 동시에 흐름을 내보낼 수 있습니다.
    spec.exporters.kafka.topic
    Network Observability Operator에서 모든 흐름을 내보내는 Kafka 주제를 지정합니다.
    spec.exporters.kafka.tls.enable
    SSL/TLS 또는 mTLS를 사용하여 Kafka 간 통신을 암호화할지 여부를 지정합니다. 활성화된 경우 Kafka CA 인증서를 ConfigMap 또는 flowlogs-pipeline 프로세서 구성 요소가 배포된 네임스페이스에서 Secret 으로 사용할 수 있어야 합니다(기본값: netobserv). spec.exporters.tls.caCert 를 사용하여 인증서를 참조합니다. mTLS의 경우 이러한 네임스페이스에서 클라이언트 시크릿도 사용할 수 있어야 하며 spec.exporters.tls.userCert 에서 참조해야 합니다.
    spec.exporters.ipfix.transport
    전송 프로토콜을 지정합니다. 기본값은 tcp 이지만 udp 를 지정할 수도 있습니다.
    spec.exporters.openTelemetry.type
    OpenTelemetry 연결 프로토콜을 지정합니다. 사용 가능한 옵션은 httpgrpc 입니다.
    spec.exporters.openTelemetry.logs
    로그 내보내기에 대한 OpenTelemetry 구성을 지정합니다. 이 구성은 Loki용으로 생성된 로그와 동일합니다.
    spec.exporters.openTelemetry.metrics
    지표 내보내기에 대한 OpenTelemetry 구성을 지정합니다. 이는 Prometheus에 대해 생성된 지표와 동일합니다. 이는 FlowCollector 리소스의 spec.processor.metrics.includeList 매개변수 또는 FlowMetrics 리소스를 통해 정의됩니다.
    spec.exporters.openTelemetry.metrics.pushTimeInterval
    OpenTelemetry 수집기로 메트릭을 전송하는 시간 간격을 지정합니다.
    spec.exporters.openTelemetry.fieldsMapping
    OpenTelemetry 형식 출력을 사용자 지정하는 선택적 매핑을 지정합니다. 네트워크 Observability 흐름 형식의 이름은 자동으로 OpenTelemetry 호환 형식으로 이름이 지정되지만 이 매개변수를 사용하면 사용자 지정 덮어쓰기가 가능합니다. 예를 들어 YAML 샘플에서 SrcAddr 는 Network Observability 입력 필드이며 OpenTelemetry 출력에서 source.address 로 이름이 변경됩니다. "네트워크 흐름 형식 참조"에서 Network Observability 및 OpenTelemetry 형식을 모두 볼 수 있습니다.

6.4. FlowCollector 리소스 업데이트

웹 콘솔을 사용하는 대신 oc patch 명령을 flowcollector 사용자 정의 리소스와 함께 사용하여 eBPF 샘플링과 같은 특정 사양을 신속하게 업데이트합니다.

프로세스

  1. 다음 명령을 실행하여 flowcollector CR을 패치하고 spec.agent.ebpf.sampling 값을 업데이트합니다.

    $ oc patch flowcollector cluster --type=json -p "[{"op": "replace", "path": "/spec/agent/ebpf/sampling", "value": <new value>}] -n netobserv"

6.5. 수집 시 네트워크 흐름 필터링

필터를 생성하여 생성된 네트워크 흐름 수를 줄입니다. 네트워크 흐름을 필터링하면 네트워크 관찰 구성 요소의 리소스 사용량을 줄일 수 있습니다.

두 종류의 필터를 구성할 수 있습니다.

  • eBPF 에이전트 필터
  • FlowLogs-pipeline 필터

6.5.1. eBPF 에이전트 필터

eBPF 에이전트 필터는 네트워크 흐름 수집 프로세스의 초기 단계에서 영향을 미치기 때문에 성능을 극대화합니다.

Network Observability Operator를 사용하여 eBPF 에이전트 필터를 구성하려면 "여러 규칙을 사용하여 eBPF 흐름 데이터 필터링"을 참조하십시오.

6.5.2. FlowLogs-pipeline 필터

FlowLogs-pipeline 필터는 나중에 네트워크 흐름 수집 프로세스에서 적용되므로 트래픽 선택을 보다 효과적으로 제어할 수 있습니다. 이는 주로 데이터 저장을 개선하는 데 사용됩니다.

FlowLogs-pipeline 필터는 다음 예와 같이 간단한 쿼리 언어를 사용하여 네트워크 흐름을 필터링합니다.

(srcnamespace="netobserv" OR (srcnamespace="ingress" AND dstnamespace="netobserv")) AND srckind!="service"

쿼리 언어에서는 다음 구문을 사용합니다.

Expand
표 6.1. 쿼리 언어 구문
카테고리Operator

논리 부울 연산자(대소문자 구분 아님)

또는

비교 연산자

= (Equals)

!= (수정되지 않음)

=~ (matches regexp)

!~ ( regexp와 일치하지 않음)

& lt ; <=(또는 같음)

& gt ; / >=(또는 같음)

단항 작업

with(field) (필드가 있음)

If (field) (field is absent)

FlowCollector 리소스의 spec.processor.filters 섹션에서 flowlogs-pipeline 필터를 구성할 수 있습니다. 예를 들면 다음과 같습니다.

YAML Flowlogs-pipeline 필터 예

apiVersion: flows.netobserv.io/v1beta2
kind: FlowCollector
metadata:
  name: cluster
spec:
  namespace: netobserv
  agent:
  processor:
    filters:
      - query: |
          (SrcK8S_Namespace="netobserv" OR (SrcK8S_Namespace="openshift-ingress" AND DstK8S_Namespace="netobserv"))
        outputTarget: Loki
        sampling: 10

다음과 같습니다.

spec.processor.filters.outputTarget
Loki,Prometheus 또는 외부 시스템과 같은 일치하는 흐름의 출력 대상을 지정합니다. 이 매개변수를 생략하면 시스템은 모든 구성된 출력으로 흐름을 보냅니다.
spec.processor.filters.sampling
저장 또는 내보낸 일치하는 흐름 수를 제한하는 선택적 샘플링 간격을 지정합니다. 예를 들어 값 10 은 흐름이 유지될 가능성이 10분의 1임을 의미합니다.

6.6. 빠른 필터 구성

사용 가능한 소스, 대상 및 범용 필터 키 목록을 사용하여 FlowCollector 리소스 내에서 빠른 필터를 수정합니다.

정확한 일치는 값에 대한 double-quotes를 사용할 수 있습니다. 그렇지 않으면 부분 일치가 텍스트 값에 사용됩니다. 키 끝에 배치된 bang(!) 문자는 부정을 의미합니다. YAML 수정에 대한 자세한 내용은 샘플 FlowCollector 리소스를 참조하십시오.

참고

일치하는 필터 유형은 "all of" 또는 "any of"는 사용자가 쿼리 옵션에서 수정할 수 있는 UI 설정입니다. 이 리소스는 이 리소스 구성의 일부가 아닙니다.

다음은 사용 가능한 모든 필터 키 목록입니다.

Expand
표 6.2. 키 필터링
Universal*소스대상설명

네임스페이스

src_namespace

dst_namespace

특정 네임스페이스와 관련된 트래픽을 필터링합니다.

name

src_name

dst_name

특정 pod, 서비스 또는 노드(호스트 네트워크 트래픽의 경우)와 같은 지정된 리프 리소스 이름과 관련된 트래픽을 필터링합니다.

kind

src_kind

dst_kind

지정된 리소스 유형과 관련된 트래픽을 필터링합니다. 리소스 종류에는 리프 리소스(Pod, 서비스 또는 노드) 또는 소유자 리소스(Deployment 및 StatefulSet)가 포함됩니다.

owner_name

src_owner_name

dst_owner_name

지정된 리소스 소유자, 즉 워크로드 또는 Pod 세트와 관련된 트래픽을 필터링합니다. 예를 들어 배포 이름, StatefulSet 이름 등이 될 수 있습니다.

resource

src_resource

dst_resource

고유하게 식별하는 표준 이름으로 표시되는 특정 리소스와 관련된 트래픽을 필터링합니다. canonical notation은 네임스페이스가 지정된 종류의 kind.namespace.name 또는 노드의 node.name 입니다. 예: Deployment.my-namespace.my-web-server.

address

src_address

dst_address

IP 주소와 관련된 트래픽을 필터링합니다. IPv4 및 IPv6이 지원됩니다. CIDR 범위도 지원됩니다.

mac

src_mac

dst_mac

MAC 주소와 관련된 트래픽을 필터링합니다.

port

src_port

dst_port

특정 포트와 관련된 트래픽을 필터링합니다.

host_address

src_host_address

dst_host_address

Pod가 실행 중인 호스트 IP 주소와 관련된 트래픽을 필터링합니다.

protocol

해당 없음

해당 없음

TCP 또는 UDP와 같은 프로토콜과 관련된 트래픽을 필터링합니다.

  • 소스 또는 대상에 대해 Universal keys filter for any of source or destination 예를 들어, name: 'my-pod'를 필터링하는 것은 모든 트래픽의 모든 트래픽을 my-podmy-pod로의 Match all 또는 Match any를 의미합니다.

6.7. 리소스 관리 및 성능 고려 사항

성능 기준을 관리하고 네트워크 관찰을 위해 리소스 소비를 최적화하는 데 필요한 eBPF 샘플링, 기능 활성화 및 리소스 제한을 포함한 주요 구성 설정을 검토합니다.

네트워크 관찰 기능에 필요한 리소스의 양은 클러스터의 크기와 관찰성 데이터를 수집하고 저장하는 클러스터의 요구 사항에 따라 달라집니다. 리소스를 관리하고 클러스터의 성능 기준을 설정하려면 다음 설정을 구성하는 것이 좋습니다. 이러한 설정을 구성하면 최적의 설정 및 관찰 기능 요구 사항이 충족될 수 있습니다.

다음 설정을 사용하면 처음부터 리소스 및 성능을 관리하는 데 도움이 될 수 있습니다.

eBPF 샘플링
Sampling 사양인 spec.agent.ebpf.sampling 을 설정하여 리소스를 관리할 수 있습니다. 기본적으로 eBPF 샘플링은 50 으로 설정되어 있으므로 흐름은 샘플링될 가능성이 50개에서 1입니다. 더 낮은 샘플링 간격 값에는 더 많은 계산, 메모리 및 스토리지 리소스가 필요합니다. 값이 0 또는 1 이면 모든 흐름이 샘플링됩니다. 기본값으로 시작하고 클러스터의 최적 설정을 결정하려면 경험적으로 구체화하는 것이 좋습니다.
eBPF 기능
활성화된 기능이 많을수록 CPU 및 메모리가 더 많이 영향을 받습니다. 이러한 기능의 전체 목록은 "네트워크 트래픽 예약"을 참조하십시오.
Loki 없이
Loki를 사용하지 않고 Prometheus를 사용하지 않고 Prometheus에 의존하는 방식으로 네트워크 관찰에 필요한 리소스 양을 줄일 수 있습니다. 예를 들어 Loki 없이 네트워크 관찰 기능을 구성할 때 메모리 사용량의 총 절감액은 20-65% 범위에 있으며 CPU 사용률은 샘플링 간격 값에 따라 10~30% 낮습니다. 자세한 내용은 "Network observability without Loki"를 참조하십시오.
인터페이스 제한 또는 제외
spec.agent.ebpf.interfacesspec.agent.ebpf.excludeInterfaces 값을 설정하여 전체 관찰 트래픽을 줄입니다. 기본적으로 에이전트는 excludeInterfaceslo (로컬 인터페이스)에 나열된 인터페이스를 제외하고 시스템의 모든 인터페이스를 가져옵니다. 인터페이스 이름은 사용된 CNI(Container Network Interface)에 따라 다를 수 있습니다.
성능 미세 조정

다음 설정을 사용하여 잠시 동안 Network Observability가 실행된 후 성능을 미세 조정할 수 있습니다.

  • 리소스 요구 사항 및 제한: spec.agent.ebpf.resourcesspec.processor.resources 사양을 사용하여 클러스터에서 예상되는 로드 및 메모리 사용량에 리소스 요구 사항 및 제한을 조정합니다. 대부분의 중간 크기의 클러스터에는 800MB의 기본 제한이 충분할 수 있습니다.
  • cache max flows timeout: eBPF 에이전트의 spec.agent.ebpf.cacheMaxFlowsspec.agent.ebpf.cacheActiveTimeout 사양을 사용하여 에이전트에서 보고하는 빈도를 제어합니다. 값이 클수록 에이전트가 더 적은 트래픽이 생성되므로 더 낮은 CPU 로드와 관련이 있습니다. 그러나 값이 클수록 메모리 사용량이 약간 길어지고 흐름 수집에서 대기 시간이 증가할 수 있습니다.

6.7.1. 리소스 고려 사항

Network Observability Operator 구성은 클러스터 워크로드 크기에 따라 조정할 수 있습니다. 다음 기준 예제를 사용하여 환경에 대한 적절한 리소스 제한 및 구성 설정을 확인합니다.

표에 설명된 예제에서는 특정 워크로드에 맞는 시나리오를 보여줍니다. 각 예제를 워크로드 요구 사항을 충족하기 위해 조정할 수 있는 기준으로만 고려해 보십시오.

이러한 권장 사항에 사용되는 테스트 베드는 다음과 같습니다.

  • 추가 small: 10-node 클러스터, 작업자당 4개의 vCPU 및 16GiB 메모리, LokiStack 크기 1x.extra- undercloud 에서는 AWS M6i 인스턴스에서 테스트합니다.
  • small: 25-node 클러스터, 작업자당 16개의 vCPU 및 64GiB 메모리, LokiStack 크기 1x. undercloud 에서는 AWS M6i 인스턴스에서 테스트합니다.
  • Large: 250-node 클러스터, 작업자당 16개의 vCPU 및 64GiB 메모리, LokiStack 크기 1x.medium 은 AWS M6i 인스턴스에서 테스트합니다. 작업자 및 컨트롤러 노드 외에도 3개의 인프라 노드(크기 M6i.12xlarge)와 워크로드 노드( M6i.8xlarge크기)를 테스트했습니다.
Expand
표 6.3. 클러스터 크기에 대한 리소스 권장 사항
기준추가 소규모(10개 노드)소규모(25개 노드)대규모(250 노드)

Operator 메모리 제한: 서브스크립션 spec.config.resources

400Mi (기본값)

400Mi (기본값)

400Mi (기본값)

eBPF 에이전트 샘플링 간격: FlowCollector spec.agent.ebpf.sampling

50 (기본값)

50 (기본값)

50 (기본값)

eBPF 에이전트 메모리 제한: FlowCollector spec.agent.ebpf.resources

800Mi (기본값)

800Mi (기본값)

1600Mi

eBPF 에이전트 캐시 크기: FlowCollector spec.agent.ebpf.cacheMaxSize

50,000

120,000 (기본값)

120,000 (기본값)

프로세서 메모리 제한: FlowCollector spec.processor.resources

800Mi (기본값)

800Mi (기본값)

800Mi (기본값)

프로세서 복제본: FlowCollector spec.processor.consumerReplicas

3 (기본값)

6

18

배포 모델: FlowCollector spec.deploymentModel

서비스 (기본값)

Kafka

Kafka

Kafka 파티션: Kafka 설치

해당 없음

48

48

Kafka 브로커: Kafka 설치

해당 없음

3 (기본값)

3 (기본값)

6.7.2. 총 평균 메모리 및 CPU 사용량

다른 eBPF 샘플링 값에서 두 개의 개별 트래픽 시나리오(테스트 1 및 테스트2 )에서 네트워크 관찰 가능성 구성 요소의 총 평균 CPU 및 메모리 사용량을 자세히 검토하십시오.

다음 표는 두 가지 테스트( 테스트 1테스트 2) 에 대한 샘플링 값이 150인 클러스터의 총 리소스 사용량 평균을 간략하게 보여줍니다. 테스트는 다음과 같은 방식으로 다릅니다.

  • 테스트 1 은 OpenShift Container Platform 클러스터의 총 네임스페이스, Pod 및 서비스 수 외에도 많은 수신 트래픽 볼륨을 고려하여 eBPF 에이전트를 로드하며 지정된 클러스터 크기에 대한 워크로드 수가 많은 사용 사례를 나타냅니다. 예를 들어 테스트 1 은 76 네임 스페이스, 5153 Pod 및 2305 서비스로 구성되며 네트워크 트래픽 규모는 ~350MB/s입니다.
  • 테스트 2 는 OpenShift Container Platform 클러스터의 총 네임스페이스, Pod 및 서비스 수 외에도 많은 수신 트래픽 볼륨을 고려하여 지정된 클러스터 크기에 대한 워크로드 수가 많은 사용 사례를 나타냅니다. 예를 들어 Test 2 는 553 네임 스페이스, 6998 Pod 및 2508 서비스로 구성되며 네트워크 트래픽 규모는 ~950MB/s입니다.

다양한 유형의 클러스터 사용 사례가 다른 테스트에서 예시되므로 이 표의 수는 병렬 비교 시 선형으로 확장되지 않습니다. 대신 개인 클러스터 사용량을 평가하기 위한 벤치마크로 사용하기 위한 것입니다. 표에 설명된 예제에서는 특정 워크로드에 맞는 시나리오를 보여줍니다. 각 예제를 워크로드 요구 사항을 충족하기 위해 조정할 수 있는 기준으로만 고려해 보십시오.

참고

Prometheus로 내보낸 지표는 리소스 사용량에 영향을 미칠 수 있습니다. 메트릭의 카디널리티 값은 영향을 받는 리소스를 결정하는 데 도움이 될 수 있습니다. 자세한 내용은 추가 리소스 섹션의 "네트워크 흐름 형식"을 참조하십시오.

Expand
표 6.4. 총 평균 리소스 사용량
샘플링 값사용된 리소스테스트 1개(25개의 노드)테스트 2개(250 노드)

Sampling = 50

총 NetObserv CPU 사용량

1.35

5.39

총 NetObserv RSS(메모리) 사용량

16GB

63 GB

Sampling = 1

총 NetObserv CPU 사용량

1.82

11.99

총 NetObserv RSS(메모리) 사용량

22 GB

87 GB

요약: 이 표에는 모든 기능이 활성화된 Agents, CryostatP, Kafka 및 Loki가 포함된 Network Observability의 평균 총 리소스 사용량이 표시됩니다. 활성화된 기능에 대한 자세한 내용은 이 테스트에서 사용할 수 있는 모든 기능을 포함하는 "네트워크 트래픽 예약"에서 다루는 기능을 참조하십시오.

7장. 테넌트당 네트워크 관찰 기능 모델

글로벌 클러스터 거버넌스를 유지하면서 FlowCollectorSlice 리소스를 사용하여 네트워크 트래픽 분석 관리를 프로젝트 관리자에게 위임합니다.

7.1. 테넌트별 계층 거버넌스 및 테넌트 autonomy

클러스터 관리자는 글로벌 거버넌스를 유지하면서 프로젝트 관리자가 특정 네임스페이스 내에서 네트워크 트래픽 관찰 기능을 관리할 수 있습니다.

Network Observability Operator는 계층적 구성 모델을 사용하여 멀티 테넌시를 지원합니다. 이 아키텍처는 클러스터 관리자 개입 없이 개별 팀에 셀프 서비스 가시성이 필요한 대규모 배포 및 호스팅된 컨트롤 플레인 환경에 유용합니다.

계층적 모델은 다음 구성 요소로 구성됩니다.

글로벌 거버넌스
클러스터 관리자는 글로벌 FlowCollector 리소스를 관리합니다. 이 리소스는 관찰 가능 인프라를 정의하고 테넌트별 구성이 허용되는지 여부를 결정합니다.
테넌트 autonomy
프로젝트 관리자는 FlowCollectorSlice 리소스를 관리합니다. 이 네임스페이스 범위의 CR(사용자 정의 리소스)을 사용하면 팀이 워크로드에 대한 특정 관찰 기능 설정을 정의할 수 있습니다.

7.2. 세분화된 흐름 수집을 위한 FlowCollectorSlice 리소스

FlowCollectorSlice 는 세분화된 다중 테넌트 네트워크 흐름 컬렉션을 가능하게 하는 CRD(사용자 정의 리소스 정의)입니다. 네임스페이스 또는 서브넷을 기반으로 논리 슬라이스를 정의하면 트래픽을 선택적으로 수집하고 전체 클러스터가 아닌 특정 워크로드에 사용자 정의 샘플링을 적용할 수 있습니다.

모든 트래픽에 균일하게 적용되는 단일 글로벌 구성 대신 세분화된 선택 및 다중 테넌트 인식 흐름 컬렉션을 활성화하여 기존 FlowCollector 사용자 지정 리소스를 보완합니다.

슬라이스 기반 컬렉션이 활성화되면 하나 이상의 FlowCollectorSlice 와 일치하는 트래픽만 수집되어 관리자가 모니터링되는 네트워크 흐름을 정확하게 제어할 수 있습니다.

7.2.1. FlowCollectorSlice의 이점

기본적으로 네트워크 흐름 컬렉션은 클러스터의 모든 트래픽에 균일하게 적용됩니다. 이로 인해 과도한 데이터 볼륨과 유연성이 제한될 수 있습니다.

FlowCollectorSlice 를 사용하면 다음과 같은 이점이 있습니다.

  • 특정 네임스페이스 또는 워크로드에 대해 선택적 흐름 컬렉션을 활성화합니다.
  • 멀티 테넌트 및 환경 기반 관찰 기능 지원
  • 관련 트래픽을 필터링하여 스토리지 및 처리 비용을 줄입니다.
  • 옵트인 구성을 통해 이전 버전과의 호환성을 유지합니다.

7.2.2. FlowCollector와 FlowCollectorSlice 간의 관계

FlowCollector 리소스는 클러스터에 대한 글로벌 흐름 수집 동작을 정의하지만, FlowCollectorSlice 리소스는 슬라이스 기반 필터링이 활성화된 경우 컬렉션에 적합한 트래픽을 정의합니다.

FlowCollector.spec.slicesConfig 필드는 슬라이스 정의가 적용되는 방법을 제어합니다.

7.2.3. 컬렉션 모드

슬라이스 동작은 FlowCollector.spec.slicesConfig.collectionMode 필드에 의해 관리됩니다. 필드를 다음 컬렉션 모드 중 하나로 설정합니다.

AlwaysCollect
  • 모든 클러스터 네임스페이스에서 네트워크 흐름을 수집합니다.
  • FlowCollectorSlice 리소스에 정의된 서브넷 및 샘플링 구성을 적용합니다.
  • FlowCollectorSlice 리소스의 네임스페이스 선택 논리를 무시합니다.
  • 이전 버전과의 호환성을 위해 기본 컬렉션 동작을 유지 관리합니다.
allowlist
  • 하나 이상의 FlowCollectorSlice 리소스와 일치하는 트래픽만 수집합니다.
  • 선택적 네임스페이스 허용 목록에는 컬렉션에서 선택한 네임스페이스가 포함됩니다.

7.2.4. FlowCollectorSlice 상태

FlowCollectorSlice 리소스는 다음을 보고하는 상태 하위 리소스를 노출합니다.

  • 검증 결과.
  • 조정 상태.
  • 슬라이스가 성공적으로 적용되었는지 여부입니다.

이 상태를 통해 관리자는 슬라이스 정의가 활성 상태이고 예상대로 작동하는지 확인할 수 있습니다.

7.3. Network Observability Operator FlowCollectorSlice 활성화

FlowCollector Slicor 리소스에서 FlowCollectorSlice 기능을 활성화하면 클러스터 관리자가 흐름 수집 및 데이터 강화 관리를 특정 네임스페이스에 위임할 수 있습니다.

프로젝트 관리자가 고유한 설정을 관리하려면 클러스터 관리자가 FlowCollector 사용자 지정 리소스를 활성화하여 FlowCollectorSlice 사용자 지정 리소스를 조사해야 합니다.

사전 요구 사항

  • Network Observability Operator가 설치되어 있습니다.
  • 클러스터에 FlowCollector 사용자 지정 리소스가 있습니다.
  • cluster-admin 권한이 있어야 합니다.

프로세스

  1. 다음 명령을 실행하여 FlowCollector 사용자 지정 리소스를 편집합니다.

    $ oc edit flowcollector cluster
  2. 슬라이스를 사용할 수 있는 네임스페이스를 정의하도록 spec.processor.slicesConfig 필드를 구성합니다.

    apiVersion: flows.netobserv.io/v1beta2
    kind: FlowCollector
    metadata:
      name: cluster
    spec:
      processor:
        slicesConfig:
          enable: true
          collectionMode: AllowList
          namespacesAllowList:
           - /openshift-.*|netobserv.*/

    다음과 같습니다.

    spec.processor.sliceConfig.enable
    FlowCollectorSlice 기능이 활성화되어 있는지 여부를 지정합니다. 그렇지 않으면 FlowCollectorSlice 의 모든 리소스가 무시됩니다.
    spec.processor.sliceConfig.collectionMode
    FlowCollectorSlice 사용자 지정 리소스가 흐름 컬렉션 프로세스에 영향을 미치는 방법을 지정합니다. AlwaysCollect 로 설정하면 FlowCollectorSlice 의 존재 여부에 관계없이 모든 흐름이 수집됩니다. AllowList 로 설정하면 FlowCollectorSlice 리소스가 있거나 글로벌 namespacesAllowList 를 통해 구성된 네임스페이스와 관련된 흐름만 수집됩니다.
    spec.processor.sliceConfig.namespacesAllowList

    해당 네임스페이스에 FlowCollectorSlice 의 존재 여부에 관계없이 항상 흐름이 수집되는 네임스페이스 목록을 지정합니다.

    참고

    namespacesAllowList 필드는 /openshift-.*/ 와 같은 정규식을 지원하여 여러 네임스페이스를 캡처하거나 netobserv 와 같은 엄격한 일치를 특정 네임스페이스와 일치시킬 수 있습니다.

  3. 변경 사항을 저장하고 편집기를 종료합니다.

검증

  • openshift- 로 시작하는 netobserv 네임스페이스 및 네임스페이스에서 네트워크 흐름만 웹 콘솔의 네트워크 트래픽 페이지에 표시되는지 확인합니다.

7.3.1. Network Observability Operator FlowCollectorSlice 비활성화

Network Observability Operator에서 슬라이스 기반 필터링을 비활성화하여 기존 FlowCollectorSlice 리소스를 보존하면서 글로벌 흐름 컬렉션을 재개합니다.

프로세스

  1. 다음 명령을 실행하여 FlowCollector 리소스를 편집합니다.

    $ oc edit flowcollector cluster
  2. spec.processor.slicesConfig.collectionMode 필드를 AlwaysCollect:로 설정합니다.

    apiVersion: flows.netobserv.io/v1beta2
    kind: FlowCollector
    metadata:
      name: cluster
    spec:
      processor:
        slicesConfig:
          enable: true
          collectionMode: AlwaysCollect
          ...
  3. 변경 사항을 저장합니다.

    흐름 컬렉션은 모든 트래픽에 대해 재개되며 기존 FlowCollectorSlice 리소스는 향후 사용할 수 있도록 계속 사용할 수 있습니다.

7.4. 프로젝트 관리자로 FlowCollectorSlice 구성

프로젝트 관리자는 분산된 네트워크 트래픽 분석을 위해 FlowCollectorSlice 사용자 정의 리소스를 구성하여 자체 네임스페이스 내에서 흐름 수집 및 데이터 강화를 관리할 수 있습니다.

사전 요구 사항

  • Network Observability Operator가 설치되어 있습니다.
  • 네임스페이스에 대한 project-admin 권한이 있습니다.

프로세스

  1. flowCollectorSlice.yaml 이라는 YAML 파일을 생성합니다.

    apiVersion: flows.netobserv.io/v1alpha1
    kind: FlowCollectorSlice
    metadata:
      name: flowcollectorslice-sample
      namespace: my-app
    spec:
      sampling: 1
      subnetLabels:
        - name: EXT:Database
          cidrs:
            - 192.168.50.0/24
  2. 다음 명령을 실행하여 구성을 적용합니다.

    $ oc apply -f flowCollectorSlice.yaml

검증

  1. OpenShift Container Platform 콘솔에서 모니터링네트워크 트래픽 으로 이동합니다.
  2. EXT:Database 레이블을 사용하여 192.168.50.0/24 서브넷으로의 흐름이 관찰되는지 확인합니다.

7.5. FlowCollectorSlice [flows.netobserv.io/v1alpha1]

설명
FlowCollectorSlice는 네임스페이스 테넌트당 일부 FlowCollector 구성을 분산할 수 있는 API입니다.
유형
object
Expand
속성유형설명

apiVersion

string

APIVersion은 버전이 지정된 이 오브젝트 표현의 스키마를 정의합니다. 서버는 인식된 스키마를 최신 내부 값으로 변환해야 하며 인식할 수 없는 값을 거부할 수 있습니다. 자세한 내용은 https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

kind

string

kind는 이 오브젝트가 나타내는 REST 리소스에 해당하는 문자열 값입니다. 서버는 클라이언트가 요청을 제출하는 끝점에서 이를 유추할 수 있습니다. CamelCase로 업데이트할 수 없습니다. 자세한 내용은 https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

메타데이터

object

표준 오브젝트의 메타데이터입니다. 자세한 내용은 https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

spec

object

FlowCollectorSliceSpec은 원하는 FlowCollectorSlice 상태를 정의합니다.

7.5.1. .metadata

설명
표준 오브젝트의 메타데이터입니다. 자세한 내용은 https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
유형
object

7.5.2. .spec

설명
FlowCollectorSliceSpec은 원하는 FlowCollectorSlice 상태를 정의합니다.
유형
object
Expand
속성유형설명

sampling

integer

샘플링 은 이 슬라이스에 적용할 선택적 샘플링 간격입니다. 예를 들어 값 50은 50 의 일치 흐름 1이 샘플링됨을 의미합니다.

subnetLabels

array

subnetLabels 를 사용하면 클러스터 외부 워크로드 또는 웹 서비스를 식별하기 위해 서브넷 및 IP 레이블을 사용자 지정할 수 있습니다. 기본 빠른 필터 및 제공된 일부 메트릭 예제에서 작업하려면 외부 서브넷에 EXT: 접두사 , 레이블이 지정되거나 전혀 레이블이 지정되지 않아야 합니다.

FlowCollectorSlice에 구성된 서브넷 레이블은 관련 네임스페이스의 흐름으로 제한되지 않습니다. 전체 클러스터의 흐름은 이 구성을 사용하여 레이블을 지정할 수 있습니다. 그러나 클러스터 범위의 FlowCollector에 정의된 서브넷 레이블은 규칙이 충돌하는 경우 우선합니다.

7.5.3. .spec.subnetLabels

설명

subnetLabels 를 사용하면 클러스터 외부 워크로드 또는 웹 서비스를 식별하기 위해 서브넷 및 IP 레이블을 사용자 지정할 수 있습니다. 기본 빠른 필터 및 제공된 일부 메트릭 예제에서 작업하려면 외부 서브넷에 EXT: 접두사 , 레이블이 지정되거나 전혀 레이블이 지정되지 않아야 합니다.

FlowCollectorSlice에 구성된 서브넷 레이블은 관련 네임스페이스의 흐름으로 제한되지 않습니다. 전체 클러스터의 흐름은 이 구성을 사용하여 레이블을 지정할 수 있습니다. 그러나 클러스터 범위의 FlowCollector에 정의된 서브넷 레이블은 규칙이 충돌하는 경우 우선합니다.

유형
array

7.5.4. .spec.subnetLabels[]

설명
SubnetLabel을 사용하면 클러스터 외부 워크로드 또는 웹 서비스를 식별하는 등의 서브넷 및 IP에 레이블을 지정할 수 있습니다.
유형
object
필수 항목
  • cidrs
  • name
Expand
속성유형설명

cidrs

배열(문자열)

["1.2.3.4/32"] 와 같은 CIDR 목록입니다.

name

string

일치하는 흐름에 플래그를 지정하는 데 사용되는 레이블 이름입니다. 기본 빠른 필터 및 제공된 일부 메트릭 예제에서 작업하려면 외부 서브넷에 EXT: 접두사 , 레이블이 지정되거나 전혀 레이블이 지정되지 않아야 합니다.

8장. Network Policy

관리자는 netobserv 네임스페이스에 대한 네트워크 정책을 생성할 수 있습니다. 이 정책은 Network Observability Operator에 대한 인바운드 및 아웃바운드 액세스를 보호합니다.

8.1. FlowCollector 사용자 정의 리소스를 사용하여 네트워크 정책 구성

수신 및 송신 네트워크 정책을 설정하여 Pod 트래픽을 제어할 수 있습니다. 이렇게 하면 보안이 강화되고 필요한 네트워크 흐름 데이터만 수집됩니다. 이렇게 하면 노이즈가 줄어들고 규정 준수가 지원되며 네트워크 통신에 대한 가시성이 향상됩니다.

네트워크 관찰 기능에 대한 송신 및 수신 네트워크 정책을 배포하도록 FlowCollector CR(사용자 정의 리소스)을 구성할 수 있습니다. 기본적으로 spec.NetworkPolicy.enable 사양은 true 로 설정됩니다.

네트워크 정책이 있는 다른 네임스페이스에 Loki, Kafka 또는 내보내기를 설치한 경우 네트워크 관찰 구성 요소가 해당 구성 요소와 통신할 수 있는지 확인해야 합니다. 설정에 대해 다음 사항을 고려하십시오.

  • Loki에 대한 연결 ( FlowCollector CR spec.loki 매개변수에 정의됨)
  • Kafka에 연결( FlowCollector CR spec.kafka 매개변수에 정의됨)
  • 모든 내보내기에 대한 연결( FlowCollector CR spec.exporters 매개변수에 정의됨)
  • Loki를 사용하고 정책 대상에 포함하는 경우 외부 오브젝트 스토리지( LokiStack 관련 보안에 정의됨)에 연결합니다.

프로세스

  1. 웹 콘솔에서 에코시스템설치된 Operator 페이지로 이동합니다.
  2. Network Observability에 대해 제공된 API에서 Flow Collector 를 선택합니다.
  3. 클러스터를 선택한 다음 YAML 탭을 선택합니다.
  4. FlowCollector CR을 구성합니다. 샘플 구성은 다음과 같습니다.

    네트워크 정책에 대한 FlowCollector CR의 예

    apiVersion: flows.netobserv.io/v1beta2
    kind: FlowCollector
    metadata:
      name: cluster
    spec:
      namespace: netobserv
      networkPolicy:
        enable: true
        additionalNamespaces: ["openshift-console", "openshift-monitoring"]
    # ...

    다음과 같습니다.

    spec.networkPolicy.enable
    네트워크 정책 관리를 활성화할지 여부를 지정합니다. 기본값은 true입니다.
    spec.networkPolicy.additionalNamespaces
    네트워크 정책에 포함할 네임스페이스를 지정합니다. 기본값은 ["openshift-console", "openshift-monitoring"] 입니다.

9장. 네트워크 관찰 기능 DNS 확인 분석

DNS 확인 분석에서 eBPF 기반 디코딩을 사용하여 서비스 검색 문제를 식별하고 단계를 수행하여 FlowCollector 리소스에서 DNS 추적을 활성화하여 도메인 이름으로 네트워크 흐름 레코드를 강화할 수 있습니다.

9.1. DNS 확인 분석의 전략적 이점

DNS 확인 분석을 사용하여 도메인 이름 및 상태 코드로 eBPF 흐름 레코드를 강화하여 네트워크 전송 실패와 서비스 검색 문제를 구분합니다.

표준 흐름 로그는 포트 53에서 트래픽이 발생한 경우에만 표시됩니다. DNS 확인 분석을 사용하면 다음 작업을 완료할 수 있습니다.

  • 식별할 시간 단축(Mtti): NXDOMAIN 오류와 같은 네트워크 라우팅 실패와 DNS 확인 실패 사이에 즉시 해제됩니다.
  • 내부 서비스 대기 시간 측정: CoreDNS가 특정 내부 조회(예: my-service.namespace.svc.cluster.local)에 응답하는 데 걸리는 시간을 추적합니다.
  • 감사 외부 종속성: 사이드카 또는 수동 패킷 캡처 없이도 워크로드가 통신하는 외부 API 또는 타사 도메인을 감사합니다.
  • 향상된 보안 상태: 내부 워크로드에서 쿼리하는 FQDN(정규화된 도메인 이름)을 감사하여 잠재적인 데이터 유출 또는 명령 및 제어(C2) 활동을 감지합니다.

9.1.1. DNS 흐름 강화

이 기능이 활성화되면 eBPF 에이전트는 흐름 레코드를 강화합니다. 이 메타데이터를 사용하면 소스 IP뿐만 아니라 연결(도메인)의 의도로 트래픽을 그룹화하고 필터링할 수 있습니다.

향상된 DNS 디코딩을 사용하면 eBPF 에이전트가 DNS 요청에 대한 쿼리 이름과 함께 포트 53에서 UDP 및 TCP DNS 트래픽을 검사할 수 있습니다.

9.2. 네트워크 관찰 기능에 대한 DNS 도메인 추적 구성

Network Observability Operator에서 DNS 추적을 활성화하여 클러스터 내에서 네트워크 흐름에 대한 DNS 쿼리 이름, 응답 코드 및 대기 시간을 모니터링합니다.

사전 요구 사항

  • Network Observability Operator가 설치되어 있습니다.
  • cluster-admin 권한이 있어야 합니다.
  • FlowCollector 사용자 지정 리소스에 대해 잘 알고 있습니다.

프로세스

  1. 다음 명령을 실행하여 FlowCollector 리소스를 편집합니다.

    $ oc edit flowcollector cluster
  2. DNS 추적 기능을 활성화하도록 eBPF 에이전트를 구성합니다.

    apiVersion: flows.netobserv.io/v1alpha1
    kind: FlowCollector
    metadata:
      name: cluster
    spec:
      agent:
        type: eBPF
        ebpf:
          features:
            - DNSTracking

    다음과 같습니다.

    spec.agent.type.ebpf.features
    eBPF 에이전트에 사용할 기능 목록을 지정합니다. DNS 추적을 활성화하려면 DNSTracking 을 이 목록에 추가합니다.
  3. 저장하고 편집기를 종료합니다.

검증

  1. OpenShift Container Platform 웹 콘솔에서 모니터링네트워크 트래픽 으로 이동합니다.
  2. 트래픽 흐름 보기에서 열 관리 아이콘을 클릭합니다.
  3. DNS 쿼리 이름, DNS 응답 코드 및 DNS 대기 시간 열이 선택되어 있는지 확인합니다.
  4. Port to 53 을 설정하여 결과를 필터링합니다.
  5. 흐름 테이블 열이 도메인 이름 및 DNS 메타데이터로 채워져 있는지 확인합니다.

9.3. DNS 흐름 강화 및 분석 참조

네트워크 흐름에 추가된 메타데이터를 식별하고, 네트워크 최적화를 위해 DNS 데이터를 활용하고, 클러스터에 미치는 성능 및 스토리지 영향을 파악합니다.

다음 표에서는 DNS 추적을 활성화할 때 네트워크 흐름에 추가된 메타데이터 필드를 설명합니다.

참고

압축 포인터 또는 캐시 제한으로 인해 쿼리 이름이 없거나 잘릴 수 있습니다.

Expand
표 9.1. DNS 흐름 메타데이터
필드설명

dns_query_name

쿼리되는 FQDN(정규화된 도메인 이름)입니다.

example.com

dns_response_code

DNS 서버에서 반환한 상태 코드입니다.

NOERROR,NXDomain

dns_id

쿼리와 응답 일치에 사용되는 트랜잭션 ID입니다.

45213

9.3.1. 네트워크 최적화를 위해 DNS 데이터 활용

다음 운영 결과에 대해 캡처된 DNS 메타데이터를 사용합니다.

  • 감사 외부 종속 항목: 권한이 없는 외부 API 또는 고위험 도메인에 워크로드가 도달하지 않도록 합니다.
  • 성능 튜닝: CoreDNS Pod에 추가 확장이 필요한지 또는 업스트림 DNS 공급자가 지연되는지 확인하기 위해 DNS 대기 시간을 모니터링합니다.

9.3.2. 잘못된 구성 오류 확인

높은 빈도의 NXDOMAIN 응답은 일반적으로 애플리케이션 코드 또는 오래된 환경 변수에서 서비스 검색 오류를 나타냅니다.

서비스 및 Pod에서 DNS 검색으로 인해 Kubernetes에서 NXDOMAIN 오류가 발생할 수 있습니다. 이러한 결과는 반드시 잘못된 URL 또는 손상된 URL을 나타내는 것은 아니지만 성능에 부정적인 영향을 미칠 수 있습니다.

my-svc.my-namespace.svc 와 같은 유효한 서비스 또는 Pod 호스트 이름에도 NXDOMAIN 오류가 반환되면 확인자가 다른 접미사에 대해 DNS를 쿼리하도록 구성됩니다. 정규화된 도메인 이름에 후행 점을 추가하여 이름을 모호하지 않음을 확인자에게 알릴 수 있습니다.

예를 들어 https://my-svc.my-namespace.svc 대신 https://my-svc.my-namespace.svc.cluster.local 를 후행 점과 함께 사용합니다.

9.3.3. Loki 스토리지 고려 사항

DNS 추적은 레이블 수와 흐름당 메타데이터 양을 늘립니다. Loki 스토리지 크기가 증가된 로그 볼륨을 수용하도록 조정되었는지 확인합니다.

10장. 네트워크 트래픽 관찰

관리자는 OpenShift Container Platform 웹 콘솔에서 네트워크 트래픽을 관찰하여 자세한 문제 해결 및 분석을 수행할 수 있습니다. 이 기능을 사용하면 트래픽 흐름의 다양한 그래픽 표현에서 통찰력을 얻을 수 있습니다.

10.1. 개요 보기에서 네트워크 트래픽 관찰

네트워크 트래픽 개요 보기는 집계된 흐름 지표와 애플리케이션 통신에 대한 시각적 통찰력을 제공합니다. 관리자는 메트릭을 사용하여 데이터 볼륨을 모니터링하고 연결 문제를 해결하며 클러스터 전체에서 비정상적인 트래픽 패턴을 감지할 수 있습니다.

개요 보기에는 OpenShift Container Platform 클러스터에서 집계 네트워크 트래픽이 표시되어 통신 중인 애플리케이션 및 전송되는 데이터를 확인할 수 있습니다. 최상위 트래픽 흐름 및 평균 바이트 비율과 함께 소스, 대상 및 흐름 유형별로 자세한 통찰력을 제공합니다.

관리자는 연결 문제를 해결하고 비정상적인 트래픽 패턴을 감지하고 애플리케이션 성능을 최적화할 수 있습니다. 네트워크 동작에 대한 간략한 개요를 제공하여 작업을 더 쉽게 우선시하고 리소스 사용량을 효율적으로 수행할 수 있습니다.

10.1.1. 개요 뷰 작업

OpenShift Container Platform 콘솔에서 네트워크 트래픽 개요 보기로 이동하여 흐름 속도 통계의 그래픽 표시를 확인하고 사용 가능한 옵션을 사용하여 표시 범위를 구성합니다.

사전 요구 사항

  • 관리자 권한으로 클러스터에 액세스합니다.

프로세스

  1. 모니터링네트워크 트래픽 으로 이동합니다.
  2. 네트워크 트래픽 페이지에서 개요 탭을 클릭합니다.
  3. 메뉴 아이콘을 클릭하여 각 흐름 속도 데이터의 범위를 구성합니다.

10.1.2. 개요 보기에 대한 고급 옵션 구성

흐름 속도 통계 및 트래픽 데이터 표시를 구체화하도록 그래프 범위, 라벨 잘림 및 패널 관리와 같은 고급 옵션을 구성하여 네트워크 트래픽 개요 보기를 사용자 지정합니다.

고급 옵션에 액세스하려면 고급 옵션 표시를 클릭합니다. Display options 드롭다운 메뉴를 사용하여 그래프에서 세부 정보를 구성할 수 있습니다. 사용 가능한 옵션은 다음과 같습니다.

  • 범위: 네트워크 트래픽이 이동하는 구성 요소를 보려면 선택합니다. Node, Namespace, Owner, Zones, Cluster 또는 Resource로 리소스 범위를 설정할 수 있습니다. 소유자는 리소스 집계입니다. 리소스는 호스트 네트워크 트래픽 또는 알 수 없는 IP 주소의 경우 Pod, 서비스, 노드일 수 있습니다. 기본값은 Namespace 입니다.
  • truncate 레이블: 드롭다운 목록에서 레이블의 필요한 너비를 선택합니다. 기본값은 M 입니다.
10.1.2.1. 패널 및 디스플레이 관리

표시할 패널을 선택하고, 다시 정렬하고, 특정 패널에 집중할 수 있습니다. 패널을 추가하거나 제거하려면 패널 관리를 클릭합니다.

기본적으로 다음 패널이 표시됩니다.

  • 상위 X 평균 바이트 비율
  • 합계로 누적된 상위 X 바이트 비율

패널 관리에서 다른 패널을 추가할 수 있습니다.

  • 상위 X 평균 패킷 속도
  • 총으로 누적된 상위 X 패킷 비율

쿼리 옵션을 사용하면 Top 5, Top 10, Top 15 개 비율을 표시할지 여부를 선택할 수 있습니다.

10.1.3. 패킷 드롭 추적

드롭 위치를 식별하고 호스트 또는 OVS별 드롭인 이유를 감지하고, 개요 보기에서 전용 그래픽 패널을 제공하는 eBPF 기반 패킷 드롭 추적을 사용하여 네트워크 패킷 손실을 모니터링하고 분석합니다.

개요 보기에서 패킷 손실을 사용하여 네트워크 흐름 레코드의 그래픽 표시를 구성할 수 있습니다. eBPF 추적점 후크를 사용하면 TCP, UDP, SCTP, ICMPv4 및 ICMPv6 프로토콜의 패킷 드롭에 대한 중요한 통찰력을 얻을 수 있으므로 다음과 같은 작업을 수행할 수 있습니다.

  • 식별: 패킷이 드롭되는 정확한 위치와 네트워크 경로를 지정합니다. 특정 장치, 인터페이스 또는 경로가 중단되기 더 쉽습니다.
  • 근본 원인 분석: eBPF 프로그램에서 수집한 데이터를 검사하여 패킷 드롭의 원인을 파악합니다. 예를 들어 혼잡, 버퍼 문제 또는 특정 네트워크 이벤트의 결과입니까?
  • 성능 최적화: 패킷의 명확한 그림에서는 버퍼 크기 조정, 라우팅 경로 재구성 또는 QoS(Quality of Service) 조치 구현과 같은 네트워크 성능을 최적화하는 단계를 수행할 수 있습니다.

패킷 드롭 추적이 활성화되면 기본적으로 개요 에서 다음 패널을 볼 수 있습니다.

  • 상위 X 패킷은 드롭 상태가 총으로 누적됨
  • 상위 X 패킷이 삭제되면 합계가 누적됩니다.
  • 상위 X 평균 삭제 패킷 속도
  • 상위 X는 합계를 사용하여 누적된 패킷 비율 삭제

패널 관리에서 다른 패킷 드롭 패널을 추가할 수 있습니다.

  • 상위 X 평균 감소 바이트 비율
  • 상위 X가 합계로 누적된 상위 바이트 비율
10.1.3.1. 패킷 드롭 유형

네트워크 관찰 기능에서 패킷 드롭 다운의 두 가지 종류(호스트 드롭 및 OVS 드롭)로 감지됩니다. 호스트 삭제에는 SKB_DROP 접두사가 붙고 OVS 드롭이 OVS_DROP 접두사가 붙습니다. 드롭된 흐름은 각 드롭 유형에 대한 설명에 대한 링크와 함께 트래픽 흐름 테이블의 측면 패널에 표시됩니다. 호스트 드롭 이유의 예는 다음과 같습니다.

  • SKB_DROP_REASON_NO_SOCKET: 소켓이 누락되어 패킷이 삭제됩니다.
  • SKB_DROP_REASON_TCP_CSUM: TCP 체크섬 오류로 인해 삭제된 패킷

OVS 드롭 이유의 예는 다음과 같습니다.

  • OVS_DROP_LAST_ACTION: 암시적 드롭 동작으로 인해 삭제된 OVS 패킷(예: 구성된 네트워크 정책으로 인해).
  • OVS_DROP_IP_TTL: 만료된 IP TTL으로 인해 삭제된 OVS 패킷

패킷 드롭 추적 활성화 및 작업에 대한 자세한 내용은 이 섹션의 추가 리소스 를 참조하십시오.

10.1.4. DNS 추적

eBPF 기반 DNS 추적을 사용하여 DNS 활동을 모니터링하여 쿼리 패턴에 대한 인사이트를 얻고, 보안 위협을 감지하고, 개요 보기의 전용 그래픽 패널을 통해 대기 시간 문제를 해결합니다.

개요 보기에서 네트워크 흐름의 DNS(Domain Name System) 추적을 그래픽으로 표시할 수 있습니다. eBPF(Extended Berkeley Packet Filter) 추적 후크와 함께 DNS 추적을 사용하면 다양한 용도로 사용할 수 있습니다.

  • 네트워크 모니터링: DNS 쿼리 및 응답에 대한 인사이트를 제공하여 네트워크 관리자가 비정상적인 패턴, 잠재적인 병목 또는 성능 문제를 식별할 수 있도록 지원합니다.
  • 보안 분석: 악성 코드가 사용하는 도메인 이름 생성 알고리즘(DGA)과 같은 의심스러운 DNS 활동을 감지하거나 보안 위반을 나타낼 수 있는 무단 DNS 확인을 식별합니다.
  • 문제 해결: DNS 확인 단계를 추적하고 대기 시간을 추적하며 잘못된 구성을 식별하여 DNS 관련 문제를 디버깅합니다.

기본적으로 DNS 추적이 활성화되면 개요 의 도넛 또는 행 차트에 표시되는 비어 있지 않은 메트릭을 확인할 수 있습니다.

  • 상위 X DNS 응답 코드
  • 전체 X 평균 DNS 대기 시간
  • 상위 X 90번째 백분위 DNS 대기 시간

패널 관리에 다른 DNS 추적 패널을 추가할 수 있습니다.

  • X 최소 DNS 대기 시간
  • 상위 X 최대 DNS 대기 시간
  • 상위 X 99번째 백분위 DNS 대기 시간

이 기능은 IPv4 및 IPv6 UDP 및 TCP 프로토콜에서 지원됩니다.

이 뷰 활성화 및 작업에 대한 자세한 내용은 이 섹션의 추가 리소스 를 참조하십시오.

10.1.5. Round-Trip Time

eBPF 후크 포인트를 사용하여 성능 병목 현상을 식별하고 개요 보기의 전용 패널을 통해 TCP 관련 문제를 해결하는 TCP Round-Trip Time (RTT) 지표를 사용하여 네트워크 흐름 대기 시간을 분석합니다.

TCP 원활한 Round-Trip Time(sRTT)을 사용하여 네트워크 흐름 대기 시간을 분석할 수 있습니다. fentry/tcp_rcv_ established ed eBPF 후크 포인트에서 캡처된 RTT를 사용하여 다음과 같이 TCP 소켓에서 sRTT를 읽을 수 있습니다.

  • 네트워크 모니터링: TCP 대기 시간에 대한 인사이트를 제공하여 네트워크 관리자가 비정상적인 패턴, 잠재적인 병목 또는 성능 문제를 식별할 수 있도록 지원합니다.
  • 문제 해결: 대기 시간을 추적하고 잘못된 구성을 식별하여 TCP 관련 문제를 디버깅합니다.

기본적으로 RTT가 활성화되면 개요 에 표시되는 TCP RTT 메트릭을 볼 수 있습니다.

  • 전반적으로 상위 X 90번째 백분위 TCP Round Trip Time
  • 상위 X 평균 TCP Round Trip Time
  • 최하 X 최소 TCP Round Trip Time

패널 관리에서 다른 RTT 패널을 추가할 수 있습니다.

  • top X 최대 TCP Round Trip Time with overall
  • 상위 X 99번째 백분위 TCP Round Trip Time

이 뷰 활성화 및 작업에 대한 자세한 내용은 이 섹션의 추가 리소스 를 참조하십시오.

10.1.6. eBPF 흐름 규칙 필터

eBPF 흐름 규칙 필터링을 사용하여 포트 및 CIDR 표기법을 기반으로 캡처 기준을 지정하고 전용 상태 대시보드 및 Prometheus 지표를 통해 필터 성능을 모니터링하여 패킷 캡처 볼륨을 제어합니다.

규칙 기반 필터링을 사용하여 eBPF 흐름 테이블에 캐시된 패킷의 볼륨을 제어할 수 있습니다. 예를 들어, 필터는 포트 100에서 들어오는 패킷만 캡처하도록 지정할 수 있습니다. 그런 다음 필터와 일치하는 패킷만 캡처되고 나머지 패킷만 삭제됩니다.

여러 필터 규칙을 적용할 수 있습니다.

10.1.6.1. 수신 및 송신 트래픽 필터링

CIDR(Classless Inter-Domain Routing) 표기법은 기본 IP 주소와 접두사 길이를 결합하여 IP 주소 범위를 효율적으로 나타냅니다. 수신 및 송신 트래픽의 경우 소스 IP 주소는 먼저 CIDR 표기법으로 구성된 필터 규칙을 일치시키는 데 사용됩니다. 일치하는 항목이 있는 경우 필터링이 진행됩니다. 일치하는 항목이 없는 경우 대상 IP는 CIDR 표기법으로 구성된 필터 규칙을 일치시키는 데 사용됩니다.

소스 IP 또는 대상 IP CIDR과 일치하는 후 peerIP 를 사용하여 특정 엔드포인트를 찾아 패킷의 대상 IP 주소를 구분할 수 있습니다. 프로비저닝된 작업을 기반으로 흐름 데이터는 eBPF 흐름 테이블에 캐시되거나 캐시되지 않습니다.

10.1.6.2. 대시보드 및 메트릭 통합

이 옵션이 활성화되면 eBPF 에이전트 통계Netobserv/Health 대시보드에 이제 필터링된 흐름 속도 보기가 표시됩니다. 또한, ObserveMetrics 에서 netobserv_agent_filtered_flows_total 을 쿼리하여 FlowFilterAcceptCounter,FlowFilterNoMatchCounter 또는 FlowFilterRecjectCounter 의 이유와 함께 메트릭을 관찰할 수 있습니다.

10.1.6.3. 흐름 필터 구성 매개변수

CIDR 범위, 필터 작업, 프로토콜 및 특정 포트 구성을 포함하여 FlowCollector 리소스에서 흐름 필터 규칙을 구성하는 데 필요한 및 선택적 매개 변수를 참조합니다.

Expand
표 10.1. 필수 구성 매개변수
매개변수설명

enable

eBPF 흐름 필터링 기능을 활성화하려면 enabletrue 로 설정합니다.

cidr

흐름 필터 규칙의 IP 주소 및 CIDR 마스크를 제공합니다. IPv4 및 IPv6 주소 형식을 모두 지원합니다. 모든 IP에 대해 일치시키려면 IPv4에 0.0.0.0/0 을 사용하거나 IPv6의 경우 ::/0 을 사용할 수 있습니다.

작업

흐름 필터 규칙에 대해 수행하는 작업을 설명합니다. 가능한 값은 Accept 또는 Reject 입니다.

  • Accept action matching 규칙의 경우 flow 데이터는 eBPF 테이블에 캐시되고 전역 메트릭인 FlowFilterAcceptCounter 로 업데이트됩니다.
  • Reject 작업 일치 규칙의 경우 흐름 데이터가 삭제되고 eBPF 테이블에 캐시되지 않습니다. 흐름 데이터는 글로벌 메트릭인 FlowFilterRejectCounter 로 업데이트됩니다.
  • 규칙이 일치하지 않으면 flow가 eBPF 테이블에 캐시되고 전역 메트릭인 FlowFilterNoMatchCounter 로 업데이트됩니다.
Expand
표 10.2. 선택적 구성 매개변수
매개변수설명

direction

흐름 필터 규칙의 방향을 정의합니다. 가능한 값은 Ingress 또는 Egress 입니다.

protocol

흐름 필터 규칙의 프로토콜을 정의합니다. 가능한 값은 TCP,UDP,SCTP,ICMP, ICMPv6 입니다.

tcpFlags

흐름을 필터링하는 TCP 플래그를 정의합니다. 가능한 값은 SYN,SYN-ACK,ACK,FIN,RST,PSH,URG,ECE,CWR,FIN-ACK, RST-ACK 입니다.

ports

흐름 필터링에 사용할 포트를 정의합니다. 소스 또는 대상 포트에 사용할 수 있습니다. 단일 포트를 필터링하려면 단일 포트를 정수 값으로 설정합니다. 예 : 포트: 80 포트 범위를 필터링하려면 문자열 형식으로 "start-end" 범위를 사용합니다. 예 : 포트: "80-100"

sourcePorts

흐름 필터링에 사용할 소스 포트를 정의합니다. 단일 포트를 필터링하려면 단일 포트를 정수 값으로 설정합니다(예: sourcePorts: 80 ). 포트 범위를 필터링하려면 "start-end" 범위 문자열 형식을 사용합니다(예: sourcePorts: "80-100" ).

destPorts

DestPorts는 흐름을 필터링하는 데 사용할 대상 포트를 정의합니다. 단일 포트를 필터링하려면 단일 포트를 정수 값으로 설정합니다(예: destPorts: 80 ). 포트 범위를 필터링하려면 문자열 형식으로 "start-end" 범위를 사용합니다(예: destPorts: "80-100" ).

icmpType

흐름 필터링에 사용할 ICMP 유형을 정의합니다.

icmpCode

흐름 필터링에 사용할 ICMP 코드를 정의합니다.

peerIP

흐름을 필터링하는 데 사용할 IP 주소를 정의합니다(예: 10.10.10.10 ).

10.1.7. 사용자 정의 네트워크

유연한 네트워크 분할에 UDN(사용자 정의 네트워크)을 사용하고 Network Observability Operator를 활용하여 트래픽 흐름 테이블의 전용 라벨 및 이름 필터를 통해 이러한 세그먼트를 모니터링하는 방법을 알아봅니다.

UDN(사용자 정의 네트워크)은 기본적으로 사용자 지정 계층 2 및 계층 3 네트워크 세그먼트를 활성화하여 Kubernetes pod 네트워크에 대한 기본 계층 3 토폴로지의 유연성 및 분할 기능을 개선합니다. 이러한 세그먼트는 기본 OVN-Kubernetes CNI 플러그인을 사용하는 컨테이너 Pod 및 가상 머신의 기본 또는 보조 네트워크 역할을 합니다.

UDN은 광범위한 네트워크 아키텍처 및 토폴로지를 지원하여 네트워크 유연성, 보안 및 성능을 향상시킵니다.

Network Observability를 사용하여 UDNMapping 기능을 활성화하면 트래픽 흐름 테이블에 UDN 레이블 열이 있습니다. 소스 네트워크 이름 및 대상 네트워크 이름을 필터링할 수 있습니다.

10.1.8. OVN-Kubernetes 네트워킹 이벤트

OVN-Kubernetes 네트워크 이벤트 추적을 사용하여 클러스터에서 네트워크 정책, 관리 네트워크 정책 및 송신 방화벽 규칙을 모니터링하고 감사합니다.

중요

OVN-Kubernetes 네트워킹 이벤트 추적은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

네트워크 이벤트 추적의 인사이트를 사용하여 다음 작업에 도움이 될 수 있습니다.

  • 네트워크 모니터링: 허용 및 차단된 트래픽을 모니터링하여 네트워크 정책 및 관리자 네트워크 정책에 따라 패킷이 허용되거나 차단되는지 여부를 감지합니다.
  • 네트워크 보안: 아웃바운드 트래픽을 추적하고 송신 방화벽 규칙을 준수하는지 확인할 수 있습니다. 무단 아웃바운드 연결을 감지하고 송신 규칙을 위반하는 아웃바운드 트래픽에 플래그를 지정합니다.

이 뷰 활성화 및 작업에 대한 자세한 내용은 이 섹션의 추가 리소스 를 참조하십시오.

10.2. 트래픽 흐름 보기에서 네트워크 트래픽 관찰

클러스터 구성 요소 간 실시간 및 기록 네트워크 통신을 모니터링하려면 트래픽 흐름 보기를 사용합니다. eBPF를 통해 수집된 세분화된 흐름 데이터를 분석하면 네트워크 트래픽을 감사하고 네트워크 정책을 검증하고 외부 보고 및 분석을 위해 데이터를 내보낼 수 있습니다.

Network Observability Operator의 트래픽 흐름 보기는 OpenShift Container Platform 클러스터 전체에서 네트워크 활동을 세부적으로 표현합니다. eBPF 기술을 활용하여 흐름 데이터를 수집함으로써 관리자는 Pod, 서비스 및 노드 간의 실시간 및 기록 통신을 모니터링할 수 있습니다. 이러한 가시성은 네트워크 트래픽을 감사하고, 네트워크 정책을 검증하고, 클러스터 인프라 내에서 예기치 않은 통신 패턴을 식별하는 데 중요합니다.

트래픽 흐름 인터페이스에서 개별 행과 상호 작용하여 자세한 흐름 정보를 검색하여 특정 연결 세부 정보를 분석할 수 있습니다. 보기는 행 밀도를 조정하고 열을 관리할 수 있는 표시 옵션 메뉴를 통해 고급 사용자 지정을 지원합니다. 특정 열을 선택하고 다시 정렬하면 테이블을 조정하여 소스 및 대상 끝점 또는 트래픽 볼륨과 같이 해당 환경의 가장 관련 데이터 지점을 강조 표시할 수 있습니다.By selecting and reordering specific columns, you can tailor the table to highlight the most relevant data points for your environment, such as source and destination endpoints or traffic volume.

외부 분석 및 보고를 지원하기 위해 트래픽 흐름 보기에는 데이터 내보내기 기능이 포함됩니다. 전체 데이터 세트를 내보내거나 특정 필드를 선택하여 네트워크 활동에 대한 대상 보고서를 생성할 수 있습니다. 이 기능을 통해 장기 감사 또는 타사 모니터링 툴에서 사용하기 위해 네트워크 흐름 데이터에 액세스할 수 있으므로 OpenShift Container Platform 환경의 네트워크 상태를 문서화하고 분석할 수 있는 유연한 방법을 제공합니다.

10.2.1. 트래픽 흐름 보기 작업

트래픽 흐름 테이블을 사용하여 자세한 네트워크 흐름 정보를 보고 분석합니다.

관리자는 트래픽 흐름 테이블로 이동하여 네트워크 흐름 정보를 볼 수 있습니다.

사전 요구 사항

  • 관리자 액세스 권한이 있습니다.

프로세스

  1. 모니터링네트워크 트래픽 으로 이동합니다.
  2. 네트워크 트래픽 페이지에서 트래픽 흐름 탭을 클릭합니다.
  3. 각 행을 클릭하여 해당 흐름 정보를 가져옵니다.

10.2.2. 트래픽 흐름 표시 설정

트래픽 흐름 보기에는 디스플레이 밀도, 데이터 열 및 데이터 내보내기 옵션을 사용자 지정하는 설정이 포함되어 있습니다.

10.2.2.1. 표시 옵션

다음 요소는 트래픽 흐름 보기에서 사용할 수 있습니다.

고급 옵션 표시
현재 뷰를 사용자 지정하고 내보낼 메뉴를 지정합니다.
디스플레이 옵션 드롭다운
데이터 테이블의 행 크기를 지정합니다. 기본값은 Normal 입니다.
열 관리
트래픽 흐름 테이블에 표시된 열을 선택하고 재정렬하는 대화 상자를 지정합니다.

10.2.3. 트래픽 흐름 데이터 내보내기

트래픽 흐름 보기에서 네트워크 흐름 데이터를 외부 분석 또는 보고를 위해 CSV 파일로 내보냅니다.

프로세스

  1. 데이터 내보내기 를 클릭합니다.
  2. 창에서 모든 데이터를 내보내려면 Export all data 확인란을 선택하고, 내보낼 필수 필드를 선택하려면 확인란을 지웁니다.
  3. 내보내기 를 클릭합니다.

10.2.4. FlowCollector 사용자 지정 리소스로 IPsec 구성

FlowCollector 리소스에서 IPsec 추적을 활성화하여 암호화된 트래픽을 모니터링하고, IPsec 상태 열을 트래픽 흐름 보기에 추가하고, 전용 암호화 대시보드를 생성합니다.

OpenShift Container Platform에서 IPsec은 기본적으로 비활성화되어 있습니다. " IPsec 암호화 구성"의 지침에 따라 IPsec을 활성화할 수 있습니다.

사전 요구 사항

  • OpenShift Container Platform에서 IPsec 암호화를 활성화했습니다.

프로세스

  1. 웹 콘솔에서 EcosystemInstalled Operators 로 이동합니다.
  2. NetObserv Operator제공된 API 제목에서 흐름 수집기 를 선택합니다.
  3. 클러스터를 선택한 다음 YAML 탭을 선택합니다.
  4. IPsec에 대한 FlowCollector 사용자 정의 리소스를 구성합니다.

    IPsec에 대한 FlowCollector 구성 예

    apiVersion: flows.netobserv.io/v1beta2
    kind: FlowCollector
    metadata:
      name: cluster
    spec:
      namespace: netobserv
      agent:
        type: eBPF
        ebpf:
          features:
          - "IPSec"

검증

IPsec이 활성화된 경우:

  • IPsec Status 라는 새 열이 네트워크 관찰 기능 트래픽 흐름 뷰에 표시되어 흐름이 IPsec 암호화되었는지 또는 암호화/암호 해독 중에 오류가 있는지 여부를 표시합니다.
  • 암호화된 트래픽의 백분율을 보여주는 새 대시보드가 생성됩니다.

10.2.5. 대화 추적 작업

웹 콘솔에서 관련 네트워크 흐름을 그룹화하고 분석하기 위한 대화 추적을 사용하도록 FlowCollector 사용자 지정 리소스를 구성합니다.

관리자는 동일한 대화의 일부인 네트워크 흐름을 그룹화할 수 있습니다. 대화는 IP 주소, 포트 및 프로토콜로 식별되는 피어 그룹화로 정의되므로 고유한 대화 ID가 생성됩니다. 웹 콘솔에서 대화 이벤트를 쿼리할 수 있습니다. 이러한 이벤트는 웹 콘솔에서 다음과 같이 표시됩니다.

  • 대화 시작: 이 이벤트는 연결이 시작되거나 TCP 플래그가 인터셉트될 때 발생합니다.
  • 대화 눈금: 이 이벤트는 연결이 활성화된 동안 FlowCollector spec.processor.conversationHeartbeatInterval 매개변수에 정의된 각 지정된 간격으로 수행됩니다.
  • 대화 종료: 이 이벤트는 FlowCollector spec.processor.conversationEndTimeout 매개변수에 도달하거나 TCP 플래그를 가로챌 때 발생합니다.
  • 흐름: 지정된 간격 내에 발생하는 네트워크 트래픽 흐름입니다.

프로세스

  1. 웹 콘솔에서 EcosystemInstalled Operators 로 이동합니다.
  2. NetObserv Operator제공된 API 제목에서 흐름 수집기 를 선택합니다.
  3. 클러스터를 선택한 다음 YAML 탭을 선택합니다.
  4. spec.processor.logTypes,conversationEndTimeoutconversationHeartbeatInterval 매개변수가 관찰 요구 사항에 따라 설정되도록 FlowCollector 사용자 지정 리소스를 구성합니다. 샘플 구성은 다음과 같습니다.

    대화 추적을 위한 FlowCollector 구성

    apiVersion: flows.netobserv.io/v1beta2
    kind: FlowCollector
    metadata:
      name: cluster
    spec:
     processor:
      logTypes: Flows
      advanced:
       conversationEndTimeout: 10s
       conversationHeartbeatInterval: 30s

    다음과 같습니다.

    spec.processor.logTypes
    내보낼 이벤트 유형을 지정합니다. Flows 로 설정하면 Flow 이벤트만 내보내집니다. All 으로 설정하면 대화 및 흐름 이벤트가 모두 내보내 네트워크 트래픽 페이지에 표시됩니다. 대화 이벤트에만 집중하려면 Conversation start,Conversation tick, Conversation end events를 지정합니다. 대화 끝 이벤트만 내보내려면 EndedConversations 를 지정합니다. EndedConversations 의 경우 스토리지 요구 사항이 All 및 lowest에서 가장 높습니다.
    spec.processor.advanced.conversationEndTimeout
    시간 초과에 도달하거나 TCP 플래그를 가로채면 Conversation end 이벤트가 트리거되는 기간을 지정합니다.
    spec.processor.advanced.conversationHeartbeatInterval

    네트워크 연결이 활성화된 동안 Conversation tick 이벤트 간격을 지정합니다.

    참고

    logType 옵션을 업데이트하면 이전 선택의 흐름이 콘솔 플러그인에서 명확하지 않습니다. 예를 들어, 처음에 logType 을 오전 10시까지 시간 범위에 대한 Conversations 로 설정한 다음 EndedConversations 로 이동하는 경우 콘솔 플러그인은 오전 10시 이전의 모든 대화 이벤트를 표시하고 10 AM 이후의 대화만 종료합니다.

  5. 트래픽 흐름 탭에서 네트워크 트래픽 페이지를 새로 고칩니다. 두 개의 새 열인 Event/TypeConversation Id 가 있습니다. 모든 이벤트/유형 필드는 Flow 가 선택한 쿼리 옵션인 경우 Flow 입니다.
  6. 쿼리 옵션을 선택하고 로그 유형,대화 유형을 선택합니다. 이제 이벤트/유형 이 원하는 대화 이벤트를 모두 표시합니다.
  7. 다음으로 특정 대화 ID를 필터링하거나 측면 패널에서 대화흐름 로그 유형 옵션을 전환할 수 있습니다.

10.2.6. 패킷 드롭 작업

웹 콘솔에서 네트워크 데이터 손실을 모니터링하고 시각화하도록 FlowCollector 리소스를 구성하여 Network Observability Operator에서 패킷 드롭 추적을 활성화합니다.

패킷 손실은 하나 이상의 네트워크 흐름 데이터가 대상에 도달하지 못하는 경우 발생합니다. 다음 YAML 예제의 사양에 대해 FlowCollector 를 편집하여 이러한 드롭을 추적할 수 있습니다.

중요

이 기능이 활성화되면 CPU 및 메모리 사용량이 증가합니다.

프로세스

  1. 웹 콘솔에서 EcosystemInstalled Operators 로 이동합니다.
  2. NetObserv Operator제공된 API 제목에서 흐름 수집기 를 선택합니다.
  3. 클러스터를 선택한 다음 YAML 탭을 선택합니다.
  4. 패킷 드롭에 대한 FlowCollector 사용자 정의 리소스를 구성합니다. 예를 들면 다음과 같습니다.

    FlowCollector 구성 예

    apiVersion: flows.netobserv.io/v1beta2
    kind: FlowCollector
    metadata:
      name: cluster
    spec:
      namespace: netobserv
      agent:
        type: eBPF
        ebpf:
          features:
           - PacketDrop
          privileged: true

    다음과 같습니다.

    spec.agent.ebpf.features
    활성화할 기능을 지정합니다. 각 네트워크 흐름에 대한 패킷 드롭을 시작하기 위해 PacketDrop 을 포함합니다.
    spec.agent.ebpf.privileged
    권한 모드가 활성화되었는지 여부를 지정합니다. 패킷 드롭 추적에 대해 true 로 설정해야 합니다.

검증

  • 네트워크 트래픽 페이지를 새로 고칠 때 개요,트래픽 흐름토폴로지 보기에 패킷 삭제에 대한 새 정보가 표시됩니다.

    1. 패널 관리에서 새 선택 항목을 선택하여 개요 에 표시할 패킷의 그래픽 시각화를 선택합니다.
    2. 관리에서 새 선택 항목을 선택하여 트래픽 흐름 테이블에 표시할 패킷 드롭 정보를 선택합니다.

      1. 트래픽 흐름 보기에서 측면 패널을 확장하여 패킷 드롭에 대한 자세한 정보를 볼 수도 있습니다. 호스트 삭제에는 SKB_DROP 접두사가 붙고 OVS 드롭이 OVS_DROP 접두사가 붙습니다.
    3. 토폴로지 보기에서 드롭이 있는 빨간색 행이 표시됩니다.

10.2.7. DNS 추적 작업

웹 콘솔에서 네트워크 성능, 보안 분석 및 DNS 문제 해결을 위해 DNS 추적을 사용하도록 FlowCollector 사용자 지정 리소스를 구성합니다.

다음 YAML 예제의 사양으로 FlowCollector 를 편집하여 DNS를 추적할 수 있습니다.

중요

이 기능이 활성화되면 CPU 및 메모리 사용량 증가가 eBPF 에이전트에서 관찰됩니다.

프로세스

  1. 웹 콘솔에서 EcosystemInstalled Operators 로 이동합니다.
  2. Network Observability에 대해 제공된 API에서 Flow Collector 를 선택합니다.
  3. 클러스터를 선택한 다음 YAML 탭을 선택합니다.
  4. FlowCollector 사용자 지정 리소스를 구성합니다. 샘플 구성은 다음과 같습니다.

    DNS 추적을 위한 FlowCollector 구성

    apiVersion: flows.netobserv.io/v1beta2
    kind: FlowCollector
    metadata:
      name: cluster
    spec:
      namespace: netobserv
      agent:
        type: eBPF
        ebpf:
          features:
           - DNSTracking
          sampling: 1

    • spec.agent.ebpf.features 매개변수 목록을 설정하여 웹 콘솔에서 각 네트워크 흐름의 DNS 추적을 활성화할 수 있습니다.
    • 더 정확한 메트릭을 위해 샘플링1 값으로 설정하고 DNS 대기 시간을 캡처할 수 있습니다. 1보다 큰 샘플링 값의 경우 DNS 응답 코드DNS Id 를 사용하여 흐름을 확인할 수 있으며 DNS Latency 시간을 확인할 수 없습니다.
  5. 네트워크 트래픽 페이지를 새로 고칠 때 개요 및 트래픽 흐름 보기 및 적용할 수 있는 새 필터에서 볼 수 있는 새로운 DNS 표현이 있습니다.

    1. 패널 관리에서 새 DNS 선택 사항을 선택하여 개요 에 그래픽 시각화 및 DNS 지표를 표시합니다.
    2. 관리에서 새 선택 항목을 선택하여 트래픽 흐름 보기에 DNS 열을 추가합니다.
    3. DNS Id,DNS Error DNS LatencyDNS Response Code 와 같은 특정 DNS 메트릭을 필터링하고 사이드 패널에서 자세한 정보를 확인합니다. DNS 대기 시간DNS 응답 코드 열이 기본적으로 표시됩니다.

      참고

      TCP 핸드셰이크 패킷에는 DNS 헤더가 없습니다. DNS 헤더가 없는 TCP 프로토콜은 "n/a"의 DNS 대기 시간,ID응답 코드 값을 사용하여 트래픽 흐름 데이터에 표시됩니다. 흐름 데이터를 필터링하여 "0"과 같은 Common filter "DNSError"를 사용하여 DNS 헤더가 있는 흐름만 볼 수 있습니다.

10.2.8. RTT 추적 작업

웹 콘솔을 사용하여 클러스터 전체에서 네트워크 대기 시간을 모니터링하고 분석하도록 FlowCollector 사용자 지정 리소스를 구성하여 RTT(Round Trip Time) 추적을 활성화합니다.

다음 YAML 예제의 사양으로 FlowCollector 를 편집하여 RTT를 추적할 수 있습니다.

프로세스

  1. 웹 콘솔에서 EcosystemInstalled Operators 로 이동합니다.
  2. NetObserv Operator제공된 API 제목에서 흐름 수집기 를 선택합니다.
  3. 클러스터를 선택한 다음 YAML 탭을 선택합니다.
  4. RTT 추적을 위한 FlowCollector 사용자 정의 리소스를 구성합니다. 예를 들면 다음과 같습니다.

    FlowCollector 구성 예

    apiVersion: flows.netobserv.io/v1beta2
    kind: FlowCollector
    metadata:
      name: cluster
    spec:
      namespace: netobserv
      agent:
        type: eBPF
        ebpf:
          features:
           - FlowRTT

    다음과 같습니다.

    spec.agent.ebpf.features
    활성화할 eBPF 기능 목록을 지정합니다. 이 목록에 FlowRTT 를 추가하여 RTT(Round-trip Time) 네트워크 흐름 추적을 시작합니다.

검증

네트워크 트래픽 페이지가 새로 고쳐지면 개요,트래픽 흐름토폴로지 보기에 RTT 정보가 표시됩니다.

  1. 개요 보기에서 패널 관리를 클릭하여 표시할 RTT 그래픽 시각화를 선택합니다.
  2. 트래픽 흐름 테이블에서 Flow RTT 열이 기본적으로 표시되는지 확인합니다. 열을 관리하려면 열 관리를 클릭합니다.
  3. 트래픽 흐름 보기에서 측면 패널을 확장하여 RTT 메타데이터를 확인합니다.

    1. 필터 검색 창에 protocol= TCP 를 입력하여 TCP 프로토콜의 흐름 데이터를 필터링합니다.
    2. 모든 TCP 필터링된 흐름에 FlowRTT 값이 0 보다 큰지 확인합니다.
    3. 필터 검색 창에 time_flow_rtt>=10000000 을 입력하여 10,000,000 나노초(10ms)보다 큰 FlowRTT 값을 필터링합니다.
    4. 필터를 제거합니다.
  4. 토폴로지 보기에서 표시 옵션 드롭다운 메뉴를 클릭합니다. 에지 라벨 목록에서 RTT 를 선택합니다.

10.2.9. eBPF Manager Operator 작업

eBPF Manager Operator를 Network Observability와 통합하여 eBPF 프로그램을 관리하고 권한 있는 에이전트 권한의 필요성을 줄입니다.

eBPF Manager Operator는 모든 eBPF 프로그램을 관리하여 공격 면적을 줄이고 규정 준수, 보안 및 충돌 방지를 보장합니다. Network observability는 eBPF Manager Operator를 사용하여 후크를 로드할 수 있습니다. 따라서 더 이상 eBPF 에이전트에 권한 있는 모드 또는 CAP_BPFCAP_PERFMON 과 같은 추가 Linux 기능을 제공할 필요가 없습니다. 네트워크 관찰 기능이 있는 eBPF Manager Operator는 64비트 AMD 아키텍처에서만 지원됩니다.

중요

네트워크 관찰 기능을 사용하는 eBPF Manager Operator는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

프로세스

  1. 웹 콘솔에서 EcosystemOperator Hub 로 이동합니다.
  2. eBPF Manager 를 설치합니다.
  3. bpfman 네임스페이스에서 워크로드Pod 를 확인하여 모두 실행 중인지 확인합니다.
  4. eBPF Manager Operator를 사용하도록 FlowCollector 사용자 정의 리소스를 구성합니다.

    FlowCollector 구성 예

    apiVersion: flows.netobserv.io/v1beta2
    kind: FlowCollector
    metadata:
      name: cluster
    spec:
      agent:
        ebpf:
          features:
            - EbpfManager

검증

  1. 웹 콘솔에서 EcosystemInstalled Operators 로 이동합니다.
  2. eBPF Manager Operator모든 인스턴스 탭을 클릭합니다.

    각 노드에 대해 netobserv 라는 BpfApplicationBpfProgram 오브젝트 쌍, 하나는 트래픽 제어(TCx) 수신용이고 다른 하나는 TCx 송신에 대해 있는지 확인합니다. 다른 eBPF 에이전트 기능을 활성화하면 더 많은 개체가 있을 수 있습니다.

10.2.10. 히스토그램 사용

히스토그램은 트래픽 볼륨 추세를 분석하고 특정 시간 간격에 따라 흐름 데이터를 필터링하는 데 사용할 수 있는 네트워크 흐름 로그를 시각화합니다.

히스토그램 표시를 클릭하여 흐름 기록을 가로 막대형 차트로 시각화하기 위한 도구 모음 보기를 표시할 수 있습니다. 히스토그램은 시간에 따른 로그 수를 보여줍니다. 히스토그램의 일부를 선택하여 도구 모음을 따르는 테이블에서 네트워크 흐름 데이터를 필터링할 수 있습니다.

10.2.11. 가용성 영역 작업

가용성 영역 데이터를 수집하도록 FlowCollector 사용자 지정 리소스를 구성하여 웹 콘솔의 여러 클러스터 영역에서 네트워크 트래픽을 시각화하고 분석할 수 있습니다.

클러스터 가용성 영역에 대한 정보를 수집하도록 FlowCollector 를 구성할 수 있습니다. 이를 통해 노드에 적용된 topology.kubernetes.io/zone 레이블 값을 사용하여 네트워크 흐름 데이터를 강화할 수 있습니다.

프로세스

  1. 웹 콘솔에서 에코시스템 → 설치된 Operator 로 이동합니다.
  2. NetObserv Operator제공된 API 제목에서 흐름 수집기 를 선택합니다.
  3. 클러스터를 선택한 다음 YAML 탭을 선택합니다.
  4. spec.processor.addZone 매개변수가 true 로 설정되도록 FlowCollector 사용자 지정 리소스를 구성합니다. 샘플 구성은 다음과 같습니다.

    가용성 영역 컬렉션에 대한 FlowCollector 구성

    apiVersion: flows.netobserv.io/v1beta2
    kind: FlowCollector
    metadata:
      name: cluster
    spec:
    # ...
     processor:
       addZone: true
    # ...

검증

네트워크 트래픽 페이지를 새로 고칠 때 개요,트래픽 흐름토폴로지 보기에 가용성 영역에 대한 새 정보가 표시됩니다.

  1. 개요 탭에서 영역을 사용 가능한 범위로 볼 수 있습니다.
  2. 네트워크 트래픽트래픽 흐름에서 영역은 SrcK8S_Zone 및 DstK8S_Zone 필드에서 볼 수 있습니다.
  3. 토폴로지 보기에서 영역을 범위 또는 그룹으로 설정할 수 있습니다.

10.2.12. 여러 규칙을 사용하여 eBPF 흐름 데이터 필터링

IP 주소 및 패킷 조건을 기반으로 특정 eBPF 흐름을 수락하거나 거부하여 네트워크 트래픽 데이터 수집을 구체화하도록 FlowCollector 사용자 지정 리소스에서 여러 필터링 규칙을 구성합니다.

중요
  • 필터 규칙에는 중복 CIDR(Classless Inter-Domain Routing)을 사용할 수 없습니다.
  • IP 주소가 여러 필터 규칙과 일치하면 가장 구체적인 CIDR 접두사(longest 접두사)가 있는 규칙이 우선합니다.

프로세스

  1. 웹 콘솔에서 EcosystemInstalled Operators 로 이동합니다.
  2. Network Observability에 대해 제공된 API에서 Flow Collector 를 선택합니다.
  3. 클러스터를 선택한 다음 YAML 탭을 선택합니다.
  4. FlowCollector 사용자 지정 리소스를 구성합니다.

10.2.13. eBPF 흐름 데이터 필터링 예

이러한 FlowCollector 사용자 지정 리소스 예제를 사용하여 eBPF 흐름을 필터링하여 eBPF 흐름 테이블에 캐시된 패킷의 흐름을 제어합니다.

기본적으로 다른 모든 흐름은 거부됩니다.

apiVersion: flows.netobserv.io/v1beta2
kind: FlowCollector
metadata:
  name: cluster
spec:
  namespace: netobserv
  deploymentModel: Service
  agent:
    type: eBPF
    ebpf:
      flowFilter:
        enable: true
        rules:
         - action: Accept
           cidr: 0.0.0.0/0
           sampling: 1
         - action: Accept
           cidr: 10.128.0.0/14
           peerCIDR: 10.128.0.0/14
         - action: Accept
           cidr: 172.30.0.0/16
           peerCIDR: 10.128.0.0/14
           sampling: 50

다음과 같습니다.

spec.agent.ebpf.flowFilter.enable
eBPF 흐름 필터링을 활성화할지 여부를 지정합니다. 흐름 필터링을 활성화하려면 true 로 설정합니다.
spec.agent.ebpf.flowFilter.rules.action
흐름 필터 규칙에 대한 작업을 지정합니다. 유효한 값은 Accept 또는 Reject 입니다.
spec.agent.ebpf.flowFilter.rules.cidr
흐름 필터 규칙의 IP 주소 및 CIDR 마스크를 지정합니다. 이 매개변수는 IPv4IPv6 주소 형식을 모두 지원합니다. IPv4 의 경우 0.0.0.0/0 을 사용하거나 ::/0 을 사용하여 모든 IP 주소와 일치하도록 IPv6 에 대해 를 사용합니다.
spec.agent.ebpf.flowFilter.rules.peerCIDR
흐름을 필터링하는 데 사용되는 피어 IP CIDR 을 지정합니다.
spec.agent.ebpf.flowFilter.rules.sampling
일치하는 흐름의 샘플링 간격을 지정합니다. 이 값은 spec.agent.ebpf.sampling 에 정의된 글로벌 샘플링 설정을 재정의합니다.
10.2.13.2. 패킷 삭제로 흐름을 필터링하는 YAML 예제

기본적으로 다른 모든 흐름은 거부됩니다.

apiVersion: flows.netobserv.io/v1beta2
kind: FlowCollector
metadata:
  name: cluster
spec:
  namespace: netobserv
  deploymentModel: Service
  agent:
    type: eBPF
    ebpf:
      privileged: true
      features:
        - PacketDrop
      flowFilter:
        enable: true
        rules:
        - action: Accept
          cidr: 172.30.0.0/16
          pktDrops: true

다음과 같습니다.

spec.agent.ebpf.privileged
패킷 드롭 보고에 필요한 권한 모드를 활성화할지 여부를 지정합니다.
spec.agent.ebpf.features
활성화할 eBPF 기능 목록을 지정합니다. 이 목록에 PacketDrop 값을 추가하면 각 네트워크 흐름에 대한 패킷 드롭이 보고됩니다.
spec.agent.ebpf.flowFilter.enable
eBPF 흐름 필터링을 활성화할지 여부를 지정합니다.
spec.agent.ebpf.flowFilter.rules.action
흐름 필터 규칙에 대한 작업을 지정합니다. 유효한 값은 Accept 또는 Reject 입니다.
spec.agent.ebpf.flowFilter.rules.pktDrops
패킷 드롭을 포함하는 흐름을 필터링할지 여부를 지정합니다.

10.2.14. 엔드포인트 변환(xlat)

엔드포인트 변환(xlat)은 eBPF를 사용하여 변환된 Pod 수준 메타데이터로 네트워크 흐름 로그를 강화하여 서비스 또는 로드 밸런서 뒤의 트래픽을 제공하는 특정 백엔드 Pod에 대한 가시성을 제공합니다.

eBPF(Network observability) 및 eBPF(extended Berkeley Packet Filter)를 사용하여 통합된 보기에서 트래픽을 제공하는 엔드포인트를 확인할 수 있습니다. 일반적으로 트래픽이 서비스, egressIP 또는 로드 밸런서를 통과하면 사용 가능한 Pod 중 하나로 라우팅되므로 트래픽 흐름 정보가 추상화됩니다. 트래픽에 대한 정보를 가져오려고 하면 서비스 IP 및 포트와 같은 서비스 관련 정보만 볼 수 있으며 요청을 제공하는 특정 Pod에 대한 정보는 볼 수 없습니다. 종종 서비스 트래픽과 가상 서비스 엔드포인트 모두에 대한 정보는 두 개의 별도의 흐름으로 캡처되므로 문제 해결이 어려워집니다.

이를 해결하기 위해 끝점 xlat은 다음과 같은 방법으로 도움이 될 수 있습니다.

  • 성능에 최소한의 영향을 미치는 커널 수준에서 네트워크 흐름을 캡처합니다.
  • 변환된 엔드포인트 정보를 사용하여 네트워크 흐름을 강화하여 서비스뿐만 아니라 특정 백엔드 Pod도 표시하므로 요청에 제공된 Pod를 확인할 수 있습니다.

네트워크 패킷이 처리되면 eBPF 후크는 단일 행의 네트워크 트래픽 페이지에서 볼 수 있는 다음 정보를 포함하는 변환된 엔드포인트에 대한 메타데이터로 흐름 로그를 강화합니다.

  • 소스 Pod IP
  • 소스 포트
  • 대상 Pod IP
  • 대상 포트
  • conntrack 영역 ID

10.2.15. 끝점 변환 작업 (xlat)

FlowCollector 리소스에서 엔드포인트 변환(xlat)을 활성화하여 변환된 패킷 정보를 사용하여 네트워크 흐름을 강화합니다. 이 정보를 사용하여 전용 xlat 열을 통해 서비스 트래픽을 제공하는 특정 Pod 및 오브젝트를 식별할 수 있습니다.

네트워크 관찰 기능 및 eBPF를 사용하여 번역된 엔드포인트 정보를 사용하여 Kubernetes 서비스에서 네트워크 흐름을 강화하여 트래픽을 제공하는 끝점에 대한 통찰력을 얻을 수 있습니다.

프로세스

  1. 웹 콘솔에서 EcosystemInstalled Operators 로 이동합니다.
  2. NetObserv Operator제공된 API 제목에서 흐름 수집기 를 선택합니다.
  3. 클러스터를 선택한 다음 YAML 탭을 선택합니다.
  4. PacketTranslation 에 대한 FlowCollector 사용자 정의 리소스를 구성합니다. 예를 들면 다음과 같습니다.

    FlowCollector 구성 예

    apiVersion: flows.netobserv.io/v1beta2
    kind: FlowCollector
    metadata:
      name: cluster
    spec:
      namespace: netobserv
      agent:
        type: eBPF
        ebpf:
          features:
           - PacketTranslation

    • spec.agent.ebpf.features 사양 목록에 PacketTranslation 매개변수를 나열하여 변환된 패킷 정보로 네트워크 흐름을 강화할 수 있습니다.
  5. 네트워크 트래픽 페이지를 새로 고침하여 변환된 패킷에 대한 정보를 필터링합니다.

    1. 대상 종류: 서비스를 기반으로 네트워크 흐름 데이터를 필터링합니다.
    2. 번역된 정보가 표시되는 위치와 다음 기본 열을 구분하는 xlat 열을 확인할 수 있습니다.

      • xlat 영역 ID
      • Xlat Src Kubernetes Object
      • xlat Dst Kubernetes 오브젝트
    3. 열 관리에서 추가 xlat 열 표시를 관리할 수 있습니다.You can manage the display of additional xlat columns in Manage columns.

10.2.16. 사용자 정의 네트워크 작업

UDN(사용자 정의 네트워크) 매핑을 사용하도록 FlowCollector 사용자 정의 리소스를 구성하여 웹 콘솔 내의 사용자 지정 네트워크 인터페이스 간 트래픽을 시각화할 수 있습니다.

네트워크 관찰 기능 리소스에서 UDN(사용자 정의 네트워크)을 활성화할 수 있습니다. 다음 예제에서는 FlowCollector 리소스에 대한 구성을 보여줍니다.

사전 요구 사항

  • Red Hat OpenShift Networking에서 UDN을 구성했습니다. 자세한 내용은 " CLI를 사용하여 사용자 정의 네트워크 생성" 또는 "웹 콘솔을 사용하여 사용자 정의 네트워크 생성"을 참조하십시오.

프로세스

  1. 다음 명령을 실행하여 네트워크 관찰 기능 FlowCollector 리소스를 편집합니다.

    $ oc edit flowcollector
  2. FlowCollector 리소스의 ebpf 섹션을 구성합니다.

    apiVersion: flows.netobserv.io/v1beta2
    kind: FlowCollector
    metadata:
      name: cluster
    spec:
      agent:
        ebpf:
          sampling: 1
          privileged: true
          features:
          - UDNMapping

    다음과 같습니다.

    spec.agent.ebpf.sampling
    네트워크 이벤트에 대한 샘플링 속도를 지정합니다. 모든 네트워크 이벤트를 캡처하려면 1 값으로 설정합니다. 샘플링 1 의 리소스가 너무 많은 경우 샘플링을 요구 사항에 더 적합한 것으로 설정합니다.
    spec.agent.ebpf.privileged
    권한 모드가 활성화되었는지 여부를 지정합니다. 사용자 정의 네트워크 매핑에 대해 true 로 설정해야 합니다.

검증

  • 네트워크 트래픽 페이지를 새로 고쳐 트래픽 흐름토폴로지 보기에서 업데이트된 UDN 정보를 확인합니다.

    • 네트워크 트래픽 > 트래픽 흐름에서SrcK8S_NetworkNameDstK8S_NetworkName 필드에서 UDN을 볼 수 있습니다.
    • 토폴로지 보기에서 네트워크를 범위 또는 그룹으로 설정할 수 있습니다.

10.2.17. 네트워크 이벤트 보기

보안 정책, 방화벽 및 격리 규칙이 웹 콘솔의 트래픽 흐름에 미치는 영향을 감사하기 위해 네트워크 이벤트 추적을 사용하도록 FlowCollector 사용자 지정 리소스를 구성합니다.

중요

OVN-Kubernetes 네트워킹 이벤트 추적은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

FlowCollector 를 편집하여 다음 리소스에서 삭제하거나 허용하는 네트워크 흐름과 같은 네트워크 트래픽 이벤트에 대한 정보를 볼 수 있습니다.

  • NetworkPolicy
  • AdminNetworkPolicy
  • BaselineNetworkPolicy
  • EgressFirewall
  • UserDefinedNetwork 격리
  • 멀티 캐스트 ACL

사전 요구 사항

  • cluster 라는 FeatureGate CR(사용자 정의 리소스)에 설정된 TechPreviewNoUpgrade 기능을 설정하여 OVNObservability 를 활성화해야 합니다. 자세한 내용은 "CLI를 사용하여 기능 세트 활성화" 및 "CLI를 사용하여 OVS 샘플링으로 OVN-Kubernetes 네트워크 트래픽 확인"을 참조하십시오.
  • 다음 네트워크 API 중 하나 이상을 생성했습니다: NetworkPolicy , AdminNetworkPolicy , BaselineNetworkPolicy , UserDefinedNetwork isolation, multicast 또는 EgressFirewall .

프로세스

  1. 웹 콘솔에서 EcosystemInstalled Operators 로 이동합니다.
  2. NetObserv Operator제공된 API 제목에서 흐름 수집기 를 선택합니다.
  3. 클러스터를 선택한 다음 YAML 탭을 선택합니다.
  4. NetworkEvents 보기를 사용하도록 FlowCollector CR을 구성합니다. 예를 들면 다음과 같습니다.

    FlowCollector 구성 예

    apiVersion: flows.netobserv.io/v1beta2
    kind: FlowCollector
    metadata:
      name: cluster
    spec:
       agent:
        type: eBPF
        ebpf:
      #   sampling: 1
          privileged: true
          features:
           - "NetworkEvents"

    다음과 같습니다.

    spec.agent.ebpf.sampling
    네트워크 이벤트의 샘플링 속도를 지정합니다. 모든 네트워크 이벤트를 캡처하려면 1 값으로 설정합니다. 샘플링 1 의 리소스가 너무 많은 경우 샘플링을 요구 사항에 더 적합한 것으로 설정합니다. 이 값은 선택 사항입니다.
    spec.agent.ebpf.privileged
    eBPF 에이전트가 권한 있는 모드에서 실행되는지 여부를 지정합니다. OVN 관찰 기능 라이브러리에서 로컬 OVS(Open vSwitch) 소켓 및 OVN(Open Virtual Network) 데이터베이스에 액세스해야 하므로 true 로 설정합니다.

검증

  1. 네트워크 트래픽 보기로 이동하여 트래픽 흐름 테이블을 선택합니다.
  2. 새 열 네트워크 이벤트( Network Events )에서 활성화한 다음 네트워크 API 중 하나에 대한 정보를 볼 수 있습니다: NetworkPolicy,AdminNetworkPolicy,BaselineNetworkPolicy,UserDefinedNetwork 격리, 멀티 캐스트 또는 송신 방화벽.

    이 열에서 볼 수 있는 이벤트의 예는 다음과 같습니다.

    네트워크 이벤트 출력 예

    <Dropped_or_Allowed> by <network_event_and_event_name>, direction <Ingress_or_Egress>

10.3. 토폴로지 보기에서 네트워크 트래픽 관찰

네트워크 트래픽 페이지의 토폴로지 보기에는 OpenShift Container Platform 클러스터의 네트워크 흐름 및 트래픽 볼륨이 그래픽으로 표시됩니다. 관리자는 이 보기를 사용하여 애플리케이션 트래픽 데이터를 모니터링하고 다양한 네트워크 구성 요소 간의 관계를 시각화할 수 있습니다.

시각화는 네트워크 엔터티를 노드 및 트래픽 흐름으로 나타냅니다. 그래프 내에서 개별 구성 요소를 선택하면 해당 리소스에 대한 특정 메트릭 및 상태 세부 정보가 포함된 측면 패널에 액세스할 수 있습니다. 이러한 대화형 접근 방식을 사용하면 클러스터 내에서 트래픽 패턴 및 연결 문제를 신속하게 식별할 수 있습니다.

복잡한 환경을 관리하기 위해 토폴로지 보기에는 레이아웃 및 데이터 밀도를 사용자 지정할 수 있는 고급 구성 옵션이 포함되어 있습니다. 뷰 범위를 조정하고 리소스 소유권을 나타내기 위해 그룹을 적용하고, 다른 레이아웃 알고리즘을 선택하여 그래픽 표시를 최적화할 수 있습니다. 또한 Edge 레이블을 사용하여 흐름 라인에서 직접 평균 바이트 비율과 같은 실시간 측정을 표시할 수 있습니다.

보고 또는 외부 분석을 위해 토폴로지 보기에 내보내기 기능이 있습니다. 현재 그래픽 표시를 PNG 이미지로 다운로드하거나 다른 관리자와 공유할 특정 보기 구성에 대한 직접 링크를 생성할 수 있습니다. 이러한 툴을 사용하면 네트워크 인사이트에 액세스하고 문서화할 수 있습니다.

10.3.1. 토폴로지 보기 작업

토폴로지 보기에 액세스하여 클러스터 네트워크 관계를 시각적으로 검사하고 개별 구성 요소를 선택하여 자세한 트래픽 지표 및 메타데이터를 확인합니다.

관리자는 토폴로지 보기로 이동하여 구성 요소의 세부 정보 및 지표를 확인할 수 있습니다.

사전 요구 사항

  • 관리자 액세스 권한이 있습니다.

프로세스

  1. 모니터링네트워크 트래픽 으로 이동합니다.
  2. 네트워크 트래픽 페이지에서 토폴로지 탭을 클릭합니다.
  3. 토폴로지 탭에서 각 구성 요소를 클릭하여 세부 정보 및 지표를 확인합니다.

10.3.2. 토폴로지 보기의 고급 옵션 구성

토폴로지 보기에서 사용 가능한 고급 옵션을 검토하여 표시 설정을 사용자 지정하고, 구성 요소 그룹화 및 레이아웃을 구성하고, 네트워크 그래프를 이미지로 내보냅니다.

고급 옵션 표시를 사용하여 보기를 사용자 지정하고 내보낼 수 있습니다. 고급 옵션 보기에는 다음과 같은 기능이 있습니다.

  • 보기에서 찾기: 뷰에서 필요한 구성 요소를 검색하려면 다음을 수행합니다.
  • Display options: 다음 옵션을 구성하려면 다음을 수행합니다.

    • Edge 라벨: 지정된 측정값을 에지 레이블로 표시하려면 다음을 수행합니다. 기본값은 Average rate in Cryostats를 표시하는 것입니다.
    • scope: 네트워크 트래픽이 이동하는 구성 요소의 범위를 선택합니다. 기본값은 Namespace 입니다.
    • groups: 구성 요소를 그룹화하여 소유권에 대한 이해를 강화합니다. 기본값은 None 입니다.
    • Layout: 그래픽 표현의 레이아웃을 선택합니다. 기본값은 ColaNoForce 입니다.
    • show: 표시할 필요가 있는 세부 정보를 선택합니다. 모든 옵션은 기본적으로 확인됩니다. 사용 가능한 옵션은 Edges,Edges 레이블Badges 입니다.
    • truncate 레이블: 드롭다운 목록에서 레이블의 필요한 너비를 선택합니다. 기본값은 M 입니다.
    • 그룹 축소: 그룹을 확장하거나 축소합니다. 그룹은 기본적으로 확장됩니다. group의 값이 None 경우 이 옵션이 비활성화됩니다.
10.3.2.1. 토폴로지 보기 내보내기

뷰를 내보내려면 토폴로지 보기 내보내기 를 클릭합니다. 보기는 PNG 형식으로 다운로드됩니다.

10.4. 네트워크 트래픽 필터링

Network Traffic 보기에서 사용 가능한 쿼리 옵션 및 필터링 매개변수를 검토하여 데이터 검색을 최적화하고 특정 로그 유형을 분석하며 방향 트래픽 가시성을 관리합니다.

기본적으로 네트워크 트래픽 페이지는 FlowCollector 인스턴스에 구성된 기본 필터를 기반으로 클러스터의 트래픽 흐름 데이터를 표시합니다. 필터 옵션을 사용하여 사전 설정 필터를 변경하여 필요한 데이터를 관찰할 수 있습니다.

또는 해당 집계의 필터링된 데이터를 제공하는 네임스페이스,서비스,경로,노드, 워크로드 페이지의 네트워크 트래픽 탭에서 트래픽 흐름 데이터에 액세스할 수 있습니다.

쿼리 옵션

다음과 같이 쿼리 옵션을 사용하여 검색 결과를 최적화할 수 있습니다.

  • 사용 가능한 옵션 대화 및 흐름은 흐름 로그, 새 대화, 완료된 대화 및 하트비트와 같은 로그 유형 별로 흐름을 쿼리하는 기능을 제공합니다. 이 기능은 긴 대화에 대한 업데이트가 포함된 주기적인 레코드입니다. 대화는 동일한 피어 간의 흐름을 집계하는 것입니다.
  • Match filters: 고급 필터에서 선택한 다양한 필터 매개변수 간의 관계를 확인할 수 있습니다. 사용 가능한 옵션은 all 및 match any와 일치합니다. Match all은 모든 값과 일치하는 결과를 제공하며 Match any는 입력한 값과 일치하는 결과를 제공합니다. 기본값은 all과 일치합니다.
  • 데이터 소스: Loki,Prometheus 또는 Auto 와 같은 쿼리에 사용할 데이터 소스를 선택할 수 있습니다. 중요 한 성능 개선은 Loki가 아닌 데이터 소스로 Prometheus를 사용할 때 실현할 수 있지만 Prometheus는 제한된 필터 및 집계 집합을 지원합니다. 기본 데이터 소스는 지원되는 쿼리에 Prometheus를 사용하거나 쿼리에서 Prometheus를 지원하지 않는 경우 Loki를 사용하는 Auto 입니다.
  • drops filter: 다음 쿼리 옵션을 사용하여 삭제된 패킷의 다른 수준을 볼 수 있습니다.

    • 완전히 삭제된 패킷은 완전히 삭제된 흐름 레코드를 표시합니다.
    • 포함 된 삭제 에는 드롭을 포함하지만 보낼 수 있는 흐름 레코드가 표시됩니다.
    • drop을 사용하지 않으면 전송된 패킷이 포함된 레코드가 표시됩니다.
    • 모두 앞서 언급한 모든 레코드를 보여줍니다.
  • Limit: 내부 백엔드 쿼리의 데이터 제한입니다. 일치 및 필터 설정에 따라 트래픽 흐름 데이터 수가 지정된 제한 내에 표시됩니다.
빠른 필터
빠른 필터 드롭다운 메뉴의 기본값은 FlowCollector 구성에 정의되어 있습니다. 콘솔에서 옵션을 수정할 수 있습니다.
고급 필터
드롭다운 목록에서 필터링할 매개변수를 선택하여 고급 필터, 공통,소스 또는 대상 을 설정할 수 있습니다. 흐름 데이터는 선택 사항에 따라 필터링됩니다. 적용된 필터를 활성화하거나 비활성화하려면 필터 옵션 아래에 나열된 적용된 필터를 클릭하면 됩니다.

arrow up long solid 에서 한 가지 방법과 arrow up long solid 뒤로 arrow down long solid 필터링을 전환할 수 있습니다. arrow up long solid 한 가지 방법 필터는 필터 선택에 따라 소스대상 트래픽만 표시합니다. 스왑을 사용하여 소스 대상 트래픽의 방향 보기를 변경할 수 있습니다. arrow up long solid arrow down long solid Back and forth 필터에는 소스 및 대상 필터가 있는 반환 트래픽이 포함됩니다. 네트워크 트래픽의 방향 흐름은 트래픽의 Direction 열에 Ingress' 또는 'Egress for inter-node traffic 및 ' Inner' 트래픽의 경우 단일 노드 내의 트래픽으로 표시됩니다.

기본값 재설정 을 클릭하여 기존 필터를 제거하고 FlowCollector 구성에 정의된 필터를 적용할 수 있습니다.

참고

텍스트 값을 지정하는 규칙을 이해하려면 자세히 알아보기 를 클릭합니다.

11장. 네트워크 관찰 기능 상태 규칙

Network Observability Operator는 기본 제공 메트릭과 OpenShift Container Platform 모니터링 스택을 사용하여 클러스터 네트워크 상태를 보고하여 경고를 제공합니다.

중요

네트워크 관찰 기능 상태 경고에는 OpenShift Container Platform 4.16 이상이 필요합니다.

11.1. 상태 및 성능에 대한 네트워크 관찰 기능 규칙

네트워크 관찰 기능에는 Prometheus 기반 규칙을 관리하는 시스템이 포함됩니다. 이러한 규칙을 사용하여 OpenShift Container Platform 애플리케이션 및 인프라의 상태 및 성능을 모니터링합니다.

Network Observability Operator는 이러한 규칙을 PrometheusRule 리소스로 변환합니다. Network Observability Operator는 다음 규칙 유형을 지원합니다.

  • 경고 규칙: Prometheus AlertManager 에서 관리하는 규칙을 지정하여 네트워크 anomalies 또는 인프라 실패에 대한 알림을 제공합니다.
  • 기록 규칙: 대시보드 성능 및 시각화를 개선하기 위해 미리 계산된 복잡한 Prometheus Query Language(PromQL) 표현식을 새 시계열로 지정합니다.

다음 명령을 실행하여 netobserv 네임스페이스에서 PrometheusRule 리소스를 확인합니다.

$ oc get prometheusrules -n netobserv -o yaml

11.1.1. 네트워크 상태 모니터링 및 경고 규칙

Network Observability Operator에는 네트워크 이상 및 인프라 오류를 감지하는 규칙 기반 시스템이 포함되어 있습니다. Operator는 구성을 경고 규칙으로 변환하여 OpenShift Container Platform 웹 콘솔을 통해 자동화된 모니터링 및 문제 해결을 활성화합니다.

11.1.1.1. 결과 모니터링

Network Observability Operator는 다음 영역에서 네트워크 상태를 표시합니다.

경고 UI
특정 경고가 Prometheus AlertManager 를 통해 관리되는 ObserveAlerting 에 표시됩니다.
네트워크 상태 대시보드
ObserveNetwork Health 의 특수 대시보드는 클러스터 네트워크 상태에 대한 높은 수준의 요약을 제공합니다.

네트워크 상태 대시보드는 위반을 탭으로 분류하여 문제 범위를 격리합니다.

  • Global: 전체 클러스터의 집계 상태
  • 노드: 인프라 노드에 고유합니다.
  • 네임스페이스: 개별 네임스페이스와 관련된 위반입니다.
  • 워크로드: Deployments 또는 DaemonSets 와 같은 리소스에 고유합니다.
11.1.1.2. 사전 정의된 상태 규칙

Network Observability Operator는 일반적인 네트워킹 시나리오에 대한 기본 규칙을 제공합니다. 이러한 규칙은 FlowCollector CR(사용자 정의 리소스)에서 해당 기능이 활성화된 경우에만 활성화됩니다.

다음 목록에는 사용 가능한 기본 규칙의 서브 세트가 포함되어 있습니다.

PacketDropsByDevice
높은 비율의 패킷의 트리거는 네트워크 장치에서 삭제됩니다. 표준 node-exporter 메트릭을 기반으로 하며 PacketDrop 에이전트 기능이 필요하지 않습니다.
PacketDropsByKernel
커널로 인해 높은 비율의 패킷에 대한 트리거가 삭제됩니다. PacketDrop 에이전트 기능이 필요합니다.
IPsecErrors
IPsec 암호화 오류가 감지되면 트리거됩니다. IPSec 에이전트 기능이 필요합니다.
NetpolDenied
네트워크 정책에서 거부된 트래픽이 감지될 때 트리거됩니다. NetworkEvents 에이전트 기능이 필요합니다.
LatencyHighTrend
TCP 대기 시간이 크게 증가할 때 트리거가 검색됩니다. FlowRTT 에이전트 기능이 필요합니다.
DNSErrors
DNS 오류가 감지되면 트리거됩니다. DNSTracking 에이전트 기능이 필요합니다.

Network Observability Operator에 대한 운영 경고:

NetObservNoFlows
파이프라인이 활성화되지만 흐름이 관찰되지 않을 때 트리거됩니다.
NetObservLokiError
Loki 오류로 인해 흐름이 삭제될 때 트리거됩니다.

전체 규칙 및 실행북 목록은 Network Observability Operator runbooks 를 참조하십시오.

11.1.1.3. 규칙 종속성 및 기능 요구 사항

Network Observability Operator는 FlowCollector CR(사용자 정의 리소스)에서 활성화된 기능을 기반으로 규칙을 생성합니다.

예를 들어 패킷 드롭 관련 규칙은 PacketDrop 에이전트 기능이 활성화된 경우에만 생성됩니다. 규칙은 메트릭을 기반으로 빌드됩니다. 필요한 메트릭이 누락된 경우 구성 경고가 표시될 수 있습니다. FlowCollector 리소스의 spec.processor.metrics.includeList 오브젝트에서 메트릭을 구성합니다.

11.2. 레코딩 규칙을 사용한 성능 최적화

대규모 클러스터의 경우 레코딩 규칙은 Prometheus가 네트워크 데이터를 처리하는 방법을 최적화합니다. 규칙을 기록하면 대시보드 응답성이 향상되고 복잡한 쿼리의 계산 오버헤드가 줄어듭니다.

11.2.1. 최적화 이점

복잡한 Prometheus Query Language(PromQL) 표현식을 사전 계산하고 결과를 새 시계열로 저장합니다. 경고 규칙과 달리 기록 규칙은 임계값을 모니터링하지 않습니다.

레코딩 규칙을 사용하면 다음과 같은 이점이 있습니다.

성능 개선
사전 컴퓨팅 Prometheus 쿼리를 사용하면 장기적인 추세에 대한 온디맨드 계산을 방지하여 대시보드를 더 빠르게 로드할 수 있습니다.
리소스 효율성
고정된 간격으로 데이터를 계산하면 모든 대시보드 새로 고침에서 데이터를 다시 계산하는 것보다 Prometheus 서버의 CPU 로드가 줄어듭니다.
간소화된 쿼리
cluster:network_traffic:rate_5m 과 같은 짧은 메트릭 이름을 사용하면 사용자 정의 대시보드에서 복잡한 집계 계산이 간소화됩니다.

11.2.2. 규칙 모드 비교

다음 표에서는 예상되는 결과에 따라 규칙 모드를 비교합니다.

Expand
설명경고 규칙기록 규칙

목표

문제 알림.

높은 수준의 메트릭의 기록을 저장합니다.

데이터 결과

경고 상태를 생성합니다.

영구 지표를 생성합니다.

가시성

경고 UI 및 네트워크 상태 보기.

메트릭 Explorer네트워크 상태 보기.

알림

AlertManager 알림을 트리거합니다.

알림을 트리거하지 않습니다.

11.3. 네트워크 관찰 기능 상태 규칙 구조 및 사용자 정의

Network Observability Operator의 상태 규칙은 FlowCollector CR(사용자 정의 리소스)의 spec.processor.metrics.healthRules 오브젝트에서 규칙 템플릿 및 변형을 사용하여 정의됩니다. 유연하고 세분화된 경고를 위해 기본 템플릿 및 변형을 사용자 지정할 수 있습니다.

각 템플릿에 대해 각각 고유한 임계값 및 그룹화 구성으로 변형 목록을 정의할 수 있습니다. 자세한 내용은 "기본 경고 템플릿 목록"을 참조하십시오.

다음 예제에서는 경고를 보여줍니다.

apiVersion: flows.netobserv.io/v1beta1
kind: FlowCollector
metadata:
  name: flow-collector
spec:
  processor:
    metrics:
      healthRules:
      - template: PacketDropsByKernel
        mode: Alert # or Recording
        variants:
        # triggered when the whole cluster traffic (no grouping) reaches 10% of drops
        - thresholds:
            critical: "10"
        # triggered when per-node traffic reaches 5% of drops, with gradual severity
        - thresholds:
            critical: "15"
            warning: "10"
            info: "5"
          groupBy: Node

다음과 같습니다.

spec.processor.metrics.healthRules.template
사전 정의된 규칙 템플릿의 이름을 지정합니다.
spec.processor.metrics.healthRules.mode
규칙 기능이 경고 또는 레코드 규칙으로 작동하는지 여부를 지정합니다. 이 설정은 변형별로 정의하거나 전체 템플릿에 대해 정의할 수 있습니다.
spec.processor.metrics.healthRules.variants.thresholds
규칙을 트리거하는 숫자 값을 지정합니다. 단일 변형에서 중요한 보안 수준,경고 또는 정보와 같은 여러 심각도 수준을 정의할 수 있습니다.
클러스터 전체 변형
groupBy 설정없이 정의된 변형을 지정합니다. 제공된 예에서 이 변형은 전체 클러스터 트래픽이 10% 드롭에 도달하면 트리거됩니다.
spec.processor.metrics.healthRules.variants.groupBy
메트릭을 집계하는 데 사용되는 차원을 지정합니다. 제공된 예에서 경고는 각 *노드8에 대해 독립적으로 평가됩니다.
참고

규칙을 사용자 정의하면 해당 템플릿의 기본 구성이 교체됩니다. 기본 구성을 유지하려면 수동으로 복제해야 합니다.

11.3.1. 상태 규칙에 대한 PromQL 표현식 및 메타데이터

PromQL(Prometheus Query Language)의 기본 쿼리와 특정 요구 사항에 대한 네트워크 관찰 경고를 구성할 수 있도록 사용자 정의하는 방법에 대해 알아봅니다.

네트워크 관찰 가능성 FlowCollector CR(사용자 정의 리소스)의 상태 규칙 API는 Prometheus Operator API에 매핑되어 PrometheusRule 을 생성합니다. 다음 명령을 실행하여 기본 netobserv 네임스페이스에서 PrometheusRule 를 확인할 수 있습니다.

$ oc get prometheusrules -n netobserv -oyaml
11.3.1.1. 들어오는 트래픽 급증에 대한 경고 쿼리의 예

이 예에서는 들어오는 트래픽의 급증에 대한 경고에 대한 기본 PromQL 쿼리 패턴을 제공합니다.

sum(rate(netobserv_workload_ingress_bytes_total{SrcK8S_Namespace="openshift-ingress"}[30m])) by (DstK8S_Namespace)

이 쿼리는 지난 30분 동안 openshift-ingress 네임스페이스에서 워크로드의 네임스페이스로 들어오는 바이트 속도를 계산합니다.

일부 속도만 유지하고 특정 기간 동안 쿼리를 실행하고 최종 임계값을 설정하는 등 쿼리를 사용자 지정할 수 있습니다.

필터링 노이즈

이 쿼리에 > 1000 을 추가하면 1KB/s 보다 큰 것으로 관찰된 속도만 유지되므로 저 대역폭 소비자의 노이즈가 제거됩니다.

(sum(rate(netobserv_workload_ingress_bytes_total{SrcK8S_Namespace="openshift-ingress"}[30m])) by (DstK8S_Namespace) > 1000)

바이트 비율은 FlowCollector CR(사용자 정의 리소스) 구성에 정의된 샘플링 간격과 관련이 있습니다. 샘플링 간격이 1:100 인 경우 실제 트래픽은 보고된 메트릭보다 약 100배 더 높을 수 있습니다.

시간 비교

오프셋 한정자를 사용하여 특정 기간에 대해 동일한 쿼리를 실행할 수 있습니다. 예를 들어 1일 전의 쿼리를 오프셋 1d 를 사용하여 실행할 수 있으며 5시간 전의 쿼리를 오프셋 5h 를 사용하여 실행할 수 있습니다.

sum(rate(netobserv_workload_ingress_bytes_total{SrcK8S_Namespace="openshift-ingress"}[30m] offset 1d)) (DstK8S_Namespace)

100 * (<query now> - <query from the previous day>) / <query from the previous day >를 사용하여 이전 날과 비교하여 증가 비율을 계산할 수 있습니다. 오늘 바이트 비율이 이전 날짜보다 낮은 경우 이 값은 음수일 수 있습니다.

최종 임계값
최종 임계값을 적용하여 원하는 백분율보다 낮은 증가를 필터링할 수 있습니다. 예를 들어 & gt; 100 은 100%보다 낮은 증가를 제거합니다.

PrometheusRule 의 전체 표현식은 다음과 같습니다.

...
      expr: |-
        (100 *
          (
            (sum(rate(netobserv_workload_ingress_bytes_total{SrcK8S_Namespace="openshift-ingress"}[30m])) by (DstK8S_Namespace) > 1000)
            - sum(rate(netobserv_workload_ingress_bytes_total{SrcK8S_Namespace="openshift-ingress"}[30m] offset 1d)) by (DstK8S_Namespace)
          )
          / sum(rate(netobserv_workload_ingress_bytes_total{SrcK8S_Namespace="openshift-ingress"}[30m] offset 1d)) by (DstK8S_Namespace))
        > 100
11.3.1.2. 경고 메타데이터 필드

Network Observability Operator는 모니터링 스택과 같은 다른 OpenShift Container Platform 기능의 구성 요소를 사용하여 네트워크 트래픽에 대한 가시성을 향상시킵니다. 자세한 내용은 "디스크 아키텍처 모니터링"을 참조하십시오.

규칙 정의에 맞게 일부 메타데이터를 구성해야 합니다. 이 메타데이터는 Prometheus 및 모니터링 스택의 Alertmanager 서비스 또는 네트워크 상태 대시보드에서 사용합니다.

다음 예제에서는 구성된 메타데이터가 있는 AlertingRule 리소스를 보여줍니다.

apiVersion: monitoring.openshift.io/v1
kind: AlertingRule
metadata:
  name: netobserv-alerts
  namespace: openshift-monitoring
spec:
  groups:
  - name: NetObservAlerts
    rules:
    - alert: NetObservIncomingBandwidth
      annotations:
        netobserv_io_network_health: '{"namespaceLabels":["DstK8S_Namespace"],"threshold":"100","unit":"%","upperBound":"500"}'
        message: |-
          NetObserv is detecting a surge of incoming traffic: current traffic to {{ $labels.DstK8S_Namespace }} has increased by more than 100% since yesterday.
        summary: "Surge in incoming traffic"
      expr: |-
        (100 *
          (
            (sum(rate(netobserv_workload_ingress_bytes_total{SrcK8S_Namespace="openshift-ingress"}[30m])) by (DstK8S_Namespace) > 1000)
            - sum(rate(netobserv_workload_ingress_bytes_total{SrcK8S_Namespace="openshift-ingress"}[30m] offset 1d)) by (DstK8S_Namespace)
          )
          / sum(rate(netobserv_workload_ingress_bytes_total{SrcK8S_Namespace="openshift-ingress"}[30m] offset 1d)) by (DstK8S_Namespace))
        > 100
      for: 1m
      labels:
        app: netobserv
        netobserv: "true"
        severity: warning

다음과 같습니다.

spec.groups.rules.alert.labels.netobserv
true 로 설정된 경우 감지할 Network Health dashboard에 대한 경고를 지정합니다.
spec.groups.rules.alert.labels.severity
경고의 심각도를 지정합니다. 다음은 유효한 값입니다: critical,warning 또는 info.

메시지 주석에 정의된 PromQL 표현식의 출력 레이블을 활용할 수 있습니다. 이 예제에서는 DstK8S_Namespace 마다 결과가 그룹화되므로 메시지 텍스트에 {{ $labels.DstK8S_Namespace }} 라는 표현식이 사용됩니다.

netobserv_io_network_health 주석은 선택 사항이며 네트워크 상태 페이지에서 경고가 렌더링되는 방법을 제어합니다.

netobserv_io_network_health 주석은 다음 필드로 구성된 JSON 문자열입니다.

Expand
표 11.1. netobserv_io_network_health 주석의 필드
필드유형설명

namespaceLabels

문자열 목록

네임스페이스를 보유하는 하나 이상의 레이블입니다. 제공된 경우 네임스페이스 탭 아래에 경고가 표시됩니다.

nodeLabels

문자열 목록

노드 이름을 보유하는 하나 이상의 레이블입니다. 제공된 경우 노드 탭 아래에 경고가 표시됩니다.

workloadLabels

문자열 목록

소유자/워크로드 이름을 보유하는 하나 이상의 레이블입니다. kindLabels 와 함께 제공되면 경고가 "소유자" 탭 아래에 표시됩니다.

kindLabels

문자열 목록

소유자/워크로드 종류를 보유하는 하나 이상의 레이블입니다. workloadLabels 와 함께 제공되면 "소유자" 탭 아래에 경고가 표시됩니다.

threshold

문자열

PromQL 식에 정의된 임계값과 일치해야 하는 경고 임계값입니다.

단위

문자열

표시 목적으로만 사용되는 데이터 단위입니다.

upperBound

문자열

비공개 스케일에서 점수를 계산하는 데 사용되는 상한 값입니다. 이 범위를 초과하는 메트릭 값은 고정됩니다.

links

오브젝트 목록

경고와 함께 컨텍스트를 표시할 링크 목록입니다. 각 링크에는 이름 (디스플레이 이름) 및 url 이 필요합니다.

trafficLink

문자열

URL 빌드를 위한 네트워크 트래픽 페이지에 대한 링크와 관련된 정보입니다. 일부 필터는 노드 또는 네임스페이스 필터와 같이 자동으로 설정됩니다.

namespaceLabelsnodeLabels 는 함께 사용할 수 없습니다. 둘 다 제공되지 않으면 글로벌 탭에 경고가 표시됩니다.

Expand
표 11.2. trafficLink fields
필드설명

extraFilter

삽입할 추가 필터(예: DNS 관련 경고의 DNS 응답 코드)

backAndForth

필터에 반환 트래픽이 포함되어야 하는지 여부(true 또는 false).

filterDestination

필터에서 소스 대신 트래픽 대상을 대상으로 지정하는지 여부(true 또는 false).

11.3.2. 사용자 정의 상태 규칙 구성

PromQL(PromQL)을 사용하여 특정 네트워크 지표(예: 트래픽 급증)를 기반으로 경고를 트리거하도록 사용자 정의 AlertingRule 리소스를 정의합니다.

사전 요구 사항

  • PromQL 에 대한 지식이 있어야 합니다.
  • OpenShift Container Platform 4.16 이상을 설치했습니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • Network Observability Operator가 설치되어 있습니다.

프로세스

  1. AlertingRule 리소스가 포함된 custom-alert.yaml 이라는 YAML 파일을 생성합니다.
  2. 다음 명령을 실행하여 사용자 정의 경고 규칙을 적용합니다.

    $ oc apply -f custom-alert.yaml

검증

  1. 다음 명령을 실행하여 PrometheusRule 리소스가 netobserv 네임스페이스에 생성되었는지 확인합니다.

    $ oc get prometheusrules -n netobserv -oyaml

    출력에 방금 생성한 netobserv-alerts 규칙이 포함되어 리소스가 올바르게 생성되었는지 확인해야 합니다.

  2. OpenShift Container Platform 웹 콘솔 → Observe 에서 네트워크 상태 대시보드를 확인하여 규칙이 활성 상태인지 확인합니다.

11.4. 사전 정의된 규칙 비활성화

FlowCollector CR(사용자 정의 리소스)의 spec.processor.metrics.disableAlerts 필드에서 규칙 템플릿을 비활성화할 수 있습니다. 이 설정은 규칙 템플릿 이름 목록을 허용합니다. 경고 템플릿 이름 목록은 "기본 규칙 목록"을 참조하십시오.

spec.processor.metrics.healthRules 필드에서 템플릿을 비활성화하고 재정의하는 경우 disable 설정이 우선하며 경고 규칙이 생성되지 않습니다.

12장. 대시보드 및 경고로 메트릭 사용

Network Observability Operator는 flowlogs-pipeline 구성 요소를 사용하여 흐름 로그에서 지표를 생성합니다. 이러한 메트릭을 사용하여 사용자 지정 경고를 설정하고 네트워크 활동 분석을 위한 대시보드를 확인합니다.

12.1. 네트워크 관찰 기능 지표 대시보드 보기

노드, 네임스페이스, 소유자, 포드 및 서비스별로 메트릭을 필터링하는 옵션과 함께 OpenShift Container Platform 콘솔의 개요 탭을 사용하여 네트워크 관찰 기능 지표 대시보드를 확인합니다.

프로세스

  1. 웹 콘솔 ObserveDashboards 에서 Netobserv 대시보드를 선택합니다.
  2. 다음 카테고리에서 네트워크 트래픽 지표를 확인합니다. 각각 노드, 네임스페이스, 소스 및 대상당 하위 집합을 갖습니다.

    • 바이트 비율
    • 패킷 드롭
    • DNS
    • RTT
  3. Netobserv/Health 대시보드를 선택합니다.
  4. 다음 카테고리에서 Operator의 상태에 대한 메트릭을 표시하고 각 카테고리에는 노드, 네임스페이스, 소스 및 대상당 하위 집합이 있습니다.

    • flows
    • 흐름 오버 헤드
    • 유량
    • 에이전트
    • 프로세서
    • Operator

      인프라애플리케이션 메트릭은 네임스페이스 및 워크로드에 대한 분할 보기에 표시됩니다.

12.2. 네트워크 관찰 기능 지표

FlowCollector 리소스에서 구성하고, 트래픽을 모니터링하고 Prometheus 경고를 생성하는 데 사용할 수 있는 netobserv_ 접두사가 붙은 network observability 지표의 포괄적인 목록을 검토합니다.

flowlogs-pipeline 에서 생성한 지표는 지표를 추가하거나 제거하기 위해 FlowCollector 사용자 정의 리소스의 spec.processor.metrics.includeList 에서 구성할 수 있습니다.

예제 "경고 생성"과 같이 Prometheus 규칙에 includeList 지표를 사용하여 경고를 생성할 수도 있습니다.

ObserveMetrics 를 통해 콘솔에서와 같이 Prometheus에서 이러한 지표를 찾을 때 또는 경고를 정의할 때 모든 메트릭 이름 앞에 netobserv_ 접두사가 지정됩니다. 예를 들어 netobserv_namespace_flows_total. 사용 가능한 지표 이름은 다음과 같습니다.

includeList 지표 이름

이름 뒤에 별표 * 는 기본적으로 활성화되어 있습니다.

  • namespace_egress_bytes_total
  • namespace_egress_packets_total
  • namespace_ingress_bytes_total
  • namespace_ingress_packets_total
  • namespace_flows_total *
  • node_egress_bytes_total
  • node_egress_packets_total
  • node_ingress_bytes_total *
  • node_ingress_packets_total
  • node_flows_total
  • workload_egress_bytes_total
  • workload_egress_packets_total
  • workload_ingress_bytes_total *
  • workload_ingress_packets_total
  • workload_flows_total
PacketDrop 메트릭 이름

spec.agent.ebpf.features ( 권한 있는 모드)에서 PacketDrop 기능이 활성화되면 다음과 같은 추가 메트릭을 사용할 수 있습니다.

  • namespace_drop_bytes_total
  • namespace_drop_packets_total *
  • node_drop_bytes_total
  • node_drop_packets_total
  • workload_drop_bytes_total
  • workload_drop_packets_total
DNS 메트릭 이름

spec.agent.ebpf.features 에서 DNSTracking 기능이 활성화되면 다음과 같은 추가 메트릭을 사용할 수 있습니다.

  • namespace_dns_latency_seconds *
  • node_dns_latency_seconds
  • workload_dns_latency_seconds
FlowRTT 메트릭 이름

spec.agent.ebpf.features 에서 FlowRTT 기능을 활성화하면 다음과 같은 추가 메트릭을 사용할 수 있습니다.

  • namespace_rtt_seconds *
  • node_rtt_seconds
  • workload_rtt_seconds
네트워크 이벤트 메트릭 이름

NetworkEvents 기능이 활성화되면 이 메트릭은 기본적으로 사용할 수 있습니다.

  • namespace_network_policy_events_total

12.3. 경고 생성

Netobserv 대시보드 메트릭을 기반으로 사용자 정의 AlertingRule 리소스를 생성하여 OpenShift Container Platform 콘솔에서 경고를 트리거하는 조건을 정의합니다.

사전 요구 사항

  • cluster-admin 역할이 있는 사용자 또는 모든 프로젝트에 대한 보기 권한이 있는 사용자로 클러스터에 액세스할 수 있습니다.
  • Network Observability Operator가 설치되어 있어야 합니다.

프로세스

  1. 가져오기 아이콘 + 를 클릭하여 YAML 파일을 생성합니다.
  2. YAML 파일에 경고 규칙 구성을 추가합니다. 다음 YAML 샘플에서는 클러스터 수신 트래픽이 대상 워크로드당 지정된 임계값이 10MBps에 도달하면 경고가 생성됩니다.

    apiVersion: monitoring.openshift.io/v1
    kind: AlertingRule
    metadata:
      name: netobserv-alerts
      namespace: openshift-monitoring
    spec:
      groups:
      - name: NetObservAlerts
        rules:
        - alert: NetObservIncomingBandwidth
          annotations:
            message: |-
              {{ $labels.job }}: incoming traffic exceeding 10 MBps for 30s on {{ $labels.DstK8S_OwnerType }} {{ $labels.DstK8S_OwnerName }} ({{ $labels.DstK8S_Namespace }}).
            summary: "High incoming traffic."
          expr: sum(rate(netobserv_workload_ingress_bytes_total     {SrcK8S_Namespace="openshift-ingress"}[1m])) by (job, DstK8S_Namespace, DstK8S_OwnerName, DstK8S_OwnerType) > 10000000
          for: 30s
          labels:
            severity: warning
    • netobserv_workload_ingress_bytes_total 메트릭은 spec.processor.metrics.includeList 에서 기본적으로 활성화됩니다.
  3. 생성 을 클릭하여 구성 파일을 클러스터에 적용합니다.

12.4. 사용자 정의 메트릭

FlowMetric API를 사용하여 흐름 로그 데이터에서 사용자 정의 지표를 정의하고, 로그 필드를 Prometheus 라벨로 활용하여 대시보드 정보를 사용자 지정하고 특정 클러스터 데이터를 모니터링합니다.

수집된 모든 플로우로그 데이터에는 소스 이름, 대상 이름 등 로그별로 레이블이 지정된 여러 필드가 있습니다. 이러한 필드는 Prometheus 레이블로 활용하여 대시보드에서 클러스터 정보를 사용자 정의할 수 있습니다.

12.5. FlowMetric API를 사용하여 사용자 정의 메트릭 구성

특정 모니터링 요구 사항에 맞게 흐름 로그 필드를 라벨로 매핑하여 사용자 정의 Prometheus 지표를 생성하도록 FlowMetric API를 구성합니다.

프로세스

  1. 웹 콘솔에서 EcosystemInstalled Operators 로 이동합니다.
  2. NetObserv Operator제공된 API 제목에서 FlowMetric 을 선택합니다.
  3. Project: 드롭다운 목록에서 Network Observability Operator 인스턴스의 프로젝트를 선택합니다.
  4. FlowMetric 만들기를 클릭합니다.
  5. FlowMetric 리소스를 구성합니다. "Custom metrics configuration examples"를 참조하십시오.

검증

  1. Pod가 새로 고쳐지면 모니터링메트릭 으로 이동합니다.
  2. Expression 필드에 해당 결과를 볼 메트릭 이름을 입력합니다. topk(5, sum(rate(netobserv_cluster_external_ingress_bytes_total{DstK8S_Namespace="my-namespace"}[2m])) by (DstK8S_HostName, DstK8S_OwnerName, DstK8S_OwnerType))와 같은 표현식을 입력할 수도 있습니다.

12.5.1. 사용자 정의 메트릭 구성 예

외부 트래픽 볼륨 또는 대기 시간 급증과 같은 기본 메트릭에서 다루지 않는 특정 네트워크 동작을 모니터링하려면 FlowMetric CR(사용자 정의 리소스)을 사용합니다. 이 예제에서는 네트워크 흐름에서 대상 Prometheus 지표를 생성하는 데 필요한 구성을 제공합니다.

12.5.1.1. 클러스터 외부 소스에서 수신 바이트 추적

외부 네트워크에서 클러스터를 입력하는 데이터 볼륨을 측정하려면 다음 FlowMetric 구성을 사용합니다. 이 메트릭은 잠재적인 대역폭 문제 또는 예기치 않은 외부 데이터 전송 비용을 식별하는 데 도움이 됩니다.

apiVersion: flows.netobserv.io/v1alpha1
kind: FlowMetric
metadata:
  name: flowmetric-cluster-external-ingress-traffic
  namespace: netobserv
spec:
  metricName: cluster_external_ingress_bytes_total
  type: Counter
  valueField: Bytes
  direction: Ingress
  labels: [DstK8S_HostName,DstK8S_Namespace,DstK8S_OwnerName,DstK8S_OwnerType]
  filters:
  - field: SrcSubnetLabel
    matchType: Absence

다음과 같습니다.

metadata.namespace
FlowMetric 리소스가 생성되는 네임스페이스를 지정합니다. 이는 기본적으로 netobservFlowCollector 리소스 spec.namespace 필드에 정의된 네임스페이스와 일치해야 합니다.
spec.metricName
OpenShift Container Platform 웹 콘솔에 netobserv-<metricName> 접두사가 표시되는 Prometheus 지표의 이름을 지정합니다.
spec.type
메트릭 유형을 지정합니다. Cryo stat 유형은 바이트 또는 패킷을 계산하는 데 유용합니다.
spec.direction
캡처할 트래픽 방향을 지정합니다. 지정하지 않으면 수신 및 송신이 모두 캡처되므로 중복될 수 있습니다.
spec.labels
지표의 모양과 다른 엔티티 간의 관계 및 메트릭 카디널리티를 정의하는 레이블을 지정합니다. 예를 들어 SrcK8S_Name 은 높은 Cardinality 메트릭입니다.
spec.filters
나열된 기준에 따라 결과를 구체화하는 기준을 지정합니다. 이 예에서는 클러스터 외부 트래픽만 선택하면 SrcSubnetLabel 이 없는 흐름만 일치하여 수행됩니다. 이는 기본적으로 서브넷 레이블 기능이 ( spec.processor.subnetLabels를 통해) 활성화되어 있다고 가정합니다.
12.5.1.2. 클러스터 외부 수신 트래픽의 RTT 대기 시간 모니터링

외부 연결의 성능을 분석하고 대기 시간이 긴 경로를 확인하려면 다음 FlowMetric 구성을 사용합니다. 이 메트릭은 표준 Prometheus 대기 시간 대시보드와 일치하도록 나노초를 초로 변환합니다.

apiVersion: flows.netobserv.io/v1alpha1
kind: FlowMetric
metadata:
  name: flowmetric-cluster-external-ingress-rtt
  namespace: netobserv
spec:
  metricName: cluster_external_ingress_rtt_seconds
  type: Histogram
  valueField: TimeFlowRttNs
  direction: Ingress
  labels: [DstK8S_HostName,DstK8S_Namespace,DstK8S_OwnerName,DstK8S_OwnerType]
  filters:
  - field: SrcSubnetLabel
    matchType: Absence
  - field: TimeFlowRttNs
    matchType: Presence
  divider: "1000000000"
  buckets: [".001", ".005", ".01", ".02", ".03", ".04", ".05", ".075", ".1", ".25", "1"]

다음과 같습니다.

metadata.namespace
FlowMetric 리소스가 생성되는 네임스페이스를 지정합니다. 이는 기본적으로 netobservFlowCollector 리소스 spec.namespace 필드에 정의된 네임스페이스와 일치해야 합니다.
spec.type
메트릭 유형을 지정합니다. histogram 유형은 TimeFlowRttNs 와 같은 대기 시간 값에 유용합니다.
spec.divider
지표를 분할하는 데 사용되는 값을 지정합니다. RTT(Round-trip Time)는 흐름에서 나노초로 제공되므로 1,000,000,000의 분할기를 사용하여 Prometheus 지침의 표준인 초 단위로 값을 변환합니다.
spec.buckets
RTT 정확도에 대한 사용자 지정 버킷을 지정합니다. 최적의 전체 정확도 범위는 5ms에서 250ms 사이입니다.

12.6. 트래픽 흐름 테이블의 중첩된 또는 배열 필드에서 메트릭 생성

FlowMetric 사용자 지정 리소스를 만들어 네트워크 이벤트 또는 인터페이스와 같은 트래픽 흐름 테이블에 중첩된 또는 배열 필드에 대한 지표를 생성합니다.

중요

OVN Observability / Viewing NetworkEvents 는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

중요

OVN Observability 및 네트워크 이벤트를 보고 추적하는 기능은 OpenShift Container Platform 4.17 및 4.18에서만 사용할 수 있습니다.

다음 예제에서는 네트워크 정책 이벤트에 대한 네트워크 이벤트 필드에서 지표를 생성하는 방법을 보여줍니다.

사전 요구 사항

  • NetworkEvents 기능을 활성화합니다. 이 작업을 수행하는 방법은 추가 리소스를 참조하십시오.
  • 지정된 네트워크 정책입니다.

프로세스

  1. 웹 콘솔에서 EcosystemInstalled Operators 로 이동합니다.
  2. NetObserv Operator제공된 API 제목에서 FlowMetric 을 선택합니다.
  3. 프로젝트 드롭다운 목록에서 Network Observability Operator 인스턴스의 프로젝트를 선택합니다.
  4. FlowMetric 만들기를 클릭합니다.
  5. FlowMetric 리소스를 생성하여 다음 구성을 추가합니다.

    정책 이름 및 네임스페이스당 네트워크 정책 이벤트 수 계산 구성

    apiVersion: flows.netobserv.io/v1alpha1
    kind: FlowMetric
    metadata:
      name: network-policy-events
      namespace: netobserv
    spec:
      metricName: network_policy_events_total
      type: Counter
      labels: [NetworkEvents>Type, NetworkEvents>Namespace, NetworkEvents>Name, NetworkEvents>Action, NetworkEvents>Direction]
      filters:
      - field: NetworkEvents>Feature
        value: acl
      flatten: [NetworkEvents]
      remap:
        "NetworkEvents>Type": type
        "NetworkEvents>Namespace": namespace
        "NetworkEvents>Name": name
        "NetworkEvents>Direction": direction

    다음과 같습니다.

    spec.labels
    트래픽 흐름 테이블의 네트워크 이벤트 의 중첩된 필드를 나타내는 레이블을 지정합니다. 각 네트워크 이벤트에는 특정 유형, 네임스페이스, 이름, 동작 및 방향이 있습니다. OpenShift Container Platform 버전에서 NetworkEvents 를 사용할 수 없는 경우 Interfaces 를 지정할 수도 있습니다.
    spec.flatten
    고유한 항목으로 표시할 항목 목록을 포함하는 선택적 필드를 지정합니다.
    spec.remap
    Prometheus에서 이름을 바꿀 선택적 필드 세트를 지정합니다.

검증

  1. 웹 콘솔에서 모니터링대시보드 로 이동하여 아래로 스크롤하여 네트워크 정책 탭을 확인합니다.
  2. 네트워크 정책 사양과 함께 생성한 메트릭에 따라 에 메트릭 필터가 표시되기 시작해야 합니다.
중요

높은 카디널리티는 Prometheus의 메모리 사용량에 영향을 미칠 수 있습니다. 네트워크 흐름 형식에서 특정 라벨에 높은 카디널리티가 있는지 확인할 수 있습니다. "네트워크 흐름 형식 참조"를 참조하십시오.

12.7. FlowMetric API를 사용하여 사용자 정의 차트 구성

FlowMetric 사용자 정의 리소스의 차트 섹션을 정의하여 OpenShift Container Platform 웹 콘솔 대시보드에 대한 사용자 정의 차트를 생성합니다.

대시보드 메뉴에서 사용자 지정 차트를 관리자로 볼 수 있습니다.

프로세스

  1. 웹 콘솔에서 EcosystemInstalled Operators 로 이동합니다.
  2. NetObserv Operator제공된 API 제목에서 FlowMetric 을 선택합니다.
  3. Project: 드롭다운 목록에서 Network Observability Operator 인스턴스의 프로젝트를 선택합니다.
  4. FlowMetric 만들기를 클릭합니다.
  5. FlowMetric 리소스를 구성합니다. "Flowmetric 차트 구성 예제"를 참조하십시오.

검증

  1. Pod가 새로 고쳐지면 모니터링대시보드 로 이동합니다.
  2. NetObserv / Main 대시보드를 검색합니다. NetObserv / Main 대시보드 아래에 있는 두 개의 패널을 보거나 선택적으로 생성한 대시보드 이름을 확인합니다.

    • 모든 차원에 걸쳐 요약된 글로벌 외부 수신률을 보여주는 텍스트 단일 통계
    • 대상 워크로드당 동일한 메트릭을 표시하는 시계열 그래프

쿼리 언어에 대한 자세한 내용은 Prometheus 설명서를 참조하십시오.

12.7.1. Flowmetric 차트 구성 예

이러한 FlowMetric 사용자 정의 리소스 예제에서는 외부 인그레스 트래픽 및 RTT(Round-trip Time) 대기 시간을 추적하기 위해 OpenShift Container Platform 웹 콘솔에서 차트를 정의하는 방법을 보여줍니다.

12.7.1.1. 클러스터 외부 소스에 대한 Ingress 바이트 차트

다음 구성을 사용하여 클러스터 외부 소스의 수신 트래픽 속도를 추적합니다. 이러한 차트는 워크로드당 대역폭 사용량을 식별하는 데 도움이 됩니다.

apiVersion: flows.netobserv.io/v1alpha1
kind: FlowMetric
metadata:
  name: flowmetric-cluster-external-ingress-traffic
  namespace: netobserv
# ...
  charts:
  - dashboardName: Main
    title: External ingress traffic
    unit: Bps
    type: SingleStat
    queries:
    - promQL: "sum(rate($METRIC[2m]))"
      legend: ""
  - dashboardName: Main
    sectionName: External
    title: Top external ingress traffic per workload
    unit: Bps
    type: StackArea
    queries:
    - promQL: "sum(rate($METRIC{DstK8S_Namespace!=\"\"}[2m])) by (DstK8S_Namespace, DstK8S_OwnerName)"
      legend: "{{DstK8S_Namespace}} / {{DstK8S_OwnerName}}"
# ...

다음과 같습니다.

metadata.namespace
FlowMetric 리소스가 생성되는 네임스페이스를 지정합니다. 이는 기본적으로 netobservFlowCollector spec.namespace 에 정의된 네임스페이스와 일치해야 합니다.
spec.charts.dashboardName
대시보드 이름을 지정합니다. 다른 dashboardName 을 사용하면 Netobserv 가 붙은 새 대시보드가 생성됩니다. 예를 들면 Netobserv / <dashboard_name>입니다.
12.7.1.2. 클러스터 외부 수신 트래픽의 RTT 대기 시간 차트

다음 구성을 사용하여 클러스터 외부 수신 트래픽에 대해 RTT(Round-trip Time)를 모니터링합니다. 이 예에서는 히스토그램_quantile 함수를 사용하여 50번째 및 99번째 백분위수(p50 및 p99)를 표시합니다.

apiVersion: flows.netobserv.io/v1alpha1
kind: FlowMetric
metadata:
  name: flowmetric-cluster-external-ingress-traffic
  namespace: netobserv
# ...
  charts:
  - dashboardName: Main
    title: External ingress TCP latency
    unit: seconds
    type: SingleStat
    queries:
    - promQL: "histogram_quantile(0.99, sum(rate($METRIC_bucket[2m])) by (le)) > 0"
      legend: "p99"
  - dashboardName: Main
    sectionName: External
    title: "Top external ingress sRTT per workload, p50 (ms)"
    unit: seconds
    type: Line
    queries:
    - promQL: "histogram_quantile(0.5, sum(rate($METRIC_bucket{DstK8S_Namespace!=\"\"}[2m])) by (le,DstK8S_Namespace,DstK8S_OwnerName))*1000 > 0"
      legend: "{{DstK8S_Namespace}} / {{DstK8S_OwnerName}}"
  - dashboardName: Main
    sectionName: External
    title: "Top external ingress sRTT per workload, p99 (ms)"
    unit: seconds
    type: Line
    queries:
    - promQL: "histogram_quantile(0.99, sum(rate($METRIC_bucket{DstK8S_Namespace!=\"\"}[2m])) by (le,DstK8S_Namespace,DstK8S_OwnerName))*1000 > 0"
      legend: "{{DstK8S_Namespace}} / {{DstK8S_OwnerName}}"
# ...

다음과 같습니다.

metadata.namespace
FlowMetric 리소스가 생성되는 네임스페이스를 지정합니다. 이는 기본적으로 netobservFlowCollector spec.namespace 에 정의된 네임스페이스와 일치해야 합니다.
spec.charts.dashboardName
대시보드 이름을 지정합니다. 다른 dashboardName 을 사용하면 Netobserv 가 붙은 새 대시보드가 생성됩니다. 예를 들면 Netobserv / <dashboard_name>입니다.
12.7.1.3. 히스토그램 평균 계산

히스토그램을 생성할 때 자동으로 생성되는 지표 $METRIC_sum 을 지표로 나누어 히스토그램의 평균을 표시할 있습니다. 이전 예에서 이 작업을 수행하는 Prometheus 쿼리는 다음과 같습니다.

promQL: "(sum(rate($METRIC_sum{DstK8S_Namespace!=\"\"}[2m])) by (DstK8S_Namespace,DstK8S_OwnerName) / sum(rate($METRIC_count{DstK8S_Namespace!=\"\"}[2m])) by (DstK8S_Namespace,DstK8S_OwnerName))*1000"

12.8. FlowMetric API 및 TCP 플래그를 사용하여 SYN 플러드 감지

사용자 정의 AlertingRuleFlowMetric 구성을 배포하여 TCP 플래그를 모니터링하여 클러스터에 대한 SYN 플러딩 공격에 대한 실시간 탐지 및 경고를 활성화합니다.

프로세스

  1. 웹 콘솔에서 EcosystemInstalled Operators 로 이동합니다.
  2. NetObserv Operator제공된 API 제목에서 FlowMetric 을 선택합니다.
  3. 프로젝트 드롭다운 목록에서 Network Observability Operator 인스턴스의 프로젝트를 선택합니다.
  4. FlowMetric 만들기를 클릭합니다.
  5. FlowMetric 리소스를 생성하여 다음 구성을 추가합니다.

    TCP 플래그를 사용하여 대상 호스트 및 리소스당 구성 계산 흐름

    apiVersion: flows.netobserv.io/v1alpha1
    kind: FlowMetric
    metadata:
      name: flows-with-flags-per-destination
    spec:
      metricName: flows_with_flags_per_destination_total
      type: Counter
      labels: [SrcSubnetLabel,DstSubnetLabel,DstK8S_Name,DstK8S_Type,DstK8S_HostName,DstK8S_Namespace,Flags]

    TCP 플래그를 사용하여 소스 호스트 및 리소스당 구성 계산 흐름

    apiVersion: flows.netobserv.io/v1alpha1
    kind: FlowMetric
    metadata:
      name: flows-with-flags-per-source
    spec:
      metricName: flows_with_flags_per_source_total
      type: Counter
      labels: [DstSubnetLabel,SrcSubnetLabel,SrcK8S_Name,SrcK8S_Type,SrcK8S_HostName,SrcK8S_Namespace,Flags]

  6. 다음 AlertingRule 리소스를 배포하여 SYN 플러드에 대해 경고합니다.

    SYN 플러드에 대한 AlertingRule

    apiVersion: monitoring.openshift.io/v1
    kind: AlertingRule
    metadata:
      name: netobserv-syn-alerts
      namespace: openshift-monitoring
    # ...
      spec:
      groups:
      - name: NetObservSYNAlerts
        rules:
        - alert: NetObserv-SYNFlood-in
          annotations:
            message: |-
              {{ $labels.job }}: incoming SYN-flood attack suspected to Host={{ $labels.DstK8S_HostName}}, Namespace={{ $labels.DstK8S_Namespace }}, Resource={{ $labels.DstK8S_Name }}. This is characterized by a high volume of SYN-only flows with different source IPs and/or ports.
            summary: "Incoming SYN-flood"
          expr: sum(rate(netobserv_flows_with_flags_per_destination_total{Flags="2"}[1m])) by (job, DstK8S_HostName, DstK8S_Namespace, DstK8S_Name) > 300
          for: 15s
          labels:
            severity: warning
            app: netobserv
        - alert: NetObserv-SYNFlood-out
          annotations:
            message: |-
              {{ $labels.job }}: outgoing SYN-flood attack suspected from Host={{ $labels.SrcK8S_HostName}}, Namespace={{ $labels.SrcK8S_Namespace }}, Resource={{ $labels.SrcK8S_Name }}. This is characterized by a high volume of SYN-only flows with different source IPs and/or ports.
            summary: "Outgoing SYN-flood"
          expr: sum(rate(netobserv_flows_with_flags_per_source_total{Flags="2"}[1m])) by (job, SrcK8S_HostName, SrcK8S_Namespace, SrcK8S_Name) > 300
          for: 15s
          labels:
            severity: warning
            app: netobserv
    # ...

    이 예에서 경고 임계값은 300 입니다. 그러나 이 값을 경험적으로 조정할 수 있습니다. 너무 낮은 임계값은 false-positives를 생성할 수 있으며 너무 높은 경우 실제 공격이 누락될 수 있습니다.

검증

  1. 웹 콘솔의 네트워크 트래픽 테이블 뷰에서 열 관리를 클릭하고 TCP 플래그 를 클릭합니다.
  2. 네트워크 트래픽 테이블 뷰에서 TCP 프로토콜 SYN TCPFlag. 동일한 byteSize 를 가진 많은 수의 흐름은 SYN 플러드를 나타냅니다.
  3. 모니터링경고로 이동하여 경고 규칙 탭을 선택합니다.
  4. netobserv-synflood-in 경고를 필터링합니다. SYN 플러딩이 발생하면 경고가 실행됩니다.

13장. Network Observability Operator 모니터링

OpenShift Container Platform 웹 콘솔을 사용하여 Network Observability Operator의 상태와 관련된 경고를 모니터링합니다. 이를 통해 시스템 안정성을 유지하고 운영 문제를 신속하게 감지할 수 있습니다.

13.1. 상태 대시보드

OpenShift Container Platform 웹 콘솔의 Network Observability Operator 상태 대시보드를 보고 Operator 및 해당 구성 요소의 상태 상태, 리소스 사용량 및 내부 통계를 모니터링합니다.

메트릭은 OpenShift Container Platform 웹 콘솔의 ObserveDashboards 페이지에 있습니다. 다음 카테고리에서 Network Observability Operator의 상태에 대한 메트릭을 볼 수 있습니다.

  • 초당 흐름 수
  • sampling
  • 마지막 순간 오류 발생
  • 초당 삭제된 흐름
  • FlowLogs-pipeline 통계
  • FlowLogs-pipleine 통계 뷰
  • eBPF 에이전트 통계 보기
  • Operator 통계
  • 리소스 사용량

13.2. 상태 경고

Loki 수집 오류, 제로 흐름 수집 또는 삭제된 eBPF 흐름과 같은 조건이 발생할 때 배너를 트리거하는 Network Observability Operator에서 생성한 상태 경고를 이해합니다.

경고가 트리거되면 대시보드에 지시하는 상태 경고 배너가 네트워크 트래픽 페이지에 표시될 수 있습니다. 다음과 같은 경우 경고가 생성됩니다.

  • Loki ingestion rate limit에 도달한 경우와 같이 flowlogs-pipeline 워크로드가 Loki 오류로 인해 흐름을 삭제하면 NetObservLokiError 경고가 발생합니다.
  • NetObservNoFlows 경고는 일정 시간 동안 흐름이 수집되지 않으면 발생합니다.
  • NetObservFlowsDropped 경고는 Network Observability eBPF 에이전트 해시 맵 테이블이 가득 차 있고 eBPF 에이전트는 성능이 저하되거나 용량 제한이 트리거될 때 발생합니다.

13.3. 상태 정보 보기

OpenShift Container Platform 웹 콘솔 내에서 Netobserv/Health 대시보드를 보고 Network Observability Operator 및 해당 구성 요소의 상태 및 리소스 사용량을 모니터링합니다.

사전 요구 사항

  • Network Observability Operator가 설치되어 있어야 합니다.
  • cluster-admin 역할 또는 모든 프로젝트에 대한 보기 권한이 있는 사용자로 클러스터에 액세스할 수 있습니다.

프로세스

  1. 웹 콘솔의 관리자 화면에서 모니터링대시보드 로 이동합니다.
  2. 대시보드 드롭다운에서 Netobserv/Health 를 선택합니다.
  3. 페이지에 표시되는 Operator의 상태에 대한 메트릭을 확인합니다.

13.3.1. 상태 경고 비활성화

FlowCollector 리소스를 편집하고 spec.processor.disableAlerts 사양을 사용하여 NetObservLokiError 또는 NetObservNoFlows 와 같은 특정 상태 경고를 비활성화합니다.

프로세스

  1. 웹 콘솔에서 EcosystemInstalled Operators 로 이동합니다.
  2. NetObserv Operator제공된 API 제목에서 흐름 수집기 를 선택합니다.
  3. 클러스터를 선택한 다음 YAML 탭을 선택합니다.
  4. spec.processor.metrics.disableAlerts 를 추가하여 다음 YAML 샘플과 같이 상태 경고를 비활성화합니다.

    apiVersion: flows.netobserv.io/v1beta2
    kind: FlowCollector
    metadata:
      name: cluster
    spec:
      processor:
        metrics:
          disableAlerts: [NetObservLokiError, NetObservNoFlows]

    다음과 같습니다.

    spec.processor.metrics.disableAlerts
    비활성화할 경고 유형을 하나 이상 지정합니다.

13.4. NetObserv 대시보드에 대한 Loki 속도 제한 경고 생성

HTTP 429 오류로 표시된 Loki 수집 속도 제한에 도달할 때 경고를 모니터링하고 트리거하는 Loki 메트릭을 기반으로 사용자 정의 AlertingRule 리소스를 생성합니다.

Loki 속도 제한에 도달할 때 Netobserv 대시보드 메트릭에 대한 사용자 정의 경고 규칙을 생성하여 경고를 트리거할 수 있습니다.

사전 요구 사항

  • cluster-admin 역할이 있는 사용자 또는 모든 프로젝트에 대한 보기 권한이 있는 사용자로 클러스터에 액세스할 수 있습니다.
  • Network Observability Operator가 설치되어 있어야 합니다.

프로세스

  1. 가져오기 아이콘 + 를 클릭하여 YAML 파일을 생성합니다.
  2. YAML 파일에 경고 규칙 구성을 추가합니다. 다음 YAML 샘플에서는 Loki 속도 제한에 도달할 때 경고가 생성됩니다.

    apiVersion: monitoring.openshift.io/v1
    kind: AlertingRule
    metadata:
      name: loki-alerts
      namespace: openshift-monitoring
    spec:
      groups:
      - name: LokiRateLimitAlerts
        rules:
        - alert: LokiTenantRateLimit
          annotations:
            message: |-
              {{ $labels.job }} {{ $labels.route }} is experiencing 429 errors.
            summary: "At any number of requests are responded with the rate limit error code."
          expr: sum(irate(loki_request_duration_seconds_count{status_code="429"}[1m])) by (job, namespace, route) / sum(irate(loki_request_duration_seconds_count[1m])) by (job, namespace, route) * 100 > 0
          for: 10s
          labels:
            severity: warning
  3. 생성 을 클릭하여 구성 파일을 클러스터에 적용합니다.

13.5. eBPF 에이전트 경고 사용

FlowCollector 사용자 정의 리소스에서 spec.agent.ebpf.cacheMaxFlows 값을 늘려 eBPF 에이전트 해시맵이 가득 차면 발생하는 NetObservAgentFlowsDropped 경고를 해결합니다.

용량 제한자가 트리거될 때 경고 NetObservAgentFlowsDropped 도 트리거됩니다. 이 경고가 표시되면 다음 예제와 같이 FlowCollector 에서 cacheMaxFlows 를 늘리는 것이 좋습니다.

참고

cacheMaxFlows 를 늘리면 eBPF 에이전트의 메모리 사용량이 증가할 수 있습니다.

프로세스

  1. 웹 콘솔에서 EcosystemInstalled Operators 로 이동합니다.
  2. Network Observability Operator제공된 API 제목에서 흐름 수집기 를 선택합니다.
  3. 클러스터를 선택한 다음 YAML 탭을 선택합니다.
  4. 다음 YAML 샘플과 같이 spec.agent.ebpf.cacheMaxFlows 값을 늘립니다.

    apiVersion: flows.netobserv.io/v1beta2
    kind: FlowCollector
    metadata:
      name: cluster
    spec:
      namespace: netobserv
      deploymentModel: Service
      agent:
        type: eBPF
        ebpf:
          cacheMaxFlows: 200000

    다음과 같습니다.

    spec.agent.ebpf.cacheMaxFlows
    캐시할 최대 흐름 수를 지정합니다. NetObservAgentFlowsDropped 경고가 발생하면 이 값을 현재 수준에서 늘립니다.

14장. 리소스 예약

테인트 및 허용 오차는 특정 Pod를 호스팅하는 노드를 제어하는 데 도움이 됩니다. 노드 선택기와 함께 이러한 툴을 사용하여 네트워크 관찰 구성 요소 배치를 안내합니다.

노드 선택기는 노드의 사용자 정의 레이블과 포드에 지정된 선택기를 사용하여 정의된 키/값 쌍의 맵을 지정합니다.

노드에서 Pod를 실행하려면 노드의 라벨과 동일한 키/값 노드 선택기가 Pod에 있어야 합니다.

14.1. 특정 노드에서 네트워크 관찰 기능 배포

특정 노드에서 네트워크 관찰 구성 요소의 배포를 제어하도록 NodeSelector,Tolerations, Affinity 를 포함한 스케줄링 사양을 사용하여 FlowCollector 리소스를 구성합니다.

spec.agent.ebpf.advanced.scheduling,spec.processor.advanced.scheduling, spec.consolePlugin.advanced.scheduling 사양에는 다음과 같은 구성 가능한 설정이 있습니다.

  • NodeSelector
  • 허용 오차
  • 유사성
  • PriorityClassName

spec.<component>.advanced.scheduling의 샘플 FlowCollector 리소스

apiVersion: flows.netobserv.io/v1beta2
kind: FlowCollector
metadata:
  name: cluster
spec:
# ...
advanced:
  scheduling:
    tolerations:
    - key: "<taint key>"
      operator: "Equal"
      value: "<taint value>"
      effect: "<taint effect>"
      nodeSelector:
        <key>: <value>
      affinity:
        nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: name
              operator: In
              values:
              - app-worker-node
      priorityClassName: """
# ...

15장. 보조 네트워크

SR-IOVOVN-Kubernetes 와 같은 보조 네트워크에서 네트워크 흐름 데이터를 수집하고 강화하도록 Network Observability Operator를 구성할 수 있습니다.

15.1. 사전 요구 사항

  • 보조 인터페이스 또는 L2 네트워크와 같은 추가 네트워크 인터페이스를 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.

15.2. SR-IOV 인터페이스 트래픽에 대한 모니터링 구성

spec.agent.ebpf.privileged 필드를 true 로 설정하여 SR-IOV(Single Root I/O Virtualization) 장치에서 트래픽을 모니터링하도록 FlowCollector 리소스를 구성하여 eBPF 에이전트가 다른 네트워크 네임스페이스를 모니터링할 수 있습니다.

eBPF 에이전트는 기본적으로 모니터링되는 호스트 네트워크 네임스페이스 외에도 다른 네트워크 네임스페이스를 모니터링합니다. VF(가상 기능) 인터페이스가 있는 Pod가 생성되면 새 네트워크 네임스페이스가 생성됩니다. SRIOVNetwork 정책 IPAM 구성을 지정하면 VF 인터페이스가 호스트 네트워크 네임스페이스에서 Pod 네트워크 네임스페이스로 마이그레이션됩니다.

사전 요구 사항

  • SR-IOV 장치를 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.
  • SRIOVNetwork CR(사용자 정의 리소스) spec.ipam 구성은 인터페이스에서 나열하거나 다른 플러그인에서 나열하는 범위의 IP 주소로 설정해야 합니다.

프로세스

  1. 웹 콘솔에서 EcosystemInstalled Operators 로 이동합니다.
  2. NetObserv Operator제공된 API 제목에서 흐름 수집기 를 선택합니다.
  3. 클러스터를 선택한 다음 YAML 탭을 선택합니다.
  4. FlowCollector 사용자 지정 리소스를 구성합니다. 샘플 구성은 다음과 같습니다.

    SR-IOV 모니터링을 위한 FlowCollector 구성

    apiVersion: flows.netobserv.io/v1beta2
    kind: FlowCollector
    metadata:
      name: cluster
    spec:
      namespace: netobserv
      deploymentModel: Service
      agent:
        type: eBPF
        ebpf:
          privileged: true

    • SR-IOV 모니터링을 활성화하려면 spec.agent.ebpf.privileged 필드 값을 true 로 설정해야 합니다.

eBPF 에이전트를 권한 있는 모드로 설정하고 보조 네트워크의 인덱싱을 정의하여 VM 보조 네트워크 트래픽을 모니터링하도록 FlowCollector 를 구성하여 OpenShift Virtualization의 흐름을 캡처하고 보강할 수 있습니다.

기본 내부 pod 네트워크에 연결된 VM에서 들어오는 네트워크 흐름은 네트워크 관찰 기능에 의해 자동으로 캡처됩니다.

프로세스

  1. 다음 명령을 실행하여 가상 머신 시작 관리자 Pod에 대한 정보를 가져옵니다. 이 정보는 5단계에서 사용됩니다.

    $ oc get pod virt-launcher-<vm_name>-<suffix> -n <namespace> -o yaml
    apiVersion: v1
    kind: Pod
    metadata:
      annotations:
        k8s.v1.cni.cncf.io/network-status: |-
          [{
            "name": "ovn-kubernetes",
            "interface": "eth0",
            "ips": [
              "10.129.2.39"
            ],
            "mac": "0a:58:0a:81:02:27",
            "default": true,
            "dns": {}
          },
          {
            "name": "my-vms/l2-network",
            "interface": "podc0f69e19ba2",
            "ips": [
              "10.10.10.15"
            ],
            "mac": "02:fb:f8:00:00:12",
            "dns": {}
          }]
      name: virt-launcher-fedora-aqua-fowl-13-zr2x9
      namespace: my-vms
    spec:
    #  ...
    status:
    #  ...

    다음과 같습니다.

    name
    보조 네트워크의 이름을 지정합니다.
    interface
    보조 네트워크의 네트워크 인터페이스를 지정합니다.
    ips
    보조 네트워크에서 사용하는 IP 주소 목록을 지정합니다.
    mac
    보조 네트워크에 사용되는 MAC 주소를 지정합니다.
  2. 웹 콘솔에서 EcosystemInstalled Operators 로 이동합니다.
  3. NetObserv Operator제공된 API 제목에서 흐름 수집기 를 선택합니다.
  4. 클러스터를 선택한 다음 YAML 탭을 선택합니다.
  5. 추가 네트워크 조사에서 발견한 정보를 기반으로 FlowCollector 를 구성합니다.

    apiVersion: flows.netobserv.io/v1beta2
    kind: FlowCollector
    metadata:
      name: cluster
    spec:
      agent:
        ebpf:
          privileged: true
      processor:
        advanced:
          secondaryNetworks:
          - index:
            - MAC
            name: my-vms/l2-network
    # ...

    다음과 같습니다.

    spec.agent.ebpf.privileged
    eBPF 에이전트가 권한 있는 모드에서 실행되도록 지정합니다. 이 모드는 가상 머신 시작 관리자 Pod의 보조 네트워크 인터페이스에서 흐름을 수집하는 데 필요합니다.
    spec.processor.advanced.secondaryNetworks.index
    가상 머신 시작 관리자 Pod를 인덱싱하는 데 사용할 필드를 지정합니다. MAC 주소를 인덱싱 필드로 사용하여 보조 인터페이스에 대한 네트워크 흐름을 얻는 것이 좋습니다. Pod 간에 MAC 주소가 겹치는 경우 IP 및 인터페이스와 같은 추가 인덱싱 필드를 추가하여 정확한 보강을 보장할 수 있습니다.
    MAC
    MAC 주소를 인덱싱 필드 값으로 지정합니다. 추가 네트워크 정보에 MAC 주소가 포함된 경우 인덱스 필드 목록에 MAC을 추가합니다.
    spec.processor.advanced.secondaryNetworks.name
    가상 머신 시작 관리자 Pod의 k8s.v1.cni.cncf.io/network-status 주석에 있는 보조 네트워크의 이름을 지정합니다. 형식은 일반적으로 < namespace>/<network_attachment_definition_name>입니다.

검증

  1. VM 트래픽을 관찰합니다.

    1. 네트워크 트래픽 페이지로 이동합니다.
    2. k8s.v1.cni.cncf.io/network-status 주석에 있는 가상 머신 IP를 사용하여 소스 IP로 필터링합니다.
    3. 보강해야 하는 SourceDestination 필드를 모두 보고 VM 시작 관리자 Pod 및 VM 인스턴스를 소유자로 식별합니다.

16장. Network Observability CLI

16.1. 네트워크 Observability CLI 설치

Network Observability CLI(oc netobserv)는 클러스터 네트워크 트래픽을 디버그하고 문제를 해결하는 데 사용되는 독립 실행형 OpenShift CLI(oc) 플러그인입니다. Network Observability Operator와 독립적으로 작동하여 즉각적인 네트워크 성능 진단을 수집합니다.

16.1.1. 네트워크 Observability CLI 정보

네트워크 Observability CLI(oc netobserv)를 사용하여 네트워킹 문제를 신속하게 디버그하고 해결합니다. 이 툴은 Network Observability Operator를 설치하지 않고 흐름 및 패킷에 대한 즉각적인 실시간 통찰력을 제공합니다.

Network Observability CLI는 수집된 데이터를 임시 수집기 Pod로 스트리밍하기 위해 eBPF 에이전트를 사용하는 흐름 및 패킷 시각화 툴입니다. 캡처하는 동안 영구 스토리지가 필요하지 않습니다. 실행 후 출력이 로컬 시스템으로 전송됩니다.

중요

CLI 캡처는 8-10 분과 같은 짧은 기간 동안만 실행하기위한 것입니다. 너무 오래 실행되는 경우 실행 중인 프로세스를 삭제하기 어려울 수 있습니다.

16.1.2. 네트워크 Observability CLI 설치

Network Observability CLI는 네트워크 관찰 기능을 신속하게 디버그하고 문제를 해결하는 간단한 방법을 제공합니다. 별도로 설치해야 합니다.

Network Observability CLI(oc netobserv)를 설치하는 것은 Network Observability Operator 설치와 별도의 절차입니다. 즉, 소프트웨어 카탈로그에서 Operator를 설치하더라도 CLI 를 별도로 설치해야 합니다.

참고

사용자는 선택적으로 Krew를 사용하여 netobserv CLI 플러그인을 설치할 수 있습니다. 자세한 내용은 "Krew를 사용하여 CLI 플러그인 설치"를 참조하십시오.

사전 요구 사항

  • OpenShift CLI(oc)를 설치해야 합니다.
  • macOS 또는 Linux 운영 체제가 있어야 합니다.
  • docker 또는 podman 을 설치해야 합니다.
참고

podman 또는 docker 를 사용하여 설치 명령을 실행할 수 있습니다. 이 절차에서는 podman 을 사용합니다.

프로세스

  1. 다음 명령을 실행하여 Red Hat 레지스트리에 로그인합니다.

    $ podman login registry.redhat.io
  2. 다음 명령을 실행하여 이미지에서 oc-netobserv 파일을 추출합니다.

    $ podman create --name netobserv-cli registry.redhat.io/network-observability/network-observability-cli-rhel9:1.11
    $ podman cp netobserv-cli:/oc-netobserv .
    $ podman rm netobserv-cli
  3. 추출된 파일을 시스템의 PATH 에 있는 디렉터리(예: /usr/local/bin/ )로 이동합니다.

    $ sudo mv oc-netobserv /usr/local/bin/

검증

  1. oc netobserv 를 사용할 수 있는지 확인합니다.

    $ oc netobserv version

    이 명령은 다음 예와 유사한 결과를 생성해야 합니다.

Netobserv CLI version <version>

16.2. 네트워크 Observability CLI 사용

Network Observability CLI는 터미널 내에서 직접 네트워크 흐름 및 패킷 Telemetry를 필터링하고 시각화합니다. 이 툴은 캡처된 데이터를 타사 분석 유틸리티와 원활하게 통합하기 위해 JSON, 데이터베이스 파일 또는 PCAP( Packet Capture) 파일로 내보냅니다.

16.2.1. 흐름 캡처

네트워크 흐름을 캡처하고 CLI에서 직접 리소스 또는 영역을 기반으로 필터를 적용합니다. 이를 통해 서로 다른 두 영역 간의 RTT(Round-Trip Time) 시각화와 같은 복잡한 사용 사례를 해결할 수 있습니다.

CLI의 테이블 시각화는 보기 및 흐름 검색 기능을 제공합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • 네트워크 Observability CLI(oc netobserv) 플러그인을 설치합니다.

프로세스

  1. 다음 명령을 실행하여 활성화된 필터를 사용하여 흐름을 캡처합니다.

    $ oc netobserv flows --enable_filter=true --action=Accept --cidr=0.0.0.0/0 --protocol=TCP --port=49051
  2. 터미널의 라이브 테이블 필터 프롬프트에 필터 를 추가하여 들어오는 흐름을 추가로 조정합니다. 예를 들면 다음과 같습니다.

    live table filter: [SrcK8S_Zone:us-west-1b] press enter to match multiple regular expressions at once
  3. PageUpPageDown 키를 사용하여 없음,리소스,영역,호스트,소유자위의 모든 항목을 전환합니다.
  4. 캡처를 중지하려면 Ctrl+C 누릅니다. 캡처된 데이터는 CLI를 설치하는 데 사용되는 것과 동일한 경로에 있는 ./output 디렉터리에 있는 두 개의 개별 파일에 기록됩니다.
  5. 캡처된 데이터의 JSON 배열이 포함된 ./output/flow/<capture_date_time>.json JSON 파일에서 캡처된 데이터를 확인합니다.

    JSON 파일의 예

    {
      "AgentIP": "10.0.1.76",
      "Bytes": 561,
      "DnsErrno": 0,
      "Dscp": 20,
      "DstAddr": "f904:ece9:ba63:6ac7:8018:1e5:7130:0",
      "DstMac": "0A:58:0A:80:00:37",
      "DstPort": 9999,
      "Duplicate": false,
      "Etype": 2048,
      "Flags": 16,
      "FlowDirection": 0,
      "IfDirection": 0,
      "Interface": "ens5",
      "K8S_FlowLayer": "infra",
      "Packets": 1,
      "Proto": 6,
      "SrcAddr": "3e06:6c10:6440:2:a80:37:b756:270f",
      "SrcMac": "0A:58:0A:80:00:01",
      "SrcPort": 46934,
      "TimeFlowEndMs": 1709741962111,
      "TimeFlowRttNs": 121000,
      "TimeFlowStartMs": 1709741962111,
      "TimeReceived": 1709741964
    }

  6. SQLite를 사용하여 ./output/flow/<capture_date_time>.db 데이터베이스 파일을 검사할 수 있습니다. 예를 들면 다음과 같습니다.

    1. 다음 명령을 실행하여 파일을 엽니다.

      $ sqlite3 ./output/flow/<capture_date_time>.db
    2. SQLite SELECT 문을 실행하여 데이터를 쿼리합니다. 예를 들면 다음과 같습니다.

      sqlite> SELECT DnsLatencyMs, DnsFlagsResponseCode, DnsId, DstAddr, DstPort, Interface, Proto, SrcAddr, SrcPort, Bytes, Packets FROM flow WHERE DnsLatencyMs >10 LIMIT 10;

      출력 예

      12|NoError|58747|10.128.0.63|57856||17|172.30.0.10|53|284|1
      11|NoError|20486|10.128.0.52|56575||17|169.254.169.254|53|225|1
      11|NoError|59544|10.128.0.103|51089||17|172.30.0.10|53|307|1
      13|NoError|32519|10.128.0.52|55241||17|169.254.169.254|53|254|1
      12|NoError|32519|10.0.0.3|55241||17|169.254.169.254|53|254|1
      15|NoError|57673|10.128.0.19|59051||17|172.30.0.10|53|313|1
      13|NoError|35652|10.0.0.3|46532||17|169.254.169.254|53|183|1
      32|NoError|37326|10.0.0.3|52718||17|169.254.169.254|53|169|1
      14|NoError|14530|10.0.0.3|58203||17|169.254.169.254|53|246|1
      15|NoError|40548|10.0.0.3|45933||17|169.254.169.254|53|174|1

16.2.2. 패킷 캡처

네트워크 Observability CLI를 사용하여 네트워크 패킷을 캡처합니다. 정확한 실시간 디버깅을 위해 필터를 적용하고 터미널에서 실시간 디버깅을 개선할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • 네트워크 Observability CLI(oc netobserv) 플러그인을 설치합니다.

프로세스

  1. 필터가 활성화된 상태에서 패킷 캡처를 실행합니다.

    $ oc netobserv packets --action=Accept --cidr=0.0.0.0/0 --protocol=TCP --port=49051
  2. 터미널의 라이브 테이블 필터 프롬프트에 필터 를 추가하여 들어오는 패킷을 구체화합니다. 예제 필터는 다음과 같습니다.

    live table filter: [SrcK8S_Zone:us-west-1b] press enter to match multiple regular expressions at once
  3. PageUpPageDown 키를 사용하여 없음,리소스,영역,호스트,소유자위의 모든 항목을 전환합니다.
  4. 캡처를 중지하려면 Ctrl+C 누릅니다.
  5. CLI를 설치하는 데 사용된 것과 동일한 경로에 있는 ./output/pcap 디렉터리에 있는 단일 파일에 기록된 캡처된 데이터를 확인합니다.

    1. ./output/pcap/<capture_date_time>.pcap 파일은 Wireshark로 열 수 있습니다.

16.2.3. 메트릭 캡처

서비스 모니터를 사용하여 Prometheus에서 온디맨드 네트워크 관찰 기능 대시보드를 생성합니다. 이를 통해 네트워크 메트릭을 신속하게 보고 분석할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • 네트워크 Observability CLI(oc netobserv) 플러그인을 설치합니다.

프로세스

  1. 다음 명령을 실행하여 필터를 사용하여 메트릭을 캡처합니다.

    출력 예

    $ oc netobserv metrics --enable_filter=true --cidr=0.0.0.0/0 --protocol=TCP --port=49051

  2. 터미널에 제공된 링크를 열어 NetObserv / On-Demand 대시보드를 확인합니다.

    예제 URL

    https://console-openshift-console.apps.rosa...openshiftapps.com/monitoring/dashboards/netobserv-cli

    참고

    빈 그래프로 표시되지 않는 기능.

16.2.4. 네트워크 Observability CLI 정리

oc netobserv cleanup 을 사용하여 클러스터에서 Network Observability CLI에서 설치한 모든 구성 요소를 수동으로 제거합니다. 캡처 후 클라이언트가 이 명령을 자동으로 실행하는 동안 연결 문제에 직면하면 수동으로 실행해야 할 수 있습니다.

프로세스

  • 다음 명령을 실행합니다.

    $ oc netobserv cleanup

16.3. Network Observability CLI (oc netobserv) 참조

Network Observability CLI(oc netobserv)는 Network Observability Operator와 기능 및 필터링 패리티를 제공합니다. 명령줄 인수를 사용하여 기능을 동적으로 전환하고 특정 클러스터 네트워크 트래픽 흐름을 분리합니다.

16.3.1. Network Observability CLI 사용

Network Observability CLI(oc netobserv)를 사용하여 명령줄 인수를 전달하여 추가 분석을 위해 흐름 데이터, 패킷 데이터 및 메트릭을 캡처하고 Network Observability Operator에서 지원하는 기능을 활성화할 수 있습니다.

16.3.1.1. 구문

oc netobserv 명령의 기본 구문:

oc netobserv 구문

$ oc netobserv [<command>] [<feature_option>] [<command_options>] 
1

1
기능 옵션은 oc netobserv flows 명령과 함께만 사용할 수 있습니다. oc netobserv packets 명령과 함께 사용할 수 없습니다.
16.3.1.2. 기본 명령
Expand
표 16.1. 기본 명령
명령설명

flows

흐름 정보를 캡처합니다. 하위 명령의 경우 "Flows capture options" 표를 참조하십시오.

패킷

패킷 데이터를 캡처합니다. 하위 명령의 경우 "Packets capture options" 표를 참조하십시오.

metrics

지표 데이터를 캡처합니다. 하위 명령의 경우 "Metrics capture options" 표를 참조하십시오.

팔로우

백그라운드에서 실행할 때 수집기 로그를 따릅니다.

중지

에이전트 daemonset를 제거하여 컬렉션을 중지합니다.

복사

수집기에서 로컬로 생성된 파일을 복사합니다.

cleanup

Network Observability CLI 구성 요소를 제거합니다.

version

소프트웨어 버전을 출력합니다.

help

도움말 표시.

16.3.1.3. 흐름 캡처 옵션

흐름 캡처에는 패킷 드롭에 대한 추가 기능 활성화, DNS 대기 시간, Round-trip 시간, 필터링 등 필수 명령과 추가 옵션이 있습니다.

oc netobserv flows 구문

$ oc netobserv flows [<feature_option>] [<command_options>]

Expand
옵션설명기본

--enable_all

모든 eBPF 기능 활성화

false

--enable_dns

DNS 추적 활성화

false

--enable_ipsec

IPsec 추적 활성화

false

--enable_network_events

네트워크 이벤트 모니터링 활성화

false

--enable_pkt_translation

패킷 변환 활성화

false

--enable_pkt_drop

패킷 삭제 활성화

false

--enable_rtt

RTT 추적 활성화

false

--enable_udn_mapping

사용자 정의 네트워크 매핑 활성화

false

--get-subnets

서브넷 정보 가져오기

false

--privileged

강제 eBPF 에이전트 권한 모드

auto

--sampling

패킷 샘플링 간격

1

--backRepository

백그라운드에서 실행

false

--copy

출력 파일을 로컬로 복사

prompt

--log-level

구성 요소 로그

info

--max-time

최대 캡처 시간

5m

--max-bytes

최대 캡처 바이트

50000000 = 50MB

--action

필터 작업

accept

--cidr

CIDR 필터링

0.0.0.0/0

--direction

필터 방향

-

--dport

대상 포트 필터링

-

--dport_range

대상 포트 범위 필터링

-

--dports

두 대상 포트 중 하나에서 필터링

-

--drops

삭제된 패킷만 포함된 필터 흐름

false

--icmp_code

ICMP 코드 필터링

-

--icmp_type

필터 ICMP 유형

-

--node-selector

특정 노드에서 캡처

-

--peer_ip

피어 IP 필터링

-

--peer_cidr

피어 CIDR 필터링

-

--port_range

포트 범위 필터링

-

--port

필터 포트

-

--ports

두 포트 중 하나에서 필터링

-

--protocol

필터 프로토콜

-

--query

사용자 정의 쿼리를 사용하여 흐름을 필터링

-

--sport_range

소스 포트 범위 필터링

-

--sport

소스 포트 필터링

-

--sports

두 개의 소스 포트 중 하나에서 필터링

-

--tcp_flags

필터 TCP 플래그

-

--interfaces

모니터링할 인터페이스 목록, 쉼표로 구분됨

-

--exclude_interfaces

제외할 인터페이스 목록, 쉼표로 구분

Lo

PacketDrop 및 RTT 기능이 활성화된 TCP 프로토콜 및 포트 49051에서 흐름 캡처를 실행하는 예:

$ oc netobserv flows --enable_pkt_drop  --enable_rtt --action=Accept --cidr=0.0.0.0/0 --protocol=TCP --port=49051

16.3.1.4. 패킷 캡처 옵션

필터를 사용하여 패킷 캡처와 동일한 데이터를 캡처할 수 있습니다. 패킷 드롭, DNS, RTT 및 네트워크 이벤트와 같은 특정 기능은 흐름 및 메트릭 캡처에만 사용할 수 있습니다.

oc netobserv 패킷 구문

$ oc netobserv packets [<option>]

Expand
옵션설명기본

--backRepository

백그라운드에서 실행

false

--copy

출력 파일을 로컬로 복사

prompt

--log-level

구성 요소 로그

info

--max-time

최대 캡처 시간

5m

--max-bytes

최대 캡처 바이트

50000000 = 50MB

--action

필터 작업

accept

--cidr

CIDR 필터링

0.0.0.0/0

--direction

필터 방향

-

--dport

대상 포트 필터링

-

--dport_range

대상 포트 범위 필터링

-

--dports

두 대상 포트 중 하나에서 필터링

-

--drops

삭제된 패킷만 포함된 필터 흐름

false

--icmp_code

ICMP 코드 필터링

-

--icmp_type

필터 ICMP 유형

-

--node-selector

특정 노드에서 캡처

-

--peer_ip

피어 IP 필터링

-

--peer_cidr

피어 CIDR 필터링

-

--port_range

포트 범위 필터링

-

--port

필터 포트

-

--ports

두 포트 중 하나에서 필터링

-

--protocol

필터 프로토콜

-

--query

사용자 정의 쿼리를 사용하여 흐름을 필터링

-

--sport_range

소스 포트 범위 필터링

-

--sport

소스 포트 필터링

-

--sports

두 개의 소스 포트 중 하나에서 필터링

-

--tcp_flags

필터 TCP 플래그

-

TCP 프로토콜 및 포트 49051에서 패킷 캡처를 실행하는 예:

$ oc netobserv packets --action=Accept --cidr=0.0.0.0/0 --protocol=TCP --port=49051

16.3.1.5. 메트릭 캡처 옵션

흐름 캡처와 동일한 메트릭 캡처에서 기능을 활성화하고 필터를 사용할 수 있습니다. 생성된 그래프는 그에 따라 대시보드에 채워집니다.

oc netobserv 메트릭 구문

$ oc netobserv metrics [<option>]

Expand
옵션설명기본

--enable_all

모든 eBPF 기능 활성화

false

--enable_dns

DNS 추적 활성화

false

--enable_ipsec

IPsec 추적 활성화

false

--enable_network_events

네트워크 이벤트 모니터링 활성화

false

--enable_pkt_translation

패킷 변환 활성화

false

--enable_pkt_drop

패킷 삭제 활성화

false

--enable_rtt

RTT 추적 활성화

false

--enable_udn_mapping

사용자 정의 네트워크 매핑 활성화

false

--get-subnets

서브넷 정보 가져오기

false

--privileged

강제 eBPF 에이전트 권한 모드

auto

--sampling

패킷 샘플링 간격

1

--backRepository

백그라운드에서 실행

false

--log-level

구성 요소 로그

info

--max-time

최대 캡처 시간

1h

--action

필터 작업

accept

--cidr

CIDR 필터링

0.0.0.0/0

--direction

필터 방향

-

--dport

대상 포트 필터링

-

--dport_range

대상 포트 범위 필터링

-

--dports

두 대상 포트 중 하나에서 필터링

-

--drops

삭제된 패킷만 포함된 필터 흐름

false

--icmp_code

ICMP 코드 필터링

-

--icmp_type

필터 ICMP 유형

-

--node-selector

특정 노드에서 캡처

-

--peer_ip

피어 IP 필터링

-

--peer_cidr

피어 CIDR 필터링

-

--port_range

포트 범위 필터링

-

--port

필터 포트

-

--ports

두 포트 중 하나에서 필터링

-

--protocol

필터 프로토콜

-

--query

사용자 정의 쿼리를 사용하여 흐름을 필터링

-

--sport_range

소스 포트 범위 필터링

-

--sport

소스 포트 필터링

-

--sports

두 개의 소스 포트 중 하나에서 필터링

-

--tcp_flags

필터 TCP 플래그

-

--include_list

생성할 메트릭 이름 목록, 쉼표로 구분

namespace_flows_total,node_ingress_bytes_total,node_egress_bytes_total,workload_ingress_bytes_total

--interfaces

모니터링할 인터페이스 목록, 쉼표로 구분됨

-

--exclude_interfaces

제외할 인터페이스 목록, 쉼표로 구분

Lo

TCP 드롭 다운에 대한 메트릭 캡처 실행 예

$ oc netobserv metrics --enable_pkt_drop --protocol=TCP

17장. FlowCollector API 참조

FlowCollector API는 네트워크 흐름 수집을 위한 배포를 Pilot하고 구성하는 데 사용되는 기본 스키마입니다. 이 참조 가이드에서는 이러한 중요한 설정을 관리하는 데 도움이 됩니다.

17.1. FlowCollector API 사양

설명
FlowCollector 는 기본 배포를 시험하고 구성하는 네트워크 흐름 컬렉션 API의 스키마입니다.
유형
object
Expand
속성유형설명

apiVersion

string

APIVersion은 버전이 지정된 이 오브젝트 표현의 스키마를 정의합니다. 서버는 인식된 스키마를 최신 내부 값으로 변환해야 하며 인식할 수 없는 값을 거부할 수 있습니다. 자세한 내용은 https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

kind

string

kind는 이 오브젝트가 나타내는 REST 리소스에 해당하는 문자열 값입니다. 서버는 클라이언트가 요청을 제출하는 끝점에서 이를 유추할 수 있습니다. CamelCase로 업데이트할 수 없습니다. 자세한 내용은 https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

메타데이터

object

표준 오브젝트의 메타데이터입니다. 자세한 내용은 https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

spec

object

FlowCollector 리소스의 원하는 상태를 정의합니다.

*: 이 문서 전체에서 기능에 대해 "지원되지 않음" 또는 "더 이상 사용되지 않음"은 이 기능이 Red Hat에서 공식적으로 지원하지 않음을 의미합니다. 예를 들어 커뮤니티에서 기여하고 유지 관리를 위한 공식적인 동의 없이 수락되었을 수 있습니다. 제품 유지 관리자는 최상의 노력으로 이러한 기능에 대한 지원을 제공할 수 있습니다.

17.1.1. .metadata

설명
표준 오브젝트의 메타데이터입니다. 자세한 내용은 https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
유형
object

17.1.2. .spec

설명

FlowCollector 리소스의 원하는 상태를 정의합니다.

*: 이 문서 전체에서 기능에 대해 "지원되지 않음" 또는 "더 이상 사용되지 않음"은 이 기능이 Red Hat에서 공식적으로 지원하지 않음을 의미합니다. 예를 들어 커뮤니티에서 기여하고 유지 관리를 위한 공식적인 동의 없이 수락되었을 수 있습니다. 제품 유지 관리자는 최상의 노력으로 이러한 기능에 대한 지원을 제공할 수 있습니다.

유형
object
Expand
속성유형설명

agent

object

흐름 추출에 대한 에이전트 구성입니다.

consolePlugin

object

Console Plugin 은 사용 가능한 경우 OpenShift Container Platform 콘솔 플러그인과 관련된 설정을 정의합니다.

deploymentModel

string

deploymentModel 은 흐름 처리를 위해 원하는 유형의 배포를 정의합니다. 가능한 값은 다음과 같습니다:

- 흐름 프로세서가 확장 가능한 배포에서 지원하는 Kubernetes 서비스로 수신 대기하도록 하는 서비스 (기본값)입니다.

- Kafka to make flows sent to a Kafka pipeline before consumption by the processor.

- 흐름 프로세서가 DaemonSet에서 지원하는 호스트 네트워크를 사용하여 에이전트에서 직접 수신하도록 합니다. 15개의 노드 미만의 소규모 클러스터에서만 권장됩니다.

Kafka는 더 나은 확장성, 복원력 및 고가용성을 제공할 수 있습니다(자세한 내용은 https://www.redhat.com/en/topics/integration/what-is-apache-kafka)를 참조하십시오.

메모리 효율이 낮기 때문에 대규모 클러스터에서 direct 를 사용하지 않는 것이 좋습니다.

exporters

array

exporters 는 사용자 정의 사용 또는 스토리지에 대한 추가 선택적 내보내기를 정의합니다.

kafka

object

Kafka 구성을 통해 Kafka를 흐름 컬렉션 파이프라인의 일부로 브로커로 사용할 수 있습니다. spec.deploymentModelKafka 인 경우 사용할 수 있습니다.

loki

object

Loki, 흐름 저장소, 클라이언트 설정.

네임스페이스

string

네트워크 Observability Pod가 배포되는 네임스페이스입니다.

networkPolicy

object

NetworkPolicy 는 네트워크 Observability 구성 요소 격리에 대한 네트워크 정책 설정을 정의합니다.

프로세서

object

프로세서는 에이전트에서 흐름을 수신하고, 보강하고, 메트릭을 생성하고, Loki 지속성 계층 및/또는 사용 가능한 내보내기로 전달하는 구성 요소의 설정을 정의합니다.

prometheus

object

Prometheus 는 콘솔 플러그인에서 지표를 가져오는 데 사용되는 querier 구성과 같은 Prometheus 설정을 정의합니다.

17.1.3. .spec.agent

설명
흐름 추출에 대한 에이전트 구성입니다.
유형
object
Expand
속성유형설명

ebpf

object

eBPFspec.agent.typeeBPF로 설정된 경우 eBPF 기반 흐름 보고기와 관련된 설정을 설명합니다.

type

string

유형 [더 이상 사용되지 않음(*)]은 흐름 추적 에이전트를 선택합니다. 이전에는 이 필드를 eBPF 또는 IPFIX 중에서 선택할 수 있었습니다. 이제 eBPF 만 허용되므로 이 필드는 더 이상 사용되지 않으며 향후 API 버전에서 제거될 예정입니다.

17.1.4. .spec.agent.ebpf

설명
eBPFspec.agent.typeeBPF로 설정된 경우 eBPF 기반 흐름 보고기와 관련된 설정을 설명합니다.
유형
object
Expand
속성유형설명

advanced

object

Advanced 를 사용하면 eBPF 에이전트의 내부 구성의 일부 측면을 설정할 수 있습니다. 이 섹션은 GOGCGOMAXPROCS 환경 변수와 같은 디버깅 및 세분화된 성능 최적화를 목표로 합니다. 이러한 값을 at your own risk로 설정합니다. 거기에서 기본 Linux 기능을 재정의할 수도 있습니다.

cacheActiveTimeout

string

cacheActiveTimeout 은 에이전트가 전송되기 전에 흐름을 집계하는 기간입니다. cacheMaxFlowscacheActiveTimeout 을 늘리면 네트워크 트래픽 오버헤드와 CPU 로드를 줄일 수 있지만 더 많은 메모리 소비와 흐름 컬렉션에서 대기 시간이 증가할 수 있습니다.

cacheMaxFlows

integer

cacheMaxFlows 는 집계의 최대 흐름 수입니다. 도달하면 보고자가 흐름을 보냅니다. cacheMaxFlowscacheActiveTimeout 을 늘리면 네트워크 트래픽 오버헤드와 CPU 로드를 줄일 수 있지만 더 많은 메모리 소비와 흐름 컬렉션에서 대기 시간이 증가할 수 있습니다.

excludeInterfaces

배열(문자열)

excludeInterfaces 에는 흐름 추적에서 제외된 인터페이스 이름이 포함되어 있습니다. 슬래시로 묶은 항목(예: /br-/ )은 정규식으로 일치합니다. 그렇지 않으면 대소문자를 구분하지 않는 문자열로 일치됩니다.

features

배열(문자열)

활성화할 추가 기능 목록입니다. 모두 기본적으로 비활성화되어 있습니다. 추가 기능을 활성화하면 성능에 영향을 미칠 수 있습니다. 가능한 값은 다음과 같습니다:

- PacketDrop: 패킷 삭제 흐름 로깅 기능을 활성화합니다. 이 기능을 사용하려면 커널 디버그 파일 시스템을 마운트해야 하므로 eBPF 에이전트 Pod는 spec.agent.ebpf.privileged 를 통해 권한으로 실행해야 합니다.

- DNSTracking: DNS 추적 기능을 활성화합니다.

- FlowRTT: TCP 트래픽에서 eBPF 에이전트의 흐름 대기 시간(sRTT) 추출을 활성화합니다.

- NetworkEvents: 흐름 및 네트워크 정책과 같은 네트워크 이벤트 모니터링 기능을 활성화합니다. 이 기능을 사용하려면 커널 디버그 파일 시스템을 마운트해야 하므로 eBPF 에이전트 Pod는 spec.agent.ebpf.privileged 를 통해 권한으로 실행해야 합니다. Observability 기능과 함께 OVN-Kubernetes 네트워크 플러그인을 사용해야 합니다. 중요: 이 기능은 기술 프리뷰로 사용할 수 있습니다.

- PacketTranslation: Service NAT와 같은 패킷 변환 정보를 사용하여 흐름을 강화합니다.

- EbpfManager: [Unsupported (*)]. eBPF Manager를 사용하여 네트워크 Observability eBPF 프로그램을 관리합니다. 사전 요구 사항: eBPF Manager Operator(또는 업스트림 bpfman operator)를 설치해야 합니다.

- UDNMapping: UDN(사용자 정의 네트워크)에 인터페이스를 매핑할 수 있습니다.

이 기능을 사용하려면 커널 디버그 파일 시스템을 마운트해야 하므로 eBPF 에이전트 Pod는 spec.agent.ebpf.privileged 를 통해 권한으로 실행해야 합니다. Observability 기능과 함께 OVN-Kubernetes 네트워크 플러그인을 사용해야 합니다.

- IPsec 암호화를 사용하여 노드 간 흐름을 추적합니다.

flowFilter

object

flowFilter 는 흐름 필터링과 관련된 eBPF 에이전트 구성을 정의합니다.

imagePullPolicy

string

imagePullPolicy 는 위에 정의된 이미지의 Kubernetes 가져오기 정책입니다.

인터페이스

배열(문자열)

인터페이스에 는 흐름이 수집되는 위치의 인터페이스 이름이 포함되어 있습니다. 비어 있는 경우 에이전트는 excludeInterfaces 에 나열된 인터페이스를 제외하고 시스템의 모든 인터페이스를 가져옵니다. 슬래시로 묶은 항목(예: /br-/ )은 정규식으로 일치합니다. 그렇지 않으면 대소문자를 구분하지 않는 문자열로 일치됩니다.

kafkaBatchSize

integer

kafkaBatchSize 는 파티션으로 전송되기 전에 요청의 최대 크기를 바이트 단위로 제한합니다. Kafka를 사용하지 않을 때는 무시됩니다. 기본값: 1MB.

logLevel

string

loglevel 은 Network Observability eBPF Agent의 로그 수준을 정의합니다.

metrics

object

메트릭은 메트릭 과 관련된 eBPF 에이전트 구성을 정의합니다.

privileged

boolean

eBPF 에이전트 컨테이너의 권한 모드입니다. true 로 설정하면 에이전트는 보조 인터페이스를 포함하여 더 많은 트래픽을 캡처할 수 있습니다. Operator는 무시하거나 false 로 설정하면 Operator가 세분화된 기능(BPF, PERFMON, NET_ADMIN)을 컨테이너로 설정합니다. 일부 에이전트 기능에는 패킷 드롭 추적과 같은 권한 있는 모드가 필요합니다( 기능참조) 및 SR-IOV 지원.

resources

object

리소스는 이 컨테이너에 필요한 컴퓨팅 리소스입니다. 자세한 내용은 https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/에서 참조하십시오.

sampling

integer

eBPF 프로브의 샘플링 간격입니다. 100은 100인 하나의 패킷이 전송됨을 의미합니다. 0 또는 1은 모든 패킷이 샘플링됨을 의미합니다.

17.1.5. .spec.agent.ebpf.advanced

설명
Advanced 를 사용하면 eBPF 에이전트의 내부 구성의 일부 측면을 설정할 수 있습니다. 이 섹션은 GOGCGOMAXPROCS 환경 변수와 같은 디버깅 및 세분화된 성능 최적화를 목표로 합니다. 이러한 값을 at your own risk로 설정합니다. 거기에서 기본 Linux 기능을 재정의할 수도 있습니다.
유형
object
Expand
속성유형설명

capOverride

배열(문자열)

Linux 기능은 권한으로 실행되지 않는 경우 재정의됩니다. 기본 기능은 BPF, PERFMON 및 NET_ADMIN입니다.

env

오브젝트(문자열)

env 를 사용하면 사용자 지정 환경 변수를 기본 구성 요소에 전달할 수 있습니다. GOGCGOMAXPROCS 와 같은 매우 구체적인 성능 튜닝 옵션을 전달하는 데 유용합니다. 이는 에지 디버그 또는 지원 시나리오에서만 유용하므로 FlowCollector 설명자의 일부로 공개적으로 노출해서는 안 됩니다.

scheduling

object

스케줄링은 노드에서 Pod를 예약하는 방법을 제어합니다.

17.1.6. .spec.agent.ebpf.advanced.scheduling

설명
스케줄링은 노드에서 Pod를 예약하는 방법을 제어합니다.
유형
object
Expand
속성유형설명

유사성

object

지정된 경우 Pod의 스케줄링 제약 조건입니다. 문서는 https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling 를 참조하십시오.

nodeSelector

오브젝트(문자열)

nodeSelector 를 사용하면 각 라벨이 지정된 노드에만 Pod를 예약할 수 있습니다. 문서는 https://kubernetes.io/docs/concepts/configuration/assign-pod-node/ 를 참조하십시오.

priorityClassName

string

지정된 경우 Pod의 우선 순위를 나타냅니다. 문서는 https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/#how-to-use-priority-and-preemption 를 참조하십시오. 지정하지 않으면 기본 우선순위가 사용되거나 기본값이 없는 경우 0이 사용됩니다.

허용 오차

array

허용 오차 는 일치하는 테인트가 있는 노드에 Pod를 예약할 수 있는 허용 오차 목록입니다. 문서는 https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling 를 참조하십시오.

17.1.7. .spec.agent.ebpf.advanced.scheduling.affinity

설명
지정된 경우 Pod의 스케줄링 제약 조건입니다. 문서는 https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling 를 참조하십시오.
유형
object

17.1.8. .spec.agent.ebpf.advanced.scheduling.tolerations

설명
허용 오차 는 일치하는 테인트가 있는 노드에 Pod를 예약할 수 있는 허용 오차 목록입니다. 문서는 https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling 를 참조하십시오.
유형
array

17.1.9. .spec.agent.ebpf.flowFilter

설명
flowFilter 는 흐름 필터링과 관련된 eBPF 에이전트 구성을 정의합니다.
유형
object
Expand
속성유형설명

작업

string

작업은 필터와 일치하는 흐름에서 수행할 작업을 정의합니다. 사용 가능한 옵션은 기본값인 AcceptReject 입니다.

cidr

string

CIDR 은 흐름을 필터링할 IP CIDR을 정의합니다. 예: 10.10.10.0/24 또는 100:100:100:100::/64

destPorts

integer-or-string

destPorts 는 선택적으로 흐름을 필터링할 대상 포트를 정의합니다. 단일 포트를 필터링하려면 단일 포트를 정수 값으로 설정합니다. 예를 들어 destPorts: 80 입니다. 포트 범위를 필터링하려면 문자열 형식으로 "start-end" 범위를 사용합니다. 예를 들어 destPorts: "80-100" 입니다. 두 포트를 필터링하려면 문자열 형식으로 "port1,port2"를 사용합니다. 예를 들어 포트: "80,100" 입니다.

direction

string

방향은 선택적으로 흐름을 필터링할 방향을 정의합니다. 사용 가능한 옵션은 IngressEgress 입니다.

enable

boolean

eBPF 흐름 필터링 기능을 활성화하려면 enabletrue 로 설정합니다.

icmpCode

integer

IMP(Internet Control Message Protocol) 트래픽의 경우 icmpCode 에서는 선택적으로 흐름을 필터링할 ICMP 코드를 정의합니다.

icmpType

integer

ICMP 트래픽의 경우 icmpType.icmpType은 선택적으로 흐름을 필터링할 ICMP 유형을 정의합니다.

peerCIDR

string

peerCIDR 는 흐름을 필터링할 피어 IP CIDR을 정의합니다. 예: 10.10.10.0/24 또는 100:100:100:100::/64

peerIP

string

peerIP 는 선택적으로 흐름을 필터링할 원격 IP 주소를 정의합니다. 예: 10.10.10.10 .

pktDrops

boolean

pktDrops 는 선택적으로 패킷 드롭을 포함하는 흐름만 필터링합니다.

ports

integer-or-string

포트 선택적으로 흐름을 필터링할 포트를 정의합니다. 소스 및 대상 포트 모두에 사용됩니다. 단일 포트를 필터링하려면 단일 포트를 정수 값으로 설정합니다. 예를 들어 포트: 80 입니다. 포트 범위를 필터링하려면 문자열 형식으로 "start-end" 범위를 사용합니다. 예를 들어 포트: "80-100" 입니다. 두 포트를 필터링하려면 문자열 형식으로 "port1,port2"를 사용합니다. 예를 들어 포트: "80,100" 입니다.

protocol

string

프로토콜 은 선택적으로 흐름을 필터링할 프로토콜을 정의합니다. 사용 가능한 옵션은 TCP,UDP,ICMP,ICMPv6SCTP 입니다.

rules

array

규칙은 eBPF 에이전트에서 필터링 규칙 목록을 정의합니다. 필터링이 활성화되면 기본적으로 규칙과 일치하지 않는 흐름이 거부됩니다. 기본값을 변경하려면 { action: "Accept", cidr: "0.0.0.0/0"} }을(를) 허용하는 규칙을 정의한 다음 거부 규칙으로 구체화할 수 있습니다.

sampling

integer

샘플링 은 일치하는 패킷의 샘플링 간격이며 spec.agent.ebpf.sampling 에 정의된 글로벌 샘플링을 재정의합니다.

sourcePorts

integer-or-string

sourcePorts 는 선택적으로 흐름을 필터링할 소스 포트를 정의합니다. 단일 포트를 필터링하려면 단일 포트를 정수 값으로 설정합니다. 예를 들어 sourcePorts: 80 입니다. 포트 범위를 필터링하려면 문자열 형식으로 "start-end" 범위를 사용합니다. 예를 들어 sourcePorts: "80-100" 입니다. 두 포트를 필터링하려면 문자열 형식으로 "port1,port2"를 사용합니다. 예를 들어 포트: "80,100" 입니다.

tcpFlags

string

tcpFlags 는 선택적으로 흐름을 필터링하는 TCP 플래그를 정의합니다. 표준 플래그(RFC-9293) 외에도 SYN-ACK,FIN-ACK, RST-ACK 의 세 가지 조합 중 하나로 필터링할 수도 있습니다.

17.1.10. .spec.agent.ebpf.flowFilter.rules

설명
규칙은 eBPF 에이전트에서 필터링 규칙 목록을 정의합니다. 필터링이 활성화되면 기본적으로 규칙과 일치하지 않는 흐름이 거부됩니다. 기본값을 변경하려면 { action: "Accept", cidr: "0.0.0.0/0"} }을(를) 허용하는 규칙을 정의한 다음 거부 규칙으로 구체화할 수 있습니다.
유형
array

17.1.11. .spec.agent.ebpf.flowFilter.rules[]

설명
CryostatPFFlowFilterRule 은 흐름 필터링 규칙에 대한 원하는 eBPF 에이전트 구성을 정의합니다.
유형
object
Expand
속성유형설명

작업

string

작업은 필터와 일치하는 흐름에서 수행할 작업을 정의합니다. 사용 가능한 옵션은 기본값인 AcceptReject 입니다.

cidr

string

CIDR 은 흐름을 필터링할 IP CIDR을 정의합니다. 예: 10.10.10.0/24 또는 100:100:100:100::/64

destPorts

integer-or-string

destPorts 는 선택적으로 흐름을 필터링할 대상 포트를 정의합니다. 단일 포트를 필터링하려면 단일 포트를 정수 값으로 설정합니다. 예를 들어 destPorts: 80 입니다. 포트 범위를 필터링하려면 문자열 형식으로 "start-end" 범위를 사용합니다. 예를 들어 destPorts: "80-100" 입니다. 두 포트를 필터링하려면 문자열 형식으로 "port1,port2"를 사용합니다. 예를 들어 포트: "80,100" 입니다.

direction

string

방향은 선택적으로 흐름을 필터링할 방향을 정의합니다. 사용 가능한 옵션은 IngressEgress 입니다.

icmpCode

integer

IMP(Internet Control Message Protocol) 트래픽의 경우 icmpCode 에서는 선택적으로 흐름을 필터링할 ICMP 코드를 정의합니다.

icmpType

integer

ICMP 트래픽의 경우 icmpType.icmpType은 선택적으로 흐름을 필터링할 ICMP 유형을 정의합니다.

peerCIDR

string

peerCIDR 는 흐름을 필터링할 피어 IP CIDR을 정의합니다. 예: 10.10.10.0/24 또는 100:100:100:100::/64

peerIP

string

peerIP 는 선택적으로 흐름을 필터링할 원격 IP 주소를 정의합니다. 예: 10.10.10.10 .

pktDrops

boolean

pktDrops 는 선택적으로 패킷 드롭을 포함하는 흐름만 필터링합니다.

ports

integer-or-string

포트 선택적으로 흐름을 필터링할 포트를 정의합니다. 소스 및 대상 포트 모두에 사용됩니다. 단일 포트를 필터링하려면 단일 포트를 정수 값으로 설정합니다. 예를 들어 포트: 80 입니다. 포트 범위를 필터링하려면 문자열 형식으로 "start-end" 범위를 사용합니다. 예를 들어 포트: "80-100" 입니다. 두 포트를 필터링하려면 문자열 형식으로 "port1,port2"를 사용합니다. 예를 들어 포트: "80,100" 입니다.

protocol

string

프로토콜 은 선택적으로 흐름을 필터링할 프로토콜을 정의합니다. 사용 가능한 옵션은 TCP,UDP,ICMP,ICMPv6SCTP 입니다.

sampling

integer

샘플링 은 일치하는 패킷의 샘플링 간격이며 spec.agent.ebpf.sampling 에 정의된 글로벌 샘플링을 재정의합니다.

sourcePorts

integer-or-string

sourcePorts 는 선택적으로 흐름을 필터링할 소스 포트를 정의합니다. 단일 포트를 필터링하려면 단일 포트를 정수 값으로 설정합니다. 예를 들어 sourcePorts: 80 입니다. 포트 범위를 필터링하려면 문자열 형식으로 "start-end" 범위를 사용합니다. 예를 들어 sourcePorts: "80-100" 입니다. 두 포트를 필터링하려면 문자열 형식으로 "port1,port2"를 사용합니다. 예를 들어 포트: "80,100" 입니다.

tcpFlags

string

tcpFlags 는 선택적으로 흐름을 필터링하는 TCP 플래그를 정의합니다. 표준 플래그(RFC-9293) 외에도 SYN-ACK,FIN-ACK, RST-ACK 의 세 가지 조합 중 하나로 필터링할 수도 있습니다.

17.1.12. .spec.agent.ebpf.metrics

설명
메트릭은 메트릭 과 관련된 eBPF 에이전트 구성을 정의합니다.
유형
object
Expand
속성유형설명

disableAlerts

배열(문자열)

disableAlerts 는 비활성화해야 하는 경고 목록입니다. 가능한 값은 다음과 같습니다:

NetObservDroppedFlows 에서는 eBPF 에이전트가 패킷 또는 흐름을 누락할 때(예: BPF 해시 맵이 사용 중이거나 전체 용량 제한)가 트리거될 때 트리거됩니다.

enable

boolean

eBPF 에이전트 메트릭 컬렉션을 비활성화하려면 enablefalse 로 설정합니다. 기본적으로 활성화되어 있습니다.

server

object

Prometheus 스크랩에 대한 지표 서버 끝점 구성입니다.

17.1.13. .spec.agent.ebpf.metrics.server

설명
Prometheus 스크랩에 대한 지표 서버 끝점 구성입니다.
유형
object
Expand
속성유형설명

port

integer

지표 서버 HTTP 포트입니다.

tls

object

TLS 구성입니다.

17.1.14. .spec.agent.ebpf.metrics.server.tls

설명
TLS 구성입니다.
유형
object
필수 항목
  • type
Expand
속성유형설명

insecureSkipVerify

boolean

insecureSkipVerify 를 사용하면 제공된 인증서의 클라이언트 측 확인을 건너뛸 수 있습니다. true 로 설정하면 providedCaFile 필드가 무시됩니다.

제공됨

object

typeProvided 로 설정된 경우 TLS 구성입니다.

providedCaFile

object

typeProvided 로 설정된 경우 CA 파일에 대한 참조입니다.

type

string

TLS 구성 유형을 선택합니다.

- 끝점에 대해 TLS를 구성하지 않도록 비활성화됨 (기본값)입니다. - 인증서 파일과 키 파일을 수동으로 제공하도록 제공됩니다. [Unsupported(*)]. - 주석을 사용하여 OpenShift Container Platform 자동 생성 인증서를 사용하도록 자동 설정됩니다.

17.1.15. .spec.agent.ebpf.metrics.server.tls.provided

설명
typeProvided 로 설정된 경우 TLS 구성입니다.
유형
object
Expand
속성유형설명

certFile

string

cert file은 구성 맵 또는 시크릿 내의 인증서 파일 이름의 경로를 정의합니다.

certKey

string

certKey 는 구성 맵 또는 시크릿 내의 인증서 개인 키 파일 이름의 경로를 정의합니다. 키가 필요하지 않은 경우 생략합니다.

name

string

인증서가 포함된 구성 맵 또는 시크릿의 이름입니다.

네임스페이스

string

인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.

type

string

인증서 참조: configmap 또는 secret 을 입력합니다.

17.1.16. .spec.agent.ebpf.metrics.server.tls.providedCaFile

설명
typeProvided 로 설정된 경우 CA 파일에 대한 참조입니다.
유형
object
Expand
속성유형설명

file

string

구성 맵 또는 시크릿 내의 파일 이름입니다.

name

string

파일이 포함된 구성 맵 또는 시크릿의 이름입니다.

네임스페이스

string

파일이 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.

type

string

파일 참조: configmap 또는 secret 에 대해 를 입력합니다.

17.1.17. .spec.agent.ebpf.resources

설명
리소스는 이 컨테이너에 필요한 컴퓨팅 리소스입니다. 자세한 내용은 https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/에서 참조하십시오.
유형
object
Expand
속성유형설명

limits

integer-or-string

제한은 허용되는 최대 컴퓨팅 리소스 양을 나타냅니다. 자세한 내용은 https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

requests

integer-or-string

요청은 필요한 최소 컴퓨팅 리소스 양을 설명합니다. 컨테이너에 대한 Requests를 생략하면 구현 정의된 값을 제외하고 명시적으로 지정된 경우 기본값은 Limits로 설정됩니다. 요청은 제한을 초과할 수 없습니다. 자세한 내용은 https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

17.1.18. .spec.consolePlugin

설명
Console Plugin 은 사용 가능한 경우 OpenShift Container Platform 콘솔 플러그인과 관련된 설정을 정의합니다.
유형
object
Expand
속성유형설명

advanced

object

Advanced 를 사용하면 콘솔 플러그인의 내부 구성의 일부 측면을 설정할 수 있습니다. 이 섹션은 GOGCGOMAXPROCS 환경 변수와 같은 디버깅 및 세분화된 성능 최적화를 목표로 합니다. 이러한 값을 at your own risk로 설정합니다.

autoscaler

object

플러그인 배포에 설정할 수평 Pod 자동 스케일러 의 자동 스케일러 [더 이상 사용되지 않음 (*)] 사양입니다. 사용 중단 알림: 관리형 자동 스케일러는 향후 버전에서 제거됩니다. 선택한 자동 스케일러를 대신 구성하고 spec.consolePlugin.unmanagedReplicastrue 로 설정할 수 있습니다. HorizontalPodAutoscaler 문서(autoscaling/v2)를 참조하십시오.

enable

boolean

콘솔 플러그인 배포를 활성화합니다.

imagePullPolicy

string

imagePullPolicy 는 위에 정의된 이미지의 Kubernetes 가져오기 정책입니다.

logLevel

string

콘솔 플러그인 백엔드의 로그 수준입니다.

portNaming

object

portNaming 은 port-to-service 이름 변환의 구성을 정의합니다.

quickFilters

array

quickFilters 는 Console 플러그인에 대한 빠른 필터 사전 설정을 구성합니다. 외부 트래픽의 필터는 서브넷 레이블이 내부 및 외부 트래픽을 구분하도록 구성되어 있다고 가정합니다( spec.processor.subnetLabels참조).

replicas

integer

replicas 는 시작할 복제본(Pod) 수를 정의합니다.

resources

object

이 컨테이너에 필요한 컴퓨팅 리소스 측면에서 리소스입니다. 자세한 내용은 https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ 을 참조하십시오.

standalone

boolean

OpenShift Container Platform 콘솔 대신 독립 실행형 콘솔로 배포합니다. 통합 환경을 제공하지 않으므로 OpenShift Container Platform과 함께 사용하는 것은 권장되지 않습니다. [지원되지 않음(*)].

unmanagedReplicas

boolean

UnmanagedReplicastrue 인 경우 Operator는 복제본 을 조정하지 않습니다. 이는 Pod 자동 스케일러를 사용할 때 유용합니다.

17.1.19. .spec.consolePlugin.advanced

설명
Advanced 를 사용하면 콘솔 플러그인의 내부 구성의 일부 측면을 설정할 수 있습니다. 이 섹션은 GOGCGOMAXPROCS 환경 변수와 같은 디버깅 및 세분화된 성능 최적화를 목표로 합니다. 이러한 값을 at your own risk로 설정합니다.
유형
object
Expand
속성유형설명

args

배열(문자열)

args 를 사용하면 사용자 지정 인수를 기본 구성 요소에 전달할 수 있습니다. 에지 디버그 또는 지원 시나리오에서만 유용하므로 FlowCollector 설명자의 일부로 공개적으로 노출해서는 안 되는 일부 매개 변수(예: URL 또는 구성 경로)를 재정의하는 데 유용합니다.

env

오브젝트(문자열)

env 를 사용하면 사용자 지정 환경 변수를 기본 구성 요소에 전달할 수 있습니다. GOGCGOMAXPROCS 와 같은 매우 구체적인 성능 튜닝 옵션을 전달하는 데 유용합니다. 이는 에지 디버그 또는 지원 시나리오에서만 유용하므로 FlowCollector 설명자의 일부로 공개적으로 노출해서는 안 됩니다.

port

integer

port 는 플러그인 서비스 포트입니다. 메트릭을 위해 예약된 9002를 사용하지 마십시오.

등록

boolean

등록true 로 설정하면 제공된 콘솔 플러그인을 OpenShift Container Platform 콘솔 Operator에 자동으로 등록할 수 있습니다. false 로 설정하면 oc patch console.operator.openshift.io/cluster를 편집하여 수동으로 등록할 수 있습니다. oc patch console.operator.openshift.io cluster --type='json' -p '[{"op": "add", "path": "/spec/plugins/-", "value": "netobserv-plugin"}]]

scheduling

object

scheduling은 노드에서 pod가 어떻게 스케줄링되는지 제어합니다.

17.1.20. .spec.consolePlugin.advanced.scheduling

설명
scheduling은 노드에서 pod가 어떻게 스케줄링되는지 제어합니다.
유형
object
Expand
속성유형설명

유사성

object

지정된 경우 Pod의 스케줄링 제약 조건입니다. 문서는 https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling 를 참조하십시오.

nodeSelector

오브젝트(문자열)

nodeSelector 를 사용하면 각 라벨이 지정된 노드에만 Pod를 예약할 수 있습니다. 문서는 https://kubernetes.io/docs/concepts/configuration/assign-pod-node/ 를 참조하십시오.

priorityClassName

string

지정된 경우 Pod의 우선 순위를 나타냅니다. 문서는 https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/#how-to-use-priority-and-preemption 를 참조하십시오. 지정하지 않으면 기본 우선순위가 사용되거나 기본값이 없는 경우 0이 사용됩니다.

허용 오차

array

허용 오차 는 일치하는 테인트가 있는 노드에 Pod를 예약할 수 있는 허용 오차 목록입니다. 문서는 https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling 를 참조하십시오.

17.1.21. .spec.consolePlugin.advanced.scheduling.affinity

설명
지정된 경우 Pod의 스케줄링 제약 조건입니다. 문서는 https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling 를 참조하십시오.
유형
object

17.1.22. .spec.consolePlugin.advanced.scheduling.tolerations

설명
허용 오차 는 일치하는 테인트가 있는 노드에 Pod를 예약할 수 있는 허용 오차 목록입니다. 문서는 https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling 를 참조하십시오.
유형
array

17.1.23. .spec.consolePlugin.autoscaler

설명
플러그인 배포에 설정할 수평 Pod 자동 스케일러 의 자동 스케일러 [더 이상 사용되지 않음 (*)] 사양입니다. 사용 중단 알림: 관리형 자동 스케일러는 향후 버전에서 제거됩니다. 선택한 자동 스케일러를 대신 구성하고 spec.consolePlugin.unmanagedReplicastrue 로 설정할 수 있습니다. HorizontalPodAutoscaler 문서(autoscaling/v2)를 참조하십시오.
유형
object

17.1.24. .spec.consolePlugin.portNaming

설명
portNaming 은 port-to-service 이름 변환의 구성을 정의합니다.
유형
object
Expand
속성유형설명

enable

boolean

콘솔 플러그인 포트-서비스 이름 변환을 활성화

portNames

오브젝트(문자열)

portNames 는 콘솔에서 사용할 추가 포트 이름을 정의합니다(예 : {"3100": "loki"} ).

17.1.25. .spec.consolePlugin.quickFilters

설명
quickFilters 는 Console 플러그인에 대한 빠른 필터 사전 설정을 구성합니다. 외부 트래픽의 필터는 서브넷 레이블이 내부 및 외부 트래픽을 구분하도록 구성되어 있다고 가정합니다( spec.processor.subnetLabels참조).
유형
array

17.1.26. .spec.consolePlugin.quickFilters[]

설명
QuickFilter 는 콘솔의 빠른 필터에 대한 사전 설정 구성을 정의합니다.
유형
object
필수 항목
  • filter
  • name
Expand
속성유형설명

default

boolean

default 는 이 필터가 기본적으로 활성화되어야 하는지 여부를 정의합니다.

filter

오브젝트(문자열)

filter 는 이 필터를 선택할 때 설정할 키 및 값 집합입니다. 각 키는 쉼표로 구분된 문자열을 사용하여 값 목록과 연결할 수 있습니다(예: filter: {"src_namespace": "namespace1,namespace2"} ).

name

string

콘솔에 표시되는 필터의 이름

17.1.27. .spec.consolePlugin.resources

설명
이 컨테이너에 필요한 컴퓨팅 리소스 측면에서 리소스입니다. 자세한 내용은 https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ 을 참조하십시오.
유형
object
Expand
속성유형설명

limits

integer-or-string

제한은 허용되는 최대 컴퓨팅 리소스 양을 나타냅니다. 자세한 내용은 https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

requests

integer-or-string

요청은 필요한 최소 컴퓨팅 리소스 양을 설명합니다. 컨테이너에 대한 Requests를 생략하면 구현 정의된 값을 제외하고 명시적으로 지정된 경우 기본값은 Limits로 설정됩니다. 요청은 제한을 초과할 수 없습니다. 자세한 내용은 https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

17.1.28. .spec.exporters

설명
exporters 는 사용자 정의 사용 또는 스토리지에 대한 추가 선택적 내보내기를 정의합니다.
유형
array

17.1.29. .spec.exporters[]

설명
FlowCollectorExporter 는 보강된 흐름을 보낼 추가 내보내기를 정의합니다.
유형
object
필수 항목
  • type
Expand
속성유형설명

ipfix

object

강화된 IPFIX 흐름을 보내기 위한 IP 주소 및 포트와 같은 IPFIX 구성입니다.

kafka

object

풍요한 흐름을 보내기 위한 주소 및 주제와 같은 Kafka 구성입니다.

openTelemetry

object

강화된 로그 또는 메트릭을 전송하는 IP 주소 및 포트와 같은 OpenTelemetry 구성입니다.

type

string

type 은 내보내기 유형을 선택합니다. 사용 가능한 옵션은 Kafka,IPFIXOpenTelemetry 입니다.

17.1.30. .spec.exporters[].ipfix

설명
강화된 IPFIX 흐름을 보내기 위한 IP 주소 및 포트와 같은 IPFIX 구성입니다.
유형
object
필수 항목
  • enterpriseID
  • targetHost
  • targetPort
Expand
속성유형설명

enterpriseID

integer

EnterpriseID 또는 개인 엔터프라이즈 번호(PEN). 지금까지 Network Observability는 할당된 번호를 소유하지 않으므로 구성에 대해 열린 상태로 유지됩니다. PEN은 Kubernetes 이름, RTT 등과 같은 표준 데이터를 수집하는 데 필요합니다.

targetHost

string

IPFIX 외부 수신자의 주소입니다.

targetPort

integer

IPFIX 외부 수신자용 포트입니다.

transport

string

IPFIX 연결에 사용되는 전송 프로토콜(TCP 또는 UDP)은 기본적으로 TCP 입니다.

17.1.31. .spec.exporters[].kafka

설명
풍요한 흐름을 보내기 위한 주소 및 주제와 같은 Kafka 구성입니다.
유형
object
필수 항목
  • address
  • topic
Expand
속성유형설명

address

string

Kafka 서버의 주소

sasl

object

SASL 인증 구성. [지원되지 않음(*)].

tls

object

TLS 클라이언트 구성. TLS를 사용하는 경우 주소가 TLS에 사용되는 Kafka 포트(일반적으로 9093)와 일치하는지 확인합니다.

topic

string

사용할 Kafka 주제입니다. 존재할 수 있어야 합니다. Network Observability는 이를 생성하지 않습니다.

17.1.32. .spec.exporters[].kafka.sasl

설명
SASL 인증 구성. [지원되지 않음(*)].
유형
object
Expand
속성유형설명

clientIDReference

object

클라이언트 ID가 포함된 시크릿 또는 구성 맵에 대한 참조

clientSecretReference

object

클라이언트 보안이 포함된 시크릿 또는 구성 맵에 대한 참조

type

string

사용할 SASL 인증 유형 또는 SASL을 사용하지 않는 경우 Disabled

17.1.33. .spec.exporters[].kafka.sasl.clientIDReference

설명
클라이언트 ID가 포함된 시크릿 또는 구성 맵에 대한 참조
유형
object
Expand
속성유형설명

file

string

구성 맵 또는 시크릿 내의 파일 이름입니다.

name

string

파일이 포함된 구성 맵 또는 시크릿의 이름입니다.

네임스페이스

string

파일이 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.

type

string

파일 참조: configmap 또는 secret 에 대해 를 입력합니다.

17.1.34. .spec.exporters[].kafka.sasl.clientSecretReference

설명
클라이언트 보안이 포함된 시크릿 또는 구성 맵에 대한 참조
유형
object
Expand
속성유형설명

file

string

구성 맵 또는 시크릿 내의 파일 이름입니다.

name

string

파일이 포함된 구성 맵 또는 시크릿의 이름입니다.

네임스페이스

string

파일이 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.

type

string

파일 참조: configmap 또는 secret 에 대해 를 입력합니다.

17.1.35. .spec.exporters[].kafka.tls

설명
TLS 클라이언트 구성. TLS를 사용하는 경우 주소가 TLS에 사용되는 Kafka 포트(일반적으로 9093)와 일치하는지 확인합니다.
유형
object
Expand
속성유형설명

caCert

object

cacert는 인증 기관의 인증서 참조를 정의합니다.

enable

boolean

TLS 활성화

insecureSkipVerify

boolean

insecureSkipVerify 를 사용하면 서버 인증서의 클라이언트 측 확인을 건너뛸 수 있습니다. true 로 설정하면 caCert 필드가 무시됩니다.

userCert

object

UserCert 는 사용자 인증서 참조를 정의하고 mTLS에 사용됩니다. 단방향 TLS를 사용하는 경우 이 속성을 무시할 수 있습니다.

17.1.36. .spec.exporters[].kafka.tls.caCert

설명
cacert는 인증 기관의 인증서 참조를 정의합니다.
유형
object
Expand
속성유형설명

certFile

string

cert file은 구성 맵 또는 시크릿 내의 인증서 파일 이름의 경로를 정의합니다.

certKey

string

certKey 는 구성 맵 또는 시크릿 내의 인증서 개인 키 파일 이름의 경로를 정의합니다. 키가 필요하지 않은 경우 생략합니다.

name

string

인증서가 포함된 구성 맵 또는 시크릿의 이름입니다.

네임스페이스

string

인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.

type

string

인증서 참조: configmap 또는 secret 을 입력합니다.

17.1.37. .spec.exporters[].kafka.tls.userCert

설명
UserCert 는 사용자 인증서 참조를 정의하고 mTLS에 사용됩니다. 단방향 TLS를 사용하는 경우 이 속성을 무시할 수 있습니다.
유형
object
Expand
속성유형설명

certFile

string

cert file은 구성 맵 또는 시크릿 내의 인증서 파일 이름의 경로를 정의합니다.

certKey

string

certKey 는 구성 맵 또는 시크릿 내의 인증서 개인 키 파일 이름의 경로를 정의합니다. 키가 필요하지 않은 경우 생략합니다.

name

string

인증서가 포함된 구성 맵 또는 시크릿의 이름입니다.

네임스페이스

string

인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.

type

string

인증서 참조: configmap 또는 secret 을 입력합니다.

17.1.38. .spec.exporters[].openTelemetry

설명
강화된 로그 또는 메트릭을 전송하는 IP 주소 및 포트와 같은 OpenTelemetry 구성입니다.
유형
object
필수 항목
  • targetHost
  • targetPort
Expand
속성유형설명

fieldsMapping

array

OpenTelemetry 적합성 형식에 매핑되는 사용자 지정 필드입니다. 기본적으로 네트워크 Observability 형식 제안이 사용됩니다. https://github.com/rhobs/observability-data-model/blob/main/network-observability.md#format-proposal . 현재 L3 또는 L4에 대해 허용되는 표준이 없으므로 네트워크 로그를 자유롭게 재정의할 수 있습니다.

headers

오브젝트(문자열)

메시지에 추가할 헤더(선택 사항)

logs

object

로그에 대한 OpenTelemetry 구성.

metrics

object

메트릭에 대한 OpenTelemetry 구성.

protocol

string

OpenTelemetry 연결의 프로토콜입니다. 사용 가능한 옵션은 httpgrpc 입니다.

targetHost

string

OpenTelemetry 수신기의 주소입니다.

targetPort

integer

OpenTelemetry 수신기용 포트입니다.

tls

object

TLS 클라이언트 구성.

17.1.39. .spec.exporters[].openTelemetry.fieldsMapping

설명
OpenTelemetry 적합성 형식에 매핑되는 사용자 지정 필드입니다. 기본적으로 네트워크 Observability 형식 제안이 사용됩니다. https://github.com/rhobs/observability-data-model/blob/main/network-observability.md#format-proposal . 현재 L3 또는 L4에 대해 허용되는 표준이 없으므로 네트워크 로그를 자유롭게 재정의할 수 있습니다.
유형
array

17.1.40. .spec.exporters[].openTelemetry.fieldsMapping[]

설명
유형
object
Expand
속성유형설명

input

string

 

multiplier

integer

 

output

string

 

17.1.41. .spec.exporters[].openTelemetry.logs

설명
로그에 대한 OpenTelemetry 구성.
유형
object
Expand
속성유형설명

enable

boolean

OpenTelemetry 수신자에 로그를 보내려면 enabletrue 로 설정합니다.

17.1.42. .spec.exporters[].openTelemetry.metrics

설명
메트릭에 대한 OpenTelemetry 구성.
유형
object
Expand
속성유형설명

enable

boolean

OpenTelemetry 수신자에 지표를 보내려면 enabletrue 로 설정합니다.

pushTimeInterval

string

수집기로 전송되는 메트릭의 빈도를 지정합니다.

17.1.43. .spec.exporters[].openTelemetry.tls

설명
TLS 클라이언트 구성.
유형
object
Expand
속성유형설명

caCert

object

cacert는 인증 기관의 인증서 참조를 정의합니다.

enable

boolean

TLS 활성화

insecureSkipVerify

boolean

insecureSkipVerify 를 사용하면 서버 인증서의 클라이언트 측 확인을 건너뛸 수 있습니다. true 로 설정하면 caCert 필드가 무시됩니다.

userCert

object

UserCert 는 사용자 인증서 참조를 정의하고 mTLS에 사용됩니다. 단방향 TLS를 사용하는 경우 이 속성을 무시할 수 있습니다.

17.1.44. .spec.exporters[].openTelemetry.tls.caCert

설명
cacert는 인증 기관의 인증서 참조를 정의합니다.
유형
object
Expand
속성유형설명

certFile

string

cert file은 구성 맵 또는 시크릿 내의 인증서 파일 이름의 경로를 정의합니다.

certKey

string

certKey 는 구성 맵 또는 시크릿 내의 인증서 개인 키 파일 이름의 경로를 정의합니다. 키가 필요하지 않은 경우 생략합니다.

name

string

인증서가 포함된 구성 맵 또는 시크릿의 이름입니다.

네임스페이스

string

인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.

type

string

인증서 참조: configmap 또는 secret 을 입력합니다.

17.1.45. .spec.exporters[].openTelemetry.tls.userCert

설명
UserCert 는 사용자 인증서 참조를 정의하고 mTLS에 사용됩니다. 단방향 TLS를 사용하는 경우 이 속성을 무시할 수 있습니다.
유형
object
Expand
속성유형설명

certFile

string

cert file은 구성 맵 또는 시크릿 내의 인증서 파일 이름의 경로를 정의합니다.

certKey

string

certKey 는 구성 맵 또는 시크릿 내의 인증서 개인 키 파일 이름의 경로를 정의합니다. 키가 필요하지 않은 경우 생략합니다.

name

string

인증서가 포함된 구성 맵 또는 시크릿의 이름입니다.

네임스페이스

string

인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.

type

string

인증서 참조: configmap 또는 secret 을 입력합니다.

17.1.46. .spec.kafka

설명
Kafka 구성을 통해 Kafka를 흐름 컬렉션 파이프라인의 일부로 브로커로 사용할 수 있습니다. spec.deploymentModelKafka 인 경우 사용할 수 있습니다.
유형
object
필수 항목
  • address
  • topic
Expand
속성유형설명

address

string

Kafka 서버의 주소

sasl

object

SASL 인증 구성. [지원되지 않음(*)].

tls

object

TLS 클라이언트 구성. TLS를 사용하는 경우 주소가 TLS에 사용되는 Kafka 포트(일반적으로 9093)와 일치하는지 확인합니다.

topic

string

사용할 Kafka 주제입니다. 존재할 수 있어야 합니다. Network Observability는 이를 생성하지 않습니다.

17.1.47. .spec.kafka.sasl

설명
SASL 인증 구성. [지원되지 않음(*)].
유형
object
Expand
속성유형설명

clientIDReference

object

클라이언트 ID가 포함된 시크릿 또는 구성 맵에 대한 참조

clientSecretReference

object

클라이언트 보안이 포함된 시크릿 또는 구성 맵에 대한 참조

type

string

사용할 SASL 인증 유형 또는 SASL을 사용하지 않는 경우 Disabled

17.1.48. .spec.kafka.sasl.clientIDReference

설명
클라이언트 ID가 포함된 시크릿 또는 구성 맵에 대한 참조
유형
object
Expand
속성유형설명

file

string

구성 맵 또는 시크릿 내의 파일 이름입니다.

name

string

파일이 포함된 구성 맵 또는 시크릿의 이름입니다.

네임스페이스

string

파일이 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.

type

string

파일 참조: configmap 또는 secret 에 대해 를 입력합니다.

17.1.49. .spec.kafka.sasl.clientSecretReference

설명
클라이언트 보안이 포함된 시크릿 또는 구성 맵에 대한 참조
유형
object
Expand
속성유형설명

file

string

구성 맵 또는 시크릿 내의 파일 이름입니다.

name

string

파일이 포함된 구성 맵 또는 시크릿의 이름입니다.

네임스페이스

string

파일이 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.

type

string

파일 참조: configmap 또는 secret 에 대해 를 입력합니다.

17.1.50. .spec.kafka.tls

설명
TLS 클라이언트 구성. TLS를 사용하는 경우 주소가 TLS에 사용되는 Kafka 포트(일반적으로 9093)와 일치하는지 확인합니다.
유형
object
Expand
속성유형설명

caCert

object

cacert는 인증 기관의 인증서 참조를 정의합니다.

enable

boolean

TLS 활성화

insecureSkipVerify

boolean

insecureSkipVerify 를 사용하면 서버 인증서의 클라이언트 측 확인을 건너뛸 수 있습니다. true 로 설정하면 caCert 필드가 무시됩니다.

userCert

object

UserCert 는 사용자 인증서 참조를 정의하고 mTLS에 사용됩니다. 단방향 TLS를 사용하는 경우 이 속성을 무시할 수 있습니다.

17.1.51. .spec.kafka.tls.caCert

설명
cacert는 인증 기관의 인증서 참조를 정의합니다.
유형
object
Expand
속성유형설명

certFile

string

cert file은 구성 맵 또는 시크릿 내의 인증서 파일 이름의 경로를 정의합니다.

certKey

string

certKey 는 구성 맵 또는 시크릿 내의 인증서 개인 키 파일 이름의 경로를 정의합니다. 키가 필요하지 않은 경우 생략합니다.

name

string

인증서가 포함된 구성 맵 또는 시크릿의 이름입니다.

네임스페이스

string

인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.

type

string

인증서 참조: configmap 또는 secret 을 입력합니다.

17.1.52. .spec.kafka.tls.userCert

설명
UserCert 는 사용자 인증서 참조를 정의하고 mTLS에 사용됩니다. 단방향 TLS를 사용하는 경우 이 속성을 무시할 수 있습니다.
유형
object
Expand
속성유형설명

certFile

string

cert file은 구성 맵 또는 시크릿 내의 인증서 파일 이름의 경로를 정의합니다.

certKey

string

certKey 는 구성 맵 또는 시크릿 내의 인증서 개인 키 파일 이름의 경로를 정의합니다. 키가 필요하지 않은 경우 생략합니다.

name

string

인증서가 포함된 구성 맵 또는 시크릿의 이름입니다.

네임스페이스

string

인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.

type

string

인증서 참조: configmap 또는 secret 을 입력합니다.

17.1.53. .spec.loki

설명
Loki, 흐름 저장소, 클라이언트 설정.
유형
object
필수 항목
  • mode
Expand
속성유형설명

advanced

object

Advanced 를 사용하면 Loki 클라이언트의 내부 구성의 일부 측면을 설정할 수 있습니다. 이 섹션은 디버깅 및 세분화된 성능 최적화를 목표로 합니다.

enable

boolean

Loki에 흐름을 저장하려면 enabletrue 로 설정합니다. 콘솔 플러그인은 Loki 또는 Prometheus를 메트릭의 데이터 소스로 사용하거나 ( spec.prometheus.querier) 또는 둘 다 사용할 수 있습니다. 모든 쿼리를 Loki에서 Prometheus로 전송할 수 있는 것은 아닙니다. 따라서 Loki가 비활성화된 경우 Pod별 정보 가져오기 또는 원시 흐름 보기와 같은 플러그인의 일부 기능도 비활성화됩니다. Prometheus와 Loki가 모두 활성화된 경우 Prometheus가 우선 순위를 수행하며 Loki는 Prometheus가 처리할 수 없는 쿼리의 폴백으로 사용됩니다. 둘 다 비활성화되어 있으면 콘솔 플러그인이 배포되지 않습니다.

lokiStack

object

LokiStack 모드에 대한 Loki 구성입니다. 이 기능은 쉽게 Loki Operator 구성에 유용합니다. 다른 모드에서는 무시됩니다.

manual

object

수동 모드의 Loki 구성. 이는 가장 유연한 구성입니다. 다른 모드에서는 무시됩니다.

마이크로 서비스

object

마이크로 서비스 모드에 대한 Loki 구성입니다. 마이크로 서비스 배포 모드(https://grafana.com/docs/loki/latest/fundamentals/architecture/deployment-modes/#microservices-mode)를 사용하여 Loki를 설치할 때 이 옵션을 사용합니다. 다른 모드에서는 무시됩니다.

mode

string

mode 는 Loki의 설치 모드에 따라 설정해야 합니다.

- Loki Operator를 사용하여 Loki를 관리할 때 LokiStack 사용

- Loki가 모놀리식 워크로드로 설치될 때 Cryostatlithic 사용

- Loki가 마이크로 서비스로 설치되지만 Loki Operator가 없는 경우 마이크로 서비스 사용

- 위의 옵션이 설정과 일치하지 않는 경우 수동 사용

모놀리식

object

Cryostat 모드에 대한 Loki 구성입니다. Loki가 모놀리식 배포 모드(https://grafana.com/docs/loki/latest/fundamentals/architecture/deployment-modes/#monolithic-mode)를 사용하여 설치할 때 이 옵션을 사용합니다. 다른 모드에서는 무시됩니다.

readTimeout

string

readTimeout 은 최대 콘솔 플러그인 loki 쿼리의 총 시간 제한입니다. 시간 초과가 0이면 시간 초과가 없음을 의미합니다.

writeBatchSize

integer

writeBatchSize 는 전송 전에 누적되는 Loki 로그의 최대 배치 크기(바이트)입니다.

writeBatchWait

string

writeBatchWait 은 Loki 일괄 처리를 보내기 전에 대기하는 최대 시간입니다.

writeTimeout

string

writeTimeout 은 최대 Loki 시간 연결/요청 제한입니다. 시간 초과가 0이면 시간 초과가 없음을 의미합니다.

17.1.54. .spec.loki.advanced

설명
Advanced 를 사용하면 Loki 클라이언트의 내부 구성의 일부 측면을 설정할 수 있습니다. 이 섹션은 디버깅 및 세분화된 성능 최적화를 목표로 합니다.
유형
object
Expand
속성유형설명

excludeLabels

배열(문자열)

excludeLabels 는 Loki 라벨 목록에서 제외할 필드 목록입니다. [Unsupported (*)].

staticLabels

오브젝트(문자열)

staticLabels 는 Loki 스토리지의 각 흐름에 설정할 수 있는 공통 레이블의 맵입니다.

writeMaxBackoff

string

writeMaxBackoff 는 재시도 사이의 Loki 클라이언트 연결의 최대 백오프 시간입니다.

writeMaxRetries

integer

writeMaxRetries 는 Loki 클라이언트 연결에 대한 최대 재시도 횟수입니다.

writeMinBackoff

string

writeMinBackoff 는 재시도 사이의 Loki 클라이언트 연결의 초기 백오프 시간입니다.

17.1.55. .spec.loki.lokiStack

설명
LokiStack 모드에 대한 Loki 구성입니다. 이 기능은 쉽게 Loki Operator 구성에 유용합니다. 다른 모드에서는 무시됩니다.
유형
object
필수 항목
  • name
Expand
속성유형설명

name

string

사용할 기존 LokiStack 리소스의 이름입니다.

네임스페이스

string

LokiStack 리소스가 있는 네임스페이스입니다. 생략하면 spec.namespace 와 동일한 것으로 간주됩니다.

17.1.56. .spec.loki.manual

설명
수동 모드의 Loki 구성. 이는 가장 유연한 구성입니다. 다른 모드에서는 무시됩니다.
유형
object
Expand
속성유형설명

authToken

string

auth token은 Loki에 인증할 토큰을 가져오는 방법을 설명합니다.

- disabled 는 요청과 함께 토큰을 보내지 않습니다.

- 권한을 위해 사용자 토큰을 전달합니다.

- host [deprecated (*)] - 로컬 Pod 서비스 계정을 사용하여 Loki에 인증합니다.

Loki Operator를 사용하는 경우 이 Operator를 Forward 로 설정해야 합니다.

ingesterUrl

string

ingesterUrl 은 흐름을 내보내는 기존 Loki ingester 서비스의 주소입니다. Loki Operator를 사용할 때 경로에 설정된 네트워크 테넌트를 사용하여 Loki 게이트웨이 서비스로 설정합니다(예: https://loki-gateway-http.netobserv.svc:8080/api/logs/v1/network ).

querierUrl

string

querierUrl 은 Loki querier 서비스의 주소를 지정합니다. Loki Operator를 사용할 때 경로에 설정된 네트워크 테넌트를 사용하여 Loki 게이트웨이 서비스로 설정합니다(예: https://loki-gateway-http.netobserv.svc:8080/api/logs/v1/network ).

statusTls

object

Loki 상태 URL에 대한 TLS 클라이언트 구성

statusUrl

string

statusUrl 은 Loki /ready,/metrics/config 끝점의 주소를 지정합니다. 경우 Loki querier URL과 다릅니다. 비어 있는 경우 querierUrl 값이 사용됩니다. 이 기능은 프런트 엔드에서 오류 메시지와 일부 컨텍스트를 표시하는 데 유용합니다. Loki Operator를 사용하는 경우 Loki HTTP 쿼리 프런트 엔드 서비스로 설정합니다(예: https://loki-query-frontend-http.netobserv.svc:3100/ ). statusUrl 이 설정된 경우 statusTLS 구성이 사용됩니다.

tenantID

string

tenantId 는 각 요청에 대해 테넌트를 식별하는 Loki X-Scope-OrgID 입니다. Loki Operator를 사용하는 경우 특수 테넌트 모드에 해당하는 네트워크 로 설정합니다.

tls

object

Loki URL에 대한 TLS 클라이언트 구성

17.1.57. .spec.loki.manual.statusTls

설명
Loki 상태 URL에 대한 TLS 클라이언트 구성
유형
object
Expand
속성유형설명

caCert

object

cacert는 인증 기관의 인증서 참조를 정의합니다.

enable

boolean

TLS 활성화

insecureSkipVerify

boolean

insecureSkipVerify 를 사용하면 서버 인증서의 클라이언트 측 확인을 건너뛸 수 있습니다. true 로 설정하면 caCert 필드가 무시됩니다.

userCert

object

UserCert 는 사용자 인증서 참조를 정의하고 mTLS에 사용됩니다. 단방향 TLS를 사용하는 경우 이 속성을 무시할 수 있습니다.

17.1.58. .spec.loki.manual.statusTls.caCert

설명
cacert는 인증 기관의 인증서 참조를 정의합니다.
유형
object
Expand
속성유형설명

certFile

string

cert file은 구성 맵 또는 시크릿 내의 인증서 파일 이름의 경로를 정의합니다.

certKey

string

certKey 는 구성 맵 또는 시크릿 내의 인증서 개인 키 파일 이름의 경로를 정의합니다. 키가 필요하지 않은 경우 생략합니다.

name

string

인증서가 포함된 구성 맵 또는 시크릿의 이름입니다.

네임스페이스

string

인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.

type

string

인증서 참조: configmap 또는 secret 을 입력합니다.

17.1.59. .spec.loki.manual.statusTls.userCert

설명
UserCert 는 사용자 인증서 참조를 정의하고 mTLS에 사용됩니다. 단방향 TLS를 사용하는 경우 이 속성을 무시할 수 있습니다.
유형
object
Expand
속성유형설명

certFile

string

cert file은 구성 맵 또는 시크릿 내의 인증서 파일 이름의 경로를 정의합니다.

certKey

string

certKey 는 구성 맵 또는 시크릿 내의 인증서 개인 키 파일 이름의 경로를 정의합니다. 키가 필요하지 않은 경우 생략합니다.

name

string

인증서가 포함된 구성 맵 또는 시크릿의 이름입니다.

네임스페이스

string

인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.

type

string

인증서 참조: configmap 또는 secret 을 입력합니다.

17.1.60. .spec.loki.manual.tls

설명
Loki URL에 대한 TLS 클라이언트 구성
유형
object
Expand
속성유형설명

caCert

object

cacert는 인증 기관의 인증서 참조를 정의합니다.

enable

boolean

TLS 활성화

insecureSkipVerify

boolean

insecureSkipVerify 를 사용하면 서버 인증서의 클라이언트 측 확인을 건너뛸 수 있습니다. true 로 설정하면 caCert 필드가 무시됩니다.

userCert

object

UserCert 는 사용자 인증서 참조를 정의하고 mTLS에 사용됩니다. 단방향 TLS를 사용하는 경우 이 속성을 무시할 수 있습니다.

17.1.61. .spec.loki.manual.tls.caCert

설명
cacert는 인증 기관의 인증서 참조를 정의합니다.
유형
object
Expand
속성유형설명

certFile

string

cert file은 구성 맵 또는 시크릿 내의 인증서 파일 이름의 경로를 정의합니다.

certKey

string

certKey 는 구성 맵 또는 시크릿 내의 인증서 개인 키 파일 이름의 경로를 정의합니다. 키가 필요하지 않은 경우 생략합니다.

name

string

인증서가 포함된 구성 맵 또는 시크릿의 이름입니다.

네임스페이스

string

인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.

type

string

인증서 참조: configmap 또는 secret 을 입력합니다.

17.1.62. .spec.loki.manual.tls.userCert

설명
UserCert 는 사용자 인증서 참조를 정의하고 mTLS에 사용됩니다. 단방향 TLS를 사용하는 경우 이 속성을 무시할 수 있습니다.
유형
object
Expand
속성유형설명

certFile

string

cert file은 구성 맵 또는 시크릿 내의 인증서 파일 이름의 경로를 정의합니다.

certKey

string

certKey 는 구성 맵 또는 시크릿 내의 인증서 개인 키 파일 이름의 경로를 정의합니다. 키가 필요하지 않은 경우 생략합니다.

name

string

인증서가 포함된 구성 맵 또는 시크릿의 이름입니다.

네임스페이스

string

인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.

type

string

인증서 참조: configmap 또는 secret 을 입력합니다.

17.1.63. .spec.loki.microservices

설명
마이크로 서비스 모드에 대한 Loki 구성입니다. 마이크로 서비스 배포 모드(https://grafana.com/docs/loki/latest/fundamentals/architecture/deployment-modes/#microservices-mode)를 사용하여 Loki를 설치할 때 이 옵션을 사용합니다. 다른 모드에서는 무시됩니다.
유형
object
Expand
속성유형설명

ingesterUrl

string

ingesterUrl 은 흐름을 내보내는 기존 Loki ingester 서비스의 주소입니다.

querierUrl

string

querierURL 은 Loki querier 서비스의 주소를 지정합니다.

tenantID

string

tenantId 는 각 요청에 대해 테넌트를 식별하는 Loki X-Scope-OrgID 헤더입니다.

tls

object

Loki URL에 대한 TLS 클라이언트 구성

17.1.64. .spec.loki.microservices.tls

설명
Loki URL에 대한 TLS 클라이언트 구성
유형
object
Expand
속성유형설명

caCert

object

cacert는 인증 기관의 인증서 참조를 정의합니다.

enable

boolean

TLS 활성화

insecureSkipVerify

boolean

insecureSkipVerify 를 사용하면 서버 인증서의 클라이언트 측 확인을 건너뛸 수 있습니다. true 로 설정하면 caCert 필드가 무시됩니다.

userCert

object

UserCert 는 사용자 인증서 참조를 정의하고 mTLS에 사용됩니다. 단방향 TLS를 사용하는 경우 이 속성을 무시할 수 있습니다.

17.1.65. .spec.loki.microservices.tls.caCert

설명
cacert는 인증 기관의 인증서 참조를 정의합니다.
유형
object
Expand
속성유형설명

certFile

string

cert file은 구성 맵 또는 시크릿 내의 인증서 파일 이름의 경로를 정의합니다.

certKey

string

certKey 는 구성 맵 또는 시크릿 내의 인증서 개인 키 파일 이름의 경로를 정의합니다. 키가 필요하지 않은 경우 생략합니다.

name

string

인증서가 포함된 구성 맵 또는 시크릿의 이름입니다.

네임스페이스

string

인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.

type

string

인증서 참조: configmap 또는 secret 을 입력합니다.

17.1.66. .spec.loki.microservices.tls.userCert

설명
UserCert 는 사용자 인증서 참조를 정의하고 mTLS에 사용됩니다. 단방향 TLS를 사용하는 경우 이 속성을 무시할 수 있습니다.
유형
object
Expand
속성유형설명

certFile

string

cert file은 구성 맵 또는 시크릿 내의 인증서 파일 이름의 경로를 정의합니다.

certKey

string

certKey 는 구성 맵 또는 시크릿 내의 인증서 개인 키 파일 이름의 경로를 정의합니다. 키가 필요하지 않은 경우 생략합니다.

name

string

인증서가 포함된 구성 맵 또는 시크릿의 이름입니다.

네임스페이스

string

인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.

type

string

인증서 참조: configmap 또는 secret 을 입력합니다.

17.1.67. .spec.loki.monolithic

설명
Cryostat 모드에 대한 Loki 구성입니다. Loki가 모놀리식 배포 모드(https://grafana.com/docs/loki/latest/fundamentals/architecture/deployment-modes/#monolithic-mode)를 사용하여 설치할 때 이 옵션을 사용합니다. 다른 모드에서는 무시됩니다.
유형
object
Expand
속성유형설명

installDemoLoki

boolean

installDemoLokitrue 로 설정하여 Loki 배포, 서비스 및 스토리지를 자동으로 생성합니다. 이는 개발 및 데모 목적에 유용합니다. 프로덕션에서는 사용하지 마십시오. [지원되지 않음(*)].

tenantID

string

tenantId 는 각 요청에 대해 테넌트를 식별하는 Loki X-Scope-OrgID 헤더입니다.

tls

object

Loki URL에 대한 TLS 클라이언트 구성

url

string

URL 은 ingester와 querier를 둘 다 가리키는 기존 Loki 서비스의 고유한 주소입니다.

17.1.68. .spec.loki.monolithic.tls

설명
Loki URL에 대한 TLS 클라이언트 구성
유형
object
Expand
속성유형설명

caCert

object

cacert는 인증 기관의 인증서 참조를 정의합니다.

enable

boolean

TLS 활성화

insecureSkipVerify

boolean

insecureSkipVerify 를 사용하면 서버 인증서의 클라이언트 측 확인을 건너뛸 수 있습니다. true 로 설정하면 caCert 필드가 무시됩니다.

userCert

object

UserCert 는 사용자 인증서 참조를 정의하고 mTLS에 사용됩니다. 단방향 TLS를 사용하는 경우 이 속성을 무시할 수 있습니다.

17.1.69. .spec.loki.monolithic.tls.caCert

설명
cacert는 인증 기관의 인증서 참조를 정의합니다.
유형
object
Expand
속성유형설명

certFile

string

cert file은 구성 맵 또는 시크릿 내의 인증서 파일 이름의 경로를 정의합니다.

certKey

string

certKey 는 구성 맵 또는 시크릿 내의 인증서 개인 키 파일 이름의 경로를 정의합니다. 키가 필요하지 않은 경우 생략합니다.

name

string

인증서가 포함된 구성 맵 또는 시크릿의 이름입니다.

네임스페이스

string

인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.

type

string

인증서 참조: configmap 또는 secret 을 입력합니다.

17.1.70. .spec.loki.monolithic.tls.userCert

설명
UserCert 는 사용자 인증서 참조를 정의하고 mTLS에 사용됩니다. 단방향 TLS를 사용하는 경우 이 속성을 무시할 수 있습니다.
유형
object
Expand
속성유형설명

certFile

string

cert file은 구성 맵 또는 시크릿 내의 인증서 파일 이름의 경로를 정의합니다.

certKey

string

certKey 는 구성 맵 또는 시크릿 내의 인증서 개인 키 파일 이름의 경로를 정의합니다. 키가 필요하지 않은 경우 생략합니다.

name

string

인증서가 포함된 구성 맵 또는 시크릿의 이름입니다.

네임스페이스

string

인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.

type

string

인증서 참조: configmap 또는 secret 을 입력합니다.

17.1.71. .spec.networkPolicy

설명
NetworkPolicy 는 네트워크 Observability 구성 요소 격리에 대한 네트워크 정책 설정을 정의합니다.
유형
object
Expand
속성유형설명

additionalNamespaces

배열(문자열)

additionalNamespaces 에는 네트워크 Observability 네임스페이스에 연결할 수 있는 추가 네임스페이스가 포함되어 있습니다. 네트워크 정책 구성에서 유연성을 제공하지만 보다 구체적인 구성이 필요한 경우 이를 비활성화하고 대신 직접 설치할 수 있습니다.

enable

boolean

Network Observability(main 및 privileged)에서 사용하는 네임스페이스에 네트워크 정책을 배포합니다. 이러한 네트워크 정책은 바람직하지 않은 연결을 원하지 않고 해당 구성 요소의 연결을 방지하기 위해 Network Observability 구성 요소를 더 잘 격리합니다. 이 옵션은 OVNKubernetes와 함께 사용할 때 기본적으로 활성화되어 있으며 달리 비활성화되어 있습니다(다른 CNI에서 테스트되지 않음). 비활성화되면 네트워크 Observability 구성 요소에 대한 네트워크 정책을 수동으로 생성할 수 있습니다.

17.1.72. .spec.processor

설명
프로세서는 에이전트에서 흐름을 수신하고, 보강하고, 메트릭을 생성하고, Loki 지속성 계층 및/또는 사용 가능한 내보내기로 전달하는 구성 요소의 설정을 정의합니다.
유형
object
Expand
속성유형설명

addZone

boolean

addZone 은 소스 및 대상 영역으로 흐름에 라벨을 지정하여 가용성 영역 인식을 허용합니다. 이 기능을 사용하려면 노드에 "topology.kubernetes.io/zone" 라벨을 설정해야 합니다.

advanced

object

Advanced 를 사용하면 흐름 프로세서의 내부 구성의 일부 측면을 설정할 수 있습니다. 이 섹션은 GOGCGOMAXPROCS 환경 변수와 같은 디버깅 및 세분화된 성능 최적화를 목표로 합니다. 이러한 값을 at your own risk로 설정합니다.

clusterName

string

clusterName은 흐름 데이터에 표시되는 클러스터의 이름입니다. 이는 다중 클러스터 컨텍스트에서 유용합니다. OpenShift Container Platform을 사용하는 경우 자동으로 결정되도록 비워 둡니다.

consumerReplicas

integer

consumerReplicasflowlogs-pipeline 용으로 시작할 복제본(Pod) 수를 정의합니다. 기본값은 3입니다. spec.deploymentModelDirect 이거나 spec.processor.unmanagedReplicastrue 인 경우 이 설정은 무시됩니다.

deduper

object

deduper 를 사용하면 리소스 사용량을 저장하기 위해 중복으로 식별되는 흐름을 샘플링하거나 삭제할 수 있습니다.

filters

array

필터 를 사용하면 사용자 지정 필터를 정의하여 생성된 흐름의 양을 제한할 수 있습니다. 이러한 필터는 Kubernetes 네임스페이스로 필터링하는 것과 같이 eBPF 에이전트 필터( spec.agent.ebpf.flowFilter)보다 유연성을 제공하지만 성능이 저하됩니다.

imagePullPolicy

string

imagePullPolicy 는 위에 정의된 이미지의 Kubernetes 가져오기 정책입니다.

kafkaConsumerAutoscaler

object

kafkaConsumerAutoscaler [deprecated (*)]는 Kafka 메시지를 사용하는 flowlogs-pipeline-transformer 에 대해 설정하는 수평 Pod 자동 스케일러의 사양입니다. 이 설정은 Kafka가 비활성화되면 무시됩니다. 사용 중단 알림: 관리형 자동 스케일러는 향후 버전에서 제거됩니다. 선택한 자동 스케일러를 대신 구성하고 spec.processor.unmanagedReplicastrue 로 설정할 수 있습니다. HorizontalPodAutoscaler 문서(autoscaling/v2)를 참조하십시오.

kafkaConsumerBatchSize

integer

kafkaConsumerBatchSize 는 브로커에게 소비자가 허용하는 최대 배치 크기(바이트)를 나타냅니다. Kafka를 사용하지 않을 때는 무시됩니다. 기본값: 10MB.

kafkaConsumerQueueCapacity

integer

kafkaConsumerQueueCapacity 는 Kafka 소비자 클라이언트에서 사용되는 내부 메시지 큐의 용량을 정의합니다. Kafka를 사용하지 않을 때는 무시됩니다.

kafkaConsumerReplicas

integer

kafkaConsumerReplicas [deprecated (*)]는 Kafka 메시지를 사용하는 flowlogs-pipeline-transformer.NET Framework에 시작할 복제본(Pod) 수를 정의합니다. 이 설정은 Kafka가 비활성화되면 무시됩니다. 사용 중단 알림: 대신 spec.processor.consumerReplicas 를 사용합니다.

logLevel

string

프로세서 런타임의 로그 수준

logTypes

string

logTypes 는 생성할 원하는 레코드 유형을 정의합니다. 가능한 값은 다음과 같습니다:

- 일반 네트워크 흐름을 내보내는 흐름입니다. 이는 기본값입니다.

- 시작된 대화에 대한 이벤트를 생성하는 대화, 대화 및 정기적인 "틱" 업데이트에 대한 대화가 종료되었습니다. 이 모드에서는 긴 대화에서는 Prometheus 지표가 정확하지 않습니다.

- 종료된 대화 이벤트만 생성하기 위한 종료. 이 모드에서는 긴 대화에서는 Prometheus 지표가 정확하지 않습니다.

- 모두 네트워크 흐름과 모든 대화 이벤트를 생성합니다. 리소스 공간에 미치는 영향은 권장되지 않습니다.

metrics

object

메트릭 은 메트릭과 관련된 프로세서 구성을 정의합니다.

multiClusterDeployment

boolean

다중 클러스터 기능을 활성화하려면 multiClusterDeploymenttrue 로 설정합니다. 이를 통해 데이터 흐름을 위해 clusterName 레이블이 추가되었습니다.

resources

object

리소스는 이 컨테이너에 필요한 컴퓨팅 리소스입니다. 자세한 내용은 https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/에서 참조하십시오.

slicesConfig

object

FlowCollectorSlices 사용자 지정 리소스를 관리하는 글로벌 구성입니다.

subnetLabels

object

subnetLabels 는 서브넷 및 IP에 사용자 지정 레이블을 정의하거나 클러스터 외부 트래픽을 식별하는 데 사용되는 OpenShift Container Platform에서 인식된 서브넷의 자동 레이블을 활성화할 수 있습니다. 서브넷이 흐름의 소스 또는 대상 IP와 일치하면 해당 필드가 SrcSubnetLabel 또는 DstSubnetLabel.

unmanagedReplicas

boolean

UnmanagedReplicastrue 인 경우 Operator는 consumerReplicas 를 조정하지 않습니다. 이는 Pod 자동 스케일러를 사용할 때 유용합니다.

17.1.73. .spec.processor.advanced

설명
Advanced 를 사용하면 흐름 프로세서의 내부 구성의 일부 측면을 설정할 수 있습니다. 이 섹션은 GOGCGOMAXPROCS 환경 변수와 같은 디버깅 및 세분화된 성능 최적화를 목표로 합니다. 이러한 값을 at your own risk로 설정합니다.
유형
object
Expand
속성유형설명

conversationEndTimeout

string

conversationEndTimeout 은 대화가 종료되었다고 간주하기 위해 네트워크 흐름을 수신한 후 대기하는 시간입니다. 이 지연은 FIN 패킷이 TCP 흐름에 대해 수집될 때 무시됩니다(대신 conversationTerminatingTimeout 참조).

conversationHeartbeatInterval

string

conversationHeartbeatInterval 은 대화의 "틱" 이벤트 사이에 대기하는 시간입니다.

conversationTerminatingTimeout

string

conversationTerminatingTimeout 은 대화를 종료하기 위해 감지된 FIN 플래그에서 대기하는 시간입니다. TCP 흐름에만 관련이 있습니다.

dropUnusedFields

boolean

dropUnusedFields [더 이상 사용되지 않음 (*)] 이 설정은 더 이상 사용되지 않습니다.

enableKubeProbes

boolean

enableKubeProbes 는 Kubernetes 활성 및 준비 상태 프로브를 활성화하거나 비활성화하는 플래그입니다.

env

오브젝트(문자열)

env 를 사용하면 사용자 지정 환경 변수를 기본 구성 요소에 전달할 수 있습니다. GOGCGOMAXPROCS 와 같은 매우 구체적인 성능 튜닝 옵션을 전달하는 데 유용합니다. 이는 에지 디버그 또는 지원 시나리오에서만 유용하므로 FlowCollector 설명자의 일부로 공개적으로 노출해서는 안 됩니다.

healthPort

integer

healthPort 는 상태 점검 API를 노출하는 Pod의 수집기 HTTP 포트입니다.

port

integer

흐름 수집기(호스트 포트)의 포트입니다. 일부 값은 허용되지 않습니다. 1024보다 크고 4500, 4789 및 6081과 달라야 합니다.

profilePort

integer

profilePort 를 사용하면 이 포트를 수신하는 Go pprof 프로파일러를 설정할 수 있습니다.

scheduling

object

스케줄링은 노드에서 Pod를 예약하는 방법을 제어합니다.

secondaryNetworks

array

리소스 식별을 위해 확인할 보조 네트워크를 정의합니다. 올바른 ID를 보장하기 위해 인덱싱된 값은 클러스터 전체에서 고유 식별자를 형성해야 합니다. 여러 리소스에서 동일한 인덱스를 사용하는 경우 해당 리소스의 레이블이 잘못 지정될 수 있습니다.

17.1.74. .spec.processor.advanced.scheduling

설명
스케줄링은 노드에서 Pod를 예약하는 방법을 제어합니다.
유형
object
Expand
속성유형설명

유사성

object

지정된 경우 Pod의 스케줄링 제약 조건입니다. 문서는 https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling 를 참조하십시오.

nodeSelector

오브젝트(문자열)

nodeSelector 를 사용하면 각 라벨이 지정된 노드에만 Pod를 예약할 수 있습니다. 문서는 https://kubernetes.io/docs/concepts/configuration/assign-pod-node/ 를 참조하십시오.

priorityClassName

string

지정된 경우 Pod의 우선 순위를 나타냅니다. 문서는 https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/#how-to-use-priority-and-preemption 를 참조하십시오. 지정하지 않으면 기본 우선순위가 사용되거나 기본값이 없는 경우 0이 사용됩니다.

허용 오차

array

허용 오차 는 일치하는 테인트가 있는 노드에 Pod를 예약할 수 있는 허용 오차 목록입니다. 문서는 https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling 를 참조하십시오.

17.1.75. .spec.processor.advanced.scheduling.affinity

설명
지정된 경우 Pod의 스케줄링 제약 조건입니다. 문서는 https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling 를 참조하십시오.
유형
object

17.1.76. .spec.processor.advanced.scheduling.tolerations

설명
허용 오차 는 일치하는 테인트가 있는 노드에 Pod를 예약할 수 있는 허용 오차 목록입니다. 문서는 https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling 를 참조하십시오.
유형
array

17.1.77. .spec.processor.advanced.secondaryNetworks

설명
리소스 식별을 위해 확인할 보조 네트워크를 정의합니다. 올바른 ID를 보장하기 위해 인덱싱된 값은 클러스터 전체에서 고유 식별자를 형성해야 합니다. 여러 리소스에서 동일한 인덱스를 사용하는 경우 해당 리소스의 레이블이 잘못 지정될 수 있습니다.
유형
array

17.1.78. .spec.processor.advanced.secondaryNetworks[]

설명
유형
object
필수 항목
  • 인덱스
  • name
Expand
속성유형설명

인덱스

배열(문자열)

index 는 Pod를 인덱싱하는 데 사용할 필드 목록입니다. 클러스터 전체에서 고유한 Pod ID를 형성해야 합니다. MAC,IP,인터페이스 중 하나일 수 있습니다. 'k8s.v1.cni.cncf.io/network-status' 주석에 없는 필드는 인덱스에 추가할 수 없습니다.

name

string

name 은 Pod 주석 'k8s.v1.cni.cncf.io/network-status'에 표시되는 네트워크 이름과 일치해야 합니다.

17.1.79. .spec.processor.deduper

설명
deduper 를 사용하면 리소스 사용량을 저장하기 위해 중복으로 식별되는 흐름을 샘플링하거나 삭제할 수 있습니다.
유형
object
Expand
속성유형설명

mode

string

Processor de-duplication 모드를 설정합니다. 에이전트는 다른 노드에서 보고된 동일한 흐름을 중복 제거할 수 없기 때문에 에이전트 기반 중복 제거 외에도 제공됩니다.

- Drop 를 사용하여 중복으로 간주되는 모든 흐름을 삭제하여 리소스 사용량에 더 많이 저장할 수 있지만 피어 또는 네트워크 이벤트에서 사용되는 네트워크 인터페이스와 같은 일부 정보가 손실될 수 있습니다.

- 샘플을 사용하여 기본값인 50에 하나의 흐름만 무작위로 유지합니다. 이 흐름은 중복으로 간주됩니다. 이는 모든 중복을 삭제하거나 모든 중복을 유지하는 것 사이의 타협입니다. 이 샘플링 작업은 에이전트 기반 샘플링에 추가됩니다. 에이전트 및 프로세서 샘플링 값이 모두 50 이면 결합된 샘플링은 1:2500입니다.

- Disabled 를 사용하여 프로세서 기반 중복 제거를 끕니다.

sampling

integer

샘플링 은 deduper 모드가 샘플 인 경우 샘플링 간격입니다. 예를 들어, 값 50 은 50개 중 1개의 흐름이 샘플링된다는 것을 의미합니다.

17.1.80. .spec.processor.filters

설명
필터 를 사용하면 사용자 지정 필터를 정의하여 생성된 흐름의 양을 제한할 수 있습니다. 이러한 필터는 Kubernetes 네임스페이스로 필터링하는 것과 같이 eBPF 에이전트 필터( spec.agent.ebpf.flowFilter)보다 유연성을 제공하지만 성능이 저하됩니다.
유형
array

17.1.81. .spec.processor.filters[]

설명
CryostatPFilterSet 은 모든 조건을 충족하는 CryostatP 기반 필터링에 대해 원하는 구성을 정의합니다.
유형
object
Expand
속성유형설명

outputTarget

string

지정된 경우 이러한 필터는 Loki,Metrics 또는 Exporters 라는 단일 출력을 대상으로 합니다. 기본적으로 모든 출력은 대상으로 합니다.

query

string

유지할 네트워크 흐름을 선택하는 쿼리입니다. https://github.com/netobserv/flowlogs-pipeline/blob/main/docs/filtering.md 에서 이 쿼리 언어에 대한 자세한 내용은 다음을 참조하십시오.

sampling

integer

샘플링 은 이 필터에 적용할 선택적 샘플링 간격입니다. 예를 들어 값 50은 50 의 일치 흐름 1이 샘플링됨을 의미합니다.

17.1.82. .spec.processor.kafkaConsumerAutoscaler

설명
kafkaConsumerAutoscaler [deprecated (*)]는 Kafka 메시지를 사용하는 flowlogs-pipeline-transformer 에 대해 설정하는 수평 Pod 자동 스케일러의 사양입니다. 이 설정은 Kafka가 비활성화되면 무시됩니다. 사용 중단 알림: 관리형 자동 스케일러는 향후 버전에서 제거됩니다. 선택한 자동 스케일러를 대신 구성하고 spec.processor.unmanagedReplicastrue 로 설정할 수 있습니다. HorizontalPodAutoscaler 문서(autoscaling/v2)를 참조하십시오.
유형
object

17.1.83. .spec.processor.metrics

설명
메트릭 은 메트릭과 관련된 프로세서 구성을 정의합니다.
유형
object
Expand
속성유형설명

disableAlerts

배열(문자열)

disableAlerts 는 기본 경고 세트에서 비활성화해야 하는 경고 그룹 목록입니다. 가능한 값은 다음과 같습니다. NetObservNoFlows,NetObservLokiError,PacketDropsByKernel,PacketDropsByDevice,IPsecErrors,NetpolDenied,LatencyHighTrend,DNSErrors, DNSNxDomain,ExternalEgressHighTrend,ExternalIngressHighTrend,Ingress5xxErrors,IngressHTTPLatencyTrend. 경고에 대한 자세한 내용은 https://github.com/netobserv/network-observability-operator/blob/main/docs/HealthRules.md

healthRules

array

healthRules 는 Prometheus에 대해 생성할 상태 규칙 목록으로, 템플릿 및 변형으로 구성됩니다. 각 상태 규칙은 mode 필드를 기반으로 경고 또는 레코딩 규칙을 생성하도록 구성할 수 있습니다. 건강 규칙에 대한 자세한 내용은 https://github.com/netobserv/network-observability-operator/blob/main/docs/HealthRules.md

includeList

배열(문자열)

includeList 는 생성할 메트릭 이름 목록입니다. 이름은 접두사 없이 Prometheus의 이름에 해당합니다. 예를 들어 namespace_egress_packets_total 은 Prometheus에 netobserv_namespace_egress_packets_total 으로 표시됩니다. 더 많은 메트릭을 추가하면 Prometheus 워크로드 리소스에 더 큰 영향을 미칩니다. 기본적으로 활성화된 메트릭은 다음과 같습니다. namespace_flows_total,node_ingress_bytes_total,node_egress_bytes_total,workload_ingress_bytes_total,workload_egress_bytes_total,namespace_drop_packets_total ( PacketDrop 기능이 활성화된 경우), namespace_rtt_seconds ( FlowRTT 기능이 활성화된 경우) namespace_dns_latency_seconds ( DNSTracking 기능이 활성화된 경우), namespace_network_policy_events_total ( NetworkEvents 기능이 활성화된 경우) 자세한 내용은 사용 가능한 메트릭 전체 목록으로 다음을 수행합니다. https://github.com/netobserv/network-observability-operator/blob/main/docs/Metrics.md

server

object

Prometheus 스크랩에 대한 메트릭 서버 끝점 구성

17.1.84. .spec.processor.metrics.healthRules

설명
healthRules 는 Prometheus에 대해 생성할 상태 규칙 목록으로, 템플릿 및 변형으로 구성됩니다. 각 상태 규칙은 mode 필드를 기반으로 경고 또는 레코딩 규칙을 생성하도록 구성할 수 있습니다. 건강 규칙에 대한 자세한 내용은 https://github.com/netobserv/network-observability-operator/blob/main/docs/HealthRules.md
유형
array

17.1.85. .spec.processor.metrics.healthRules[]

설명
유형
object
필수 항목
  • 템플릿
  • 변형
Expand
속성유형설명

mode

string

mode는 이 상태 규칙을 경고 또는 레코딩 규칙으로 생성해야 하는지 여부를 정의합니다. 가능한 값은 Alert (기본값), Recording 입니다. 기록 규칙 위반은 Prometheus 경고를 생성하지 않고 네트워크 상태 대시보드에 표시됩니다. 이를 통해 많은 새로운 경고가 발생할 수 있는 SRE 및 클러스터 관리자에 대한 상태 정보를 가져올 수 있는 대체 방법이 제공됩니다.

템플릿

string

상태 규칙 템플릿 이름. 가능한 값은 다음과 같습니다. PacketDropsByKernel,PacketDropsByDevice,IPsecErrors,NetpolDenied,LatencyHighTrend,DNSErrors,DNSNxDomain,ExternalEgressHighTrend,ExternalIngressHighTrend, Ingress5xxErrors,IngressHTTPLatencyTrend. 참고: NetObservNoFlowsNetObservLokiError 는 경고 전용이며 상태 규칙으로 사용할 수 없습니다. 건강 규칙에 대한 자세한 내용은 https://github.com/netobserv/network-observability-operator/blob/main/docs/HealthRules.md

변형

array

이 템플릿의 변형 목록

17.1.86. .spec.processor.metrics.healthRules[].variants

설명
이 템플릿의 변형 목록
유형
array

17.1.87. .spec.processor.metrics.healthRules[].variants[]

설명
유형
object
필수 항목
  • 임계값
Expand
속성유형설명

groupBy

string

선택적 그룹화 기준, 가능한 값은 노드 , 네임스페이스, 워크로드입니다.

lowVolumeThreshold

string

볼륨 임계값이 낮으면 신호를 개선하기 위해 트래픽이 너무 적은 메트릭을 무시할 수 있습니다. 이는 절대 속도(컨텍스트에 따라 초당 바이트 또는 초당 패킷 수)로 제공됩니다. 제공된 경우 플롯으로 패를 사용할 수 있어야 합니다.

mode

string

mode는 이 특정 변형에 대한 상태 규칙 모드를 재정의합니다. 지정하지 않으면 상위 상태 규칙의 모드에서 상속됩니다. 가능한 값은 Alert,Recording 입니다.

임계값

object

심각도별로 상태 규칙의 임계값입니다. 이러한 오류는 경고가 트리거되는 오류의 백분율로 표시됩니다. 이들은 플로어로 구울 수 있어야합니다. 경고 및 레코딩 모드 모두에 필요합니다.

trendDuration

string

상태 규칙 추세를 위해 기준 비교의 기간 간격입니다. 예를 들어, "2h"는 2시간 평균과 비교를 의미합니다. 기본값은 2h입니다.

trendOffset

string

상태 규칙 추세를 위해 기준 비교에 대한 시간 오프셋입니다. 예를 들어, "1d"는 past past와의 비교를 의미합니다. 기본값은 1d입니다.

17.1.88. .spec.processor.metrics.healthRules[].variants[].thresholds

설명
심각도별로 상태 규칙의 임계값입니다. 이러한 오류는 경고가 트리거되는 오류의 백분율로 표시됩니다. 이들은 플로어로 구울 수 있어야합니다. 경고 및 레코딩 모드 모두에 필요합니다.
유형
object
Expand
속성유형설명

심각

string

심각도 심각도의 임계값 입니다. Critical 경고를 생성하지 않도록 비워 둡니다.

info

string

심각도 정보 의 임계값 . 정보 경고를 생성하지 않도록 비워 둡니다.

경고

string

심각도 경고 의 임계값입니다. 경고 경고를 생성하지 않도록 비워 둡니다.

17.1.89. .spec.processor.metrics.server

설명
Prometheus 스크랩에 대한 메트릭 서버 끝점 구성
유형
object
Expand
속성유형설명

port

integer

지표 서버 HTTP 포트입니다.

tls

object

TLS 구성입니다.

17.1.90. .spec.processor.metrics.server.tls

설명
TLS 구성입니다.
유형
object
필수 항목
  • type
Expand
속성유형설명

insecureSkipVerify

boolean

insecureSkipVerify 를 사용하면 제공된 인증서의 클라이언트 측 확인을 건너뛸 수 있습니다. true 로 설정하면 providedCaFile 필드가 무시됩니다.

제공됨

object

typeProvided 로 설정된 경우 TLS 구성입니다.

providedCaFile

object

typeProvided 로 설정된 경우 CA 파일에 대한 참조입니다.

type

string

TLS 구성 유형을 선택합니다.

- 끝점에 대해 TLS를 구성하지 않도록 비활성화됨 (기본값)입니다. - 인증서 파일과 키 파일을 수동으로 제공하도록 제공됩니다. [Unsupported(*)]. - 주석을 사용하여 OpenShift Container Platform 자동 생성 인증서를 사용하도록 자동 설정됩니다.

17.1.91. .spec.processor.metrics.server.tls.provided

설명
typeProvided 로 설정된 경우 TLS 구성입니다.
유형
object
Expand
속성유형설명

certFile

string

cert file은 구성 맵 또는 시크릿 내의 인증서 파일 이름의 경로를 정의합니다.

certKey

string

certKey 는 구성 맵 또는 시크릿 내의 인증서 개인 키 파일 이름의 경로를 정의합니다. 키가 필요하지 않은 경우 생략합니다.

name

string

인증서가 포함된 구성 맵 또는 시크릿의 이름입니다.

네임스페이스

string

인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.

type

string

인증서 참조: configmap 또는 secret 을 입력합니다.

17.1.92. .spec.processor.metrics.server.tls.providedCaFile

설명
typeProvided 로 설정된 경우 CA 파일에 대한 참조입니다.
유형
object
Expand
속성유형설명

file

string

구성 맵 또는 시크릿 내의 파일 이름입니다.

name

string

파일이 포함된 구성 맵 또는 시크릿의 이름입니다.

네임스페이스

string

파일이 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.

type

string

파일 참조: configmap 또는 secret 에 대해 를 입력합니다.

17.1.93. .spec.processor.resources

설명
리소스는 이 컨테이너에 필요한 컴퓨팅 리소스입니다. 자세한 내용은 https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/에서 참조하십시오.
유형
object
Expand
속성유형설명

limits

integer-or-string

제한은 허용되는 최대 컴퓨팅 리소스 양을 나타냅니다. 자세한 내용은 https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

requests

integer-or-string

요청은 필요한 최소 컴퓨팅 리소스 양을 설명합니다. 컨테이너에 대한 Requests를 생략하면 구현 정의된 값을 제외하고 명시적으로 지정된 경우 기본값은 Limits로 설정됩니다. 요청은 제한을 초과할 수 없습니다. 자세한 내용은 https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

17.1.94. .spec.processor.slicesConfig

설명
FlowCollectorSlices 사용자 지정 리소스를 관리하는 글로벌 구성입니다.
유형
object
필수 항목
  • enable
Expand
속성유형설명

collectionMode

string

collectionMode 는 FlowCollectorSlice 사용자 정의 리소스가 흐름 수집 프로세스에 미치는 영향을 결정합니다.

- AlwaysCollect 로 설정하면 FlowCollectorSlice의 존재 여부에 관계없이 모든 흐름이 수집됩니다.

- AllowList 로 설정하면 FlowCollectorSlice 리소스가 있거나 글로벌 namespacesAllowList 를 통해 구성된 네임스페이스와 관련된 흐름만 수집됩니다.

enable

boolean

FlowCollectorSlice 기능이 활성화되어 있는지 여부를 결정합니다. 그렇지 않으면 일종의 FlowCollectorSlice의 모든 리소스가 무시됩니다.

namespacesAllowList

배열(문자열)

namespacesAllowList 는 해당 네임스페이스에 FlowCollectorSlice가 있는지에 관계없이 항상 흐름을 수집하는 네임스페이스 목록입니다. 슬래시로 묶은 항목(예: /openshift-.*/ )은 정규식과 일치합니다. collectionModeAllowList 와 다른 경우 이 설정은 무시됩니다.

17.1.95. .spec.processor.subnetLabels

설명
subnetLabels 는 서브넷 및 IP에 사용자 지정 레이블을 정의하거나 클러스터 외부 트래픽을 식별하는 데 사용되는 OpenShift Container Platform에서 인식된 서브넷의 자동 레이블을 활성화할 수 있습니다. 서브넷이 흐름의 소스 또는 대상 IP와 일치하면 해당 필드가 SrcSubnetLabel 또는 DstSubnetLabel.
유형
object
Expand
속성유형설명

customLabels

array

customLabels 를 사용하면 클러스터 외부 워크로드 또는 웹 서비스를 식별하기 위해 서브넷 및 IP 레이블을 사용자 지정할 수 있습니다. 기본 빠른 필터 및 제공된 일부 메트릭 예제에서 작업하려면 외부 서브넷에 EXT: 접두사 , 레이블이 지정되거나 전혀 레이블이 지정되지 않아야 합니다.

openShiftAuto detect 가 비활성화되었거나 OpenShift Container Platform을 사용하지 않는 경우 내부 트래픽을 외부 트래픽과 구분하기 위해 클러스터 서브넷에 대한 라벨을 수동으로 구성하는 것이 좋습니다.

openShiftAutoDetect 가 활성화된 경우 customLabels 는 겹치는 경우 감지된 서브넷을 덮어씁니다.

openShiftAutoDetect

boolean

OpenShift Auto detect를 사용하면 true 로 설정하면 OpenShift Container Platform 설치 구성 및 Cluster Network Operator 구성을 기반으로 머신, Pod 및 서비스 서브넷을 자동으로 감지할 수 있습니다. 간접적으로 외부 트래픽을 정확하게 감지하는 방법입니다. 해당 서브넷에 대해 레이블이 지정되지 않은 흐름은 클러스터 외부에 있습니다. OpenShift Container Platform에서 기본적으로 활성화되어 있습니다.

17.1.96. .spec.processor.subnetLabels.customLabels

설명

customLabels 를 사용하면 클러스터 외부 워크로드 또는 웹 서비스를 식별하기 위해 서브넷 및 IP 레이블을 사용자 지정할 수 있습니다. 기본 빠른 필터 및 제공된 일부 메트릭 예제에서 작업하려면 외부 서브넷에 EXT: 접두사 , 레이블이 지정되거나 전혀 레이블이 지정되지 않아야 합니다.

openShiftAuto detect 가 비활성화되었거나 OpenShift Container Platform을 사용하지 않는 경우 내부 트래픽을 외부 트래픽과 구분하기 위해 클러스터 서브넷에 대한 라벨을 수동으로 구성하는 것이 좋습니다.

openShiftAutoDetect 가 활성화된 경우 customLabels 는 겹치는 경우 감지된 서브넷을 덮어씁니다.

유형
array

17.1.97. .spec.processor.subnetLabels.customLabels[]

설명
SubnetLabel을 사용하면 클러스터 외부 워크로드 또는 웹 서비스를 식별하는 등의 서브넷 및 IP에 레이블을 지정할 수 있습니다.
유형
object
필수 항목
  • cidrs
  • name
Expand
속성유형설명

cidrs

배열(문자열)

["1.2.3.4/32"] 와 같은 CIDR 목록입니다.

name

string

일치하는 흐름에 플래그를 지정하는 데 사용되는 레이블 이름입니다. 기본 빠른 필터 및 제공된 일부 메트릭 예제에서 작업하려면 외부 서브넷에 EXT: 접두사 , 레이블이 지정되거나 전혀 레이블이 지정되지 않아야 합니다.

17.1.98. .spec.prometheus

설명
Prometheus 는 콘솔 플러그인에서 지표를 가져오는 데 사용되는 querier 구성과 같은 Prometheus 설정을 정의합니다.
유형
object
Expand
속성유형설명

querier

object

콘솔 플러그인에 사용되는 클라이언트 설정과 같은 Prometheus 쿼리 구성입니다.

17.1.99. .spec.prometheus.querier

설명
콘솔 플러그인에 사용되는 클라이언트 설정과 같은 Prometheus 쿼리 구성입니다.
유형
object
필수 항목
  • mode
Expand
속성유형설명

enable

boolean

enabletrue 이면 Console 플러그인 쿼리는 가능한 경우 Loki 대신 Prometheus에서 흐름 메트릭을 쿼리합니다. 기본적으로 활성화되어 있습니다. 이 기능을 비활성화하려면 false 로 설정합니다. 콘솔 플러그인은 Loki 또는 Prometheus를 메트릭의 데이터 소스로 사용하거나 ( spec.loki참조) 또는 둘 다 사용할 수 있습니다. 모든 쿼리를 Loki에서 Prometheus로 전송할 수 있는 것은 아닙니다. 따라서 Loki가 비활성화된 경우 Pod별 정보 가져오기 또는 원시 흐름 보기와 같은 플러그인의 일부 기능도 비활성화됩니다. Prometheus와 Loki가 모두 활성화된 경우 Prometheus가 우선 순위를 수행하며 Loki는 Prometheus가 처리할 수 없는 쿼리의 폴백으로 사용됩니다. 둘 다 비활성화되어 있으면 콘솔 플러그인이 배포되지 않습니다.

manual

object

수동 모드에 대한 Prometheus 구성입니다.

mode

string

모드는 네트워크 Observability 메트릭을 저장하는 Prometheus 설치 유형에 따라 설정해야 합니다.

- Auto 를 사용하여 자동으로 구성합니다. OpenShift Container Platform에서 OpenShift Container Platform 클러스터 모니터링의 Thanos querier를 사용합니다.

- 수동 설정에 수동 사용.

timeout

string

시간 초과 는 Prometheus에 대한 콘솔 플러그인 쿼리의 읽기 제한 시간입니다. 시간 초과가 0이면 시간 초과가 없음을 의미합니다.

17.1.100. .spec.prometheus.querier.manual

설명
수동 모드에 대한 Prometheus 구성입니다.
유형
object
Expand
속성유형설명

alertManager

object

Alertmanager 구성입니다. 이는 콘솔에서 상태 정보를 표시하기 위해 음소거된 경고를 쿼리하는 데 사용됩니다. OpenShift Container Platform에서 사용하는 경우 대신 Console API를 사용하도록 비워 둘 수 있습니다. [지원되지 않음(*)].

forwardUserToken

boolean

Prometheus에 대한 쿼리에 로그인한 사용자 토큰을 전달하려면 true 를 설정합니다.

tls

object

Prometheus URL에 대한 TLS 클라이언트 구성

url

string

URL 은 메트릭을 쿼리하는 데 사용할 기존 Prometheus 서비스의 주소입니다.

17.1.101. .spec.prometheus.querier.manual.alertManager

설명
Alertmanager 구성입니다. 이는 콘솔에서 상태 정보를 표시하기 위해 음소거된 경고를 쿼리하는 데 사용됩니다. OpenShift Container Platform에서 사용하는 경우 대신 Console API를 사용하도록 비워 둘 수 있습니다. [지원되지 않음(*)].
유형
object
Expand
속성유형설명

tls

object

Prometheus AlertManager URL에 대한 TLS 클라이언트 구성

url

string

URL 은 경고를 쿼리하는 데 사용할 기존 Prometheus AlertManager 서비스의 주소입니다.

17.1.102. .spec.prometheus.querier.manual.alertManager.tls

설명
Prometheus AlertManager URL에 대한 TLS 클라이언트 구성
유형
object
Expand
속성유형설명

caCert

object

cacert는 인증 기관의 인증서 참조를 정의합니다.

enable

boolean

TLS 활성화

insecureSkipVerify

boolean

insecureSkipVerify 를 사용하면 서버 인증서의 클라이언트 측 확인을 건너뛸 수 있습니다. true 로 설정하면 caCert 필드가 무시됩니다.

userCert

object

UserCert 는 사용자 인증서 참조를 정의하고 mTLS에 사용됩니다. 단방향 TLS를 사용하는 경우 이 속성을 무시할 수 있습니다.

17.1.103. .spec.prometheus.querier.manual.alertManager.tls.caCert

설명
cacert는 인증 기관의 인증서 참조를 정의합니다.
유형
object
Expand
속성유형설명

certFile

string

cert file은 구성 맵 또는 시크릿 내의 인증서 파일 이름의 경로를 정의합니다.

certKey

string

certKey 는 구성 맵 또는 시크릿 내의 인증서 개인 키 파일 이름의 경로를 정의합니다. 키가 필요하지 않은 경우 생략합니다.

name

string

인증서가 포함된 구성 맵 또는 시크릿의 이름입니다.

네임스페이스

string

인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.

type

string

인증서 참조: configmap 또는 secret 을 입력합니다.

17.1.104. .spec.prometheus.querier.manual.alertManager.tls.userCert

설명
UserCert 는 사용자 인증서 참조를 정의하고 mTLS에 사용됩니다. 단방향 TLS를 사용하는 경우 이 속성을 무시할 수 있습니다.
유형
object
Expand
속성유형설명

certFile

string

cert file은 구성 맵 또는 시크릿 내의 인증서 파일 이름의 경로를 정의합니다.

certKey

string

certKey 는 구성 맵 또는 시크릿 내의 인증서 개인 키 파일 이름의 경로를 정의합니다. 키가 필요하지 않은 경우 생략합니다.

name

string

인증서가 포함된 구성 맵 또는 시크릿의 이름입니다.

네임스페이스

string

인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.

type

string

인증서 참조: configmap 또는 secret 을 입력합니다.

17.1.105. .spec.prometheus.querier.manual.tls

설명
Prometheus URL에 대한 TLS 클라이언트 구성
유형
object
Expand
속성유형설명

caCert

object

cacert는 인증 기관의 인증서 참조를 정의합니다.

enable

boolean

TLS 활성화

insecureSkipVerify

boolean

insecureSkipVerify 를 사용하면 서버 인증서의 클라이언트 측 확인을 건너뛸 수 있습니다. true 로 설정하면 caCert 필드가 무시됩니다.

userCert

object

UserCert 는 사용자 인증서 참조를 정의하고 mTLS에 사용됩니다. 단방향 TLS를 사용하는 경우 이 속성을 무시할 수 있습니다.

17.1.106. .spec.prometheus.querier.manual.tls.caCert

설명
cacert는 인증 기관의 인증서 참조를 정의합니다.
유형
object
Expand
속성유형설명

certFile

string

cert file은 구성 맵 또는 시크릿 내의 인증서 파일 이름의 경로를 정의합니다.

certKey

string

certKey 는 구성 맵 또는 시크릿 내의 인증서 개인 키 파일 이름의 경로를 정의합니다. 키가 필요하지 않은 경우 생략합니다.

name

string

인증서가 포함된 구성 맵 또는 시크릿의 이름입니다.

네임스페이스

string

인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.

type

string

인증서 참조: configmap 또는 secret 을 입력합니다.

17.1.107. .spec.prometheus.querier.manual.tls.userCert

설명
UserCert 는 사용자 인증서 참조를 정의하고 mTLS에 사용됩니다. 단방향 TLS를 사용하는 경우 이 속성을 무시할 수 있습니다.
유형
object
Expand
속성유형설명

certFile

string

cert file은 구성 맵 또는 시크릿 내의 인증서 파일 이름의 경로를 정의합니다.

certKey

string

certKey 는 구성 맵 또는 시크릿 내의 인증서 개인 키 파일 이름의 경로를 정의합니다. 키가 필요하지 않은 경우 생략합니다.

name

string

인증서가 포함된 구성 맵 또는 시크릿의 이름입니다.

네임스페이스

string

인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.

type

string

인증서 참조: configmap 또는 secret 을 입력합니다.

18장. FlowMetric 구성 매개변수

FlowMetric API는 수집된 네트워크 흐름 로그에서 사용자 정의 관찰 가능 지표를 생성하는 데 사용됩니다.

18.1. FlowMetric [flows.netobserv.io/v1alpha1]

설명
FlowMetric은 수집된 흐름 로그에서 사용자 지정 지표를 생성할 수 있는 API입니다.
유형
object
Expand
속성유형설명

apiVersion

string

APIVersion은 버전이 지정된 이 오브젝트 표현의 스키마를 정의합니다. 서버는 인식된 스키마를 최신 내부 값으로 변환해야 하며 인식할 수 없는 값을 거부할 수 있습니다. 자세한 내용은 https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

kind

string

kind는 이 오브젝트가 나타내는 REST 리소스에 해당하는 문자열 값입니다. 서버는 클라이언트가 요청을 제출하는 끝점에서 이를 유추할 수 있습니다. CamelCase로 업데이트할 수 없습니다. 자세한 내용은 https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

메타데이터

object

표준 오브젝트의 메타데이터입니다. 자세한 내용은 https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

spec

object

FlowMetricSpec은 원하는 FlowMetricSpec을 정의합니다. 제공된 API를 사용하면 필요에 따라 이러한 메트릭을 사용자 지정할 수 있습니다.

새 메트릭을 추가하거나 기존 레이블을 수정할 때 심각한 영향을 미칠 수 있으므로 Prometheus 워크로드의 메모리 사용량을 신중하게 모니터링해야 합니다. CF https://rhobs-handbook.netlify.app/products/openshiftmonitoring/telemetry.md/#what-is-the-cardinality-of-a-metric

모든 네트워크 관찰 기능 메트릭의 카디널리티를 확인하려면 promql:count({name=~"netobserv.*"})로 (이름) 로 실행합니다.

18.1.1. .metadata

설명
표준 오브젝트의 메타데이터입니다. 자세한 내용은 https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
유형
object

18.1.2. .spec

설명

FlowMetricSpec은 원하는 FlowMetricSpec을 정의합니다. 제공된 API를 사용하면 필요에 따라 이러한 메트릭을 사용자 지정할 수 있습니다.

새 메트릭을 추가하거나 기존 레이블을 수정할 때 심각한 영향을 미칠 수 있으므로 Prometheus 워크로드의 메모리 사용량을 신중하게 모니터링해야 합니다. CF https://rhobs-handbook.netlify.app/products/openshiftmonitoring/telemetry.md/#what-is-the-cardinality-of-a-metric

모든 네트워크 관찰 기능 메트릭의 카디널리티를 확인하려면 promql:count({name=~"netobserv.*"})로 (이름) 로 실행합니다.

유형
object
필수 항목
  • type
Expand
속성유형설명

버킷

배열(문자열)

유형이 "Histogram"일 때 사용할 버킷 목록입니다. 목록은 플릿으로 패리팅할 수 있어야 합니다. 설정하지 않으면 Prometheus 기본 버킷이 사용됩니다.

charts

array

관리자 보기, Dashboards 메뉴의 OpenShift Container Platform 콘솔의 차트 구성입니다.

direction

string

수신, 송신 또는 방향 흐름에 대해 필터링합니다. Ingress 로 설정하면 FlowDirection:0|2 에서 정규식 필터를 추가하는 것과 동일합니다. Egress 로 설정하면 FlowDirection:1|2 에서 정규식 필터를 추가하는 것과 동일합니다.

divider

string

0이 아닌 경우 값의 스케일 인수(divider)입니다. metric value = Flow value / Divider.

filters

array

필터 는 고려되는 흐름을 제한하는 데 사용되는 필드 및 값 목록입니다. 사용 가능한 필드 목록에 대한 설명서를 참조하십시오. https://docs.redhat.com/en/documentation/openshift_container_platform/latest/html/network_observability/json-flows-format-reference.

flatten

배열(문자열)

flatten 은 Interfaces 또는 NetworkEvents와 같이 병합되어야 하는 배열 유형 필드 목록입니다. 병합된 필드는 해당 필드에서 항목당 하나의 메트릭을 생성합니다. 예를 들어, 바이트 카운터의 인터페이스를 병합할 때 Interfaces [br-ex, ens5]를 갖는 흐름은 br-exens5 에 대한 카운터를 늘립니다.

help

string

Prometheus에 표시되는 지표의 도움말 텍스트입니다.

labels

배열(문자열)

labels 는 Prometheus 레이블로 사용해야 하는 필드 목록입니다(예: SrcK8S_Namespace). 레이블 선택부터 이 메트릭의 단위 수준 및 쿼리 시 사용 가능한 집계가 생성됩니다. 지표 카디널리티에 영향을 미치므로 신중하게 수행해야 합니다(cf https://rhobs-handbook.netlify.app/products/openshiftmonitoring/telemetry.md/#what-is-the-cardinality-of-a-metric). 일반적으로 IP 또는 MAC 주소와 같은 매우 높은 카디널리티 레이블을 설정하지 마십시오. "SrcK8S_OwnerName" 또는 "DstK8S_OwnerName"은 가능한 한 "SrcK8S_Name" 또는 "DstK8S_Name"보다 우선해야 합니다. 사용 가능한 필드 목록에 대한 설명서를 참조하십시오. https://docs.redhat.com/en/documentation/openshift_container_platform/latest/html/network_observability/json-flows-format-reference.

metricName

string

메트릭의 이름입니다. Prometheus에서는 자동으로 "netobserv_" 접두사가 지정됩니다. FlowMetric 리소스 이름을 기반으로 이름을 생성하려면 비워 둡니다.

remap

오브젝트(문자열)

생성된 지표 라벨에 흐름 필드와 다른 이름을 사용하도록 remap 속성을 설정합니다. 원본 흐름 필드를 키로 사용하고 원하는 라벨 이름을 값으로 사용합니다.

type

string

메트릭 유형: "Counter", "Histogram" 또는 "Gauge". 시간이 지남에 따라 증가하고 rates 또는 Packets와 같은 비율을 계산할 수 있는 모든 값에 "Counter"를 사용합니다. 대기 시간과 같이 독립적으로 샘플링해야하는 모든 값에 대해 "Histogram"을 사용하십시오. 시간이 지남에 따라 정확도가 필요하지 않은 다른 값에는 "Gauge"를 사용합니다. (가그들은 Prometheus가 메트릭을 가져올 때 N초마다 샘플링됩니다).

valueField

string

valueField 는 이 메트릭의 값으로 사용해야 하는 flow 필드입니다(예: Cryostats ). 이 필드에는 숫자 값이 있어야 합니다. 흐름당 특정 값이 아닌 흐름을 계산하도록 비워 둡니다. 사용 가능한 필드 목록에 대한 설명서를 참조하십시오. https://docs.redhat.com/en/documentation/openshift_container_platform/latest/html/network_observability/json-flows-format-reference.

18.1.3. .spec.charts

설명
관리자 보기, Dashboards 메뉴의 OpenShift Container Platform 콘솔의 차트 구성입니다.
유형
array

18.1.4. .spec.charts[]

설명
메트릭에 연결된 차트 / 대시보드 생성 구성
유형
object
필수 항목
  • dashboardName
  • queries
  • title
  • type
Expand
속성유형설명

dashboardName

string

포함된 대시보드의 이름입니다. 이 이름이 기존 대시보드를 참조하지 않으면 새 대시보드가 생성됩니다.

queries

array

이 차트에 표시할 쿼리 목록입니다. typeSingleStat 이고 여러 쿼리가 제공되면 이 차트는 여러 패널(쿼리당 하나씩)에서 자동으로 확장됩니다.

sectionName

string

포함된 대시보드 섹션의 이름입니다. 이 이름이 기존 섹션을 참조하지 않으면 새 섹션이 생성됩니다. sectionName 이 생략되거나 비어 있으면 차트는 글로벌 상단 섹션에 배치됩니다.

title

string

차트의 이름입니다.

type

string

차트의 유형입니다.

단위

string

이 차트의 단위입니다. 현재 몇 개의 유닛만 지원됩니다. 일반 번호를 사용하려면 비워 둡니다.

18.1.5. .spec.charts[].queries

설명
이 차트에 표시할 쿼리 목록입니다. typeSingleStat 이고 여러 쿼리가 제공되면 이 차트는 여러 패널(쿼리당 하나씩)에서 자동으로 확장됩니다.
유형
array

18.1.6. .spec.charts[].queries[]

설명
PromQL 쿼리 구성
유형
object
필수 항목
  • legend
  • promQL
  • top
Expand
속성유형설명

legend

string

이 차트에 표시되는 각 시계열에 적용되는 쿼리 범례입니다. 여러 시계열이 표시되면 각각을 구분하는 범례를 설정해야 합니다. {{ Label }} 형식으로 수행할 수 있습니다. 예를 들어 promQL 그룹이 ( Label1, Label2)의 sum(rate(rate($METRIC[2m]))과 같은 레이블당 시계열을 그룹하는 경우 Label 1={{ Label1 }}, Label2={{ Label2 }} } 로 작성할 수 있습니다.

promQL

string

Prometheus에 대해 실행할 promQL 쿼리입니다. 차트 유형이 SingleStat 인 경우 이 쿼리는 단일 시계열만 반환해야 합니다. 다른 유형의 경우 상위 7이 표시됩니다. $METRIC 을 사용하여 이 리소스에 정의된 지표를 참조할 수 있습니다. 예: sum(rate($METRIC[2m])). promQL 에 대한 자세한 내용은 Prometheus 설명서를 참조하십시오. https://prometheus.io/docs/prometheus/latest/querying/basics/

top

integer

타임스탬프당 표시할 상위 N 시리즈입니다. SingleStat 차트 유형에는 적용되지 않습니다.

18.1.7. .spec.filters

설명
필터 는 고려되는 흐름을 제한하는 데 사용되는 필드 및 값 목록입니다. 사용 가능한 필드 목록에 대한 설명서를 참조하십시오. https://docs.redhat.com/en/documentation/openshift_container_platform/latest/html/network_observability/json-flows-format-reference.
유형
array

18.1.8. .spec.filters[]

설명
유형
object
필수 항목
  • field
  • matchType
Expand
속성유형설명

field

string

필터링할 필드의 이름입니다(예: SrcK8S_Namespace).

matchType

string

적용할 일치 유형

value

string

필터링할 값입니다. matchTypeEqual 또는 NotEqual 인 경우 $(SomeField) 와 함께 필드 삽입을 사용하여 흐름의 다른 필드를 참조할 수 있습니다.

19장. 네트워크 흐름 형식 참조

내부적으로 사용되고 Kafka로 흐름 데이터를 내보내는 데 사용되는 네트워크 흐름 형식의 사양을 검토합니다.

19.1. 네트워크 흐름 형식 참조.

이는 네트워크 흐름 형식의 사양입니다. 해당 형식은 Prometheus 지표 라벨뿐만 아니라 Loki 저장소의 내부적으로는 Kafka 내보내기가 구성된 경우 사용됩니다.

"Filter ID" 열에는 빠른 필터를 정의할 때 사용할 관련 이름이 표시됩니다( FlowCollector 사양의 spec.consolePlugin.quickFilters 참조).

"Loki 레이블" 열은 Loki를 직접 쿼리할 때 유용합니다. 레이블 필드는 스트림 선택기 를 사용하여 선택해야 합니다.

"Cardinality" 열은 이 필드가 FlowMetrics API를 사용하여 Prometheus 레이블로 사용되는 경우 임플리드 메트릭 카디널리티에 대한 정보를 제공합니다. 이 API 사용에 대한 자세한 내용은 FlowMetrics 설명서를 참조하십시오.

Expand
이름유형설명필터 IDLoki 레이블CardinalityOpenTelemetry

바이트

number

바이트 수

해당 없음

제공되지 않음

avoid

바이트

DnsErrno

number

DNS 추적기 ebpf 후크 함수에서 반환된 오류 번호

dns_errno

제공되지 않음

OK

dns.errno

DnsFlags

number

DNS 레코드의 DNS 플래그

해당 없음

제공되지 않음

OK

dns.flags

DnsFlagsResponseCode

string

구문 분석된 DNS 헤더 RCODEs 이름

dns_flag_response_code

제공되지 않음

OK

dns.responsecode

DnsId

number

DNS 레코드 ID

dns_id

제공되지 않음

avoid

dns.id

DnsLatencyMs

number

DNS 요청과 응답 사이의 시간(밀리초)

dns_latency

제공되지 않음

avoid

dns.latency

DnsName

string

DNS 쿼리 이름

dns_name

제공되지 않음

주의

해당 없음

Dscp

number

고유 서비스 코드 포인트 (DSCP) 값

dscp

제공되지 않음

OK

dscp

DstAddr

string

대상 IP 주소(ipv4 또는 ipv6)

dst_address

제공되지 않음

avoid

destination.address

DstK8S_HostIP

string

대상 노드 IP

dst_host_address

제공되지 않음

OK

destination.k8s.host.address

DstK8S_HostName

string

대상 노드 이름

dst_host_name

제공되지 않음

OK

destination.k8s.host.name

DstK8S_Name

string

Pod 이름, 서비스 이름 또는 노드 이름과 같은 대상 Kubernetes 오브젝트의 이름입니다.

dst_name

제공되지 않음

주의

destination.k8s.name

DstK8S_Namespace

string

대상 네임스페이스

dst_namespace

제공됨

OK

destination.k8s.namespace.name

DstK8S_NetworkName

string

대상 네트워크 이름

dst_network

제공되지 않음

OK

해당 없음

DstK8S_OwnerName

string

배포 이름, StatefulSet 이름 등과 같은 대상 소유자의 이름입니다.

dst_owner_name

제공됨

OK

destination.k8s.owner.name

DstK8S_OwnerType

string

Deployment, StatefulSet 등과 같은 대상 소유자의 종류입니다.

dst_kind

제공되지 않음

OK

destination.k8s.owner.kind

DstK8S_Type

string

Pod, 서비스 또는 노드와 같은 대상 Kubernetes 오브젝트의 종류입니다.

dst_kind

제공됨

OK

destination.k8s.kind

DstK8S_Zone

string

대상 가용성 영역

dst_zone

제공됨

OK

destination.zone

DstMac

string

대상 MAC 주소

dst_mac

제공되지 않음

avoid

destination.mac

DstPort

number

대상 포트

dst_port

제공되지 않음

주의

destination.port

DstSubnetLabel

string

대상 서브넷 레이블

dst_subnet_label

제공되지 않음

OK

destination.subnet.label

플래그

string[]

RFC-9293에 따라 흐름으로 구성된 TCP 플래그 목록과 다음 패키지별 조합을 나타내는 추가 사용자 정의 플래그:
- SYN_ACK
- FIN_ACK
- RST_ACK

tcp_flags

제공되지 않음

주의

tcp.flags

FlowDirection

number

흐름은 노드 관찰 지점에서 해석되는 방향입니다.
- 0: Ingress(노드 관찰 시점에서 들어오는 트래픽)
- 1: Egress(노드 관찰 지점의 트래픽 제외)
- 2단계(동일 소스 및 대상 노드가 있음) 중 하나일 수 있습니다.

node_direction

제공됨

OK

host.direction

IPSecStatus

string

커널 xfrm_output 함수에서 제공하는 IPsec 암호화의 상태) 또는 암호 해독 (xfrm_input을 통해 수신 시)

ipsec_status

제공되지 않음

OK

해당 없음

IcmpCode

number

ICMP 코드

icmp_code

제공되지 않음

OK

icmp.code

IcmpType

number

ICMP 유형

icmp_type

제공되지 않음

OK

icmp.type

IfDirections

number[]

네트워크 인터페이스 관찰 지점의 흐름 방향입니다.
- 0: Ingress(interface incoming traffic)
- 1: Egress(interface outgoing traffic) 중 하나일 수 있습니다.

ifdirections

제공되지 않음

OK

interface.directions

인터페이스

string[]

네트워크 인터페이스

인터페이스

제공되지 않음

주의

interface.names

K8S_ClusterName

string

클러스터 이름 또는 식별자

cluster_name

제공됨

OK

k8s.cluster.name

K8S_FlowLayer

string

흐름 계층: 'app' 또는 'infra'

flow_layer

제공됨

OK

k8s.layer

NetworkEvents

object[]

네트워크 이벤트(예: 네트워크 정책의 경우 "acl") - 유형(예: "관리자NetworkPolicy")
- 네임스페이스(예: 이벤트가 적용되는 경우 네임스페이스) -
- 작업(예: "허용" 또는 "검색") - 작업(예: "허용" 또는 "검색") - 작업(예: "허용" 또는 "검색") - 활동(예: "허용 또는 송신)



network_events

제공되지 않음

avoid

해당 없음

패킷

number

패킷 수

해당 없음

제공되지 않음

avoid

패킷

PktDropBytes

number

커널에 의해 삭제된 바이트 수

해당 없음

제공되지 않음

avoid

drops.bytes

PktDropLatestDropCause

string

최신 드롭 원인

pkt_drop_cause

제공되지 않음

OK

drops.latestcause

PktDropLatestFlags

number

마지막으로 삭제된 패킷의 TCP 플래그

해당 없음

제공되지 않음

OK

drops.latestflags

PktDropLatestState

string

마지막으로 삭제된 패킷의 TCP 상태

pkt_drop_state

제공되지 않음

OK

drops.lateststate

PktDropPackets

number

커널에 의해 삭제된 패킷 수

해당 없음

제공되지 않음

avoid

drops.packets

proto

number

L4 프로토콜

protocol

제공되지 않음

OK

protocol

sampling

number

이 흐름에 사용되는 샘플링 간격

해당 없음

제공되지 않음

OK

해당 없음

SrcAddr

string

소스 IP 주소(ipv4 또는 ipv6)

src_address

제공되지 않음

avoid

source.address

SrcK8S_HostIP

string

소스 노드 IP

src_host_address

제공되지 않음

OK

source.k8s.host.address

SrcK8S_HostName

string

소스 노드 이름

src_host_name

제공되지 않음

OK

source.k8s.host.name

SrcK8S_Name

string

Pod 이름, 서비스 이름 또는 노드 이름과 같은 소스 Kubernetes 오브젝트의 이름입니다.

src_name

제공되지 않음

주의

source.k8s.name

SrcK8S_Namespace

string

소스 네임스페이스

src_namespace

제공됨

OK

source.k8s.namespace.name

SrcK8S_NetworkName

string

소스 네트워크 이름

src_network

제공되지 않음

OK

해당 없음

SrcK8S_OwnerName

string

배포 이름, StatefulSet 이름 등과 같은 소스 소유자의 이름입니다.

src_owner_name

제공됨

OK

source.k8s.owner.name

SrcK8S_OwnerType

string

Deployment, StatefulSet 등과 같은 소스 소유자의 종류입니다.

src_kind

제공되지 않음

OK

source.k8s.owner.kind

SrcK8S_Type

string

Pod, 서비스 또는 노드와 같은 소스 Kubernetes 오브젝트의 종류입니다.

src_kind

제공됨

OK

source.k8s.kind

SrcK8S_Zone

string

소스 가용성 영역

src_zone

제공됨

OK

source.zone

SrcMac

string

소스 MAC 주소

src_mac

제공되지 않음

avoid

source.mac

SrcPort

number

소스 포트

src_port

제공되지 않음

주의

source.port

SrcSubnetLabel

string

소스 서브넷 레이블

src_subnet_label

제공되지 않음

OK

source.subnet.label

TimeFlowEndMs

number

이 흐름의 종료 타임스탬프(밀리초)

해당 없음

제공되지 않음

avoid

Timeflowend

TimeFlowRttNs

number

TCP Smoothed Round Trip Time (SRTT), 나노초

time_flow_rtt

제공되지 않음

avoid

tcp.rtt

TimeFlowStartMs

number

이 흐름의 타임스탬프 시작(밀리초)

해당 없음

제공되지 않음

avoid

timeflowstart

TimeReceived

number

흐름 수집기에서 이 흐름을 수신하고 처리하는 타임스탬프(초)

해당 없음

제공되지 않음

avoid

Timereceived

Udns

string[]

사용자 정의 네트워크 목록

udns

제공되지 않음

주의

해당 없음

XlatDstAddr

string

패킷 변환 대상 주소

xlat_dst_address

제공되지 않음

avoid

해당 없음

XlatDstPort

number

패킷 변환 대상 포트

xlat_dst_port

제공되지 않음

주의

해당 없음

XlatSrcAddr

string

패킷 변환 소스 주소

xlat_src_address

제공되지 않음

avoid

해당 없음

XlatSrcPort

number

패킷 변환 소스 포트

xlat_src_port

제공되지 않음

주의

해당 없음

ZoneId

number

패킷 변환 영역 ID

xlat_zone_id

제공되지 않음

avoid

해당 없음

_HashId

string

대화 추적에서 대화 식별자

id

제공되지 않음

avoid

해당 없음

_RecordType

string

레코드 유형: 일반 흐름 로그의 경우 flowLog, 또는 newConnection,하트비트, 대화 추적을 위한endConnection

type

제공됨

OK

해당 없음

20장. 네트워크 관찰 기능 문제 해결

Network Observability Operator 및 해당 구성 요소와 관련된 일반적인 문제를 해결하려면 진단 작업을 수행합니다.

20.1. must-gather 툴 사용

must-gather 툴을 사용하여 클러스터 문제 해결을 지원하기 위해 Pod 로그 및 구성 세부 정보를 포함하여 Network Observability Operator 리소스에 대한 진단 정보를 수집합니다.

프로세스

  1. must-gather 데이터를 저장하려는 디렉터리로 이동합니다.
  2. 다음 명령을 실행하여 클러스터 전체 must-gather 리소스를 수집합니다.

    $ oc adm must-gather
     --image-stream=openshift/must-gather \
     --image=quay.io/netobserv/must-gather

20.2. OpenShift Container Platform 콘솔에서 네트워크 트래픽 메뉴 항목 구성

FlowCollector 리소스 및 콘솔 운영자 구성에 콘솔 플러그인을 수동으로 등록하여 OpenShift Container Platform 콘솔의 Observe 메뉴에서 누락된 네트워크 트래픽 메뉴 항목을 복원합니다.

사전 요구 사항

  • OpenShift Container Platform 버전 4.10 이상이 설치되어 있어야 합니다.

프로세스

  1. 다음 명령을 실행하여 spec.consolePlugin.register 필드가 true 로 설정되어 있는지 확인합니다.

    $ oc -n netobserv get flowcollector cluster -o yaml

    출력 예

    apiVersion: flows.netobserv.io/v1alpha1
    kind: FlowCollector
    metadata:
      name: cluster
    spec:
      consolePlugin:
        register: false

  2. 선택 사항: Console Operator 구성을 수동으로 편집하여 netobserv-plugin 플러그인을 추가합니다.

    $ oc edit console.operator.openshift.io cluster

    출력 예

    ...
    spec:
      plugins:
      - netobserv-plugin
    ...

  3. 선택 사항: 다음 명령을 실행하여 spec.consolePlugin.register 필드를 true 로 설정합니다.

    $ oc -n netobserv edit flowcollector cluster -o yaml

    출력 예

    apiVersion: flows.netobserv.io/v1alpha1
    kind: FlowCollector
    metadata:
      name: cluster
    spec:
      consolePlugin:
        register: true

  4. 다음 명령을 실행하여 콘솔 Pod의 상태가 실행 중인지 확인합니다.

    $ oc get pods -n openshift-console -l app=console
  5. 다음 명령을 실행하여 콘솔 Pod를 다시 시작합니다.

    $ oc delete pods -n openshift-console -l app=console
  6. 브라우저 캐시 및 기록을 지웁니다.
  7. 다음 명령을 실행하여 네트워크 관찰 플러그인 Pod의 상태를 확인합니다.

    $ oc get pods -n netobserv -l app=netobserv-plugin

    출력 예

    NAME                                READY   STATUS    RESTARTS   AGE
    netobserv-plugin-68c7bbb9bb-b69q6   1/1     Running   0          21s

  8. 다음 명령을 실행하여 네트워크 관찰 플러그인 Pod의 로그를 확인합니다.

    $ oc logs -n netobserv -l app=netobserv-plugin

    출력 예

    time="2022-12-13T12:06:49Z" level=info msg="Starting netobserv-console-plugin [build version: , build date: 2022-10-21 15:15] at log level info" module=main
    time="2022-12-13T12:06:49Z" level=info msg="listening on https://:9001" module=server

흐름 수집기와 Kafka 배포 간의 연결을 복원하기 위해 flow-pipeline 포드를 수동으로 다시 시작하여 Kafka에서 네트워크 흐름을 사용하지 못하는 문제를 해결합니다.

deploymentModel: KAFKA 를 사용하여 흐름 수집기를 먼저 배포한 다음 Kafka를 배포한 경우 흐름 수집기가 Kafka에 올바르게 연결되지 않을 수 있습니다. Flowlogs-pipeline이 Kafka의 네트워크 흐름을 사용하지 않는 flow-pipeline Pod를 수동으로 다시 시작합니다.

프로세스

  1. 다음 명령을 실행하여 flow-pipeline 포드를 삭제하여 다시 시작합니다.

    $ oc delete pods -n netobserv -l app=flowlogs-pipeline-transformer

20.4. br-int 및 br-ex 인터페이스 모두에서 네트워크 흐름을 볼 수 없음

br-intbr-ex 와 같은 가상 브릿지 장치에 대한 인터페이스 제한을 제거하여 네트워크 흐름이 누락된 문제를 해결하여 eBPF 에이전트가 적절한 계층 3 인터페이스에 연결할 수 있도록 합니다.

br-exbr-int 는 OSI 계층 2에서 작동하는 가상 브릿지 장치입니다. eBPF 에이전트는 IP 및 TCP 수준, 계층 3 및 4에서 각각 작동합니다. eBPF 에이전트는 네트워크 트래픽이 물리적 호스트 또는 가상 pod 인터페이스와 같은 다른 인터페이스에서 처리할 때 br-exbr-int 를 통과하는 네트워크 트래픽을 캡처할 수 있습니다. eBPF 에이전트 네트워크 인터페이스를 br-exbr-int 에만 연결하도록 제한하면 네트워크 흐름이 표시되지 않습니다.

인터페이스의 부분을 수동으로 제거하거나 네트워크 인터페이스를 br-intbr-ex 로 제한하는 Interfaces를 제외합니다.

프로세스

  1. 인터페이스 제거: ['br-int', 'br-ex' ] 필드. 이를 통해 에이전트는 모든 인터페이스에서 정보를 가져올 수 있습니다. 또는 Layer-3 인터페이스를 지정할 수 있습니다(예: eth0 ). 다음 명령을 실행합니다.

    $ oc edit -n netobserv flowcollector.yaml -o yaml

    출력 예

    apiVersion: flows.netobserv.io/v1alpha1
    kind: FlowCollector
    metadata:
      name: cluster
    spec:
      agent:
        type: EBPF
        ebpf:
          interfaces: [ 'br-int', 'br-ex' ] 
    1

    1
    네트워크 인터페이스를 지정합니다.

20.5. Network observability 컨트롤러 관리자 Pod가 메모리 부족

컨트롤러 관리자 Pod가 메모리가 부족하지 않도록 Subscription 오브젝트의 메모리 제한을 늘려 Network Observability Operator의 메모리 문제를 해결합니다.

Subscription 오브젝트에서 spec.config.resources.limits.memory 사양을 편집하여 Network Observability Operator의 메모리 제한을 늘릴 수 있습니다.

프로세스

  1. 웹 콘솔에서 EcosystemInstalled Operators로 이동합니다.
  2. 네트워크 관찰 기능을 클릭한 다음 서브스크립션 을 선택합니다.
  3. 작업 메뉴에서 서브스크립션 편집을 클릭합니다.

    1. 또는 CLI를 사용하여 다음 명령을 실행하여 Subscription 오브젝트에 대한 YAML 구성을 열 수 있습니다.

      $ oc edit subscription netobserv-operator -n openshift-netobserv-operator
  4. Subscription 오브젝트를 편집하여 config.resources.limits.memory 사양을 추가하고 메모리 요구 사항을 고려하여 값을 설정합니다. 리소스 고려 사항에 대한 자세한 내용은 추가 리소스를 참조하십시오.

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: netobserv-operator
      namespace: openshift-netobserv-operator
    spec:
      channel: stable
      config:
        resources:
          limits:
            memory: 800Mi     
    1
    
          requests:
            cpu: 100m
            memory: 100Mi
      installPlanApproval: Automatic
      name: netobserv-operator
      source: redhat-operators
      sourceNamespace: openshift-marketplace
      startingCSV: <network_observability_operator_latest_version> 
    2
    1
    예를 들어 메모리 제한을 800Mi 로 늘릴 수 있습니다.
    2
    이 값은 편집해서는 안 되지만 Operator의 최신 릴리스에 따라 변경됩니다.

20.6. Loki에 사용자 정의 쿼리 실행

명령줄 인터페이스를 사용하여 사용 가능한 레이블을 검색하거나 소스 네임스페이스와 같은 특정 기준으로 로그를 필터링하도록 사용자 정의 Loki 쿼리를 실행하여 네트워크 흐름 데이터의 문제를 해결합니다.

이 작업을 수행하는 방법에는 두 가지 예가 있습니다. 이 작업을 수행하는 방법은 <api_token>을 자신의 요구 사항에 따라 조정할 수 있습니다.

참고

이 예에서는 Network Observability Operator 및 Loki 배포에 netobserv 네임스페이스를 사용합니다. 또한 이 예제에서는 LokiStack이라는 이름이 loki 라고 가정합니다. 선택적으로 예제, 특히 -n netobserv 또는 loki-gateway URL을 적용하여 다른 네임스페이스 및 이름을 사용할 수 있습니다.

사전 요구 사항

  • Network Observability Operator에서 사용할 Loki Operator를 설치합니다.

프로세스

  1. 사용 가능한 모든 레이블을 가져오려면 다음 명령을 실행합니다.

    $ oc exec deployment/netobserv-plugin -n netobserv -- curl -G -s -H 'X-Scope-OrgID:network' -H 'Authorization: Bearer <api_token>' -k https://loki-gateway-http.netobserv.svc:8080/api/logs/v1/network/loki/api/v1/labels | jq
  2. 소스 네임스페이스인 my-namespace 에서 모든 흐름을 가져오려면 다음 명령을 실행합니다.

    $ oc exec deployment/netobserv-plugin -n netobserv -- curl -G -s -H 'X-Scope-OrgID:network' -H 'Authorization: Bearer <api_token>' -k https://loki-gateway-http.netobserv.svc:8080/api/logs/v1/network/loki/api/v1/query --data-urlencode 'query={SrcK8S_Namespace="my-namespace"}' | jq

20.7. Loki ResourceExhausted 오류 문제 해결

FlowCollector 리소스에서 batchSize 또는 Loki 구성의 최대 메시지 크기 설정을 조정하여 Loki ResourceExhausted 오류를 해결하여 흐름 데이터가 메모리 제한 내에 유지되도록 합니다.

network observability에서 전송한 네트워크 흐름 데이터가 구성된 최대 메시지 크기를 초과하면 Loki가 ResourceExhausted 오류를 반환할 수 있습니다. Red Hat Loki Operator를 사용하는 경우 이 최대 메시지 크기는 100MiB로 구성됩니다.

프로세스

  1. Ecosystem설치된 Operators 로 이동하여 프로젝트 드롭다운 메뉴에서 모든 프로젝트를 확인합니다.
  2. 제공된 API 목록에서 Network Observability Operator를 선택합니다.
  3. 흐름 수집기 를 클릭한 다음 YAML 보기 탭을 클릭합니다.

    1. Loki Operator를 사용하는 경우 spec.loki.batchSize 값이 98MiB를 초과하지 않는지 확인합니다.
    2. Grafana Loki와 같은 Red Hat Loki Operator와 다른 Loki 설치 방법을 사용하는 경우 grpc_server_max_recv_msg_size Loki 서버 설정이 FlowCollector 리소스 spec.loki.batchSize 값보다 높은지 확인합니다. 그렇지 않은 경우 grpc_server_max_recv_msg_size 값을 늘리거나 제한보다 낮도록 spec.loki.batchSize 값을 줄여야 합니다.
  4. FlowCollector 를 편집한 경우 저장을 클릭합니다.

20.8. Loki 빈 링 오류

Pod 상태를 확인하거나, 이전 영구 볼륨 클레임을 지우거나, 포드를 다시 시작하여 연결을 복원하고 네트워크 흐름이 올바르게 저장 및 표시되는지 확인하여 Loki "빈 링" 오류를 조사하고 해결합니다.

Loki "빈 링" 오류로 인해 flows가 Loki에 저장되지 않고 웹 콘솔에 표시되지 않습니다. 이 오류는 다양한 상황에서 발생할 수 있습니다. 이를 모두 해결하기 위한 단일 해결 방법이 존재하지 않습니다. Loki Pod에서 로그를 조사하고 LokiStack 이 정상이고 준비되었는지 확인하는 데 수행할 수 있는 몇 가지 작업이 있습니다.

이 오류가 관찰되는 몇 가지 상황은 다음과 같습니다.

  • LokiStack 을 제거하고 동일한 네임스페이스에 다시 설치한 후 이전 PVC가 제거되지 않으므로 이 오류가 발생할 수 있습니다.

    • 작업: LokiStack 을 다시 제거하여 PVC를 제거한 다음 LokiStack 을 다시 설치할 수 있습니다.
  • 인증서 교체 후 이 오류는 flowlogs-pipelineconsole-plugin Pod와의 통신을 방지할 수 있습니다.

    • 작업: Pod를 다시 시작하여 연결을 복원할 수 있습니다.

20.9. LokiStack 속도 제한 오류

Loki 속도 제한 오류를 해결하고 LokiStack 리소스를 업데이트하여 네트워크 관찰 기능 데이터 스트림에 대한 수집 속도 및 버스트 제한을 늘려 데이터 손실을 방지합니다.

Loki 테넌트에 배치된 속도 제한은 스트림 제한 초과(limit:xMB/sec)를 수집하는 동안 데이터 및 429 오류가 발생할 수 있습니다. 이 오류를 알리기 위해 경고를 설정하는 것이 좋습니다. 자세한 내용은 이 섹션의 추가 리소스의 "NetObserv 대시보드에 대한 Loki 속도 제한 경고 생성"을 참조하십시오.

다음 절차에 표시된 대로 perStreamRateLimitperStreamRateLimitBurst 사양을 사용하여 LokiStack CRD를 업데이트할 수 있습니다.

프로세스

  1. Ecosystem설치된 Operators 로 이동하여 프로젝트 드롭다운의 모든 프로젝트를 확인합니다.
  2. Loki Operator 를 찾고 LokiStack 탭을 선택합니다.
  3. YAML 보기를 사용하여 기존 LokiStack 인스턴스를 생성하거나 편집하여 perStreamRateLimitperStreamRateLimitBurst 사양을 추가합니다.

    apiVersion: loki.grafana.com/v1
    kind: LokiStack
    metadata:
      name: loki
      namespace: netobserv
    spec:
      limits:
        global:
          ingestion:
            perStreamRateLimit: 6        
    1
    
            perStreamRateLimitBurst: 30  
    2
    
      tenants:
        mode: openshift-network
      managementState: Managed
    1
    perStreamRateLimit 의 기본값은 3 입니다.
    2
    perStreamRateLimitBurst 의 기본값은 15 입니다.
  4. 저장을 클릭합니다.

검증

perStreamRateLimitperStreamRateLimitBurst 사양을 업데이트하면 클러스터 재시작의 pod가 429 rate-limit 오류가 더 이상 발생하지 않습니다.

20.10. 대규모 쿼리를 실행하면 Loki 오류가 발생합니다.

인덱싱된 필터를 사용하여 대규모 쿼리를 실행할 때 Loki 시간 초과 및 요청 오류를 완화하고, Prometheus를 긴 시간 범위로 사용하거나, 사용자 지정 메트릭을 생성하거나, Loki 및 FlowCollector 성능 설정을 조정하는 방법을 설명합니다.

긴 시간 동안 대규모 쿼리를 실행하는 경우 시간 초과 또는 미해결 요청과 같이 Loki 오류가 발생할 수 있습니다. 이 문제에 대한 완전한 해결 방법은 없지만 이를 완화하는 방법은 여러 가지가 있습니다.

쿼리를 조정하여 인덱싱된 필터를 추가합니다.
Loki 쿼리를 사용하면 인덱싱된 필드 또는 레이블이 모두 쿼리할 수 있습니다. 레이블에 필터가 포함된 쿼리는 더 나은 성능을 보입니다. 예를 들어 인덱싱된 필드가 아닌 특정 Pod를 쿼리하는 경우 해당 네임스페이스를 쿼리에 추가할 수 있습니다. 인덱싱된 필드 목록은 Loki 레이블 열에서 "네트워크 흐름 형식 참조"에서 확인할 수 있습니다.
Loki가 아닌 Prometheus를 쿼리하는 것이 좋습니다.
Prometheus는 대규모 시간 범위에서 쿼리하기 위해 Loki보다 더 적합합니다. 그러나 Loki 대신 Prometheus를 사용할 수 있는지 여부는 사용 사례에 따라 다릅니다. 예를 들어 Prometheus의 쿼리는 Loki보다 크며, 많은 시간 범위가 성능에 영향을 미치지 않습니다. 그러나 Prometheus 메트릭에는 Loki의 흐름 로그만큼 많은 정보가 포함되어 있지 않습니다. 네트워크 Observability OpenShift 웹 콘솔은 쿼리가 호환되는 경우 Loki를 통해 Prometheus를 자동으로 사용합니다. 그렇지 않으면 기본값은 Loki입니다. Prometheus에 대해 쿼리가 실행되지 않으면 일부 필터 또는 집계를 변경하여 전환을 수행할 수 있습니다. OpenShift 웹 콘솔에서 Prometheus를 강제로 사용할 수 있습니다. 호환되지 않는 쿼리가 실패할 때 오류 메시지가 표시되므로 쿼리가 호환되도록 변경할 레이블을 파악하는 데 도움이 될 수 있습니다. 예를 들어 리소스 또는 Pod 에서 소유자 로 필터 또는 집계를 변경합니다.
FlowMetrics API를 사용하여 자체 메트릭을 생성하는 것이 좋습니다.
필요한 데이터를 Prometheus 지표로 사용할 수 없는 경우 FlowMetrics API를 사용하여 자체 지표를 생성할 수 있습니다. 자세한 내용은 "FlowMetrics API 참조" 및 " FlowMetric API를 사용하여 사용자 정의 메트릭 구성"을 참조하십시오.
쿼리 성능을 개선하도록 Loki 구성

문제가 지속되면 Loki를 구성하여 쿼리 성능을 향상시킬 수 있습니다. 일부 옵션은 Loki에 사용한 설치 모드(Operator 및 LokiStack 사용, Monolithic 모드, Microservices 모드 등)에 따라 달라집니다.

Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 문서 정보

Legal Notice

Theme

© 2026 Red Hat
맨 위로 이동