home..

Cilium 심층탐구

October 2024 (3593 Words, 20 Minutes)

mont-kim Docker Container Pod Container Kubernetes Service

About Cilium

BPF & eBPF란?

Reference : 링크

기존의 Linux Network Stack의 구조입니다.

리눅스 네트워크 스택의 단점은 복잡하고, 변경에 시간이 걸리고, 레이어를 건너뛰기 어렵습니다.

Cilium_FOSDEM_2020.pdf

https://bit.ly/3EiLsU3

기존의 네트워크 스택은 많은 레이어들이 존재합니다.

https://cilium.io/blog/2020/11/10/ebpf-future-of-networking/

하지만 ebpf를 이용할경우 이러한 과정들을 훨씬 단순하게 가져갈수있다는 eBPF측에서 주장합니다.

기존의 네트워크 스택중 IPtables의 한계점에 대해 살폅보겠습니다.

IPtables 단점

기존 iptables의 문제점

• iptables 업데이트: 모든 규칙을 한 번에 다시 작성하고 업데이트해야 함.
• 규칙 체인의 구조: 규칙을 연결 리스트로 구현하여 모든 연산이 O(n)의 시간이 소요됨.
• ACL 구현 문제: 접근 제어 목록을 순차적으로 처리하여 성능 저하 유발.
• IP 및 포트 기반: 레이어 7 프로토콜을 인식하지 못함.
• 새로운 IP 또는 포트 추가: 새 IP나 포트가 생길 때마다 규칙 추가 및 체인 변경 필요.
• 리소스 사용량: Kubernetes에서 리소스를 많이 소비함.

이러한 문제들은 특히 많은 서비스가 실행되거나 트래픽이 많은 시스템에서 성능 저하를 유발할 수 있음.

Kubernetes의 iptables

• kube-proxy: DNAT iptables 규칙을 사용하여 서비스 및 로드 밸런싱 구현.
• CNI플러그인: 대부분의 CNI플러그인이 네트워크 정책을 위해 iptables를 사용함.

결과적으로 나타나는 현상

• Kubernetes 클러스터를 새로 설치한 후에도 예상보다 많은 iptables 규칙이 생성되며, 동일한 규칙이 6,979번 반복되는 경우도 존재

쿠버네티스에서 IPtables를 채택하여 Service 등을 구현하면서 생긴 원론적인 문제이기도하며, 이전에 다루었던 Service가 갖는 로드밸런싱 부하를 줄이기위해 Endpoint → EndpointSlice 등을 구현하였지만, 여전히 벗어날 수 없는 근본적인 한계점이 있는 상태입니다.

그중에서도 IPtables, Netfilter 방식과 eBFP 방식을 비교한 글을 살펴보겠습니다.

https://blog.naver.com/kangdorr/222593265958

• BPF가 IPtable를 대체하는 과정입니다.

• BPF가 iptables를 대체하는 구조 iptables의 각 체인(prerouting, input, forward, output, postrouting)에서 eBPF가 어떻게 사용되는지를 나타냅니다. 기존 iptables의 필터링 작업이 BPF를 통해 대체되며, eBPF 코드를 삽입하여 필터링과 NAT(Network Address Translation) 작업을 수행합니다. eBPF는 TC(트래픽 컨트롤) 훅을 통해 패킷을 필터링하고 네트워크 장치(가상 또는 물리적)로 보냅니다. 또한 XDP(Express Data Path)를 통해 더 빠르고 효율적으로 패킷을 처리합니다.
• BPF 기반 필터링 아키텍처 필터링이 Netfilter와 결합되어 작동하는 과정을 설명합니다. 패킷이 네트워크 장치로 들어오면, TC 또는 XDP 훅에서 BPF 코드가 적용되어 입력 체인(ingress) 및 출력 체인(egress)으로 분류됩니다. 이 과정에서 연결 추적(Connection Tracking)이 활성화되어, 패킷의 세션 상태가 업데이트되고 세션을 저장하여 추후 패킷 처리가 더 효율적으로 이루어지도록 합니다.
• BPF 기반 Tail Calls BPF 프로그램이 체인을 통해 어떻게 여러 개의 규칙을 순차적으로 처리하는지를 보여줍니다각 BPF 프로그램이 헤더를 파싱하고, IP 및 프로토콜을 확인한 후, 규칙에 맞는 액션을 취하게 됩니다. 이 과정에서 Tail Call 메커니즘을 사용하여 하나의 BPF 프로그램이 끝날 때 다른 BPF 프로그램을 호출함으로써 더욱 복잡한 처리도 가능해집니다. 이러한 방식으로 패킷 처리의 연속성을 유지하면서도 성능 저하 없이 규칙을 적용할 수 있게 됩니다.

요약

• BPF는 iptables의 한계를 보완하며, 더 높은 성능과 유연성을 제공합니다. iptables가 규칙을 순차적으로 처리하는 것과 달리, BPF는 직접 네트워크 스택을 우회하거나 최소화하여 더 빠르게 필터링 및 NAT 작업을 수행할 수 있습니다.
• connection Tracking 및 Tail Calls과 같은 메커니즘을 통해 네트워크 상태를 추적하고, 다단계 규칙을 효과적으로 처리할 수 있습니다.

BPF (Berkeley Packet Filter) kernel hooks : BPF 는 커널에 삽입하여 패킷을 통제(필터링) 할 수 있으며, 각 영역에서 Hook을 통한 접근이 가능합니다.

https://bit.ly/3EiLsU3

그림은 eBPF가 네트워크 스택의 여러 계층에서 추적, 모니터링, 필터링, 성능 최적화 작업을 수행하면서, 각 계층에서 네트워크 스택을 더 빠르고 효율적인 방식으로 대체하거나 보완하는 방식을 설명해줍니다.

extended Berkeley Packet Filter - 링크

• Dynamically program the kernel for efficient networking, observability, tracing, and security

https://ebpf.io/

• BPF(1992년) 를 확장해서 eBPF가 (2014년, Alexei Starovoitov) 가 나왔고, eBPF 를 다양한 영역 (보안, 추적, 네트워킹, 모니터링)에서 활용하기 시작하였습니다.

  

  Extended BPF의 개념으로는

  • 레지스터 확장: 기존 BPF는 소수의 레지스터(누산기 등)만을 사용했지만, eBPF는 10개의 범용 레지스터를 추가하여 더 복잡한 연산이 가능합니다.
  • 스택 공간 증가: BPF는 작은 메모리 공간을 사용했으나, eBPF는 512바이트 스택을 제공해 더 많은 데이터를 처리할 수 있습니다.
  • 맵(Maps): eBPF는 키-값 저장소인 맵을 도입하여 커널과 사용자 공간 간의 데이터 공유 및 복잡한 데이터 관리를 지원합니다.
  • 커널 내부의 가상 머신: eBPF는 커널 내에서 안전하게 실행되는 가상 머신처럼 동작해, 네트워크 필터링 외에도 다양한 용도로 활용될 수 있습니다.

• eBPF is a revolutionary technology that can run sandboxed programs in the Linux kernel without changing kernel source code or loading kernel modules.

  → 커널 내에 (샌드박스 내에서) 자유롭게 프로그래밍하여 적용이 가능합니다.

  

  https://ebpf.io/

  

  • Networking (네트워킹): 커널 공간을 벗어나지 않고 패킷 처리를 가속화하며, 추가적인 프로토콜 파서를 지원해 네트워크 트래픽 처리 및 전달 로직을 쉽게 프로그래밍할 수 있습니다.
  • Observability (관측성): 샘플을 외부로 내보낼 필요 없이 커널 내에서 사용자 정의 메트릭을 수집하고 다양한 소스로부터 가시성 이벤트와 데이터를 생성 및 집계합니다.
  • Tracing & Profiling (추적 및 프로파일링): eBPF 프로그램을 커널 및 사용자 애플리케이션의 프로브 포인트에 연결해 시스템 성능 문제를 해결하기 위한 심층적인 분석 및 진단을 제공합니다.
  • Security (보안): 모든 시스템 호출을 추적하고 패킷 및 소켓 수준의 네트워킹을 이해해 더 나은 제어를 위한 보안 시스템을 만들 수 있습니다.

(참고) XDP(eXpress Data Path) : eBPF based fast data-path

XDP는 eBPF 프로그램을 네트워크 장치 드라이버에 직접 연결하여 네트워크 인터페이스 카드(NIC)에서 패킷을 수신하자마자 즉시 실행됩니다. 패킷이 커널의 나머지 네트워크 스택으로 전달되기 전에 매우 빠르게 처리합니다.

https://www.netronome.com/blog/open-source-packet-filtering-bpf-fosdem19/

• 패킷 차단 비교

• Native XDP 지원 NIC : 아래 Netronome 는 XDP Offload 지원

집에 보유중인 SFP+ 이상 규격의 NIC들은 전부다 Mellanox 제품이라 Driver단에서의 XDP를 지원하네요.

Cillium 소개

• cilium은 eBPF (Berkeley Packet Filter)를 기반의 CNIPlugin으로 Pod Network 환경과 보안을 제공해줍니다

https://isovalent.com/blog/post/migrating-from-metallb-to-cilium/

• Kubernetes와 같은 Linux 컨테이너 관리 플랫폼을 사용하여 배포된 응용 프로그램 서비스 간의 네트워크 및 API 연결을 제공하는 오픈 소스 소프트웨어 입니다.

  

  https://cilium.io/blog/2020/11/10/ebpf-future-of-networking/

Cilium의 eBPF 모드는 추가적인 App 이나 설정 변경 없이 리눅스 커널을 자유롭게 프로그래밍하여 동작시킬 수 있습니다

참조 - 링크

• Kernel Layer에서 동작하는 Bytecode를 안전하게 Kernel에 Loading(injection) 할 수 있다

https://cilium.io/blog/2020/11/10/ebpf-future-of-networking/

Cilium attaches eBPF programs to ingress TC hooks of these links in order to intercept all incoming packets for further processing.

• 수신 NIC 의 ingress TC hooks 을 사용하여 모든 패킷을 가로챕니다.
• Linux TC(Traffic Control) : 커널에서 동작하는 패킷 스케줄러 - 링크

그림의 NIC 에 TC Hooks 에 eBPF 프로그램이 Attach 되어서 실행됩니다

Cilium에는 두가지 네트워크 모드가 존재합니다.

터널 모드(VXLAN, GENEVE), 네이티브 라우팅 모드

• In the tunnel mode, Cilium sets up a number of VXLAN(UDP 8472) or Geneve(UDP 6081) interfaces and forwards traffic over them.
• In the native-routing mode, Cilium does nothing to setup reachability, assuming that it will be provided externally.

https://docs.cilium.io/en/stable/concepts/networking/routing/#native-routing

2021.10월 cilium 는 CNCF 에 Join 되었습니다 - 링크

또한 Google GKE dataplane 과 AWS EKS Anywhere 에 기본 CNI로 cilium 을 사용합니다 - 링크

100% Kube-proxy replacement : iptables 거의 사용하지 않아도 동작, Datapath Optimizations (iptables bypass) - Docs

• 하지만 iptables 기능을 활용하는 일부 동작들은 이슈가 발생할 수 있음, 물론 지속해서 해당 이슈를 해결하고 있음 (예. istio, FHRP/VRRP - 링크)

Calico vs Cilium 성능 비교 - 링크

Cilium 아키텍처

구성요소 - 링크

https://github.com/cilium/cilium

• Cilium Agent : 데몬셋으로 실행, K8S API 설정으로 부터 ‘네트워크 설정, 네트워크 정책, 서비스 부하분산, 모니터링’ 등을 수행하며, eBPF 프로그램을 관리한다.
• Cilium client (CLI) : Cilium 커멘드툴, eBPF maps 에 직접 접속하여 상태를 확인할 수 있다.
• Cilium Operator : K8S 클러스터에 대한 한 번씩 처리해야 하는 작업을 관리.
• Hubble : 네트워크와 보안 모니터링 플랫폼 역할을 하여, ‘Server, Relay, Client, Graphical UI’ 로 구성되어 있다.
• Data Store : Cilium Agent 간의 상태를 저장하고 전파하는 데이터 저장소, 2가지 종류 중 선택(K8S CRDs, Key-Value Store)

eBPF Datapath - 링크

Introduction - 링크

• XDP : 네트워킹 드라이버의 가장 앞 단에서 XDP BPF hook 을 통해서 BPF program 을 트리거되기 때문에, 가능한 최고의 패킷 처리 성능을 제공

  

  https://cilium.io/blog/2020/06/22/cilium-18

  • Prefilter: An XDP program and provides a set of prefilter rules used to filter traffic from the network for best performance.
  • LoadBalancer & NodePort XDP Acceleration

  • XDP-based Standalone Load Balancer : Maglev Consistent Hashing , n-Tuple PCAP Recorder

    Hubble Recorder Demo

• TC (Traffic control) Ingress/Egress
  • Network Interface 에 tc ingress hook 에서 BPF programs 실행된다.
  • 파드와 연결된 veth pair 의 lxc 의 tc ingress hook 에서 BPF programs 실행된다. 노드(호스트)로 in/out 트래픽 모두를 모니터링 및 통제/정책을 적용할 수 있다.
• Socket operations : BPF socket operations program 은 root cgroup 에 연결되며 TCP event(ESTABLISHED) 에서 실행됨
• Socket send/recv : The socket send/recv hook 은 TCP socket 의 모든 송수신 작업에서 실행, hook 에서 검사/삭제/리다이렉션을 할 수 있다
• Endpoint Policy: 정책에 따라 패킷을 차단/전달하거나, 서비스로 전달하거나, L7 정책 전달 할 수 있다.
  • the Cilium datapath responsible for mapping packets to identities and enforcing L3 and L4 policies.
• Service: 모든 패킷의 목적지 IP/Port 의 map 조회 시 일치하면 L3/L4 endpoint 로 전달하며, Service block 는 모든 인터페이스의 TC ingress hook 에서 동작할 수 있다.
• L3 Encryption, Socket Layer Enforcement : skip~
• L7 Policy: The L7 Policy object redirect proxy traffic to a Cilium userspace proxy instance. Cilium uses an Envoy instance as its userspace proxy. Envoy will then either forward the traffic or generate appropriate reject messages based on the configured L7 policy.

Life of a Packet - 링크

Endpoint to Endpoint : 그림처럼 L7 정책 시에는 커널 hookpoint 와 Userspace Proxy 사용으로 성능이 조금 떨어질 수 있다

Egress from Endpoint

Ingress to Endpoint

eBPF Maps - 링크

• 모든 eBPF Map 은 상한 용량이 있으며, limit 관련 여러 옵션들이 있다.

eBPF Map

• kube-proxy 는 리눅스 코어에 따라 CT table 최대 수가 결정되며, Cilium 은 BPF Maps 이라는 자체 연결 추적 테이블을 가지고 메모리에 따라 최대 수가 결정됨

Iptables Usage - 링크

• 커널 버전이 낮을 경우 iptables 동작으로 구현 될 수 있다. 혹은 cilium 미동작(장애 등 문제) 시, 트래픽 처리 보완 시.

Cilium Installation

배포

Cilium 설치 정보(w/Helm) 및 확인 - Docs

#
helm repo add cilium https://helm.cilium.io/
helm repo update

echo "
k8sServiceHost: 192.168.10.10
k8sServicePort: 6443
debug:
  enabled: true
rollOutCiliumPods: true
routingMode: native
autoDirectNodeRoutes: true
bpf:
  masquerade: true
  hostRouting: true
endpointRoutes:
  enabled: true
ipam:
  mode: kubernetes
k8s:
  requireIPv4PodCIDR: true
kubeProxyReplacement: true
ipv4NativeRoutingCIDR: 192.168.0.0/16
installNoConntrackIptablesRules: true
hubble:
  ui:
    enabled: true
  relay:
    enabled: true
  metrics:
    enableOpenMetrics: true
    enabled:
      - dns:query;ignoreAAAA
      - drop
      - tcp
      - flow
      - port-distribution
      - icmp
      - httpV2:exemplars=true;labelsContext=source_ip\,source_namespace\,source_workload\,destination_ip\,destination_namespace\,destination_workload\,traffic_direction
prometheus:
  enabled: true
operator:
  prometheus:
    enabled: true
  replicas: 1
" > cilium-values.yaml 
helm upgrade --install cilium cilium/cilium --version 1.16.3 --namespace kube-system -f cilium-values.yaml

## 주요 파라미터 설명
debug.enabled=true # cilium 파드에 로그 레벨을 debug 설정
autoDirectNodeRoutes=true # 동일 대역 내의 노드들 끼리는 상대 노드의 podCIDR 대역의 라우팅이 자동으로 설정
endpointRoutes.enabled=true # 호스트에 endpoint(파드)별 개별 라우팅 설정
hubble.relay.enabled=true --set hubble.ui.enabled=true # hubble 활성화
ipam.mode=kubernetes --set k8s.requireIPv4PodCIDR=true # k8s IPAM 활용
kubeProxyReplacement=true # kube-proxy 없이 (최대한) 대처할수 있수 있게
ipv4NativeRoutingCIDR=192.168.0.0/16 # 해당 대역과 통신 시 IP Masq 하지 않음, 보통 사내망 대역을 지정
operator.replicas=1 # cilium-operator 파드 기본 1개
enableIPv4Masquerade=true --set bpf.masquerade=true # 파드를 위한 Masquerade , 추가로 Masquerade 을 BPF 로 처리 >> enableIPv4Masquerade=true 인 상태에서 추가로 bpf.masquerade=true 적용이 가능*

kubectl get ciliumnodes # cilium_host 인터페이스의 IP 확인
kubectl get ciliumendpoints -A

# Native XDP 지원 NIC 확인 : https://docs.cilium.io/en/stable/bpf/progtypes/#xdp-drivers
ethtool -i ens5
driver: ena
version: 6.8.0-1015-aws

# https://docs.cilium.io/en/stable/operations/performance/tuning/#bypass-iptables-connection-tracking
watch -d kubectl get pod -A # 모니터링
helm upgrade cilium cilium/cilium --namespace kube-system --reuse-values --set installNoConntrackIptablesRules=true

# 확인: 기존 raw 에 아래 rule 추가 확인
iptables -t raw -S | grep notrack

Cilium CLI 설치 : inspect the state of a Cilium installation, and enable/disable various features (e.g. clustermesh, Hubble) - Link

# Cilium CLI 설치
CILIUM_CLI_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/cilium-cli/main/stable.txt)
CLI_ARCH=amd64
if [ "$(uname -m)" = "aarch64" ]; then CLI_ARCH=arm64; fi
curl -L --fail --remote-name-all https://github.com/cilium/cilium-cli/releases/download/${CILIUM_CLI_VERSION}/cilium-linux-${CLI_ARCH}.tar.gz{,.sha256sum}
sha256sum --check cilium-linux-${CLI_ARCH}.tar.gz.sha256sum
sudo tar xzvfC cilium-linux-${CLI_ARCH}.tar.gz /usr/local/bin
rm cilium-linux-${CLI_ARCH}.tar.gz{,.sha256sum}

# 확인
cilium status --wait
cilium config view

# cilium 데몬셋 파드 내에서 cilium 명령어로 상태 확인
export CILIUMPOD0=$(kubectl get -l k8s-app=cilium pods -n kube-system --field-selector spec.nodeName=k8s-s  -o jsonpath='{.items[0].metadata.name}')
alias c0="kubectl exec -it $CILIUMPOD0 -n kube-system -c cilium-agent -- cilium"
c0 status --verbose

# Native Routing 확인 : # 192.168.0.0/16 대역은 IP Masq 없이 라우팅
c0 status | grep KubeProxyReplacement
# enableIPv4Masquerade=true(기본값) , bpf.masquerade=true 확인
cilium config view | egrep 'enable-ipv4-masquerade|enable-bpf-masquerade'

c0 status --verbose | grep Masquerading

# Configure the eBPF-based ip-masq-agent
# https://docs.cilium.io/en/stable/network/concepts/masquerading/
helm upgrade cilium cilium/cilium --namespace kube-system --reuse-values --set ipMasqAgent.enabled=true

#
cilium config view | grep -i masq
enable-bpf-masquerade                             true
enable-ip-masq-agent                              true
...

export CILIUMPOD0=$(kubectl get -l k8s-app=cilium pods -n kube-system --field-selector spec.nodeName=k8s-s  -o jsonpath='{.items[0].metadata.name}')
alias c0="kubectl exec -it $CILIUMPOD0 -n kube-system -c cilium-agent -- cilium"
c0 status --verbose | grep Masquerading
kubectl get cm -n kube-system cilium-config -o yaml  | grep ip-masq

⁉️ Cilium Native Routing 모드에서 노드가 서로 다른 네트워크 대역을 가질때 라우팅 처리는 어떻게 될까요?

</aside>

Cilium 기본 정보

변수 & 단축키

# cilium 파드 이름
export CILIUMPOD0=$(kubectl get -l k8s-app=cilium pods -n kube-system --field-selector spec.nodeName=k8s-s  -o jsonpath='{.items[0].metadata.name}')
export CILIUMPOD1=$(kubectl get -l k8s-app=cilium pods -n kube-system --field-selector spec.nodeName=k8s-w1 -o jsonpath='{.items[0].metadata.name}')
export CILIUMPOD2=$(kubectl get -l k8s-app=cilium pods -n kube-system --field-selector spec.nodeName=k8s-w2 -o jsonpath='{.items[0].metadata.name}')

# 단축키(alias) 지정
alias c0="kubectl exec -it $CILIUMPOD0 -n kube-system -c cilium-agent -- cilium"
alias c1="kubectl exec -it $CILIUMPOD1 -n kube-system -c cilium-agent -- cilium"
alias c2="kubectl exec -it $CILIUMPOD2 -n kube-system -c cilium-agent -- cilium"

alias c0bpf="kubectl exec -it $CILIUMPOD0 -n kube-system -c cilium-agent -- bpftool"
alias c1bpf="kubectl exec -it $CILIUMPOD1 -n kube-system -c cilium-agent -- bpftool"
alias c2bpf="kubectl exec -it $CILIUMPOD2 -n kube-system -c cilium-agent -- bpftool"

# Hubble UI 웹 접속
kubectl patch -n kube-system svc hubble-ui -p '{"spec": {"type": "NodePort"}}'
HubbleUiNodePort=$(kubectl get svc -n kube-system hubble-ui -o jsonpath={.spec.ports[0].nodePort})
echo -e "Hubble UI URL = http://$(curl -s ipinfo.io/ip):$HubbleUiNodePort"

자주 쓰는 Cilium CLI 명령어

Isovalent - Cilium Cheat Sheet.pdf

# cilium 파드 확인
kubectl get pod -n kube-system -l k8s-app=cilium -owide

# cilium 파드 재시작
kubectl -n kube-system rollout restart ds/cilium
혹은
kubectl delete pod -n kube-system -l k8s-app=cilium

# cilium 설정 정보 확인
cilium config view

# cilium 파드의 cilium 상태 확인
c0 status --verbose

# cilium 엔드포인트 확인
kubectl get ciliumendpoints -A
c0 endpoint list
c0 bpf endpoint list
c0 map get cilium_lxc
c0 ip list

# Manage the IPCache mappings for IP/CIDR <-> Identity
c0 bpf ipcache list

# Service/NAT List 확인
c0 service list
c0 bpf lb list
c0 bpf lb list --revnat
c0 bpf nat list

# List all open BPF maps
c0 map list
c0 map list --verbose

# List contents of a policy BPF map : Dump all policy maps
c0 bpf policy get --all
c0 bpf policy get --all -n

# cilium monitor
c0 monitor -v
c0 monitor -v --type l7

Cilium 기본 정보 확인

# cilium 버전 확인
cilium version

# cilium 상태 확인
cilium status

# kube-proxy 파드 확인 >> 없다!
kubectl get pod -A

# cilium 설정 정보 확인
kubectl get cm -n kube-system cilium-config -o yaml
cilium config view

# ciliumnodes(cn) 정보 확인
kubectl get cn
kubectl get cn k8s-m -o yaml

# 노드별 파드 대역 확인
kubectl get ciliumnodes -o yaml | grep podCIDRs -A1

# cilium 파드 확인
kubectl get pod -n kube-system -l k8s-app=cilium -owide

# cilium 엔드포인트 확인
kubectl get ciliumendpoints.cilium.io -A

다양한 명령어들로 실제 CNI가 동작하는 범위와 동작하는 설정들에 대해 조회가 가능합니다.

네트워크 기본 정보 확인 : k8s-w1/w2 에 SSH 접속 후 ip -c link/route 정보 확인

http://arthurchiao.art/blog/ctrip-network-arch-evolution/

# 네트워크 인터페이스 정보 확인
ip -br -c link
ip -br -c addr
--------------------------------------------
# cilium_net 과 cilium_host 는 veth peer 관계이며, cilium_host 는 파드의 GW IP 주소로 지정되며 32bit 이다
ip -c addr show cilium_net ; ip -c addr show cilium_host

# proxy arp 는 disable(0) 상태이며, 파드와 연결된 lxc 도 모두 0 이다
# 파드의 32bit ip의 gw 가 각각 연결된 veth 인터페이스의 mac 으로 cilium_host 의 IP/MAC 응답을 처리한다, 어떻게 동작이 되는걸까요? >> eBPF program!!!
cat /proc/sys/net/ipv4/conf/cilium_net/proxy_arp
cat /proc/sys/net/ipv4/conf/cilium_host/proxy_arp

# lxc_health 인터페이스는 veth 로 cilium(NET NS 0, 호스트와 다름)과 veth pair 이다 - [링크](https://arthurchiao.art/blog/cilium-code-health-probe/)
# cilium 인터페이스에 파드 IP가 할당되어 있으며, cilium-health-responder 로 동작한다
lsns -t net

• cilium Container Networking Control Flow - Link

Hubble UI & CLI

Observability

Hubble을 통한 네트워크 가시성

Hubble 네트워크 관찰 기능 (문서 링크)

• Hubble 관찰 기능 설정 (문서 링크)
• CLI를 통한 네트워크 흐름 확인 (문서 링크)
• 서비스 맵 & Hubble UI (문서 링크)
• Hubble Exporter 설정 (문서 링크)
• TLS 구성 (문서 링크)

Prometheus & Grafana

Prometheus 및 Grafana 실행 (문서 링크)

모니터링 및 메트릭 (문서 링크)

Layer 7 프로토콜 가시성 (문서 링크)

Hubble을 활용한 네트워크 가시성 및 보안

Hubble을 통한 네트워크 보안 활용 (3부): Hubble 데이터를 활용한 네트워크 보안 (블로그 링크)

Hubble을 통한 네트워크 가시성 활용 (2부): 네트워크 가시성을 위한 Hubble 활용 (블로그 링크)

Hubble 및 Cilium 소개 (1부): Cilium 및 Hubble 소개 (블로그 링크)

Hubble 소개 : 통신 및 서비스와 네트워킹 인프라의 동작에 대한 심층적인 가시성을 완전히 투명한 방식으로 제공하는 관찰성을 제공 - Blog

https://cilium.io/blog/2019/11/19/announcing-hubble

• Cluster-wide observability with Hubble Relay

https://cilium.io/blog/2020/06/22/cilium-18

• 서비스 종속성 그래프

• 다양한 메트릭(네트워크, HTTP, DNS 등) 모니터링

• 통제 예시
  • Allow all HTTP requests with method GET and path /public/.*. Deny all other requests.
  • Allow service1 to produce on Kafka topic topic1 and service2 to consume on topic1. Reject all other Kafka messages.
  • Require the HTTP header X-Token: [0-9]+ to be present in all REST calls.

Hubble UI/CLI 접근 및 확인 - Docs

# 확인
cilium status

# UI 파드 정보 확인
kubectl get pod -n kube-system -l k8s-app=hubble-ui -o wide

# Hubble UI 웹 접속
kubectl patch -n kube-system svc hubble-ui -p '{"spec": {"type": "NodePort"}}'
HubbleUiNodePort=$(kubectl get svc -n kube-system hubble-ui -o jsonpath={.spec.ports[0].nodePort})
echo -e "Hubble UI URL = http://$(curl -s ipinfo.io/ip):$HubbleUiNodePort"

## Service NodePort 생성 후 아래 정보 확인!
iptables -t nat -S
conntrack -L
conntrack -L |grep -v 2379

# Install Hubble Client
HUBBLE_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/hubble/master/stable.txt)
HUBBLE_ARCH=amd64
if [ "$(uname -m)" = "aarch64" ]; then HUBBLE_ARCH=arm64; fi
curl -L --fail --remote-name-all https://github.com/cilium/hubble/releases/download/$HUBBLE_VERSION/hubble-linux-${HUBBLE_ARCH}.tar.gz{,.sha256sum}
sha256sum --check hubble-linux-${HUBBLE_ARCH}.tar.gz.sha256sum
sudo tar xzvfC hubble-linux-${HUBBLE_ARCH}.tar.gz /usr/local/bin
rm hubble-linux-${HUBBLE_ARCH}.tar.gz{,.sha256sum}

# Hubble API Access : localhost TCP 4245 Relay 를 통해 접근, observe 를 통해서 flow 쿼리 확인 가능!
cilium hubble port-forward &

# CLI 로 Hubble API 상태 확인
hubble status

# query the flow API and look for flows
hubble observe
# hubble observe --pod netpod
# hubble observe --namespace galaxy --http-method POST --http-path /v1/request-landing
# hubble observe --pod deathstar --protocol http
# hubble observe --pod deathstar --verdict DROPPED

자가 테스트 cilium connectivity test → Hubble UI 접속 후 cilium-test-Y 네임스페이스 선택

해당 UI 하위부분에 test 중인 네트워크 정보들이 보입니다.

kubectl delete ns cilium-test-Y

© 2024 mont kim   •  Powered by Soopr   •  Theme  Moonwalk