cat <<EOF | kubectl create -f -
apiVersion: v1
kind: Pod
metadata:
name: netpod
labels:
app: netpod
spec:
nodeName: k8s-m
containers:
- name: netshoot-pod
image: nicolaka/netshoot
command: ["tail"]
args: ["-f", "/dev/null"]
terminationGracePeriodSeconds: 0
---
apiVersion: v1
kind: Pod
metadata:
name: webpod1
labels:
app: webpod
spec:
nodeName: k8s-w1
containers:
- name: container
image: traefik/whoami
terminationGracePeriodSeconds: 0
---
apiVersion: v1
kind: Service
metadata:
name: svc1
spec:
ports:
- name: svc1-webport
port: 80
targetPort: 80
selector:
app: webpod
type: NodePort
EOF
====================
# 파드 서비스 정보
kubectl get pod -o wide
kubectl get svc svc1
# map list 확인
c0 map list --verbose
c1 map list --verbose
동작 : haruband(한글) - 링크Magic!*https://arthurchiao.art/blog/k8s-l4lb/
DSR 사용 시 ip 옵션 헤더('목적지포트 + ? + 목적지IP' )에 최초 접속한 노드의 ip 정보를 담아서 타겟 노드로 전달한다.
타켓 노드는 전달받은 IP 옵션 헤더에 저장된 원래의 목적지 주소를 cilium_snat_v4_external 맵에 저장해놓고, conntrack 맵에 변환 정보를 추가한다.
이후 파드가 응답 패킷을 만들어 전송하면 파드의 veth LXC의 bpf_lxc.c #from-container 에서, conntrack 맵에 저장된 정보를 이용하여 cilium_snat_v4_external 맵에서 필요한 정보를 가져와서 응답 패킷의 출발지 주소를 원래 클라이언트가 접속한 주소로 변환한다. 이러한 과정을 통해 클라이언트는 패킷을 보낸 주소 그대로 패킷을 받게 되는 것이다. Magic!
또한, 클라이언트 IP(접속자 IP)는 파드까지 보존되어서 도달한다.
# 서비스(NodePort)를 확인
kubectl get svc svc1 -o jsonpath='{.spec.ports[0].nodePort}';echo
32465
------------------------------------------------------------------------------
# k8s-pc 나 자신의 PC 에서 Service(NodePort) 접속 트래픽 발생
SVCNPORT=$(kubectl get svc svc1 -o jsonpath='{.spec.ports[0].nodePort}')
curl -s k8s-m:$SVCNPORT
curl -s k8s-m:$SVCNPORT | grep Hostname
# k8s-pc 나 자신의 PC 에서 지속적으로 접속 트래픽 발생
while true; do curl -s k8s-m:$SVCNPORT | grep Hostname;echo "-----";sleep 1;done
------------------------------------------------------------------------------
# 모니터링 : 워커노드에 최초 TCP SYN 에 IP옵션 헤더값 포함된 패킷 확인! >> 아래 처럼 출력된 IPv4Option 에 맨 뒤부터 읽으면 된다!
c0 monitor # 없다!
c1 monitor -vv
------------------------------------------------------------------------------
level=info msg="Initializing dissection cache..." subsys=monitor
Ethernet {Contents=[..14..] Payload=[..70..] SrcMAC=82:dc:d0:66:f2:30 DstMAC=6a:f1:5e:fd:53:8b EthernetType=IPv4 Length=0}
IPv4 {Contents=[..28..] Payload=[..40..] Version=4 IHL=7 TOS=0 Length=68 Id=28665 Flags=DF FragOffset=0 TTL=62 Protocol=TCP Checksum=47859 SrcIP=192.168.20.100 DstIP=172.16.1.97 Options=[IPv4Option(154:[64 118 10 10 168 192])] Padding=[]}
TCP {Contents=[..40..] Payload=[] SrcPort=59364 DstPort=80(http) Seq=2356875422 Ack=0 DataOffset=10 FIN=false SYN=true RST=false PSH=false ACK=false URG=false ECE=false CWR=false NS=false Window=64240 Checksum=21511 Urgent=0 Options=[..5..] Padding=[]}
CPU 00: MARK 0x0 FROM 2375 to-endpoint: 82 bytes (82 captured), state new, interface lxc8c5f8079ec7eidentity world->29901, orig-ip 192.168.20.100, to endpoint 2375
------------------------------------------------------------------------------
# 패킷 덤프 - 마스터노드
NODEPORT=$(kubectl get svc svc1 -o jsonpath='{.spec.ports[0].nodePort}')
echo $NODEPORT
tcpdump -eni any tcp port 80 or tcp port $NODEPORT -q -v
13:56:05.057646 In 08:00:27:06:8a:0d (tos 0x0, ttl 63, id 34911, offset 0, flags [DF], proto TCP (6), length 60)
192.168.20.100.59340 > 192.168.10.10.30272: tcp 0
13:56:05.057670 Out 08:00:27:cb:61:e9 (tos 0x0, ttl 63, id 34911, offset 0, flags [DF], proto TCP (6), length 68, options (unknown 154))
192.168.20.100.59340 > 172.16.1.97.80: tcp 0
tcpdump -i any tcp port 80 or tcp port $NODEPORT -w /tmp/dsr1.pcap
# 패킷 덤프 - 워커노드
NODEPORT=$(kubectl get svc svc1 -o jsonpath='{.spec.ports[0].nodePort}')
tcpdump -eni any tcp port 80 or tcp port $NODEPORT -q -v
tcpdump -i any tcp port 80 or tcp port $NODEPORT -w /tmp/dsr2.pcap
(혹은) tcpdump -eni any tcp port 80 or tcp port $NODEPORT -q -v -X
23:05:55.934635 Out 08:00:27:96:81:a2 (tos 0x0, ttl 63, id 7544, offset 0, flags [DF], proto TCP (6), length 68, options (unknown 154))
192.168.20.100.35484 > 172.16.1.35.80: tcp 0
0x0000: 4700 0044 1d78 4000 3f06 1db0 c0a8 1464 G..D.x@.?......d
0x0010: ac10 0123 9a08 3b79 0a0a a8c0 8a9c 0050 ...#../y.......P
0x0020: 8eb3 9b9b 0000 0000 a002 faf0 7420 0000 ............t...
0x0030: 0204 05b4 0402 080a 0670 9b04 0000 0000 .........p......
0x0040: 0103 0306 ....
# 옵션 헤더의 Hex 에서 정보 추출
Hex='0a 0a a8 c0'
for perIP in $Hex; do echo $((0x${perIP})); done | xargs echo | sed 's/ /./g'
10.10.168.192 => 꺼꾸로 보자! 클라이언트가 최초 접근 노드 IP (192.168.10.10)
2f79 -> (Hex순서뒤집기) 792f -> (10진수로변환) 31023
# 16진수 -> 10진수 변환
A=792F
echo $((0x${A}))
31023 >> 클라이언트가 최초 접근 노드의 Port
9a08 -> (Hex순서뒤집기) 089a -> (10진수로변환) 2222
A=089a
echo $((0x${A}))
2202 >> 요건 머지? Endpoint ID 인가? 32bit 배수가 되기 위한 패딩인가? 확인해보자!
# 실습 완료 후 삭제
kubectl delete svc svc1 && kubectl delete pod webpod1 netpod
최초 접속 노드(마스터)에는 외부클라이언트가 인입되는 형태의 트래픽만 보인다! 참고 : 전통적인 L4 장비에서 L2 DSR 동작 - 서버에 Loopback 설정이 필요했음
# 파드 서비스 정보 kubectl get pod -o wide kubectl get svc svc1 # maplist 확인 c0 maplist --verbose c1 maplist --verbose
DSR 사용 시 ip 옵션 헤더('목적지포트 + ? + 목적지IP' )에 최초 접속한 노드의 ip 정보를 담아서 타겟 노드로 전달한다.
타켓 노드는 전달받은 IP 옵션 헤더에 저장된 원래의 목적지 주소를 cilium_snat_v4_external 맵에 저장해놓고, conntrack 맵에 변환 정보를 추가한다.
이후 파드가 응답 패킷을 만들어 전송하면 파드의 veth LXC의 bpf_lxc.c #from-container 에서, conntrack 맵에 저장된 정보를 이용하여 cilium_snat_v4_external 맵에서 필요한 정보를 가져와서 응답 패킷의 출발지 주소를 원래 클라이언트가 접속한 주소로 변환한다. 이러한 과정을 통해 클라이언트는 패킷을 보낸 주소 그대로 패킷을 받게 되는 것이다. Magic!
또한, 클라이언트 IP(접속자 IP)는 파드까지 보존되어서 도달한다.
# 서비스(NodePort)를 확인
kubectl get svc svc1 -o jsonpath='{.spec.ports[0].nodePort}';echo
32465
------------------------------------------------------------------------------
# k8s-pc 나 자신의 PC 에서 Service(NodePort) 접속 트래픽 발생
SVCNPORT=$(kubectl get svc svc1 -o jsonpath='{.spec.ports[0].nodePort}')
curl -s **k8s-m**:$SVCNPORT
curl -s **k8s-m**:$SVCNPORT | grep Hostname
# k8s-pc 나 자신의 PC 에서 지속적으로 접속 트래픽 발생
while true; do curl -s **k8s-m**:$SVCNPORT | grep Hostname;echo "-----";sleep 1;done
------------------------------------------------------------------------------
# 모니터링 : 워커노드에 최초 TCP SYN 에 IP옵션 헤더값 포함된 패킷 확인! >> 아래 처럼 출력된 **IPv4Option** 에 맨 뒤부터 읽으면 된다!
c0 monitor # 없다!
**c1 monitor -vv**
------------------------------------------------------------------------------
level=info msg="Initializing dissection cache..." subsys=monitor
Ethernet {Contents=[..14..] Payload=[..70..] SrcMAC=82:dc:d0:66:f2:30 DstMAC=6a:f1:5e:fd:53:8b EthernetType=IPv4 Length=0}
**IPv4** {Contents=[..28..] Payload=[..40..] Version=4 IHL=7 TOS=0 Length=68 Id=28665 Flags=DF FragOffset=0 TTL=62 Protocol=TCP Checksum=47859 SrcIP=192.168.20.100 DstIP=172.16.1.97 Options=[**IPv4Option**(154:[64 118 **10 10 168 192**])] Padding=[]}
**TCP** {Contents=[..40..] Payload=[] SrcPort=59364 DstPort=80(http) Seq=2356875422 Ack=0 DataOffset=10 FIN=false SYN=true RST=false PSH=false ACK=false URG=false ECE=false CWR=false NS=false Window=64240 Checksum=21511 Urgent=0 Options=[..5..] Padding=[]}
CPU 00: MARK 0x0 FROM 2375 to-endpoint: 82 bytes (82 captured), state new, interface lxc8c5f8079ec7eidentity world->29901, **orig-ip 192.168.20.100**, to endpoint 2375
------------------------------------------------------------------------------
# 패킷 덤프 - 마스터노드
NODEPORT=$(kubectl get svc svc1 -o jsonpath='{.spec.ports[0].nodePort}')
echo $NODEPORT
tcpdump -eni any tcp port 80 or tcp port $NODEPORT -q -v
13:56:05.057646 In 08:00:27:06:8a:0d (tos 0x0, ttl 63, id 34911, offset 0, flags [DF], proto TCP (6), length 60)
192.168.20.100.59340 > 192.168.10.10.30272: tcp 0
13:56:05.057670 Out 08:00:27:cb:61:e9 (tos 0x0, ttl 63, id 34911, offset 0, flags [DF], proto TCP (6), length 68, **options (unknown 154))**
192.168.20.100.59340 > 172.16.1.97.80: tcp 0
tcpdump -i any tcp port 80 or tcp port $NODEPORT -w /tmp/dsr1.pcap
# 패킷 덤프 - 워커노드
NODEPORT=$(kubectl get svc svc1 -o jsonpath='{.spec.ports[0].nodePort}')
tcpdump -eni any tcp port 80 or tcp port $NODEPORT -q -v
tcpdump -i any tcp port 80 or tcp port $NODEPORT -w /tmp/dsr2.pcap
(혹은) tcpdump -eni any tcp port 80 or tcp port $NODEPORT -q -v -X
23:05:55.934635 Out 08:00:27:96:81:a2 (tos 0x0, ttl 63, id 7544, offset 0, flags [DF], proto TCP (6), length 68, **options (unknown 154)**)
192.168.20.100.35484 > 172.16.1.35.80: tcp 0
0x0000: 4700 0044 1d78 4000 3f06 1db0 c0a8 1464 G..D.x@.?......d
0x0010: ac10 0123 **9a08 3b79 0a0a a8c0** 8a9c 0050 ...#../y.......P
0x0020: 8eb3 9b9b 0000 0000 a002 faf0 7420 0000 ............t...
0x0030: 0204 05b4 0402 080a 0670 9b04 0000 0000 .........p......
0x0040: 0103 0306 ....
**# 옵션 헤더의 Hex 에서 정보 추출**
Hex='**0a 0a a8 c0**'
for perIP in $Hex; do echo $((0x${perIP})); done | xargs echo | sed 's/ /./g'
10.10.168.192 => 꺼꾸로 보자! 클라이언트가 최초 접근 노드 IP (192.168.10.10)
**2f79** -> (Hex순서뒤집기) **792f** -> (10진수로변환) **31023**
# 16진수 -> 10진수 변환
**A**=**792F**
echo $((0x${**A**}))
31023 >> 클라이언트가 최초 접근 노드의 Port
9a08 -> (Hex순서뒤집기) 089a -> (10진수로변환) 2222
**A**=089a
echo $((0x${**A**}))
2202 >> 요건 머지? Endpoint ID 인가? 32bit 배수가 되기 위한 패딩인가? 확인해보자!
# 실습 완료 후 삭제
kubectl delete svc svc1 && kubectl delete pod webpod1 netpod
최초 접속 노드(마스터)에는 외부클라이언트가 인입되는 형태의 트래픽만 보인다!
참고 : 전통적인 L4 장비에서 L2 DSR 동작 - 서버에 Loopback 설정이 필요했음
포트 기반 Restriction of accessible ports (Layer 4) for both incoming and outgoing connections, e.g. endpoint with label role=frontend 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.
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).
Prefilter: An XDP program and provides a set of prefilter rules used to filtertraffic 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 redirectproxytraffic to a Cilium userspaceproxyinstance. 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.
→ L7 정책는 커널hookpoint와Userspace Proxy사용으로 성능이 조금 떨어질 수 있다
# 테스트를 위한 트래픽 발생 서버/클라이언트 파드 생성
cat <<EOF | kubectl apply -f -
---
apiVersion: v1
kind: Pod
metadata:
annotations:
# Limits egress bandwidth to 10Mbit/s.
kubernetes.io/egress-bandwidth: "10M"
labels:
# This pod will act as server.
app.kubernetes.io/name: netperf-server
name: netperf-server
spec:
containers:
- name: netperf
image: cilium/netperf
ports:
- containerPort: 12865
---
apiVersion: v1
kind: Pod
metadata:
# This Pod will act as client.
name: netperf-client
spec:
affinity:
# Prevents the client from being scheduled to the
# same node as the server.
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app.kubernetes.io/name
operator: In
values:
- netperf-server
topologyKey: kubernetes.io/hostname
containers:
- name: netperf
args:
- sleep
- infinity
image: cilium/netperf
EOF
# egress BW 제한 정보 확인
kubectl describe pod netperf-server | grep Annotations:
Annotations: kubernetes.io/egress-bandwidth: 10M
# egress BW 제한이 설정된 파드가 있는 cilium pod 에서 제한 정보 확인
c1 bpf bandwidth list
c2 bpf bandwidth list
IDENTITY EGRESS BANDWIDTH (BitsPerSec)
904 10M
c1 endpoint list
c2 endpoint list
ENDPOINT POLICY (ingress) POLICY (egress) IDENTITY LABELS (source:key[=value]) IPv6 IPv4 STATUS
ENFORCEMENT ENFORCEMENT
904 Disabled Disabled 21565 k8s:app.kubernetes.io/name=netperf-server 172.16.2.153 ready
# 트래픽 발생 >> Hubble UI 에서 확인
# egress traffic of the netperf-server Pod has been limited to 10Mbit per second.
NETPERF_SERVER_IP=$(kubectl get pod netperf-server -o jsonpath='{.status.podIP}')
kubectl exec netperf-client -- netperf -t TCP_MAERTS -H "${NETPERF_SERVER_IP}"
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
131072 16384 16384 10.00 9.54 # 10Mbps 제한 확인!
# 5M 제한 설정 후 테스트
kubectl get pod netperf-server -o json | sed -e 's|10M|5M|g' | kubectl apply -f -
c1 bpf bandwidth list
c2 bpf bandwidth list
kubectl exec netperf-client -- netperf -t TCP_MAERTS -H "${NETPERF_SERVER_IP}"
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
131072 16384 16384 10.09 4.56 # 4.5Mbps 제한 확인!
# 20M 제한 설정 후 테스트
kubectl get pod netperf-server -o json | sed -e 's|5M|20M|g' | kubectl apply -f -
kubectl exec netperf-client -- netperf -t TCP_MAERTS -H "${NETPERF_SERVER_IP}"
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
131072 16384 16384 10.00 18.95 # 19Mbps 제한 확인!
tc qdisc show dev ens5
# 삭제
kubectl delete pod netperf-client netperf-server
L2 Announcements / L2 Aware LB (Beta) - Link , Blog
L2 Announcements는 로컬 영역 네트워크에서 서비스를 표시하고 도달 가능하게 만드는 기능입니다. 이 기능은 주로 사무실 또는 캠퍼스 네트워크와 같이 BGP 기반 라우팅이 없는 네트워크 내에서 온프레미스 배포를 위해 고안되었습니다.
이 기능을 사용하면 ExternalIP 및/또는 LoadBalancer IP에 대한 ARP 쿼리에 응답합니다. 이러한 IP는 여러 노드의 가상 IP(네트워크 장치에 설치되지 않음)이므로 각 서비스에 대해 한 번에 한 노드가 ARP 쿼리에 응답하고 MAC 주소로 응답합니다. 이 노드는 서비스 로드 밸런싱 기능으로 로드 밸런싱을 수행하여 북쪽/남쪽 로드 밸런서 역할을 합니다.
NodePort 서비스에 비해 이 기능의 장점은 각 서비스가 고유한 IP를 사용할 수 있으므로 여러 서비스가 동일한 포트 번호를 사용할 수 있다는 것입니다. NodePort를 사용할 때 트래픽을 보낼 호스트를 결정하는 것은 클라이언트에게 달려 있으며 노드가 다운되면 IP+Port 콤보를 사용할 수 없게 됩니다. L2 공지를 사용하면 서비스 VIP가 다른 노드로 간단히 마이그레이션되고 계속 작동합니다.https://isovalent.com/blog/post/migrating-from-metallb-to-cilium/
참고 : 전통적인 L4 장비에서 L2 DSR 동작 - 서버에 Loopback 설정이 필요했음 
