네트워크 관찰 기능

OpenShift Container Platform 4.15

Network Observability Operator

Red Hat OpenShift Documentation Team

초록

이 문서에서는 OpenShift Container Platform 클러스터의 네트워크 트래픽 흐름을 관찰하고 분석하는 데 사용할 수 있는 Network Observability Operator를 사용하는 방법을 설명합니다.

1장. Network Observability Operator 릴리스 노트

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

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

Network Observability Operator 에 대한 개요는 Network Observability Operator 정보를 참조하십시오.

1.1. Network Observability Operator 1.5.0

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

Network Observability Operator 1.5.0

1.1.1. 새로운 기능 및 개선 사항

1.1.1.1. DNS 추적 개선 사항

1.5에서는 이제 UDP 외에도 TCP 프로토콜이 지원됩니다. 새 대시보드는 네트워크 트래픽 페이지의 개요 보기에도 추가됩니다. 자세한 내용은 DNS 추적 구성 및 DNS 추적 작업을 참조하십시오.

1.1.1.2. Round-trip Time (RTT)

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

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

Observe → Dashboards → NetObserv 의 네트워크 관찰 기능 지표 대시보드에는 Prometheus 경고를 생성하는 데 사용할 수 있는 새로운 메트릭 유형이 있습니다. 이제 includeList 사양에 사용 가능한 메트릭을 정의할 수 있습니다. 이전 릴리스에서는 이러한 지표가 ignoreTags 사양에 정의되어 있습니다. 이러한 지표의 전체 목록은 Network Observability Metrics 를 참조하십시오.

1.1.1.4. Loki 없이 네트워크 Observability 개선 사항

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

1.1.1.5. 가용성 영역

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

1.1.1.6. 주요 개선 사항

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

성능 개선

spec.agent.ebpf.kafkaBatchSize 기본값은 Kafka를 사용할 때 eBPF 성능을 개선하기 위해 10MB 에서 1MB 로 변경됩니다.
중요
기존 설치에서 업그레이드할 때 이 새 값은 구성에 자동으로 설정되지 않습니다. 업그레이드 후 eBPF 에이전트 메모리 사용을 사용하여 성능 회귀를 모니터링하는 경우 kafkaBatchSize 를 새 값으로 줄이는 것이 좋습니다.

웹 콘솔 개선 사항:

DNS 및 RTT에 대한 개요 보기에 새 패널이 추가되었습니다: Min, Max, P90, P99.
새로운 패널 디스플레이 옵션이 추가되었습니다.
- 하나의 패널에 중점을 두고 다른 패널은 볼 수 있지만 더 작은 집중을 유지합니다.
- 그래프 유형을 전환합니다.
- top 및 Overall 을 표시합니다.
컬렉션 대기 시간 경고가 사용자 정의 시간 범위 팝업 창에 표시됩니다.
패널 관리 및 열 관리 팝업 창에 대한 가시성이 향상됩니다.
송신 QoS의 DSCP(Differentiated Services Code Point) 필드는 웹 콘솔 네트워크 트래픽 페이지에서 QoS DSCP를 필터링하는 데 사용할 수 있습니다.

구성 개선 사항:

spec.loki.mode 사양의 LokiStack 모드는 URL, TLS, 클러스터 역할 및 클러스터 역할 바인딩과 authToken 값을 자동으로 설정하여 설치를 간소화합니다. 수동 모드를 사용하면 이러한 설정 구성을 보다 효과적으로 제어할 수 있습니다.
API 버전은 flows.netobserv.io/v1beta1 에서 flows.netobserv.io/v1beta2 로 변경합니다.

1.1.2. 버그 수정

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

1.1.3. 확인된 문제

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

1.2. Network Observability Operator 1.4.2

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

2023:6787 네트워크 Observability Operator 1.4.2

1.2.1. CVE

1.3. Network Observability Operator 1.4.1

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

2023:5974 Network Observability Operator 1.4.1

1.3.1. CVE

1.3.2. 버그 수정

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

1.4. Network Observability Operator 1.4.0

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

RHSA-2023:5379 Network Observability Operator 1.4.0

1.4.1. 채널 제거

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

1.4.2. 새로운 기능 및 개선 사항

1.4.2.1. 주요 개선 사항

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

웹 콘솔 개선 사항:

쿼리 옵션에서 중복된 흐름을 표시할지 여부를 선택하기 위해 중복된 흐름 확인란이 추가됩니다.In the Query Options, the Duplicate flows check is added to choose whether or not to show duplicated flows.
One-way, Back-and-forth, 스왑 필터를 사용하여 소스 및 대상 트래픽을 필터링할 수 있습니다.
Observe → Dashboards → NetObserv 및 NetObserv/ Health 의 네트워크 관찰 기능 메트릭 대시보드는 다음과 같이 수정됩니다.
- NetObserv 대시보드에는 노드, 네임스페이스 및 워크로드별로 수신된 상위 바이트, 패킷, 패킷이 표시됩니다. 이 대시보드에서 흐름 그래프가 제거됩니다.
- NetObserv / Health 대시 보드에는 노드, 네임스페이스 및 워크로드당 최고 흐름률뿐만 아니라 흐름 오버헤드가 표시됩니다.
- 인프라 및 애플리케이션 메트릭은 네임스페이스 및 워크로드에 대한 분할 보기에 표시됩니다.

자세한 내용은 네트워크 Observability 메트릭 및 빠른 필터 를 참조하십시오.

구성 개선 사항:

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

자세한 내용은 Flow Collector 샘플 리소스 및 Flow Collector API 참조를 참조하십시오.

1.4.2.2. Loki 없이 Network Observability

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

1.4.2.3. DNS 추적

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

자세한 내용은 DNS 추적 구성 및 DNS 추적 작업을 참조하십시오.

1.4.2.4. SR-IOV 지원

SR-IOV(Single Root I/O Virtualization) 장치를 사용하여 클러스터에서 트래픽을 수집할 수 있습니다. 자세한 내용은 SR-IOV 인터페이스 트래픽 모니터링 구성을 참조하십시오.

1.4.2.5. IPFIX 내보내기 지원

이제 eBPF-enriched 네트워크 흐름을 IPFIX 수집기로 내보낼 수 있습니다. 자세한 내용은 보강된 네트워크 흐름 데이터 내보내기 를 참조하십시오.

1.4.2.6. 패킷 드롭

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

1.4.2.7. s390x 아키텍처 지원

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

1.4.3. 버그 수정

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

1.4.4. 확인된 문제

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

1.5. Network Observability Operator 1.3.0

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

RHSA-2023:3905 Network Observability Operator 1.3.0

1.5.1. 채널 사용 중단

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

1.5.2. 새로운 기능 및 개선 사항

1.5.2.1. 네트워크 Observability의 멀티 테넌시

시스템 관리자는 Loki에 저장된 흐름에 대해 개별 사용자 액세스 또는 그룹 액세스를 허용 및 제한할 수 있습니다. 자세한 내용은 네트워크 Observability 의 멀티 테넌시 를 참조하십시오.

1.5.2.2. 흐름 기반 메트릭 대시보드

이번 릴리스에서는 OpenShift Container Platform 클러스터의 네트워크 흐름에 대한 개요를 제공하는 새 대시보드가 추가되었습니다. 자세한 내용은 네트워크 Observability 메트릭 을 참조하십시오.

1.5.2.3. must-gather 툴 문제 해결

Network Observability Operator에 대한 정보를 이제 문제 해결을 위해 must-gather 데이터에 포함할 수 있습니다. 자세한 내용은 Network Observability must-gather 를 참조하십시오.

1.5.2.4. 여러 아키텍처 지원

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

1.5.3. 더 이상 사용되지 않는 기능

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

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

1.5.4. 버그 수정

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

1.5.5. 확인된 문제

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

1.6. Network Observability Operator 1.2.0

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

RHSA-2023:1817 Network Observability Operator 1.2.0

1.6.1. 다음 업데이트 준비

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

1.6.2. 새로운 기능 및 개선 사항

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

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

1.6.2.2. 대화 추적

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

1.6.2.3. 네트워크 Observability 상태 경고

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

1.6.3. 버그 수정

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

1.6.4. 알려진 문제

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

1.6.5. 주요 기술 변경 사항

이전에는 사용자 정의 네임스페이스를 사용하여 Network Observability Operator를 설치할 수 있었습니다. 이번 릴리스에서는 ClusterServiceVersion 을 변경하는 변환 Webhook 가 도입되었습니다. 이러한 변경으로 인해 사용 가능한 모든 네임스페이스가 더 이상 나열되지 않습니다. 또한 Operator 지표 컬렉션을 활성화하려면 openshift-operators 네임스페이스와 같이 다른 Operator와 공유하는 네임스페이스를 사용할 수 없습니다. 이제 Operator를 openshift-netobserv-operator 네임스페이스에 설치해야 합니다. 이전에 사용자 정의 네임스페이스를 사용하여 Network Observability Operator를 설치한 경우 새 Operator 버전으로 자동 업그레이드할 수 없습니다. 이전에 사용자 정의 네임스페이스를 사용하여 Operator를 설치한 경우 설치된 Operator 인스턴스를 삭제하고 openshift-netobserv-operator 네임스페이스에 Operator를 다시 설치해야 합니다. 일반적으로 사용되는 netobserv 네임스페이스와 같은 사용자 정의 네임스페이스는 FlowCollector, Loki, Kafka 및 기타 플러그인에 계속 사용할 수 있습니다. (NETOBSERV-907)(NETOBSERV-956)

1.7. Network Observability Operator 1.1.0

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

RHSA-2023:0786 Network Observability Operator 보안 권고 업데이트

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

1.7.1. 버그 수정

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

2장. 네트워크 Observability 정보

Red Hat은 클러스터 관리자에게 OpenShift Container Platform 클러스터의 네트워크 트래픽을 관찰할 수 있는 Network Observability Operator를 제공합니다. Network Observability Operator는 eBPF 기술을 사용하여 네트워크 흐름을 생성합니다. 그런 다음 OpenShift Container Platform 정보로 네트워크 흐름이 강화되고 Loki에 저장됩니다. 자세한 정보 및 문제 해결을 위해 OpenShift Container Platform 콘솔에서 저장된 네트워크 흐름 정보를 보고 분석할 수 있습니다.

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

Loki Operator: Loki는 수집된 모든 흐름을 저장하는 데 사용되는 백엔드입니다. Network Observability Operator에서 사용할 Loki를 설치하는 것이 좋습니다. Loki 없이 Network Observability 를 사용하도록 선택할 수 있지만 링크된 섹션에 설명된 대로 이 작업을 수행하는 데 몇 가지 고려 사항이 있습니다. Loki를 설치하도록 선택하는 경우 Red Hat에서 지원하므로 Loki Operator를 사용하는 것이 좋습니다.
Grafana Operator: Grafana Operator와 같은 오픈 소스 제품을 사용하여 사용자 정의 대시보드 및 쿼리 기능을 생성하기 위해 Grafana를 설치할 수 있습니다. Red Hat은 Grafana Operator를 지원하지 않습니다.
AMQ Streams Operator: Kafka는 대규모 배포를 위해 OpenShift Container Platform 클러스터에서 확장성, 복원력 및 고가용성을 제공합니다. Kafka를 사용하도록 선택하는 경우 Red Hat에서 지원하므로 AMQ Streams Operator를 사용하는 것이 좋습니다.

2.2. Network Observability Operator

Network Observability Operator는 Flow Collector API 사용자 정의 리소스 정의를 제공합니다. Flow Collector 인스턴스는 설치 중에 생성되며 네트워크 흐름 컬렉션을 구성할 수 있습니다. 흐름 수집기 인스턴스는 Loki에 저장하기 전에 네트워크 흐름이 수집되고 Kubernetes 메타데이터로 보강되는 모니터링 파이프라인을 구성하는 Pod 및 서비스를 배포합니다. 데몬 세트 오브젝트로 배포된 eBPF 에이전트는 네트워크 흐름을 생성합니다.

2.3. OpenShift Container Platform 콘솔 통합

OpenShift Container Platform 콘솔 통합은 개요, 토폴로지 보기 및 트래픽 흐름 테이블을 제공합니다.

2.3.1. 네트워크 Observability 지표 대시보드

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

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

2.3.2. 네트워크 Observability 토폴로지 보기

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

2.3.3. 트래픽 흐름 테이블

트래픽 흐름 테이블 뷰는 원시 흐름, 집계되지 않은 필터링 옵션 및 구성 가능한 열에 대한 뷰를 제공합니다. OpenShift Container Platform 콘솔은 네트워크 흐름 데이터 및 트래픽 양을 표시하는 트래픽 흐름 탭을 제공합니다.

3장. Network Observability Operator 설치

Loki를 설치하는 것은 Network Observability Operator를 사용하는 데 권장되는 전제 조건입니다. Loki 없이 Network Observability 를 사용하도록 선택할 수 있지만 이전에 연결된 섹션에 설명된 몇 가지 고려 사항이 있습니다.

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

참고

Loki Operator는 LokiStack 로그 저장소를 구성하는 데도 사용할 수 있습니다. Network Observability Operator에는 로깅과 별도로 전용 LokiStack이 필요합니다.

3.1. Loki 없이 Network Observability

Loki 설치 단계를 수행하지 않고 "Network Observability Operator 설치"로 직접 건너뛰어 Loki 없이 Network Observability를 사용할 수 있습니다. 흐름만 Kafka 소비자 또는 IPFIX 수집기로 내보내거나 대시보드 메트릭만 필요한 경우 Loki를 설치하거나 Loki에 스토리지를 제공할 필요가 없습니다. Loki가 없으면 Observe 아래에 네트워크 트래픽 패널이 없으므로 개요 차트, 흐름 테이블 또는 토폴로지가 없습니다. 다음 표에서는 Loki와 사용 가능한 기능을 비교합니다.

표 3.1. Loki와의 기능 가용성 비교
	Loki 사용	Loki 없이
내보내기
흐름 기반 메트릭 및 대시보드
트래픽 흐름 개요, 표 및 토폴로지 보기
빠른 필터
OpenShift Container Platform 콘솔 네트워크 트래픽 탭 통합

추가 리소스

강화된 네트워크 흐름 데이터를 내보냅니다.

3.2. Loki Operator 설치

Loki Operator 버전 5.7+ 는 Network Observabilty에서 지원되는 Loki Operator 버전입니다. 이러한 버전은 openshift-network 테넌트 구성 모드를 사용하여 LokiStack 인스턴스를 생성하고 네트워크 Observability에 대해 완전 자동 인증 및 권한 부여 지원을 제공하는 기능을 제공합니다. Loki를 설치하는 방법은 여러 가지가 있습니다. 한 가지 방법은 OpenShift Container Platform 웹 콘솔 Operator Hub를 사용하는 것입니다.

사전 요구 사항

지원되는 Log Store (AWS S3, Google Cloud Storage, Azure, Swift, Minio, OpenShift Data Foundation)
OpenShift Container Platform 4.10+
Linux Kernel 4.18+

프로세스

OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
사용 가능한 Operator 목록에서 Loki Operator 를 선택하고 설치를 클릭합니다.
설치 모드에서 클러스터의 모든 네임스페이스를 선택합니다.

검증

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

중요

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

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

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

웹 콘솔을 사용하여 프로젝트 → 모든 프로젝트 드롭다운으로 이동하여 프로젝트 생성 을 선택합니다. 프로젝트 이름을 netobserv 로 지정하고 생성 을 클릭합니다.
오른쪽 상단에 있는 가져오기 아이콘 + 로 이동합니다. YAML 파일을 편집기에 붙여넣습니다.
다음은 S3 스토리지에 대한 시크릿 YAML 파일의 예입니다.
```
apiVersion: v1
kind: Secret
metadata:
  name: loki-s3
  namespace: netobserv   1
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
```
1
이 설명서의 설치 예제에서는 모든 구성 요소에서 동일한 네임스페이스 netobserv 를 사용합니다. 선택적으로 다른 구성 요소에 다른 네임스페이스를 사용할 수 있습니다.

검증

시크릿을 생성하면 웹 콘솔에 워크로드 → 시크릿 아래에 표시되어야 합니다.

추가 리소스

흐름 수집기 API 참조
흐름 수집기 샘플 리소스
Loki 오브젝트 스토리지

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

웹 콘솔 또는 CLI를 사용하여 LokiStack을 배포하여 네임스페이스 또는 새 프로젝트를 생성할 수 있습니다.

프로세스

Operator → 설치된 Operator 로 이동하여 프로젝트 드롭다운에서 모든 프로젝트를 확인합니다.
Loki Operator 를 찾습니다. 세부 정보에서 제공된 API에서 LokiStack 을 선택합니다.
LokiStack 생성을 클릭합니다.
다음 필드가 양식 보기 또는 YAML 보기에 지정되었는지 확인합니다.
```
apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: loki
  namespace: netobserv   1
spec:
  size: 1x.small
  storage:
    schemas:
    - version: v12
      effectiveDate: '2022-06-01'
    secret:
      name: loki-s3
      type: s3
  storageClassName: gp3  2
  tenants:
    mode: openshift-network
```
1
이 설명서의 설치 예제에서는 모든 구성 요소에서 동일한 네임스페이스 netobserv 를 사용합니다. 선택적으로 다른 네임스페이스를 사용할 수 있습니다.
2
ReadWriteOnce 액세스 모드에서 클러스터에서 사용할 수 있는 스토리지 클래스 이름을 사용합니다. oc get storageclasses 를 사용하여 클러스터에서 사용 가능한 항목을 확인할 수 있습니다.
중요
클러스터 로깅에 사용되는 동일한 LokiStack 을 재사용해서는 안 됩니다.
생성을 클릭합니다.

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

중요

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

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

프로세스

다음 명령을 입력하여 새 그룹을 생성합니다.
```
$ oc adm groups new cluster-admin
```
다음 명령을 입력하여 원하는 사용자를 cluster-admin 그룹에 추가합니다.
```
$ oc adm groups add-users cluster-admin <username>
```
다음 명령을 입력하여 cluster-admin 사용자 역할을 그룹에 추가합니다.
```
$ oc adm policy add-cluster-role-to-group cluster-admin cluster-admin
```

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

광범위한 권한이 필요한 사용자가 많은 대규모 배포가 있는 경우 adminGroup 필드를 사용하여 사용자 지정 그룹을 생성할 수 있습니다. LokiStack CR의 adminGroups 필드에 지정된 그룹의 멤버인 사용자는 관리자로 간주됩니다. admin 사용자는 cluster-logging-application-view 역할도 할당한 경우 모든 네임스페이스의 모든 애플리케이션 로그에 액세스할 수 있습니다.

LokiStack CR의 예

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
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)

3.2.5. Loki 배포 크기 조정

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

표 3.2. Loki 크기 조정
	1x.demo	1x.extra-windows	1x.small	1x.medium
데이터 전송	데모만 사용	100GB/일	500GB/일	2TB/일
초당 쿼리(QPS)	데모만 사용	200ms에서 1-25 QPS	25-50 QPS (200ms)	25-75 QPS (200ms)
복제 요인	없음	2	2	2
총 CPU 요청	없음	14개의 vCPU	34 vCPU	54 vCPU
총 메모리 요청	없음	31Gi	67Gi	139Gi
총 디스크 요청	40Gi	430Gi	430Gi	590Gi

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

LokiStack 인스턴스는 구성된 크기에 따라 기본 설정과 함께 제공됩니다. 수집 및 쿼리 제한과 같은 일부 설정을 재정의할 수 있습니다. Loki 오류가 콘솔 플러그인에 표시되는 경우 또는 flowlogs-pipeline 로그에 업데이트할 수 있습니다. 웹 콘솔의 자동 경고는 이러한 제한에 도달할 때 이를 알려줍니다.

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

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

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

3.2.7. 네트워크 Observability에서 멀티 테넌시 활성화

Network Observability Operator의 멀티 테넌시를 사용하면 개별 사용자 액세스 또는 그룹 액세스를 Loki에 저장된 흐름에 대해 허용하고 제한할 수 있습니다. 프로젝트 관리자에 대한 액세스 권한이 활성화됩니다. 일부 네임스페이스에 대한 액세스 권한이 제한된 프로젝트 관리자는 해당 네임스페이스의 흐름에만 액세스할 수 있습니다.

사전 요구 사항

Loki Operator 버전 5.7이상이 설치되어 있어야 합니다.
프로젝트 관리자로 로그인해야 합니다.

프로세스

다음 명령을 실행하여 user1 에 읽기 권한을 부여합니다.
```
$ oc adm policy add-cluster-role-to-user netobserv-reader user1
```
이제 데이터는 허용된 사용자 네임스페이스로 제한됩니다. 예를 들어 단일 네임스페이스에 액세스할 수 있는 사용자는 이 네임스페이스 내부 및 이 네임스페이스로 이동하는 모든 흐름을 볼 수 있습니다. 프로젝트 관리자는 OpenShift Container Platform 콘솔의 관리자 화면에 액세스하여 네트워크 흐름 트래픽 페이지에 액세스할 수 있습니다.

3.3. Network Observability Operator 설치

OpenShift Container Platform 웹 콘솔 Operator Hub를 사용하여 Network Observability Operator를 설치할 수 있습니다. Operator를 설치할 때 FlowCollector CRD(사용자 정의 리소스 정의)를 제공합니다. FlowCollector 를 만들 때 웹 콘솔에서 사양을 설정할 수 있습니다.

중요

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

사전 요구 사항

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

참고

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

프로세스

OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
OperatorHub 의 사용 가능한 Operator 목록에서 Network Observability Operator 를 선택하고 설치를 클릭합니다.
이 네임스페이스에서 Operator 권장 클러스터 모니터링 활성화 확인란을 선택합니다.
Operators → 설치된 Operator로 이동합니다. 네트워크 Observability용 제공된 API에서 흐름 수집기 링크를 선택합니다.
Flow Collector 탭으로 이동하여 FlowCollector 만들기 를 클릭합니다. 양식 보기에서 다음 항목을 선택합니다.
1. spec.agent.ebpf.Sampling: 흐름에 대한 샘플링 크기를 지정합니다. 샘플링 크기가 감소하면 리소스 사용량에 더 큰 영향을 미칩니다. 자세한 내용은 "FlowCollector API 참조", spec.agent.ebpf 를 참조하십시오.
2. Loki를 사용하는 경우 다음 사양을 설정합니다.
  1. spec.loki.mode: LokiStack 모드로 설정하여 URL, TLS, 클러스터 역할 및 클러스터 역할 바인딩과 authToken 값을 자동으로 설정합니다. 또는 수동 모드를 사용하면 이러한 설정의 구성을 보다 효과적으로 제어할 수 있습니다.
  2. spec.loki.lokistack.name: 이를 LokiStack 리소스의 이름으로 설정합니다. 이 문서에서 loki 가 사용됩니다.
3. 선택 사항: 대규모 환경에 있는 경우 보다 탄력적이고 확장 가능한 방식으로 데이터를 전달하기 위해 Kafka로 FlowCollector 를 구성하는 것이 좋습니다. "Important Flow Collector 구성 고려 사항" 섹션의 " Kafka 스토리지를 사용하여 흐름 수집기 리소스 구성"을 참조하십시오.
4. 선택 사항: FlowCollector 를 만드는 다음 단계 전에 다른 선택적 설정을 구성합니다. 예를 들어 Loki를 사용하지 않도록 선택하는 경우 Kafka 또는 IPFIX로 내보내기 흐름을 구성할 수 있습니다. "Important Flow Collector 구성 고려 사항" 섹션에서 " Kafka 및 IPFIX로 보강된 네트워크 흐름 데이터 내보내기"를 참조하십시오.
생성을 클릭합니다.

검증

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

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

3.4. 중요한 흐름 수집기 구성 고려 사항

FlowCollector 인스턴스를 생성하면 재구성할 수 있지만 Pod가 종료되고 다시 생성되어 손상될 수 있습니다. 따라서 처음으로 FlowCollector 를 만들 때 다음 옵션을 구성할 수 있습니다.

Kafka를 사용하여 Flow Collector 리소스 구성
Kafka 또는 IPFIX에 보강된 네트워크 흐름 데이터 내보내기
SR-IOV 인터페이스 트래픽에 대한 모니터링 구성
대화 추적 작업
DNS 추적 작업
패킷 드롭 작업

추가 리소스

Flow Collector 사양 및 Network Observability Operator 아키텍처 및 리소스 사용에 대한 자세한 내용은 다음 리소스를 참조하십시오.

흐름 수집기 API 참조
흐름 수집기 샘플 리소스
리소스 고려 사항
Network Observability 컨트롤러 관리자 Pod 문제 해결
네트워크 Observability 아키텍처

3.5. Kafka 설치 (선택 사항)

Kafka Operator는 대규모 환경에서 지원됩니다. Kafka는 보다 탄력적이고 확장 가능한 방식으로 네트워크 흐름 데이터를 전달하기 위해 높은 처리량과 대기 시간이 짧은 데이터 피드를 제공합니다. Loki Operator 및 Network Observability Operator가 설치된 것처럼 Operator Hub에서 Kafka Operator를 Red Hat AMQ Streams 로 설치할 수 있습니다. Kafka를 스토리지 옵션으로 구성하려면 " FlowCollector 리소스 구성"을 참조하십시오.

참고

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

추가 리소스

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

3.6. Network Observability Operator 설치 제거

OpenShift Container Platform 웹 콘솔 Operator Hub를 사용하여 Network Observability Operator를 설치 제거하고 Operator → 설치된 Operator 영역에서 작업할 수 있습니다.

프로세스

FlowCollector 사용자 지정 리소스를 제거합니다.
1. 제공된 API 열에서 Network Observability Operator 옆에 있는 흐름 수집기 를 클릭합니다.
2. 클러스터 의 옵션 메뉴 를 클릭하고 FlowCollector 삭제 를 선택합니다.
Network Observability Operator를 설치 제거합니다.
1. Operator → 설치된 Operator 영역으로 돌아갑니다.
2. Network Observability Operator 옆에 있는 옵션 메뉴 를 클릭하고 Operator 설치 제거를 선택합니다.
3. 홈 → 프로젝트 및 openshift-netobserv-operator선택
4. 작업으로 이동하여 프로젝트 삭제를 선택합니다.
FlowCollector CRD(사용자 정의 리소스 정의)를 제거합니다.
1. 관리 → 클러스터 리소스 정의로 이동합니다.
2. FlowCollector 를 찾고 옵션 메뉴를 클릭합니다.
3. Delete CustomResourceDefinition 을 선택합니다.
  중요
  Loki Operator 및 Kafka는 설치된 경우 그대로 유지되며 별도로 제거해야 합니다. 또한 오브젝트 저장소에 남아 있는 데이터와 제거해야 하는 영구 볼륨이 있을 수 있습니다.

4장. OpenShift Container Platform의 Network Observability Operator

Network Observability는 네트워크 Observability eBPF 에이전트에서 생성하는 네트워크 트래픽 흐름을 수집하고 보강하기 위해 모니터링 파이프라인을 배포하는 OpenShift Operator입니다.

4.1. 상태 보기

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

프로세스

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

$ oc get flowcollector/cluster

출력 예

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

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

$ oc get pods -n netobserv

출력 예

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

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

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

$ oc get pods -n netobserv-privileged

출력 예

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

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

Loki Operator를 사용하는 경우 다음 명령을 입력하여 openshift-operators-redhat 네임스페이스에서 실행중인 Pod의 상태를 확인합니다.

$ oc get pods -n openshift-operators-redhat

출력 예

NAME                                                READY   STATUS    RESTARTS   AGE
loki-operator-controller-manager-5f6cff4f9d-jq25h   2/2     Running   0          18h
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

4.2. Network Observablity Operator 아키텍처

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

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

Kafka 옵션을 사용하는 경우 eBPF 에이전트는 네트워크 흐름 데이터를 Kafka로 전송하고 flowlogs-pipeline 은 다음 다이어그램에 표시된 대로 Loki로 보내기 전에 Kafka 주제에서 읽습니다.

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

oc describe 명령을 사용하여 상태를 검사하고 FlowCollector 의 세부 정보를 볼 수 있습니다.

프로세스

다음 명령을 실행하여 Network Observability Operator의 상태 및 구성을 확인합니다.
```
$ oc describe flowcollector/cluster
```

5장. Network Observability Operator 구성

Flow Collector API 리소스를 업데이트하여 Network Observability Operator 및 해당 관리 구성 요소를 구성할 수 있습니다. 설치 중에 Flow Collector가 명시적으로 생성됩니다. 이 리소스는 클러스터 전체에서 작동하기 때문에 단일 FlowCollector 만 허용되며 cluster 라는 이름을 지정해야 합니다.

5.1. FlowCollector 리소스 보기

OpenShift Container Platform 웹 콘솔에서 직접 YAML을 보고 편집할 수 있습니다.

프로세스

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

다음 예제에서는 OpenShift Container Platform Network Observability Operator의 샘플 FlowCollector 리소스를 보여줍니다.

샘플 FlowCollector 리소스

apiVersion: flows.netobserv.io/v1beta2
kind: FlowCollector
metadata:
  name: cluster
spec:
  namespace: netobserv
  deploymentModel: Direct
  agent:
    type: eBPF                                1
    ebpf:
      sampling: 50                            2
      logLevel: info
      privileged: false
      resources:
        requests:
          memory: 50Mi
          cpu: 100m
        limits:
          memory: 800Mi
  processor:               3
    logLevel: info
    resources:
      requests:
        memory: 100Mi
        cpu: 100m
      limits:
        memory: 800Mi
    logTypes: Flows
    advanced:
      conversationEndTimeout: 10s
      conversationHeartbeatInterval: 30s
  loki:                     4
    mode: LokiStack         5
  consolePlugin:
    register: true
    logLevel: info
    portNaming:
      enable: true
      portNames:
        "3100": loki
    quickFilters:            6
    - name: Applications
      filter:
        src_namespace!: 'openshift-,netobserv'
        dst_namespace!: 'openshift-,netobserv'
      default: true
    - name: Infrastructure
      filter:
        src_namespace: 'openshift-,netobserv'
        dst_namespace: 'openshift-,netobserv'
    - name: Pods network
      filter:
        src_kind: 'Pod'
        dst_kind: 'Pod'
      default: true
    - name: Services network
      filter:
        dst_kind: 'Service'

1: 에이전트 사양인 spec.agent.type 은 Cryostat PF 여야 합니다. eBPF는 지원되는 유일한 OpenShift Container Platform 옵션입니다.
2: Sampling 사양인 spec.agent.ebpf.sampling 을 설정하여 리소스를 관리할 수 있습니다. 샘플링 값이 작으면 많은 양의 컴퓨팅, 메모리 및 스토리지 리소스를 사용할 수 있습니다. 샘플링 비율 값을 지정하여 이를 완화할 수 있습니다. 값이 100이면 100개마다 하나의 흐름이 샘플링됩니다. 값이 0 또는 1이면 모든 흐름이 캡처됩니다. 값이 낮을수록 반환된 흐름의 증가 및 파생 메트릭의 정확도가 낮아집니다. 기본적으로 eBPF 샘플링은 값 50으로 설정되므로 50마다 하나의 흐름이 샘플링됩니다. 더 많은 샘플 흐름은 더 많은 스토리지가 필요하다는 것을 의미합니다. 클러스터를 관리할 수 있는 설정을 결정하려면 기본값으로 시작하고 경험적으로 구체화하는 것이 좋습니다.
3: 대화 추적을 활성화하도록 Processor specification spec.processor. 를 설정할 수 있습니다. 활성화하면 웹 콘솔에서 대화 이벤트를 쿼리할 수 있습니다. spec.processor.logTypes 값은 Flows 입니다. spec.processor.advanced 값은 Conversations,EndedConversations 또는 ALL 입니다. EndedConversations 의 경우 스토리지 요구 사항이 All 및 lowest에서 가장 높습니다.
4: Loki 사양인 spec.loki 는 Loki 클라이언트를 지정합니다. 기본값은 Loki Operator 설치 섹션에 언급된 Loki 설치 경로와 일치합니다. Loki에 다른 설치 방법을 사용한 경우 설치에 적절한 클라이언트 정보를 지정합니다.
5: LokiStack 모드는 querierUrl,ingesterUrl 및 statusUrl,tenantID 및 해당 TLS 구성 등 몇 가지 구성을 자동으로 설정합니다. Loki에 로그를 읽고 쓰기 위해 클러스터 역할 및 클러스터 역할 바인딩이 생성됩니다. authToken 은 Forward 로 설정됩니다. 수동 모드를 사용하여 수동으로 설정할 수 있습니다.
6: spec.quickFilters 사양은 웹 콘솔에 표시되는 필터를 정의합니다. 애플리케이션 필터 키,src_namespace 및 dst_namespace 는 negated (!)이므로 애플리케이션 필터 는 openshift- 또는 netobserv 네임스페이스의 대상이 아닌 모든 트래픽을 표시합니다. 자세한 내용은 아래의 빠른 필터 구성을 참조하십시오.

추가 리소스

대화 추적에 대한 자세한 내용은 대화 작업을 참조하십시오.

5.2. Kafka를 사용하여 Flow Collector 리소스 구성

처리량이 높고 대기 시간이 짧은 데이터 피드에 Kafka를 사용하도록 FlowCollector 리소스를 구성할 수 있습니다. Kafka 인스턴스를 실행해야 하며 OpenShift Container Platform Network Observability 전용 Kafka 주제를 해당 인스턴스에서 생성해야 합니다. 자세한 내용은 AMQ Streams를 사용한 Kafka 문서를 참조하십시오.

사전 요구 사항

Kafka가 설치되어 있어야 합니다. Red Hat은 AMQ Streams Operator를 사용하여 Kafka를 지원합니다.

프로세스

웹 콘솔에서 Operator → 설치된 Operator 로 이동합니다.
Network Observability Operator의 제공된 API 제목에서 흐름 수집기 를 선택합니다.
클러스터를 선택한 다음 YAML 탭을 클릭합니다.
다음 샘플 YAML과 같이 OpenShift Container Platform Network Observability Operator의 FlowCollector 리소스를 수정하여 Kafka를 사용합니다.

FlowCollector 리소스의 Kafka 구성 샘플

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

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

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

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

사전 요구 사항

Kafka 또는 IPFIX 수집기 끝점은 Network Observability flowlogs-pipeline Pod에서 사용할 수 있습니다.

프로세스

웹 콘솔에서 Operator → 설치된 Operator 로 이동합니다.
NetObserv Operator 의 제공된 API 제목에서 흐름 수집기 를 선택합니다.
클러스터를 선택한 다음 YAML 탭을 선택합니다.
다음과 같이 FlowCollector 를 편집하여 spec.exporters 를 구성합니다.
```
apiVersion: flows.netobserv.io/v1beta2
kind: FlowCollector
metadata:
  name: cluster
spec:
  exporters:
  - type: Kafka                         1
      kafka:
        address: "kafka-cluster-kafka-bootstrap.netobserv"
        topic: netobserv-flows-export   2
        tls:
          enable: false                 3
  - type: IPFIX                         4
      ipfix:
        targetHost: "ipfix-collector.ipfix.svc.cluster.local"
        targetPort: 4739
        transport: tcp or udp           5
```
2
Network Observability Operator는 모든 흐름을 구성된 Kafka 주제로 내보냅니다.
3
SSL/TLS 또는 mTLS를 사용하여 Kafka 간에 모든 통신을 암호화할 수 있습니다. 활성화하면 Kafka CA 인증서를 ConfigMap 또는 Secret으로 사용할 수 있어야 합니다. flowlogs-pipeline 프로세서 구성 요소가 배포되는 네임스페이스(기본값: netobserv). spec.exporters.tls.caCert 를 사용하여 참조해야 합니다. mTLS를 사용하는 경우 이러한 네임스페이스에서 클라이언트 시크릿을 사용할 수 있어야 합니다(예: AMQ Streams User Operator를 사용하여 생성할 수 있음) spec.exporters.tls.userCert 에서 참조해야 합니다.
1 4
흐름을 Kafka로 내보내거나 내보내기와 함께 IPFIX로 내보낼 수 있습니다.
5
전송을 지정하는 옵션이 있습니다. 기본값은 tcp 이지만 udp 도 지정할 수 있습니다.
구성 후 네트워크 흐름 데이터를 JSON 형식의 사용 가능한 출력으로 전송할 수 있습니다. 자세한 내용은 네트워크 흐름 형식 참조를 참조하십시오.

추가 리소스

흐름 형식을 지정하는 방법에 대한 자세한 내용은 네트워크 흐름 형식 참조를 참조하십시오.

5.4. 흐름 수집기 리소스 업데이트

OpenShift Container Platform 웹 콘솔에서 YAML을 편집하는 대신 flowcollector CR(사용자 정의 리소스)을 패치하여 eBPF 샘플링과 같은 사양을 구성할 수 있습니다.

프로세스

다음 명령을 실행하여 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"

5.5. 빠른 필터 구성

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

참고

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

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

표 5.1. 키 필터링
Universal*	소스	대상	설명
네임스페이스	`src_namespace`	`dst_namespace`	특정 네임스페이스와 관련된 트래픽을 필터링합니다.
name	`src_name`	`dst_name`	특정 pod, 서비스 또는 노드(호스트 네트워크 트래픽의 경우)와 같은 지정된 리프 리소스 이름과 관련된 트래픽을 필터링합니다.
kind	`src_kind`	`dst_kind`	지정된 리소스 유형과 관련된 트래픽을 필터링합니다. 리소스 종류에는 리프 리소스(Pod, 서비스 또는 노드) 또는 소유자 리소스(Deployment 및 StatefulSet)가 포함됩니다.
owner_name	`src_owner_name`	`dst_owner_name`	지정된 리소스 소유자, 즉 워크로드 또는 Pod 세트와 관련된 트래픽을 필터링합니다. 예를 들어 배포 이름, StatefulSet 이름 등이 될 수 있습니다.
resource	`src_resource`	`dst_resource`	고유하게 식별하는 표준 이름으로 표시되는 특정 리소스와 관련된 트래픽을 필터링합니다. canonical notation은 네임스페이스가 지정된 종류의 `kind.namespace.name` 또는 노드의 `node.name` 입니다. 예: `Deployment.my-namespace.my-web-server`.
address	`src_address`	`dst_address`	IP 주소와 관련된 트래픽을 필터링합니다. IPv4 및 IPv6이 지원됩니다. CIDR 범위도 지원됩니다.
mac	`src_mac`	`dst_mac`	MAC 주소와 관련된 트래픽을 필터링합니다.
port	`src_port`	`dst_port`	특정 포트와 관련된 트래픽을 필터링합니다.
host_address	`src_host_address`	`dst_host_address`	Pod가 실행 중인 호스트 IP 주소와 관련된 트래픽을 필터링합니다.
프로토콜	해당 없음	해당 없음	TCP 또는 UDP와 같은 프로토콜과 관련된 트래픽을 필터링합니다.

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

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

SR-IOV(Single Root I/O Virtualization) 장치가 있는 클러스터에서 트래픽을 수집하려면 FlowCollector spec.agent.ebpf.privileged 필드를 true 로 설정해야 합니다. 그런 다음 eBPF 에이전트는 기본적으로 모니터링되는 호스트 네트워크 네임스페이스 외에도 다른 네트워크 네임스페이스를 모니터링합니다. VF(가상 기능) 인터페이스가 있는 Pod가 생성되면 새 네트워크 네임스페이스가 생성됩니다. SRIOVNetwork 정책 IPAM 구성을 지정하면 VF 인터페이스가 호스트 네트워크 네임스페이스에서 Pod 네트워크 네임스페이스로 마이그레이션됩니다.

사전 요구 사항

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

프로세스

웹 콘솔에서 Operator → 설치된 Operator 로 이동합니다.
NetObserv Operator 의 제공된 API 제목에서 흐름 수집기 를 선택합니다.
클러스터를 선택한 다음 YAML 탭을 선택합니다.
FlowCollector 사용자 지정 리소스를 구성합니다. 샘플 구성은 다음과 같습니다.

SR-IOV 모니터링을 위한 FlowCollector 구성

apiVersion: flows.netobserv.io/v1beta2
kind: FlowCollector
metadata:
  name: cluster
spec:
  namespace: netobserv
  deploymentModel: Direct
  agent:
    type: eBPF
    ebpf:
      privileged: true   1

1: SR-IOV 모니터링을 활성화하려면 spec.agent.ebpf.privileged 필드 값을 true 로 설정해야 합니다.

추가 리소스

SriovNetwork 사용자 정의 리소스 생성에 대한 자세한 내용은 CNI VRF 플러그인을 사용하여 추가 SR-IOV 네트워크 연결 생성을 참조하십시오.

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

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

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

eBPF 샘플링: Sampling 사양인 spec.agent.ebpf.sampling 을 설정하여 리소스를 관리할 수 있습니다. 더 작은 샘플링 값은 많은 양의 컴퓨팅, 메모리 및 스토리지 리소스를 사용할 수 있습니다. 샘플링 비율 값을 지정하여 이를 완화할 수 있습니다. 값이 100 이면 100개마다 하나의 흐름이 샘플링됩니다. 값이 0 또는 1 이면 모든 흐름이 캡처됩니다. 값이 작으면 반환된 흐름이 증가하고 파생 메트릭의 정확도가 증가합니다. 기본적으로 eBPF 샘플링은 값 50으로 설정되므로 50마다 하나의 흐름이 샘플링됩니다. 더 많은 샘플 흐름은 더 많은 스토리지가 필요하다는 것을 의미합니다. 클러스터가 관리할 수 있는 설정을 결정하기 위해 기본값을 시작하고 실제적으로 구체화하는 것이 좋습니다.
인터페이스 제한 또는 제외: spec.agent.ebpf.interfaces 및 spec.agent.ebpf.excludeInterfaces 값을 설정하여 전체 관찰 트래픽을 줄입니다. 기본적으로 에이전트는 excludeInterfaces 및 lo (로컬 인터페이스)에 나열된 인터페이스를 제외하고 시스템의 모든 인터페이스를 가져옵니다. 인터페이스 이름은 사용된 CNI(Container Network Interface)에 따라 다를 수 있습니다.

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

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

5.7.1. 리소스 고려 사항

다음 표에는 특정 워크로드 크기가 있는 클러스터의 리소스 고려 사항의 예가 요약되어 있습니다.

중요

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

표 5.2. 리소스 권장 사항
	추가 소규모(10개 노드)	소규모(25개 노드)	중간(65 노드) ^[2]	대규모(120개 노드) ^[2]
작업자 노드 vCPU 및 메모리	4개의 vCPU\| 16GiB mem ^[1]	16개의 vCPU\| 64GiB mem ^[1]	16개의 vCPU\| 64GiB mem ^[1]	16개의 vCPU\| 64GiB Mem ^[1]
LokiStack 크기	`1x.extra-small`	`1x.small`	`1x.small`	`1x.medium`
네트워크 Observability 컨트롤러 메모리 제한	400Mi(기본값)	400Mi(기본값)	400Mi(기본값)	400Mi(기본값)
eBPF 샘플링 속도	50(기본값)	50(기본값)	50(기본값)	50(기본값)
eBPF 메모리 제한	800Mi (기본값)	800Mi (기본값)	800Mi (기본값)	1600Mi
CryostatP 메모리 제한	800Mi (기본값)	800Mi (기본값)	800Mi (기본값)	800Mi (기본값)
CryostatP Kafka 파티션	해당 없음	48	48	48
Kafka 소비자 복제본	해당 없음	24	24	24
Kafka 브로커	해당 없음	3 (기본값)	3 (기본값)	3 (기본값)

AWS M6i 인스턴스로 테스트되었습니다.
이 작업자와 컨트롤러 외에도 3개의 인프라 노드(크기 M6i.12xlarge) 및 1 워크로드 노드( M6i.8xlarge크기)를 테스트했습니다.

6장. Network Policy

admin 역할이 있는 사용자는 netobserv 네임스페이스에 대한 네트워크 정책을 생성하여 Network Observability Operator에 대한 인바운드 액세스를 보호할 수 있습니다.

6.1. 네트워크 Observability에 대한 네트워크 정책 생성

netobserv 네임스페이스에 대한 수신 트래픽을 보호하려면 네트워크 정책을 생성해야 할 수 있습니다. 웹 콘솔에서 양식 보기를 사용하여 네트워크 정책을 생성할 수 있습니다.

프로세스

네트워킹 → NetworkPolicies 로 이동합니다.
프로젝트 드롭다운 메뉴에서 netobserv 프로젝트를 선택합니다.
정책의 이름을 지정합니다. 이 예에서 정책 이름은 allow-ingress 입니다.
Ingress 규칙 추가를 세 번 클릭하여 수신 규칙을 생성합니다.
양식에 다음을 지정합니다.
1. 첫 번째 Ingress 규칙에 대해 다음 사양을 만듭니다.
  1. Add allowed source 드롭다운 메뉴에서 동일한 네임스페이스에서 Pod 허용을 선택합니다.
2. 두 번째 Ingress 규칙에 대해 다음 사양을 만듭니다.
  1. Add allowed source 드롭다운 메뉴에서 클러스터 내부에서 Pod 허용을 선택합니다.
  2. + 네임스페이스 선택기 추가 를 클릭합니다.
  3. kubernetes.io/metadata.name 레이블과 선택기 openshift-console 을 추가합니다.
3. 세 번째 Ingress 규칙에 대해 다음 사양을 만듭니다.
  1. Add allowed source 드롭다운 메뉴에서 클러스터 내부에서 Pod 허용을 선택합니다.
  2. + 네임스페이스 선택기 추가 를 클릭합니다.
  3. kubernetes.io/metadata.name 레이블과 선택기 openshift-monitoring 를 추가합니다.

검증

모니터링 → 네트워크 트래픽 으로 이동합니다.
트래픽 흐름 탭 또는 탭을 보고 데이터가 표시되는지 확인합니다.
모니터링 → 대시보드 로 이동합니다. NetObserv/Health 선택에서 흐름이 수집되고 첫 번째 그래프에 표시되는 Loki로 전송되는지 확인합니다.

6.2. 네트워크 정책의 예

다음은 netobserv 네임스페이스의 예제 NetworkPolicy 오브젝트에 주석을 답니다.

네트워크 정책 샘플

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-ingress
  namespace: netobserv
spec:
  podSelector: {}            1
  ingress:
    - from:
        - podSelector: {}    2
          namespaceSelector: 3
            matchLabels:
              kubernetes.io/metadata.name: openshift-console
        - podSelector: {}
          namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: openshift-monitoring
  policyTypes:
    - Ingress
status: {}

1: 정책이 적용되는 Pod를 설명하는 선택기입니다. 정책 오브젝트는 NetworkPolicy 오브젝트를 정의하는 프로젝트에서 Pod만 선택할 수 있습니다. 이 문서에서는 netobserv serv 프로젝트인 Network Observability Operator가 설치된 프로젝트입니다.
2: 정책 오브젝트가 수신 트래픽을 허용하는 Pod와 일치하는 선택기입니다. 기본값은 선택기가 NetworkPolicy 와 동일한 네임스페이스의 Pod와 일치한다는 것입니다.
3: namespaceSelector 를 지정하면 선택기가 지정된 네임스페이스의 Pod와 일치합니다.

추가 리소스

CLI를 사용하여 네트워크 정책 생성

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

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

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

개요 보기에는 클러스터의 네트워크 트래픽 흐름에 대한 전체 집계 지표가 표시됩니다. 관리자는 사용 가능한 표시 옵션을 사용하여 통계를 모니터링할 수 있습니다.

7.1.1. 개요 뷰 작업

관리자는 개요 보기로 이동하여 흐름 속도 통계의 그래픽 표시를 확인할 수 있습니다.

프로세스

모니터링 → 네트워크 트래픽 으로 이동합니다.
네트워크 트래픽 페이지에서 개요 탭을 클릭합니다.

메뉴 아이콘을 클릭하여 각 흐름 속도 데이터의 범위를 구성할 수 있습니다.

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

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

범위: 네트워크 트래픽이 이동하는 구성 요소를 보려면 선택합니다. 노드 , 네임스페이스,소유자 , 영역 ,클러스터 또는 리소스로 범위를 설정할 수 있습니다. 소유자는 리소스 집계입니다. 리소스는 호스트 네트워크 트래픽 또는 알 수 없는 IP 주소의 경우 Pod, 서비스, 노드일 수 있습니다. 기본값은 Namespace 입니다.
truncate 레이블: 드롭다운 목록에서 레이블의 필요한 너비를 선택합니다. 기본값은 M 입니다.

7.1.2.1. 패널 및 디스플레이 관리

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

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

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

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

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

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

7.1.3. 패킷 드롭 추적

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

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

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

상위 X 패킷은 합계를 사용하여 상태 스택 삭제
상위 X 패킷이 삭제되면 합계가 누적됩니다.
상위 X 평균 삭제 패킷 속도
상위 X는 합계를 사용하여 누적된 패킷 비율 삭제

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

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

7.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 패킷

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

추가 리소스

패킷 드롭 작업
네트워크 Observability 메트릭

7.1.4. DNS 추적

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

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

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

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

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

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

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

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

추가 리소스

DNS 추적 작업
네트워크 Observability 메트릭

7.1.5. Round-Trip Time

TCP 핸드셰이크 Round-Trip Time (RTT)을 사용하여 네트워크 흐름을 분석할 수 있습니다. fentry/tcp_rcv_ established ed eBPF hookpoint에서 캡처된 RTT를 사용하여 TCP 소켓에서 SRTT를 읽고 다음을 지원할 수 있습니다.

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

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

상위 X 90번째 백분위 TCP 핸드셰이크 Round Trip Time
전반적으로 상위 X 평균 TCP 핸드셰이크 Round Trip Time
최하위 X 최소 TCP 핸드셰이크 Round Trip Time

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

최대 X 최대 TCP 핸드셰이크 Round Trip Time
상위 X 99번째 백분위 TCP 핸드셰이크 Round Trip Time

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

추가 리소스

RTT 추적 작업

7.2. 트래픽 흐름 보기에서 네트워크 트래픽 관찰

트래픽 흐름 보기에는 네트워크 흐름의 데이터와 테이블의 트래픽 양이 표시됩니다. 관리자는 트래픽 흐름 테이블을 사용하여 애플리케이션 간 트래픽 양을 모니터링할 수 있습니다.

7.2.1. 트래픽 흐름 보기 작업

관리자는 트래픽 흐름 테이블로 이동하여 네트워크 흐름 정보를 볼 수 있습니다.

프로세스

모니터링 → 네트워크 트래픽 으로 이동합니다.
네트워크 트래픽 페이지에서 트래픽 흐름 탭을 클릭합니다.

각 행을 클릭하면 해당 흐름 정보를 얻을 수 있습니다.

7.2.2. 트래픽 흐름 보기에 대한 고급 옵션 구성

고급 옵션 표시를 사용하여 보기를 사용자 지정하고 내보낼 수 있습니다. 표시 옵션 드롭다운 메뉴를 사용하여 행 크기를 설정할 수 있습니다. 기본값은 Normal 입니다.

7.2.2.1. 열 관리

표시할 필수 열을 선택하고 순서를 다시 정렬할 수 있습니다. 열을 관리하려면 열 관리를 클릭합니다.

7.2.2.2. 트래픽 흐름 데이터 내보내기

트래픽 흐름 보기에서 데이터를 내보낼 수 있습니다.

프로세스

데이터 내보내기 를 클릭합니다.
팝업 창에서 모든 데이터를 내보내려면 모든 데이터 내보내기 확인란을 선택하고 확인란의 선택을 해제하여 내보낼 필수 필드를 선택할 수 있습니다.
내보내기 를 클릭합니다.

7.2.3. 대화 추적 작업

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

대화 시작: 이 이벤트는 연결이 시작되거나 TCP 플래그가 인터셉트될 때 발생합니다.
대화 눈금: 이 이벤트는 연결이 활성화된 동안 FlowCollector spec.processor.conversationHeartbeatInterval 매개변수에 정의된 각 지정된 간격으로 수행됩니다.
대화 종료: 이 이벤트는 FlowCollector spec.processor.conversationEndTimeout 매개변수에 도달하거나 TCP 플래그를 가로챌 때 발생합니다.
flow: 지정된 간격 내에 발생하는 네트워크 트래픽 흐름입니다.

프로세스

웹 콘솔에서 Operator → 설치된 Operator 로 이동합니다.
NetObserv Operator 의 제공된 API 제목에서 흐름 수집기 를 선택합니다.
클러스터를 선택한 다음 YAML 탭을 선택합니다.
spec.processor.logTypes,conversationEndTimeout 및 conversationHeartbeatInterval 매개변수가 관찰 요구 사항에 따라 설정되도록 FlowCollector 사용자 지정 리소스를 구성합니다. 샘플 구성은 다음과 같습니다.
대화 추적을 위한 FlowCollector 구성
```
apiVersion: flows.netobserv.io/v1beta2
kind: FlowCollector
metadata:
  name: cluster
spec:
 processor:
  logTypes: Flows                              1
  advanced:
   conversationEndTimeout: 10s                 2
   conversationHeartbeatInterval: 30s          3
```
1
logTypes 를 Flow 로 설정하면 Flow 이벤트만 내보냅니다. 값을 All 으로 설정하면 대화 및 흐름 이벤트가 모두 내보내 네트워크 트래픽 페이지에 표시됩니다. 대화 이벤트에만 집중하기 위해 대화 시작, 대화틱 및 대화 끝 이벤트 또는 대화 끝점 이벤트만 내보내는 Conversations 를 지정할 수 있습니다. EndedConversations 의 경우 스토리지 요구 사항이 All 및 lowest에서 가장 높습니다.
2
Conversation end 이벤트는 conversationEndTimeout 에 도달하거나 TCP 플래그가 가로채는 시점을 나타냅니다.
3
Conversation tick 이벤트는 네트워크 연결이 활성화된 동안 FlowCollector conversationHeartbeatInterval 매개변수에 정의된 각 지정된 간격을 나타냅니다.
참고
logType 옵션을 업데이트하면 이전 선택의 흐름이 콘솔 플러그인에서 명확하지 않습니다. 예를 들어, 처음에 logType 을 오전 10시까지 시간 범위에 대한 Conversations 로 설정한 다음 EndedConversations 로 이동하는 경우 콘솔 플러그인은 오전 10시 이전의 모든 대화 이벤트를 표시하고 10 AM 이후의 대화만 종료합니다.
트래픽 흐름 탭에서 네트워크 트래픽 페이지를 새로 고칩니다. 두 개의 새 열인 Event/Type 및 Conversation Id 가 있습니다. 모든 이벤트/유형 필드는 Flow 가 선택한 쿼리 옵션인 경우 Flow 입니다.
쿼리 옵션을 선택하고 로그 유형,대화 유형을 선택합니다. 이제 이벤트/유형 이 원하는 대화 이벤트를 모두 표시합니다.
다음으로 특정 대화 ID를 필터링하거나 측면 패널에서 대화 및 흐름 로그 유형 옵션을 전환할 수 있습니다.

7.2.4. 패킷 드롭 작업

패킷 손실은 하나 이상의 네트워크 흐름 데이터가 대상에 도달하지 못하는 경우 발생합니다. 다음 YAML 예제의 사양에 대해 FlowCollector 를 편집하여 이러한 드롭을 추적할 수 있습니다.

중요

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

프로세스

웹 콘솔에서 Operator → 설치된 Operator 로 이동합니다.
NetObserv Operator 의 제공된 API 제목에서 흐름 수집기 를 선택합니다.
클러스터를 선택한 다음 YAML 탭을 선택합니다.
패킷 드롭에 대한 FlowCollector 사용자 정의 리소스를 구성합니다. 예를 들면 다음과 같습니다.
FlowCollector 구성 예
```
apiVersion: flows.netobserv.io/v1beta2
kind: FlowCollector
metadata:
  name: cluster
spec:
  namespace: netobserv
  deploymentModel: Direct
  agent:
    type: eBPF
    ebpf:
      features:
       - PacketDrop            1
      privileged: true         2
```
1
spec.agent.ebpf.features 사양 목록에 PacketDrop 매개변수를 나열하여 각 네트워크 흐름의 패킷 삭제 보고를 시작할 수 있습니다.
2
패킷 드롭 추적의 경우 spec.agent.ebpf.privileged 사양 값이 true 여야 합니다.

검증

네트워크 트래픽 페이지를 새로 고칠 때 개요,트래픽 흐름 및 토폴로지 보기에 패킷 삭제에 대한 새 정보가 표시됩니다.
1. 패널 관리에서 새 선택 항목을 선택하여 개요 에 표시할 패킷의 그래픽 시각화를 선택합니다.
2. 열 관리에서 새 선택 항목을 선택하여 트래픽 흐름 테이블에 표시할 패킷 드롭 정보를 선택합니다.
  1. 트래픽 흐름 보기에서 측면 패널을 확장하여 패킷 드롭에 대한 자세한 정보를 볼 수도 있습니다. 호스트 삭제에는 SKB_DROP 접두사가 붙고 OVS 드롭이 OVS_DROP 접두사가 붙습니다.
3. 토폴로지 보기에서 드롭이 있는 빨간색 행이 표시됩니다.

7.2.5. DNS 추적 작업

DNS 추적을 사용하면 네트워크를 모니터링하고 보안 분석을 수행하고 DNS 문제를 해결할 수 있습니다. 다음 YAML 예제의 사양으로 FlowCollector 를 편집하여 DNS를 추적할 수 있습니다.

중요

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

프로세스

웹 콘솔에서 Operator → 설치된 Operator 로 이동합니다.
네트워크 Observa bility 에 대해 제공된 API 제목에서 흐름 수집기 를 선택합니다.
클러스터를 선택한 다음 YAML 탭을 선택합니다.
FlowCollector 사용자 지정 리소스를 구성합니다. 샘플 구성은 다음과 같습니다.
DNS 추적을 위한 FlowCollector 구성
```
apiVersion: flows.netobserv.io/v1beta2
kind: FlowCollector
metadata:
  name: cluster
spec:
  namespace: netobserv
  deploymentModel: Direct
  agent:
    type: eBPF
    ebpf:
      features:
       - DNSTracking           1
      sampling: 1              2
```
1
spec.agent.ebpf.features 매개변수 목록을 설정하여 웹 콘솔에서 각 네트워크 흐름의 DNS 추적을 활성화할 수 있습니다.
2
보다 정확한 메트릭을 위해 샘플링 을 1 값으로 설정할 수 있습니다.
네트워크 트래픽 페이지를 새로 고칠 때 개요 및 트래픽 흐름 보기 및 적용할 수 있는 새 필터에서 볼 수 있는 새로운 DNS 표현이 있습니다.
1. 패널 관리에서 새 DNS 선택 사항을 선택하여 개요 에 그래픽 시각화 및 DNS 지표를 표시합니다.
2. 열 관리에서 새 선택 항목을 선택하여 트래픽 흐름 보기에 DNS 열을 추가합니다.
3. DNS Id,DNS Error DNS Latency 및 DNS Response Code 와 같은 특정 DNS 메트릭을 필터링하고 사이드 패널에서 자세한 정보를 확인합니다. DNS 대기 시간 및 DNS 응답 코드 열이 기본적으로 표시됩니다.

참고

TCP 핸드셰이크 패킷에는 DNS 헤더가 없습니다. DNS 헤더가 없는 TCP 프로토콜은 "n/a"의 DNS 대기 시간,ID 및 응답 코드 값을 사용하여 트래픽 흐름 데이터에 표시됩니다. 흐름 데이터를 필터링하여 "0"과 같은 Common filter "DNSError"를 사용하여 DNS 헤더가 있는 흐름만 볼 수 있습니다.

7.2.6. RTT 추적 작업

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

프로세스

웹 콘솔에서 Operator → 설치된 Operator 로 이동합니다.
NetObserv Operator 의 제공된 API 제목에서 흐름 수집기 를 선택합니다.
클러스터를 선택한 다음 YAML 탭을 선택합니다.
RTT 추적을 위한 FlowCollector 사용자 정의 리소스를 구성합니다. 예를 들면 다음과 같습니다.
FlowCollector 구성 예
```
apiVersion: flows.netobserv.io/v1beta2
kind: FlowCollector
metadata:
  name: cluster
spec:
  namespace: netobserv
  deploymentModel: Direct
  agent:
    type: eBPF
    ebpf:
      features:
       - FlowRTT   1
```
1
spec.agent.ebpf.features 사양 목록에 FlowRTT 매개변수를 나열하여 RTT 네트워크 흐름 추적을 시작할 수 있습니다.

검증

네트워크 트래픽 페이지를 새로 고칠 때 개요,트래픽 흐름 및 토폴로지 보기에 RTT에 대한 새 정보가 표시됩니다.

개요 에서 패널 관리에서 새 선택 사항을 선택하여 표시할 RTT의 그래픽 시각화를 선택합니다.
트래픽 흐름 테이블에서는 흐름 RTT 열을 볼 수 있으며 열 관리에서 디스플레이를 관리할 수 있습니다.
트래픽 흐름 보기에서 측면 패널을 확장하여 RTT에 대한 자세한 정보를 볼 수도 있습니다.
필터링 예
1. 공통 필터 → 프로토콜 을 클릭합니다.
2. TCP,Ingress 방향을 기반으로 네트워크 흐름 데이터를 필터링하고 10,000,000 나노초(10ms)보다 큰 FlowRTT 값을 찾습니다.
3. 프로토콜 필터를 제거합니다.
4. Common Filter에서 0보다 큰 Flow RTT 값을 필터링합니다.
토폴로지 보기에서 표시 옵션 드롭다운을 클릭합니다. 그런 다음 에지 레이블 드롭다운 목록에서 RTT 를 클릭합니다.

7.2.6.1. 히스토그램 사용

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

7.2.7. 가용성 영역 작업

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

프로세스

웹 콘솔에서 Operator → 설치된 Operator 로 이동합니다.
NetObserv Operator 의 제공된 API 제목에서 흐름 수집기 를 선택합니다.
클러스터를 선택한 다음 YAML 탭을 선택합니다.
spec.processor.addZone 매개변수가 true 로 설정되도록 FlowCollector 사용자 지정 리소스를 구성합니다. 샘플 구성은 다음과 같습니다.
가용성 영역 컬렉션에 대한 FlowCollector 구성
```
apiVersion: flows.netobserv.io/v1beta2
kind: FlowCollector
metadata:
  name: cluster
spec:
# ...
 processor:
  addZone: true
# ...
```

검증

네트워크 트래픽 페이지를 새로 고칠 때 개요,트래픽 흐름 및 토폴로지 보기에 가용성 영역에 대한 새 정보가 표시됩니다.

개요 탭에서 영역을 사용 가능한 범위로 볼 수 있습니다.
네트워크 트래픽 → 트래픽 흐름에서 영역은 SrcK8S_Zone 및 DstK8S_Zone 필드에서 볼 수 있습니다.
토폴로지 보기에서 영역을 범위 또는 그룹으로 설정할 수 있습니다.

7.3. 토폴로지 보기에서 네트워크 트래픽 관찰

토폴로지 보기에는 네트워크 흐름과 트래픽 양을 그래픽으로 표시할 수 있습니다. 관리자는 토폴로지 보기를 사용하여 애플리케이션에서 트래픽 데이터를 모니터링할 수 있습니다.

7.3.1. 토폴로지 보기 작업

관리자는 토폴로지 보기로 이동하여 구성 요소의 세부 정보 및 지표를 확인할 수 있습니다.

프로세스

모니터링 → 네트워크 트래픽 으로 이동합니다.
네트워크 트래픽 페이지에서 토폴로지 탭을 클릭합니다.

토폴로지 에서 각 구성 요소를 클릭하여 구성 요소의 세부 정보 및 지표를 확인할 수 있습니다.

7.3.2. 토폴로지 보기의 고급 옵션 구성

고급 옵션 표시를 사용하여 보기를 사용자 지정하고 내보낼 수 있습니다. 고급 옵션 보기에는 다음과 같은 기능이 있습니다.

보기에서 찾기: 뷰에서 필요한 구성 요소를 검색하려면 다음을 수행합니다.
Display options: 다음 옵션을 구성하려면 다음을 수행합니다.
- Edge 라벨: 지정된 측정값을 에지 레이블로 표시하려면 다음을 수행합니다. 기본값은 Average rate in Cryostats를 표시하는 것입니다.
- scope: 네트워크 트래픽이 이동하는 구성 요소의 범위를 선택합니다. 기본값은 Namespace 입니다.
- groups: 구성 요소를 그룹화하여 소유권에 대한 이해를 강화합니다. 기본값은 None 입니다.
- layout : 그래픽 표현의 레이아웃을 선택합니다. 기본값은 ColaNoForce 입니다.
- show: 표시할 필요가 있는 세부 정보를 선택합니다. 모든 옵션은 기본적으로 확인됩니다. 사용 가능한 옵션은 Edges,Edges 레이블 및 Badges 입니다.
- truncate 레이블: 드롭다운 목록에서 레이블의 필요한 너비를 선택합니다. 기본값은 M 입니다.
- 그룹 축소: 그룹을 확장하거나 축소합니다. 그룹은 기본적으로 확장됩니다. group의 값이 None 인 경우 이 옵션이 비활성화됩니다.

7.3.2.1. 토폴로지 보기 내보내기

뷰를 내보내려면 토폴로지 보기 내보내기 를 클릭합니다. 보기는 PNG 형식으로 다운로드됩니다.

7.4. 네트워크 트래픽 필터링

기본적으로 네트워크 트래픽 페이지는 FlowCollector 인스턴스에 구성된 기본 필터를 기반으로 클러스터의 트래픽 흐름 데이터를 표시합니다. 필터 옵션을 사용하여 사전 설정 필터를 변경하여 필요한 데이터를 관찰할 수 있습니다.

쿼리 옵션

다음과 같이 쿼리 옵션을 사용하여 검색 결과를 최적화할 수 있습니다.

사용 가능한 옵션 대화 및 흐름은 흐름 로그, 새 대화, 완료된 대화 및 하트비트와 같은 로그 유형 별로 흐름을 쿼리하는 기능을 제공합니다. 이 기능은 긴 대화에 대한 업데이트가 포함된 주기적인 레코드입니다. 대화는 동일한 피어 간의 흐름을 집계하는 것입니다.
중복된 흐름: 여러 인터페이스에서 흐름이 보고될 수 있으며 소스 및 대상 노드 모두에서 흐름이 데이터에 여러 번 표시될 수 있습니다. 이 쿼리 옵션을 선택하면 중복된 흐름을 표시하도록 선택할 수 있습니다. 복제된 흐름은 포트를 포함한 동일한 소스 및 대상을 가지며 Interface 및 Direction 필드를 제외하고 동일한 프로토콜을 갖습니다. 중복은 기본적으로 숨겨집니다. 드롭다운 목록의 Common 섹션에서 Direction 필터를 사용하여 수신 트래픽과 송신 트래픽 사이를 전환합니다.
match 필터: 고급 필터에서 선택한 다양한 필터 매개변수 간의 관계를 확인할 수 있습니다. 사용 가능한 옵션은 all 및 match any와 일치합니다. match all은 모든 값과 일치하는 결과를 제공하며 모든 값과 일치하면 입력된 값과 일치하는 결과가 제공됩니다. 기본값은 all과 일치합니다.
drops filter: 다음 쿼리 옵션을 사용하여 삭제된 패킷의 다른 수준을 볼 수 있습니다.
- 완전히 삭제된 패킷은 완전히 삭제된 흐름 레코드를 표시합니다.
- 포함 된 삭제 에는 드롭을 포함하지만 보낼 수 있는 흐름 레코드가 표시됩니다.
- drop을 사용하지 않으면 전송된 패킷이 포함된 레코드가 표시됩니다.
- 모두 앞서 언급한 모든 레코드를 보여줍니다.
limit: 내부 백엔드 쿼리의 데이터 제한입니다. 일치 및 필터 설정에 따라 트래픽 흐름 데이터 수가 지정된 제한 내에 표시됩니다.

빠른 필터

빠른 필터 드롭다운 메뉴의 기본값은 FlowCollector 구성에 정의되어 있습니다. 콘솔에서 옵션을 수정할 수 있습니다.

고급 필터

드롭다운 목록에서 필터링할 매개변수를 선택하여 고급 필터, 공통,소스 또는 대상 을 설정할 수 있습니다. 흐름 데이터는 선택 사항에 따라 필터링됩니다. 적용된 필터를 활성화하거나 비활성화하려면 필터 옵션 아래에 나열된 적용된 필터를 클릭하면 됩니다.

에서 한 가지 방법과 뒤로 필터링을 전환할 수 있습니다. 한 가지 방법 필터는 필터 선택에 따라 소스 및 대상 트래픽만 표시합니다. 스왑을 사용하여 소스 및 대상 트래픽의 방향 보기를 변경할 수 있습니다. Back and forth 필터에는 소스 및 대상 필터가 있는 반환 트래픽이 포함됩니다. 네트워크 트래픽의 방향 흐름은 트래픽의 Direction 열에 Ingress' 또는 'Egress for inter-node traffic 및 ' Inner' 트래픽의 경우 단일 노드 내의 트래픽으로 표시됩니다.

기본값 재설정 을 클릭하여 기존 필터를 제거하고 FlowCollector 구성에 정의된 필터를 적용할 수 있습니다.

참고

텍스트 값을 지정하는 규칙을 이해하려면 자세히 알아보기 를 클릭합니다.

또는 해당 집계의 필터링된 데이터를 제공하는 네임스페이스,서비스,경로,노드, 워크로드 페이지의 네트워크 트래픽 탭에서 트래픽 흐름 데이터에 액세스할 수 있습니다.

추가 리소스

FlowCollector 에서 빠른 필터를 구성하는 방법에 대한 자세한 내용은 빠른 필터 및 흐름 수집기 샘플 리소스 구성 을 참조하십시오.

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

Network Observability Operator는 flowlogs-pipeline 을 사용하여 흐름 로그에서 지표를 생성합니다. 사용자 정의 경고 및 대시보드 보기를 설정하여 이러한 메트릭을 활용할 수 있습니다.

8.1. 네트워크 Observability 메트릭 대시보드 보기

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

프로세스

웹 콘솔 Observe → Dashboards 에서 Netobserv 대시보드를 선택합니다.
다음 카테고리에서 네트워크 트래픽 지표를 확인합니다. 각각 노드, 네임스페이스, 소스 및 대상당 하위 집합을 갖습니다.
- 바이트 비율
- 패킷 드롭
- DNS
- RTT
Netobserv/Health 대시보드를 선택합니다.
다음 카테고리에서 Operator의 상태에 대한 메트릭을 표시하고 각 카테고리에는 노드, 네임스페이스, 소스 및 대상마다 하위 집합이 있습니다.
- flows
- 흐름 오버 헤드
- 유량
- 에이전트
- 프로세서
- Operator

인프라 및 애플리케이션 메트릭은 네임스페이스 및 워크로드에 대한 분할 보기에 표시됩니다.

8.2. 네트워크 Observability 메트릭

flowlogs-pipeline 에서 생성한 지표는 지표를 추가하거나 제거하기 위해 FlowCollector 사용자 정의 리소스의 spec.processor.metrics.includeList 에서 구성할 수 있습니다.

예제 "경고 생성"과 같이 Prometheus 규칙에 includeList 지표를 사용하여 경고를 생성할 수도 있습니다.

Observe → Metrics를 통해 콘솔에서와 같이 Prometheus에서 이러한 메트릭을 조회하거나 경고를 정의할 때 모든 메트릭 이름 앞에 'netobserv_가 붙습니다. 예를 들면 'netobserv_namespace_flows_total입니다. 사용 가능한 지표 이름은 다음과 같습니다.

8.2.1. 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

8.2.1.1. 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

8.2.1.2. DNS 메트릭 이름

spec.agent.ebpf.features 에서 DNSTracking 기능이 활성화되면 다음과 같은 추가 메트릭을 사용할 수 있습니다.

namespace_dns_latency_seconds *
node_dns_latency_seconds
workload_dns_latency_seconds

8.2.1.3. FlowRTT 메트릭 이름

spec.agent.ebpf.features 에서 FlowRTT 기능을 활성화하면 다음과 같은 추가 메트릭을 사용할 수 있습니다.

namespace_rtt_seconds *
node_rtt_seconds
workload_rtt_seconds

8.3. 경고 생성

Netobserv 대시보드 지표에 대한 사용자 정의 Prometheus 규칙을 생성하여 일부 정의된 조건이 충족되면 경고를 트리거할 수 있습니다.

사전 요구 사항

cluster-admin 역할 또는 모든 프로젝트에 대한 보기 권한이 있는 사용자로 클러스터에 액세스할 수 있습니다.
Network Observability Operator가 설치되어 있어야 합니다.

프로세스

가져오기 아이콘 + 를 클릭하여 YAML 파일을 생성합니다.

YAML 파일에 경고 규칙 구성을 추가합니다. 다음 YAML 샘플에서는 클러스터 수신 트래픽이 대상 워크로드당 지정된 임계값이 10MBps에 도달하면 경고가 생성됩니다.

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: netobserv-alerts
  namespace: openshift-netobserv-operator
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      1
      for: 30s
      labels:
        severity: warning

1: netobserv_workload_ingress_bytes_total 메트릭은 spec.processor.metrics.includeList 에서 기본적으로 활성화됩니다.

생성 을 클릭하여 구성 파일을 클러스터에 적용합니다.

추가 리소스

대시보드에서 볼 수 있는 경고를 만드는 방법에 대한 자세한 내용은 사용자 정의 프로젝트에 대한 경고 규칙 생성 을 참조하십시오.

9장. Network Observability Operator 모니터링

웹 콘솔을 사용하여 Network Observability Operator의 상태와 관련된 경고를 모니터링할 수 있습니다.

9.1. 상태 정보 보기

웹 콘솔의 대시보드 페이지에서 Network Observability Operator의 상태 및 리소스 사용량에 대한 메트릭에 액세스할 수 있습니다. 경고가 트리거될 경우 대시보드로 연결되는 상태 경고 배너는 네트워크 트래픽 및 홈 페이지에 표시될 수 있습니다. 다음과 같은 경우 경고가 생성됩니다.

Loki ingestion rate limit에 도달한 경우와 같이 flowlogs-pipeline 워크로드가 Loki 오류로 인해 흐름을 삭제하면 NetObservLokiError 경고가 발생합니다.
NetObservNoFlows 경고는 일정 시간 동안 흐름이 수집되지 않으면 발생합니다.

다음 카테고리에서 Operator의 상태에 대한 메트릭을 볼 수도 있습니다.

+ * 흐름 오버 헤드 * 소스 및 대상 노드당 상위 흐름 속도 * 소스 및 대상 네임스페이스당 상위 흐름 속도 * 소스 및 대상 워크로드당 상위 흐름 속도 * 에이전트 * 프로세서 * Operator

사전 요구 사항

Network Observability Operator가 설치되어 있어야 합니다.
cluster-admin 역할 또는 모든 프로젝트에 대한 보기 권한이 있는 사용자로 클러스터에 액세스할 수 있습니다.

프로세스

웹 콘솔의 관리자 화면에서 모니터링 → 대시보드 로 이동합니다.
대시보드 드롭다운에서 Netobserv/Health 를 선택합니다.
페이지에 표시되는 Operator의 상태에 대한 메트릭을 확인합니다.

9.1.1. 상태 경고 비활성화

FlowCollector 리소스를 편집하여 상태 경고를 비활성화할 수 있습니다.

웹 콘솔에서 Operator → 설치된 Operator 로 이동합니다.
NetObserv Operator 의 제공된 API 제목에서 흐름 수집기 를 선택합니다.
클러스터를 선택한 다음 YAML 탭을 선택합니다.
spec.processor.metrics.disableAlerts 를 추가하여 다음 YAML 샘플과 같이 상태 경고를 비활성화합니다.
```
apiVersion: flows.netobserv.io/v1beta2
kind: FlowCollector
metadata:
  name: cluster
spec:
  processor:
    metrics:
      disableAlerts: [NetObservLokiError, NetObservNoFlows] 1
```
1
비활성화할 경고 유형을 모두 사용하여 하나 또는 목록을 지정할 수 있습니다.

9.2. NetObserv 대시보드에 대한 Loki 속도 제한 경고 생성

Loki 속도 제한에 도달했을 때 경고를 트리거하도록 Netobserv 대시보드 지표에 대한 사용자 정의 Prometheus 규칙을 생성할 수 있습니다.

사전 요구 사항

cluster-admin 역할 또는 모든 프로젝트에 대한 보기 권한이 있는 사용자로 클러스터에 액세스할 수 있습니다.
Network Observability Operator가 설치되어 있어야 합니다.

프로세스

가져오기 아이콘 + 를 클릭하여 YAML 파일을 생성합니다.

YAML 파일에 경고 규칙 구성을 추가합니다. 다음 YAML 샘플에서는 Loki 속도 제한에 도달할 때 경고가 생성됩니다.

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: loki-alerts
  namespace: openshift-netobserv-operator
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

생성 을 클릭하여 구성 파일을 클러스터에 적용합니다.

추가 리소스

대시보드에서 볼 수 있는 경고를 만드는 방법에 대한 자세한 내용은 사용자 정의 프로젝트에 대한 경고 규칙 생성 을 참조하십시오.

10장. FlowCollector 구성 매개변수

FlowCollector는 기본 배포를 시험하고 구성하는 네트워크 흐름 컬렉션 API의 스키마입니다.

10.1. FlowCollector API 사양

설명: FlowCollector 는 기본 배포를 시험하고 구성하는 네트워크 흐름 컬렉션 API의 스키마입니다.
유형: object

속성	유형	설명
`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에서 공식적으로 지원하지 않음을 의미합니다. 예를 들어 커뮤니티에서 기여하고 유지 관리를 위한 공식적인 동의 없이 수락되었을 수 있습니다. 제품 유지 관리자는 최상의 노력으로 이러한 기능에 대한 지원을 제공할 수 있습니다.

10.1.1. .metadata

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

10.1.2. .spec

설명: FlowCollector 리소스의 원하는 상태를 정의합니다.

*: 이 문서 전체에서 "지원되지 않음" 또는 "더 이상 사용되지 않음"은 이 기능이 Red Hat에서 공식적으로 지원하지 않음을 의미합니다. 예를 들어 커뮤니티에서 기여하고 유지 관리를 위한 공식적인 동의 없이 수락되었을 수 있습니다. 제품 유지 관리자는 최상의 노력으로 이러한 기능에 대한 지원을 제공할 수 있습니다.
유형: object

속성	유형	설명
`agent`	`object`	흐름 추출에 대한 에이전트 구성입니다.
`consolePlugin`	`object`	Console `Plugin` 은 사용 가능한 경우 OpenShift Container Platform 콘솔 플러그인과 관련된 설정을 정의합니다.
`deploymentModel`	`string`	`deploymentModel` 은 흐름 처리를 위해 원하는 유형의 배포를 정의합니다. 가능한 값은 다음과 같습니다. - `직접` (기본값)은 에이전트에서 직접 흐름 프로세서를 수신 대기하도록 합니다. - `Kafka` 가 프로세서에서 사용하기 전에 Kafka 파이프라인으로 전송되는 흐름을 만듭니다. Kafka는 더 나은 확장성, 복원력 및 고가용성을 제공할 수 있습니다(자세한 내용은 https://www.redhat.com/en/topics/integration/what-is-apache-kafka)를 참조하십시오.
`내보내기`	`array`	`내보내기` 는 사용자 정의 사용 또는 스토리지에 대한 추가 선택적 내보내기를 정의합니다.
`kafka`	`object`	Kafka 구성을 통해 Kafka를 흐름 컬렉션 파이프라인의 일부로 브로커로 사용할 수 있습니다. `spec.deploymentModel` 이 `Kafka` 인 경우 사용할 수 있습니다.
`loki`	`object`	`Loki,` 흐름 저장소, 클라이언트 설정.
`네임스페이스`	`string`	네트워크 Observability Pod가 배포되는 네임스페이스입니다.
`프로세서`	`object`	`프로세서는` 에이전트에서 흐름을 수신하고, 보강하고, 메트릭을 생성하고, Loki 지속성 계층 및/또는 사용 가능한 내보내기로 전달하는 구성 요소의 설정을 정의합니다.

10.1.3. .spec.agent

설명: 흐름 추출에 대한 에이전트 구성입니다.
유형: object

속성	유형	설명
`ebpf`	`object`	`eBPF 는` `spec.agent.type` 이 eBPF로 설정된 경우 eBPF 기반 흐름 보고기와 관련된 설정을 설명합니다.
`ipfix`	`object`	`ipFI` X [deprecated (*)] - `spec.agent.type` 이 IPFIX로 설정된 경우 `IPFIX` 기반 흐름 보고기와 관련된 설정을 설명합니다.
`type`	`string`	`type` 은 흐름 추적 에이전트를 선택합니다. 가능한 값은 다음과 같습니다. - `eBPF` (기본값)는 네트워크 Observability eBPF 에이전트를 사용합니다. - 기존 `IPFIX` 컬렉터를 사용하기 위해. `eBPF` 는 더 나은 성능을 제공하고 클러스터에 설치된 CNI와 관계없이 작동해야 합니다. `IPFIX` 는 OVN-Kubernetes CNI에서 작동합니다(IPFIX 내보내기를 지원하는 경우 다른 CNI가 작동할 수 있지만 수동 구성이 필요합니다).

10.1.4. .spec.agent.ebpf

설명: eBPF 는 spec.agent.type 이 eBPF로 설정된 경우 eBPF 기반 흐름 보고기와 관련된 설정을 설명합니다.
유형: object

속성	유형	설명
`고급`	`object`	`Advanced` 를 사용하면 eBPF 에이전트의 내부 구성의 일부 측면을 설정할 수 있습니다. 이 섹션은 `GOGC` 및 `GOMAXPROCS` env vars와 같은 디버깅 및 세분화된 성능 최적화를 목표로 합니다. 이러한 값을 at your own risk로 설정합니다.
`cacheActiveTimeout`	`string`	`cacheActiveTimeout` 은 보고자가 전송하기 전에 집계하는 최대 기간입니다. `cacheMaxFlows` 및 `cacheActiveTimeout` 을 늘리면 네트워크 트래픽 오버헤드와 CPU 로드를 줄일 수 있지만 더 많은 메모리 소비와 흐름 컬렉션에서 대기 시간이 증가할 수 있습니다.
`cacheMaxFlows`	`integer`	`cacheMaxFlows` 는 집계의 최대 흐름 수입니다. 도달한 경우 보고자가 흐름을 보냅니다. `cacheMaxFlows` 및 `cacheActiveTimeout` 을 늘리면 네트워크 트래픽 오버헤드와 CPU 로드를 줄일 수 있지만 더 많은 메모리 소비와 흐름 컬렉션에서 대기 시간이 증가할 수 있습니다.
`excludeInterfaces`	`배열(문자열)`	`excludeInterfaces` 에는 흐름 추적에서 제외된 인터페이스 이름이 포함되어 있습니다. 슬래시로 묶은 항목(예: `/br-/` )은 정규식으로 일치합니다. 그렇지 않으면 대소문자를 구분하지 않는 문자열로 일치됩니다.
`features`	`배열(문자열)`	활성화할 추가 기능 목록입니다. 모두 기본적으로 비활성화되어 있습니다. 추가 기능을 활성화하면 성능에 영향을 미칠 수 있습니다. 가능한 값은 다음과 같습니다. - `PacketDrop`: 패킷 삭제 흐름 로깅 기능을 활성화합니다. 이 기능을 사용하려면 커널 디버그 파일 시스템을 마운트해야 하므로 eBPF Pod를 privileged로 실행해야 합니다. `spec.agent.ebpf.privileged` 매개변수가 설정되지 않은 경우 오류가 보고됩니다. - `DNSTracking`: DNS 추적 기능을 활성화합니다. - `FlowRTT`: TCP 핸드셰이크 중에 eBPF 에이전트에서 RTT( flow latency) 계산을 활성화합니다. 이 기능은 `샘플링` 1에서 더 잘 작동합니다.
`imagePullPolicy`	`string`	`imagePullPolicy` 는 위에 정의된 이미지의 Kubernetes 가져오기 정책입니다.
`인터페이스`	`배열(문자열)`	`인터페이스에` 는 흐름이 수집되는 위치의 인터페이스 이름이 포함되어 있습니다. 비어 있는 경우 에이전트는 ExcludeInterfaces에 나열된 인터페이스를 제외하고 시스템의 모든 인터페이스를 가져옵니다. 슬래시로 묶은 항목(예: `/br-/` )은 정규식으로 일치합니다. 그렇지 않으면 대소문자를 구분하지 않는 문자열로 일치됩니다.
`kafkaBatchSize`	`integer`	`kafkaBatchSize` 는 파티션으로 전송되기 전에 요청의 최대 크기를 바이트 단위로 제한합니다. Kafka를 사용하지 않을 때는 무시됩니다. 기본값: 10MB.
`logLevel`	`string`	`loglevel` 은 Network Observability eBPF Agent의 로그 수준을 정의합니다.
`privileged`	`boolean`	eBPF 에이전트 컨테이너의 권한 모드입니다. 무시하거나 `false` 로 설정하면 Operator는 세분화된 기능(BPF, PERFMON, NET_ADMIN, SYS_RESOURCE)을 컨테이너로 설정합니다. 어떤 이유로든 이러한 기능을 설정할 수 없는 경우(예: CAP_BPF를 모르는 이전 커널 버전이 사용 중인 경우 보다 글로벌 권한을 위해 이 모드를 켤 수 있습니다. 일부 에이전트 기능에는 패킷 드롭 추적과 같은 권한 있는 모드가 필요합니다( `기능`참조) 및 SR-IOV 지원.
`resources`	`object`	`리소스는` 이 컨테이너에 필요한 컴퓨팅 리소스입니다. 자세한 내용은 https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
`sampling`	`integer`	흐름 보고기의 샘플링 속도입니다. 100은 100에 하나의 흐름이 전송되었음을 의미합니다. 0 또는 1은 모든 흐름이 샘플링됨을 의미합니다.

10.1.5. .spec.agent.ebpf.advanced

설명: Advanced 를 사용하면 eBPF 에이전트의 내부 구성의 일부 측면을 설정할 수 있습니다. 이 섹션은 GOGC 및 GOMAXPROCS env vars와 같은 디버깅 및 세분화된 성능 최적화를 목표로 합니다. 이러한 값을 at your own risk로 설정합니다.
유형: object

속성	유형	설명
`env`	`오브젝트(문자열)`	`env` 를 사용하면 사용자 지정 환경 변수를 기본 구성 요소에 전달할 수 있습니다. `GOGC` 및 `GOMAXPROCS` 와 같은 매우 구체적인 성능 튜닝 옵션을 전달하는 데 유용합니다. 이는 에지 디버그 또는 지원 시나리오에서만 유용하므로 FlowCollector 설명자의 일부로 공개적으로 노출해서는 안 됩니다.

10.1.6. .spec.agent.ebpf.resources

설명: 리소스는 이 컨테이너에 필요한 컴퓨팅 리소스입니다. 자세한 내용은 https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
유형: object

속성	유형	설명
`limits`	`integer-or-string`	제한은 허용되는 최대 컴퓨팅 리소스 양을 나타냅니다. 자세한 내용은 https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
`requests`	`integer-or-string`	요청은 필요한 최소 컴퓨팅 리소스 양을 설명합니다. 컨테이너에 대한 Requests를 생략하면 구현 정의된 값을 제외하고 명시적으로 지정된 경우 기본값은 Limits로 설정됩니다. 요청은 제한을 초과할 수 없습니다. 자세한 내용은 https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

10.1.7. .spec.agent.ipfix

설명: ipFI X [deprecated (*)] - spec.agent.type 이 IPFIX로 설정된 경우 IPFIX 기반 흐름 보고기와 관련된 설정을 설명합니다.
유형: object

속성	유형	설명
`cacheActiveTimeout`	`string`	`cacheActiveTimeout` 은 보고자가 전송하기 전에 집계하는 최대 기간입니다.
`cacheMaxFlows`	`integer`	`cacheMaxFlows` 는 집계의 최대 흐름 수입니다. 도달한 경우 보고자가 흐름을 보냅니다.
`clusterNetworkOperator`	`object`	`clusterNetworkOperator` 는 사용 가능한 경우 OpenShift Container Platform Cluster Network Operator와 관련된 설정을 정의합니다.
`forceSampleAll`	`boolean`	`forceSampleAll` 을 사용하면 IPFIX 기반 흐름 보고기에서 샘플링을 비활성화할 수 있습니다. 클러스터 불안정성을 생성할 수 있으므로 IPFIX를 사용하여 모든 트래픽을 샘플링하지 않는 것이 좋습니다. 이렇게 하려면 이 플래그를 `true` 로 설정합니다. at your own risk 입니다. `true` 로 설정하면 `샘플링` 값이 무시됩니다.
`ovnKubernetes`	`object`	`OVNKubernetes` 는 사용 가능한 경우 OVN-Kubernetes CNI의 설정을 정의합니다. 이 구성은 OpenShift Container Platform 없이 OVN의 IPFIX 내보내기를 사용할 때 사용됩니다. OpenShift Container Platform을 사용하는 경우 대신 `clusterNetworkOperator` 속성을 참조하십시오.
`sampling`	`integer`	`샘플링` 은 보고자의 샘플링 비율입니다. 100은 100에 하나의 흐름이 전송되었음을 의미합니다. 클러스터 안정성을 보장하기 위해 2 아래의 값을 설정할 수 없습니다. 클러스터 안정성에 영향을 미칠 수 있는 모든 패킷을 샘플링하려면 `forceSampleAll` 을 참조하십시오. 또는 IPFIX 대신 eBPF Agent를 사용할 수 있습니다.

10.1.8. .spec.agent.ipfix.clusterNetworkOperator

설명: clusterNetworkOperator 는 사용 가능한 경우 OpenShift Container Platform Cluster Network Operator와 관련된 설정을 정의합니다.
유형: object

속성	유형	설명
`네임스페이스`	`string`	구성 맵을 배포할 네임스페이스입니다.

10.1.9. .spec.agent.ipfix.ovnKubernetes

설명: OVNKubernetes 는 사용 가능한 경우 OVN-Kubernetes CNI의 설정을 정의합니다. 이 구성은 OpenShift Container Platform 없이 OVN의 IPFIX 내보내기를 사용할 때 사용됩니다. OpenShift Container Platform을 사용하는 경우 대신 clusterNetworkOperator 속성을 참조하십시오.
유형: object

속성	유형	설명
`containerName`	`string`	`containername` 은 IPFIX에 대해 구성할 컨테이너의 이름을 정의합니다.
`daemonSetName`	`string`	`daemonSetName` 은 OVN-Kubernetes Pod를 제어하는 DaemonSet의 이름을 정의합니다.
`네임스페이스`	`string`	OVN-Kubernetes Pod가 배포되는 네임스페이스입니다.

10.1.10. .spec.consolePlugin

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

속성	유형	설명
`고급`	`object`	`Advanced` 를 사용하면 콘솔 플러그인의 내부 구성의 일부 측면을 설정할 수 있습니다. 이 섹션은 `GOGC` 및 `GOMAXPROCS` env vars와 같은 디버깅 및 세분화된 성능 최적화를 목표로 합니다. 이러한 값을 at your own risk로 설정합니다.
`자동 스케일러`	`object`	플러그인 배포에 설정할 수평 Pod 자동 스케일러의 자동 스케일러 사양입니다. HorizontalPodAutoscaler 문서(autoscaling/v2)를 참조하십시오.
`enable`	`boolean`	콘솔 플러그인 배포를 활성화합니다. `spec.loki.enable` 도 `true`여야 합니다.
`imagePullPolicy`	`string`	`imagePullPolicy` 는 위에 정의된 이미지의 Kubernetes 가져오기 정책입니다.
`logLevel`	`string`	콘솔 플러그인 백엔드의 `로그 수준`
`portNaming`	`object`	`portNaming` 은 port-to-service 이름 변환의 구성을 정의합니다.
`quickFilters`	`array`	`quickFilters` 는 Console 플러그인에 대한 빠른 필터 사전 설정을 구성합니다.
`replicas`	`integer`	`replicas` 는 시작할 복제본(Pod) 수를 정의합니다.
`resources`	`object`	이 컨테이너에 필요한 컴퓨팅 리소스 측면에서 리소스입니다. 자세한 내용은 https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

10.1.11. .spec.consolePlugin.advanced

설명: Advanced 를 사용하면 콘솔 플러그인의 내부 구성의 일부 측면을 설정할 수 있습니다. 이 섹션은 GOGC 및 GOMAXPROCS env vars와 같은 디버깅 및 세분화된 성능 최적화를 목표로 합니다. 이러한 값을 at your own risk로 설정합니다.
유형: object

속성	유형	설명
`args`	`배열(문자열)`	`args` 를 사용하면 사용자 지정 인수를 기본 구성 요소에 전달할 수 있습니다. Edge 디버그 또는 지원 시나리오에서만 유용하므로 FlowCollector 설명자의 일부로 공개적으로 노출해서는 안 되는 일부 매개 변수를 재정의하는 데 유용합니다.
`env`	`오브젝트(문자열)`	`env` 를 사용하면 사용자 지정 환경 변수를 기본 구성 요소에 전달할 수 있습니다. `GOGC` 및 `GOMAXPROCS` 와 같은 매우 구체적인 성능 튜닝 옵션을 전달하는 데 유용합니다. 이는 에지 디버그 또는 지원 시나리오에서만 유용하므로 FlowCollector 설명자의 일부로 공개적으로 노출해서는 안 됩니다.
`port`	`integer`	`port` 는 플러그인 서비스 포트입니다. 메트릭을 위해 예약된 9002를 사용하지 마십시오.
`등록`	`boolean`	`등록` 은 `true` 로 설정하면 제공된 콘솔 플러그인을 OpenShift Container Platform 콘솔 Operator에 자동으로 등록할 수 있습니다. `false` 로 설정하면 oc patch console.operator.openshift.io/cluster를 편집하여 수동으로 등록할 수 있습니다. `oc patch console.operator.openshift.io cluster --type='json' -p '[{"op": "add", "path": "/spec/plugins/-", "value": "netobserv-plugin"}]]`

10.1.12. .spec.consolePlugin.autoscaler

설명: 플러그인 배포에 설정할 수평 Pod 자동 스케일러의 자동 스케일러 사양입니다. HorizontalPodAutoscaler 문서(autoscaling/v2)를 참조하십시오.
유형: object

10.1.13. .spec.consolePlugin.portNaming

설명: portNaming 은 port-to-service 이름 변환의 구성을 정의합니다.
유형: object

속성	유형	설명
`enable`	`boolean`	콘솔 플러그인 포트-서비스 이름 변환을 활성화
`portNames`	`오브젝트(문자열)`	`portNames` 는 콘솔에서 사용할 추가 포트 이름을 정의합니다(예 `: {"3100": "loki"}` ).

10.1.14. .spec.consolePlugin.quickFilters

설명: quickFilters 는 Console 플러그인에 대한 빠른 필터 사전 설정을 구성합니다.
유형: array

10.1.15. .spec.consolePlugin.quickFilters[]

설명

QuickFilter 는 콘솔의 빠른 필터에 대한 사전 설정 구성을 정의합니다.

유형

object

필수 항목

filter
name

속성	유형	설명
`default`	`boolean`	`default` 는 이 필터가 기본적으로 활성화되어야 하는지 여부를 정의합니다.
`filter`	`오브젝트(문자열)`	`filter` 는 이 필터를 선택할 때 설정할 키 및 값 집합입니다. 각 키는 쉼표로 구분된 문자열을 사용하여 값 목록과 연결할 수 있습니다(예: `filter: {"src_namespace": "namespace1,namespace2"}` ).
`name`	`string`	콘솔에 표시되는 필터의 이름

10.1.16. .spec.consolePlugin.resources

설명: 이 컨테이너에 필요한 컴퓨팅 리소스 측면에서 리소스입니다. 자세한 내용은 https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
유형: object

속성	유형	설명
`limits`	`integer-or-string`	제한은 허용되는 최대 컴퓨팅 리소스 양을 나타냅니다. 자세한 내용은 https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
`requests`	`integer-or-string`	요청은 필요한 최소 컴퓨팅 리소스 양을 설명합니다. 컨테이너에 대한 Requests를 생략하면 구현 정의된 값을 제외하고 명시적으로 지정된 경우 기본값은 Limits로 설정됩니다. 요청은 제한을 초과할 수 없습니다. 자세한 내용은 https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

10.1.17. .spec.exporters

설명: 내보내기 는 사용자 정의 사용 또는 스토리지에 대한 추가 선택적 내보내기를 정의합니다.
유형: array

10.1.18. .spec.exporters[]

설명

FlowCollectorExporter 는 보강된 흐름을 보낼 추가 내보내기를 정의합니다.

유형

object

필수 항목

type

속성	유형	설명
`ipfix`	`object`	강화된 IPFIX 흐름을 보내기 위한 IP 주소 및 포트와 같은 IPFIX 구성입니다.
`kafka`	`object`	풍요한 흐름을 보내기 위한 주소 및 주제와 같은 Kafka 구성입니다.
`type`	`string`	`type` 은 내보내기 유형을 선택합니다. 사용 가능한 옵션은 `Kafka` 및 `IPFIX` 입니다.

10.1.19. .spec.exporters[].ipfix

설명

강화된 IPFIX 흐름을 보내기 위한 IP 주소 및 포트와 같은 IPFIX 구성입니다.

유형

object

필수 항목

targetHost
targetPort

속성	유형	설명
`targetHost`	`string`	IPFIX 외부 수신자의 주소
`targetPort`	`integer`	IPFIX 외부 수신자용 포트
`전송`	`string`	IPFIX 연결에 사용되는 전송 프로토콜(`TCP` 또는 `UDP`)은 기본적으로 `TCP` 입니다.

10.1.20. .spec.exporters[].kafka

설명

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

유형

object

필수 항목

address
topic

속성	유형	설명
`address`	`string`	Kafka 서버의 주소
`SASL`	`object`	SASL 인증 구성. [지원되지 않음(*)].
`tls`	`object`	TLS 클라이언트 구성. TLS를 사용하는 경우 주소가 TLS에 사용되는 Kafka 포트(일반적으로 9093)와 일치하는지 확인합니다.
`topic`	`string`	사용할 Kafka 주제입니다. 존재할 수 있어야 합니다. Network Observability는 이를 생성하지 않습니다.

10.1.21. .spec.exporters[].kafka.sasl

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

속성	유형	설명
`clientIDReference`	`object`	클라이언트 ID가 포함된 시크릿 또는 구성 맵에 대한 참조
`clientSecretReference`	`object`	클라이언트 보안이 포함된 시크릿 또는 구성 맵에 대한 참조
`type`	`string`	사용할 SASL 인증 유형 또는 SASL을 사용하지 않는 경우 `Disabled`

10.1.22. .spec.exporters[].kafka.sasl.clientIDReference

설명: 클라이언트 ID가 포함된 시크릿 또는 구성 맵에 대한 참조
유형: object

속성	유형	설명
`file`	`string`	구성 맵 또는 시크릿 내의 파일 이름
`name`	`string`	파일이 포함된 구성 맵 또는 시크릿의 이름
`네임스페이스`	`string`	파일이 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.
`type`	`string`	파일 참조에 대해 "configmap" 또는 "secret"을 입력합니다.

10.1.23. .spec.exporters[].kafka.sasl.clientSecretReference

설명: 클라이언트 보안이 포함된 시크릿 또는 구성 맵에 대한 참조
유형: object

속성	유형	설명
`file`	`string`	구성 맵 또는 시크릿 내의 파일 이름
`name`	`string`	파일이 포함된 구성 맵 또는 시크릿의 이름
`네임스페이스`	`string`	파일이 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.
`type`	`string`	파일 참조에 대해 "configmap" 또는 "secret"을 입력합니다.

10.1.24. .spec.exporters[].kafka.tls

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

속성	유형	설명
`caCert`	`object`	`cacert는 인증` 기관의 인증서 참조를 정의합니다.
`enable`	`boolean`	TLS 활성화
`insecureSkipVerify`	`boolean`	`insecureSkipVerify` 를 사용하면 서버 인증서의 클라이언트 측 확인을 건너뛸 수 있습니다. `true` 로 설정하면 `caCert` 필드가 무시됩니다.
`userCert`	`object`	`UserCert` 는 사용자 인증서 참조를 정의하고 mTLS에 사용됩니다(단방향 TLS 사용 시 무시할 수 있음)

10.1.25. .spec.exporters[].kafka.tls.caCert

설명: cacert는 인증 기관의 인증서 참조를 정의합니다.
유형: object

속성	유형	설명
`certFile`	`string`	`cert` file은 구성 맵 또는 시크릿 내의 인증서 파일 이름의 경로를 정의합니다.
`certKey`	`string`	`certKey` 는 구성 맵 또는 시크릿 내의 인증서 개인 키 파일 이름의 경로를 정의합니다. 키가 필요하지 않은 경우 생략합니다.
`name`	`string`	인증서가 포함된 구성 맵 또는 시크릿의 이름
`네임스페이스`	`string`	인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.
`type`	`string`	인증서 참조에 대한 유형: `configmap` 또는 `secret`

10.1.26. .spec.exporters[].kafka.tls.userCert

설명: UserCert 는 사용자 인증서 참조를 정의하고 mTLS에 사용됩니다(단방향 TLS 사용 시 무시할 수 있음)
유형: object

속성	유형	설명
`certFile`	`string`	`cert` file은 구성 맵 또는 시크릿 내의 인증서 파일 이름의 경로를 정의합니다.
`certKey`	`string`	`certKey` 는 구성 맵 또는 시크릿 내의 인증서 개인 키 파일 이름의 경로를 정의합니다. 키가 필요하지 않은 경우 생략합니다.
`name`	`string`	인증서가 포함된 구성 맵 또는 시크릿의 이름
`네임스페이스`	`string`	인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.
`type`	`string`	인증서 참조에 대한 유형: `configmap` 또는 `secret`

10.1.27. .spec.kafka

설명

Kafka 구성을 통해 Kafka를 흐름 컬렉션 파이프라인의 일부로 브로커로 사용할 수 있습니다. spec.deploymentModel 이 Kafka 인 경우 사용할 수 있습니다.

유형

object

필수 항목

address
topic

속성	유형	설명
`address`	`string`	Kafka 서버의 주소
`SASL`	`object`	SASL 인증 구성. [지원되지 않음(*)].
`tls`	`object`	TLS 클라이언트 구성. TLS를 사용하는 경우 주소가 TLS에 사용되는 Kafka 포트(일반적으로 9093)와 일치하는지 확인합니다.
`topic`	`string`	사용할 Kafka 주제입니다. 존재할 수 있어야 합니다. Network Observability는 이를 생성하지 않습니다.

10.1.28. .spec.kafka.sasl

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

속성	유형	설명
`clientIDReference`	`object`	클라이언트 ID가 포함된 시크릿 또는 구성 맵에 대한 참조
`clientSecretReference`	`object`	클라이언트 보안이 포함된 시크릿 또는 구성 맵에 대한 참조
`type`	`string`	사용할 SASL 인증 유형 또는 SASL을 사용하지 않는 경우 `Disabled`

10.1.29. .spec.kafka.sasl.clientIDReference

설명: 클라이언트 ID가 포함된 시크릿 또는 구성 맵에 대한 참조
유형: object

속성	유형	설명
`file`	`string`	구성 맵 또는 시크릿 내의 파일 이름
`name`	`string`	파일이 포함된 구성 맵 또는 시크릿의 이름
`네임스페이스`	`string`	파일이 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.
`type`	`string`	파일 참조에 대해 "configmap" 또는 "secret"을 입력합니다.

10.1.30. .spec.kafka.sasl.clientSecretReference

설명: 클라이언트 보안이 포함된 시크릿 또는 구성 맵에 대한 참조
유형: object

속성	유형	설명
`file`	`string`	구성 맵 또는 시크릿 내의 파일 이름
`name`	`string`	파일이 포함된 구성 맵 또는 시크릿의 이름
`네임스페이스`	`string`	파일이 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.
`type`	`string`	파일 참조에 대해 "configmap" 또는 "secret"을 입력합니다.

10.1.31. .spec.kafka.tls

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

속성	유형	설명
`caCert`	`object`	`cacert는 인증` 기관의 인증서 참조를 정의합니다.
`enable`	`boolean`	TLS 활성화
`insecureSkipVerify`	`boolean`	`insecureSkipVerify` 를 사용하면 서버 인증서의 클라이언트 측 확인을 건너뛸 수 있습니다. `true` 로 설정하면 `caCert` 필드가 무시됩니다.
`userCert`	`object`	`UserCert` 는 사용자 인증서 참조를 정의하고 mTLS에 사용됩니다(단방향 TLS 사용 시 무시할 수 있음)

10.1.32. .spec.kafka.tls.caCert

설명: cacert는 인증 기관의 인증서 참조를 정의합니다.
유형: object

속성	유형	설명
`certFile`	`string`	`cert` file은 구성 맵 또는 시크릿 내의 인증서 파일 이름의 경로를 정의합니다.
`certKey`	`string`	`certKey` 는 구성 맵 또는 시크릿 내의 인증서 개인 키 파일 이름의 경로를 정의합니다. 키가 필요하지 않은 경우 생략합니다.
`name`	`string`	인증서가 포함된 구성 맵 또는 시크릿의 이름
`네임스페이스`	`string`	인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.
`type`	`string`	인증서 참조에 대한 유형: `configmap` 또는 `secret`

10.1.33. .spec.kafka.tls.userCert

설명: UserCert 는 사용자 인증서 참조를 정의하고 mTLS에 사용됩니다(단방향 TLS 사용 시 무시할 수 있음)
유형: object

속성	유형	설명
`certFile`	`string`	`cert` file은 구성 맵 또는 시크릿 내의 인증서 파일 이름의 경로를 정의합니다.
`certKey`	`string`	`certKey` 는 구성 맵 또는 시크릿 내의 인증서 개인 키 파일 이름의 경로를 정의합니다. 키가 필요하지 않은 경우 생략합니다.
`name`	`string`	인증서가 포함된 구성 맵 또는 시크릿의 이름
`네임스페이스`	`string`	인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.
`type`	`string`	인증서 참조에 대한 유형: `configmap` 또는 `secret`

10.1.34. .spec.loki

설명: Loki, 흐름 저장소, 클라이언트 설정.
유형: object

속성	유형	설명
`고급`	`object`	`Advanced` 를 사용하면 Loki 클라이언트의 내부 구성의 일부 측면을 설정할 수 있습니다. 이 섹션은 디버깅 및 세분화된 성능 최적화를 목표로 합니다.
`enable`	`boolean`	Loki에 흐름을 저장하려면 `enable` 를 `true` 로 설정합니다. OpenShift Container Platform 콘솔 플러그인 설치에 필요합니다.
`lokiStack`	`object`	`LokiStack` 모드에 대한 Loki 구성입니다. 이 기능은 쉽게 loki-operator 구성에 유용합니다. 다른 모드에서는 무시됩니다.
`Manual`	`object`	`수동` 모드의 Loki 구성. 이는 가장 유연한 구성입니다. 다른 모드에서는 무시됩니다.
`마이크로 서비스`	`object`	`마이크로 서비스` 모드에 대한 Loki 구성입니다. 마이크로 서비스 배포 모드(https://grafana.com/docs/loki/latest/fundamentals/architecture/deployment-modes/#microservices-mode)를 사용하여 Loki를 설치할 때 이 옵션을 사용합니다. 다른 모드에서는 무시됩니다.
`mode`	`string`	`mode` must be set according to the installation mode of Loki: - Loki가 `Loki` Operator를 사용하여 관리될 때 Lokistack 사용 - Loki가 모놀리식 워크로드로 설치될 때 Lokilithic 사용 - Loki가 마이크로 서비스로 설치될 때 마이크로 서비스 사용, Loki Operator 없이 `Microservices` 사용 - 위의 옵션이 설정과 일치하지 않는 경우 `Manual` 을 사용합니다.
`모놀리식`	`object`	Cryostat 모드에 대한 `Loki` 구성입니다. Loki가 모놀리식 배포 모드(https://grafana.com/docs/loki/latest/fundamentals/architecture/deployment-modes/#monolithic-mode)를 사용하여 설치할 때 이 옵션을 사용합니다. 다른 모드에서는 무시됩니다.
`readTimeout`	`string`	`readTimeout` 은 최대 콘솔 플러그인 loki 쿼리의 총 시간 제한입니다. 시간 초과가 0이면 시간 초과가 없음을 의미합니다.
`writeBatchSize`	`integer`	`writeBatchSize` 는 전송 전에 누적되는 Loki 로그의 최대 배치 크기(바이트)입니다.
`writeBatchWait`	`string`	`writeBatchWait` 은 Loki 일괄 처리를 보내기 전에 대기하는 최대 시간입니다.
`writeTimeout`	`string`	`writeTimeout` 은 최대 Loki 시간 연결/요청 제한입니다. 시간 초과가 0이면 시간 초과가 없음을 의미합니다.

10.1.35. .spec.loki.advanced

설명: Advanced 를 사용하면 Loki 클라이언트의 내부 구성의 일부 측면을 설정할 수 있습니다. 이 섹션은 디버깅 및 세분화된 성능 최적화를 목표로 합니다.
유형: object

속성	유형	설명
`staticLabels`	`오브젝트(문자열)`	`staticLabels` 는 Loki 스토리지의 각 흐름에 설정할 수 있는 공통 레이블의 맵입니다.
`writeMaxBackoff`	`string`	`writeMaxBackoff` 는 재시도 사이의 Loki 클라이언트 연결의 최대 백오프 시간입니다.
`writeMaxRetries`	`integer`	`writeMaxRetries` 는 Loki 클라이언트 연결에 대한 최대 재시도 횟수입니다.
`writeMinBackoff`	`string`	`writeMinBackoff` 는 재시도 사이의 Loki 클라이언트 연결의 초기 백오프 시간입니다.

10.1.36. .spec.loki.lokiStack

설명: LokiStack 모드에 대한 Loki 구성입니다. 이 기능은 쉽게 loki-operator 구성에 유용합니다. 다른 모드에서는 무시됩니다.
유형: object

속성	유형	설명
`name`	`string`	사용할 기존 LokiStack 리소스의 이름입니다.
`네임스페이스`	`string`	이 `LokiStack` 리소스가 있는 네임스페이스입니다. 생략하면 `spec.namespace` 와 동일한 것으로 간주됩니다.

10.1.37. .spec.loki.manual

설명: 수동 모드의 Loki 구성. 이는 가장 유연한 구성입니다. 다른 모드에서는 무시됩니다.
유형: object

속성	유형	설명
`authToken`	`string`	`authtoken은 Loki에 인증할 토큰` 을 가져오는 방법을 설명합니다. - `Disabled` 는 요청과 함께 토큰을 보내지 않습니다. - 앞으로는 승인을 위해 사용자 토큰을 전달합니다. - `호스트` [deprecated (*)] - 로컬 Pod 서비스 계정을 사용하여 Loki에 인증합니다. Loki Operator를 사용하는 경우 이 Operator를 `Forward` 로 설정해야 합니다.
`ingesterUrl`	`string`	`ingesterUrl` 은 흐름을 내보내는 기존 Loki ingester 서비스의 주소입니다. Loki Operator를 사용할 때 경로에 설정된 `네트워크` 테넌트를 사용하여 Loki 게이트웨이 서비스로 설정합니다(예: https://loki-gateway-http.netobserv.svc:8080/api/logs/v1/network ).
`querierUrl`	`string`	`querierUrl` 은 Loki querier 서비스의 주소를 지정합니다. Loki Operator를 사용할 때 경로에 설정된 `네트워크` 테넌트를 사용하여 Loki 게이트웨이 서비스로 설정합니다(예: https://loki-gateway-http.netobserv.svc:8080/api/logs/v1/network ).
`statusTls`	`object`	Loki 상태 URL에 대한 TLS 클라이언트 구성
`statusUrl`	`string`	`statusUrl` 은 Loki `/ready`,`/metrics` 및 `/config` 끝점의 주소를 지정합니다. 경우 Loki querier URL과 다릅니다. 비어 있는 경우 `querierUrl` 값이 사용됩니다. 이 기능은 프런트 엔드에서 오류 메시지와 일부 컨텍스트를 표시하는 데 유용합니다. Loki Operator를 사용하는 경우 Loki HTTP 쿼리 프런트 엔드 서비스로 설정합니다(예: https://loki-query-frontend-http.netobserv.svc:3100/ ). `statusUrl` 이 설정된 경우 `statusTLS` 구성이 사용됩니다.
`tenantID`	`string`	`tenantId` 는 각 요청에 대해 테넌트를 식별하는 Loki `X-Scope-OrgID` 입니다. Loki Operator를 사용하는 경우 특수 테넌트 모드에 해당하는 `네트워크` 로 설정합니다.
`tls`	`object`	Loki URL에 대한 TLS 클라이언트 구성

10.1.38. .spec.loki.manual.statusTls

설명: Loki 상태 URL에 대한 TLS 클라이언트 구성
유형: object

속성	유형	설명
`caCert`	`object`	`cacert는 인증` 기관의 인증서 참조를 정의합니다.
`enable`	`boolean`	TLS 활성화
`insecureSkipVerify`	`boolean`	`insecureSkipVerify` 를 사용하면 서버 인증서의 클라이언트 측 확인을 건너뛸 수 있습니다. `true` 로 설정하면 `caCert` 필드가 무시됩니다.
`userCert`	`object`	`UserCert` 는 사용자 인증서 참조를 정의하고 mTLS에 사용됩니다(단방향 TLS 사용 시 무시할 수 있음)

10.1.39. .spec.loki.manual.statusTls.caCert

설명: cacert는 인증 기관의 인증서 참조를 정의합니다.
유형: object

속성	유형	설명
`certFile`	`string`	`cert` file은 구성 맵 또는 시크릿 내의 인증서 파일 이름의 경로를 정의합니다.
`certKey`	`string`	`certKey` 는 구성 맵 또는 시크릿 내의 인증서 개인 키 파일 이름의 경로를 정의합니다. 키가 필요하지 않은 경우 생략합니다.
`name`	`string`	인증서가 포함된 구성 맵 또는 시크릿의 이름
`네임스페이스`	`string`	인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.
`type`	`string`	인증서 참조에 대한 유형: `configmap` 또는 `secret`

10.1.40. .spec.loki.manual.statusTls.userCert

설명: UserCert 는 사용자 인증서 참조를 정의하고 mTLS에 사용됩니다(단방향 TLS 사용 시 무시할 수 있음)
유형: object

속성	유형	설명
`certFile`	`string`	`cert` file은 구성 맵 또는 시크릿 내의 인증서 파일 이름의 경로를 정의합니다.
`certKey`	`string`	`certKey` 는 구성 맵 또는 시크릿 내의 인증서 개인 키 파일 이름의 경로를 정의합니다. 키가 필요하지 않은 경우 생략합니다.
`name`	`string`	인증서가 포함된 구성 맵 또는 시크릿의 이름
`네임스페이스`	`string`	인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.
`type`	`string`	인증서 참조에 대한 유형: `configmap` 또는 `secret`

10.1.41. .spec.loki.manual.tls

설명: Loki URL에 대한 TLS 클라이언트 구성
유형: object

속성	유형	설명
`caCert`	`object`	`cacert는 인증` 기관의 인증서 참조를 정의합니다.
`enable`	`boolean`	TLS 활성화
`insecureSkipVerify`	`boolean`	`insecureSkipVerify` 를 사용하면 서버 인증서의 클라이언트 측 확인을 건너뛸 수 있습니다. `true` 로 설정하면 `caCert` 필드가 무시됩니다.
`userCert`	`object`	`UserCert` 는 사용자 인증서 참조를 정의하고 mTLS에 사용됩니다(단방향 TLS 사용 시 무시할 수 있음)

10.1.42. .spec.loki.manual.tls.caCert

설명: cacert는 인증 기관의 인증서 참조를 정의합니다.
유형: object

속성	유형	설명
`certFile`	`string`	`cert` file은 구성 맵 또는 시크릿 내의 인증서 파일 이름의 경로를 정의합니다.
`certKey`	`string`	`certKey` 는 구성 맵 또는 시크릿 내의 인증서 개인 키 파일 이름의 경로를 정의합니다. 키가 필요하지 않은 경우 생략합니다.
`name`	`string`	인증서가 포함된 구성 맵 또는 시크릿의 이름
`네임스페이스`	`string`	인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.
`type`	`string`	인증서 참조에 대한 유형: `configmap` 또는 `secret`

10.1.43. .spec.loki.manual.tls.userCert

설명: UserCert 는 사용자 인증서 참조를 정의하고 mTLS에 사용됩니다(단방향 TLS 사용 시 무시할 수 있음)
유형: object

속성	유형	설명
`certFile`	`string`	`cert` file은 구성 맵 또는 시크릿 내의 인증서 파일 이름의 경로를 정의합니다.
`certKey`	`string`	`certKey` 는 구성 맵 또는 시크릿 내의 인증서 개인 키 파일 이름의 경로를 정의합니다. 키가 필요하지 않은 경우 생략합니다.
`name`	`string`	인증서가 포함된 구성 맵 또는 시크릿의 이름
`네임스페이스`	`string`	인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.
`type`	`string`	인증서 참조에 대한 유형: `configmap` 또는 `secret`

10.1.44. .spec.loki.microservices

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

속성	유형	설명
`ingesterUrl`	`string`	`ingesterUrl` 은 흐름을 내보내는 기존 Loki ingester 서비스의 주소입니다.
`querierUrl`	`string`	`querierURL` 은 Loki querier 서비스의 주소를 지정합니다.
`tenantID`	`string`	`tenantId` 는 각 요청에 대해 테넌트를 식별하는 Loki `X-Scope-OrgID` 헤더입니다.
`tls`	`object`	Loki URL에 대한 TLS 클라이언트 구성

10.1.45. .spec.loki.microservices.tls

설명: Loki URL에 대한 TLS 클라이언트 구성
유형: object

속성	유형	설명
`caCert`	`object`	`cacert는 인증` 기관의 인증서 참조를 정의합니다.
`enable`	`boolean`	TLS 활성화
`insecureSkipVerify`	`boolean`	`insecureSkipVerify` 를 사용하면 서버 인증서의 클라이언트 측 확인을 건너뛸 수 있습니다. `true` 로 설정하면 `caCert` 필드가 무시됩니다.
`userCert`	`object`	`UserCert` 는 사용자 인증서 참조를 정의하고 mTLS에 사용됩니다(단방향 TLS 사용 시 무시할 수 있음)

10.1.46. .spec.loki.microservices.tls.caCert

설명: cacert는 인증 기관의 인증서 참조를 정의합니다.
유형: object

속성	유형	설명
`certFile`	`string`	`cert` file은 구성 맵 또는 시크릿 내의 인증서 파일 이름의 경로를 정의합니다.
`certKey`	`string`	`certKey` 는 구성 맵 또는 시크릿 내의 인증서 개인 키 파일 이름의 경로를 정의합니다. 키가 필요하지 않은 경우 생략합니다.
`name`	`string`	인증서가 포함된 구성 맵 또는 시크릿의 이름
`네임스페이스`	`string`	인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.
`type`	`string`	인증서 참조에 대한 유형: `configmap` 또는 `secret`

10.1.47. .spec.loki.microservices.tls.userCert

설명: UserCert 는 사용자 인증서 참조를 정의하고 mTLS에 사용됩니다(단방향 TLS 사용 시 무시할 수 있음)
유형: object

속성	유형	설명
`certFile`	`string`	`cert` file은 구성 맵 또는 시크릿 내의 인증서 파일 이름의 경로를 정의합니다.
`certKey`	`string`	`certKey` 는 구성 맵 또는 시크릿 내의 인증서 개인 키 파일 이름의 경로를 정의합니다. 키가 필요하지 않은 경우 생략합니다.
`name`	`string`	인증서가 포함된 구성 맵 또는 시크릿의 이름
`네임스페이스`	`string`	인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.
`type`	`string`	인증서 참조에 대한 유형: `configmap` 또는 `secret`

10.1.48. .spec.loki.monolithic

설명: Cryostat 모드에 대한 Loki 구성입니다. Loki가 모놀리식 배포 모드(https://grafana.com/docs/loki/latest/fundamentals/architecture/deployment-modes/#monolithic-mode)를 사용하여 설치할 때 이 옵션을 사용합니다. 다른 모드에서는 무시됩니다.
유형: object

속성	유형	설명
`tenantID`	`string`	`tenantId` 는 각 요청에 대해 테넌트를 식별하는 Loki `X-Scope-OrgID` 헤더입니다.
`tls`	`object`	Loki URL에 대한 TLS 클라이언트 구성
`url`	`string`	`URL` 은 ingester와 querier를 둘 다 가리키는 기존 Loki 서비스의 고유한 주소입니다.

10.1.49. .spec.loki.monolithic.tls

설명: Loki URL에 대한 TLS 클라이언트 구성
유형: object

속성	유형	설명
`caCert`	`object`	`cacert는 인증` 기관의 인증서 참조를 정의합니다.
`enable`	`boolean`	TLS 활성화
`insecureSkipVerify`	`boolean`	`insecureSkipVerify` 를 사용하면 서버 인증서의 클라이언트 측 확인을 건너뛸 수 있습니다. `true` 로 설정하면 `caCert` 필드가 무시됩니다.
`userCert`	`object`	`UserCert` 는 사용자 인증서 참조를 정의하고 mTLS에 사용됩니다(단방향 TLS 사용 시 무시할 수 있음)

10.1.50. .spec.loki.monolithic.tls.caCert

설명: cacert는 인증 기관의 인증서 참조를 정의합니다.
유형: object

속성	유형	설명
`certFile`	`string`	`cert` file은 구성 맵 또는 시크릿 내의 인증서 파일 이름의 경로를 정의합니다.
`certKey`	`string`	`certKey` 는 구성 맵 또는 시크릿 내의 인증서 개인 키 파일 이름의 경로를 정의합니다. 키가 필요하지 않은 경우 생략합니다.
`name`	`string`	인증서가 포함된 구성 맵 또는 시크릿의 이름
`네임스페이스`	`string`	인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.
`type`	`string`	인증서 참조에 대한 유형: `configmap` 또는 `secret`

10.1.51. .spec.loki.monolithic.tls.userCert

설명: UserCert 는 사용자 인증서 참조를 정의하고 mTLS에 사용됩니다(단방향 TLS 사용 시 무시할 수 있음)
유형: object

속성	유형	설명
`certFile`	`string`	`cert` file은 구성 맵 또는 시크릿 내의 인증서 파일 이름의 경로를 정의합니다.
`certKey`	`string`	`certKey` 는 구성 맵 또는 시크릿 내의 인증서 개인 키 파일 이름의 경로를 정의합니다. 키가 필요하지 않은 경우 생략합니다.
`name`	`string`	인증서가 포함된 구성 맵 또는 시크릿의 이름
`네임스페이스`	`string`	인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.
`type`	`string`	인증서 참조에 대한 유형: `configmap` 또는 `secret`

10.1.52. .spec.processor

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

속성	유형	설명
`addZone`	`boolean`	`addZone` 은 소스 및 대상 영역의 흐름에 레이블을 지정하여 가용성 영역 인식을 허용합니다. 이 기능을 사용하려면 노드에 "topology.kubernetes.io/zone" 라벨을 설정해야 합니다.
`고급`	`object`	`Advanced` 를 사용하면 흐름 프로세서의 내부 구성의 일부 측면을 설정할 수 있습니다. 이 섹션은 `GOGC` 및 `GOMAXPROCS` env vars와 같은 디버깅 및 세분화된 성능 최적화를 목표로 합니다. 이러한 값을 at your own risk로 설정합니다.
`clusterName`	`string`	`cluster` name은 흐름 데이터에 표시할 클러스터의 이름입니다. 이는 다중 클러스터 컨텍스트에서 유용합니다. OpenShift Container Platform을 사용하는 경우 자동으로 결정되도록 비워 둡니다.
`imagePullPolicy`	`string`	`imagePullPolicy` 는 위에 정의된 이미지의 Kubernetes 가져오기 정책입니다.
`kafkaConsumerAutoscaler`	`object`	`kafkaConsumerAutoscaler` 는 Kafka 메시지를 사용하는 `flowlogs-pipeline-transformer` 에 대해 설정하는 수평 Pod 자동 스케일러의 사양입니다. 이 설정은 Kafka가 비활성화되면 무시됩니다. HorizontalPodAutoscaler 문서(autoscaling/v2)를 참조하십시오.
`kafkaConsumerBatchSize`	`integer`	`kafkaConsumerBatchSize` 는 브로커에게 소비자가 허용하는 최대 배치 크기(바이트)를 나타냅니다. Kafka를 사용하지 않을 때는 무시됩니다. 기본값: 10MB.
`kafkaConsumerQueueCapacity`	`integer`	`kafkaConsumerQueueCapacity` 는 Kafka 소비자 클라이언트에서 사용되는 내부 메시지 큐의 용량을 정의합니다. Kafka를 사용하지 않을 때는 무시됩니다.
`kafkaConsumerReplicas`	`integer`	`kafkaConsumerReplicas` 는 Kafka 메시지를 사용하는 `flowlogs-pipeline-transformer` 용으로 시작할 복제본(pod) 수를 정의합니다. 이 설정은 Kafka가 비활성화되면 무시됩니다.
`logLevel`	`string`	프로세서 런타임의 `로그 수준`
`logTypes`	`string`	`logTypes` 는 생성할 원하는 레코드 유형을 정의합니다. 가능한 값은 다음과 같습니다. - 일반 네트워크 흐름을 내보낼 흐름(기본값) - 시작된 대화에 대한 이벤트를 생성하는 대화, 정기된 대화 및 주기적인 "tick" 업데이트 - 종료된 대화 이벤트만 생성하는 엔드드인 대화 이벤트 - 모두 네트워크 흐름과 `모든` 대화 이벤트를 생성할 수 있습니다.
`메트릭`	`object`	`메트릭` 은 메트릭과 관련된 프로세서 구성을 정의합니다.
`multiClusterDeployment`	`boolean`	다중 클러스터 기능을 활성화하려면 `multiClusterDeployment` 을 `true` 로 설정합니다. 이를 통해 데이터 흐름을 위해 `clusterName` 레이블이 추가되었습니다.
`resources`	`object`	`리소스는` 이 컨테이너에 필요한 컴퓨팅 리소스입니다. 자세한 내용은 https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

10.1.53. .spec.processor.advanced

설명: Advanced 를 사용하면 흐름 프로세서의 내부 구성의 일부 측면을 설정할 수 있습니다. 이 섹션은 GOGC 및 GOMAXPROCS env vars와 같은 디버깅 및 세분화된 성능 최적화를 목표로 합니다. 이러한 값을 at your own risk로 설정합니다.
유형: object

속성	유형	설명
`conversationEndTimeout`	`string`	`conversationEndTimeout` 은 대화가 종료되었다고 간주하기 위해 네트워크 흐름을 수신한 후 대기하는 시간입니다. 이 지연은 FIN 패킷이 TCP 흐름에 대해 수집될 때 무시됩니다(대신 `conversationTerminatingTimeout` 참조).
`conversationHeartbeatInterval`	`string`	`conversationHeartbeatInterval` 은 대화의 "틱" 이벤트 사이에 대기하는 시간입니다.
`conversationTerminatingTimeout`	`string`	`conversationTerminatingTimeout` 은 대화를 종료하기 위해 감지된 FIN 플래그에서 대기하는 시간입니다. TCP 흐름에만 관련이 있습니다.
`dropUnusedFields`	`boolean`	`dropUnusedFields` 를 사용하면 `true` 로 설정하면 OVS에서 사용하지 않는 것으로 알려진 필드를 삭제하여 스토리지 공간을 절약할 수 있습니다.
`enableKubeProbes`	`boolean`	`enableKubeProbes` 는 Kubernetes 활성 및 준비 상태 프로브를 활성화하거나 비활성화하는 플래그입니다.
`env`	`오브젝트(문자열)`	`env` 를 사용하면 사용자 지정 환경 변수를 기본 구성 요소에 전달할 수 있습니다. `GOGC` 및 `GOMAXPROCS` 와 같은 매우 구체적인 성능 튜닝 옵션을 전달하는 데 유용합니다. 이는 에지 디버그 또는 지원 시나리오에서만 유용하므로 FlowCollector 설명자의 일부로 공개적으로 노출해서는 안 됩니다.
`healthPort`	`integer`	`healthPort` 는 상태 점검 API를 노출하는 Pod의 수집기 HTTP 포트입니다.
`port`	`integer`	흐름 수집기(호스트 포트)의 포트입니다. 일부 값은 허용되지 않습니다. 1024보다 크고 4500, 4789 및 6081과 달라야 합니다.
`profilePort`	`integer`	`profilePort` 를 사용하면 이 포트를 수신하는 Go pprof 프로파일러를 설정할 수 있습니다.

10.1.54. .spec.processor.kafkaConsumerAutoscaler

설명: kafkaConsumerAutoscaler 는 Kafka 메시지를 사용하는 flowlogs-pipeline-transformer 에 대해 설정하는 수평 Pod 자동 스케일러의 사양입니다. 이 설정은 Kafka가 비활성화되면 무시됩니다. HorizontalPodAutoscaler 문서(autoscaling/v2)를 참조하십시오.
유형: object

10.1.55. .spec.processor.metrics

설명: 메트릭 은 메트릭과 관련된 프로세서 구성을 정의합니다.
유형: object

속성	유형	설명
`disableAlerts`	`배열(문자열)`	`disableAlerts` 는 비활성화해야 하는 경고 목록입니다. 가능한 값은 다음과 같습니다. `NetObservNoFlows` 에서는 특정 기간 동안 흐름이 관찰되지 않을 때 트리거됩니다. `NetObservLokiError`: Loki 오류로 인해 흐름을 삭제할 때 트리거됩니다.
`includeList`	`배열(문자열)`	`includeList` 는 생성할 메트릭 이름 목록입니다. 이름은 접두사 없이 Prometheus의 이름에 해당합니다. 예를 들어 `namespace_egress_packets_total` 은 Prometheus에 `netobserv_namespace_egress_packets_total` 으로 표시됩니다. 더 많은 메트릭을 추가하면 Prometheus 워크로드 리소스에 더 큰 영향을 미칩니다. 기본적으로 활성화된 메트릭은 `namespace_flows_total`,`node_ingress_bytes_total`,`workload_ingress_bytes_total`,`namespace_drop_packets_total` ( `PacketDrop` 기능이 활성화된 경우), `namespace_rtt_seconds` ( `FlowRTT` 기능이 활성화된 경우), `namespace_dns_latency_seconds` ( `DNSTracking` 기능이 활성화된 경우)입니다. 자세한 내용은 사용 가능한 메트릭 전체 목록으로 다음을 수행합니다. https://github.com/netobserv/network-observability-operator/blob/main/docs/Metrics.md
`server`	`object`	Prometheus 스크랩에 대한 메트릭 서버 끝점 구성

10.1.56. .spec.processor.metrics.server

설명: Prometheus 스크랩에 대한 메트릭 서버 끝점 구성
유형: object

속성	유형	설명
`port`	`integer`	prometheus HTTP 포트
`tls`	`object`	TLS 구성입니다.

10.1.57. .spec.processor.metrics.server.tls

설명: TLS 구성입니다.
유형: object

속성	유형	설명
`insecureSkipVerify`	`boolean`	`insecureSkipVerify` 를 사용하면 제공된 인증서의 클라이언트 측 확인을 건너뛸 수 있습니다. `true` 로 설정하면 `providedCaFile` 필드가 무시됩니다.
`제공됨`	`object`	`type` 이 `Provided` 로 설정된 경우 TLS 구성입니다.
`providedCaFile`	`object`	`type` 이 `Provided` 로 설정된 경우 CA 파일에 대한 참조입니다.
`type`	`string`	끝점에 대해 TLS를 구성하지 않도록 TLS 구성 유형 - `Disabled` (기본값)를 선택합니다. - 인증서 파일과 키 파일을 수동으로 제공하도록 `제공됩니다`. - 자동으로 주석을 사용하여 OpenShift Container Platform 자동 생성 인증서를 사용합니다.

10.1.58. .spec.processor.metrics.server.tls.provided

설명: type 이 Provided 로 설정된 경우 TLS 구성입니다.
유형: object

속성	유형	설명
`certFile`	`string`	`cert` file은 구성 맵 또는 시크릿 내의 인증서 파일 이름의 경로를 정의합니다.
`certKey`	`string`	`certKey` 는 구성 맵 또는 시크릿 내의 인증서 개인 키 파일 이름의 경로를 정의합니다. 키가 필요하지 않은 경우 생략합니다.
`name`	`string`	인증서가 포함된 구성 맵 또는 시크릿의 이름
`네임스페이스`	`string`	인증서가 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.
`type`	`string`	인증서 참조에 대한 유형: `configmap` 또는 `secret`

10.1.59. .spec.processor.metrics.server.tls.providedCaFile

설명: type 이 Provided 로 설정된 경우 CA 파일에 대한 참조입니다.
유형: object

속성	유형	설명
`file`	`string`	구성 맵 또는 시크릿 내의 파일 이름
`name`	`string`	파일이 포함된 구성 맵 또는 시크릿의 이름
`네임스페이스`	`string`	파일이 포함된 구성 맵 또는 시크릿의 네임스페이스입니다. 생략하면 기본값은 Network Observability가 배포된 동일한 네임스페이스를 사용하는 것입니다. 네임스페이스가 다르면 필요에 따라 마운트할 수 있도록 구성 맵 또는 시크릿이 복사됩니다.
`type`	`string`	파일 참조에 대해 "configmap" 또는 "secret"을 입력합니다.

10.1.60. .spec.processor.resources

설명: 리소스는 이 컨테이너에 필요한 컴퓨팅 리소스입니다. 자세한 내용은 https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
유형: object

속성	유형	설명
`limits`	`integer-or-string`	제한은 허용되는 최대 컴퓨팅 리소스 양을 나타냅니다. 자세한 내용은 https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
`requests`	`integer-or-string`	요청은 필요한 최소 컴퓨팅 리소스 양을 설명합니다. 컨테이너에 대한 Requests를 생략하면 구현 정의된 값을 제외하고 명시적으로 지정된 경우 기본값은 Limits로 설정됩니다. 요청은 제한을 초과할 수 없습니다. 자세한 내용은 https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

11장. 네트워크 흐름 형식 참조

이는 내부 및 Kafka로 흐름을 내보낼 때 네트워크 흐름 형식의 사양입니다.

11.1. 네트워크 흐름 형식 참조

이는 네트워크 흐름 형식의 사양입니다. 해당 형식은 Prometheus 지표 라벨뿐만 아니라 Loki 저장소의 내부적으로는 Kafka 내보내기가 구성된 경우 사용됩니다.

"Filter ID" 열에는 빠른 필터를 정의할 때 사용할 관련 이름이 표시됩니다( FlowCollector 사양의 spec.consolePlugin.quickFilters 참조).

"Loki 레이블" 열은 Loki를 직접 쿼리할 때 유용합니다. 레이블 필드는 스트림 선택기 를 사용하여 선택해야 합니다.

이름	유형	설명	필터 ID	Loki 레이블
`바이트`	number	바이트 수	해당 없음	제공되지 않음
`DnsErrno`	number	DNS 추적기 ebpf 후크 함수에서 반환된 오류 번호	`dns_errno`	제공되지 않음
`DnsFlags`	number	DNS 레코드의 DNS 플래그	해당 없음	제공되지 않음
`DnsFlagsResponseCode`	string	구문 분석된 DNS 헤더 RCODEs 이름	`dns_flag_response_code`	제공되지 않음
`DnsId`	number	DNS 레코드 ID	`dns_id`	제공되지 않음
`DnsLatencyMs`	number	DNS 요청과 응답 사이의 시간(밀리초)	`dns_latency`	제공되지 않음
`Dscp`	number	고유 서비스 코드 포인트 (DSCP) 값	`dscp`	제공되지 않음
`DstAddr`	string	대상 IP 주소(ipv4 또는 ipv6)	`dst_address`	제공되지 않음
`DstK8S_HostIP`	string	대상 노드 IP	`dst_host_address`	제공되지 않음
`DstK8S_HostName`	string	대상 노드 이름	`dst_host_name`	제공되지 않음
`DstK8S_Name`	string	Pod 이름, 서비스 이름 또는 노드 이름과 같은 대상 Kubernetes 오브젝트의 이름입니다.	`dst_name`	제공되지 않음
`DstK8S_Namespace`	string	대상 네임스페이스	`dst_namespace`	제공됨
`DstK8S_OwnerName`	string	배포 이름, StatefulSet 이름 등과 같은 대상 소유자의 이름입니다.	`dst_owner_name`	제공됨
`DstK8S_OwnerType`	string	Deployment, StatefulSet 등과 같은 대상 소유자의 종류입니다.	`dst_kind`	제공되지 않음
`DstK8S_Type`	string	Pod, 서비스 또는 노드와 같은 대상 Kubernetes 오브젝트의 종류입니다.	`dst_kind`	제공됨
`DstK8S_Zone`	string	대상 가용성 영역	`dst_zone`	제공됨
`DstMac`	string	대상 MAC 주소	`dst_mac`	제공되지 않음
`DstPort`	number	대상 포트	`dst_port`	제공되지 않음
`중복`	boolean	이 흐름이 동일한 호스트의 다른 인터페이스에서도 캡처되었는지 여부를 나타냅니다.	해당 없음	제공됨
`플래그`	number	RFC-9293에 따라 흐름으로 구성된 고유한 TCP 플래그의 논리 OR 조합과 다음 각팩트 조합을 나타내는 추가 사용자 지정 플래그: - SYN+ACK (0x100) - FIN+ACK (0x200) - RST+ACK (0x400)	해당 없음	제공되지 않음
`FlowDirection`	number	노드 관찰 지점의 흐름 방향입니다. - 0: Ingress(노드 관찰 시점에서 들어오는 트래픽) - 1: Egress(노드 관찰 지점의 트래픽 제외) - 2단계(동일 소스 및 대상 노드가 있음) 중 하나일 수 있습니다.	`방향`	제공됨
`IcmpCode`	number	ICMP 코드	`icmp_code`	제공되지 않음
`IcmpType`	number	ICMP 유형	`icmp_type`	제공되지 않음
`IfDirection`	number	네트워크 인터페이스 관찰 지점의 흐름 방향입니다. - 0: Ingress(interface incoming traffic) - 1: Egress(interface outgoing traffic) 중 하나일 수 있습니다.	해당 없음	제공되지 않음
`인터페이스`	string	네트워크 인터페이스	`인터페이스`	제공되지 않음
`K8S_ClusterName`	string	클러스터 이름 또는 식별자	`cluster_name`	제공됨
`K8S_FlowLayer`	string	흐름 계층: 'app' 또는 'infra'	`flow_layer`	제공되지 않음
`패킷`	number	패킷 수	해당 없음	제공되지 않음
`PktDropBytes`	number	커널에 의해 삭제된 바이트 수	해당 없음	제공되지 않음
`PktDropLatestDropCause`	string	최신 드롭 원인	`pkt_drop_cause`	제공되지 않음
`PktDropLatestFlags`	number	마지막으로 삭제된 패킷의 TCP 플래그	해당 없음	제공되지 않음
`PktDropLatestState`	string	마지막으로 삭제된 패킷의 TCP 상태	`pkt_drop_state`	제공되지 않음
`PktDropPackets`	number	커널에 의해 삭제된 패킷 수	해당 없음	제공되지 않음
`proto`	number	L4 프로토콜	`프로토콜`	제공되지 않음
`SrcAddr`	string	소스 IP 주소(ipv4 또는 ipv6)	`src_address`	제공되지 않음
`SrcK8S_HostIP`	string	소스 노드 IP	`src_host_address`	제공되지 않음
`SrcK8S_HostName`	string	소스 노드 이름	`src_host_name`	제공되지 않음
`SrcK8S_Name`	string	Pod 이름, 서비스 이름 또는 노드 이름과 같은 소스 Kubernetes 오브젝트의 이름입니다.	`src_name`	제공되지 않음
`SrcK8S_Namespace`	string	소스 네임스페이스	`src_namespace`	제공됨
`SrcK8S_OwnerName`	string	배포 이름, StatefulSet 이름 등과 같은 소스 소유자의 이름입니다.	`src_owner_name`	제공됨
`SrcK8S_OwnerType`	string	Deployment, StatefulSet 등과 같은 소스 소유자의 종류입니다.	`src_kind`	제공되지 않음
`SrcK8S_Type`	string	Pod, 서비스 또는 노드와 같은 소스 Kubernetes 오브젝트의 종류입니다.	`src_kind`	제공됨
`SrcK8S_Zone`	string	소스 가용성 영역	`src_zone`	제공됨
`SrcMac`	string	소스 MAC 주소	`src_mac`	제공되지 않음
`SrcPort`	number	소스 포트	`src_port`	제공되지 않음
`TimeFlowEndMs`	number	이 흐름의 종료 타임스탬프(밀리초)	해당 없음	제공되지 않음
`TimeFlowRttNs`	number	TCP Smoothed Round Trip Time (SRTT), 나노초	`time_flow_rtt`	제공되지 않음
`TimeFlowStartMs`	number	이 흐름의 타임스탬프 시작(밀리초)	해당 없음	제공되지 않음
`TimeReceived`	number	흐름 수집기에서 이 흐름을 수신하고 처리하는 타임스탬프(초)	해당 없음	제공되지 않음
`_HashId`	string	대화 추적에서 대화 식별자	`id`	제공되지 않음
`_RecordType`	string	레코드 유형: 일반 흐름 로그의 경우 'flowLog' 또는 'newConnection', 'heartbeat', 'endConnection' for conversation 추적	`type`	제공됨

12장. 네트워크 Observability 문제 해결

네트워크 Observability 문제 해결을 지원하기 위해 일부 문제 해결 작업을 수행할 수 있습니다.

12.1. must-gather 툴 사용

must-gather 툴을 사용하여 Network Observability Operator 리소스 및 Pod 로그, FlowCollector, Webhook 구성과 같은 클러스터 전체 리소스에 대한 정보를 수집할 수 있습니다.

프로세스

must-gather 데이터를 저장하려는 디렉터리로 이동합니다.

다음 명령을 실행하여 클러스터 전체 must-gather 리소스를 수집합니다.

$ oc adm must-gather
 --image-stream=openshift/must-gather \
 --image=quay.io/netobserv/must-gather

12.2. OpenShift Container Platform 콘솔에서 네트워크 트래픽 메뉴 항목 구성

OpenShift Container Platform 콘솔의 Observe 메뉴에 네트워크 트래픽 메뉴 항목이 나열되지 않은 경우 OpenShift Container Platform 콘솔에서 네트워크 트래픽 메뉴 항목을 수동으로 구성합니다.

사전 요구 사항

OpenShift Container Platform 버전 4.10 이상이 설치되어 있어야 합니다.

프로세스

다음 명령을 실행하여 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

선택 사항: Console Operator 구성을 수동으로 편집하여 netobserv-plugin 플러그인을 추가합니다.
```
$ oc edit console.operator.openshift.io cluster
```
출력 예
```
...
spec:
  plugins:
  - netobserv-plugin
...
```

선택 사항: 다음 명령을 실행하여 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

다음 명령을 실행하여 콘솔 Pod의 상태가 실행 중인지 확인합니다.
```
$ oc get pods -n openshift-console -l app=console
```
다음 명령을 실행하여 콘솔 Pod를 다시 시작합니다.
```
$ oc delete pods -n openshift-console -l app=console
```
브라우저 캐시 및 기록을 지웁니다.

다음 명령을 실행하여 Network Observability 플러그인 Pod의 상태를 확인합니다.

$ oc get pods -n netobserv -l app=netobserv-plugin

출력 예

NAME                                READY   STATUS    RESTARTS   AGE
netobserv-plugin-68c7bbb9bb-b69q6   1/1     Running   0          21s

다음 명령을 실행하여 Network Observability 플러그인 Pod의 로그를 확인합니다.

$ oc logs -n netobserv -l app=netobserv-plugin

출력 예

time="2022-12-13T12:06:49Z" level=info msg="Starting netobserv-console-plugin [build version: , build date: 2022-10-21 15:15] at log level info" module=main
time="2022-12-13T12:06:49Z" level=info msg="listening on https://:9001" module=server

12.3. FlowLogs-Pipeline은 Kafka를 설치한 후 네트워크 흐름을 사용하지 않습니다.

deploymentModel: KAFKA 를 사용하여 흐름 수집기를 먼저 배포한 다음 Kafka를 배포한 경우 흐름 수집기가 Kafka에 올바르게 연결되지 않을 수 있습니다. Flowlogs-pipeline이 Kafka의 네트워크 흐름을 사용하지 않는 flow-pipeline Pod를 수동으로 다시 시작합니다.

프로세스

다음 명령을 실행하여 flow-pipeline 포드를 삭제하여 다시 시작합니다.
```
$ oc delete pods -n netobserv -l app=flowlogs-pipeline-transformer
```

12.4. `br-int` 및 `br-ex` 인터페이스 모두에서 네트워크 흐름을 볼 수 없음

br-ex' 및 br-int 는 OSI 계층 2에서 작동하는 가상 브릿지 장치입니다. eBPF 에이전트는 IP 및 TCP 수준, 계층 3 및 4에서 각각 작동합니다. eBPF 에이전트는 네트워크 트래픽이 물리적 호스트 또는 가상 pod 인터페이스와 같은 다른 인터페이스에서 처리할 때 br-ex 및 br-int 를 통과하는 네트워크 트래픽을 캡처할 수 있습니다. eBPF 에이전트 네트워크 인터페이스를 br-ex 및 br-int 에만 연결하도록 제한하면 네트워크 흐름이 표시되지 않습니다.

인터페이스의 부분을 수동으로 제거하거나 네트워크 인터페이스를 br-int 및 br-ex 로 제한하는 Interfaces를 제외합니다.

프로세스

인터페이스 제거: ['br-int', 'br-ex' ] 필드. 이를 통해 에이전트는 모든 인터페이스에서 정보를 가져올 수 있습니다. 또는 Layer-3 인터페이스를 지정할 수 있습니다(예: eth0 ). 다음 명령을 실행합니다.
```
$ oc edit -n netobserv flowcollector.yaml -o yaml
```
출력 예
```
apiVersion: flows.netobserv.io/v1alpha1
kind: FlowCollector
metadata:
  name: cluster
spec:
  agent:
    type: EBPF
    ebpf:
      interfaces: [ 'br-int', 'br-ex' ] 1
```
1
네트워크 인터페이스를 지정합니다.

12.5. Network Observability 컨트롤러 관리자 Pod가 메모리 부족

Subscription 오브젝트에서 spec.config.resources.limits.memory 사양을 편집하여 Network Observability Operator의 메모리 제한을 늘릴 수 있습니다.

프로세스

웹 콘솔에서 Operator → 설치된 Operator로 이동합니다.
네트워크 관찰 기능을 클릭한 다음 서브스크립션 을 선택합니다.
작업 메뉴에서 서브스크립션 편집을 클릭합니다.
1. 또는 CLI를 사용하여 다음 명령을 실행하여 Subscription 오브젝트에 대한 YAML 구성을 열 수 있습니다.
```
$ oc edit subscription netobserv-operator -n openshift-netobserv-operator
```

Subscription 오브젝트를 편집하여 config.resources.limits.memory 사양을 추가하고 메모리 요구 사항을 고려하여 값을 설정합니다. 리소스 고려 사항에 대한 자세한 내용은 추가 리소스를 참조하십시오.

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: netobserv-operator
  namespace: openshift-netobserv-operator
spec:
  channel: stable
  config:
    resources:
      limits:
        memory: 800Mi     1
      requests:
        cpu: 100m
        memory: 100Mi
  installPlanApproval: Automatic
  name: netobserv-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  startingCSV: <network_observability_operator_latest_version> 2

1: 예를 들어 메모리 제한을 800Mi 로 늘릴 수 있습니다.
2: 이 값은 편집해서는 안 되지만 Operator의 최신 릴리스에 따라 변경됩니다.

추가 리소스

리소스 고려 사항

12.6. Loki ResourceExhausted 오류 문제 해결

네트워크 Observability에서 보낸 네트워크 흐름 데이터가 구성된 최대 메시지 크기를 초과하면 Loki가 ResourceExhausted 오류를 반환할 수 있습니다. Red Hat Loki Operator를 사용하는 경우 이 최대 메시지 크기는 100MiB로 구성됩니다.

프로세스

Operator → 설치된 Operator 로 이동하여 프로젝트 드롭다운 메뉴에서 모든 프로젝트를 확인합니다.
제공된 API 목록에서 Network Observability Operator를 선택합니다.
흐름 수집기 를 클릭한 다음 YAML 보기 탭을 클릭합니다.
1. Loki Operator를 사용하는 경우 spec.loki.batchSize 값이 98MiB를 초과하지 않는지 확인합니다.
2. Grafana Loki와 같은 Red Hat Loki Operator와 다른 Loki 설치 방법을 사용하는 경우 grpc_server_max_recv_msg_size Loki 서버 설정이 FlowCollector 리소스 spec.loki.batchSize 값보다 높은지 확인합니다. 그렇지 않은 경우 grpc_server_max_recv_msg_size 값을 늘리거나 제한보다 낮도록 spec.loki.batchSize 값을 줄여야 합니다.
FlowCollector 를 편집한 경우 저장을 클릭합니다.

12.7. Loki 빈 링 오류

Loki "빈 링" 오류로 인해 flows가 Loki에 저장되지 않고 웹 콘솔에 표시되지 않습니다. 이 오류는 다양한 상황에서 발생할 수 있습니다. 이를 모두 해결하기 위한 단일 해결 방법이 존재하지 않습니다. Loki Pod에서 로그를 조사하고 LokiStack 이 정상이고 준비되었는지 확인하는 데 수행할 수 있는 몇 가지 작업이 있습니다.

이 오류가 관찰되는 몇 가지 상황은 다음과 같습니다.

LokiStack 을 제거하고 동일한 네임스페이스에 다시 설치한 후 이전 PVC가 제거되지 않으므로 이 오류가 발생할 수 있습니다.
- 작업: LokiStack 을 다시 제거하여 PVC를 제거한 다음 LokiStack 을 다시 설치할 수 있습니다.
인증서 교체 후 이 오류는 flowlogs-pipeline 및 console-plugin Pod와의 통신을 방지할 수 있습니다.
- 작업: Pod를 다시 시작하여 연결을 복원할 수 있습니다.

12.8. 리소스 문제 해결

12.9. LokiStack 속도 제한 오류

Loki 테넌트에 배치된 속도 제한은 스트림 제한 초과(limit:xMB/sec)를 수집하는 동안 데이터 및 429 오류가 발생할 수 있습니다. 이 오류를 알리기 위해 경고를 설정하는 것이 좋습니다. 자세한 내용은 이 섹션의 추가 리소스의 "NetObserv 대시보드에 대한 Loki 속도 제한 경고 생성"을 참조하십시오.

다음 절차에 표시된 대로 perStreamRateLimit 및 perStreamRateLimitBurst 사양을 사용하여 LokiStack CRD를 업데이트할 수 있습니다.

프로세스

Operator → 설치된 Operator 로 이동하여 프로젝트 드롭다운에서 모든 프로젝트를 확인합니다.
Loki Operator 를 찾고 LokiStack 탭을 선택합니다.

YAML 보기를 사용하여 기존 LokiStack 인스턴스를 생성하거나 편집하여 perStreamRateLimit 및 perStreamRateLimitBurst 사양을 추가합니다.

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 입니다.

저장을 클릭합니다.

검증

perStreamRateLimit 및 perStreamRateLimitBurst 사양을 업데이트하면 클러스터 재시작의 pod가 429 rate-limit 오류가 더 이상 발생하지 않습니다.

Legal Notice

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.