네트워크 관찰성


OpenShift Container Platform 4.19

OpenShift 컨테이너 플랫폼에서 네트워크 관찰 연산자 구성 및 사용

초록

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

1장. 네트워크 관찰 운영자 릴리스 노트

Network Observability Operator의 새로운 기능, 개선 사항, 수정된 문제 및 알려진 문제를 검토합니다. 이 릴리스 노트에서는 최신 Operator 릴리스에서 변경 사항 및 보안 권고를 이해하는 데 도움이 되는 정보를 제공합니다.

네트워크 관찰 연산자를 통해 관리자는 OpenShift Container Platform 클러스터의 네트워크 트래픽 흐름을 관찰하고 분석할 수 있습니다.

이 릴리스 노트는 OpenShift 컨테이너 플랫폼의 네트워크 관찰 연산자 개발 과정을 추적합니다.

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장. 네트워크 관찰 운영자 릴리스 노트 보관소

2.1. 네트워크 관찰 운영자 릴리스 노트 보관소

이 릴리스 노트는 OpenShift 컨테이너 플랫폼의 네트워크 관찰 연산자에 대한 과거 개발 사항을 추적합니다. 이는 참고 목적으로만 사용됩니다.

네트워크 관찰 연산자를 통해 관리자는 OpenShift Container Platform 클러스터의 네트워크 트래픽 흐름을 관찰하고 분석할 수 있습니다.

2.1.1. 네트워크 관측 가능성 운영자 1.10.1 권고 사항

네트워크 관찰 가능성 운영자 1.10.1 릴리스에 대한 권고 사항을 검토할 수 있습니다.

2.1.2. 네트워크 관측 가능성 운영자 1.10.1 CVE

네트워크 관찰 가능성 운영자 1.10.1 릴리스의 CVE를 검토할 수 있습니다.

2.1.3. 네트워크 관측 가능성 운영자 1.10.1 버전에서 수정된 문제점들

네트워크 관찰 가능성 운영자 1.10.1 릴리스에는 성능 및 사용자 경험을 개선하는 여러 수정 사항이 포함되어 있습니다.

15개 이상의 노드로 구성된 클러스터에서 직접 모드를 사용할 때 경고가 발생했습니다.

이번 업데이트 이전에는 대규모 클러스터에서 직접 배포 모델을 사용하지 말라는 권장 사항은 문서에서만 확인할 수 있었습니다.

이번 릴리스를 통해 네트워크 관찰 가능성 운영자는 15개 이상의 노드로 구성된 클러스터에서 직접 배포 모드를 사용할 경우 경고를 생성합니다.

NETOBSERV-2460

OpenShiftSDN에서 네트워크 정책 배포가 비활성화되었습니다.

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

이번 릴리스부터 네트워크 관찰 가능성 운영자는 OpenShift SDN이 감지될 때 더 이상 네트워크 정책을 배포하려고 시도하지 않고 대신 경고를 표시합니다. 또한 네트워크 정책 활성화의 기본값이 수정되었습니다. 이제 OVN-Kubernetes가 클러스터 네트워크 플러그인으로 감지된 경우에만 기본적으로 활성화됩니다.

(NETOBSERV-980)

서브넷 레이블 문자에 대한 유효성 검사가 추가되었습니다.

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

이번 릴리스에서는 FlowCollector 사용자 지정 리소스에 서브넷 레이블 이름을 구성할 때 즉시 유효성 검사가 수행됩니다. 유효성 검사를 통해 이름에 영숫자, 콜론( :), 밑줄( _) , 하이픈 (-) 만 포함되어 있는지 확인합니다. 그 결과, 웹 콘솔 플러그인에서 서브넷 레이블을 기준으로 필터링하는 기능이 이제 예상대로 작동합니다.

넷옵서브-2438

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

이번 업데이트 이전에는 네트워크 관찰 가능성 CLI가 현재 작업 디렉터리에 하나의 임시( tmp ) 디렉터리를 생성하거나 재사용했습니다. 이로 인해 서로 다른 실행 간에 충돌이나 데이터 손상이 발생할 수 있습니다.

이번 릴리스를 통해 네트워크 관찰 가능성 CLI는 실행할 때마다 고유한 임시 디렉터리를 생성하여 잠재적인 충돌을 방지하고 파일 관리의 효율성을 향상시켰습니다.

넷옵서브-2481

2.1.4. 네트워크 관찰성 운영자 1.10 권고

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

2.1.5. 네트워크 관찰 연산자 1.10의 새로운 기능 및 향상된 기능

Network Observability Operator 1.10 릴리스에서는 보안이 강화되고, 성능이 개선되었으며, 더 나은 네트워크 흐름 관리를 위한 새로운 CLI UI 도구가 도입되었습니다.

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

네트워크 관찰 운영자는 이제 포드 트래픽을 제어하기 위해 유입 및 유출 네트워크 정책을 모두 구성할 수 있습니다. 이러한 개선으로 보안이 강화되었습니다.

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

2.1.5.2. 네트워크 관찰성 운영자 CLI UI 업데이트

이 릴리스에서는 네트워크 관찰 운영자 CLI( oc netobserv ) 사용자 인터페이스(UI)에 다음과 같은 새로운 기능과 업데이트가 추가되었습니다.

테이블 뷰 개선

  • 사용자 정의 가능한 열: 열 관리를 클릭하여 표시할 열을 선택하고 필요에 맞게 표를 맞춤 설정합니다.
  • 스마트 필터링: 라이브 필터에 자동 제안 기능이 추가되어 올바른 키와 값을 더 쉽게 선택할 수 있습니다.
  • 패킷 미리보기: 패킷을 캡처할 때 행을 클릭하면 pcap 콘텐츠를 직접 검사할 수 있습니다.

터미널 기반 선형 차트 개선

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

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

  • FlowCollector CR을 구성합니다.
  • 자원 발자국을 계산해 보세요.
  • 구성 경고나 높은 메트릭 카디널리티와 같은 문제가 증가했습니다.
2.1.5.4. 성능 개선

Network Observability Operator 1.10에서는 Operator의 성능과 메모리 사용량이 개선되었으며, 특히 대규모 클러스터에서 눈에 띄게 향상되었습니다.

2.1.6. 네트워크 관찰 연산자 1.10 기술 미리보기 기능

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

2.1.6.1. 네트워크 관찰 운영자 사용자 정의 알림(기술 미리 보기)

이 릴리스에서는 새로운 알림 기능과 사용자 정의 알림 구성이 도입되었습니다. 이러한 기능은 기술 미리 보기 기능이므로 명시적으로 활성화해야 합니다.

새로운 알림을 보려면 OpenShift Container Platform 웹 콘솔에서 관찰알림알림 규칙을 클릭합니다.

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. 네트워크 관찰 연산자 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. 이전 OpenShift Container Platform 버전과 eBPF 에이전트 호환성

네트워크 관찰 명령줄 인터페이스(CLI) 패킷 캡처 기능에 사용되는 eBPF 에이전트는 OpenShift Container Platform 버전 4.16 이하와 호환되지 않습니다.

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

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

(NETOBSERV-980)

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

결과적으로, 흐름 데이터는 flowlogs-pipeline 구성 요소에 의해 처리되지 않으며 네트워크 트래픽 대시 보드나 구성된 저장소(Loki)에 나타나지 않습니다. eBPF 에이전트 포드 로그는 수집기에 연결을 시도할 때 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.enable을 false 로 설정하여 Network Observability Operator 1.10의 FlowCollector 리소스에서 NetworkPolicy를 비활성화합니다.

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

(NETOBSERV-980)

2.1.9. Network Observability Operator 1.10에서 수정된 문제

Network Observability Operator 1.10 릴리스에는 성능과 사용자 경험을 개선하는 여러 가지 문제가 수정되었습니다.

2.1.9.1. MetricName 및 Remap 필드가 검증되었습니다.

이 업데이트 이전에는 사용자가 잘못된 메트릭 이름으로 FlowMetric 사용자 지정 리소스(CR)를 만들 수 있었습니다. FlowMetric CR이 성공적으로 생성되었지만 기본 메트릭은 사용자에게 오류 피드백을 제공하지 않고 아무런 오류도 발생하지 않았습니다.

이번 릴리스에서는 FlowMetric , metricNameremap 필드가 생성 전에 검증되므로 사용자가 잘못된 이름을 입력하면 즉시 알림을 받게 됩니다.

(NETOBSERV-980)

2.1.9.2. HTML-이미지 내보내기 성능 향상

이 업데이트 이전에는 기본 라이브러리의 성능 문제로 인해 HTML을 이미지로 내보내는 기능에 시간이 오래 걸려 브라우저가 멈추는 현상이 발생했습니다.

이번 릴리스에서는 html-to-image 라이브러리의 성능이 개선되어 내보내기 대기 시간이 줄어들고 이미지 생성 중 브라우저가 멈추는 현상이 없어졌습니다.

(NETOBSERV-980)

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

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

이 릴리스에서는 구성에 일관성이 없는 경우 유효성 검사 후크가 사용자에게 즉시 경고합니다. 이를 통해 사용자의 이해를 높이고 잘못된 구성을 방지할 수 있습니다.

(NETOBSERV-980)

2.1.9.4. OpenTelemetry 내보내기에 서브넷 레이블이 추가되었습니다.

이 업데이트 이전에는 OpenTelemetry 메트릭 내보내기 도구에 네트워크 흐름 레이블인 SrcSubnetLabelDstSubnetLabel 이 없어서 비어 있는 것으로 표시되었습니다.

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

(NETOBSERV-980)

이 업데이트 이전에는 모든 네트워크 관찰 구성 요소에 기본 허용 범위가 설정되어 NoSchedule 로 오염된 노드를 포함하여 모든 노드에서 예약이 가능했습니다. 이로 인해 클러스터 업그레이드가 차단될 가능성이 있습니다.

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

또한, FlowCollector 사용자 정의 리소스(CR)에서 항상 허용 범위를 구성할 수 있었지만 이전에는 허용 범위를 빈 목록으로 바꾸는 것이 불가능했습니다. 이제 허용 범위를 빈 목록으로 바꿀 수 있습니다.

(NETOBSERV-980)

2.1.10. 네트워크 관찰성 운영자 1.9.3 권고

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

2.1.11. 네트워크 관찰 운영자 1.9.2 권고

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

2.1.12. 네트워크 관찰성 1.9.2 버그 수정

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

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

2.1.13. 네트워크 관찰성 운영자 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에서 흐름이 관찰됩니다. ( 네트옵서버-2333 )
  • 이 업데이트 이전에는 IPFIX 수집기가 다시 시작되면 IPFIX 내보내기를 구성하면 연결이 끊어지고 수집기로 네트워크 흐름 전송이 중단될 수 있었습니다. 이 릴리스에서는 연결이 복구되었으며 네트워크 흐름은 계속 수집기로 전송됩니다. ( NETOBSERV-2315 )
  • 이 업데이트 이전에는 IPFIX 내보내기를 구성할 때 포트 정보가 없는 흐름(예: ICMP 트래픽)이 무시되어 로그에 오류가 발생했습니다. IPFIX 내보내기에서 TCP 플래그와 ICMP 데이터도 누락되었습니다. 이번 릴리스에서는 이러한 세부 정보가 포함되었습니다. 누락된 필드(예: 포트)는 더 이상 오류를 발생시키지 않으며 내보낸 데이터의 일부입니다. (NETOBSERV-2307)
  • 이 업데이트 이전에는 사용자 정의 네트워크(UDN) 매핑 기능이 OpenShift Container Platform 4.18에서 구성 문제와 경고가 발생했는데, 이는 코드에서 OpenShift 버전이 잘못 설정되었기 때문입니다. 이는 사용자 경험에 영향을 미쳤습니다. 이 릴리스부터 UDN 매핑은 이제 경고 없이 OpenShift Container Platform 4.18을 지원하여 원활한 사용자 경험을 제공합니다. (NETOBSERV-2305)
  • 이 업데이트 이전에는 네트워크 트래픽 페이지의 확장 기능이 OpenShift Container Platform Console 4.19와 호환성 문제가 있었습니다. 이로 인해 확장 시 메뉴 공간이 비어 있고 사용자 인터페이스가 일관되지 않았습니다. 이번 릴리스에서는 NetflowTraffic 부분과 테마 후크 의 호환성 문제가 해결되었습니다. 네트워크 트래픽 보기의 사이드 메뉴가 이제 제대로 관리되어 사용자 인터페이스와의 상호 작용 방식이 개선되었습니다. (NETOBSERV-2304)

2.1.15. 네트워크 관찰성 운영자 1.9.0 권고

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

  • Network Observability Operator 1.3.0

2.1.16. Network Observability Operator 1.9.0의 새로운 기능 및 향상된 기능

Network Observability Operator 1.9.0 릴리스의 새로운 기능과 향상된 기능을 검토할 수 있습니다.

2.1.16.1. 네트워크 관찰이 가능한 사용자 정의 네트워크

이번 릴리스를 통해 user-defined networks (UDN) 기능이 Network Observability에서 일반적으로 사용 가능해졌습니다. 네트워크 관찰에서 UDNMapping 기능이 활성화되면 트래픽 흐름 테이블에 UDN 레이블 열이 생깁니다. 소스 네트워크 이름대상 네트워크 이름 정보에 대한 로그를 필터링할 수 있습니다.

2.1.16.2. 섭취 시 필터 플로우로그

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

  • eBPF 에이전트 필터
  • Flowlogs-파이프라인 필터
2.1.16.3. IPsec 지원

이 업데이트는 OpenShift Container Platform에서 IPsec이 활성화된 경우 네트워크 관찰성을 다음과 같이 향상시킵니다.

  • IPsec 상태 라는 새 열이 네트워크 관찰 트래픽 흐름 보기에 표시되어 흐름이 성공적으로 IPsec 암호화되었는지 또는 암호화/복호화 중에 오류가 발생했는지 여부를 보여줍니다.
  • 암호화된 트래픽의 비율을 보여주는 새로운 대시보드가 생성됩니다.
2.1.16.4. 네트워크 관찰 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에서만 사용할 수 있습니다. Network Observability 1.8 및 OpenShift Container Platform 4.18과 함께 이 기능을 사용하는 경우 Network Observability 업그레이드를 피하거나 Network Observability 1.9 및 OpenShift Container Platform을 4.19로 업그레이드하는 것이 좋습니다.
  • netobserv-reader 클러스터 역할의 이름이 netobserv-loki-reader 로 변경되었습니다.
  • eBPF 에이전트의 CPU 성능이 향상되었습니다.

2.1.18. 네트워크 관찰 연산자 1.9.0 기술 미리보기 기능

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

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

기술 프리뷰 기능 지원 범위

2.1.18.1. 네트워크 관찰이 가능한 eBPF 관리자 운영자

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

2.1.19. 네트워크 관찰성 운영자 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)
  • 이전에는 사용자가 콘솔 플러그인의 트래픽 흐름 보기에서 바이트 또는 패킷 별로 흐름을 정렬할 수 없었습니다. 이 업데이트를 통해 사용자는 BytesPackets 별로 흐름을 정렬할 수 있습니다. ( NETOBSERV-2239 )
  • 이전에는 IPFIX 내보내기 기능으로 FlowCollector 리소스를 구성할 때 IPFIX 흐름의 MAC 주소가 처음 2바이트로 잘렸습니다. 이 업데이트를 통해 MAC 주소가 IPFIX 흐름에 완전히 표현되었습니다. (NETOBSERV-2208)
  • 이전에는 Operator 검증 웹훅에서 보낸 일부 경고에 수행해야 할 작업에 대한 명확한 설명이 부족했습니다. 이번 업데이트를 통해 일부 메시지가 검토되고 수정되어 더욱 실행 가능하게 되었습니다. ( NETOBSERV-2178 )
  • 이전에는 FlowCollector 리소스에서 LokiStack을 참조할 때 입력 오류 등의 문제가 있는지 알아내는 것이 명확하지 않았습니다. 이 업데이트를 통해 FlowCollector 상태에서 해당 LokiStack을 찾을 수 없다는 사실이 명확하게 나타납니다. ( NETOBSERV-2174 )
  • 이전에는 콘솔 플러그인 트래픽 흐름 보기에서 텍스트 오버플로가 발생할 경우 텍스트 생략 부호로 인해 표시될 텍스트의 대부분이 가려지는 경우가 있었습니다. 이 업데이트를 통해 가능한 한 많은 텍스트를 표시합니다. ( 네트옵저브-2119 )
  • 이전에는 네트워크 관찰 기능 1.8.1 및 이전 버전의 콘솔 플러그인이 OpenShift Container Platform 4.19 웹 콘솔에서 작동하지 않아 네트워크 트래픽 페이지에 접근할 수 없었습니다. 이 업데이트를 통해 콘솔 플러그인이 호환되고 네트워크 트래픽 페이지에 네트워크 관찰 기능 1.9.0에서 접근할 수 있습니다. (NETOBSERV-2046)
  • 이전에는 대화 추적( FlowCollector 리소스의 logTypes: Conversations 또는 logTypes: All )을 사용할 때 대시보드에 표시되는 트래픽 비율 측정항목에 결함이 있어 트래픽이 통제 불능적으로 증가했다고 잘못 표시했습니다. 이제 측정항목에서 더 정확한 트래픽 비율을 보여줍니다. 그러나 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. 네트워크 관찰 운영자 1.8.1 권고

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

Network Observability Operator 1.8.1

2.1.23. 네트워크 관찰성 운영자 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 릴리스의 해결된 문제를 검토할 수 있습니다.

  • 이 수정을 통해 OpenShift Container Platform의 향후 버전에서는 관찰 메뉴가 한 번만 나타나도록 할 수 있습니다. (NETOBSERV-2139)

2.1.25. 네트워크 관찰성 운영자 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 에이전트에서 CPU 리소스가 40~57% 감소할 가능성이 있습니다.
2.1.26.4. 네트워크 관찰 CLI

이번 릴리스에서는 다음과 같은 새로운 기능, 옵션 및 필터가 Network Observability CLI에 추가되었습니다.

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

    • IP, 포트, 프로토콜, 작업, TCP 플래그 등에 대한 eBPF 필터
    • --node-selector를 사용한 사용자 정의 노드
    • --drops 만 사용하여 삭제합니다.
    • --regexes를 사용하는 모든 필드

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

2.1.27. Network Observability Operator 릴리스 노트 1.8.0 수정된 문제

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

  • 이전에는 네트워크 관찰 운영자가 메트릭 서버의 RBAC를 관리하기 위해 "kube-rbac-proxy" 컨테이너와 함께 제공되었습니다. 이 외부 구성 요소는 더 이상 사용되지 않으므로 제거해야 했습니다. 이제 사이드카 프록시가 필요 없이 Kubernetes 컨트롤러 런타임을 통한 직접적인 TLS 및 RBAC 관리로 대체되었습니다. (NETOBSERV-1999)
  • 이전에는 OpenShift Container Platform 콘솔 플러그인에서 여러 값과 같지 않은 키를 필터링해도 아무것도 필터링되지 않았습니다. 이 수정을 통해 예상한 결과, 즉 필터링된 값이 하나도 없는 모든 흐름이 반환됩니다. (NETOBSERV-1990)
  • 이전에는 Loki가 비활성화된 OpenShift Container Platform 콘솔 플러그인에서 호환되지 않는 필터 및 집계 집합을 선택하여 "쿼리를 작성할 수 없습니다" 오류가 발생할 가능성이 매우 컸습니다. 이제 사용자에게 필터 비호환성을 알리는 동시에 호환되지 않는 필터를 자동으로 비활성화하여 이러한 오류를 방지할 수 있습니다. (NETOBSERV-1977)
  • 이전에는 콘솔 플러그인에서 흐름 세부 정보를 볼 때 ICMP 정보가 항상 측면 패널에 표시되어 ICMP가 아닌 흐름에 대한 "정의되지 않음" 값이 표시되었습니다. 이 수정 사항을 적용하면 ICMP가 아닌 흐름에 대한 ICMP 정보가 표시되지 않습니다. (NETOBSERV-1969)
  • 이전에는 트래픽 흐름 보기의 "데이터 내보내기" 링크가 의도한 대로 작동하지 않아 빈 CSV 보고서가 생성되었습니다. 이제 내보내기 기능이 복구되어 비어 있지 않은 CSV 데이터가 생성됩니다. (NETOBSERV-1958)
  • 이전에는 loki.enable을 false 로 설정하여 process.logTypes Conversations , EndedConversations 또는 AllFlowCollector를 구성할 수 있었지만, 대화 로그는 Loki가 활성화된 경우에만 유용했습니다. 이로 인해 자원 낭비가 발생했습니다. 현재 이 구성은 유효하지 않으며 검증 웹훅에서 거부됩니다. (NETOBSERV-1957)
  • Processor.logTypes를 All 로 설정하여 FlowCollector를 구성하면 다른 옵션보다 CPU, 메모리, 네트워크 대역폭 등의 리소스가 훨씬 더 많이 소모됩니다. 이런 사실은 이전에는 기록되지 않았습니다. 이 문제는 이제 문서화되었으며, 검증 웹훅에서 경고가 발생합니다. (NETOBSERV-1956)
  • 이전에는 높은 스트레스 상황에서 eBPF 에이전트가 생성한 일부 흐름이 실수로 무시되어 트래픽 대역폭이 과소평가되는 경우가 있었습니다. 이제 생성된 흐름은 해제되지 않습니다. (NETOBSERV-1954)
  • 이전에는 FlowCollector 구성에서 네트워크 정책을 활성화하면 Operator 웹훅에 대한 트래픽이 차단되어 FlowMetrics API 유효성 검사가 중단되었습니다. 이제 웹후크에 대한 트래픽이 허용됩니다. (NETOBSERV-1934)
  • 이전에는 기본 네트워크 정책을 배포할 때 additionalNamespaces 필드에 openshift-consoleopenshift-monitoring 네임스페이스가 기본적으로 설정되어 중복된 규칙이 발생했습니다. 이제 기본적으로 추가 네임스페이스가 설정되지 않아 중복된 규칙을 방지하는 데 도움이 됩니다.( NETOBSERV-1933 )
  • 이전에는 OpenShift Container Platform 콘솔 플러그인에서 TCP 플래그를 필터링하면 원하는 플래그가 정확히 포함된 흐름만 일치했습니다. 이제 원하는 플래그 이상을 갖는 모든 흐름이 필터링된 흐름에 나타납니다. (NETOBSERV-1890)
  • eBPF 에이전트가 권한 모드에서 실행되고 포드가 지속적으로 추가되거나 삭제되면 파일 설명자(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. 네트워크 관찰성 운영자 1.7.0 권고

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

2.1.30. 네트워크 관찰 연산자 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 가상화를 위한 네트워크 관찰성

OVN(Open Virtual Network)-Kubernetes 등을 통해 보조 네트워크에 연결된 VM에서 나오는 eBPF가 강화된 네트워크 흐름을 식별하여 OpenShift 가상화 설정에서 네트워킹 패턴을 관찰할 수 있습니다.

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

이 릴리스를 사용하면 네트워크 관찰을 위한 네트워크 정책을 배포하도록 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) 필터링 규칙에 두 개의 포트를 사용할 수 있습니다.
  • 이제 프로토콜 필드를 비워두면 와일드카드 프로토콜을 사용하여 전송 포트를 필터링할 수 있습니다.

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

2.1.30.8. 네트워크 관찰 CLI

네트워크 관찰 CLI( oc netobserv )가 이제 일반적으로 사용 가능합니다. 1.6 Technology Preview 릴리스 이후 다음과 같은 개선 사항이 적용되었습니다.

  • 이제 패킷 캡처를 위한 플로우 캡처와 유사한 eBPF 강화 필터가 있습니다.
  • 이제 흐름과 패킷 캡처 모두에 필터 tcp_flags를 사용할 수 있습니다.
  • 자동 해제 옵션은 max-bytes 또는 max-time에 도달하면 사용할 수 있습니다.

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

2.1.31. Network Observability Operator 1.7.0에서 문제가 해결되었습니다.

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

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

2.1.32. 네트워크 관찰 연산자 1.7.0 알려진 문제

Network Observability Operator 1.7.0 릴리스에 대한 알려진 문제는 다음과 같습니다.

  • 네트워크 관찰 기능을 갖춘 must-gather 도구를 사용하는 경우 클러스터에 FIPS가 활성화되어 있으면 로그가 수집되지 않습니다. (NETOBSERV-1830)
  • FlowCollector 에서 spec.networkPolicy가 활성화되어 netobserv 네임스페이스에 네트워크 정책이 설치되면 FlowMetrics API를 사용할 수 없습니다. 네트워크 정책은 검증 웹훅에 대한 호출을 차단합니다. 해결 방법으로 다음 네트워크 정책을 사용하세요.

    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. 네트워크 관찰 운영자 릴리스 노트 1.6.2 권고

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

2.1.34. 네트워크 관찰 운영자 릴리스 노트 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 릴리스의 해결된 문제를 검토할 수 있습니다.

  • 2차 인터페이스 지원이 추가되었을 때, 인터페이스 알림에 대해 알아보기 위해 네트워크별 네임스페이스를 netlink에 등록하기 위해 여러 번 반복해야 할 필요가 있었습니다. 동시에, 실패한 핸들러로 인해 파일 기술자 누수가 발생했습니다. TCX 후크의 경우 TC와 달리 인터페이스가 다운되면 핸들러를 명시적으로 제거해야 했기 때문입니다. 이제 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. 네트워크 관찰 운영자 릴리스 노트 1.6.1 권고

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

2.1.38. 네트워크 관찰 운영자 릴리스 노트 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 보다 큰 값으로 구성된 경우, 손실된 바이트가 보고되고 손실된 패킷은 샘플링 구성을 무시합니다. 이는 한 방울도 놓치지 않기 위해 의도적으로 이루어졌지만, 부작용으로 보고된 방울의 비율과 방울이 없는 비율에 차이가 생겼습니다. 예를 들어, 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가 비활성화되면 단계별 실행 아이콘이 소유자 범위에 숨겨지므로 이 시나리오는 더 이상 발생하지 않습니다.( NETOBSERV-1721 ) (NETOBSERV-980)
  • 이전에는 Loki가 비활성화되었을 때 그룹이 설정되었지만 범위가 변경되어 그룹이 무효화되면 OpenShift 웹 콘솔의 토폴로지 보기에 오류가 표시되었습니다. 이 수정을 통해 잘못된 그룹이 제거되어 오류가 방지됩니다. (NETOBSERV-1722)
  • YAML 뷰 가 아닌 OpenShift 웹 콘솔 Form 뷰 에서 FlowCollector 리소스를 생성할 때, 다음 설정이 웹 콘솔에서 잘못 관리되었습니다: agent.ebpf.metrics.enableprocessor.subnetLabels.openShiftAutoDetect . 이러한 설정은 YAML 보기 에서만 비활성화할 수 있으며, Form 보기 에서는 비활성화할 수 없습니다. 혼란을 피하기 위해 이러한 설정은 양식 보기 에서 제거되었습니다. YAML 뷰 에서는 여전히 접근이 가능합니다. (NETOBSERV-1731)
  • 이전에는 eBPF 에이전트가 SIGTERM 신호로 인한 충돌 등 비정상적인 충돌이 발생하기 전에 설치된 트래픽 제어 흐름을 정리할 수 없었습니다. 이전 필터가 제거되지 않았기 때문에 동일한 이름을 가진 여러 개의 교통 제어 흐름 필터가 생성되었습니다. 이 수정 사항을 적용하면 에이전트가 시작될 때 새 트래픽 제어 흐름이 설치되기 전에 이전에 설치된 모든 트래픽 제어 흐름이 정리됩니다. (NETOBSERV-1732)
  • 이전에는 사용자 정의 서브넷 레이블을 구성하고 OpenShift 서브넷 자동 감지를 활성화한 경우 OpenShift 서브넷이 사용자 정의 서브넷보다 우선하여 클러스터 서브넷에서 사용자 정의 레이블을 정의할 수 없었습니다. 이 수정 사항을 적용하면 사용자 정의 서브넷이 우선적으로 적용되어 클러스터 서브넷에 대한 사용자 정의 레이블을 정의할 수 있습니다. (NETOBSERV-1734)

2.1.40. 네트워크 관찰 운영자 릴리스 노트 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 데이터는 Prometheus 레이블과 함께 사용하여 대시보드의 클러스터 정보를 사용자 지정할 수 있습니다. 흐름과 메트릭에서 식별하려는 모든 서브넷에 사용자 정의 레이블을 추가할 수 있습니다. 이러한 개선 사항은 흐름 로그와 메트릭 모두에 존재하는 새로운 레이블인 SrcSubnetLabelDstSubnetLabel 을 사용하여 외부 트래픽을 보다 쉽게 식별하는 데에도 사용할 수 있습니다. 이러한 필드는 외부 트래픽이 있을 때 비어 있으므로 이를 식별하는 방법이 제공됩니다.

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

2.1.41.3. eBPF 성능 향상

다음 업데이트를 통해 CPU와 메모리 측면에서 eBPF 에이전트의 성능이 향상되었습니다.

  • eBPF 에이전트는 이제 TC 대신 TCX 웹훅을 사용합니다.
  • NetObserv/Health 대시보드에 eBPF 지표를 보여주는 새로운 섹션이 추가되었습니다.

    • 새로운 eBPF 메트릭을 기반으로 eBPF 에이전트가 흐름을 삭제할 때 알림이 표시됩니다.
  • 중복된 흐름이 제거되었으므로 이제 로키 저장소 수요가 크게 감소합니다. 네트워크 인터페이스당 여러 개의 개별 중복된 흐름이 있는 대신, 관련 네트워크 인터페이스 목록이 있는 중복이 제거된 흐름이 하나 있습니다.
중요

복제된 흐름이 업데이트되면서 네트워크 트래픽 테이블의 InterfaceInterface Direction 필드의 이름이 InterfacesInterface Directions 로 바뀌었습니다. 따라서 이러한 필드를 사용하는 북마크된 빠른 필터 쿼리는 interfacesifdirections 로 업데이트해야 합니다.

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

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 생성을 위한 Operator Lifecycle Manager(OLM) 양식에 OpenShift Container Platform 설명서에 대한 끊어진 링크가 표시되었습니다. 이제 링크가 유효한 페이지를 가리키도록 업데이트되었습니다. (NETOBSERV-1607)
  • 이전에는 Operator Hub의 Network Observability Operator 설명에 설명서로 가는 링크가 끊어져 표시되었습니다. 이 수정을 통해 해당 링크가 복구되었습니다. (NETOBSERV-1544)
  • 이전에는 Loki가 비활성화되고 Loki 모드가 LokiStack 으로 설정되었거나 Loki 수동 TLS 구성이 구성된 경우에도 네트워크 관찰 운영자는 여전히 Loki CA 인증서를 읽으려고 시도했습니다. 이 수정 사항을 적용하면 Loki가 비활성화된 경우 Loki 구성에 설정이 있더라도 Loki 인증서가 읽히지 않습니다. (NETOBSERV-1647)
  • 이전에는 Network Observability Operator를 위한 oc must-gather 플러그인이 amd64 아키텍처에서만 작동했고 다른 모든 아키텍처에서는 실패했습니다. 그 이유는 해당 플러그인이 oc 바이너리에 amd64를 사용했기 때문입니다. 이제 Network Observability Operator oc must-gather 플러그인은 모든 아키텍처 플랫폼에서 로그를 수집합니다.
  • 이전에는 not equal to를 사용하여 IP 주소를 필터링할 때 네트워크 관찰 연산자가 요청 오류를 반환했습니다. 이제 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)
  • 개요 탭의 패널 관리 창에서 총계 , 막대형 , 도넛형 또는 선형을 필터링해도 결과가 표시되지 않습니다. (NETOBSERV-1540)
  • SR-IOV 보조 인터페이스는 인터페이스가 먼저 생성된 다음 eBPF 에이전트가 배포된 경우 감지되지 않습니다. 에이전트가 먼저 배포된 후 SR-IOV 인터페이스가 생성된 경우에만 감지됩니다. (NETOBSERV-1697)
  • Loki가 비활성화되어 있으면 OpenShift 웹 콘솔의 토폴로지 보기에서 네트워크 토폴로지 다이어그램 옆 슬라이더에 클러스터영역 집계 옵션이 항상 표시됩니다. 관련 기능이 활성화되어 있지 않은 경우에도 마찬가지입니다. 이러한 슬라이더 옵션을 무시하는 것 외에는 특별한 해결 방법이 없습니다. (NETOBSERV-1705)
  • Loki가 비활성화되어 있고 OpenShift 웹 콘솔이 처음 로드되면 "요청이 상태 코드 400으로 실패했습니다. Loki가 비활성화되었습니다 ."라는 오류가 표시될 수 있습니다. 해결 방법으로, 토폴로지개요 탭 사이를 클릭하는 등 네트워크 트래픽 페이지에서 콘텐츠를 계속 전환할 수 있습니다. 오류는 사라져야 합니다. (NETOBSERV-1706)

2.1.44. 네트워크 관찰성 운영자 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. 왕복 시간(RTT)

fentry/tcp_rcv_established 확장 버클리 패킷 필터(eBPF) 후크포인트에서 캡처한 TCP 핸드셰이크 왕복 시간(RTT)을 사용하여 평활화된 왕복 시간(SRTT)을 읽고 네트워크 흐름을 분석할 수 있습니다. 웹 콘솔의 개요 , 네트워크 트래픽토폴로지 페이지에서 네트워크 트래픽을 모니터링하고 RTT 메트릭, 필터링 및 에지 레이블링을 사용하여 문제를 해결할 수 있습니다.

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

2.1.45.3. 메트릭, 대시보드 및 알림 기능 향상

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

이러한 지표의 전체 목록은 다음을 참조하세요.

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

Loki를 사용하지 않더라도 DNS, 패킷 손실, 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. 성능 향상
  • Kafka를 사용할 때 eBPF 성능을 향상시키기 위해 spec.agent.ebpf.kafkaBatchSize 기본값이 10MB 에서 1MB 로 변경되었습니다.

    중요

    기존 설치에서 업그레이드하는 경우 이 새로운 값은 구성에 자동으로 설정되지 않습니다. 업그레이드 후 eBPF 에이전트 메모리 소비로 인한 성능 회귀를 모니터링하는 경우 kafkaBatchSize 를 새 값으로 줄이는 것을 고려할 수 있습니다.

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

    • 한 패널에 초점을 맞추는 동시에 다른 패널은 작게 초점을 맞춰서 볼 수 있도록 합니다.
    • 그래프 유형을 전환합니다.
    • 상위전체 보기.
  • 사용자 지정 시간 범위 창에 수집 지연 경고가 표시됩니다.
  • 패널 관리열 관리 팝업 창의 내용에 대한 가시성이 향상됩니다.
  • 송신 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 에이전트가 실행 중인 노드가 특정 클러스터 구성을 확인하지 못했습니다. 이로 인해 일부 트래픽 측정 항목을 제공하지 못하는 결과가 발생했습니다. 이 수정을 통해 eBPF 에이전트의 노드 IP가 포드 상태에서 추론되어 운영자에 의해 안전하게 제공됩니다. 이제 누락된 지표가 복원되었습니다. (NETOBSERV-1430)
  • 이전에는 Loki Operator의 '입력 크기가 너무 깁니다' 오류에 문제를 해결하기 위한 추가 정보가 포함되지 않았습니다. 이 수정 사항을 적용하면 오류 옆에 있는 웹 콘솔에 도움말이 직접 표시되고 자세한 안내를 위한 직접 링크가 제공됩니다. (NETOBSERV-1464)
  • 이전에는 콘솔 플러그인 읽기 시간 초과가 30초로 강제 적용되었습니다. FlowCollector v1beta2 API 업데이트를 사용하면 spec.loki.readTimeout 사양을 구성하여 Loki Operator queryTimeout 제한에 따라 이 값을 업데이트할 수 있습니다. (NETOBSERV-1443)
  • 이전에는 Operator 번들이 features.operators.openshift.io/… 와 같이 CSV 주석으로 지원되는 일부 기능을 예상대로 표시하지 않았습니다. 이번 수정을 통해 이러한 주석이 예상대로 CSV에 설정됩니다. (NETOBSERV-1305)
  • 이전에는 조정 중에 FlowCollector 상태가 가끔씩 DeploymentInProgressReady 상태 사이를 오가곤 했습니다. 이 수정 사항을 적용하면 모든 기본 구성 요소가 완전히 준비된 경우에만 상태가 준비로 변경됩니다. (NETOBSERV-1293)

2.1.47. Network Observability Operator 1.5.0 알려진 문제

Network Observability Operator 1.5 릴리스에 대한 알려진 문제는 다음과 같습니다.

  • 웹 콘솔에 접속하려고 할 때 OCP 4.14.10의 캐시 문제로 인해 Observe 뷰에 접속할 수 없습니다. 웹 콘솔에 다음 오류 메시지가 표시됩니다: /api/plugins/monitoring-plugin/에서 유효한 플러그인 매니페스트를 가져오지 못했습니다 . 권장되는 해결 방법은 클러스터를 최신 마이너 버전으로 업데이트하는 것입니다. 이 방법이 효과가 없으면 Red Hat Knowledgebase 문서 에 설명된 해결 방법을 적용해야 합니다.( NETOBSERV-1493 )
  • Network Observability Operator 1.3.0이 릴리스된 이후, Operator를 설치하면 커널 오염 경고가 나타납니다. 이 오류의 원인은 네트워크 관찰 eBPF 에이전트에 메모리 제약이 있어 해시맵 테이블 전체를 미리 할당할 수 없기 때문입니다. Operator eBPF 에이전트는 해시맵의 메모리가 너무 많이 필요할 때 사전 할당이 비활성화되도록 BPF_F_NO_PREALLOC 플래그를 설정합니다.

2.1.48. 네트워크 관찰 운영자 1.4.2 권고

다음 권고 사항은 Network Observability Operator 1.4.2에 대해 제공됩니다.

2.1.49. 네트워크 관찰성 운영자 1.4.2 CVE

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

2.1.50. 네트워크 관찰 운영자 1.4.1 권고

네트워크 관찰 운영자 1.4.1에 대한 다음 권고 사항을 검토할 수 있습니다.

2.1.51. 네트워크 관찰 운영자 릴리스 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에서는 동일한 노드에서 실행되는 포드 간의 흐름을 설명하기 위해 내부 흐름 방향이 도입되었습니다. 내부 방향의 흐름은 흐름에서 파생된 Prometheus 메트릭에서 고려되지 않아 바이트와 패킷 속도가 과소평가되었습니다. 이제 파생된 지표에는 내부 방향의 흐름이 포함되어 정확한 바이트와 패킷 속도를 제공합니다. (NETOBSERV-1344)

2.1.53. 네트워크 관찰성 릴리스 노트 1.4.0 권고

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

2.1.54. 네트워크 관찰성 릴리스 노트 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. 웹 콘솔 개선 사항:
  • 쿼리 옵션 에서 중복된 흐름을 표시할지 여부를 선택할 수 있는 중복된 흐름 확인란이 추가되었습니다.
  • 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 매개변수가 추가되어 클러스터 이름이 흐름 데이터에 나타납니다. 이는 다중 클러스터 컨텍스트에서 유용합니다. OpenShift Container Platform을 사용하는 경우, 자동으로 결정되도록 비워 두세요.

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

2.1.54.4. Loki 없이도 네트워크 관찰 가능

네트워크 관찰 연산자는 이제 Loki 없이도 작동하고 사용할 수 있습니다. Loki가 설치되지 않은 경우 KAFKA 또는 IPFIX 형식으로만 흐름을 내보내고 네트워크 관찰성 메트릭 대시보드에서 메트릭을 제공할 수 있습니다.

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

2.1.54.5. DNS 추적

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

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

2.1.54.6. SR-IOV 지원

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

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

2.1.54.7. IPFIX 수출 지원

이제 eBPF가 강화된 네트워크 흐름을 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 아키텍처 지원

네트워크 관찰 연산자는 이제 s390x 아키텍처에서 실행될 수 있습니다. 이전에는 amd64, ppc64le, arm64에서 실행되었습니다.

2.1.55. 네트워크 관찰성 릴리스 노트 1.4.0에서 제거된 기능

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

2.1.55.1. 채널 제거

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

2.1.56. 네트워크 관찰성 릴리스 노트 1.4.0 수정된 문제

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

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

2.1.57. 네트워크 관찰성 릴리스 노트 1.4.0 알려진 문제

Network Observability Operator 1.4.0 릴리스에서 알려진 문제는 다음과 같습니다.

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

2.1.58. 네트워크 관찰성 운영자 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에 저장된 흐름에 대한 개별 사용자 액세스 또는 그룹 액세스를 허용하고 제한할 수 있습니다. 자세한 내용은 "네트워크 관찰의 다중 테넌시"를 참조하세요.
2.1.59.2. 흐름 기반 메트릭 대시보드
  • 이 릴리스에서는 OpenShift Container Platform 클러스터의 네트워크 흐름에 대한 개요를 제공하는 새로운 대시보드가 추가되었습니다. 자세한 내용은 "네트워크 관찰성 지표 대시보드"를 참조하세요.
2.1.59.3. 필수 수집 도구를 사용한 문제 해결
  • 이제 네트워크 관찰 운영자에 대한 정보를 문제 해결을 위한 필수 수집 데이터에 포함할 수 있습니다. 자세한 내용은 "네트워크 관찰성 필수 수집"을 참조하세요.
2.1.59.4. 이제 여러 아키텍처가 지원됩니다.
  • Network Observability Operator는 이제 amd64, ppc64le, 또는 arm64 아키텍처에서 실행할 수 있습니다. 이전에는 amd64 에서만 실행되었습니다.

2.1.60. 네트워크 관찰 연산자 1.3.0 더 이상 사용되지 않는 기능

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

2.1.60.1. 채널 지원 중단

향후 운영자 업데이트를 받으려면 채널을 v1.0.x 에서 안정 버전 으로 전환해야 합니다. 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를 설치했을 때 클러스터 모니터링 Operator가 메트릭을 읽는 데 필요한 RoleRoleBinding이 예상대로 설치되지 않았습니다. 웹 콘솔에서 Operator를 설치할 때 문제가 발생하지 않았습니다. 이제, 어떤 방법으로 Operator를 설치하든 필요한 RoleRoleBinding이 설치됩니다. (NETOBSERV-1003)
  • 1.2 버전부터 네트워크 관찰 운영자는 흐름 수집에 문제가 발생하면 경고를 발생시킬 수 있습니다. 이전에는 버그로 인해 알림을 비활성화하는 관련 구성인 spec.processor.metrics.disableAlerts가 예상대로 작동하지 않았고 때로는 효과가 없었습니다. 이제 이 구성이 수정되어 알림을 비활성화할 수 있게 되었습니다. (NETOBSERV-976)
  • 이전에는 spec.loki.authToken을 DISABLED 로 설정하여 네트워크 관찰 기능을 구성한 경우 kubeadmin 클러스터 관리자만 네트워크 흐름을 볼 수 있었습니다. 다른 유형의 클러스터 관리자는 권한 부여 실패를 받았습니다. 이제 모든 클러스터 관리자가 네트워크 흐름을 볼 수 있습니다. (NETOBSERV-972)
  • 이전에는 버그로 인해 사용자가 spec.consolePlugin.portNaming.enable을 false 로 설정할 수 없었습니다. 이제 이 설정을 false 로 설정하여 포트-서비스 이름 변환을 비활성화할 수 있습니다. (NETOBSERV-971)
  • 이전에는 잘못된 구성으로 인해 콘솔 플러그인에서 노출된 메트릭이 클러스터 모니터링 운영자(Prometheus)에서 수집되지 않았습니다. 이제 구성이 수정되어 콘솔 플러그인 메트릭이 OpenShift Container Platform 웹 콘솔에서 올바르게 수집되고 액세스할 수 있습니다. (NETOBSERV-765)
  • 이전에는 FlowCollector 에서 processor.metrics.tls가 AUTO 로 설정된 경우 flowlogs-pipeline servicemonitor가 적절한 TLS 체계를 적용하지 않아 웹 콘솔에서 메트릭이 표시되지 않았습니다. 이제 AUTO 모드에 대한 문제가 해결되었습니다. (NETOBSERV-1070)
  • 이전에는 Kafka 및 Loki에 사용되는 인증서 구성에서 네임스페이스 필드를 지정할 수 없었기 때문에 인증서는 네트워크 관찰 기능이 배포된 동일한 네임스페이스에 있어야 했습니다. 게다가 TLS/mTLS와 함께 Kafka를 사용할 경우 사용자는 eBPF 에이전트 포드가 배포된 권한 있는 네임스페이스에 인증서를 수동으로 복사하고 인증서 로테이션과 같은 경우 인증서 업데이트를 수동으로 관리해야 했습니다. 이제 FlowCollector 리소스에 인증서에 대한 네임스페이스 필드를 추가하여 네트워크 관찰 설정이 간소화되었습니다. 결과적으로 사용자는 네트워크 관찰 네임스페이스에 인증서를 수동으로 복사하지 않고도 다른 네임스페이스에 Loki나 Kafka를 설치할 수 있습니다. 원본 증명서를 보관하여 필요할 때 사본을 자동으로 업데이트합니다. (NETOBSERV-773)
  • 이전에는 SCTP, ICMPv4 및 ICMPv6 프로토콜이 네트워크 관찰 에이전트에서 다루어지지 않아 네트워크 흐름에 대한 포괄적인 범위가 부족했습니다. 이러한 프로토콜은 이제 흐름 범위를 개선하는 데 도움이 되는 것으로 알려져 있습니다. (NETOBSERV-934)

2.1.62. 네트워크 관찰 연산자 1.3.0 알려진 문제

Network Observability Operator 1.3.0 릴리스와 관련된 문제를 해결하려면 다음 문제와 해결 방법(있는 경우)을 검토하세요.

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

향후 릴리스 및 업데이트를 계속 받으려면 Network Observability Operator의 업데이트 채널을 더 이상 사용되지 않는 v1.0.x 에서 안정적인 채널로 전환하세요.

설치된 운영자의 구독은 운영자에 대한 업데이트를 추적하고 수신하는 업데이트 채널을 지정합니다. Network Observability Operator가 1.2 버전으로 출시되기 전까지는 v1.0.x 채널만 사용할 수 있었습니다. 네트워크 관찰 연산자 1.2 릴리스에서는 업데이트를 추적하고 수신하기 위한 안정적인 업데이트 채널이 도입되었습니다. 향후 운영자 업데이트를 받으려면 채널을 v1.0.x 에서 안정 버전 으로 전환해야 합니다. v1.0.x 채널은 더 이상 사용되지 않으며 다음 릴리스에서 삭제될 예정입니다.

2.1.64. 네트워크 관찰성 운영자 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. 네트워크 관찰 상태 알림

이제 네트워크 관찰 연산자는 쓰기 단계에서 오류가 발생하거나 Loki 수집 속도 제한에 도달한 경우 flowlogs-pipeline에서 흐름이 삭제되는 경우 자동으로 알림을 생성합니다. 자세한 내용은 "상태 대시보드"를 참조하세요.

2.1.66. 네트워크 관찰 연산자 1.2.0 버그 수정

Network Observability Operator 1.2.0 릴리스에 대한 다음 해결된 문제를 확인할 수 있습니다.

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

2.1.67. Network Observability Operator 1.2.0 알려진 문제

Network Observability Operator 1.2.0 릴리스와 관련된 문제를 해결하려면 다음 문제와 해결 방법(있는 경우)을 검토하세요.

  • Network Observability Operator의 1.2.0 릴리스에서 Loki Operator 5.6을 사용하면 Loki 인증서 전환이 주기적으로 flowlogs-pipeline 포드에 영향을 미쳐 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 을 변경하는 변환 웹훅이 도입되었습니다. 이러한 변경으로 인해 사용 가능한 네임스페이스가 모두 나열되지 않습니다. 또한, 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. 네트워크 관찰 연산자 1.1.0 개선 사항

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

네트워크 관찰 연산자는 이제 안정적이며 릴리스 채널은 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장. 네트워크 관찰성에 관하여

네트워크 관찰 연산자를 사용하면 eBPF 기술을 통해 네트워크 트래픽을 관찰하고 Prometheus 메트릭과 Loki 로그를 통해 문제 해결에 대한 통찰력을 얻을 수 있습니다.

OpenShift Container Platform 콘솔에서 저장된 정보를 보고 분석하여 추가적인 통찰력을 얻고 문제를 해결할 수 있습니다.

3.1. Network Observability Operator

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

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

eBPF 에이전트는 데몬셋 객체로 배포되어 네트워크 흐름을 생성합니다. 파이프라인은 Loki에 저장하거나 Prometheus 메트릭을 생성하기 전에 Kubernetes 메타데이터로 네트워크 흐름을 수집하고 강화합니다.

3.2. 네트워크 관찰 연산자의 선택적 종속성

흐름 저장을 위한 Loki Operator 및 탄력적이고 대규모 데이터 처리 및 확장성을 위한 AMQ Streams(Kafka)와 같은 선택적 종속성을 사용하여 네트워크 관찰 가능성 연산자를 통합합니다.

지원되는 선택적 종속성에는 흐름 저장을 위한 Loki Operator와 Kafka를 통한 대규모 데이터 처리를 위한 AMQ Streams가 포함됩니다.

로키 오퍼레이터
Loki를 백엔드로 사용하면 수집된 모든 흐름을 최대한 세부적으로 저장할 수 있습니다. Loki를 설치하려면 Red Hat에서 지원하는 Loki Operator를 사용하는 것이 좋습니다. Loki 없이 네트워크 관찰 기능을 사용할 수도 있지만, 몇 가지 요소를 고려해야 합니다. 자세한 내용은 "Network Observability without Loki"를 참조하십시오.
AMQ 스트림 운영자

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

참고

Kafka를 사용하기로 선택한 경우 Red Hat에서 지원하는 AMQ Streams Operator를 사용하는 것이 좋습니다.

3.3. OpenShift 컨테이너 플랫폼 콘솔 통합

네트워크 관찰 가능성 운영자는 OpenShift 컨테이너 플랫폼 콘솔과 통합되어 개요, 토폴로지 보기 및 트래픽 흐름 테이블을 제공합니다.

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

참고

개발자 액세스와 네임스페이스에 대한 액세스가 제한된 관리자에게 다중 테넌시를 활성화하려면 역할을 정의하여 권한을 지정해야 합니다. 자세한 내용은 "네트워크 관찰에서 다중 테넌시 활성화"를 참조하세요.

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

OpenShift Container Platform 콘솔에서 네트워크 관찰 가능성 메트릭 대시보드를 검토해 보세요. 이 대시보드는 전반적인 트래픽 흐름 집계, 필터링 옵션, 그리고 운영자 상태 모니터링을 위한 전용 대시보드를 제공합니다.

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

Observe대시보드 에서 Netobserv 대시보드는 OpenShift Container Platform 클러스터의 네트워크 흐름에 대한 빠른 개요를 제공합니다. Netobserv/Health 대시보드는 운영자의 상태에 대한 측정 항목을 제공합니다. 자세한 내용은 "네트워크 관찰성 측정항목" 및 "상태 정보 보기"를 참조하세요.

3.3.2. 네트워크 관찰 토폴로지 뷰

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

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

3.3.3. 교통 흐름표

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

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

3.4. 네트워크 관찰 CLI

네트워크 관찰 가능성 CLI( oc netobserv )는 전체 네트워크 관찰 가능성 운영자 설치 없이도 네트워크 문제를 신속하게 실시간으로 파악할 수 있도록 흐름 및 패킷 데이터를 스트리밍하는 경량 도구입니다.

네트워크 관찰 CLI는 eBPF 에이전트를 사용하여 수집된 데이터를 임시 수집기 포드로 스트리밍하는 흐름 및 패킷 시각화 도구입니다. 캡처하는 동안 지속적인 저장이 필요하지 않습니다. 실행 후 출력이 로컬 컴퓨터로 전송됩니다. 이를 통해 네트워크 관찰 운영자를 설치하지 않고도 패킷과 흐름 데이터에 대한 빠르고 실시간 통찰력을 얻을 수 있습니다.

4장. 네트워크 관찰 연산자 설치

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

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

4.1. Loki 없이도 네트워크 관찰 가능

Loki Operator를 설치한 경우와 설치하지 않은 경우 네트워크 관찰 기능을 통해 사용할 수 있는 기능을 비교해 보세요.

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

Expand
표 4.1. Loki가 있는 경우와 없는 경우의 기능 가용성 비교
 로키와 함께로키 없이

내보내기

X

X

Multi-tenancy

X

X

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

X

 

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

X

X

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

X

X

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

X

X

교통 흐름 보기 표

X

 

Topology view

X

X

OpenShift 컨테이너 플랫폼 콘솔 네트워크 트래픽 탭 통합

X

X

  1. 예를 들어 포드당.
  2. 예를 들어, 워크로드나 네임스페이스별로.
  3. 패킷 드롭의 통계는 Loki에서만 사용할 수 있습니다.

4.2. Loki Operator 설치

네트워크 관찰을 위한 자동 클러스터 내 인증 및 권한 부여를 제공하는 안전한 LokiStack 인스턴스를 활성화하려면 소프트웨어 카탈로그에서 지원되는 Loki Operator 버전을 설치하세요.

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 웹 콘솔에서 OperatorOperatorHub를 클릭합니다.
  2. 사용 가능한 Operator 목록에서 Loki Operator를 선택하고 설치를 클릭합니다.
  3. 설치 모드에서 클러스터의 모든 네임스페이스를 선택합니다.

검증

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

Loki를 제거하려면 Loki를 설치하는 데 사용한 방법에 해당하는 제거 프로세스를 참조하세요. 제거해야 할 ClusterRoleClusterRoleBinding , 객체 저장소에 저장된 데이터, 영구 볼륨이 남아 있을 수 있습니다.

4.2.1. 로키 저장소에 대한 비밀 만들기

Amazon Web Services(AWS)와 같은 클라우드 스토리지 자격 증명을 사용하여 비밀을 생성하면 Loki Operator가 로그 지속성에 필요한 개체 저장소에 액세스할 수 있습니다.

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 사용자 정의 리소스 생성

웹 콘솔이나 OpenShift CLI( oc )를 사용하여 LokiStack 사용자 정의 리소스를 배포하고, Loki 개체 스토리지에 대한 올바른 네임스페이스, 배포 크기 및 비밀 이름을 구성합니다.

LokiStack 사용자 정의 리소스(CR)를 배포하여 네임스페이스나 새 프로젝트를 만들 수 있습니다.

프로세스

  1. Operators설치된 Operators로 이동하여 프로젝트 드롭다운에서 모든 프로젝트를 확인합니다.
  2. Loki Operator를 찾으세요. 세부 정보의 제공된 API 아래에서 LokiStack을 선택합니다.
  3. LokiStack 만들기를 클릭합니다.
  4. 다음 필드가 Form View 또는 YAML View 에 지정되어 있는지 확인하세요.

    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. 클러스터 관리자 사용자 역할에 대한 새 그룹 만들기

중요

클러스터 관리자 사용자로서 여러 네임스페이스에 대한 애플리케이션 로그를 쿼리할 때 클러스터의 모든 네임스페이스의 문자 합계가 5120을 초과하면 Parse error: input size too long (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. 로키 사이즈
 1x.demo1x.extra-small1x.small1x.medium

데이터 전송

데모용으로만 사용 가능

100GB/일

500GB/day

2TB/day

초당 쿼리 수(QPS)

데모용으로만 사용 가능

200ms에서 1-25 QPS

200ms에서 25-50 QPS

200ms에서 25-75 QPS

복제 인자

없음

2

2

2

총 CPU 요청 수

없음

14 vCPUs

34 vCPUs

54 vCPUs

총 메모리 요청 수

없음

31Gi

67Gi

139Gi

총 디스크 요청 수

40Gi

430Gi

430Gi

590Gi

4.2.6. LokiStack 섭취 한도 및 상태 알림

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

참고

콘솔 플러그인이나 flowlogs-pipeline 로그에 Loki 오류가 표시되는 경우 수집 및 쿼리 제한을 업데이트하는 것이 좋습니다.

구성된 제한의 예는 다음과 같습니다.

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

이러한 설정에 대한 자세한 내용은 LokiStack API 참조를 확인하세요.

4.3. 네트워크 관찰 연산자 설치

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

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

중요

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

사전 요구 사항

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

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

프로세스

  1. OpenShift Container Platform 웹 콘솔에서 OperatorOperatorHub를 클릭합니다.
  2. OperatorHub 에서 사용 가능한 운영자 목록에서 Network Observability Operator를 선택하고 설치를 클릭합니다.
  3. 이 네임스페이스에서 운영자가 권장하는 클러스터 모니터링을 활성화하는 확인란을 선택합니다.
  4. Operators설치된 Operator로 이동합니다. 네트워크 관찰을 위한 제공된 API에서 Flow Collector 링크를 선택합니다.
  5. Network Observability FlowCollector 설정 마법사를 따르세요.
  6. 생성을 클릭합니다.

검증

이것이 성공했는지 확인하려면 Observe 로 이동하면 옵션에 네트워크 트래픽이 나열되어 있어야 합니다.

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

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>
  • 클러스터 전체에 액세스하려면 클러스터 관리자가 아닌 사용자에게 netobserv-loki-reader , cluster-monitoring-view , netobserv-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. 중요한 Flow Collector 구성 고려 사항

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

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

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

4.5.1. 삭제된 버전의 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.6. Kafka 설치(선택 사항)

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

Loki Operator와 Network Observability Operator를 설치한 것처럼 Operator Hub에서 Red Hat AMQ Streams 로 Kafka Operator를 설치할 수 있습니다. Kafka를 스토리지 옵션으로 구성하려면 "Kafka를 사용하여 FlowCollector 리소스 구성"을 참조하세요.

참고

Kafka를 제거하려면 설치에 사용한 방법에 해당하는 제거 프로세스를 참조하세요.

4.7. 네트워크 관찰 연산자 제거

OpenShift Container Platform 웹 콘솔 Operator Hub의 EcosystemInstalled Operators 영역에서 Network Observability Operator를 제거합니다.

프로세스

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

    1. 제공된 API 열에서 Network Observability Operator 옆에 있는 흐름 수집기 를 클릭합니다.
    2. 클러스터 의 옵션 메뉴 kebab 를 클릭하고 FlowCollector 삭제 를 선택합니다.
  2. 네트워크 관찰 연산자를 제거합니다.

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

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

      중요

      Loki Operator와 Kafka는 설치된 경우 그대로 유지되므로 별도로 제거해야 합니다. 또한, 개체 저장소에 남아 있는 데이터가 있을 수도 있고, 제거해야 하는 영구 볼륨이 있을 수도 있습니다.

5장. OpenShift 컨테이너 플랫폼의 네트워크 관찰 연산자

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

5.1. 상태 보기

`oc get` 명령어를 사용하여 FlowCollector 리소스 상태는 물론 eBPF 에이전트 , flowlogs-pipeline 및 콘솔 플러그인 Pod의 상태를 확인하여 네트워크 관찰 가능성 운영자의 작동 상태를 볼 수 있습니다.

네트워크 관찰 연산자는 Flow Collector API를 제공합니다. Flow Collector 리소스가 생성되면 Loki 로그 저장소에 네트워크 흐름을 생성하고 저장하기 위해 Pod와 서비스를 배포하고, OpenShift Container Platform 웹 콘솔에 대시보드, 메트릭 및 흐름을 표시합니다.

프로세스

  1. FlowCollector 의 상태를 보려면 다음 명령을 실행하세요.

    $ oc get flowcollector/cluster

    출력 예

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

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

    $ 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 Console을 위한 시각화 플러그인을 생성합니다.

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

    $ 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 포드는 노드의 네트워크 인터페이스를 모니터링하여 흐름을 가져와 flowlogs-pipeline 포드로 전송합니다.

  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. 네트워크 관찰성 연산자 아키텍처

FlowCollector 리소스가 eBPF 에이전트를 관리하는 방식을 자세히 검토하십시오. 이 에이전트는 플로우를 수집하고 보강하여 Loki에 저장하거나 Prometheus에 메트릭을 전송합니다.

네트워크 관찰 연산자는 FlowCollector API를 제공하는데, 이는 설치 시 인스턴스화되고 eBPF 에이전트 , flowlogs-pipelinenetobserv-plugin 구성 요소를 조정하도록 구성됩니다. 클러스터당 하나의 FlowCollector 만 지원됩니다.

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

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를 사용한 네트워크 관찰

5.3. 네트워크 관찰 운영자 상태 및 구성 보기

oc describe flowcollector/cluster 명령을 사용하여 네트워크 관찰 가능성 운영자의 현재 상태, 구성 세부 정보 및 생성된 리소스를 검사합니다.

프로세스

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

    $ oc describe flowcollector/cluster

6장. 네트워크 관찰 연산자 구성

클러스터 전체 FlowCollector API 리소스(클러스터)를 업데이트하여 네트워크 관찰 운영자를 구성하고 구성 요소 구성 및 흐름 수집 설정을 관리합니다.

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

6.1. FlowCollector 리소스 보기

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

프로세스

  1. 웹 콘솔에서 Operators설치된 Operators 로 이동합니다.
  2. NetObserv Operator 에 대한 제공된 API 제목 아래에서 Flow Collector를 선택합니다.
  3. 클러스터를 선택한 다음 YAML 탭을 선택합니다. 여기에서 FlowCollector 리소스를 수정하여 네트워크 관찰 연산자를 구성할 수 있습니다.

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. 웹 콘솔에서 Operators설치된 Operators 로 이동합니다.
  2. Network Observability Operator의 제공된 API 제목 아래에서 Flow Collector를 선택합니다.
  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의 Red Hat 빌드나 Prometheus와 같은 호환 가능한 OpenTelemetry 엔드포인트로 내보낼 수 있습니다.

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

사전 요구 사항

  • Kafka, IPFIX 또는 OpenTelemetry 수집기 엔드포인트는 Network Observability flowlogs-pipeline pod에서 사용할 수 있습니다.

프로세스

  1. 웹 콘솔에서 Operators설치된 Operators 로 이동합니다.
  2. NetObserv Operator 에 대한 제공된 API 제목 아래에서 Flow Collector를 선택합니다.
  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 로 이름이 변경됩니다. "네트워크 흐름 형식 참조"에서 네트워크 관찰성과 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-파이프라인 필터

6.5.1. eBPF 에이전트 필터

eBPF 에이전트 필터는 네트워크 흐름 수집 프로세스의 가장 초기 단계에서 적용되므로 성능을 극대화합니다.

네트워크 관찰 연산자로 eBPF 에이전트 필터를 구성하려면 "여러 규칙을 사용하여 eBPF 흐름 데이터 필터링"을 참조하세요.

6.5.2. Flowlogs-파이프라인 필터

Flowlogs 파이프라인 필터는 네트워크 흐름 수집 프로세스에서 나중에 적용되므로 트래픽 선택에 대한 제어력이 더 뛰어납니다. 이는 주로 데이터 저장을 개선하는 데 사용됩니다.

Flowlogs 파이프라인 필터는 다음 예에서 볼 수 있듯이 간단한 쿼리 언어를 사용하여 네트워크 흐름을 필터링합니다.

(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-파이프라인 필터 예시

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 리소스 내에서 빠른 필터를 수정합니다.

값을 큰따옴표로 묶으면 정확한 일치가 가능합니다. 그렇지 않은 경우 텍스트 값에 대한 부분 일치가 사용됩니다. 키의 끝에 붙는 뱅(!) 문자는 부정을 의미합니다. YAML 수정에 대한 자세한 내용은 샘플 FlowCollector 리소스를 참조하십시오.

참고

"모두" 또는 "아무거나"와 일치하는 필터는 사용자가 쿼리 옵션에서 수정할 수 있는 UI 설정입니다. 이 리소스는 이 리소스 구성의 일부가 아닙니다.

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

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

네임스페이스

src_namespace

dst_namespace

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

name

src_name

dst_name

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

kind

src_kind

dst_kind

주어진 리소스 종류와 관련된 트래픽을 필터링합니다. 리소스 종류에는 리프 리소스(Pod, 서비스 또는 노드)나 소유자 리소스(배포 및 StatefulSet)가 포함됩니다.

owner_name

src_owner_name

dst_owner_name

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

resource

src_resource

dst_resource

정식 이름으로 표시되는 특정 리소스와 관련된 트래픽을 필터링하여 해당 리소스를 고유하게 식별합니다. 정식 표기법은 네임스페이스 종류의 경우 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

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

protocol

해당 없음

해당 없음

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

  • 모든 소스 및 대상에 대한 범용 키 필터링. 예를 들어, name: 'my-pod'를 필터링하는 것은 모든 트래픽의 모든 트래픽을 my-podmy-pod로의 Match all 또는 Match any를 의미합니다.

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

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

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

다음 설정은 처음부터 리소스와 성과를 관리하는 데 도움이 될 수 있습니다.

eBPF 샘플링
샘플링 사양인 spec.agent.ebpf.sampling 을 설정하여 리소스를 관리할 수 있습니다. 기본적으로 eBPF 샘플링은 50 으로 설정되어 있으므로 흐름이 샘플링될 확률은 50분의 1입니다. 샘플링 간격 값이 낮을수록 더 많은 계산, 메모리, 저장 리소스가 필요합니다. 0 또는 1 의 값은 모든 흐름이 샘플링됨을 의미합니다. 기본값으로 시작한 후 경험을 통해 값을 조정하여 클러스터에 가장 적합한 설정을 찾는 것이 좋습니다.
eBPF 기능
더 많은 기능을 활성화할수록 CPU와 메모리에 영향을 주는 양도 늘어납니다. 이러한 기능의 전체 목록은 "네트워크 트래픽 관찰"을 참조하세요.
로키 없이
Loki를 사용하지 않고 대신 Prometheus를 사용하면 네트워크 관찰에 필요한 리소스 양을 줄일 수 있습니다. 예를 들어, Loki 없이 네트워크 관찰 기능을 구성하면 메모리 사용량을 총 20~65% 절감할 수 있으며, 샘플링 간격 값에 따라 CPU 사용률은 10~30% 낮아집니다. 자세한 내용은 "Network Observability without Loki"를 참조하십시오.
인터페이스 제한 또는 제외
spec.agent.ebpf.interfacesspec.agent.ebpf.excludeInterfaces 에 대한 값을 설정하여 관찰된 전체 트래픽을 줄입니다. 기본적으로 에이전트는 excludeInterfaceslo (로컬 인터페이스)에 나열된 인터페이스를 제외한 시스템의 모든 인터페이스를 가져옵니다. 인터페이스 이름은 사용되는 컨테이너 네트워크 인터페이스(CNI)에 따라 다를 수 있습니다.
성능 미세 조정

다음 설정은 네트워크 관찰 기능을 일정 시간 동안 실행한 후 성능을 미세 조정하는 데 사용할 수 있습니다.

  • 리소스 요구 사항 및 제한 사항 : spec.agent.ebpf.resourcesspec.processor.resources 사양을 사용하여 클러스터에서 예상되는 부하와 메모리 사용량에 맞게 리소스 요구 사항 및 제한 사항을 조정합니다. 대부분의 중간 규모 클러스터에는 기본 제한인 800MB가 충분할 수 있습니다.
  • 캐시 최대 흐름 시간 초과 : 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 클러스터의 총 네임스페이스, 포드 및 서비스 수 외에도 높은 유입 트래픽 볼륨을 고려하고, eBPF 에이전트에 부하를 주며, 주어진 클러스터 크기에 대해 많은 작업 부하가 있는 사용 사례를 나타냅니다. 예를 들어, 테스트 1은 76개의 네임스페이스, 5,153개의 Pod, 2,305개의 서비스로 구성되며 네트워크 트래픽 규모는 약 350MB/s입니다.
  • 테스트 2에서는 OpenShift Container Platform 클러스터의 총 네임스페이스, 포드 및 서비스 수 외에도 높은 유입 트래픽 볼륨을 고려하고 주어진 클러스터 크기에 대해 많은 수의 워크로드가 있는 사용 사례를 나타냅니다. 예를 들어, 테스트 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

요약: 이 표는 모든 기능이 활성화된 에이전트, FLP, Kafka, Loki를 포함한 네트워크 관찰의 평균 총 리소스 사용량을 보여줍니다. 어떤 기능이 활성화되어 있는지에 대한 자세한 내용은 "네트워크 트래픽 관찰"에서 다루는 기능을 참조하세요. 여기에는 이 테스트에서 활성화된 모든 기능이 포함되어 있습니다.

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 네임스페이스에 대한 네트워크 정책을 만들 수 있습니다. 이 정책은 네트워크 관찰 운영자에 대한 인바운드 및 아웃바운드 액세스를 보호합니다.

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설치된 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. 개요 보기에 대한 고급 옵션 구성

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

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

  • 범위 : 네트워크 트래픽이 흐르는 구성 요소를 보려면 선택합니다. Node, Namespace, Owner, Zones, Cluster 또는 Resource로 리소스 범위를 설정할 수 있습니다. 소유자 는 리소스의 집합체입니다. 리소스는 호스트 네트워크 트래픽의 경우 포드, 서비스, 노드이거나 알 수 없는 IP 주소일 수 있습니다. 기본값은 Namespace 입니다.
  • 라벨 자르기 : 드롭다운 목록에서 라벨의 필요한 너비를 선택합니다. 기본값은 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) 조치 구현 등 네트워크 성능을 최적화하기 위한 조치를 취할 수 있습니다.

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

  • 상위 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(도메인 이름 시스템) 추적에 대한 그래픽 표현을 구성할 수 있습니다. 확장된 Berkeley Packet Filter(eBPF) 추적점 후크와 함께 DNS 추적을 사용하면 다양한 목적을 달성할 수 있습니다.

  • 네트워크 모니터링: DNS 쿼리와 응답에 대한 통찰력을 얻어 네트워크 관리자가 비정상적인 패턴, 잠재적 병목 현상 또는 성능 문제를 식별하는 데 도움이 됩니다.
  • 보안 분석: 맬웨어가 사용하는 도메인 이름 생성 알고리즘(DGA)과 같은 의심스러운 DNS 활동을 감지하거나 보안 위반을 나타낼 수 있는 승인되지 않은 DNS 확인을 식별합니다.
  • 문제 해결: DNS 확인 단계를 추적하고, 지연 시간을 추적하고, 잘못된 구성을 식별하여 DNS 관련 문제를 디버깅합니다.

기본적으로 DNS 추적이 활성화된 경우 개요 에서 도넛형 또는 선형 차트로 표현된 다음과 같은 비어 있지 않은 메트릭을 볼 수 있습니다.

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

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

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

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

이 보기를 활성화하고 사용하는 방법에 대한 자세한 내용은 이 섹션의 추가 리소스를 참조하세요.

10.1.5. 왕복 시간

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

TCP 평활화 왕복 시간(sRTT)을 사용하여 네트워크 흐름 지연을 분석할 수 있습니다. fentry/tcp_rcv_established eBPF 후크포인트에서 캡처한 RTT를 사용하여 TCP 소켓에서 sRTT를 읽어 다음 작업에 도움을 줄 수 있습니다.

  • 네트워크 모니터링: TCP 지연 시간에 대한 통찰력을 얻어 네트워크 관리자가 비정상적인 패턴, 잠재적 병목 현상 또는 성능 문제를 식별하는 데 도움을 줍니다.
  • 문제 해결: 지연 시간을 추적하고 잘못된 구성을 식별하여 TCP 관련 문제를 디버깅합니다.

기본적으로 RTT가 활성화된 경우 개요 에 다음과 같은 TCP RTT 메트릭이 표시됩니다.

  • 전체 TCP 왕복 시간 중 상위 X 90번째 백분위수
  • 전반적인 상위 X 평균 TCP 왕복 시간
  • 전체에 대한 최소 TCP 왕복 시간(최소 X)

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

  • 전체와 함께 상위 X 최대 TCP 왕복 시간
  • 전체 TCP 왕복 시간 중 상위 X 99번째 백분위수

이 보기를 활성화하고 사용하는 방법에 대한 자세한 내용은 이 섹션의 추가 리소스를 참조하세요.

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 흐름 필터링 기능을 활성화하려면 enable을 true 로 설정합니다.

cidr

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

작업

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

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

방향

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

protocol

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

tcpFlags

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

ports

흐름 필터링에 사용할 포트를 정의합니다. 출발지 포트나 목적지 포트에 모두 사용할 수 있습니다. 단일 포트를 필터링하려면 단일 포트를 정수 값으로 설정합니다. 예를 들어 포트: 80 . 포트 범위를 필터링하려면 문자열 형식의 "시작-끝" 범위를 사용하세요. 예를 들어 포트: "80-100"

sourcePorts

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

destPorts

DestPorts는 흐름 필터링에 사용할 대상 포트를 정의합니다. 단일 포트를 필터링하려면 단일 포트를 정수 값으로 설정합니다(예 : destPorts: 80 ). 포트 범위를 필터링하려면 문자열 형식의 "시작-끝" 범위를 사용하세요(예 : 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 플러그인을 사용하는 컨테이너 포드와 가상 머신의 기본 또는 보조 네트워크 역할을 합니다.

UDN은 광범위한 네트워크 아키텍처와 토폴로지를 지원하여 네트워크의 유연성, 보안, 성능을 향상시킵니다.

네트워크 관찰 기능과 함께 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. 웹 콘솔에서 Operators설치된 Operators 로 이동합니다.
  2. NetObserv Operator 에 대한 제공된 API 제목 아래에서 Flow Collector를 선택합니다.
  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 상태 라는 새 열이 네트워크 관찰 트래픽 흐름 보기에 표시되어 흐름이 성공적으로 IPsec 암호화되었는지 또는 암호화/복호화 중에 오류가 발생했는지 여부를 보여줍니다.
  • 암호화된 트래픽의 비율을 보여주는 새로운 대시보드가 생성됩니다.

10.2.5. 대화 추적 작업

웹 콘솔에서 관련 네트워크 흐름을 그룹화하고 분석하기 위한 대화 추적을 사용하도록 FlowCollector 사용자 지정 리소스를 구성합니다.

관리자는 동일한 대화에 속하는 네트워크 흐름을 그룹화할 수 있습니다. 대화는 IP 주소, 포트, 프로토콜로 식별되는 피어 그룹으로 정의되며, 고유한 대화 ID가 생성됩니다. 웹 콘솔에서 대화 이벤트를 쿼리할 수 있습니다. 이러한 이벤트는 웹 콘솔에서 다음과 같이 표시됩니다.

  • 대화 시작 : 이 이벤트는 연결이 시작되거나 TCP 플래그가 가로채질 때 발생합니다.
  • 대화 틱 : 이 이벤트는 연결이 활성화되어 있는 동안 FlowCollector spec.processor.conversationHeartbeatInterval 매개변수에 정의된 각 지정 간격에서 발생합니다.
  • 대화 종료 : 이 이벤트는 FlowCollector spec.processor.conversationEndTimeout 매개변수에 도달하거나 TCP 플래그가 가로채질 때 발생합니다.
  • 흐름: 지정된 간격 내에 발생하는 네트워크 트래픽 흐름입니다.

프로세스

  1. 웹 콘솔에서 Operators설치된 Operators 로 이동합니다.
  2. NetObserv Operator 에 대한 제공된 API 제목 아래에서 Flow Collector를 선택합니다.
  3. 클러스터를 선택한 다음 YAML 탭을 선택합니다.
  4. spec.processor.logTypes , conversationEndTimeout , conversationHeartbeatInterval 매개변수가 관찰 요구 사항에 맞게 설정되도록 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시 이후에 종료된 대화만 표시합니다.

  5. 트래픽 흐름 탭에서 네트워크 트래픽 페이지를 새로 고칩니다. 이벤트/유형대화 ID라는 두 개의 새로운 열이 있다는 점에 주목하세요. 흐름이 선택된 쿼리 옵션인 경우 모든 이벤트/유형 필드는 흐름 입니다.
  6. 쿼리 옵션을 선택하고 로그 유형 , 대화를 선택합니다. 이제 이벤트/유형에 원하는 대화 이벤트가 모두 표시됩니다.
  7. 다음으로, 측면 패널에서 특정 대화 ID로 필터링하거나 대화흐름 로그 유형 옵션 간에 전환할 수 있습니다.

10.2.6. 패킷 삭제 작업

웹 콘솔에서 네트워크 데이터 손실을 모니터링하고 시각화하도록 FlowCollector 리소스를 구성하여 Network Observability Operator에서 패킷 드롭 추적을 활성화합니다.

패킷 손실은 하나 이상의 네트워크 흐름 데이터 패킷이 목적지에 도달하지 못할 때 발생합니다. 다음 YAML 예제의 사양에 따라 FlowCollector를 편집하여 이러한 감소를 추적할 수 있습니다.

중요

이 기능을 활성화하면 CPU와 메모리 사용량이 증가합니다.

프로세스

  1. 웹 콘솔에서 Operators설치된 Operators 로 이동합니다.
  2. NetObserv Operator 에 대한 제공된 API 제목 아래에서 Flow Collector를 선택합니다.
  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를 추적할 수 있습니다.

중요

이 기능을 활성화하면 eBPF 에이전트에서 CPU 및 메모리 사용량이 증가하는 것이 관찰됩니다.

프로세스

  1. 웹 콘솔에서 Operators설치된 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

    • 웹 콘솔에서 각 네트워크 흐름의 DNS 추적을 활성화하려면 spec.agent.ebpf.features 매개변수 목록을 설정할 수 있습니다.
    • 더욱 정확한 측정 항목을 얻고 DNS 지연 시간을 파악하려면 샘플링 값을 1 로 설정할 수 있습니다. 1보다 큰 샘플링 값의 경우 DNS 응답 코드DNS Id 를 사용하여 흐름을 확인할 수 있으며 DNS Latency 시간을 확인할 수 없습니다.
  5. 네트워크 트래픽 페이지를 새로 고치면 개요트래픽 흐름 보기에서 볼 수 있는 새로운 DNS 표현과 적용할 수 있는 새로운 필터가 표시됩니다.

    1. 관리 패널 에서 새로운 DNS 선택 사항을 선택하여 개요 에 그래픽 시각화와 DNS 메트릭을 표시합니다.
    2. 트래픽 흐름 보기에 DNS 열을 추가하려면 열 관리 에서 새 선택 사항을 선택합니다.
    3. DNS ID , DNS 오류 DNS 대기 시간DNS 응답 코드 와 같은 특정 DNS 메트릭을 필터링하고 측면 패널에서 자세한 정보를 확인하세요. DNS 대기 시간DNS 응답 코드 열은 기본적으로 표시됩니다.

      참고

      TCP 핸드셰이크 패킷에는 DNS 헤더가 없습니다. DNS 헤더가 없는 TCP 프로토콜 흐름은 트래픽 흐름 데이터에 "n/a"의 DNS 대기 시간 , ID응답 코드 값으로 표시됩니다. 일반 필터 "DNSError"가 "0"인 경우 DNS 헤더가 있는 흐름만 보려면 흐름 데이터를 필터링할 수 있습니다.

10.2.8. RTT 추적 작업

웹 콘솔을 사용하여 클러스터 전체에서 네트워크 대기 시간을 모니터링하고 분석하도록 FlowCollector 사용자 지정 리소스를 구성하여 RTT(Round Trip Time) 추적을 활성화합니다.

다음 YAML 예제의 사양에 따라 FlowCollector를 편집하여 RTT를 추적할 수 있습니다.

프로세스

  1. 웹 콘솔에서 Operators설치된 Operators 로 이동합니다.
  2. NetObserv Operator 에 대한 제공된 API 제목에서 Flow Collector를 선택합니다.
  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 관리자 운영자와 함께 작업하기

eBPF Manager Operator를 Network Observability와 통합하여 eBPF 프로그램을 관리하고 권한 있는 에이전트 권한의 필요성을 줄입니다.

eBPF 관리자 운영자는 모든 eBPF 프로그램을 관리하여 공격 표면을 줄이고 규정 준수, 보안 및 충돌 방지를 보장합니다. 네트워크 관찰은 eBPF 관리자 연산자를 사용하여 후크를 로드할 수 있습니다. 결과적으로 더 이상 eBPF 에이전트에 권한 모드나 CAP_BPFCAP_PERFMON 과 같은 추가 Linux 기능을 제공할 필요가 없습니다. 네트워크 관찰 기능을 갖춘 eBPF 관리자 연산자는 64비트 AMD 아키텍처에서만 지원됩니다.

중요

네트워크 관찰 기능을 갖춘 eBPF 관리자 운영자는 기술 미리 보기 기능에 불과합니다. 기술 미리 보기 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

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

프로세스

  1. 웹 콘솔에서 운영자운영자 허브 로 이동합니다.
  2. eBPF 관리자를 설치합니다.
  3. bpfman 네임스페이스의 워크로드포드를 확인하여 모두 제대로 작동하고 있는지 확인합니다.
  4. eBPF Manager Operator를 사용하도록 FlowCollector 사용자 정의 리소스를 구성합니다.

    FlowCollector 구성 예

    apiVersion: flows.netobserv.io/v1beta2
    kind: FlowCollector
    metadata:
      name: cluster
    spec:
      agent:
        ebpf:
          features:
            - EbpfManager

검증

  1. 웹 콘솔에서 Operators설치된 Operators 로 이동합니다.
  2. eBPF 관리자 운영자모든 인스턴스 탭을 클릭합니다.

    각 노드에 대해 netobserv 라는 이름의 BpfApplication 과 트래픽 제어(TCx) 수신용과 TCx 송신용의 BpfProgram 객체 쌍이 있는지 확인합니다. 다른 eBPF 에이전트 기능을 활성화하면 더 많은 개체가 생길 수 있습니다.

10.2.10. 히스토그램을 사용하여

히스토그램은 트래픽 볼륨 추세를 분석하고 특정 시간 간격에 따라 흐름 데이터를 필터링하는 데 사용할 수 있는 네트워크 흐름 로그를 시각화합니다.

'히스토그램 표시'를 클릭하면 흐름 기록을 막대 차트로 시각화하는 도구 모음 보기가 표시됩니다. 히스토그램은 시간에 따른 로그 수를 보여줍니다. 도구 모음 다음에 나오는 표에서 네트워크 흐름 데이터를 필터링하려면 히스토그램의 일부를 선택할 수 있습니다.

10.2.11. 가용성 영역 작업

가용성 영역 데이터를 수집하도록 FlowCollector 사용자 지정 리소스를 구성하여 웹 콘솔의 여러 클러스터 영역에서 네트워크 트래픽을 시각화하고 분석할 수 있습니다.

FlowCollector를 구성하여 클러스터 가용성 영역에 대한 정보를 수집할 수 있습니다. 이를 통해 노드에 적용된 topology.kubernetes.io/zone 레이블 값으로 네트워크 흐름 데이터를 풍부하게 만들 수 있습니다.

프로세스

  1. 웹 콘솔에서 Operator설치된 Operator 로 이동합니다.
  2. NetObserv Operator 에 대한 제공된 API 제목 아래에서 Flow Collector를 선택합니다.
  3. 클러스터를 선택한 다음 YAML 탭을 선택합니다.
  4. FlowCollector 사용자 정의 리소스를 구성하여 spec.processor.addZone 매개변수가 true 로 설정되도록 합니다. 샘플 구성은 다음과 같습니다.

    가용성 영역 수집을 위해 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 접두사(가장 긴 접두사)가 있는 규칙이 우선합니다.

프로세스

  1. 웹 콘솔에서 Operators설치된 Operators 로 이동합니다.
  2. Network Observability에 대해 제공된 API에서 Flow Collector 를 선택합니다.
  3. 클러스터를 선택한 다음 YAML 탭을 선택합니다.
  4. FlowCollector 사용자 정의 리소스를 구성합니다.

10.2.13. eBPF 흐름 데이터 필터링 예

이러한 FlowCollector 사용자 지정 리소스 예제를 사용하여 eBPF 흐름을 필터링하여 eBPF 흐름 테이블에 캐시된 패킷의 흐름을 제어합니다.

10.2.13.1. 모든 남북 교통과 1:50 동서 교통을 샘플링하기 위한 YAML 예제

기본적으로 다른 모든 흐름은 거부됩니다.

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에 대한 가시성을 제공합니다.

네트워크 관찰 기능과 확장된 Berkeley Packet Filter(eBPF)를 사용하면 통합된 보기에서 트래픽을 처리하는 엔드포인트에 대한 가시성을 얻을 수 있습니다. 일반적으로 트래픽이 서비스, 출구 IP 또는 로드 밸런서를 통과할 때 트래픽 흐름 정보는 사용 가능한 포드 중 하나로 라우팅되면서 추상화됩니다. 트래픽에 대한 정보를 얻으려고 하면 서비스 IP 및 포트와 같은 서비스 관련 정보만 볼 수 있으며, 요청을 처리하는 특정 포드에 대한 정보는 볼 수 없습니다. 서비스 트래픽과 가상 서비스 엔드포인트에 대한 정보가 두 개의 별도 흐름으로 수집되는 경우가 많아 문제 해결이 복잡해집니다.

이 문제를 해결하기 위해 Endpoint xlat은 다음과 같은 방법으로 도움을 줄 수 있습니다.

  • 성능에 미치는 영향을 최소화하기 위해 커널 수준에서 네트워크 흐름을 캡처합니다.
  • 번역된 엔드포인트 정보로 네트워크 흐름을 풍부하게 하면 서비스뿐만 아니라 특정 백엔드 포드도 표시되므로 어떤 포드가 요청을 처리했는지 확인할 수 있습니다.

네트워크 패킷이 처리됨에 따라 eBPF 후크는 변환된 엔드포인트에 대한 메타데이터로 흐름 로그를 강화합니다. 여기에는 네트워크 트래픽 페이지에서 단일 행으로 볼 수 있는 다음 정보가 포함됩니다.

  • 소스 포드 IP
  • 소스 포트
  • 목적지 포드 IP
  • destination.port
  • Conntrack 존 ID

10.2.15. 엔드포인트 번역(xlat) 작업

FlowCollector 리소스에서 엔드포인트 변환(xlat)을 활성화하여 변환된 패킷 정보를 사용하여 네트워크 흐름을 강화합니다. 이 정보를 사용하여 전용 xlat 열을 통해 서비스 트래픽을 제공하는 특정 Pod 및 오브젝트를 식별할 수 있습니다.

네트워크 관찰성과 eBPF를 사용하면 번역된 엔드포인트 정보로 Kubernetes 서비스의 네트워크 흐름을 강화하고 트래픽을 처리하는 엔드포인트에 대한 통찰력을 얻을 수 있습니다.

프로세스

  1. 웹 콘솔에서 Operators설치된 Operators 로 이동합니다.
  2. NetObserv Operator 에 대한 제공된 API 제목에서 Flow Collector를 선택합니다.
  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_zone_id
      • Xlat Src Kubernetes 객체
      • Xlat Dst Kubernetes 객체
    3. 추가 xlat 열의 표시는 열 관리 에서 관리할 수 있습니다.

10.2.16. 사용자 정의 네트워크 작업

UDN(사용자 정의 네트워크) 매핑을 사용하도록 FlowCollector 사용자 정의 리소스를 구성하여 웹 콘솔 내의 사용자 지정 네트워크 인터페이스 간 트래픽을 시각화할 수 있습니다.

네트워크 관찰 리소스에서 사용자 정의 네트워크(UDN)를 활성화할 수 있습니다. 다음 예에서는 FlowCollector 리소스에 대한 구성을 보여줍니다.

사전 요구 사항

  • Red Hat OpenShift Networking에서 UDN을 구성했습니다. 자세한 내용은 "CLI를 사용하여 UserDefinedNetwork 만들기" 또는 "웹 콘솔을 사용하여 UserDefinedNetwork 만들기"를 참조하세요.

프로세스

  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
  • 사용자 정의 네트워크 격리
  • 멀티캐스트 ACL

사전 요구 사항

  • FeatureGate 사용자 정의 리소스(CR)의 cluster 라는 이름의 TechPreviewNoUpgrade 기능 세트를 설정하여 OVNObservability를 활성화해야 합니다. 자세한 내용은 "CLI를 사용하여 기능 세트 활성화" 및 "CLI를 사용하여 OVS 샘플링으로 OVN-Kubernetes 네트워크 트래픽 확인"을 참조하세요.
  • 다음 네트워크 API 중 하나 이상을 생성했습니다: NetworkPolicy , AdminNetworkPolicy , BaselineNetworkPolicy , UserDefinedNetwork isolation, multicast 또는 EgressFirewall .

프로세스

  1. 웹 콘솔에서 Operators설치된 Operators 로 이동합니다.
  2. NetObserv Operator 에 대한 제공된 API 제목에서 Flow Collector를 선택합니다.
  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. 다음 네트워크 API 중 하나가 활성화한 경우, 해당 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: 구성 요소를 그룹화하여 소유권에 대한 이해를 강화합니다. 기본값은 nil입니다.
    • 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 에이전트 기능이 필요합니다.
IPsec 오류
IPsec 암호화 오류가 감지되면 트리거됩니다. IPSec 에이전트 기능이 필요합니다.
NetpolDenied
네트워크 정책에서 거부된 트래픽이 감지될 때 트리거됩니다. NetworkEvents 에이전트 기능이 필요합니다.
LatencyHighTrend
TCP 대기 시간이 크게 증가할 때 트리거가 검색됩니다. FlowRTT 에이전트 기능이 필요합니다.
DNS 오류
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 표현식 및 메타데이터

Prometheus Query Language( PromQL )의 기본 쿼리에 대해 알아보고, 특정 요구 사항에 맞게 네트워크 관찰 알림을 구성할 수 있도록 사용자 정의하는 방법을 알아보세요.

네트워크 관찰 가능성 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 보다 큰 속도만 관찰되어 대역폭이 낮은 소비자의 노이즈가 제거됩니다.

(SrcK8S_Namespace="openshift-ingress"}[30m]의 합계 비율(netobserv_workload_ingress_bytes_total)) (DstK8S_Namespace) > 1000)

바이트 속도는 FlowCollector 사용자 정의 리소스( CR ) 구성에서 정의된 샘플링 간격을 기준으로 합니다. 샘플링 간격이 1:100 이면 실제 트래픽은 보고된 지표보다 약 100배 더 높을 수 있습니다.

시간 비교

오프셋 수정자를 사용하면 특정 기간 동안 동일한 쿼리를 실행할 수 있습니다. 예를 들어, 하루 전의 쿼리는 오프셋 1d를 사용하여 실행할 수 있고, 5시간 전의 쿼리는 오프셋 5h를 사용하여 실행할 수 있습니다.

sum(rate(netobserv_workload_ingress_bytes_total{SrcK8S_Namespace="openshift-ingress"}[30m] 오프셋 1d)) (DstK8S_Namespace))

100 * (<현재 쿼리> - <전날 쿼리>) / <전날 쿼리> 공식을 사용하면 전날 대비 증가율을 계산할 수 있습니다. 오늘의 바이트 속도가 전날보다 낮으면 이 값은 음수가 될 수 있습니다.

최종 임계값
원하는 백분율보다 낮은 증가를 필터링하기 위해 최종 임계값을 적용할 수 있습니다. 예를 들어, > 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. 알림 메타데이터 필드

네트워크 관찰 운영자는 모니터링 스택과 같은 다른 OpenShift 컨테이너 플랫폼 기능의 구성 요소를 사용하여 네트워크 트래픽에 대한 가시성을 향상시킵니다. 자세한 내용은 "스택 아키텍처 모니터링"을 참조하세요.

규칙 정의에 맞게 일부 메타데이터를 구성해야 합니다. 이 메타데이터는 모니터링 스택의 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 로 설정된 경우 네트워크 상태 대시 보드에서 감지할 알림을 지정합니다.
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 와 함께 제공되면 "소유자" 탭 아래에 경고가 표시됩니다.

임계값

문자열

PromQL 표현식에서 정의된 임계값과 일치해야 하는 경고 임계값입니다.

단위

문자열

표시 목적으로만 사용되는 데이터 단위입니다.

upperBound

문자열

폐쇄된 척도에서 점수를 계산하는 데 사용되는 상한값입니다. 이 경계를 초과하는 메트릭 값은 고정됩니다.

links

개체 목록.

알림과 함께 상황에 맞게 표시할 링크 목록입니다. 각 링크에는 이름 (표시 이름)과 URL이 필요합니다.

trafficLink

문자열

URL 빌드를 위한 네트워크 트래픽 페이지에 대한 링크와 관련된 정보입니다. 일부 필터는 노드 또는 네임스페이스 필터와 같이 자동으로 설정됩니다.

namespaceLabelsnodeLabels는 상호 배타적입니다. 둘 다 제공되지 않으면 알림은 글로벌 탭에 나타납니다.

Expand
표 11.2. trafficLink fields
필드설명

extraFilter

삽입할 추가 필터(예: DNS 관련 경고의 DNS 응답 코드)

backAndForth

필터에 반환 트래픽이 포함되어야 하는지 여부(true 또는 false).

filterDestination

필터에서 소스 대신 트래픽 대상을 대상으로 지정하는지 여부(true 또는 false).

11.3.2. 사용자 정의 상태 규칙 구성

Prometheus 쿼리 언어( PromQL )를 사용하여 특정 네트워크 측정항목(예: 트래픽 급증)에 따라 알림을 트리거하는 사용자 지정 AlertingRule 리소스를 정의합니다.

사전 요구 사항

  • PromQL 에 대한 지식.
  • OpenShift Container Platform 4.16 이상을 설치했습니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • 네트워크 관찰 연산자를 설치했습니다.

프로세스

  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 웹 콘솔의 네트워크 상태 대시보드를 확인하여 규칙이 활성화되었는지 확인합니다. → 관찰합니다 .

11.4. 사전 정의된 규칙 비활성화

FlowCollector CR(사용자 정의 리소스)의 spec.processor.metrics.disableAlerts 필드에서 규칙 템플릿을 비활성화할 수 있습니다. 이 설정은 규칙 템플릿 이름 목록을 허용합니다. 경고 템플릿 이름 목록은 "기본 규칙 목록"을 참조하십시오.

spec.processor.metrics.healthRules 필드에서 템플릿을 비활성화하고 재정의하는 경우 disable 설정이 우선하며 경고 규칙이 생성되지 않습니다.

12장. 대시보드 및 경고로 메트릭 사용

네트워크 관찰 연산자는 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_ 접두사가 붙은 네트워크 관찰 가능성 메트릭의 전체 목록을 검토하십시오.

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 역할이 있는 사용자 또는 모든 프로젝트에 대한 보기 권한이 있는 사용자로 클러스터에 액세스할 수 있습니다.
  • 네트워크 관찰 연산자가 설치되어 있습니다.

프로세스

  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를 사용하여 사용자 정의 메트릭 구성

FlowMetric API를 구성하여 특정 모니터링 요구 사항을 충족하도록 플로우 로그 필드를 레이블로 매핑함으로써 사용자 지정 Prometheus 메트릭을 생성할 수 있습니다.

프로세스

  1. 웹 콘솔에서 Operators설치된 Operators 로 이동합니다.
  2. NetObserv Operator 에 대한 제공된 API 제목에서 FlowMetric을 선택합니다.
  3. 프로젝트: 드롭다운 목록에서 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 은 높은 카디널리티 메트릭입니다.
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 관찰/ NetworkEvents 보기는 기술 미리 보기 기능에 불과합니다. 기술 미리 보기 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

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

중요

OVN 관찰 기능과 네트워크 이벤트를 보고 추적하는 기능은 OpenShift Container Platform 4.17 및 4.18에서만 사용할 수 있습니다.

다음 예는 네트워크 정책 이벤트에 대한 네트워크 이벤트 필드에서 메트릭을 생성하는 방법을 보여줍니다.

사전 요구 사항

  • NetworkEvents 기능을 활성화합니다. 이 작업을 수행하는 방법은 추가 리소스를 참조하십시오.
  • 네트워크 정책이 지정되었습니다.

프로세스

  1. 웹 콘솔에서 Operators설치된 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. 네트워크 정책 사양과 함께 생성한 메트릭을 기반으로 메트릭 필터링이 적용되는 것을 확인할 수 있습니다.

12.7. FlowMetric API를 사용하여 사용자 정의 차트 구성

FlowMetric 사용자 지정 리소스의 차트 섹션을 정의하여 OpenShift Container Platform 웹 콘솔 대시보드용 사용자 지정 차트를 생성합니다.

관리자는 대시보드 메뉴에서 사용자 지정 차트를 볼 수 있습니다.

프로세스

  1. 웹 콘솔에서 Operators설치된 Operators 로 이동합니다.
  2. NetObserv Operator 에 대한 제공된 API 제목에서 FlowMetric을 선택합니다.
  3. 프로젝트: 드롭다운 목록에서 Network Observability Operator 인스턴스의 프로젝트를 선택합니다.
  4. FlowMetric 만들기를 클릭합니다.
  5. FlowMetric 리소스를 구성합니다. "Flowmetric 차트 구성 예제"를 참조하십시오.

검증

  1. Pod가 새로 고쳐지면 모니터링대시보드 로 이동합니다.
  2. NetObserv/메인 대시 보드를 검색하세요. 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
대시보드 이름을 지정합니다. 다른 대시보드 이름을 사용하면 Netobserv 로 시작하는 새로운 대시보드가 생성됩니다. 예를 들어, Netobserv / <대시보드_이름> .
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
대시보드 이름을 지정합니다. 다른 대시보드 이름을 사용하면 Netobserv 로 시작하는 새로운 대시보드가 생성됩니다. 예를 들어, Netobserv / <대시보드_이름> .
12.7.1.3. 히스토그램 평균 계산

히스토그램을 생성할 때 자동으로 생성되는메트릭 $METRIC_sum을 메트릭 $METRIC_count로 나누어 히스토그램의 평균을 표시할 수 있습니다. 앞의 예에서 이를 수행하기 위한 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. 웹 콘솔에서 Operators설치된 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. SYN 플러딩에 대한 경고를 위해 다음 AlertingRule 리소스를 배포합니다.

    SYN 플러딩에 대한 경고 규칙

    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 입니다. 하지만 경험적으로 이 값을 조정할 수 있습니다. 임계값이 너무 낮으면 거짓 양성 결과가 나올 수 있고, 임계값이 너무 높으면 실제 공격을 놓칠 수 있습니다.

검증

  1. 웹 콘솔에서 네트워크 트래픽 테이블 보기의 열 관리를 클릭하고 TCP 플래그를 클릭합니다.
  2. 네트워크 트래픽 테이블 보기에서 TCP 프로토콜 SYN TCPFlag를 필터링합니다. 동일한 byteSize를 가진 많은 수의 흐름은 SYN 플러드를 나타냅니다.
  3. 모니터링경고로 이동하여 경고 규칙 탭을 선택합니다.
  4. netobserv-synflood-in 경고 에 대한 필터링. SYN 플러딩이 발생하면 경고가 실행됩니다.

13장. 네트워크 관찰성 운영자 모니터링

OpenShift Container Platform 웹 콘솔을 사용하여 네트워크 관찰 운영자의 상태와 관련된 알림을 모니터링합니다. 이를 통해 시스템 안정성을 유지하고 운영 문제를 신속하게 감지할 수 있습니다.

13.1. 건강 대시보드

OpenShift Container Platform 웹 콘솔에서 네트워크 관찰 가능성 운영자 상태 대시보드를 확인하여 운영자와 해당 구성 요소의 상태, 리소스 사용량 및 내부 통계를 모니터링할 수 있습니다.

메트릭은 OpenShift Container Platform 웹 콘솔의 관찰대시보드 페이지에서 확인할 수 있습니다. 네트워크 관찰 가능성 운영자의 상태에 대한 지표는 다음 범주에서 확인할 수 있습니다.

  • 초당 흐름
  • sampling:
  • 마지막 순간 오류 발생
  • 초당 감소된 흐름
  • Flowlogs-파이프라인 통계
  • Flowlogs-파이프라인 통계 뷰
  • eBPF 에이전트 통계 보기
  • 운영자 통계
  • 리소스 사용량

13.2. 건강 알림

Loki 데이터 수집 오류, 데이터 수집 없음 또는 eBPF 데이터 흐름 손실과 같은 상황이 발생할 때 배너를 표시하는 네트워크 관찰 가능성 운영자가 생성하는 상태 경고를 이해하십시오.

알림이 발생하면 대시보드로 이동하는 건강 알림 배너가 네트워크 트래픽홈페이지 에 나타날 수 있습니다. 다음과 같은 경우 알림이 생성됩니다.

  • NetObservLokiError 경고는 Loki 오류(예: Loki 수집 속도 제한에 도달한 경우)로 인해 flowlogs-pipeline 작업 부하가 흐름을 삭제하는 경우 발생합니다.
  • NetObservNoFlows 경고는 특정 시간 동안 흐름이 수집되지 않으면 발생합니다.
  • NetObservFlowsDropped 경고는 Network Observability eBPF 에이전트 해시맵 테이블이 가득 차고 eBPF 에이전트가 성능이 저하된 상태로 흐름을 처리하거나 용량 제한이 트리거되는 경우 발생합니다.

13.3. 건강 정보 보기

OpenShift Container Platform 웹 콘솔 내의 Netobserv/Health 대시보드를 통해 네트워크 관찰 가능성 운영자(Network Observability Operator) 및 해당 구성 요소의 상태와 리소스 사용량을 모니터링할 수 있습니다.

사전 요구 사항

  • 네트워크 관찰 연산자가 설치되어 있습니다.
  • cluster-admin 역할 또는 모든 프로젝트에 대한 보기 권한이 있는 사용자로 클러스터에 액세스할 수 있습니다.

프로세스

  1. 웹 콘솔의 관리자 관점에서 관찰대시보드 로 이동합니다.
  2. 대시보드 드롭다운에서 Netobserv/Health를 선택합니다.
  3. 페이지에 표시되는 운영자 상태에 대한 측정 항목을 확인하세요.

13.3.1. 건강 알림 비활성화

FlowCollector 리소스를 편집하고 spec.processor.metrics.disableAlerts 사양을 사용하여 NetObservLokiError 또는 NetObservNoFlows 와 같은 특정 상태 알림을 비활성화할 수 있습니다.

프로세스

  1. 웹 콘솔에서 Operators설치된 Operators 로 이동합니다.
  2. NetObserv Operator 에 대한 제공된 API 제목 아래에서 Flow Collector를 선택합니다.
  3. 클러스터를 선택한 다음 YAML 탭을 선택합니다.
  4. 다음 YAML 샘플과 같이 spec.processor.metrics.disableAlerts를 추가하여 상태 알림을 비활성화합니다.

    apiVersion: flows.netobserv.io/v1beta2
    kind: FlowCollector
    metadata:
      name: cluster
    spec:
      processor:
        metrics:
          disableAlerts: [NetObservLokiError, NetObservNoFlows]

    다음과 같습니다.

    spec.processor.metrics.disableAlerts
    비활성화할 경고 유형을 하나 이상 지정합니다.

13.4. NetObserv 대시보드에 대한 Loki 속도 제한 알림 생성

Loki 메트릭을 기반으로 하는 사용자 지정 AlertingRule 리소스를 생성하여 HTTP 429 오류로 표시되는 Loki 데이터 수집 속도 제한에 도달할 때 알림을 감지하고 트리거합니다.

Netobserv 대시보드 메트릭에 대한 사용자 정의 알림 규칙을 만들어 Loki 속도 제한에 도달했을 때 알림을 트리거할 수 있습니다.

사전 요구 사항

  • cluster-admin 역할이 있는 사용자 또는 모든 프로젝트에 대한 보기 권한이 있는 사용자로 클러스터에 액세스할 수 있습니다.
  • 네트워크 관찰 연산자가 설치되어 있습니다.

프로세스

  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 에이전트 알림 사용

eBPF 에이전트 해시맵이 가득 찼을 때 발생하는 NetObservAgentFlowsDropped 경고를 해결하려면 FlowCollector 사용자 지정 리소스에서 spec.agent.ebpf.cacheMaxFlows 값을 늘리십시오.

용량 제한기가 작동되면 NetObservAgentFlowsDropped 라는 경고도 발생합니다. 이 경고가 표시되면 다음 예와 같이 FlowCollector 에서 cacheMaxFlows를 늘리는 것을 고려하세요.

참고

cacheMaxFlows를 늘리면 eBPF 에이전트의 메모리 사용량이 늘어날 수 있습니다.

프로세스

  1. 웹 콘솔에서 Operators설치된 Operators 로 이동합니다.
  2. Network Observability Operator제공된 API 제목 아래에서 Flow Collector를 선택합니다.
  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에 있어야 합니다.

14.1. 특정 노드에서의 네트워크 관찰성 배포

NodeSelector , TolerationsAffinity 를 포함한 스케줄링 사양을 사용하여 FlowCollector 리소스를 구성하면 특정 노드에 네트워크 관찰 가능성 구성 요소가 배포되는 방식을 제어할 수 있습니다.

spec.agent.ebpf.advanced.scheduling , spec.processor.advanced.schedulingspec.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장. 2차 네트워크

SR-IOVOVN-Kubernetes 와 같은 보조 네트워크에서 네트워크 흐름 데이터를 수집하고 보강하도록 네트워크 관찰 연산자를 구성할 수 있습니다.

15.1. 사전 요구 사항

  • 보조 인터페이스나 L2 네트워크와 같은 추가 네트워크 인터페이스가 있는 OpenShift Container Platform 클러스터에 액세스합니다.

15.2. SR-IOV 인터페이스 트래픽에 대한 모니터링 구성

FlowCollector 리소스를 구성하여 SR-IOV(Single Root I/O Virtualization) 장치의 트래픽을 모니터링하려면 spec.agent.ebpf.privileged 필드를 true 로 설정하십시오. 이렇게 하면 eBPF 에이전트가 다른 네트워크 네임스페이스를 모니터링할 수 있습니다.

eBPF 에이전트는 기본적으로 모니터링되는 호스트 네트워크 네임스페이스 외에도 다른 네트워크 네임스페이스를 모니터링합니다. 가상 기능(VF) 인터페이스가 있는 포드가 생성되면 새로운 네트워크 네임스페이스가 생성됩니다. SRIOVNetwork 정책 IPAM 구성이 지정되면 VF 인터페이스는 호스트 네트워크 네임스페이스에서 포드 네트워크 네임스페이스로 마이그레이션됩니다.

사전 요구 사항

  • SR-IOV 장치가 있는 OpenShift Container Platform 클러스터에 액세스합니다.
  • SRIOVNetwork 사용자 정의 리소스(CR) 사양.ipam 구성은 인터페이스가 나열한 범위나 다른 플러그인의 IP 주소로 설정해야 합니다.

프로세스

  1. 웹 콘솔에서 Operators설치된 Operators 로 이동합니다.
  2. NetObserv Operator 에 대한 제공된 API 제목 아래에서 Flow Collector를 선택합니다.
  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 로 설정해야 합니다.

FlowCollector를 구성하여 VM 보조 네트워크 트래픽을 모니터링하려면 eBPF 에이전트를 권한 모드로 설정하고 보조 네트워크에 대한 인덱싱을 정의하여 OpenShift 가상화에서 발생하는 흐름을 캡처하고 보강할 수 있도록 합니다.

기본 내부 포드 네트워크에 연결된 VM에서 발생하는 네트워크 흐름은 네트워크 관찰 기능을 통해 자동으로 캡처됩니다.

프로세스

  1. 다음 명령을 실행하여 가상 머신 런처 포드에 대한 정보를 가져옵니다. 이 정보는 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. 웹 콘솔에서 Operators설치된 Operators 로 이동합니다.
  3. NetObserv Operator 에 대한 제공된 API 제목 아래에서 Flow Collector를 선택합니다.
  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를 인덱싱하는 데 사용할 필드를 지정합니다. 2차 인터페이스의 네트워크 흐름을 강화하려면 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. 보강해야 할 소스대상 필드를 모두 보고 VM 런처 포드와 VM 인스턴스를 소유자로 식별합니다.

16장. 네트워크 관찰 CLI

16.1. 네트워크 Observability CLI 설치

네트워크 관찰 CLI( oc netobserv )는 네트워크 관찰 연산자와 별도로 배포됩니다. CLI는 OpenShift CLI( oc ) 플러그인으로 사용할 수 있습니다. 네트워크 관찰을 통해 빠르게 디버깅하고 문제를 해결할 수 있는 가벼운 방법을 제공합니다.

16.1.1. 네트워크 관찰 CLI에 관하여

네트워크 관찰 CLI( oc netobserv )를 사용하면 네트워크 문제를 빠르게 디버깅하고 해결할 수 있습니다. 이 도구는 네트워크 관찰 운영자를 설치하지 않고도 흐름과 패킷에 대한 즉각적이고 실시간적인 통찰력을 제공합니다.

네트워크 관찰 CLI는 eBPF 에이전트를 사용하여 수집된 데이터를 임시 수집기 포드로 스트리밍하는 흐름 및 패킷 시각화 도구입니다. 캡처하는 동안 지속적인 저장이 필요하지 않습니다. 실행 후 출력이 로컬 컴퓨터로 전송됩니다.

중요

CLI 캡처는 8~10분 정도의 짧은 기간 동안만 실행되도록 설계되었습니다. 너무 오래 실행되는 경우 실행 중인 프로세스를 삭제하기 어려울 수 있습니다.

16.1.2. 네트워크 Observability CLI 설치

네트워크 관찰 CLI를 사용하면 네트워크 관찰을 빠르게 디버깅하고 문제를 해결할 수 있는 가벼운 방법을 제공합니다. 별도로 설치해야 합니다.

네트워크 관찰 CLI( oc netobserv )를 설치하는 것은 네트워크 관찰 운영자 설치와 별도의 절차입니다. 즉, 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 정리

터미널에서 직접 흐름과 패킷 데이터를 시각화하고 필터링하여 특정 포트를 사용하는 사람을 식별하는 등 구체적인 사용량을 확인할 수 있습니다. 네트워크 관찰 CLI는 흐름을 JSON으로 수집하고 데이터베이스 파일이나 패킷을 PCAP 파일로 수집하는데, 이는 타사 도구와 함께 사용할 수 있습니다.

16.2.1. 흐름 캡처

CLI에서 직접 네트워크 흐름을 캡처하고 리소스나 영역을 기반으로 필터를 적용합니다. 이를 통해 두 개의 서로 다른 영역 간의 왕복 시간(RTT)을 시각화하는 등 복잡한 사용 사례를 해결하는 데 도움이 됩니다.

CLI에서 테이블 시각화를 통해 보기 및 흐름 검색 기능을 제공합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • 네트워크 관찰 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 키를 사용하여 None , Resource , Zone , Host , Owner그 이상의 모든 항목 사이를 전환합니다.
  4. 캡처를 중지하려면 Ctrl+C 를 누르세요. 캡처된 데이터는 CLI를 설치하는 데 사용된 경로와 동일한 경로에 있는 ./output 디렉토리의 두 개의 별도 파일에 기록됩니다.
  5. ./output/flow/<capture_date_time>.json 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. 패킷 캡처

네트워크 관찰 CLI를 사용하여 네트워크 패킷을 캡처합니다. 터미널에서 필터를 적용하고 실시간으로 세부 조정하여 정확하고 실시간 디버깅을 수행할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • 네트워크 관찰 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 키를 사용하여 None , Resource , Zone , Host , Owner그 이상의 모든 항목 사이를 전환합니다.
  4. 캡처를 중지하려면 Ctrl+C 를 누르세요.
  5. CLI를 설치하는 데 사용된 경로와 동일한 경로에 있는 ./output/pcap 디렉토리의 단일 파일에 기록된 캡처된 데이터를 확인합니다.

    1. ./output/pcap/<capture_date_time>.pcap 파일은 Wireshark로 열 수 있습니다.

16.2.3. 메트릭 캡처

서비스 모니터를 사용하여 Prometheus에서 주문형 네트워크 관찰 대시보드를 생성합니다. 이를 통해 네트워크 지표를 빠르게 보고 분석할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • 네트워크 관찰 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. 네트워크 관찰 CLI(oc netobserv) 참조

네트워크 관찰 CLI( oc netobserv )에는 네트워크 관찰 연산자에서 사용할 수 있는 대부분의 기능과 필터링 옵션이 있습니다. 명령줄 인수를 전달하여 기능이나 필터링 옵션을 활성화할 수 있습니다.

16.3.1. 네트워크 관찰 CLI 사용법

네트워크 관찰 CLI( oc netobserv )를 사용하면 명령줄 인수를 전달하여 흐름 데이터, 패킷 데이터 및 메트릭을 캡처하고 추가 분석을 수행하고 네트워크 관찰 운영자가 지원하는 기능을 활성화할 수 있습니다.

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. 기본 명령
명령설명

흐름

흐름 정보를 수집합니다. 하위 명령에 대해서는 "흐름 캡처 옵션" 표를 참조하세요.

패킷

패킷 데이터를 캡처합니다. 하위 명령에 대해서는 "패킷 캡처 옵션" 표를 참조하세요.

metrics

측정항목 데이터를 수집합니다. 하위 명령에 대해서는 "메트릭 캡처 옵션" 표를 참조하세요.

팔로우

백그라운드에서 실행할 때 수집기 로그를 따르세요.

중지

에이전트 데몬셋을 제거하여 수집을 중지합니다.

복사

수집기에서 생성된 파일을 로컬로 복사합니다.

cleanup

네트워크 관찰 CLI 구성 요소를 제거합니다.

version

소프트웨어 버전을 인쇄하세요.

help

도움을 보여주세요.

16.3.1.3. 흐름 캡처 옵션

흐름 캡처에는 필수 명령은 물론 패킷 삭제, DNS 지연, 왕복 시간, 필터링 등에 대한 추가 기능을 활성화하는 등의 추가 옵션도 있습니다.

oc netobserv 흐름 구문

$ 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

배경

백그라운드에서 실행

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
옵션설명기본

배경

백그라운드에서 실행

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

배경

백그라운드에서 실행

false

--log-level

구성 요소 로그

info

--max-time

최대 캡처 시간

1시간

--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는 네트워크 흐름 수집을 위한 배포를 시범 운영하고 구성하는 데 사용되는 기본 스키마입니다. 이 참조 가이드는 중요한 설정을 관리하는 데 도움이 됩니다.

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

consolePlugin은 사용 가능한 경우 OpenShift Container Platform Console 플러그인과 관련된 설정을 정의합니다.

deploymentModel

string

deploymentModel은 흐름 처리를 위한 원하는 배포 유형을 정의합니다. 가능한 값은 다음과 같습니다:

- 흐름 프로세서가 확장 가능한 배포에서 지원하는 Kubernetes 서비스로 수신 대기하도록 하는 서비스 (기본값)입니다.

- Kafka는 프로세서가 사용하기 전에 Kafka 파이프라인으로 흐름을 보냅니다.

- 흐름 프로세서가 DaemonSet에서 지원하는 호스트 네트워크를 사용하여 에이전트에서 직접 수신하도록 합니다. 15개 미만의 노드로 구성된 소규모 클러스터에서만 권장됩니다.

Kafka는 더 나은 확장성, 복원력 및 고가용성을 제공할 수 있습니다(자세한 내용은 https://www.redhat.com/en/topics/integration/what-is-apache-kafka)를 참조하십시오.

메모리 효율이 낮기 때문에 대규모 클러스터에서 direct 를 사용하지 않는 것이 좋습니다.

exporters

array

exporters 는 사용자 정의 사용 또는 스토리지에 대한 추가 선택적 내보내기를 정의합니다.

kafka

object

카프카 구성을 사용하면 카프카를 플로우 수집 파이프라인의 일부로 브로커로 사용할 수 있습니다. spec.deploymentModelKafka 인 경우 사용 가능합니다.

loki

object

로키 , 플로우 스토어, 클라이언트 설정.

네임스페이스

string

네트워크 관찰 포드가 배포되는 네임스페이스입니다.

networkPolicy

object

networkPolicy는 네트워크 관찰 구성 요소 격리에 대한 네트워크 정책 설정을 정의합니다.

프로세서

object

프로세서는 에이전트로부터 흐름을 수신하고, 이를 풍부하게 하고, 메트릭을 생성하고, 이를 Loki 지속성 계층 및/또는 사용 가능한 모든 내보내기 도구로 전달하는 구성 요소의 설정을 정의합니다.

prometheus

object

prometheus는 콘솔 플러그인에서 메트릭을 가져오는 데 사용되는 쿼리어 구성과 같은 Prometheus 설정을 정의합니다.

17.1.3. .spec.agent

설명
흐름 추출을 위한 에이전트 구성.
유형
object
Expand
재산유형설명

ebpf

object

eBPFspec.agent.typeeBPF로 설정된 경우 eBPF 기반 흐름 보고기와 관련된 설정을 설명합니다.

type

string

type [deprecated (*)]은 흐름 추적 에이전트를 선택합니다. 이전에는 이 필드에서 eBPF 또는 IPFIX 중에서 선택할 수 있었습니다. 현재는 eBPF 만 허용되므로 이 필드는 더 이상 사용되지 않으며 향후 API 버전에서 삭제될 예정입니다.

17.1.4. .spec.agent.ebpf

설명
eBPFspec.agent.typeeBPF로 설정된 경우 eBPF 기반 흐름 보고기와 관련된 설정을 설명합니다.
유형
object
Expand
재산유형설명

advanced

object

Advanced 를 사용하면 eBPF 에이전트의 내부 구성의 일부 측면을 설정할 수 있습니다. 이 섹션은 주로 GOGCGOMAXPROCS 환경 변수와 같은 디버깅 및 세부적인 성능 최적화를 목표로 합니다. 이러한 값을 설정하는 것은 사용자의 책임입니다. 거기에서 기본 Linux 기능을 재정의할 수도 있습니다.

cacheActiveTimeout

string

cacheActiveTimeout 은 에이전트가 전송되기 전에 흐름을 집계하는 기간입니다. cacheMaxFlowscacheActiveTimeout을 늘리면 네트워크 트래픽 오버헤드와 CPU 부하가 줄어들 수 있지만, 메모리 소모가 늘어나고 흐름 수집에 대한 지연 시간이 늘어날 것으로 예상할 수 있습니다.

cacheMaxFlows

integer

cacheMaxFlows 는 집계의 최대 흐름 수입니다. 도달하면 보고자가 흐름을 보냅니다. cacheMaxFlowscacheActiveTimeout을 늘리면 네트워크 트래픽 오버헤드와 CPU 부하가 줄어들 수 있지만, 메모리 소모가 늘어나고 흐름 수집에 대한 지연 시간이 늘어날 것으로 예상할 수 있습니다.

excludeInterfaces

배열(문자열)

excludeInterfaces 에는 흐름 추적에서 제외되는 인터페이스 이름이 포함되어 있습니다. /br-/ 와 같이 슬래시로 묶인 항목은 정규 표현식으로 일치합니다. 그렇지 않으면 대소문자를 구분하는 문자열로 일치합니다.

features

배열(문자열)

추가로 활성화할 수 있는 기능 목록입니다. 이러한 기능은 모두 기본적으로 비활성화되어 있습니다. 추가 기능을 활성화하면 성능에 영향을 미칠 수 있습니다. 가능한 값은 다음과 같습니다:

- PacketDrop : 패킷 삭제 흐름 로깅 기능을 활성화합니다. 이 기능을 사용하려면 커널 디버그 파일 시스템을 마운트해야 하므로 eBPF 에이전트 포드는 spec.agent.ebpf.privileged 를 통해 특권 모드로 실행되어야 합니다.

- DNSTracking: DNS 추적 기능을 활성화합니다.

- FlowRTT : TCP 트래픽에서 eBPF 에이전트의 흐름 지연(sRTT) 추출을 활성화합니다.

- NetworkEvents : 네트워크 흐름과 네트워크 정책의 상관관계 등 네트워크 이벤트 모니터링 기능을 활성화합니다. 이 기능을 사용하려면 커널 디버그 파일 시스템을 마운트해야 하므로 eBPF 에이전트 포드는 spec.agent.ebpf.privileged 를 통해 특권 모드로 실행되어야 합니다. Observability 기능을 갖춘 OVN-Kubernetes 네트워크 플러그인을 사용해야 합니다. 중요: 이 기능은 기술 미리 보기로 제공됩니다.

- PacketTranslation : 서비스 NAT와 같은 패킷 변환 정보를 사용하여 풍부한 흐름을 활성화합니다.

- EbpfManager : [지원되지 않음(*)]. eBPF Manager를 사용하여 네트워크 관찰 eBPF 프로그램을 관리합니다. 필수 조건: eBPF Manager 운영자(또는 업스트림 bpfman 운영자)가 설치되어 있어야 합니다.

- UDNMapping : 사용자 정의 네트워크(UDN)에 대한 인터페이스 매핑을 활성화합니다.

이 기능을 사용하려면 커널 디버그 파일 시스템을 마운트해야 하므로 eBPF 에이전트 포드는 spec.agent.ebpf.privileged 를 통해 특권 모드로 실행되어야 합니다. Observability 기능을 갖춘 OVN-Kubernetes 네트워크 플러그인을 사용해야 합니다.

- IPSec , IPsec 암호화를 통해 노드 간 흐름을 추적합니다.

flowFilter

object

flowFilter 는 흐름 필터링과 관련된 eBPF 에이전트 구성을 정의합니다.

imagePullPolicy

string

imagePullPolicy 는 위에 정의된 이미지에 대한 Kubernetes 풀 정책입니다.

interfaces

배열(문자열)

인터페이스에 는 흐름이 수집되는 위치의 인터페이스 이름이 포함되어 있습니다. 비어 있는 경우 에이전트는 excludeInterfaces 에 나열된 인터페이스를 제외한 시스템의 모든 인터페이스를 가져옵니다. /br-/ 와 같이 슬래시로 묶인 항목은 정규 표현식으로 일치합니다. 그렇지 않으면 대소문자를 구분하는 문자열로 일치합니다.

kafkaBatchSize

integer

kafkaBatchSize 는 파티션으로 전송되기 전에 요청의 최대 크기를 바이트 단위로 제한합니다. Kafka를 사용하지 않을 때는 무시됩니다. 기본값: 1MB.

logLevel

string

loglevel 은 Network Observability eBPF Agent의 로그 수준을 정의합니다.

metrics

object

메트릭은 메트릭과 관련된 eBPF 에이전트 구성을 정의합니다.

privileged

boolean

eBPF 에이전트 컨테이너의 권한 모드입니다. true 로 설정하면 에이전트는 2차 인터페이스를 포함하여 더 많은 트래픽을 캡처할 수 있습니다. 무시하거나 false 로 설정하면 연산자는 컨테이너에 세부적인 기능(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 환경 변수와 같은 디버깅 및 세부적인 성능 최적화를 목표로 합니다. 이러한 값을 설정하는 것은 사용자의 책임입니다. 거기에서 기본 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

지정된 경우, 포드의 스케줄링 제약 조건이 적용됩니다. 자세한 내용은 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

tolerations는 포드가 일치하는 taint가 있는 노드에 스케줄을 지정할 수 있도록 하는 tolerations 목록입니다. 자세한 내용은 https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling 을 참조하세요.

17.1.7. .spec.agent.ebpf.advanced.scheduling.affinity

설명
지정된 경우, 포드의 스케줄링 제약 조건이 적용됩니다. 자세한 내용은 https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling 을 참조하세요.
유형
object

17.1.8. .spec.agent.ebpf.advanced.scheduling.tolerations

설명
tolerations는 포드가 일치하는 taint가 있는 노드에 스케줄을 지정할 수 있도록 하는 tolerations 목록입니다. 자세한 내용은 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

action은 필터와 일치하는 흐름에 대해 수행할 작업을 정의합니다. 사용 가능한 옵션은 기본값인 AcceptReject입니다 .

cidr

string

cidr은 흐름을 필터링할 IP CIDR을 정의합니다. 예: 10.10.10.0/24 또는 100:100:100:100::/64

destPorts

integer-or-string

destPorts는 선택적으로 흐름을 필터링할 대상 포트를 정의합니다. 단일 포트를 필터링하려면 단일 포트를 정수 값으로 설정합니다. 예를 들어, destPorts: 80 . 포트 범위를 필터링하려면 문자열 형식의 "시작-끝" 범위를 사용하세요. 예를 들어, destPorts: "80-100" . 두 개의 포트를 필터링하려면 문자열 형식으로 "port1,port2"를 사용합니다. 예를 들어, 포트: "80,100" .

방향

string

direction은 선택적으로 흐름을 필터링할 방향을 정의합니다. 사용 가능한 옵션은 IngressEgress 입니다.

enable

boolean

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

icmpCode

integer

icmpCode 는 인터넷 제어 메시지 프로토콜(ICMP) 트래픽의 경우 선택적으로 흐름을 필터링할 ICMP 코드를 정의합니다.

icmpType

integer

ICMP 트래픽의 경우 icmpType 은 선택적으로 흐름을 필터링할 ICMP 유형을 정의합니다.

peerCIDR

string

peerCIDR은 흐름을 필터링할 Peer 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

ports는 선택적으로 흐름을 필터링할 포트를 정의합니다. 소스 및 대상 포트 모두에 사용됩니다. 단일 포트를 필터링하려면 단일 포트를 정수 값으로 설정합니다. 예를 들어, 포트: 80 . 포트 범위를 필터링하려면 문자열 형식의 "시작-끝" 범위를 사용하세요. 예를 들어, 포트: "80-100" . 두 개의 포트를 필터링하려면 문자열 형식으로 "port1,port2"를 사용합니다. 예를 들어, 포트: "80,100" .

protocol

string

protocol은 선택적으로 흐름을 필터링할 프로토콜을 정의합니다. 사용 가능한 옵션은 TCP , UDP , ICMP , ICMPv6SCTP 입니다.

rules[]

array

규칙은 eBPF 에이전트의 필터링 규칙 목록을 정의합니다. 필터링이 활성화된 경우 기본적으로 어떤 규칙과도 일치하지 않는 흐름은 거부됩니다. 기본값을 변경하려면 모든 것을 허용하는 규칙을 정의합니다. { action: "Accept", cidr: "0.0.0.0/0" } , 그런 다음 거부 규칙을 세부적으로 지정합니다.

sampling:

integer

sampling은 일치하는 패킷에 대한 샘플링 간격으로, spec.agent.ebpf.sampling 에서 정의된 글로벌 샘플링을 재정의합니다.

sourcePorts

integer-or-string

sourcePorts는 선택적으로 흐름을 필터링할 소스 포트를 정의합니다. 단일 포트를 필터링하려면 단일 포트를 정수 값으로 설정합니다. 예를 들어, sourcePorts: 80 . 포트 범위를 필터링하려면 문자열 형식의 "시작-끝" 범위를 사용하세요. 예를 들어, 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[]

설명
EBPFFlowFilterRule은 흐름 필터링 규칙과 관련된 원하는 eBPF 에이전트 구성을 정의합니다.
유형
object
Expand
재산유형설명

작업

string

action은 필터와 일치하는 흐름에 대해 수행할 작업을 정의합니다. 사용 가능한 옵션은 기본값인 AcceptReject입니다 .

cidr

string

cidr은 흐름을 필터링할 IP CIDR을 정의합니다. 예: 10.10.10.0/24 또는 100:100:100:100::/64

destPorts

integer-or-string

destPorts는 선택적으로 흐름을 필터링할 대상 포트를 정의합니다. 단일 포트를 필터링하려면 단일 포트를 정수 값으로 설정합니다. 예를 들어, destPorts: 80 . 포트 범위를 필터링하려면 문자열 형식의 "시작-끝" 범위를 사용하세요. 예를 들어, destPorts: "80-100" . 두 개의 포트를 필터링하려면 문자열 형식으로 "port1,port2"를 사용합니다. 예를 들어, 포트: "80,100" .

방향

string

direction은 선택적으로 흐름을 필터링할 방향을 정의합니다. 사용 가능한 옵션은 IngressEgress 입니다.

icmpCode

integer

icmpCode 는 인터넷 제어 메시지 프로토콜(ICMP) 트래픽의 경우 선택적으로 흐름을 필터링할 ICMP 코드를 정의합니다.

icmpType

integer

ICMP 트래픽의 경우 icmpType 은 선택적으로 흐름을 필터링할 ICMP 유형을 정의합니다.

peerCIDR

string

peerCIDR은 흐름을 필터링할 Peer 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

ports는 선택적으로 흐름을 필터링할 포트를 정의합니다. 소스 및 대상 포트 모두에 사용됩니다. 단일 포트를 필터링하려면 단일 포트를 정수 값으로 설정합니다. 예를 들어, 포트: 80 . 포트 범위를 필터링하려면 문자열 형식의 "시작-끝" 범위를 사용하세요. 예를 들어, 포트: "80-100" . 두 개의 포트를 필터링하려면 문자열 형식으로 "port1,port2"를 사용합니다. 예를 들어, 포트: "80,100" .

protocol

string

protocol은 선택적으로 흐름을 필터링할 프로토콜을 정의합니다. 사용 가능한 옵션은 TCP , UDP , ICMP , ICMPv6SCTP 입니다.

sampling:

integer

sampling은 일치하는 패킷에 대한 샘플링 간격으로, spec.agent.ebpf.sampling 에서 정의된 글로벌 샘플링을 재정의합니다.

sourcePorts

integer-or-string

sourcePorts는 선택적으로 흐름을 필터링할 소스 포트를 정의합니다. 단일 포트를 필터링하려면 단일 포트를 정수 값으로 설정합니다. 예를 들어, sourcePorts: 80 . 포트 범위를 필터링하려면 문자열 형식의 "시작-끝" 범위를 사용하세요. 예를 들어, 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는 비활성화해야 할 알림 목록입니다. 가능한 값은 다음과 같습니다:

eBPF 에이전트에서 패킷이나 흐름이 누락된 경우(예: BPF 해시맵이 사용 중이거나 가득 찬 경우 또는 용량 제한이 트리거되는 경우)에 트리거되는 NetObservDroppedFlows 입니다.

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 로 설정하면, 제공된CaFile 필드는 무시됩니다.

제공됨

object

유형이 제공됨 으로 설정된 경우의 TLS 구성입니다.

providedCaFile

object

유형이 제공됨 으로 설정된 경우 CA 파일에 대한 참조입니다.

type

string

TLS 구성 유형을 선택하세요:

- 비활성화 (기본값) - 엔드포인트에 TLS를 구성하지 않습니다. - 인증서 파일과 키 파일을 수동으로 제공 합니다 . [지원되지 않음(*)]. - 자동 - 주석을 사용하여 OpenShift Container Platform에서 자동 생성된 인증서를 사용합니다.

17.1.15. .spec.agent.ebpf.metrics.server.tls.provided

설명
유형이 제공됨 으로 설정된 경우의 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

설명
유형이 제공됨 으로 설정된 경우 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

요청은 필요한 최소 컴퓨팅 리소스 양을 설명합니다. 컨테이너에 대한 요청이 생략되면 명시적으로 지정되어 있으면 제한이 기본값으로 설정되고, 그렇지 않으면 구현에서 정의한 값이 기본값으로 설정됩니다. 요청은 한도를 초과할 수 없습니다. 자세한 정보: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

17.1.18. .spec.consolePlugin

설명
consolePlugin은 사용 가능한 경우 OpenShift Container Platform Console 플러그인과 관련된 설정을 정의합니다.
유형
object
Expand
재산유형설명

advanced

object

고급을 사용하면 콘솔 플러그인의 내부 구성의 일부 측면을 설정할 수 있습니다. 이 섹션은 주로 GOGCGOMAXPROCS 환경 변수와 같은 디버깅 및 세부적인 성능 최적화를 목표로 합니다. 이러한 값을 설정하는 것은 사용자의 책임입니다.

autoscaler

object

플러그인 배포에 설정할 수평 Pod 자동 스케일러 의 자동 스케일러 [더 이상 사용되지 않음 (*)] 사양입니다. 사용 중단 알림: 관리형 자동 스케일러는 향후 버전에서 제거됩니다. 선택한 자동 스케일러를 대신 구성하고 spec.consolePlugin.unmanagedReplicastrue 로 설정할 수 있습니다. HorizontalPodAutoscaler 문서(자동 확장/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는 시작할 복제본(포드)의 수를 정의합니다.

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

설명
고급을 사용하면 콘솔 플러그인의 내부 구성의 일부 측면을 설정할 수 있습니다. 이 섹션은 주로 GOGCGOMAXPROCS 환경 변수와 같은 디버깅 및 세부적인 성능 최적화를 목표로 합니다. 이러한 값을 설정하는 것은 사용자의 책임입니다.
유형
object
Expand
재산유형설명

인수

배열(문자열)

args를 사용하면 기본 구성 요소에 사용자 정의 인수를 전달할 수 있습니다. URL이나 구성 경로와 같이 FlowCollector 설명자의 일부로 공개적으로 노출되어서는 안 되는 일부 매개변수를 재정의하는 데 유용합니다. 이러한 매개변수는 에지 디버그나 지원 시나리오에서만 유용합니다.

env

객체(문자열)

env를 사용하면 사용자 정의 환경 변수를 기본 구성 요소에 전달할 수 있습니다. GOGCGOMAXPROCS 와 같이 매우 구체적인 성능 조정 옵션을 전달하는 데 유용합니다. 이러한 옵션은 FlowCollector 설명자의 일부로 공개적으로 노출되어서는 안 되며, 에지 디버그 또는 지원 시나리오에서만 유용합니다.

port

integer

port 는 플러그인 서비스 포트입니다. 메트릭을 위해 예약된 9002를 사용하지 마십시오.

등록하다

boolean

register를 true 로 설정하면 제공된 콘솔 플러그인을 OpenShift Container Platform 콘솔 운영자에게 자동으로 등록할 수 있습니다. false 로 설정된 경우에도 다음 명령으로 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

지정된 경우, 포드의 스케줄링 제약 조건이 적용됩니다. 자세한 내용은 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

tolerations는 포드가 일치하는 taint가 있는 노드에 스케줄을 지정할 수 있도록 하는 tolerations 목록입니다. 자세한 내용은 https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling 을 참조하세요.

17.1.21. .spec.consolePlugin.advanced.scheduling.affinity

설명
지정된 경우, 포드의 스케줄링 제약 조건이 적용됩니다. 자세한 내용은 https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling 을 참조하세요.
유형
object

17.1.22. .spec.consolePlugin.advanced.scheduling.tolerations

설명
tolerations는 포드가 일치하는 taint가 있는 노드에 스케줄을 지정할 수 있도록 하는 tolerations 목록입니다. 자세한 내용은 https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling 을 참조하세요.
유형
array

17.1.23. .spec.consolePlugin.autoscaler

설명
플러그인 배포에 설정할 수평 Pod 자동 스케일러 의 자동 스케일러 [더 이상 사용되지 않음 (*)] 사양입니다. 사용 중단 알림: 관리형 자동 스케일러는 향후 버전에서 제거됩니다. 선택한 자동 스케일러를 대신 구성하고 spec.consolePlugin.unmanagedReplicastrue 로 설정할 수 있습니다. HorizontalPodAutoscaler 문서(자동 확장/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

요청은 필요한 최소 컴퓨팅 리소스 양을 설명합니다. 컨테이너에 대한 요청이 생략되면 명시적으로 지정되어 있으면 제한이 기본값으로 설정되고, 그렇지 않으면 구현에서 정의한 값이 기본값으로 설정됩니다. 요청은 한도를 초과할 수 없습니다. 자세한 정보: 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 구성(풍부한 IPFIX 흐름을 보낼 IP 주소 및 포트 등)

kafka

object

풍요한 흐름을 보내기 위한 주소 및 주제와 같은 Kafka 구성입니다.

openTelemetry

object

강화된 로그 또는 메트릭을 전송하는 IP 주소 및 포트와 같은 OpenTelemetry 구성입니다.

type

string

type은 내보내기 프로그램의 유형을 선택합니다. 사용 가능한 옵션은 Kafka , IPFIXOpenTelemetry 입니다.

17.1.30. .spec.exporters[].ipfix

설명
IPFIX 구성(풍부한 IPFIX 흐름을 보낼 IP 주소 및 포트 등)
유형
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

카프카 서버의 주소

사슬

object

SASL 인증 구성. [지원되지 않음(*)].

tls

object

TLS 클라이언트 구성. TLS를 사용하는 경우 주소가 TLS에 사용되는 Kafka 포트(일반적으로 9093)와 일치하는지 확인합니다.

topic

string

사용할 카프카 주제. 그것은 반드시 존재해야 합니다. 네트워크 관찰성이 이를 생성하지 않습니다.

17.1.32. .spec.exporters[].kafka.sasl

설명
SASL 인증 구성. [지원되지 않음(*)].
유형
object
Expand
재산유형설명

clientIDReference

object

클라이언트 ID를 포함하는 비밀 또는 구성 맵에 대한 참조

clientSecretReference

object

클라이언트 비밀을 포함하는 비밀 또는 구성 맵에 대한 참조

type

string

사용할 SASL 인증 유형 또는 SASL을 사용하지 않는 경우 비활성화됨

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

certFile은 구성 맵이나 비밀 내의 인증서 파일 이름에 대한 경로를 정의합니다.

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

certFile은 구성 맵이나 비밀 내의 인증서 파일 이름에 대한 경로를 정의합니다.

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 규격 형식에 매핑되는 사용자 정의 필드입니다. 기본적으로 네트워크 관찰성 형식 제안이 사용됩니다: 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 규격 형식에 매핑되는 사용자 정의 필드입니다. 기본적으로 네트워크 관찰성 형식 제안이 사용됩니다: 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 수신기로 보내려면 enable을 true 로 설정합니다.

17.1.42. .spec.exporters[].openTelemetry.metrics

설명
메트릭을 위한 OpenTelemetry 구성.
유형
object
Expand
재산유형설명

enable

boolean

OpenTelemetry 수신기에 메트릭을 전송하려면 enable을 true 로 설정합니다.

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

certFile은 구성 맵이나 비밀 내의 인증서 파일 이름에 대한 경로를 정의합니다.

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

certFile은 구성 맵이나 비밀 내의 인증서 파일 이름에 대한 경로를 정의합니다.

certKey

string

certKey는 구성 맵 또는 비밀 내의 인증서 개인 키 파일 이름에 대한 경로를 정의합니다. 키가 필요하지 않으면 생략합니다.

name

string

인증서가 포함된 구성 맵 또는 시크릿의 이름입니다.

네임스페이스

string

인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본적으로 Network Observability가 배포된 것과 동일한 네임스페이스를 사용합니다. 네임스페이스가 다르면 구성 맵이나 비밀이 복사되어 필요에 따라 마운트될 수 있습니다.

type

string

인증서 참조 유형: configmap 또는 secret .

17.1.46. .spec.kafka

설명
카프카 구성을 사용하면 카프카를 플로우 수집 파이프라인의 일부로 브로커로 사용할 수 있습니다. spec.deploymentModelKafka 인 경우 사용 가능합니다.
유형
object
필수 항목
  • address
  • topic
Expand
재산유형설명

address

string

카프카 서버의 주소

사슬

object

SASL 인증 구성. [지원되지 않음(*)].

tls

object

TLS 클라이언트 구성. TLS를 사용하는 경우 주소가 TLS에 사용되는 Kafka 포트(일반적으로 9093)와 일치하는지 확인합니다.

topic

string

사용할 카프카 주제. 그것은 반드시 존재해야 합니다. 네트워크 관찰성이 이를 생성하지 않습니다.

17.1.47. .spec.kafka.sasl

설명
SASL 인증 구성. [지원되지 않음(*)].
유형
object
Expand
재산유형설명

clientIDReference

object

클라이언트 ID를 포함하는 비밀 또는 구성 맵에 대한 참조

clientSecretReference

object

클라이언트 비밀을 포함하는 비밀 또는 구성 맵에 대한 참조

type

string

사용할 SASL 인증 유형 또는 SASL을 사용하지 않는 경우 비활성화됨

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

certFile은 구성 맵이나 비밀 내의 인증서 파일 이름에 대한 경로를 정의합니다.

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

certFile은 구성 맵이나 비밀 내의 인증서 파일 이름에 대한 경로를 정의합니다.

certKey

string

certKey는 구성 맵 또는 비밀 내의 인증서 개인 키 파일 이름에 대한 경로를 정의합니다. 키가 필요하지 않으면 생략합니다.

name

string

인증서가 포함된 구성 맵 또는 시크릿의 이름입니다.

네임스페이스

string

인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본적으로 Network Observability가 배포된 것과 동일한 네임스페이스를 사용합니다. 네임스페이스가 다르면 구성 맵이나 비밀이 복사되어 필요에 따라 마운트될 수 있습니다.

type

string

인증서 참조 유형: configmap 또는 secret .

17.1.53. .spec.loki

설명
로키 , 플로우 스토어, 클라이언트 설정.
유형
object
필수 항목
  • mode
Expand
재산유형설명

advanced

object

고급을 사용하면 Loki 클라이언트의 내부 구성의 일부 측면을 설정할 수 있습니다. 이 섹션은 주로 디버깅과 세부적인 성능 최적화를 목표로 합니다.

enable

boolean

Loki에 흐름을 저장하려면 enable을 true 로 설정합니다. 콘솔 플러그인은 Loki 또는 Prometheus를 메트릭의 데이터 소스로 사용하거나 ( spec.prometheus.querier) 또는 둘 다 사용할 수 있습니다. 모든 질문이 로키에서 프로메테우스로 옮겨질 수 있는 것은 아닙니다. 따라서 Loki가 비활성화되면 플러그인의 일부 기능(예: 포드별 정보 가져오기, 원시 흐름 보기)도 비활성화됩니다. Prometheus와 Loki가 모두 활성화된 경우 Prometheus가 우선하고 Loki는 Prometheus가 처리할 수 없는 쿼리에 대한 대체 수단으로 사용됩니다. 두 가지 모두 비활성화된 경우 콘솔 플러그인이 배포되지 않습니다.

lokiStack

object

LokiStack 모드를 위한 Loki 구성. 이는 Loki Operator를 쉽게 구성하는 데 유용합니다. 다른 모드에서는 무시됩니다.

manual

object

수동 모드를 위한 Loki 구성. 이것은 가장 유연한 구성입니다. 다른 모드에서는 무시됩니다.

마이크로 서비스

object

마이크로서비스 모드를 위한 Loki 구성. Loki가 마이크로서비스 배포 모드( https://grafana.com/docs/loki/latest/fundamentals/architecture/deployment-modes/#microservices-mode )를 사용하여 설치된 경우 이 옵션을 사용합니다. 다른 모드에서는 무시됩니다.

mode

string

mode 는 Loki의 설치 모드에 따라 설정해야 합니다.

- Loki Operator를 사용하여 Loki를 관리하는 경우 LokiStack을 사용합니다.

- Loki가 모놀리식 작업으로 설치된 경우 Monolithic을 사용합니다.

- Loki가 마이크로서비스로 설치되었지만 Loki Operator가 없는 경우 마이크로서비스를 사용합니다.

- 위의 옵션 중 어느 것도 설정과 일치하지 않으면 수동을 사용하세요.

단단히 짜여 하나로 되어 있는

object

모노리식 모드를 위한 Loki 구성. Loki가 모놀리식 배포 모드( https://grafana.com/docs/loki/latest/fundamentals/architecture/deployment-modes/#monolithic-mode )를 사용하여 설치된 경우 이 옵션을 사용하세요. 다른 모드에서는 무시됩니다.

readTimeout

string

readTimeout 은 콘솔 플러그인 로키 쿼리의 최대 총 시간 제한입니다. 시간 초과가 0이면 시간 초과가 없음을 의미합니다.

writeBatchSize

integer

writeBatchSize는 전송하기 전에 누적할 Loki 로그의 최대 배치 크기(바이트)입니다.

writeBatchWait

string

writeBatchWait는 Loki 배치를 보내기 전에 기다리는 최대 시간입니다.

writeTimeout

string

writeTimeout 은 Loki의 최대 시간 연결/요청 제한입니다. 시간 초과가 0이면 시간 초과가 없음을 의미합니다.

17.1.54. .spec.loki.advanced

설명
고급을 사용하면 Loki 클라이언트의 내부 구성의 일부 측면을 설정할 수 있습니다. 이 섹션은 주로 디버깅과 세부적인 성능 최적화를 목표로 합니다.
유형
object
Expand
재산유형설명

excludeLabels

배열(문자열)

excludeLabels 는 Loki 레이블 목록에서 제외할 필드 목록입니다. [지원되지 않음(*)].

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

authToken은 Loki에 인증하기 위한 토큰을 얻는 방법을 설명합니다.

- 비활성화하면 요청과 함께 토큰을 전송하지 않습니다.

- 전달은 인증을 위해 사용자 토큰을 전달합니다.

- 호스트 [더 이상 사용되지 않음(*)] - 로컬 포드 서비스 계정을 사용하여 Loki에 인증합니다.

Loki 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 쿼리어 서비스의 주소를 지정합니다. Loki Operator를 사용하는 경우 경로에 네트워크 테넌트가 설정된 Loki 게이트웨이 서비스로 설정합니다(예: https://loki-gateway-http.netobserv.svc:8080/api/logs/v1/network ).

statusTls

object

Loki 상태 URL에 대한 TLS 클라이언트 구성.

statusUrl

string

statusUrl은 Loki 쿼리자 URL과 다른 경우 Loki /ready , /metrics/config 엔드포인트의 주소를 지정합니다. 비어 있으면 querierUrl 값이 사용됩니다. 이는 프런트엔드에서 오류 메시지와 일부 컨텍스트를 표시하는 데 유용합니다. Loki Operator를 사용하는 경우 Loki HTTP 쿼리 프런트엔드 서비스로 설정합니다(예 : https://loki-query-frontend-http.netobserv.svc:3100/ ). statusUrl이 설정되면 statusTLS 구성이 사용됩니다.

tenantID

string

tenantID는 각 요청에 대한 테넌트를 식별하는 Loki X-Scope-OrgID 입니다. Loki Operator를 사용할 때는 특수 테넌트 모드에 해당하는 network 로 설정합니다.

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

certFile은 구성 맵이나 비밀 내의 인증서 파일 이름에 대한 경로를 정의합니다.

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

certFile은 구성 맵이나 비밀 내의 인증서 파일 이름에 대한 경로를 정의합니다.

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

certFile은 구성 맵이나 비밀 내의 인증서 파일 이름에 대한 경로를 정의합니다.

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

certFile은 구성 맵이나 비밀 내의 인증서 파일 이름에 대한 경로를 정의합니다.

certKey

string

certKey는 구성 맵 또는 비밀 내의 인증서 개인 키 파일 이름에 대한 경로를 정의합니다. 키가 필요하지 않으면 생략합니다.

name

string

인증서가 포함된 구성 맵 또는 시크릿의 이름입니다.

네임스페이스

string

인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본적으로 Network Observability가 배포된 것과 동일한 네임스페이스를 사용합니다. 네임스페이스가 다르면 구성 맵이나 비밀이 복사되어 필요에 따라 마운트될 수 있습니다.

type

string

인증서 참조 유형: configmap 또는 secret .

17.1.63. .spec.loki.microservices

설명
마이크로서비스 모드를 위한 Loki 구성. Loki가 마이크로서비스 배포 모드( https://grafana.com/docs/loki/latest/fundamentals/architecture/deployment-modes/#microservices-mode )를 사용하여 설치된 경우 이 옵션을 사용합니다. 다른 모드에서는 무시됩니다.
유형
object
Expand
재산유형설명

ingesterUrl

string

ingesterUrl은 흐름을 푸시할 기존 Loki ingester 서비스의 주소입니다.

querierUrl

string

querierURL은 Loki 쿼리어 서비스의 주소를 지정합니다.

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

certFile은 구성 맵이나 비밀 내의 인증서 파일 이름에 대한 경로를 정의합니다.

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

certFile은 구성 맵이나 비밀 내의 인증서 파일 이름에 대한 경로를 정의합니다.

certKey

string

certKey는 구성 맵 또는 비밀 내의 인증서 개인 키 파일 이름에 대한 경로를 정의합니다. 키가 필요하지 않으면 생략합니다.

name

string

인증서가 포함된 구성 맵 또는 시크릿의 이름입니다.

네임스페이스

string

인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본적으로 Network Observability가 배포된 것과 동일한 네임스페이스를 사용합니다. 네임스페이스가 다르면 구성 맵이나 비밀이 복사되어 필요에 따라 마운트될 수 있습니다.

type

string

인증서 참조 유형: configmap 또는 secret .

17.1.67. .spec.loki.monolithic

설명
모노리식 모드를 위한 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은 수집기와 쿼리기를 모두 가리키는 기존 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

certFile은 구성 맵이나 비밀 내의 인증서 파일 이름에 대한 경로를 정의합니다.

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

certFile은 구성 맵이나 비밀 내의 인증서 파일 이름에 대한 경로를 정의합니다.

certKey

string

certKey는 구성 맵 또는 비밀 내의 인증서 개인 키 파일 이름에 대한 경로를 정의합니다. 키가 필요하지 않으면 생략합니다.

name

string

인증서가 포함된 구성 맵 또는 시크릿의 이름입니다.

네임스페이스

string

인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본적으로 Network Observability가 배포된 것과 동일한 네임스페이스를 사용합니다. 네임스페이스가 다르면 구성 맵이나 비밀이 복사되어 필요에 따라 마운트될 수 있습니다.

type

string

인증서 참조 유형: configmap 또는 secret .

17.1.71. .spec.networkPolicy

설명
networkPolicy는 네트워크 관찰 구성 요소 격리에 대한 네트워크 정책 설정을 정의합니다.
유형
object
Expand
재산유형설명

additionalNamespaces

배열(문자열)

additionalNamespaces 에는 네트워크 Observability 네임스페이스에 연결할 수 있는 추가 네임스페이스가 포함되어 있습니다. 네트워크 정책 구성에 유연성을 제공하지만, 더 구체적인 구성이 필요한 경우 이를 비활성화하고 대신 사용자 고유의 구성을 설치할 수 있습니다.

enable

boolean

네트워크 관찰 기능에서 사용하는 네임스페이스(기본 및 권한 있는 네임스페이스)에 네트워크 정책을 배포합니다. 이러한 네트워크 정책은 네트워크 관찰 가능성 구성 요소를 더 잘 격리하여 원치 않는 연결이 발생하는 것을 방지합니다. 이 옵션은 OVNKubernetes와 함께 사용할 경우 기본적으로 활성화되고, 그렇지 않은 경우에는 비활성화됩니다(다른 CNI와의 호환성은 테스트되지 않았습니다). 이 기능을 비활성화하면 네트워크 관찰 가능성 구성 요소에 대한 네트워크 정책을 수동으로 생성할 수 있습니다.

17.1.72. .spec.processor

설명
프로세서는 에이전트로부터 흐름을 수신하고, 이를 풍부하게 하고, 메트릭을 생성하고, 이를 Loki 지속성 계층 및/또는 사용 가능한 모든 내보내기 도구로 전달하는 구성 요소의 설정을 정의합니다.
유형
object
Expand
재산유형설명

addZone

boolean

addZone 은 소스 및 대상 영역으로 흐름에 라벨을 지정하여 가용성 영역 인식을 허용합니다. 이 기능을 사용하려면 노드에 "topology.kubernetes.io/zone" 레이블을 설정해야 합니다.

advanced

object

고급 기능을 사용하면 플로우 프로세서의 내부 구성의 일부 측면을 설정할 수 있습니다. 이 섹션은 주로 GOGCGOMAXPROCS 환경 변수와 같은 디버깅 및 세부적인 성능 최적화를 목표로 합니다. 이러한 값을 설정하는 것은 사용자의 책임입니다.

clusterName

string

clusterName은 흐름 데이터에 표시되는 클러스터의 이름입니다. 이는 다중 클러스터 컨텍스트에서 유용합니다. OpenShift Container Platform을 사용하는 경우, 자동으로 결정되도록 비워 두세요.

consumerReplicas

integer

consumerReplicasflowlogs-pipeline 용으로 시작할 복제본(Pod) 수를 정의합니다. 기본값은 3입니다. spec.deploymentModelDirect 이거나 spec.processor.unmanagedReplicastrue 인 경우 이 설정은 무시됩니다.

deduper

object

deduper를 사용하면 중복으로 식별된 흐름을 샘플링하거나 삭제하여 리소스 사용량을 절약할 수 있습니다.

filters

array

필터를 사용하면 사용자 정의 필터를 정의하여 생성된 흐름의 양을 제한할 수 있습니다. 이러한 필터는 eBPF 에이전트 필터( spec.agent.ebpf.flowFilter )보다 더 많은 유연성을 제공합니다. 예를 들어 Kubernetes 네임스페이스로 필터링할 수 있지만 성능 향상 폭은 적습니다.

imagePullPolicy

string

imagePullPolicy 는 위에 정의된 이미지에 대한 Kubernetes 풀 정책입니다.

kafkaConsumerAutoscaler

object

kafkaConsumerAutoscaler [deprecated (*)]는 Kafka 메시지를 사용하는 flowlogs-pipeline-transformer 에 대해 설정하는 수평 Pod 자동 스케일러의 사양입니다. Kafka가 비활성화된 경우 이 설정은 무시됩니다. 사용 중단 알림: 관리형 자동 스케일러는 향후 버전에서 제거됩니다. 선택한 자동 스케일러를 대신 구성하고 spec.processor.unmanagedReplicastrue 로 설정할 수 있습니다. HorizontalPodAutoscaler 문서(자동 확장/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

프로세서 런타임의 logLevel

logTypes

string

logTypes는 생성할 원하는 레코드 유형을 정의합니다. 가능한 값은 다음과 같습니다:

- 정기적인 네트워크 흐름을 내보내는 흐름 . 이는 기본값입니다.

- 시작된 대화에 대한 이벤트를 생성하는 대화, 대화 종료 및 주기적인 "tick" 업데이트 이 모드에서는 Prometheus 지표가 장기 대화에 대해 정확하지 않다는 점에 유의하세요.

- EndedConversations는 종료된 대화 이벤트만 생성합니다. 이 모드에서는 Prometheus 지표가 장기 대화에 대해 정확하지 않다는 점에 유의하세요.

- 네트워크 흐름과 모든 대화 이벤트 생성합니다. 자원 사용량에 영향을 미치므로 권장하지 않습니다.

metrics

object

메트릭은 메트릭과 관련된 프로세서 구성을 정의합니다.

multiClusterDeployment

boolean

다중 클러스터 기능을 활성화하려면 multiClusterDeployment를 true 로 설정합니다. 이렇게 하면 흐름 데이터에 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

설명
고급 기능을 사용하면 플로우 프로세서의 내부 구성의 일부 측면을 설정할 수 있습니다. 이 섹션은 주로 GOGCGOMAXPROCS 환경 변수와 같은 디버깅 및 세부적인 성능 최적화를 목표로 합니다. 이러한 값을 설정하는 것은 사용자의 책임입니다.
유형
object
Expand
재산유형설명

conversationEndTimeout

string

conversationEndTimeout은 네트워크 흐름을 수신한 후 대화가 종료된 것으로 간주하기 위해 기다리는 시간입니다. TCP 흐름에 대한 FIN 패킷이 수집되는 경우 이 지연은 무시됩니다(대신 conversationTerminatingTimeout을 참조하세요).

conversationHeartbeatInterval

string

conversationHeartbeatInterval은 대화의 "틱" 이벤트 사이에 기다리는 시간입니다.

conversationTerminatingTimeout

string

conversationTerminatingTimeout은 대화를 종료하기 위해 감지된 FIN 플래그부터 기다리는 시간입니다. TCP 흐름에만 해당됩니다.

dropUnusedFields

boolean

dropUnusedFields [더 이상 사용되지 않음(*)] 이 설정은 더 이상 사용되지 않습니다.

enableKubeProbes

boolean

enableKubeProbes 는 Kubernetes 활성 및 준비 프로브를 활성화하거나 비활성화하는 플래그입니다.

env

객체(문자열)

env를 사용하면 사용자 정의 환경 변수를 기본 구성 요소에 전달할 수 있습니다. GOGCGOMAXPROCS 와 같이 매우 구체적인 성능 조정 옵션을 전달하는 데 유용합니다. 이러한 옵션은 FlowCollector 설명자의 일부로 공개적으로 노출되어서는 안 되며, 에지 디버그 또는 지원 시나리오에서만 유용합니다.

healthPort

integer

healthPort 는 Pod의 수집기 HTTP 포트로, 상태 확인 API를 노출합니다.

port

integer

유량 수집기의 포트(호스트 포트). 관례상 일부 값은 금지되어 있습니다. 1024보다 커야 하며 4500, 4789, 6081과 달라야 합니다.

profilePort

integer

profilePort를 사용하면 이 포트를 수신하는 Go pprof 프로파일러를 설정할 수 있습니다.

scheduling

object

스케줄링은 노드에서 Pod를 예약하는 방법을 제어합니다.

secondaryNetworks

array

리소스 식별을 위해 검사할 보조 네트워크를 정의합니다. 정확한 식별을 보장하려면 인덱스된 값이 클러스터 전체에서 고유한 식별자를 형성해야 합니다. 동일한 인덱스가 여러 리소스에 의해 사용되는 경우 해당 리소스에 잘못된 레이블이 지정될 수 있습니다.

17.1.74. .spec.processor.advanced.scheduling

설명
스케줄링은 노드에서 Pod를 예약하는 방법을 제어합니다.
유형
object
Expand
재산유형설명

유사성

object

지정된 경우, 포드의 스케줄링 제약 조건이 적용됩니다. 자세한 내용은 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

tolerations는 포드가 일치하는 taint가 있는 노드에 스케줄을 지정할 수 있도록 하는 tolerations 목록입니다. 자세한 내용은 https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling 을 참조하세요.

17.1.75. .spec.processor.advanced.scheduling.affinity

설명
지정된 경우, 포드의 스케줄링 제약 조건이 적용됩니다. 자세한 내용은 https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling 을 참조하세요.
유형
object

17.1.76. .spec.processor.advanced.scheduling.tolerations

설명
tolerations는 포드가 일치하는 taint가 있는 노드에 스케줄을 지정할 수 있도록 하는 tolerations 목록입니다. 자세한 내용은 https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling 을 참조하세요.
유형
array

17.1.77. .spec.processor.advanced.secondaryNetworks

설명
리소스 식별을 위해 검사할 보조 네트워크를 정의합니다. 정확한 식별을 보장하려면 인덱스된 값이 클러스터 전체에서 고유한 식별자를 형성해야 합니다. 동일한 인덱스가 여러 리소스에 의해 사용되는 경우 해당 리소스에 잘못된 레이블이 지정될 수 있습니다.
유형
array

17.1.78. .spec.processor.advanced.secondaryNetworks[]

설명
유형
object
필수 항목
  • 인덱스
  • name
Expand
재산유형설명

인덱스

배열(문자열)

index는 포드를 인덱싱하는 데 사용할 필드 목록입니다. 클러스터 전체에서 고유한 Pod 식별자를 형성해야 합니다. MAC , IP , Interface 중 하나일 수 있습니다. 'k8s.v1.cni.cncf.io/network-status' 주석에 없는 필드는 인덱스에 추가하면 안 됩니다.

name

string

이름은 'k8s.v1.cni.cncf.io/network-status'의 포드 주석에 표시된 네트워크 이름과 일치해야 합니다.

17.1.79. .spec.processor.deduper

설명
deduper를 사용하면 중복으로 식별된 흐름을 샘플링하거나 삭제하여 리소스 사용량을 절약할 수 있습니다.
유형
object
Expand
재산유형설명

mode

string

프로세서 중복 제거 모드를 설정합니다. 에이전트는 다른 노드에서 보고된 동일한 흐름을 중복 제거할 수 없으므로, 이 기능은 에이전트 기반 중복 제거에 추가됩니다.

- Drop을 사용하여 중복으로 간주되는 모든 흐름을 삭제하면 리소스 사용량을 더 많이 절약할 수 있지만 피어에서 사용된 네트워크 인터페이스나 네트워크 이벤트와 같은 일부 정보가 손실될 가능성이 있습니다.

- 샘플을 사용하여 중복으로 간주되는 흐름 중 기본값인 50에 하나의 흐름만 무작위로 유지합니다. 이는 모든 중복을 삭제하는 것과 모든 중복을 유지하는 것 사이의 타협안입니다. 이 샘플링 작업은 에이전트 기반 샘플링에 추가됩니다. 에이전트와 프로세서의 샘플링 값이 모두 50 인 경우, 결합된 샘플링은 1:2500입니다.

- 프로세서 기반 중복 제거를 끄려면 비활성화를 사용하세요.

sampling:

integer

샘플링은 중복 제거 모드가 샘플 일 때의 샘플링 간격입니다. 예를 들어, 값 50 은 50개 중 1개의 흐름이 샘플링된다는 것을 의미합니다.

17.1.80. .spec.processor.filters

설명
필터를 사용하면 사용자 정의 필터를 정의하여 생성된 흐름의 양을 제한할 수 있습니다. 이러한 필터는 eBPF 에이전트 필터( spec.agent.ebpf.flowFilter )보다 더 많은 유연성을 제공합니다. 예를 들어 Kubernetes 네임스페이스로 필터링할 수 있지만 성능 향상 폭은 적습니다.
유형
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 문서(자동 확장/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
필수 항목
  • thresholds
Expand
재산유형설명

그룹별

string

선택적인 그룹화 기준, 가능한 값은 다음과 같습니다: 노드 , 네임스페이스 , 워크로드 .

lowVolumeThreshold

string

낮은 볼륨 임계값을 사용하면 신호 대 잡음비를 개선하기 위해 트래픽 볼륨이 너무 낮은 메트릭을 무시할 수 있습니다. 이는 절대 속도(맥락에 따라 초당 바이트 또는 초당 패킷)로 제공됩니다. 제공되는 경우 float로 구문 분석할 수 있어야 합니다.

mode

string

mode는 이 특정 변형에 대한 상태 규칙 모드를 재정의합니다. 지정하지 않으면 상위 상태 규칙의 모드에서 상속됩니다. 가능한 값은 Alert,Recording 입니다.

thresholds

object

심각도별로 상태 규칙의 임계값입니다. 이는 경고가 발생하는 오류의 백분율로 표시됩니다. 이는 부동 소수점으로 구문 분석 가능해야 합니다. 경고 및 레코딩 모드 모두에 필요합니다.

trendDuration

string

상태 규칙 추세를 위해 기준 비교의 기간 간격입니다. 예를 들어, "2h"는 2시간 평균과 비교하는 것을 의미합니다. 기본값은 2시간입니다.

trendOffset

string

상태 규칙 추세를 위해 기준 비교에 대한 시간 오프셋입니다. 예를 들어, "1d"는 어제와 비교하는 것을 의미합니다. 기본값은 1d입니다.

17.1.88. .spec.processor.metrics.healthRules[].variants[].thresholds

설명
심각도별로 상태 규칙의 임계값입니다. 이는 경고가 발생하는 오류의 백분율로 표시됩니다. 이는 부동 소수점으로 구문 분석 가능해야 합니다. 경고 및 레코딩 모드 모두에 필요합니다.
유형
object
Expand
재산유형설명

심각

string

심각도 임계값이 심각합니다 . 중요 경고를 생성하지 않으려면 비워 두세요.

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 로 설정하면, 제공된CaFile 필드는 무시됩니다.

제공됨

object

유형이 제공됨 으로 설정된 경우의 TLS 구성입니다.

providedCaFile

object

유형이 제공됨 으로 설정된 경우 CA 파일에 대한 참조입니다.

type

string

TLS 구성 유형을 선택하세요:

- 비활성화 (기본값) - 엔드포인트에 TLS를 구성하지 않습니다. - 인증서 파일과 키 파일을 수동으로 제공 합니다 . [지원되지 않음(*)]. - 자동 - 주석을 사용하여 OpenShift Container Platform에서 자동 생성된 인증서를 사용합니다.

17.1.91. .spec.processor.metrics.server.tls.provided

설명
유형이 제공됨 으로 설정된 경우의 TLS 구성입니다.
유형
object
Expand
재산유형설명

certFile

string

certFile은 구성 맵이나 비밀 내의 인증서 파일 이름에 대한 경로를 정의합니다.

certKey

string

certKey는 구성 맵 또는 비밀 내의 인증서 개인 키 파일 이름에 대한 경로를 정의합니다. 키가 필요하지 않으면 생략합니다.

name

string

인증서가 포함된 구성 맵 또는 시크릿의 이름입니다.

네임스페이스

string

인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본적으로 Network Observability가 배포된 것과 동일한 네임스페이스를 사용합니다. 네임스페이스가 다르면 구성 맵이나 비밀이 복사되어 필요에 따라 마운트될 수 있습니다.

type

string

인증서 참조 유형: configmap 또는 secret .

17.1.92. .spec.processor.metrics.server.tls.providedCaFile

설명
유형이 제공됨 으로 설정된 경우 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

요청은 필요한 최소 컴퓨팅 리소스 양을 설명합니다. 컨테이너에 대한 요청이 생략되면 명시적으로 지정되어 있으면 제한이 기본값으로 설정되고, 그렇지 않으면 구현에서 정의한 값이 기본값으로 설정됩니다. 요청은 한도를 초과할 수 없습니다. 자세한 정보: 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

openShiftAutoDetect를 true 로 설정하면 OpenShift Container Platform 설치 구성과 클러스터 네트워크 운영자 구성에 따라 머신, 포드 및 서비스 서브넷을 자동으로 감지할 수 있습니다. 간접적으로 이는 외부 트래픽을 정확하게 감지하는 방법입니다. 해당 서브넷에 대한 레이블이 지정되지 않은 흐름은 클러스터 외부에 있습니다. 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는 콘솔 플러그인에서 메트릭을 가져오는 데 사용되는 쿼리어 구성과 같은 Prometheus 설정을 정의합니다.
유형
object
Expand
재산유형설명

querier

object

콘솔 플러그인에서 사용되는 클라이언트 설정 등의 Prometheus 쿼리 구성입니다.

17.1.99. .spec.prometheus.querier

설명
콘솔 플러그인에서 사용되는 클라이언트 설정 등의 Prometheus 쿼리 구성입니다.
유형
object
필수 항목
  • mode
Expand
재산유형설명

enable

boolean

enabletrue 인 경우, 콘솔 플러그인은 가능한 한 Loki 대신 Prometheus에서 흐름 메트릭을 쿼리합니다. 이 기능은 기본적으로 활성화되어 있습니다. 이 기능을 비활성화하려면 false 로 설정하세요. 콘솔 플러그인은 Loki나 Prometheus를 메트릭의 데이터 소스로 사용하거나( spec.loki 참조) 둘 다를 사용할 수 있습니다. 모든 질문이 로키에서 프로메테우스로 옮겨질 수 있는 것은 아닙니다. 따라서 Loki가 비활성화되면 플러그인의 일부 기능(예: 포드별 정보 가져오기, 원시 흐름 보기)도 비활성화됩니다. Prometheus와 Loki가 모두 활성화된 경우 Prometheus가 우선하고 Loki는 Prometheus가 처리할 수 없는 쿼리에 대한 대체 수단으로 사용됩니다. 두 가지 모두 비활성화된 경우 콘솔 플러그인이 배포되지 않습니다.

manual

object

수동 모드를 위한 Prometheus 구성.

mode

string

모드는 네트워크 관찰성 메트릭을 저장하는 Prometheus 설치 유형에 따라 설정해야 합니다.

- 자동 구성을 사용해 자동으로 구성해보세요. OpenShift Container Platform에서 OpenShift Container Platform 클러스터 모니터링의 Thanos querier를 사용합니다.

- 수동 설정에 수동 사용.

timeout

string

timeout 은 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

certFile은 구성 맵이나 비밀 내의 인증서 파일 이름에 대한 경로를 정의합니다.

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

certFile은 구성 맵이나 비밀 내의 인증서 파일 이름에 대한 경로를 정의합니다.

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

certFile은 구성 맵이나 비밀 내의 인증서 파일 이름에 대한 경로를 정의합니다.

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

certFile은 구성 맵이나 비밀 내의 인증서 파일 이름에 대한 경로를 정의합니다.

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은 FlowMetric의 원하는 상태를 정의합니다. 제공된 API를 사용하면 이러한 지표를 사용자의 요구 사항에 맞게 사용자 정의할 수 있습니다.

새로운 지표를 추가하거나 기존 레이블을 수정할 때는 Prometheus 워크로드의 메모리 사용량을 주의 깊게 모니터링해야 합니다. 이는 잠재적으로 큰 영향을 미칠 수 있기 때문입니다. https://rhobs-handbook.netlify.app/products/openshiftmonitoring/telemetry.md/#what-is-the-cardinality-of-a-metric 참조

모든 네트워크 관찰성 지표의 기수를 확인하려면 promql : count({ name =~"netobserv.*"}) by ( name ) 을 실행합니다.

18.1.1. .metadata

설명
표준 객체의 메타데이터. 자세한 정보: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
유형
object

18.1.2. .spec

설명

FlowMetricSpec은 FlowMetric의 원하는 상태를 정의합니다. 제공된 API를 사용하면 이러한 지표를 사용자의 요구 사항에 맞게 사용자 정의할 수 있습니다.

새로운 지표를 추가하거나 기존 레이블을 수정할 때는 Prometheus 워크로드의 메모리 사용량을 주의 깊게 모니터링해야 합니다. 이는 잠재적으로 큰 영향을 미칠 수 있기 때문입니다. https://rhobs-handbook.netlify.app/products/openshiftmonitoring/telemetry.md/#what-is-the-cardinality-of-a-metric 참조

모든 네트워크 관찰성 지표의 기수를 확인하려면 promql : count({ name =~"netobserv.*"}) by ( name ) 을 실행합니다.

유형
object
필수 항목
  • type
Expand
재산유형설명

buckets

배열(문자열)

유형 이 "히스토그램"인 경우 사용할 버킷 목록입니다. 목록은 부동 소수점으로 구문 분석될 수 있어야 합니다. 설정하지 않으면 Prometheus 기본 버킷이 사용됩니다.

charts

array

대시보드 메뉴의 관리자 보기에서 OpenShift Container Platform Console에 대한 차트 구성입니다.

방향

string

유입, 유출 또는 모든 방향의 흐름을 필터링합니다. Ingress 로 설정하면 FlowDirection : 0|2 에 정규 표현식 필터를 추가하는 것과 같습니다. Egress 로 설정하면 FlowDirection 에 정규 표현식 필터를 추가하는 것과 같습니다: 1|2 .

divider

string

0이 아닌 경우 값의 스케일 인수(divider)입니다. 메트릭 값 = 흐름 값 / 분배기.

filters

array

필터는 어떤 흐름을 고려할지 제한하는 데 사용되는 필드와 값의 목록입니다. 사용 가능한 필드 목록은 다음 문서를 참조하세요: https://docs.redhat.com/en/documentation/openshift_container_platform/latest/html/network_observability/json-flows-format-reference .

단조롭게 하다

배열(문자열)

flatten은 Interfaces나 NetworkEvents와 같이 평면화되어야 하는 배열 유형 필드의 목록입니다. 평면화된 필드는 해당 필드의 항목당 하나의 메트릭을 생성합니다. 예를 들어, 바이트 카운터에서 인터페이스를 평면화할 때 인터페이스 [br-ex, ens5]가 있는 흐름은 br-ex 에 대한 카운터 하나를 증가시키고 ens5 에 대한 카운터 하나를 증가시킵니다.

help

string

Prometheus에 표시되는 지표의 도움말 텍스트입니다.

labels

배열(문자열)

레이블은 Prometheus 레이블로 사용해야 하는 필드 목록이며 차원이라고도 합니다(예: SrcK8S_Namespace ). 레이블을 선택하면 해당 메트릭의 세분성 수준과 쿼리 시점에 사용 가능한 집계가 결정됩니다. 이는 메트릭 기수에 영향을 미치므로 신중하게 수행해야 합니다( 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

객체(문자열)

생성된 메트릭 레이블에 흐름 필드와 다른 이름을 사용하려면 리맵 속성을 설정합니다. 원점 흐름 필드를 키로 사용하고, 원하는 레이블 이름을 값으로 사용합니다.

type

string

지표 유형: "카운터", "히스토그램" 또는 "게이지". 시간이 지남에 따라 증가하고 비율을 계산할 수 있는 값(예: 바이트 또는 패킷)에 대해 "카운터"를 사용합니다. 대기 시간과 같이 독립적으로 샘플링해야 하는 값에는 "히스토그램"을 사용합니다. 시간 경과에 따른 정확성이 필요하지 않은 다른 값에는 "게이지"를 사용합니다(게이지는 Prometheus가 메트릭을 가져올 때 N초마다 샘플링됩니다).

valueField

string

valueField 는 이 메트릭의 값으로 사용해야 하는 흐름 필드입니다(예: 바이트 ). 이 필드는 숫자 값을 가져야 합니다. 흐름당 특정 값을 지정하는 대신 흐름을 계산하려면 비워 두세요. 사용 가능한 필드 목록은 다음 문서를 참조하세요: https://docs.redhat.com/en/documentation/openshift_container_platform/latest/html/network_observability/json-flows-format-reference .

18.1.3. .spec.charts

설명
대시보드 메뉴의 관리자 보기에서 OpenShift Container Platform Console에 대한 차트 구성입니다.
유형
array

18.1.4. .spec.charts[]

설명
메트릭과 관련된 차트/대시보드 생성을 구성합니다.
유형
object
필수 항목
  • dashboardName
  • queries
  • title
  • type
Expand
재산유형설명

dashboardName

string

포함된 대시보드의 이름입니다. 이 이름이 기존 대시보드를 참조하지 않으면 새 대시보드가 생성됩니다.

queries

array

이 차트에 표시할 쿼리 목록입니다. 유형SingleStat 이고 여러 개의 쿼리가 제공되는 경우, 이 차트는 자동으로 여러 패널(쿼리당 하나)로 확장됩니다.

sectionName

string

포함된 대시보드 섹션의 이름입니다. 이 이름이 기존 섹션을 참조하지 않으면 새 섹션이 생성됩니다. sectionName 이 생략되거나 비어 있으면 차트는 글로벌 상단 섹션에 배치됩니다.

title

string

차트의 제목.

type

string

차트의 유형.

단위

string

이 차트의 단위입니다. 현재 지원되는 유닛은 일부에 불과합니다. 일반 번호를 사용하려면 비워 두세요.

18.1.5. .spec.charts[].queries

설명
이 차트에 표시할 쿼리 목록입니다. 유형SingleStat 이고 여러 개의 쿼리가 제공되는 경우, 이 차트는 자동으로 여러 패널(쿼리당 하나)로 확장됩니다.
유형
array

18.1.6. .spec.charts[].queries[]

설명
PromQL 쿼리를 구성합니다.
유형
object
필수 항목
  • 전설
  • promQL
  • top
Expand
재산유형설명

전설

string

이 차트에 표현된 각 시계열에 적용되는 쿼리 범례입니다. 여러 시계열이 표시되는 경우 각 시계열을 구별하는 범례를 설정해야 합니다. 다음 형식으로 수행할 수 있습니다: {{ Label }} . 예를 들어, promQLsum(rate($METRIC[2m])) by (Label1, Label2) 와 같이 레이블별로 시계열을 그룹화하는 경우 범례를 다음과 같이 작성할 수 있습니다. Label1={{ 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. 네트워크 흐름 형식 참조.

이는 네트워크 흐름 형식의 사양입니다. 이 형식은 Kafka 내보내기 기능이 구성될 때, Prometheus 메트릭 레이블에 사용될 때, 그리고 Loki 저장소에 내부적으로 사용될 때 사용됩니다.

"필터 ID" 열은 빠른 필터를 정의할 때 사용할 관련 이름을 보여줍니다( FlowCollector 사양의 spec.consolePlugin.quickFilters 참조).

"Loki 레이블" 열은 Loki를 직접 쿼리할 때 유용합니다. 레이블 필드는 스트림 선택기를 사용하여 선택해야 합니다.

"Cardinality" 열은 이 필드가 FlowMetrics API에서 Prometheus 레이블로 사용될 경우 암시적인 메트릭 카디널리티에 대한 정보를 제공합니다. 이 API 사용에 대한 자세한 내용은 FlowMetrics 문서를 참조하세요.

Expand
이름유형설명필터 ID로키 라벨기수OpenTelemetry

바이트

number

바이트 수

해당 없음

제공되지 않음

avoid

바이트

DnsErrno

number

DNS 추적기 ebpf 후크 함수에서 반환된 오류 번호

dns_errno

제공되지 않음

괜찮은

dns.errno

DnsFlags

number

DNS 레코드에 대한 DNS 플래그

해당 없음

제공되지 않음

괜찮은

dns.flags

DnsFlagsResponseCode

string

구문 분석된 DNS 헤더 RCODE 이름

dns_flag_response_code

제공되지 않음

괜찮은

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(Differentiated Services Code Point) 값

dscp

제공되지 않음

괜찮은

dscp

DstAddr

string

목적지 IP 주소(ipv4 또는 ipv6)

dst_address

제공되지 않음

avoid

destination.address

DstK8S_HostIP

string

대상 노드 IP

dst_host_address

제공되지 않음

괜찮은

destination.k8s.host.address

DstK8S_HostName

string

목적지 노드 이름

dst_host_name

제공되지 않음

괜찮은

destination.k8s.host.name

DstK8S_Name

string

Pod 이름, 서비스 이름 또는 노드 이름과 같은 대상 Kubernetes 객체의 이름입니다.

dst_name

제공되지 않음

주의 깊은

destination.k8s.name

DstK8S_Namespace

string

대상 네임스페이스

dst_namespace

제공됨

괜찮은

destination.k8s.namespace.name

DstK8S_NetworkName

string

대상 네트워크 이름

dst_network

제공되지 않음

괜찮은

해당 없음

DstK8S_OwnerName

string

배포 이름, StatefulSet 이름 등 대상 소유자의 이름입니다.

dst_owner_name

제공됨

괜찮은

destination.k8s.owner.name

DstK8S_OwnerType

string

배포, StatefulSet 등과 같은 대상 소유자의 종류

dst_kind

제공되지 않음

괜찮은

목적지.k8s.소유자.종류

DstK8S_Type

string

Pod, Service 또는 Node와 같은 대상 Kubernetes 객체의 종류입니다.

dst_kind

제공됨

괜찮은

destination.k8s.kind

DstK8S_Zone

string

목적지 가용성 영역

dst_zone

제공됨

괜찮은

destination.zone

DstMac

string

대상 MAC 주소

dst_mac

제공되지 않음

avoid

destination.mac

DstPort

number

destination.port

dst_port

제공되지 않음

주의 깊은

destination.port

DstSubnetLabel

string

대상 서브넷 레이블

dst_subnet_label

제공되지 않음

괜찮은

destination.subnet.label

플래그

string[]

RFC-9293에 따른 흐름에 포함된 TCP 플래그 목록과 다음 패킷별 조합을 나타내는 추가 사용자 정의 플래그입니다.
- SYN_ACK
- 핀_액세스
- RST_ACK

tcp_flags

제공되지 않음

주의 깊은

tcp.flags

FlowDirection

number

흐름은 노드 관찰 지점에서 해석되는 방향입니다.
- 0: Ingress(노드 관찰 시점에서 들어오는 트래픽)
- 1: Egress(노드 관찰 지점의 트래픽 제외)
- 2단계(동일 소스 및 대상 노드가 있음) 중 하나일 수 있습니다.

node_direction

제공됨

괜찮은

host.direction

IPSecStatus

string

IPsec 암호화 상태(커널 xfrm_output 함수에서 제공) 또는 복호화 상태(xfrm_input을 통해 수신 시)

ipsec_status

제공되지 않음

괜찮은

해당 없음

IcmpCode

number

--icmp_code

icmp_code

제공되지 않음

괜찮은

icmp.code

IcmpType

number

--icmp_type

icmp_type

제공되지 않음

괜찮은

icmp.type

IfDirections

number[]

네트워크 인터페이스 관찰 지점의 흐름 방향입니다.
- 0: Ingress(interface incoming traffic)
- 1: Egress(interface outgoing traffic) 중 하나일 수 있습니다.

ifdirections

제공되지 않음

괜찮은

interface.directions

인터페이스

string[]

네트워크 인터페이스

interfaces

제공되지 않음

주의 깊은

interface.names

K8S_ClusterName

string

클러스터 이름 또는 식별자

cluster_name

제공됨

괜찮은

k8s.cluster.name

K8S_FlowLayer

string

흐름 계층: 'app' 또는 'infra'

flow_layer

제공됨

괜찮은

k8s.layer

NetworkEvents

object[]

네트워크 정책 작업과 같은 중첩된 필드로 구성된 네트워크 이벤트:
- 기능(예: 네트워크 정책에 대한 "acl")
- 유형(예: "AdminNetworkPolicy")
- 네임스페이스(이벤트가 적용되는 네임스페이스가 있는 경우)
- 이름(이벤트를 트리거한 리소스의 이름)
- 작업(예: "허용" 또는 "삭제")
- 방향(진입 또는 출구)

network_events

제공되지 않음

avoid

해당 없음

패킷

number

패킷 수

해당 없음

제공되지 않음

avoid

패킷

PktDropBytes

number

커널에 의해 삭제된 바이트 수

해당 없음

제공되지 않음

avoid

drops.bytes

PktDropLatestDropCause

string

최근 하락 원인

pkt_drop_cause

제공되지 않음

괜찮은

drops.latestcause

PktDropLatestFlags

number

마지막으로 삭제된 패킷의 TCP 플래그

해당 없음

제공되지 않음

괜찮은

drops.latestflags

PktDropLatestState

string

마지막으로 삭제된 패킷의 TCP 상태

pkt_drop_state

제공되지 않음

괜찮은

drops.lateststate

PktDropPackets

number

커널에 의해 삭제된 패킷 수

해당 없음

제공되지 않음

avoid

drops.packets

프로토

number

L4 프로토콜

protocol

제공되지 않음

괜찮은

protocol

sampling:

number

이 흐름에 사용된 샘플링 간격

해당 없음

제공되지 않음

괜찮은

해당 없음

SrcAddr

string

소스 IP 주소(ipv4 또는 ipv6)

src_address

제공되지 않음

avoid

source.address

SrcK8S_HostIP

string

소스 노드 IP

src_host_address

제공되지 않음

괜찮은

source.k8s.host.address

SrcK8S_HostName

string

소스 노드 이름

src_host_name

제공되지 않음

괜찮은

source.k8s.host.name

SrcK8S_Name

string

Pod 이름, 서비스 이름 또는 노드 이름과 같은 소스 Kubernetes 객체의 이름입니다.

src_name

제공되지 않음

주의 깊은

source.k8s.name

SrcK8S_Namespace

string

소스 네임스페이스

src_namespace

제공됨

괜찮은

source.k8s.namespace.name

SrcK8S_NetworkName

string

소스 네트워크 이름

src_network

제공되지 않음

괜찮은

해당 없음

SrcK8S_OwnerName

string

배포 이름, StatefulSet 이름 등 소스 소유자의 이름입니다.

src_owner_name

제공됨

괜찮은

source.k8s.owner.name

SrcK8S_OwnerType

string

배포, StatefulSet 등과 같은 소스 소유자의 종류

src_kind

제공되지 않음

괜찮은

source.k8s.owner.kind

SrcK8S_Type

string

Pod, Service 또는 Node와 같은 소스 Kubernetes 객체의 종류입니다.

src_kind

제공됨

괜찮은

source.k8s.kind

SrcK8S_Zone

string

소스 가용성 영역

src_zone

제공됨

괜찮은

source.zone

SrcMac

string

소스 MAC 주소

src_mac

제공되지 않음

avoid

source.mac

SrcPort

number

소스 포트

src_port

제공되지 않음

주의 깊은

source.port

SrcSubnetLabel

string

소스 서브넷 레이블

src_subnet_label

제공되지 않음

괜찮은

source.subnet.label

TimeFlowEndMs

number

이 흐름의 종료 타임스탬프(밀리초)

해당 없음

제공되지 않음

avoid

시간의 흐름 끝

TimeFlowRttNs

number

TCP Smoothed Round Trip Time(SRTT), 나노초 단위

time_flow_rtt

제공되지 않음

avoid

tcp.rtt

TimeFlowStartMs

number

이 흐름의 시작 타임스탬프(밀리초)

해당 없음

제공되지 않음

avoid

timeflowstart

TimeReceived

number

이 흐름이 흐름 수집기에 의해 수신되고 처리된 타임스탬프(초)

해당 없음

제공되지 않음

avoid

시간 수신

우드너스

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 , heartbeat , endConnection

type

제공됨

괜찮은

해당 없음

20장. 네트워크 관찰성 문제 해결

네트워크 관찰 운영자 및 해당 구성 요소와 관련된 일반적인 문제를 해결하기 위한 진단 작업을 수행합니다.

20.1. must-gather 툴 사용

must-gather 툴을 사용하여 클러스터 문제 해결을 지원하기 위해 Pod 로그 및 구성 세부 정보를 포함하여 Network Observability Operator 리소스에 대한 진단 정보를 수집합니다.

프로세스

  1. must-gather 데이터를 저장하려는 디렉터리로 이동합니다.
  2. 클러스터 전체의 필수 수집 리소스를 수집하려면 다음 명령을 실행하세요.

    $ 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. 다음 명령을 실행하여 콘솔 포드의 상태가 실행 중인지 확인하세요.

    $ oc get pods -n openshift-console -l app=console
  5. 다음 명령을 실행하여 콘솔 포드를 다시 시작합니다.

    $ oc delete pods -n openshift-console -l app=console
  6. 브라우저 캐시와 기록을 지우세요.
  7. 다음 명령을 실행하여 네트워크 관찰 플러그인 포드의 상태를 확인하세요.

    $ oc get pods -n netobserv -l app=netobserv-plugin

    출력 예

    NAME                                READY   STATUS    RESTARTS   AGE
    netobserv-plugin-68c7bbb9bb-b69q6   1/1     Running   0          21s

  8. 다음 명령을 실행하여 네트워크 관찰 플러그인 포드의 로그를 확인하세요.

    $ 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에 올바르게 연결되지 않을 수 있습니다. Kafka에서 네트워크 흐름을 사용하지 않는 Flowlogs-pipeline 포드를 수동으로 다시 시작합니다.

프로세스

  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 또는 excludeInterfaces 부분을 수동으로 제거합니다.

프로세스

  1. 인터페이스 [ 'br-int', 'br-ex' ] 필드를 제거합니다. 이를 통해 에이전트는 모든 인터페이스에서 정보를 가져올 수 있습니다. 또는 eth0 과 같이 Layer-3 인터페이스를 지정할 수 있습니다. 다음 명령을 실행합니다.

    $ 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. 네트워크 관찰 컨트롤러 관리자 Pod의 메모리가 부족합니다.

컨트롤러 관리자 Pod가 메모리가 부족하지 않도록 Subscription 오브젝트의 메모리 제한을 늘려 Network Observability Operator의 메모리 문제를 해결합니다.

Subscription 객체의 spec.config.resources.limits.memory 사양을 편집하여 Network Observability Operator의 메모리 한도를 늘릴 수 있습니다.

프로세스

  1. 웹 콘솔에서 Operator설치된 Operator로 이동합니다.
  2. 네트워크 관찰성을 클릭한 다음 구독을 선택합니다.
  3. 작업 메뉴에서 구독 편집을 클릭합니다.

    1. 또는 다음 명령을 실행하여 CLI를 사용하여 Subscription 개체에 대한 YAML 구성을 열 수 있습니다.

      $ oc edit subscription netobserv-operator -n openshift-netobserv-operator
  4. 구독 객체를 편집하여 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 오류를 해결하여 흐름 데이터가 메모리 제한 내에 유지되도록 합니다.

네트워크 관찰을 통해 전송된 네트워크 흐름 데이터가 구성된 최대 메시지 크기를 초과하는 경우 Loki는 ResourceExhausted 오류를 반환할 수 있습니다. Red Hat Loki Operator를 사용하는 경우 최대 메시지 크기는 100MiB로 구성됩니다.

프로세스

  1. Operators설치된 Operators로 이동하여 프로젝트 드롭다운 메뉴에서 모든 프로젝트를 확인합니다.
  2. 제공된 API 목록에서 네트워크 관찰 연산자를 선택합니다.
  3. Flow Collector를 클릭한 다음 YAML 보기 탭을 클릭합니다.

    1. Loki Operator를 사용하는 경우 spec.loki.batchSize 값이 98MiB를 초과하지 않는지 확인하세요.
    2. Grafana Loki와 같이 Red Hat Loki Operator와 다른 Loki 설치 방법을 사용하는 경우 Grafana Loki 서버 설정의 grpc_server_max_recv_msg_size가 FlowCollector 리소스 spec.loki.batchSize 값보다 높은지 확인하세요. 그렇지 않은 경우 grpc_server_max_recv_msg_size 값을 늘리거나 spec.loki.batchSize 값을 줄여서 한도보다 낮게 설정해야 합니다.
  4. FlowCollector 를 편집한 경우 저장을 클릭합니다.

20.8. 로키 빈 반지 오류

Pod 상태를 확인하거나, 이전 영구 볼륨 클레임을 지우거나, 포드를 다시 시작하여 연결을 복원하고 네트워크 흐름이 올바르게 저장 및 표시되는지 확인하여 Loki "빈 링" 오류를 조사하고 해결합니다.

Loki "빈 링" 오류는 흐름이 Loki에 저장되지 않고 웹 콘솔에 표시되지 않는 결과를 낳습니다. 이 오류는 다양한 상황에서 발생할 수 있습니다. 이 모든 문제를 해결할 수 있는 단일한 해결책은 존재하지 않습니다. Loki Pod의 로그를 조사하고 LokiStack 이 정상이고 준비되었는지 확인하기 위해 취할 수 있는 몇 가지 조치가 있습니다.

이 오류가 관찰되는 상황 중 일부는 다음과 같습니다.

  • LokiStack을 제거한 후 같은 네임스페이스에 다시 설치하면 이전 PVC가 제거되지 않아 이 오류가 발생할 수 있습니다.

    • 조치 : LokiStack을 다시 제거하고 PVC를 제거한 다음 LokiStack을 다시 설치해보세요.
  • 인증서 회전 후 이 오류로 인해 flowlogs-pipelineconsole-plugin 포드와의 통신이 방해받을 수 있습니다.

    • 조치 : 포드를 다시 시작하여 연결을 복구할 수 있습니다.

20.9. LokiStack 속도 제한 오류

Loki 속도 제한 오류를 해결하고 LokiStack 리소스를 업데이트하여 네트워크 관찰 기능 데이터 스트림에 대한 수집 속도 및 버스트 제한을 늘려 데이터 손실을 방지합니다.

Loki 테넌트에 속도 제한을 적용하면 데이터가 일시적으로 손실될 가능성이 있으며 429 오류가 발생할 수 있습니다. 스트림을 수집하려고 시도하는 동안 스트림당 속도 제한(limit:xMB/sec)을 초과했습니다 . 이 오류가 발생하면 알림을 받도록 알림을 설정하는 것이 좋습니다. 자세한 내용은 이 섹션의 추가 리소스의 "NetObserv 대시보드에 대한 Loki 속도 제한 경고 생성"을 참조하십시오.

다음 절차에 표시된 대로 perStreamRateLimitperStreamRateLimitBurst 사양을 사용하여 LokiStack CRD를 업데이트할 수 있습니다.

프로세스

  1. Operators설치된 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 사양을 업데이트하면 클러스터의 포드가 다시 시작되고 429 속도 제한 오류가 더 이상 발생하지 않습니다.

20.10. 대규모 쿼리를 실행하면 Loki 오류가 발생합니다.

인덱싱된 필터를 사용하여 대규모 쿼리를 실행할 때 Loki 시간 초과 및 요청 오류를 완화하고, Prometheus를 긴 시간 범위로 사용하거나, 사용자 지정 메트릭을 생성하거나, Loki 및 FlowCollector 성능 설정을 조정하는 방법을 설명합니다.

장시간 동안 큰 쿼리를 실행하면 시간 초과나 처리되지 않은 요청이 너무 많아지는 등의 Loki 오류가 발생할 수 있습니다. 이 문제에 대한 완벽한 해결책은 없지만, 이를 완화할 수 있는 방법은 여러 가지가 있습니다.

인덱스 필터를 추가하려면 쿼리를 조정하세요.
Loki 쿼리를 사용하면 인덱싱된 필드나 레이블과 인덱싱되지 않은 필드나 레이블을 모두 쿼리할 수 있습니다. 레이블에 필터가 포함된 쿼리는 더 나은 성능을 보입니다. 예를 들어, 인덱싱된 필드가 아닌 특정 Pod를 쿼리하는 경우 쿼리에 해당 네임스페이스를 추가할 수 있습니다. 인덱싱된 필드 목록은 Loki 레이블 열의 "네트워크 흐름 형식 참조"에서 찾을 수 있습니다.
Loki보다는 Prometheus에 쿼리를 보내는 것을 고려하세요.
Prometheus는 Loki보다 넓은 시간 범위에 대한 쿼리를 처리하는 데 더 적합합니다. 하지만 Loki 대신 Prometheus를 사용할 수 있는지 여부는 사용 사례에 따라 달라집니다. 예를 들어, Prometheus의 쿼리는 Loki의 쿼리보다 훨씬 빠르며, 긴 시간 범위는 성능에 영향을 미치지 않습니다. 그러나 Prometheus 메트릭에는 Loki의 흐름 로그만큼 많은 정보가 포함되어 있지 않습니다. Network Observability OpenShift 웹 콘솔은 쿼리가 호환되는 경우 Loki보다 Prometheus를 자동으로 선호합니다. 호환되지 않는 경우 기본적으로 Loki를 사용합니다. 쿼리가 Prometheus에서 실행되지 않으면 일부 필터나 집계를 변경하여 전환할 수 있습니다. OpenShift 웹 콘솔에서 Prometheus 사용을 강제할 수 있습니다. 호환되지 않는 쿼리가 실패하면 오류 메시지가 표시되며, 이를 통해 쿼리를 호환 가능하게 만들기 위해 어떤 레이블을 변경해야 할지 파악하는 데 도움이 됩니다. 예를 들어, 필터나 집계를 Resource 또는 Pods 에서 Owner 로 변경합니다.
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
맨 위로 이동