CloudNet 가시다님이 진행하는 KANS 스터디 8주차 정리입니다.

4. 서비스 통신 확인

▶ Socket-Based LoadBalancing 소개

  • pod1안에서 동작하는 앱이 connect() 시스템콜을 이용하여 소켓을 연결할 때 목적지 주소가 서비스 주소(10.10.8.55)이면 소켓의 목적지 주소를 바로 백엔드 주소(10.0.0.31)로 설정한다. 이후 앱에서 해당 소켓을 통해 보내는 모든 패킷의 목적지 주소는 이미 백엔드 주소(10.0.0.31)로 설정되어 있기 때문에 중간에 DNAT 변환 및 역변환 과정이 필요없어진다.
    • destination NAT translation happens as the syscall level, before the packet is even built by the kernel.

  • Socket operations : BPF socket operations program은 root cgroup 에 연결되며 TCP event(ESTABILSHED)에서 실행한다.
  • Socket send/recv : The Socket send/recv hook은 TCP socket의 모든 송수신 작업에서 실행, hook에서 검사/삭제 리다이렉션을 할 수 있다

  • connect()와 sendto() 소켓 함수에 연결된 프로그램(connect4, sendmsg4)에서는 소켓의 목적지 주소를 백엔드 주소와 포트로 변환하고, cilium_lb4_backends 맵에 백엔드 주소와 포트를 등록해놓는다. 이후 recvmsg() 소켓 함수에 연결된 프로그램(recvmsg4)에서는 cilium_lb4_reverse_nat 맵을 이용해서 목적지 주소와 포트를 다시 서비스 주소와 포트로 변환함.

 

▶ 서비스 생성 및 접속 확인 : 파드 내에서 바로 DNAT!

  • 서비스 접속 확인

서비스 생성 확인
tcpdump 확인 시 클러스터 IP 확인 불가
서비스 정보 확인
서비스 정보 확인
BPF maps

▶ Socket-Based LoadBalancing 관련 설정값 확인 및 Cgroup 관련 정보 확인

Socket-Based LoadBalancing 관련 설정들 확인
cgroup root 경로 확인
eBPF cgroup 확인 : Socket based LB와 관련

 

▶ strace 시스템 콜 트레이싱 도구를 통해 파드 내에서 동작 확인

syscall 호출 확인
cluster IP 확인

 

IP가 netpod IP로 변경되어서 확인 가능

 

 

5. Running Prometheus & Grafana

파드와 서비스 확인
Grafana 웹 접속 확인
Prometheus 웹 접속 확인

 

6. Direct Server Return (DSR)

▶DSR(Direct Server Return) 소개

  • 기본 SNAT 사용 시 : kube-proxy 환경에서 NodePort 접속 시

  • DSR 사용 시

  • Cilium XDP DSR with PIP Encapsulation and L4 DNAT

▶ DSR 설정

  • 반드시 Tunnel mode가 Disabled -> 즉 Native Routing 모드에서만 DSR 동작
  • Ubuntu local64 LTS (Linux 5.4.0-99-generic)는 DSR 동작 불가
  • TCP는 DSR, UDP는 SNAT으로 동작하는 Hybrid DSR 모드도 있음

▶동작

  • DSR 사용 시 ip 옵션 헤더("목적지포트 +? +목적지IP')에 최초 접속한 노드의 ip 정보를 담아서 타겟 노드로 전달한다
  • 타켓 노드는 전달받은 IP 옵션 헤더에 저장된 원래의 목적지 주소를 cilium_snat_v4_external 맵에 저장해놓고, conntrack 맵에 변환 정보를 추가한다
  • 이후 파드가 응답 패킷을 만들어 전송하면 파드의 veth LXC의 bpf_lxc.c #from-container에서, conntrack 맵에 저장된 정보를 이용하여 cilium_snat_v4_external 맵에서 필요한 정보를 가져와서 응답 패킷의 출발지 주소를 원래 클라이언트가 접속한 주소로 변환한다. 이러한 과정을 통해 클라이언트는 패킷을 보낸 주소 그대로 패킷을 받게 되는 것임!

7. Network Policy (L3, L4, L7)

▶ Security

▶ Cilium Security intro : Cilium provides security on multiple levels

  • ID 기반 Identity-Based : Connectivity policies between endpoints (Layer 3), e.g. any endpoint with label role=frontend can connect to any endpoint with label role=backend.

  • 포트 기반 Restriction of accessible ports (Layer 4) for both incoming and outgoing connections, e.g. endpoint with label role=ffrontend can only make outgoing connections on port 443 (https) and endpoint role=backend can only accept connections on port 443 (https).
  • 애플리케이션 (HTTP) 기반 Fine grained access control on application protocol level to secure HTTP and remote procedure call (RPC) protocols, e.g the endpoint with label role=frontend can only perform the REST API call GET /userdata/[0-9]+, all other API interactions with role=backend are restricted.
    • Proxy Injection : Evnoy
      • Cilium is capable of transparently injecting a Layer 4 proxy into any network connection. This is used as the foundation to enforce higher level network policies (see DNS based and Layer 7 Examples).

▶ Network Policy 관련 eBPF Datapath

  • Prefilter : An XDP Program and provides a set of prefilter rules used to filter traffic from the network for best performance.
  • Endpoint Policy : 정책에 따라 패킷을 차단/전달하거나, 서비스로 전달하거나 L7로 정책 전달 할 수 있다
    • the Cilium datapath responsible for mapping packets to identities and enforcing L3 and L4 policies.
  • 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 genrate appropriate reject messages based on the configured L7 policy.
    -> L7 정책은 커널 hookpoint와 Userspace Proxy 사용으로 성능이 조금 떨어질 수 있다

▶ Deploy the Demo Application

  • 디플로이먼트(웹 서버, deathstar, replicas 2), 파드(xwing, tiefighter), 서비스(ClusterIP, service/deathstar)

파드 라벨 확인
cilium endpoint 확인
데스스타 SVC 접속하여 웹 파드 연결 확인

▶ Identity-Aware and HTTP-Aware Policy Enforcement Apply an L3/L4 Policy

  • Cilium에서는 Endpoint IP 대신, 파드의 Labels(라벨)을 사용(기준)하여 보안 정책을 적용한다
  • IP/Port 필터링을 L3/L4 네트워크 정책이라고 한다
  • 'org=empire' Labels(라벨) 부착된 파드만 허용
  • Cilium performs stateful connection tracking 이므로 리턴 트래픽은 자동으로 허용됨

파드 curl 접속
Hubble UI에서 dropped 확인
hubble cli 모니터링
endpoint list에서 정책 적용 확인(Enabled일 경우 정책 적용)

▶ Identity-Aware Policy Enforcement Apply and Test HTTP-aware L7 policy

데스스타 SVC(Cluster IP) 접속
정책 확인
접근 테스트
Hubble UI에서 확인
hubble cli에 차단 로그 확인

 

8. Bandwidth Manager

▶ Bandwidth Manager : Bandwidth and Latency Optimization

  • bandwidth manager to optimize TCP and UDP workloads and efficiently rate limit individual Pods - EDT (Earliest Departure Time)와 eBPF 사용
  • Kubernetes.io/egress-bandwidth Pod annotation which is enforced on egress at the native host networking devices
  • direct routing mode, tunneling mode 둘다 지원
  • Limitations : L7 Cilium Network Policies

▶ 설정 및 확인

인터페이스 tc qdisc 확인
적용 확인
egress bandwidth limitation 동작하는 인터페이스 확인
인터페이스 tc qdisc 확인 : 설정 전후 옵션값들이 상당히 추가

▶ 동작 및 확인

egress BW 제한 정보 확인
egress BW 제한이 설정된 파드가 있는 cilium pod에서 제한 정보 확인
egress traffic of the netperf-server Pod has been limited to 10Mbit per second
5M 제한 설정
5M 제한 설정 후 테스트
20M 제한 설정 후 테스트

9. L2 Announcements / L2 Aware LB (Beta)

  • L2 Announcements는 로컬 영역 네트워크에서 서비스를 표시하고 도달 가능하게 만드는 기능입니다. 이 기능은 주로 사무실 또는 캠퍼스 네트워크와 같이 BGP 기반 라우팅이 없는 네트워크 내에서 온프레미스 배포를 위해 고안되었습니다.
  • 이 기능을 사용하면 ExternalIP 및/또는 LoadBalancer IP에 대한 ARP 쿼리에 응답합니다. 이러한 IP는 여러 노드의 가상 IP(네트워크 장치에 설치되지 않음)이므로 각 서비스에 대해 한 번에 한 노드가 ARP 쿼리에 응답하고 MAC 주소로 응답합니다. 이 노드는 서비스 로드 밸런싱 기능으로 로드 밸런싱을 수행하여 북쪽/남쪽 로드 밸런서 역할을 합니다.
  • NodePort 서비스에 비해 이 기능의 장점은 각 서비스가 고유한 IP를 사용할 수 있으므로 여러 서비스가 동일한 포트 번호를 사용할 수 있다는 것이다. NodePort를 사용할 때 트래픽을 보낼 호스트를 결정하는 것은 클라이언트에게 달려있으며 노드가 다운되면 IP+port 콤보를 사용할 수 없게 됩니다. L2 공지를 사용하면 서비스 VIP가 다른 노드로 간단히 마이그레이션되고 계속 작동한다.

▶설정 및 확인

설정 확인
ciliumL2AnnouncementPolicy 생성 후 확인
Cilium ip pool 조회

  • 테스트용 파드, 서비스 생성

접속 확인
curl 접속 확인

 

10. Cilium Egress Gateway

  • Egress Gateway
    : 송신 게이트웨이 기능은  pod에서 시작되어 특정 클러스터 외부 CIDR로 향하는 모든 IPv4 연결을 특정 노드를 통해 라우팅한다.
    Egress Gateway 기능이 활성화되고 Egress Gateway 정책이 적용되면 클러스터를 떠나는 일치하는 패킷은 게이트웨이 노드와 연관된 선택되고 예측 가능한 IP로 위장된다.
  • Egress Gateway Advanced Troubleshooting
    - SNAT 연결 제한 : egress-gateway가 소수의 원격 엔드포인트로 트래픽을 위장하는 데 사용되는 사용 사례에서 Cilium의 NAT 매핑이 원격 엔드포인트당 할당할 수 있는 소스 IP의 최대 수를 초과하여 문제가 발생할 수 있다. 이는 기존 연결에 문제를 일으킬 수 있는데, 새로운 연결을 수용하기 위해 오래된 연결이 자동으로 제거되기 때문이다.

▶ Egress IP Gateway 소개

  • 특정 파드들을 특정 Egress GW(특정 IP)를 고정으로 외부(혹은 특정 대역)와 통신을 설정할 수 있다
  • Egress IP Gateway를 활성화하고 Egress SNAT 정책 설정

11. LoadBalancer IP Address Management (LB IPAM)

▶ BGP(MetalLB) for LoadBalancer VIP

  • Cilium v1.10부터는 별도의 추가 구성요소 없이, 서비스(Service)의 IP를 외부에 BGP로 광고할 수 있다 (MetalLB가 Cilium 파드에 포함됨)
    • Now, services are able to be reached externally from traffic outside of the cluster, without any additional components.
  • Cilium v1.11 부터는 파드의  CIDR를 Egress IP Gateway를 통해 BGP로 광고가 가능하다
    • BGP Pod CIDR Announcement : Advertise PodCIDR IP routes to your network using BGP.

12. IPSec, WireGuard

  • Transparent Encryption
    • IPsec Transparent Encryption
      : Cilium에서 관리하는 엔드포인트 간의 모든 트래픽과 Cilium에서 관리하는 호스트 트래픽이 IPsec을 사용하여 암호화된다.
    • WireGuard Transparent Encryption
      : Cilium에서 WireGuard가 활성화되면 각 클러스터 노드에서 실행되는 에이전트는 클러스터의 다른 모든 알려진 노드와 해당 노드 간에 안전한 WireGuard 터널을 설정한다.
      : 각 노드는 자체 암호화 키 쌍을 자동으로 생성하고 network.cilium.io/wg-pub-key Kubernetes CiliumNode 사용자 지정 리소스 개체의 주석을 통해 공개 키를 배포한다. 그런 다음 각 노드의 공개 키는 다른 노드에서 해당 노드에서 실행되는 Cilium 관리 엔드포인트와의 트래픽을 해독하고 암호화는데 사용된다.

▶ Transparent Encryption with WireGuard

  • 한 노드 내에서 파드(엔드포인트)간 통신 시에는 암호화 되지 않는다.
  • The WireGuard tunnel endpoint is exposed on UDP port 51871 on each node
  • Limitations : L7 policy enforcement and visibility, eBPF-based host routing

13. Tunnel mode (VXLAN, GENEVE)

  • VXLAN (Virtual Extensible LAN) : 물리적인 제한 없이 대규모의 논리적인 네트워크를 구축할 수 있도록 해주는 기술
  • VXLAN 특징
    • Overlay Network : 물리적인 네트워크 위에 논리적인 네트워크를 덧씌워 구축
    • UDP 캡슐화 : 이더넷 프레임을 UDP 패킷으로 캡슐화하여 전송
    • VNI (VXLAN Network Identifier) :  각 논리적인 네트워크를 식별하기 위한 고유한 값
  • 장점
    • 확장성 : VLAN의 제한된 네트워크 수를 극복하고 대규모 네트워크를 구성
    • 유연성 : 다양한 네트워크 토폴로지를 구현
    • 가상화 : 물리적인 네트워크와 논리적인 네트워크를 분리하여 관리
  • 단점
    • 오버헤드 : UDP 캡슐화로 인해 약간의 오버헤드가 발생할 수 있다
    • 복잡성 : 구성 및 관리가 다소 복잡
  • GENEVE(Generic Network Virtualization Encapsulation) : VXLAN의 단점을 보완하고 더욱 유연한 네트워크 가상화를 지원
  • GENEVE 특징
    • 확장성 : VXLAN과 동일하게 대규모 네트워크를 구성
    • 유연성 : 다양한 네트워크 프로토콜과 데이터 형식을 캡슐화
    • 확장성 : 새로운 기능을 추가하기 쉽도록 설계
  • 장점
    • 범용성 : VXLAN뿐만 아니라 NVGRE, STT 등 다양한 네트워크 가상화 기술을 지원
    • 확장성 : 미래의 네트워크 요구사항에 유연하게 대응
  • 단점
    • 복잡성 : VXLAN 보다 더 복잡한 구성이 필요

14. Service Mesh (+Ingress, GatewayAPI)

▶ Service Mesh

 

▶ Getting Started Using Istio & eBPF-Enabled Network Efficiency

  • Network packets travel through a much shorter path in the eBPF-accelerated, sidecarless proxy model for service mesh

https://cilium.io/blog/2021/12/01/cilium-service-mesh-beta

  • Istio Support with Kube-Proxy-Replacement

https://isovalent.com/blog/post/2021-12-release-111

15. Cilium XDP

  • XDP(eXpress Data path)란?
    • 초고속 패킷 처리 : 네트워크 인터페이스 카드(NIC)에서 패킷이 도착하자마자 커널 공간에서 바로 처리하는 기술. 이는 기존의 소프트웨어 스택을 거치는 방식보다 훨씬 빠른 처리 속도를 보장한다
    • 커널 수준의 유연성 : 사용자 정의 프로그램을 통해 패킷을 필터링, 수정, 또는 드롭하는 등 다양한 작업을 수행할 수 있다
    • eBPF와의 결합 : eBPF 기술과 결합되어 더욱 강력한 기능을 제공한다. eBPF는 커널 내에서 안전하게 실행되는 프로그램을 작성할 수 있도록 해주는 기술이다.
  • Cilium이란?
    • 컨테이너 네트워킹 : Kubernetes와 같은 컨테이너 환경에서 안전하고 효율적인 네트워킹을 제공하는 오픈 소스 프로젝트이다.
    • eBPF 기반 : Cilium은 eBPF를 활용하여 컨테이너 간 통신, 서비스 디스커버리, 네트워크 정책 등 다양한 기능을 구현한다
    • 고성능, 고가용성 : XDP와 eBPF 를 통해 높은 성능과가용성을 보장한다. 

16. Maglev Load Balancing

▶ Meglev Load Balancing 소개

  • 대규모 병렬 L4 로드 밸런싱 환경에서 L4 클러스터링 및 분산 컨시스턴트 해싱을 통해 장애 허용 및 확장

https://ziwon.github.io/post/modern-network-load-balancing-and-proxying/

 

  • kube-proxy 또는 Cilium에서 구현한 Kubernetes 서비스 부하 분산은 서비스 백엔드를 무작위로 선택하고 트래픽이 백엔드에 고정되도록 한다. 
    • 문제점 : 노드 장애가 발생할 경우 업스트림 부하 분산기가 백엔드가 현재 연결을 제공하는 이전 컨텍스트가 없는 다른 부하 분산 노드를 선택

https://cilium.io/blog/2020/11/10/cilium-19/