이쿠의 슬기로운 개발생활

Calico 리서치

이쿠우우 — Mon, 12 Jan 2026 21:47:55 +0900

목표

Calico에 대해 알아봄.

Calico 란?

Calico는 Container, VM 환경에서 L3기반 Virtual Network를 구축하게 도와주는 Networking Providers.

kubernetes에서 사용 가능한 CNI (Container Network Interface)로 Flannel과 더불어서 대표적으로 사용되고 있는 CNI.

Calico는 Kubernetes 이외에도 OpenShift, Mirantis Kubernetes Engine(MKE), OpenStack, Docker Shim등 다양한 플랫폼에서 사용 가능.

CNI란?

CNI : Container Network Interface

컨테이너 간의 네트워킹을 제어할 수 있는 플러그인을 만들기 위한 표준.

Kubernetes Cluster 내부는 Master Node 에 의해 여러 컨테이너가 생성 삭제 복구를 반복하고 있음

그에 따라 각 컨테이너의 고정적이지 않고 재할당이 빈번함.

이러한 특징을 해결하기 위해 Kubernetes Cluster는 가상 네트워크가 구성되어 있는데

기본적으로는 Worker Node 의 kube-proxy 가 네트워크를 관리하지만

보다 효율적인 네트워크 환경을 구성하기 위해

다양한 네트워크 관련 Addon 이 제공됨

종류)

Flannel, Calico, Canal, Cilium, CNI-Genie, Contiv, Multus, NSX-T, Nuage, Romana, Weave Net

Flannel과 Calico의 차이점

[Network Policy]

Flannel : 지원하지 않음

Calico : 지원

[Networking mode]

Flannel : VXLAN

Calico : IP-in-IP, VXLAN, Direct

[IPAM]

Flannel : HOST의 IPAM 사용함.

Calico : Calico 전용 IPAM을 별도로 사용함.

Calico Components

Calico-node

Daemonset으로 배포되어 모든 node에서 동작하고 있음.

Calico CNI 동작의 핵심 역할을 수행하는 container가 모두 calico-node에 포함되어있음.

Calico-node : Felix

Calico의 핵심 에이전트(Brain) 역할을 수행하며, 실제 패킷을 처리하기 위해 호스트의 커널을 조작하는 담당자.

Interface 관리: Pod가 생성되면 호스트와 연결되는 가상 인터페이스(cali***)를 생성하고 관리합니다.
Route Table 관리 (Local): 내 노드에 떠 있는 Pod로 가는 경로(Local Route)를 호스트 라우팅 테이블에 설정합니다.
Network Policy (ACL) 관리: K8s NetworkPolicy 리소스를 감지하여 방화벽 룰(iptables 등)을 설정합니다.
상태 보고: 노드의 헬스 체크 및 상태 정보를 Datastore에 보고합니다. (etcd)
- Datastore mode가 etcd인 경우 : etcd에 다이렉트로 상태보고함.
- Datastore mode가 Kubernetes API (KDD) 인 경우 : kube-apiserver 에 상태보고함 calicoNode라는 Custom Resource(CR)의 Status 필드를 업데이트

[Felix vs BIRD : 라우팅 역할 분담]

Routing Table을 작성하는 작업은 두 프로세스가 역할을 나누어 수행합니다.

BIRD: 다른 노드(Peer)로부터 받은 원격지 Pod 대역의 경로를 호스트 라우팅 테이블에 입력합니다.
- (예: "Node B로 가려면 eth0으로 가라")
Felix: 자기 노드에 생성된 Pod의 경로를 호스트 라우팅 테이블에 입력합니다.
- (예: "Pod A로 가려면 cali123 인터페이스로 가라")

[kube-proxy와 Felix의 관계 & eBPF 모드]

일반 모드 (Standard Linux Networking):
- kube-proxy: Service(ClusterIP) 연결 및 부하분산 담당 (iptables 또는 IPVS 사용).
- Felix: Pod 통신 보안(Network Policy) 담당.
- 결론: 둘 다 실행되어야 함.
eBPF 모드 (Calico의 고성능 모드):
- Felix가 eBPF 프로그램을 이용해 Network Policy뿐만 아니라 Service 부하분산까지 모두 처리함.
- 결론: 이 경우에만 kube-proxy를 비활성화(대체)할 수 있음.

Calico-node : BIRD

CALICO_NETWORKING_BACKEND 설정이 bird 일 때만 실행되는 BGP 데몬.

(vxlan 모드나 none 모드에서는 실행되지 않음.)

모든 노드에 배포되어 실행되며, 노드 간에 BGP Peering을 맺음.

내 노드에 있는 Pod들의 IP 정보를 다른 노드(Peer)들에게 전파하는 역할을 담당.

이를 통해 각 노드는 클러스터 전체의 Pod 경로(Route)를 학습하게 됨.

기본적으로 bird 백엔드 모드에서는 IP-in-IP, VXLAN 캡슐화를 모두 지원하지만, 라우팅 정보 교환 자체는 BGP(BIRD)가 담당함.

참고 (Backend=vxlan 인 경우):

이 모드에서는 BIRD가 배포되지 않으며, BGP 대신 Felix가 Datastore 정보를 기반으로 라우팅을 직접 처리함.

BGP Peering 모드 (Topology)

BIRD가 노드끼리 통신하는 방식은 크게 두 가지로 나뉘며, 클러스터 규모에 따라 선택해야 함.

BGPConfiguration 리소스의 nodeToNodeMeshEnabled 값으로 설정 가능

Node-to-Node Mesh (Default):
- nodeToNodeMeshEnabled : true
- 모든 노드가 서로 1:1로 연결됨 (Full Mesh).
- 모든 노드가 서로 1:1로 연결되므로, 노드 수가 N개일 때 연결 수는 N(N-1)/2* 개가 됨.
- 설정이 간편하나 노드 수가 많아지면 부하가 급증함.
- 단점 : 노드가 100개면 약 5,000개의 연결이 필요하지만, 노드가 1,000개가 되면 약 50만 개의 연결이 필요해져 네트워크 부하가 급증함.
Route Reflector (RR):
- nodeToNodeMeshEnabled : false
- 특정 노드(RR)를 통해서만 라우팅 정보를 교환하는 중앙 집중형 구조.
- 비유: 교실(Cluster)에서 모든 학생(Node)이 서로 떠드는 것(Full Mesh) 대신, 반장(RR)에게만 이야기하고 반장이 이를 전체에게 전달하는 방식.
- 이를 통해 연결 복잡도를 획기적으로 줄여 대규모 클러스터에서도 안정적인 통신이 가능함.
- 대규모 클러스터(Node 100개 이상)에서 필수적임.

[BIRD 프로세스 동작 확인]

ps -ef | grep bird

[peering node 목록 확인 : calicoctl 사용]

calicoctl node status

[BGP 란?]

Border Gateway Protocol의 약자로
서로 다른 AS(Autonomous System) 즉
서로 다른 Router를 연결해주는 Protocol로 Packet을 어느 Router로 Routing할지 결정해줌.
따라서 각 Router는 자신이 전달할 수 있는 IP List를 알고 있어야 함.

[Calico에서의 역할]
Calico는 각 노드를 가상의 BGP 라우터로 취급함.
각 노드는 자신이 관리하는 Pod CIDR(IP 대역) 정보를 "내 쪽으로 보내라"고 다른 노드들에게 전파함.
- iBGP (Internal BGP): 같은 클러스터 내부의 노드끼리 통신할 때 사용 (기본 AS 번호: 64512).
- eBGP (External BGP): 클러스터 외부의 물리 라우터(ToR 스위치 등)와 통신할 때 사용.

Calico-node : Confd

calico-node 컨테이너 내부에서 동작하는 경량 설정 관리 도구.

전통적인 라우팅 데몬인 BIRD는 본래 정적인 설정 파일(bird.cfg)을 읽어 동작하는데,

수시로 변하는 Kubernetes 환경(노드 추가/삭제, IP 대역 변경)에 대응할 수 있도록

동적으로 설정 파일을 생성하고 BIRD를 제어하는 역할을 수행함.

Confd는 아래와 같은 순환 구조로 BIRD를 최신 상태로 유지함.

Monitoring (감시): Calico Datastore(etcd 또는 K8s API)의 특정 Key/Value 값들을 실시간으로 모니터링(Watch)함.
Rendering (생성): 감지된 변경 사항(새로운 노드 정보, BGP 설정 변경 등)을 반영하여 BIRD 설정 템플릿을 기반으로 새로운 설정 파일(bird.cfg)을 생성함.
Trigger (적용): 설정 파일이 변경되면, Confd가 BIRD 프로세스에 **"설정을 다시 읽으라(Reload)"**는 명령을 내려 라우팅 정보를 갱신함.

Confd가 Datastore에서 주시하는 정보는 BGP Peering에 필수적인 데이터들임.

Node Information: 클러스터 내 다른 노드들의 IP 및 AS 번호 (Peering 대상).
Pod CIDR: 각 노드에 할당된 Pod IP 대역 (전파해야 할 경로 정보).
BGP Configuration: 앞서 정리한 BGPConfiguration 리소스(Full Mesh 여부, RR 설정 등).

Calico Datastore

Calico가 클러스터 네트워킹을 구성하는 데 필요한 모든 설정과 상태 정보를 저장하는 중앙 저장소.

저장 데이터:

Configuration: IP Pool, BGP Configuration, Felix Configuration 등.
Policy: Network Policy, Global Network Policy (보안 규칙).
Inventory: Node 정보, Endpoint(Pod) 정보 등.

Datastore은 Kubernetes, etcd 2개의 mode 를 제공하고 있음.

multi cluster가 아닌 경우에는 일반적으로 Kubernetes mode로 사용하는 것을 추천함.

데이터 저장소를 사용할 수 없는 경우 Calico Network는 계속 작동하지만 업데이트할 수 없음.

저장소 모드

Kubernetes mode(KDD: Kubernetes Datastore Driver)
- default mode.
- 별도의 DB를 구축하지 않고, Kubernetes API Server를 통해 데이터를 저장하고 조회함.
- 데이터는 실제로 Kubernetes의 etcd에 저장되지만,
- Calico는 이를 CRD(Custom Resource Definition) 형태로 관리함.
etcd mode
- 레거시(Legacy) 또는 특수 목적용으로 사용됨. kubernetes가 아닌 플랫폼(ex: openstack)
- kubernetes와 Calico 리소스를 분리할 수 있음.
- Calico가 직접 etcd 클러스터에 접속하여 데이터를 읽고 씀.
- Multi-cluster에서 Calico 구성할 때 사용함.

특징	Kubernetes API (KDD)	etcd Mode
권장 환경	일반적인 Kubernetes 클러스터	OpenStack, Hybrid, 특수 대규모 환경
데이터 접근	kube-apiserver 경유 (CRD)	etcd 직접 접속 (/calico/...)
운영 복잡도	낮음 (추가 관리 요소 없음)	높음 (별도 etcd 관리 및 백업 필요)
보안(RBAC)	Kubernetes RBAC 사용 가능	별도 인증서/계정 관리 필요

Calico IPAM plugin

kubernentes cluster의 Pod에 IP 주소를 할당하고 회수하는 관리자.

Calico Datastore에 저장되어있는 IP-Pools정보를 기반으로 Pod ip 대역을 설정함.

Kubernetes는 직접 Pod에 IP 주소를 할당하고 관리하는 대신 IPAM 플러그인을 사용하도록 설계되어있음.

CNI Plugin인과 마찬가지로 다양한 IPAM Plugin이 존재하지만, 보통은 CNI Plugin과 같이 제공됨.

Calico 역시 자체 IPAM Plugin인 calico-ipam을 가지고 있음.

kubernetes cluster는 default로 Host Local IPAM이 동작함.(각 Node별로 pod의 CIDR을 할당함)

하지만, Calico에서는 Pod의 IP를 직접 관리하기 위해 별도의 IPAM이 할당됨.

(참고 : Flannel의 경우 별도의 IPAM이 없고 Host의 IPAM을 사용함.)

Calico IPAM의 핵심 특징: Block Affinity

기존 방식 (Host-Local / Flannel):
- 고정 할당: 노드가 생성될 때 미리 큰 대역(예: /24, IP 256개)을 뚝 떼어 노드에 줌. (spec.podCIDR)
- 문제점:
  - Pod가 5개밖에 없는 노드도 IP 256개를 점유하므로 IP 낭비가 심함.
  - 반대로 Pod가 너무 많은 노드는 IP가 모자라 Pod 생성이 실패할 수 있음
Calico 방식 (Calico IPAM):
- 동적 블록 할당: 노드에 큰 대역을 미리 주지 않고, 작은 블록(Block, 기본 /26, IP 64개) 단위로 필요할 때마다 할당.
- 유연성: A 노드에 Pod가 많아져서 할당받은 블록을 다 쓰면, 동적으로 새로운 블록을 추가로 받아옴.
- 효율성: Pod가 적은 노드는 IP를 적게 가져가므로, 클러스터 전체의 IP 자원을 효율적으로 쓸 수 있음.

[Calico IPAM 설정 확인]

/etc/cni/net.d/10-calico.conflist

[참고] IPAM이란?

정의: IP Address Management의 약자로, 네트워크 상의 IP 주소 할당, 추적, 관리를 자동화하는 솔루션.
K8s에서의 의미: CNI 프레임워크의 일부로서, 컨테이너에 중복되지 않는 고유한 IP를 발급해주는 역할을 수행하는 모듈.

kube-controllers (Calico-kube-controllers)

Kubernetes API Server를 모니터링(Watch)하여, 클러스터의 상태 변화를 Calico Datastore에 동기화하는 컨트롤러

첨부한 그림에서 보이는 것 같이 calico-kube-controllers는 kube-apiserver를 watch하고 있음.

Datastore 모드에 따른 역할 차이

Etcd Mode인 경우: (핵심 동기화 담당)

K8s의 NetworkPolicy, Service 등을 감지하여 Etcd에 Calico 전용 데이터 포맷으로 변환 및 저장함.
이 컨트롤러가 죽으면 새로운 정책(Policy)이 적용되지 않음.

Kubernetes(KDD) Mode인 경우: (리소스 정리 및 청소 담당)

Felix가 K8s CRD를 직접 읽으므로 정책 동기화 역할은 줄어듦.
하지만 Garbage Collection(GC) 역할을 수행하기 위해 반드시 필요함.
예시:
- kubectl delete node로 노드를 삭제했을 때, kube-controllers가 없으면
- Calico는 해당 노드에 할당된 IP Block과 IP 정보를 삭제하지 않고 영원히 점유(Leak)하게 됨.
즉, 클러스터의 리소스 효율성과 데이터 무결성을 위해 KDD 모드에서도 배포되어야 함.

calico-kube-controller 내부 controller 항목

policy controller: watches network policies and programs Calico policies.
namespace controller: watches namespaces and programs Calico profiles.
serviceaccount controller: watches service accounts and programs Calico profiles.
workloadendpoint controller: watches for changes to pod labels and updates Calico workload endpoints.
node controller: watches for the removal of Kubernetes nodes and removes corresponding data from Calico, and optionally watches for node updates to create and sync host endpoints for each node.

컨트롤러	역할
Node Controller	• K8s 노드 삭제 시, Calico 데이터(IP 할당 정보 등)를 함께 삭제(GC). • (Etcd 모드 시) K8s 노드 정보를 Calico 호스트 정보로 동기화.
Policy Controller	• (주로 Etcd 모드) K8s NetworkPolicy를 감지하여 Calico Policy로 변환/동기화.
Namespace Controller	• Namespace 생성/삭제를 감지하여 Calico Profile을 관리.
ServiceAccount Controller	• ServiceAccount 변경 사항을 Calico Profile에 동기화.
WorkloadEndpoint Controller	• Pod의 라벨(Label) 변경 등을 감지하여 Endpoint 정보를 갱신.

kube-controllers가 생성하는 etcd key/value

/calico/resources/v3/projectcalico.org/

하위에 calico가 동작하는데 필요한 cluster 정보를 저장함.

(kubernetes mode로 동작하고 kube-controllers 가 없는 calico는 해당 key가 존재하지 않음.)

Typha

Calico Datastore(K8s API/etcd)와 수백/수천 개의 Felix 인스턴스 사이의 상태 캐싱 프록시(State Caching Proxy) 역할을 담당함.

Typha가 없다면, 모든 노드의 Felix, confd가 각자 API 서버에 Watch 요청을 보냄.

노드가 100개 이상 늘어나면 API 서버의 부하가 급증하여 클러스터 전체 성능 저하 발생.

Typha를 도입하면, Typha가 대표로 한 번만 데이터를 받아와서 캐싱하고,

이를 다수의 Felix에게 뿌려주어(Fan-out) Datastore의 부하를 획기적으로 줄임.

즉 하나의 Typha 인스턴스가 수백 개의 Felix를 커버할 수 있음.

Typha 설정은 아래 링크를 참고.

https://projectcalico.docs.tigera.io/reference/typha/configuration

calicoctl

calico object를 CRUD 할 수 있음, 즉 calico datastore에 접근 가능한 calico test tool.

참고

[calico 개념]

https://projectcalico.docs.tigera.io/about/about-calico

https://projectcalico.docs.tigera.io/reference/architecture/overview

https://joshrosso.com/docs/2020/2020-10-01-calico-routing-modes/

https://www.youtube.com/watch?v=MpbIZ1SmEkU

https://leebriggs.co.uk/blog/2017/02/18/kubernetes-networking-calico

https://medium.com/@BalajiSA/k8s-networking-and-calico-cni-plugin-7ebf84bf7fec

https://github.com/kubernetes-sigs/kubespray/blob/master/docs/calico.md

[잘 정리되어있음]

https://tanzu.vmware.com/developer/guides/container-networking-calico-refarch/

[calico kube controller]

https://projectcalico.docs.tigera.io/reference/kube-controllers/

[calico typha]

https://projectcalico.docs.tigera.io/reference/typha/

[calico cni plugin]

https://projectcalico.docs.tigera.io/getting-started/kubernetes/hardway/install-cni-plugin

[calico datastore]

https://projectcalico.docs.tigera.io/getting-started/kubernetes/hardway/the-calico-datastore

[calico IPAM]

https://cwal.tistory.com/13

[calico routing mode]

https://joshrosso.com/c/calico-routing-modes/

IP-in-IP : https://ssup2.github.io/theory_analysis/Kubernetes_Calico_Plugin/

3가지 mode : https://coffeewhale.com/calico-mode

https://eddie.ee/186

https://tech.hostway.co.kr/2022/04/22/675/?print=print

[calico 한글 자료]

https://ssup2.github.io/theory_analysis/Kubernetes_Calico_Plugin/

https://velog.io/@200ok/Kubernetes-Calico-CNI-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0

https://coffeewhale.com/packet-network2#bird-bgp

https://coffeewhale.com/calico-mode

https://lahuman.github.io/kang_3week_1/

https://velog.io/@200ok/Kubernetes-Calico-CNI-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0

[ipip mode에서 vxlan mode 변경]

https://tech.hostway.co.kr/2022/04/29/851/

kubernetes 모니터링 : Node Problem Detector(NPD)란?

이쿠우우 — Sun, 22 Sep 2024 21:25:20 +0900

Node Problem Detector

Node Problem Detector(NPD) 란?

Node Problem Detector는 노드의 상태를 모니터링하고

하드웨어, 커널, 컨테이너 런타임 문제와 같은 일반적인 노드 문제를 감지하는 오픈소스 라이브러리.

일반적으로 Kubernetes에 Daemonset으로 배포되어 동작함.

수집하는 metrics 계층

= system metrics

host에서 발생한 "에러 정보"를 전달함

수집하는 metrics 정보 확인 링크

NPD는 config에 지정되어있는 설정에 따라 수집하는 지표 정보가 매우 유동적임

NPD 설정 확인

--system-log-monitors=

https://github.com/kubernetes/node-problem-detector/tree/master/pkg/systemlogmonitor#metrics-reporting

/config/kernel-monitor.json
- https://github.com/kubernetes/node-problem-detector/blob/master/config/kernel-monitor.json
/config/kernel-monitor-filelog.json
- https://github.com/kubernetes/node-problem-detector/blob/master/config/kernel-monitor-filelog.json
/config/docker-monitor.json
- https://github.com/kubernetes/node-problem-detector/blob/master/config/docker-monitor.json
/config/docker-monitor-filelog.json
- https://github.com/kubernetes/node-problem-detector/blob/master/config/docker-monitor-filelog.json

--custom-plugin-monitors=

/config/network-problem-monitor.json
- https://github.com/kubernetes/node-problem-detector/blob/master/config/network-problem-monitor.json

--config.system-stats-monitor=

/config/system-stats-monitor.json
- https://github.com/kubernetes/node-problem-detector/blob/master/config/system-stats-monitor.json

problem 지표 정보 목록은 아래와 같음

problem_counter{reason="AUFSUmountHung"} 0
problem_counter{reason="ConntrackFull"} 0
problem_counter{reason="DockerHung"} 0
problem_counter{reason="Ext4Error"} 0
problem_counter{reason="Ext4Warning"} 0
problem_counter{reason="FilesystemIsReadOnly"} 0
problem_counter{reason="IOError"} 0
problem_counter{reason="KernelOops"} 0
problem_counter{reason="MemoryReadError"} 0
problem_counter{reason="OOMKilling"} 0
problem_counter{reason="TaskHung"} 15
problem_counter{reason="UnregisterNetDevice"} 0
problem_gauge{reason="AUFSUmountHung",type="KernelDeadlock"} 0
problem_gauge{reason="DockerHung",type="KernelDeadlock"} 0
problem_gauge{reason="FilesystemIsReadOnly",type="ReadonlyFilesystem"} 0

전체 항목 설명

cpu_load_15m CPU average load (15m)
cpu_load_1m CPU average load (1m)
cpu_load_5m CPU average load (5m)
cpu_runnable_task_count The average number of runnable tasks in the run-queue during the last minute
cpu_usage_time CPU usage, in seconds
disk_avg_queue_len The average queue length on the disk
disk_bytes_used Disk bytes used, in Bytes
disk_io_time The IO time spent on the disk, in ms
disk_merged_operation_count Disk merged operations count
disk_operation_bytes_count Bytes transferred in disk operations
disk_operation_count Disk operations count
disk_operation_time Time spent in disk operations, in ms
disk_weighted_io The weighted IO on the disk, in ms
host_uptime The uptime of the operating system
memory_anonymous_used Anonymous memory usage, in Bytes. Summing values of all states yields the total anonymous memory used.
memory_bytes_used Memory usage by each memory state, in Bytes. Summing values of all states yields the total memory on the node.
memory_dirty_used Dirty pages usage, in Bytes. Dirty means the memory is waiting to be written back to disk, and writeback means the memory is actively being written back to disk.
memory_page_cache_used Page cache memory usage, in Bytes. Summing values of all states yields the total anonymous memory used.
memory_unevictable_used Unevictable memory usage, in Bytes
problem_counter Number of times a specific type of problem have occurred.
problem_gauge Whether a specific type of problem is affecting the node or not.
system_cpu_stat Cumulative time each cpu spent in various stages.
system_interrupts_total Total number of interrupts serviced (cumulative).
system_os_feature OS Features like GPU support, KTD kernel, third party modules as unknown modules. 1 if the feature is enabled and 0, if disabled.
system_processes_total Number of forks since boot.
system_procs_blocked Number of processes currently blocked.
system_procs_running Number of processes currently running.

어떤 에러 정보를 수집하는지에 대한 정보가 있음.

https://github.com/kubernetes/node-problem-detector#problem-daemon

problem_gauge, problem_counter 차이

problem_gauge = 영구적인 문제
problem_counter = 일시적인 문제

참고 : https://github.com/kubernetes/node-problem-detector/tree/master/pkg/systemlogmonitor#metrics-reporting

problem_gauge의 카운트는

problem_counter항목의 condition에 명시되어있는 것과 매칭되면 증가함.

즉 problem_counter와 problem_gauge가 동시에 증가함.

수집한 metrics 정보를 전달하는 방식

= Pull 방식

npd는 HTTP 통신을 통해 Prometheus Server와 같은 metrics server가 process-exporter가 수집한 Metric Data를 가져갈 수 있게

/metrics 라는 HTTP 엔드포인트를 제공함.

exporter가 해당 엔드포인트를 제공하고 있어서 Server가 exporter의 엔드포인트로 HTTP GET 요청을 날려 Metric Data를 Pull방식으로 수집함.

default port

20257

Node Problem Detector 배포 방법

실행

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: node-problem-detector
  namespace: kube-system
  labels:
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: magnum:podsecuritypolicy:node-problem-detector
  namespace: kube-system
  labels:
    addonmanager.kubernetes.io/mode: Reconcile
    kubernetes.io/cluster-service: "true"
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: magnum:podsecuritypolicy:privileged
subjects:
- kind: ServiceAccount
  name: node-problem-detector
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: npd-binding
  labels:
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:node-problem-detector
subjects:
- kind: ServiceAccount
  name: node-problem-detector
  namespace: kube-system
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: npd
  namespace: kube-system
  labels:
    k8s-app: node-problem-detector
    version: ${NODE_PROBLEM_DETECTOR_TAG}
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile
spec:
  selector:
    matchLabels:
      k8s-app: node-problem-detector
      version: ${NODE_PROBLEM_DETECTOR_TAG}
  template:
    metadata:
      labels:
        k8s-app: node-problem-detector
        version: ${NODE_PROBLEM_DETECTOR_TAG}
        kubernetes.io/cluster-service: "true"
    spec:
      containers:
      - name: node-problem-detector
        ports:
        - containerPort: 20257
          hostPort: 20257
          protocol: TCP
        image: ${_gcr_prefix}${NPD_REPO}:${NODE_PROBLEM_DETECTOR_TAG}
        command:
        - "/bin/sh"
        - "-c"
        # Pass both config to support both journald and syslog.
        - "exec /node-problem-detector --logtostderr --system-log-monitors=/config/kernel-monitor.json,/config/kernel-monitor-filelog.json,/config/docker-monitor.json,/config/docker-monitor-filelog.json --logtostderr --enable-k8s-exporter=false --prometheus-address=0.0.0.0 --prometheus-port=20257 --custom-plugin-monitors=/config/network-problem-monitor.json --config.system-stats-monitor=/config/system-stats-monitor.json 2>&1 | tee /var/log/node-problem-detector.log"
        securityContext:
          privileged: true
        resources:
          limits:
            cpu: "200m"
            memory: "100Mi"
          requests:
            cpu: "20m"
            memory: "20Mi"
        env:
        - name: NODE_NAME
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
        volumeMounts:
        - name: log
          mountPath: /var/log
        - name: localtime
          mountPath: /etc/localtime
          readOnly: true
      volumes:
      - name: log
        hostPath:
          path: /var/log/
      - name: localtime
        hostPath:
          path: /etc/localtime
          type: "FileOrCreate"
      serviceAccountName: node-problem-detector
      tolerations:
      - operator: "Exists"
        effect: "NoExecute"
      - key: "CriticalAddonsOnly"
        operator: "Exists"
EOF

NPD가 수집한 지표 정보 확인

ex) curl 10.200.230.1:20257/metrics

NPD 탐지 확인

npd 테스트 예제 참고

https://github.com/kubernetes/node-problem-detector/tree/master/test/kernel_log_generator/problems

problem_counter의 KernelOops 항목 탐지 확인

아래와 같이 수동으로 에로 로그를 커널 로그에 추가

sudo sh -c "echo 'kernel: BUG: unable to handle kernel NULL pointer dereference at TESTING' >> /dev/kmsg"

이후 탐지 count 증가되는지 확인

curl localhost:20257/metrics

problem_counter의 OOM항목 탐지 확인

아래와 같이 수동으로 에로 로그를 커널 로그에 추가

sudo sh -c "echo 'Killed process 4070 (iksoon-test) total-vm:8192780kB, anon-rss:7231748kB, file-rss:0kB, shmem-rss:0kB' >> /dev/kmsg"

이후 탐지 count 증가되는지 확인

탐지 이후 count는 감소되지 않고 유지,

탐지 될 때 마다 count 증가함.

problem_gauge의 FilesystemIsReadOnly항목 탐지 확인

sudo sh -c "echo 'Remounting filesystem read-only' >> /dev/kmsg"

참고

https://kubernetes.io/ko/docs/tasks/debug/debug-cluster/monitor-node-health/

https://github.com/kubernetes/node-problem-detector

https://stackoverflow.com/questions/48134835/how-to-use-k8s-node-problem-detector

kubernetes 모니터링 : process-exporter 란?

이쿠우우 — Sun, 22 Sep 2024 21:02:05 +0900

Process Exporter

process-exporter 란?

System Metrics 중 "process" 관련 지표 정보를 수집할 수 있음.

Prometheus와 연동 가능

Prometheus에서 관리하는 프로젝트는 아님.

MIT license로 제공

참고 : https://github.com/ncabatoff/process-exporter

사용 case는 많지 않고... 관련 자료도 거의 없음.

수집하는 metrics 계층

= System Metrics

Instanace에서 실행 중인 Process에 대한 "system metrics"정보를 수집하여 API로 제공.

수집하는 metrics 정보 확인 링크

[process-export의 metrics list 정보]

별도로 없음.

직접 정리하면 아래와 같음.

# HELP namedprocess_namegroup_context_switches_total Context switches
# HELP namedprocess_namegroup_cpu_seconds_total Cpu user usage in seconds
# HELP namedprocess_namegroup_major_page_faults_total Major page faults
# HELP namedprocess_namegroup_memory_bytes number of bytes of memory in use
# HELP namedprocess_namegroup_minor_page_faults_total Minor page faults
# HELP namedprocess_namegroup_num_procs number of processes in this group
# HELP namedprocess_namegroup_num_threads Number of threads
# HELP namedprocess_namegroup_oldest_start_time_seconds start time in seconds since 1970/01/01 of oldest process in group
# HELP namedprocess_namegroup_open_filedesc number of open file descriptors for this group
# HELP namedprocess_namegroup_read_bytes_total number of bytes read by this group
# HELP namedprocess_namegroup_states Number of processes in states Running, Sleeping, Waiting, Zombie, or Other
# HELP namedprocess_namegroup_thread_context_switches_total Context switches for these threads
# HELP namedprocess_namegroup_thread_count Number of threads in this group with same threadname
# HELP namedprocess_namegroup_thread_cpu_seconds_total Cpu user/system usage in seconds
# HELP namedprocess_namegroup_thread_io_bytes_total number of bytes read/written by these threads
# HELP namedprocess_namegroup_thread_major_page_faults_total Major page faults for these threads
# HELP namedprocess_namegroup_thread_minor_page_faults_total Minor page faults for these threads
# HELP namedprocess_namegroup_threads_wchan Number of threads in this group waiting on each wchan
# HELP namedprocess_namegroup_worst_fd_ratio the worst (closest to 1) ratio between open fds and max fds among all procs in this group
# HELP namedprocess_namegroup_write_bytes_total number of bytes written by this group
# HELP namedprocess_scrape_errors general scrape errors: no proc metrics collected during a cycle
# HELP namedprocess_scrape_partial_errors incremented each time a tracked proc's metrics collection fails partially, e.g. unreadable I/O stats
# HELP namedprocess_scrape_procread_errors incremented each time a proc's metrics collection fails
# HELP process_cpu_seconds_total Total user and system CPU time spent in seconds.
# HELP process_exporter_build_info A metric with a constant '1' value labeled by version, revision, branch, and goversion from which process_exporter was built.
# HELP process_max_fds Maximum number of open file descriptors.
# HELP process_open_fds Number of open file descriptors.
# HELP process_resident_memory_bytes Resident memory size in bytes.
# HELP process_start_time_seconds Start time of the process since unix epoch in seconds.
# HELP process_virtual_memory_bytes Virtual memory size in bytes.
# HELP process_virtual_memory_max_bytes Maximum amount of virtual memory available in bytes.
# HELP promhttp_metric_handler_requests_in_flight Current number of scrapes being served.
# HELP promhttp_metric_handler_requests_total Total number of scrapes by HTTP status code.

수집한 metrics 정보를 전달하는 방식

= Pull 방식

node-exporter는 HTTP 통신을 통해 Prometheus Server와 같은 metrics server가 process-exporter가 수집한 Metric Data를 가져갈 수 있게

/metrics 라는 HTTP 엔드포인트를 제공함.

exporter가 해당 엔드포인트를 제공하고 있어서 Server가 exporter의 엔드포인트로 HTTP GET 요청을 날려 Metric Data를 Pull방식으로 수집함.

process-exporter 배포 방법

process-exporter.yaml

설정파일

apiVersion: v1
kind: ConfigMap
metadata:
  name: process-exporter-conf
  labels:
    name: process-exporter-conf
  namespace: monitoring
data:
  process-exporter-config.yml: |-
    process_names:
    - name: "{{.Comm}}"
      cmdline:
      - '.+'

실행

apiVersion: v1
kind: ConfigMap
metadata:
  name: process-exporter-conf
  labels:
    name: process-exporter-conf
  namespace: monitoring
data:
  process-exporter-config.yml: |-
    process_names:
    - name: "{{.Comm}}"
      cmdline:
      - '.+'
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  labels:
    app.kubernetes.io/component: process-exporter
    app.kubernetes.io/name: process-exporter
  name: process-exporter
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app.kubernetes.io/component: process-exporter
      app.kubernetes.io/name: process-exporter
  template:
    metadata:
      labels:
        app.kubernetes.io/component: process-exporter
        app.kubernetes.io/name: process-exporter
    spec:
      containers:
      - args:
        - -procfs=/host/proc
        - -config.path=/etc/process-exporter/process-exporter-config.yml
        name: process-exporter
        image: ncabatoff/process-exporter
        securityContext:
          privileged: true
        ports:
          - containerPort: 9256
            protocol: TCP
        resources:
          limits:
            cpu: 250m
            memory: 180Mi
          requests:
            cpu: 102m
            memory: 180Mi
        volumeMounts:
          - mountPath: /host/proc
            name: proc-volume
            readOnly: true
          - name: process-exporter-config-volume
            mountPath: /etc/process-exporter/
      volumes:
        - name: proc-volume
          hostPath:
            path: /proc
            type: ""
        - name: process-exporter-config-volume
          configMap:
            defaultMode: 420
            name: process-exporter-conf
---
kind: Service
apiVersion: v1
metadata:
  name: process-exporter
  namespace: monitoring
  annotations:
      prometheus.io/scrape: 'true'
      prometheus.io/port:  '9256'
spec:
  selector:
      app.kubernetes.io/component: process-exporter
      app.kubernetes.io/name: process-exporter
  ports:
  - name: node-exporter
    protocol: TCP
    port: 9256
    targetPort: 9256

참고

https://github.com/ncabatoff/process-exporter

metricbeat container 실행 방법

이쿠우우 — Sun, 22 Sep 2024 20:40:02 +0900

metricbeat container 실행 방법

worker node에서 metricbeat의 메모리 사용량이 최대 60%까지 올라가는 이슈가 있었음.

해당 메모리 사용량 이슈는 metricbeat의 메모리릭 이슈로 확인됨.
metricbeat git issues를 확인해보면 각 버전별로 항상 언급됨.
고질병인가봄...

해당 이슈를 해결 할 수 있는 방법 중 하나로

container로 실행 시켜서 CPU, Memory 사용량을 제한 하는 방법을 알아봄.

사용하는 tool은 nerdctl임

nerdctl run 명령 시 CPU, Memory 사용량 제한 하는 옵션

--cpu-period uint            Limit CPU CFS (Completely Fair Scheduler) period
      --cpu-quota int              Limit CPU CFS (Completely Fair Scheduler) quota (default -1)
      --cpu-shares uint            CPU shares (relative weight)
      --cpus float                  Number of CPUs
      --cpuset-cpus string          CPUs in which to allow execution (0-3, 0,1)
      --cpuset-mems string          MEMs in which to allow execution (0-3, 0,1)


-m, --memory string              Memory limit
      --memory-reservation string  Memory soft limit
      --memory-swap string          Swap limit equal to memory plus swap: '-1' to enable unlimited swap
      --memory-swappiness int      Tune container memory swappiness (0 to 100) (default -1) (default -1)
      --mount stringArray          Attach a filesystem mount to the container

metricbeat container 실행

nerdctl run \
--name=metricbeat \
--network host \
--privileged \
--volume="/etc/metricbeat:/etc/metricbeat:ro" \
--volume="/var/run/docker.sock:/var/run/docker.sock:ro" \
--volume="/sys/fs/cgroup:/hostfs/sys/fs/cgroup:ro" \
--volume="/proc:/hostfs/proc:ro" \
--volume="/:/hostfs:ro" \
docker.elastic.co/beats/metricbeat:8.7.0 metricbeat -e \
--path.config /etc/metricbeat/ -c /etc/metricbeat/metricbeat.yml

특이 사항

--system.hostfs 설정은 DEPRECATED 됨.

DEPRECATED: The --system.hostfs flag will be removed in the future and replaced by a config value. Will be removed in version: 8.0.0

Container로 실행 시 몇 가지 문제점이 있음

filesystem metricset에서 경로가 container 경로로 나옴 (host 부분 생략하면 실제 경로 이긴 함)
process monitoring이 불가능함
일부 system metric 항목이 host에서 수집할 때와 다른 결과가 나옴.

참고

https://www.elastic.co/guide/en/beats/metricbeat/current/running-on-docker.html#monitoring-host

metricbeat : Error initializing Kubernetes metadata enricher

이쿠우우 — Sat, 7 Sep 2024 21:04:40 +0900

metricbeat 사용중 에러 발생

오류명

Error initializing Kubernetes metadata enricher: unable to build kube config due to error: invalid configuration: no configuration has been provided, try setting KUBERNETES_MASTER environment variable

원인

kubeconfig 파일을 찾지 못해서 발생하는 에러.

근데 왜 worker node에서 kubeconfig 파일을 사용해야하는지는 ... 모르겠음.

리서치 항목 : kubeconfig 있을 때, 없을 때 차이 비교해봐야함.

kubeconifg 값에 아무것도 안주고 이상이 없는지 확인 (ERROR log 남는지 확인)
kubeconfig 환경변수 추가 안하고 kube-proxy, state-metrics 등 정보 가져오는지 확인
kubeconfig 환경변수 정상 추가 후 kube-proxy, state-metrics 등 정보 가져오는지 확인

결론 : 해당 에러는 단순하게 kubeconfig 환경변수 못찾아서 발생하는 오류고 실제 동작에는 영향이 없음.

해당 에러는 Metricbeat이 Kubernetes API 서버와 통신하기 위해 필요한 구성 정보가 없어 발생하는 문제입니다. 로컬 환경에서 실행 중인 Metricbeat은 Kubernetes 클러스터 내부에서 실행 중인 Pod이나 Container가 아니므로, InCluster 인증 방식을 사용할 수 없습니다.

해결책

kubernetes module의 kubeconfig 옵션을 사용해봤지만 해결되지 않음.

그래서 환경 변수를 사용하는 아래와 같은 방법을 사용해야함.

kubeconfig파일을 다운받고

worker node의

/etc/metricbeat/kubeconfig.yaml

경로에 배치

cat /etc/systemd/system/metricbeat.service

파일에

Environment=KUBECONFIG=/etc/metricbeat/kubeconfig.yaml

내용 추가해야함

아래와 같이 수정.

[Unit]
Description=metricbeat

[Service]
Environment=KUBECONFIG=/etc/metricbeat/kubeconfig.yaml
ExecStart=/bin/bash -c '/bin/metricbeat --path.config /etc/metricbeat/ -c /etc/metricbeat/metricbeat.yml -e'
Delegate=yes
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

이후

systemctl daemon-reload
systemctl restart metricbeat

metricbeat에서 worker node kubelet 접근 방법 리서치 중 오류 분석 내용

이쿠우우 — Sat, 7 Sep 2024 21:02:13 +0900

오류명

util/kubernetes.go:114#011Error initializing Kubernetes metadata enricher: unable to build kube config due to error: invalid configuration: no configuration has been provided, try setting KUBERNETES_MASTER environment variable

원인

인증 에러임.

token 정보가 잘못되어있었음.

해결책

bearer_token_file 옵션을 token형식이 아닌 crt, key파일로 변경해야함.

bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
을 아래와 같이 변경
ssl.certificate: "/path/to/certificate.crt"
ssl.key: "/path/to/private.key"

Kubernetes 모니터링 : metricbeat 란?

이쿠우우 — Sat, 7 Sep 2024 21:00:35 +0900

metricbeat

metricbeat란?

Elastic Stack의 일부인 오프소스 데이터 수집 에이전트로,

System 및 Service Metrics를 수집하는데 사용됨.

수집하는 metrics 계층

= System, Service Metrics

metricbeat는 다양한 module을 제공하고 있어서

system metrics 뿐만 아니라 다양한 Service Metrics도 수집할 수 있는 장점을 가지고 있음.

[모듈 정보 list]

https://www.elastic.co/guide/en/beats/metricbeat/current/metricbeat-modules.html

수집하는 metrics 정보 확인 링크

[system module 이 수집하는 metrics 정보]

https://www.elastic.co/guide/en/beats/metricbeat/current/metricbeat-module-system.html

[kubernetes module 이 수집하는 metrics 정보]

https://www.elastic.co/guide/en/beats/metricbeat/current/metricbeat-modules.html

수집한 metrics 정보를 전달하는 방식

= push 방식

metricbeat는 수집한 metrics정보를 특정 plugin으로 전달할 수 있음.

주로 Elastic Stack 관련 제품으로 보낼 수 있음.

전달 가능 대상

Elasticsearch Service
Elasticsearch
Logstash
Kafka
Redis
File
Console

[output module 목록 참고]

https://www.elastic.co/guide/en/beats/metricbeat/current/configuring-output.html

metricbeat은 추가되는 모듈에 따라 스레드가 추가될까?

직접 확인 cpu, memory, diskio 등 8개의 module을 추가하고 아래 명령으로 스레드 확인

pstree -hp "metricbeat pid"

ex) pstree -hp 2575026

확인 결과 동일하게 8개가 조회됨

metricbeat에서 fields 지정하는 방법

아래와 같이 metricbeat.yaml 파일에서 설정 가능

tags, fields 를 지정하여 설정 가능.

수집한 정보는 아래와 같이 확인할 수 있음.

metricbeat에서 kubernetes 지표 정보 수집이 가능한가?

결론

kubernetes 모듈을 사용하여 kubernetes 지표 정보 수집 가능.

metricbeat에서 worker node kubelet 접근 방법 확인

metricbeat에서 kubernetes module 사용 시

kubelet에 포함되어있는 cAdvisor로 부터 지표 정보를 가져옴.

이때 kubelet에 접속하는 방법은 2가지로 token, key 방법이 있음.

metricbeat에서 worker node kubelet 접근 방법 (token)

1. SA 생성

apiVersion: v1
kind: ServiceAccount
metadata:
  name: metricbeat
  namespace: kube-system
  labels:
    k8s-app: metricbeat

2. ClusterRole 생성

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: metricbeat
  labels:
    k8s-app: metricbeat
rules:
- apiGroups: [""]
  resources:
  - nodes
  - namespaces
  - events
  - pods
  verbs: ["get", "list", "watch"]
- apiGroups: ["batch"]
  resources:
  - jobs
  verbs: ["get", "list", "watch"]
- apiGroups: ["extensions"]
  resources:
  - replicasets
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources:
  - statefulsets
  - deployments
  verbs: ["get", "list", "watch"]
- apiGroups:
  - ""
  resources:
  - nodes/stats
  - nodes/metrics
  verbs:
  - get
- nonResourceURLs:
  - /metrics
  verbs:
  - get

3. ClusterRoleBinding 생성

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: metricbeat
subjects:
- kind: ServiceAccount
  name: metricbeat
  namespace: kube-system
roleRef:
  kind: ClusterRole
  name: metricbeat
  apiGroup: rbac.authorization.k8s.io

4. 1.24 버전 이상의 경우 SA 생성 시 secret token이 자동 생성 되지 않아서 수동 생성이 필요함

apiVersion: v1
kind: Secret
metadata:
  name: metricbeat
  namespace: kube-system
  annotations:
    kubernetes.io/service-account.name: metricbeat
type: kubernetes.io/service-account-token

5. SA 토큰 가져오기

- module: kubernetes
  metricsets:
    - container
    - node
    - pod
    - system
    - volume
  period: 30s
  hosts: ["https://iksoon-cidr-default-worker-node-0.novalocal:10250"]
  bearer_token_file: /etc/metricbeat/token
  ssl.certificate_authorities:
    - /etc/kubernetes/pki/ca.crt

일반적으로 metricbeat을 kubernetes에 배포 시 Daemonset으로 배포함.

배포 할 때 serviceaccount 생성 후

serviceaccount의 secret token 경로를 명시함.

6. kubelet API 호출

curl -Ssk --header "Authorization: Bearer ${TOKEN}" https://localhost:10250/metrics/cadvisor

metricbeat에서 worker node kubelet 접근 방법 (키 사용)

(kubelet API 호출)

kube-admin으로 생성된 클러스터의 경우 아래와 같이 "apiserver-kubelet-client.key, crt"을 사용함.

curl https://localhost:10250/metrics -k --cert "키파일 경로" --key "키파일 경로"

metricbeat의 kubernetes module에서 사용법

worker node 에서 진행

/etc/metricbeat/modules.d/kubernetes.yml

"ssl.certificate:", "ssl.key:", "ssl.certificate_authorities:" 옵션 사용.

- module: kubernetes
  metricsets:
    - node
    - system
    - pod
    - container
    - volume
  period: 30s
  hosts: ["https://iksoon-cidr-default-worker-node-0.novalocal:10250"]
  ssl.certificate: 키파일 경로
  ssl.key: 키 파일 경로
  ssl.certificate_authorities:
    - 키 파일 경로

/etc/metricbeat/metricbeat.yml

output.file:
  path: "/etc/metricbeat"
  filename: "iksoon_test"

Kubernetes 모니터링 : kube-state-metrics 란?

이쿠우우 — Thu, 5 Sep 2024 21:26:15 +0900

kube-state-metrics(KSM)

kube-state-metrics(KSM)란?

kubernetes에서 공식적으로 제공하는 서비스로

kubernetes 클러스터 내부의 Pod가 사용 중인 리소스 metric과 네트워크 I/O, Deployments 수, Pod 수 등의 다양한 정보를 수집함.

수집하는 metrics 계층

= Service Metrics : kubernetes

Container를 컨트롤 하는 Kubernetes 자체에 대한 모니터링

(Kubernetes의 자원인 Service, POD, Namespace 등)

수집하는 metrics 정보 확인 링크

https://github.com/kubernetes/kube-state-metrics/blob/main/docs/pod-metrics.md

수집한 metrics 정보를 전달하는 방식

= Pull 방식

HTTP 통신을 통해 Prometheus Server와 같은 metrics server가 kube-state-metrics가 수집한 Metric Data를 가져갈 수 있게

/metrics 라는 HTTP 엔드포인트를 제공함.

exporter가 해당 엔드포인트를 제공하고 있어서 Server가 exporter의 엔드포인트로 HTTP GET 요청을 날려 Metric Data를 Pull방식으로 수집함.

kube-state-metrics가 수집한 metrics 정보 확인하는 방법

kube-state-metrics는 모든 node에 접근하여 해당 node의 metric을 직접 수집하는 node-exporter와는 달리,

kube-state-metrics는 kubernetes가 이미 갖고 있는 데이터를 kubernetes api 서버로부터 요청하여 가져오기 때문에

cluster 내에 단 하나의 component만 배포함.

yaml

2023.01.30 기준 최신 version = v2.7.0

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    app.kubernetes.io/component: exporter
    app.kubernetes.io/name: kube-state-metrics
    app.kubernetes.io/version: 2.8.2
  name: kube-state-metrics
rules:
- apiGroups:
  - ""
  resources:
  - configmaps
  - secrets
  - nodes
  - pods
  - services
  - serviceaccounts
  - resourcequotas
  - replicationcontrollers
  - limitranges
  - persistentvolumeclaims
  - persistentvolumes
  - namespaces
  - endpoints
  verbs:
  - list
  - watch
- apiGroups:
  - apps
  resources:
  - statefulsets
  - daemonsets
  - deployments
  - replicasets
  verbs:
  - list
  - watch
- apiGroups:
  - batch
  resources:
  - cronjobs
  - jobs
  verbs:
  - list
  - watch
- apiGroups:
  - autoscaling
  resources:
  - horizontalpodautoscalers
  verbs:
  - list
  - watch
- apiGroups:
  - authentication.k8s.io
  resources:
  - tokenreviews
  verbs:
  - create
- apiGroups:
  - authorization.k8s.io
  resources:
  - subjectaccessreviews
  verbs:
  - create
- apiGroups:
  - policy
  resources:
  - poddisruptionbudgets
  verbs:
  - list
  - watch
- apiGroups:
  - certificates.k8s.io
  resources:
  - certificatesigningrequests
  verbs:
  - list
  - watch
- apiGroups:
  - discovery.k8s.io
  resources:
  - endpointslices
  verbs:
  - list
  - watch
- apiGroups:
  - storage.k8s.io
  resources:
  - storageclasses
  - volumeattachments
  verbs:
  - list
  - watch
- apiGroups:
  - admissionregistration.k8s.io
  resources:
  - mutatingwebhookconfigurations
  - validatingwebhookconfigurations
  verbs:
  - list
  - watch
- apiGroups:
  - networking.k8s.io
  resources:
  - networkpolicies
  - ingressclasses
  - ingresses
  verbs:
  - list
  - watch
- apiGroups:
  - coordination.k8s.io
  resources:
  - leases
  verbs:
  - list
  - watch
- apiGroups:
  - rbac.authorization.k8s.io
  resources:
  - clusterrolebindings
  - clusterroles
  - rolebindings
  - roles
  verbs:
  - list
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kube-state-metrics
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: kube-state-metrics
subjects:
  - kind: ServiceAccount
    name: kube-state-metrics-account
    namespace: kube-system
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: kube-state-metrics-account
  namespace: kube-system

---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: kube-state-metrics
  name: kube-state-metrics
  namespace: kube-system
spec:
  replicas: 1
  selector:
    matchLabels:
      app: kube-state-metrics
  template:
    metadata:
      labels:
        app: kube-state-metrics
    spec:
      containers:
        - name: kube-state-metrics
          image: registry.k8s.io/kube-state-metrics/kube-state-metrics:v2.7.0
          resources:
            requests:
              cpu: 500m
              memory: 2Gi
            limits:
              cpu: 500m
              memory: 2Gi
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5
            timeoutSeconds: 5
          ports:
            - containerPort: 8080
              name: scrape
            - containerPort: 8081
              name: telemetry
          readinessProbe:
            httpGet:
              path: /
              port: 8081
            initialDelaySeconds: 5
            timeoutSeconds: 5
      nodeSelector:
        kubernetes.io/os: linux
      serviceAccountName: kube-state-metrics-account
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: kube-state-metrics
  name: kube-state-http-metrics-nodeport
  namespace: kube-system
spec:
  type: NodePort
  selector:
    app: kube-state-metrics
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 8080
      nodePort: 30001
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: kube-state-metrics
  name: kube-state-telemetry-nodeport
  namespace: kube-system
spec:
  type: NodePort
  selector:
    app: kube-state-metrics
  ports:
    - protocol: TCP
      port: 8081
      targetPort: 8081
      nodePort: 30002

KSM port

8080 port : KSM으로 부터 metrics 정보를 확인하는 용도

8081 port : self metrics로 metrics 정보 수집 시도 시 성공, 실패 상태를 확인할 수 있음.

KSM의 metrics 수집 결과 확인

curl {IP}:8080/metrics

[kube-state-metrics의 metrics list 정보]

https://github.com/kubernetes/kube-state-metrics/blob/main/docs/pod-metrics.md

[참고]

https://github.com/kubernetes/kube-state-metrics

https://medium.com/finda-tech/kube-state-metrics%EC%97%90-%EB%8C%80%ED%95%B4%EC%84%9C-1303b10fb8f8

오류 : inotify_add_watch /sys/fs/cgroup/cpuacct,cpu: no such file or directory

이쿠우우 — Thu, 5 Sep 2024 21:22:43 +0900

오류 : inotify_add_watch /sys/fs/cgroup/cpuacct,cpu: no such file or directory

[상황]

cAdvisor git에 있는 kubernetes deploy인 아래의 링크를 참고해서

https://github.com/google/cadvisor/blob/master/deploy/kubernetes/base/daemonset.yaml

kubernetes cluster에 cAdvisor Daemonset 를 배포했는데

다음과 같은 오류가 발생함.

[오류 메세지]

Could not configure a source for OOM detection, disabling OOM events: open /dev/kmsg: no such file or directory

Failed to start container manager: inotify_add_watch /sys/fs/cgroup/cpuacct,cpu: no such file or directory

none of the resources are being tracked.

[원인]

해당 오류는 volume mount에 관한 오류임.

/sys/fs/cgroup 에 mount할 volume이 명시되어있지 않아서

pod가 정상적으로 running 되지 못함.

[해결]

아래와 같이 cgroup 관련 volume을 추가해줘야함

host에 / 경로에 cgroup 디렉터리도 생성해줘야함

apiVersion: apps/v1 # for Kubernetes versions before 1.9.0 use apps/v1beta2
kind: DaemonSet
metadata:
  name: cadvisor
  namespace: cadvisor
spec:
  selector:
    matchLabels:
      name: cadvisor
  template:
    metadata:
      labels:
        name: cadvisor
    spec:
      tolerations:
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      containers:
      - name: cadvisor
        image: google/cadvisor:latest
        securityContext:
          privileged: true
        resources:
          requests:
            memory: 200Mi
            cpu: 150m
          limits:
            memory: 2000Mi
            cpu: 300m
        volumeMounts:
        - name: rootfs
          mountPath: /rootfs
          readOnly: true
        - name: var-run
          mountPath: /var/run
          readOnly: true
        - name: sys
          mountPath: /sys
          readOnly: true
        - name: docker
          mountPath: /var/lib/docker
          readOnly: true
        - name: disk
          mountPath: /dev/disk
          readOnly: true
        - name: cgroup
          mountPath: /sys/fs/cgroup
          readOnly: true
        ports:
          - name: http
            containerPort: 8080
            protocol: TCP
      automountServiceAccountToken: false
      terminationGracePeriodSeconds: 30
      volumes:
      - name: rootfs
        hostPath:
          path: /
      - name: var-run
        hostPath:
          path: /var/run
      - name: sys
        hostPath:
          path: /sys
      - name: docker
        hostPath:
          path: /var/lib/docker
      - name: disk
        hostPath:
          path: /dev/disk
      - name: cgroup
        hostPath:
          path: /cgroup

cAdvisor container로 배포 해서 확인 하는 방법(storage driver = Kafka)

이쿠우우 — Thu, 5 Sep 2024 21:20:29 +0900

cAdvisor container로 배포 해서 확인 하는 방법(storage driver = Kafka)

cAdvisor에서 Kafka로 지표 전달 가능함.

storage_driver 설정을 kafka로 설정하면 됨

[참고 링크]

https://github.com/google/cadvisor/blob/master/docs/storage/kafka.md

Kafka 클러스터 실행

kafka download

wget https://archive.apache.org/dist/kafka/3.1.0/kafka_2.13-3.1.0.tgz
tar xvf kafka_2.13-3.1.0.tgz
cd kafka_2.13-3.1.0

kafka 설정 파일 변경

vim config/server.properties

아래 2개 내용 추가

listeners=PLAINTEXT://0.0.0.0:9092
advertised.listeners=PLAINTEXT://133.186.163.60:9092

설정 참고 : https://sharplee7.tistory.com/144

kafka 실행

bin/zookeeper-server-start.sh config/zookeeper.properties
bin/kafka-server-start.sh config/server.properties

[kafka 명령어 정리]

토픽 생성

./kafka-topics.sh --create --bootstrap-server localhost:9092 --replication-factor 1 --partitions 3 --topic test

토픽 삭제

./kafka-topics.sh --delete --topic kube_test --bootstrap-server localhost:9092

토픽 조회

./kafka-topics.sh --describe --bootstrap-server localhost:9092

토픽 이벤트 조회

./kafka-console-consumer.sh --bootstrap-server localhost:9092 --from-beginning --topic kube_test

참고 링크

https://ifuwanna.tistory.com/488

cAdvisor container 실행

nerdctl run \
  --volume=/:/rootfs:ro \
  --volume=/var/run:/var/run:rw \
  --volume=/sys:/sys:ro \
  --network host \
  --detach=true \
  --name=cadvisor \
  --privileged \
  gcr.io/cadvisor/cadvisor:v0.47.0 \
  --storage_driver=kafka \
  --storage_driver_kafka_broker_list=192.168.0.72:9092 \
  --storage_driver_kafka_topic=kube_test

storage_driver_kafka_broker_list 설정에

kafka가 실행 중인 host ip 입력.

토픽은 "kube_test"로 설정

결과 확인

아래와 같이 cAdvisor 컨테이너가 정상 실행됨

컨테이너가 실행되면서 kafka에 kube_test 토픽은 자동으로 생성됨.

토픽 이벤트에서 cadvisor 수집 내용 정상 확인 가능.

아래와 같이 host에서 실행 중인 container의 지표 정보도 수집가능함.

{"timestamp":"2023-04-03T00:00:12.674870998Z","machine_name":"2e79b19d7a6d","container_Name":"/system.slice/kube-apiserver.service","container_stats":{"timestamp":"2023-04-03T00:00:12.674832861Z","cpu":{"usage":{"total":1517422879969,"per_cpu_usage":[758520079913,758902800056],"user":752100000000,"system":725360000000},"cfs":{"periods":0,"throttled_periods":0,"throttled_time":0},"schedstat":{"run_time":0,"runqueue_time":0,"run_periods":0},"load_average":0},"diskio":{"io_service_bytes":[{"device":"/dev/vda","major":252,"minor":0,"stats":{"Async":0,"Read":24576,"Sync":24576,"Total":24576,"Write":0}}],"io_serviced":[{"device":"/dev/vda","major":252,"minor":0,"stats":{"Async":0,"Read":2,"Sync":2,"Total":2,"Write":0}}]},"memory":{"usage":9777152,"max_usage":10592256,"cache":0,"rss":8450048,"swap":0,"mapped_file":0,"working_set":9773056,"failcnt":0,"container_data":{"pgfault":6864,"pgmajfault":0,"numa_stats":{}},"hierarchical_data":{"pgfault":6864,"pgmajfault":0,"numa_stats":{}}},"network":{"name":"","rx_bytes":0,"rx_packets":0,"rx_errors":0,"rx_dropped":0,"tx_bytes":0,"tx_packets":0,"tx_errors":0,"tx_dropped":0,"tcp":{"Established":0,"SynSent":0,"SynRecv":0,"FinWait1":0,"FinWait2":0,"TimeWait":0,"Close":0,"CloseWait":0,"LastAck":0,"Listen":0,"Closing":0},"tcp6":{"Established":0,"SynSent":0,"SynRecv":0,"FinWait1":0,"FinWait2":0,"TimeWait":0,"Close":0,"CloseWait":0,"LastAck":0,"Listen":0,"Closing":0},"udp":{"Listen":0,"Dropped":0,"RxQueued":0,"TxQueued":0},"udp6":{"Listen":0,"Dropped":0,"RxQueued":0,"TxQueued":0},"tcp_advanced":{"RtoAlgorithm":0,"RtoMin":0,"RtoMax":0,"MaxConn":0,"ActiveOpens":0,"PassiveOpens":0,"AttemptFails":0,"EstabResets":0,"CurrEstab":0,"InSegs":0,"OutSegs":0,"RetransSegs":0,"InErrs":0,"OutRsts":0,"InCsumErrors":0,"EmbryonicRsts":0,"SyncookiesSent":0,"SyncookiesRecv":0,"SyncookiesFailed":0,"PruneCalled":0,"RcvPruned":0,"OfoPruned":0,"OutOfWindowIcmps":0,"LockDroppedIcmps":0,"TW":0,"TWRecycled":0,"TWKilled":0,"TCPTimeWaitOverflow":0,"TCPTimeouts":0,"TCPSpuriousRTOs":0,"TCPLossProbes":0,"TCPLossProbeRecovery":0,"TCPRenoRecoveryFail":0,"TCPSackRecoveryFail":0,"TCPRenoFailures":0,"TCPSackFailures":0,"TCPLossFailures":0,"DelayedACKs":0,"DelayedACKLocked":0,"DelayedACKLost":0,"ListenOverflows":0,"ListenDrops":0,"TCPHPHits":0,"TCPPureAcks":0,"TCPHPAcks":0,"TCPRenoRecovery":0,"TCPSackRecovery":0,"TCPSACKReneging":0,"TCPFACKReorder":0,"TCPSACKReorder":0,"TCPRenoReorder":0,"TCPTSReorder":0,"TCPFullUndo":0,"TCPPartialUndo":0,"TCPDSACKUndo":0,"TCPLossUndo":0,"TCPFastRetrans":0,"TCPSlowStartRetrans":0,"TCPLostRetransmit":0,"TCPRetransFail":0,"TCPRcvCollapsed":0,"TCPDSACKOldSent":0,"TCPDSACKOfoSent":0,"TCPDSACKRecv":0,"TCPDSACKOfoRecv":0,"TCPAbortOnData":0,"TCPAbortOnClose":0,"TCPAbortOnMemory":0,"TCPAbortOnTimeout":0,"TCPAbortOnLinger":0,"TCPAbortFailed":0,"TCPMemoryPressures":0,"TCPMemoryPressuresChrono":0,"TCPSACKDiscard":0,"TCPDSACKIgnoredOld":0,"TCPDSACKIgnoredNoUndo":0,"TCPMD5NotFound":0,"TCPMD5Unexpected":0,"TCPMD5Failure":0,"TCPSackShifted":0,"TCPSackMerged":0,"TCPSackShiftFallback":0,"TCPBacklogDrop":0,"PFMemallocDrop":0,"TCPMinTTLDrop":0,"TCPDeferAcceptDrop":0,"IPReversePathFilter":0,"TCPReqQFullDoCookies":0,"TCPReqQFullDrop":0,"TCPFastOpenActive":0,"TCPFastOpenActiveFail":0,"TCPFastOpenPassive":0,"TCPFastOpenPassiveFail":0,"TCPFastOpenListenOverflow":0,"TCPFastOpenCookieReqd":0,"TCPSynRetrans":0,"TCPOrigDataSent":0,"PAWSActive":0,"PAWSEstab":0}},"task_stats":{"nr_sleeping":0,"nr_running":0,"nr_stopped":0,"nr_uninterruptible":0,"nr_io_wait":0},"processes":{"process_count":0,"fd_count":0,"socket_count":0},"resctrl":{},"cpuset":{"memory_migrate":0}}}

이쿠의 슬기로운 개발생활

Calico 리서치

목표

Calico 란?

CNI란?

Flannel과 Calico의 차이점

Calico Components

Calico-node

Calico-node : Felix

[Felix vs BIRD : 라우팅 역할 분담]

[kube-proxy와 Felix의 관계 & eBPF 모드]

Calico-node : BIRD

CALICO_NETWORKING_BACKEND 설정이 bird 일 때만 실행되는 BGP 데몬.

(vxlan 모드나 none 모드에서는 실행되지 않음.)

모든 노드에 배포되어 실행되며, 노드 간에 BGP Peering을 맺음.

내 노드에 있는 Pod들의 IP 정보를 다른 노드(Peer)들에게 전파하는 역할을 담당.

이를 통해 각 노드는 클러스터 전체의 Pod 경로(Route)를 학습하게 됨.

BGP Peering 모드 (Topology)

Calico-node : Confd

Calico Datastore

저장 데이터:

저장소 모드

Calico IPAM plugin

Calico IPAM의 핵심 특징: Block Affinity

kube-controllers (Calico-kube-controllers)

Datastore 모드에 따른 역할 차이

calico-kube-controller 내부 controller 항목

kube-controllers가 생성하는 etcd key/value

Typha

calicoctl

kubernetes 모니터링 : Node Problem Detector(NPD)란?

Node Problem Detector

Node Problem Detector(NPD) 란?

수집하는 metrics 계층

수집하는 metrics 정보 확인 링크

NPD 설정 확인

수집한 metrics 정보를 전달하는 방식

default port

Node Problem Detector 배포 방법

NPD가 수집한 지표 정보 확인

NPD 탐지 확인

problem_counter의 KernelOops 항목 탐지 확인

problem_counter의 OOM항목 탐지 확인

problem_gauge의 FilesystemIsReadOnly항목 탐지 확인

kubernetes 모니터링 : process-exporter 란?

Process Exporter

process-exporter 란?

수집하는 metrics 계층

수집하는 metrics 정보 확인 링크

수집한 metrics 정보를 전달하는 방식

metricbeat container 실행 방법

metricbeat container 실행 방법

nerdctl run 명령 시 CPU, Memory 사용량 제한 하는 옵션

metricbeat container 실행

Container로 실행 시 몇 가지 문제점이 있음

metricbeat : Error initializing Kubernetes metadata enricher

metricbeat 사용중 에러 발생

오류명

원인

해결책

metricbeat에서 worker node kubelet 접근 방법 리서치 중 오류 분석 내용

오류명

원인

해결책

Kubernetes 모니터링 : metricbeat 란?

metricbeat

metricbeat란?

수집하는 metrics 계층

수집하는 metrics 정보 확인 링크

수집한 metrics 정보를 전달하는 방식

관련 설정

전달 가능 대상

metricbeat은 추가되는 모듈에 따라 스레드가 추가될까?

metricbeat에서 fields 지정하는 방법

metricbeat에서 kubernetes 지표 정보 수집이 가능한가?

결론

metricbeat에서 worker node kubelet 접근 방법 확인

metricbeat에서 worker node kubelet 접근 방법 (token)

metricbeat에서 worker node kubelet 접근 방법 (키 사용)

metricbeat의 kubernetes module에서 사용법