| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | 31 |
Tags
- sidecar injection
- windows에서 aws cli 설치하기
- ebdp
- node ip
- CICD
- Kubernetes
- 분산 traffic
- bdp
- metallb
- CNI
- traffic manager
- service mesh
- kubernetes network policy
- traffic management in istio
- loxilb
- ipvs
- Ingress
- wsl & vagrant
- blue-green
- vpc cni
- docker
- gogs
- cilium
- vagrant
- aws lb controller
- k8s-service
- aws eks
- Jenkins
- windows-aws-configure
- WSL
Archives
- Today
- Total
WellSpring
8주차 - Cilium CNI 본문
더보기
※ 본 게재 글은 gasida님의 KANS(Kubernetes Advanced Networking Study) 강의내용과 실습예제 및 kubernetes, eBPF, Cilium 공식 가이드 문서, 관련 Blog 등을 참고하여 작성하였습니다.
0. 실습 환경 구성
☞ 구성 요약 : VPC 1개(퍼블릭 서브넷 2개), EC2 인스턴스 3대 (Ubuntu 22.04 LTS, t3.xlarge - vCPU 4 , Mem 16) , testpc 1대는 t3.small
- CloudFormation 스택 실행 시 파라미터를 기입하면, 해당 정보가 반영되어 배포됩니다.
- CloudFormation 에 EC2의 UserData 부분(Script 실행)으로 실습 환경에 필요한 기본 설정들이 자동으로 진행됩니다.
▶ CloudFormation 스택 배포
- 설치 옵션 : kubeadm init ... --skip-phases=addon/kube-proxy
더보기
# YAML 파일 다운로드
curl -O https://s3.ap-northeast-2.amazonaws.com/cloudformation.cloudneta.net/kans/kans-8w.yaml
# CloudFormation 스택 배포
# aws cloudformation deploy --template-file kans-8w.yaml --stack-name mylab --parameter-overrides KeyName=<My SSH Keyname> SgIngressSshCidr=<My Home Public IP Address>/32 --region ap-northeast-2
예시) aws cloudformation deploy --template-file kans-8w.yaml --stack-name mylab --parameter-overrides KeyName=kp-gasida SgIngressSshCidr=$(curl -s ipinfo.io/ip)/32 --region ap-northeast-2
## Tip. 인스턴스 타입 변경 : MyInstanceType=t3.xlarge (vCPU 4, Mem 16)
예시) aws cloudformation deploy --template-file kans-8w.yaml --stack-name mylab --parameter-overrides MyInstanceType=t3.xlarge KeyName=kp-gasida SgIngressSshCidr=$(curl -s ipinfo.io/ip)/32 --region ap-northeast-2
# CloudFormation 스택 배포 완료 후 작업용 EC2 IP 출력
aws cloudformation describe-stacks --stack-name mylab --query 'Stacks[*].Outputs[0].OutputValue' --output text --region ap-northeast-2
# [모니터링] CloudFormation 스택 상태 : 생성 완료 확인
while true; do
date
AWS_PAGER="" aws cloudformation list-stacks \
--stack-status-filter CREATE_IN_PROGRESS CREATE_COMPLETE CREATE_FAILED DELETE_IN_PROGRESS DELETE_FAILED \
--query "StackSummaries[*].{StackName:StackName, StackStatus:StackStatus}" \
--output table
sleep 1
done
# 배포된 aws ec2 유동 공인 IP 확인
aws ec2 describe-instances --query "Reservations[*].Instances[*].{PublicIPAdd:PublicIpAddress,InstanceName:Tags[?Key=='Name']|[0].Value,Status:State.Name}" --filters Name=instance-state-name,Values=running --output text
# EC2 SSH 접속 : 바로 접속하지 말고, 5~7분 정도 후에 접속 할 것
ssh -i ~/.ssh/kp-gasida.pem ubuntu@$(aws cloudformation describe-stacks --stack-name mylab --query 'Stacks[*].Outputs[0].OutputValue' --output text --region ap-northeast-2)
...
(⎈|kubernetes-admin@kubernetes:N/A) root@k8s-s:~# <- kubeps 가 나오지 않을 경우 ssh logout 후 다시 ssh 접속 할 것!
▶ k8s-s , testpc 각각 접속 후 확인
더보기
★ 실습 환경 설명 : K8S v1.30.5 , 노드 OS(Ubuntu 22.04.5) , CNI(Cilium) , kube-proxy 미설치
- [자신의 PC] 배포된 aws ec2 유동 공인 IP 확인
더보기
aws ec2 describe-instances --query "Reservations[*].Instances[*].{PublicIPAdd:PublicIpAddress,InstanceName:Tags[?Key=='Name']|[0].Value,Status:State.Name}" --filters Name=instance-state-name,Values=running --output text- k8s-s 접속 후 확인 : ssh -i <> ubuntu@3.38.151.222
더보기
# config rename-context
kubectl config rename-context "kubernetes-admin@kubernetes" "CiliumLab"
# 기본 정보 확인
kubectl cluster-info
# node 상태 확인
kc get node -owide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
k8s-s NotReady control-plane 5m54s v1.30.5 192.168.10.10 <none> Ubuntu 22.04.5 LTS 6.8.0-1015-aws containerd://1.7.22
k8s-w1 NotReady <none> 5m32s v1.30.5 192.168.10.101 <none> Ubuntu 22.04.5 LTS 6.8.0-1015-aws containerd://1.7.22
k8s-w2 NotReady <none> 5m34s v1.30.5 192.168.10.102 <none> Ubuntu 22.04.5 LTS 6.8.0-1015-aws containerd://1.7.22
# kube-proxy 없다!
kc get pod -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-55cb58b774-8l84j 0/1 Pending 0 8m17s
kube-system coredns-55cb58b774-9prtv 0/1 Pending 0 8m17s
kube-system etcd-k8s-s 1/1 Running 0 8m31s
kube-system kube-apiserver-k8s-s 1/1 Running 0 8m31s
kube-system kube-controller-manager-k8s-s 1/1 Running 0 8m31s
kube-system kube-scheduler-k8s-s 1/1 Running 0 8m31s
hostnamectl
# cilium 의 제대로?된 동작을 위해서 커널 버전은 최소 5.8 이상 권장
uname -a
Linux k8s-s 6.8.0-1015-aws #16~204.1-Ubuntu SMP Mon Aug 19 19:38:17 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
[ 실행 결과 - 한 눈에 보기 ]
- testpc 각각 접속 후 확인 : ssh -i <> ubuntu@54.180.243.135
더보기
ip -br -c addr
hostnamectl
curl localhost
[ 실행 결과 - 한 눈에 보기 ]
※ (참고) mac M시리즈에서 VMware Fustion + Vagrant 로 vanilla k8s 설치 환경 배포 자동화 - donator : 김성중님
☞ https://github.com/icebreaker70/kans-vanilla-k8s-cilium
1. Cilium 소개
1.1 BPF/eBPF 소개 - 링크
☞ 리눅스 커널 기반 스택과 BPF의 구조 및 특성에 대한 검토해 보면 ...
- Linux Network Stack : 리눅스 네트워크 스택의 단점은 복잡하고, 변경에 시간이 걸리고, 레이어를 건너뛰기 어렵다. - Link
♣ 리눅스 커널은 여러 개의 압축된 layer 로 이루어져 있다.
♣ 수년 간 리눅스에서 강력한 User-Space API 호환성을 제공함
♣ 복잡성 때문에 단기간에 대체될 수 없다
♣ Layer를 우회하기가 매우 어려움
♣ 20년이 넘게 NetFilter를 통한 패킷필터링 기술이 적용됨
※ 참고 : IP-Netfilter & eBPF 비교 - Blog
- BPF(Berkley Packet Filter) / eBPF :
. Kernel에 Sandbox 형태로 설치되어 Packet을 필터링, 즉 Packet에 대한 제어를 할 수 있다.
. Packet Filtering하고 분석하는데 주로 사용되며, 대표적인 예로 tcpdump 에서 사용하는 필터이다.
. eBPF 는 Linux Kernel에 내장되어 시스템의 변경 없이 단순히 시스템 호출을 통해 요청을 처리할 수 있다.
☞ 왼쪽 Linux Network Stack 모델의 경우, 외부 Traffic 이 내부 Process까지 도달하기 까지 Kernel과 Userspace의 iptables 을 거쳐야만 하는 번거로움이 있는 반면, 오른쪽 eBPF 모델의 경우, Kernel에 내장되어 있어 Kernel-level에서 Packet-Filtering을 할 수 있어 보다 효율적으로 빠르게 Traffic 처리를 할 수 있다. ( k8s에서 eBPF 를 선택하는 이유!! )
[ More ... ]
더보기
☞ BPF kernel hook
* layer 별 kernel hook을 통해, 기존 iptables 에서보다 효율적으로 Traffic 처리
☞ BPF replaces iptables
☞ BPF based Filtering Architecture
☞ BPF based tail calls
1.2 Cilium 소개
- Cilium은 워크로드 간 네트워크 연결을 제공, 보안 및 관찰하기 위한 eBPF 기반 오픈 소스 클라우드 네이티브 솔루션이다.
[ More ... ]
더보기
☞ 주요 기능 개요 - Ref. Link
- Protect and secure APIs transparently
- 개별 애플리케이션 프로토콜 요청을 필터링하는 기능 제공
1) '/publc/*' path와 get method를 수반한 HTTP 요청 수락 / 이외 모든 요청 거부
2) 'topic1' 을 'service1' 에서 생성 및 'service2'에서 소비가 이루어지도록 하며, 다른 kafka Message 거부
3) 모든 REST Call에 HTTP header가 포함되어야 한다. - Secure service to service communication based on identities
- 배포의 민첩성과 수요에 따른 용이한 확장성 제공을 위해 컨테이너 형태 어플리케이션 사용
- 일반적인 컨테이너 방화벽은 소스 IP 주소와 대상 포트를 필터링하여 워크로드를 보호 방식을 사용하기 때문에 컨테이너가 시작될 때 마다 모든 방화벽을 조정해 주어야 하나,
- Cilium 은 동일한 보안정책 사용 대상에 대해 ID를 부여하고, 별도의 보안 ID-Key 값을 관리하여 컨테이너 어플리케이션에서 내보낸 모든 수신Traffic에 대하여 노드 단에서 식별이 가능하여 규모에 제한을 두지 않는다. - Secure access to and from external services
- 외부 서비스에 대한 액세스를 보호하기 위해 유입 및 유출 모두에 대한 기존 CIDR 기반 보안 정책이 지원 - Simple Networking
1) Overlay
- 모든 호스트에 걸친 캡슐화 기반 가상 네트워크 제공
- 현재, VXLAN과 Geneve가 내장되어 Linux에서 지원하는 모든 캡슐화 형식을 활성화 가능
- 최소한의 인프라 통합기반을 사용하여 IP 연결만 요구되어 거의 모든 네트워크에서 동작한다.
2) Direct Routing
- 리눅스 호스트의 일반 라우팅 테이블을 사용하며, App-Container의 IP주소를 라우팅 할 수 있어야 함
- 이 모드는 네트워크 기반지식이 있는 고급 사용자를 대상으로 하며,
- 다음의 환경에서 잘 동작한다
. Native IPv6 networks
. In conjunction with cloud network routers
. If you are already running routing daemons - Load Balancing
- 플리케이션 컨테이너 간과 외부 서비스 간의 트래픽에 대한 분산 로드 밸런싱을 구현하고
- kube-proxy와 같은 구성 요소를 완전히 대체 가능하며
- 효율적인 해시 테이블을 사용하여 거의 무제한적인 확장이 가능하다 - Bandwidth Management
- eBPF를 사용하여 효율적인 EDT 기반(Earliest Departure Time) 속도 제한을 통해 대역폭 관리를 구현
- 이를 통해 애플리케이션의 Transmission Tail Latency 시간을 크게 줄이고
- 대역폭 CNI 플러그인에서 사용되는 HTB(Hierarchy Token Bucket) 또는 TBF(Token Bucket Filter)와 같은 기존 접근 방식에 비해 다중 대기열 NIC에서 Locking을 방지할 수 있다. - Monitoring and Troubleshooting
- 메타데이터를 활용한 이벤트 모니터링
- Prometheus를 통한 지표 내보내기
- Hubble: Cilium을 위해 특별히 작성된 관찰 플랫폼입니다. 서비스 종속성 맵, 운영 모니터링 및 경고, 흐름 로그를 기반으로 한 애플리케이션 및 보안 가시성을 제공
♣ 기본적인 Data-plane 통신 : [Uerspace Proxy] = [ Envoy ] , L7 처리가 필요 없다면 bpf_lxc 간 direct 통신제공함
- 빨간 Box : Kernel Hook point
- 녹색 Box : Network device components
- 노란 Box : Cilium Components
1.3 Cilium Architecture
▶ 구성요소 - 링크
더보기
- 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 - 링크
더보기
출처 : https://cilium.io/blog/2020/06/22/cilium-18
- The Linux kernel supports a set of BPF hooks in the networking stack that can be used to run BPF programs.
- XDP : 네트워킹 드라이버의 가장 앞 단에서 XDP BPF hook 을 통해서 BPF program 을 트리거되기 때문에, 가능한 최고의 패킷 처리 성능을 제공
- 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
- 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 : L7 이하의 통신에 대해서는 TC@Endpoint 간 통신으로 빠르게 통신 가능함
☞ Ingress from Endpoint
▷ eBPF Maps - 링크
더보기
- 모든 eBPF Map 은 상한 용량이 있으며, limit 관련 여러 옵션들이 있다.
- kube-proxy 는 리눅스 코어에 따라 CT table 최대 수가 결정되며, Cilium 은 BPF Maps 이라는 자체 연결 추적 테이블을 가지고 메모리에 따라 최대 수가 결정됨
▷ Iptables Usage - 링크
더보기
- 기본적으로 Cilium은 iptables를 사용하지 않는다!!
- 커널 버전이 낮을 경우 iptables 동작으로 구현 될 수 있다. 혹은 cilium 미동작(장애 등 문제) 시, 트래픽 처리 보완 시에 사용
- 아래 그림은 cilium 과 iptables 을 같이 사용 시 다이어그램을 나타낸다.
2. Cilium 실습
2.1 배포
▶ Cilium 설치 정보(w/Helm) 및 확인 - Docs
더보기
# 모니터링
watch -d kubectl get node,pod -A -owide
#
helm repo add cilium https://helm.cilium.io/
helm repo update
#
helm install cilium cilium/cilium --version 1.16.3 --namespace kube-system \
--set k8sServiceHost=192.168.10.10 --set k8sServicePort=6443 --set debug.enabled=true \
--set rollOutCiliumPods=true --set routingMode=native --set autoDirectNodeRoutes=true \
--set bpf.masquerade=true --set bpf.hostRouting=true --set endpointRoutes.enabled=true \
--set ipam.mode=kubernetes --set k8s.requireIPv4PodCIDR=true --set kubeProxyReplacement=true \
--set ipv4NativeRoutingCIDR=192.168.0.0/16 --set installNoConntrackIptablesRules=true \
--set hubble.ui.enabled=true --set hubble.relay.enabled=true --set prometheus.enabled=true --set operator.prometheus.enabled=true --set hubble.metrics.enableOpenMetrics=true \
--set hubble.metrics.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}" \
--set operator.replicas=1
## 주요 파라미터 설명
--set debug.enabled=true # cilium 파드에 로그 레벨을 debug 설정
--set autoDirectNodeRoutes=true # 동일 대역 내의 노드들 끼리는 상대 노드의 podCIDR 대역의 라우팅이 자동으로 설정
--set endpointRoutes.enabled=true # 호스트에 endpoint(파드)별 개별 라우팅 설정
--set hubble.relay.enabled=true --set hubble.ui.enabled=true # hubble 활성화
--set ipam.mode=kubernetes --set k8s.requireIPv4PodCIDR=true # k8s IPAM 활용
--set kubeProxyReplacement=true # kube-proxy 없이 (최대한) 대처할수 있수 있게
--set ipv4NativeRoutingCIDR=192.168.0.0/16 # 해당 대역과 통신 시 IP Masq 하지 않음, 보통 사내망 대역을 지정
--set operator.replicas=1 # cilium-operator 파드 기본 1개
--set enableIPv4Masquerade=true --set bpf.masquerade=true # 파드를 위한 Masquerade , 추가로 Masquerade 을 BPF 로 처리 >> enableIPv4Masquerade=true 인 상태에서 추가로 bpf.masquerade=true 적용이 가능
# 설정 및 확인
ip -c addr
kubectl get node,pod,svc -A -owide
iptables -t nat -S
iptables -t filter -S
iptables -t raw -S
iptables -t mangle -S
conntrack -L
kubectl get crd
kubectl get ciliumnodes # cilium_host 인터페이스의 IP 확인 : CILIUMINTERNALIP
kubectl get ciliumendpoints -A
kubectl get cm -n kube-system cilium-config -o json | jq
kubetail -n kube-system -l k8s-app=cilium --since 1h
kubetail -n kube-system -l k8s-app=cilium-envoy --since 1h
# 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
-A CILIUM_OUTPUT_raw -d 192.168.0.0/16 -m comment --comment "cilium: NOTRACK for pod traffic" -j CT --notrack
-A CILIUM_OUTPUT_raw -s 192.168.0.0/16 -m comment --comment "cilium: NOTRACK for pod traffic" -j CT --notrack
...
conntrack -F
conntrack -L
conntrack -L |grep -v 2379
[ 실행 결과 - 한 눈에 보기 ]
▶ 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
...
KubeProxyReplacement: True [ens5 192.168.10.10 fe80::57:abff:fee3:da8d (Direct Routing)]
...
IPAM: IPv4: 2/254 allocated from 172.16.0.0/24,
Allocated addresses:
172.16.0.159 (router)
172.16.0.171 (health)
...
Routing: Network: Native Host: BPF
...
Device Mode: veth
Masquerading: BPF [ens5] 192.168.0.0/16 [IPv4: Enabled, IPv6: Disabled]
...
Proxy Status: OK, ip 172.16.0.159, 0 redirects active on ports 10000-20000, Envoy: external
...
KubeProxyReplacement Details:
Status: True
Socket LB: Enabled
Socket LB Tracing: Enabled
Socket LB Coverage: Full
Devices: ens5 192.168.10.10 fe80::57:abff:fee3:da8d (Direct Routing)
Mode: SNAT
Backend Selection: Random
Session Affinity: Enabled
Graceful Termination: Enabled
NAT46/64 Support: Disabled
XDP Acceleration: Disabled
Services:
- ClusterIP: Enabled
- NodePort: Enabled (Range: 30000-32767)
- LoadBalancer: Enabled
- externalIPs: Enabled
- HostPort: Enabled
BPF Maps: dynamic sizing: on (ratio: 0.002500)
...
# Native Routing 확인 : # 192.168.0.0/16 대역은 IP Masq 없이 라우팅
c0 status | grep KubeProxyReplacement
ubeProxyReplacement: True [ens5 192.168.10.10 fe80::57:abff:fee3:da8d (Direct Routing)]
# enableIPv4Masquerade=true(기본값) , bpf.masquerade=true 확인
cilium config view | egrep 'enable-ipv4-masquerade|enable-bpf-masquerade'
enable-bpf-masquerade true
enable-ipv4-masquerade true
c0 status --verbose | grep Masquerading
Masquerading: BPF [ens5] 192.168.0.0/16 [IPv4: Enabled, IPv6: Disabled]
# 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
Masquerading: BPF (ip-masq-agent) [ens5] 192.168.0.0/16 [IPv4: Enabled, IPv6: Disabled]
kubectl get cm -n kube-system cilium-config -o yaml | grep ip-masq
enable-ip-masq-agent: "true"
[ 실행 결과 - 한 눈에 보기 ]
2.2 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"
# 자주 사용 명령
helm upgrade cilium cilium/cilium --namespace kube-system --reuse-values --set
kubetail -n kube-system -l k8s-app=cilium --since 12h
kubetail -n kube-system -l k8s-app=cilium-envoy --since 12h
▶ 자주 쓰는 Cilium CLI 명령어 - Ref. Link
더보기
# 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 기본 정보 확인
더보기
[ 대표적인 항목 sampling 확인결과 ]
# 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
--------------------------------------------
# cilium cli 도움말
c0 help
# cilium 파드의 cilium 상태 확인
c0 status
c1 status
c2 status
c0 status --verbose
# 각 노드에서 파드에 할당된 IP 확인
c0 status --verbose | grep Allocated -A5
c1 status --verbose | grep Allocated -A5
c2 status --verbose | grep Allocated -A5
# 엔드포인트 리스트 : ID, 정책, 라벨, IP 주소, 상태 확인
c2 endpoint list
# 노드 리스트
c0 node list
# BFP(Direct access to local BPF maps)
# BFP 터널 리스트 확인 : Overlay Mode 사용 시 터널 정보 출력
c0 bpf tunnel list
TUNNEL VALUE
172.16.1.0:0 192.168.200.101:0
172.16.2.0:0 192.168.200.102:0
c1 bpf tunnel list
TUNNEL VALUE
172.16.2.0:0 192.168.200.102:0
172.16.0.0:0 192.168.200.10:0
c2 bpf tunnel list
TUNNEL VALUE
172.16.0.0:0 192.168.200.10:0
172.16.1.0:0 192.168.200.101:0
# 해당 노드의 로컬 엔드포인트 리스트 : nodemac 은 해당 파드와 veth pair 인 인터페이스의 mac 주소이다!
c0 bpf endpoint list
# Connection tracking tables - List connection tracking entries
c0 bpf ct list global
# Flush all NAT mapping entries
c0 bpf nat flush
# List all NAT mapping entries
c0 bpf nat list
# service list 확인, Frontend 는 Service IP, Backend 는 Pod IP(endpoint IP)를 보여준다.
c0 service list
# List load-balancing configuration
c0 bpf lb list
# List reverse NAT entries
c0 bpf lb list --revnat
# List all open BPF maps
c0 map list
c0 map list --verbose
c0 map get cilium_lxc
c0 map get cilium_ipcache
# cilium monitor
c0 monitor -h
c0 monitor -v
c0 monitor -v --type l7
# Cilium will automatically mount cgroup v2 filesystem required to attach BPF cgroup programs by default at the path /run/cilium/cgroupv2
mount | grep cilium
tree /run/cilium/cgroupv2/ -L 1
# CNI Plugin 확인
tree /etc/cni/net.d/
cat /etc/cni/net.d/05-cilium.conf
# Manage IP addresses and associated information - IP List
c0 ip list
# IDENTITY : 1(host), 2(world), 4(health), 6(remote), 파드마다 개별 ID를 가지는 것으로 보인다!
c0 ip list -n
# 엔드포인트 설정 확인 및 변경
c0 endpoint config <엔트포인트ID>
# 엔드포인트 상세 정보 확인
c0 endpoint get <엔트포인트ID>
# 엔드포인트 로그 확인
c0 endpoint log <엔트포인트ID>
# Show bpf filesystem mount details
c0 bpf fs show
# bfp 마운트 폴더 확인
tree /sys/fs/bpf
# List contents of a policy BPF map : Dump all policy maps
c0 bpf policy get --all
c0 bpf policy get --all -n
# BPF datapath traffic metrics
c0 bpf metrics list
# Manage the IPCache mappings for IP/CIDR <-> Identity
c0 bpf ipcache list
# Manage compiled BPF template objects
c0 bpf sha list
# Get datapath SHA header
c0 bpf sha get <Datapath SHA>
# Retrieve information about an identity
c0 identity list
# 엔드포인트 기준 ID
c0 identity list --endpoints
# Access metric status
c0 metrics list
[ 실행 결과 - 한 눈에 보기 ]
▶ 네트워크 기본 정보 확인 : k8s-w1/w2 에 SSH 접속 후 ip -c link/route 정보 확인
더보기
[ 네트워크 구성모델과 실제 IP addr 구성 확인 ]
# 네트워크 인터페이스 정보 확인
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
5: cilium_net@cilium_host: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 36:88:bf:c9:5c:6c brd ff:ff:ff:ff:ff:ff
...
6: cilium_host@cilium_net: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 4e:6a:8e:44:85:61 brd ff:ff:ff:ff:ff:ff
inet 172.16.1.254/32 scope link 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
0
cat /proc/sys/net/ipv4/conf/cilium_host/proxy_arp
0
# lxc_health 인터페이스는 veth 로 cilium(NET NS 0, 호스트와 다름)과 veth pair 이다 - 링크
# cilium 인터페이스에 파드 IP가 할당되어 있으며, cilium-health-responder 로 동작한다
lsns -t net
☞ 참고 : Cilium Container Networking Control Flow - Link
2.3 Hubble & CLI
2.3.1 Hubble 소개
▶ Hubble 소개 : 통신 및 서비스와 네트워킹 인프라의 동작에 대한 심층적인 가시성을 완전히 투명한 방식으로 제공하는 관찰성을 제공 - Blog
더보기
https://cilium.io/blog/2019/11/19/announcing-hubble
https://cilium.io/blog/2020/06/22/cilium-18
[ Hubble 제공 기능 및 특성 ]
- Hubble is a fully distributed networking and security observability platform. → 네트워크/보안 모니터링
- It is built on top of Cilium and eBPF to enable deep visibility into the communication and behavior of services as well as the networking infrastructure in a completely transparent manner. without requiring the application to change in any way. → 애플리케이션의 코드 수정 등 추가 설정 없이 동작
- containerized workloads as well as more traditional workloads such as virtual machines and standard Linux processes. → VM/서버도 모니터링 가능
- By leveraging Linux eBPF, Cilium retains the ability to transparently insert security visibility + enforcement, but does so in a way that is based on service / pod / container identity (in contrast to IP address identification in traditional systems) and can filter on application-layer (e.g. HTTP). → 전통적인 IP 기반은 모니터링/통제가 아니라 서비스/파드/ID 기반으로 모니터링/통제를 제공
- 기본적으로 Hubble API는 Cilium 에이전트가 실행되는 개별 노드의 범위 내에서 작동합니다. 이는 네트워크 통찰력을 로컬 Cilium 에이전트가 관찰한 트래픽으로 제한합니다. Hubble CLI( hubble)를 사용하여 로컬 Unix Domain Socket을 통해 제공된 Hubble API를 쿼리할 수 있습니다. Hubble CLI 바이너리는 기본적으로 Cilium 에이전트 포드에 설치됩니다.
- Hubble Relay를 배포하면 전체 클러스터 또는 ClusterMesh 시나리오의 여러 클러스터에 대한 네트워크 가시성이 제공됩니다. 이 모드에서 Hubble 데이터는 Hubble CLI( hubble)를 Hubble Relay 서비스로 지정하거나 Hubble UI를 통해 액세스할 수 있습니다. Hubble UI는 L3/L4 및 L7 계층에서 서비스 종속성 그래프를 자동으로 검색할 수 있는 웹 인터페이스로, 사용자 친화적인 시각화 및 서비스 맵으로서의 데이터 흐름 필터링을 허용합니다.
- Metrics export via Prometheus: Key metrics are exported via Prometheus for integration with your existing dashboards.
- Cluster-wide observability with Hubble Relay
- 서비스 종속성 그래프
- 다양한 메트릭(네트워크, 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 네임스페이스 선택 ⇒ 30분 소요, 여유 시간에 실행 해볼것!
더보기
- 테스트 완료 후 테스트 환경 삭제 kubectl delete ns cilium-test-Y
3. 노드 간 파드 통신 확인
[ 참고 링크 ]
[ 참고 - Packet Flow 설명 ]
더보기
- Endpoint to Endpoint
- Egress from Endpoint
- Ingress to Endpoint
▶ [실습] 파드 생성 및 확인
더보기
cat <<EOF | kubectl create -f -
apiVersion: v1
kind: Pod
metadata:
name: netpod
labels:
app: netpod
spec:
nodeName: k8s-s
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: Pod
metadata:
name: webpod2
labels:
app: webpod
spec:
nodeName: k8s-w2
containers:
- name: container
image: traefik/whoami
terminationGracePeriodSeconds: 0
EOF▶ Pod 변수 지정
더보기
# 테스트 파드들 IP
NETPODIP=$(kubectl get pods netpod -o jsonpath='{.status.podIP}')
WEBPOD1IP=$(kubectl get pods webpod1 -o jsonpath='{.status.podIP}')
WEBPOD2IP=$(kubectl get pods webpod2 -o jsonpath='{.status.podIP}')
# 단축키(alias) 지정
alias p0="kubectl exec -it netpod -- "
alias p1="kubectl exec -it webpod1 -- "
alias p2="kubectl exec -it webpod2 -- "▶ 파드의 ARP 동작 확인 ← Hubble Web UI 모니터링
더보기
# netpod 네트워크 정보 확인
p0 ip -c -4 addr
p0 route -n
p0 ping -c 1 $WEBPOD1IP && p0 ping -c 1 $WEBPOD2IP
p0 curl -s $WEBPOD1IP && p0 curl -s $WEBPOD2IP
p0 curl -s $WEBPOD1IP:8080 ; p0 curl -s $WEBPOD2IP:8080
p0 ping -c 1 8.8.8.8 && p0 curl -s wttr.in/seoul
p0 ip -c neigh
# hubble cli 확인
hubble observe --pod netpod
hubble observe --pod webpod1
hubble observe --pod webpod2
# BPF maps : 목적지 파드와 통신 시 어느곳으로 보내야 될지 확인할 수 있다
c0 map get cilium_ipcache
c0 map get cilium_ipcache | grep $WEBPOD1IP
# netpod 의 LXC 변수 지정
LXC=<k8s-s의 가장 나중에 lxc 이름>
LXC=lxc335e04832afa
# 파드와 veth pair 에 IP가 없다! proxy_arp 도 없다! 하지만 GW MAC 요청 시 lxc(veth)의 MAC 으로 응답이 온다! >> eBPF Magic!
# Cilium hijacks ARP table of POD1, forces the next hop to be the peer end (host side) of the veth pair.
ip -c addr show dev $LXC- Node’s eBPF programs
# list of eBPF programs
c0bpf net show
c0bpf net show | grep $LXC
lxc335e04832afa(12) tcx/ingress cil_from_container prog_id 1529 link_id 26
lxc335e04832afa(12) tcx/egress cil_to_container prog_id 1531 link_id 27
# Use bpftool prog show id to view additional information about a program, including a list of attached eBPF maps:
c0bpf prog show id <출력된 prog id 입력>
c0bpf prog show id 1529
1531: sched_cls name cil_to_container tag 3f1e92871a2c4013 gpl
loaded_at 2024-10-20T07:47:27+0000 uid 0
xlated 1712B jited 1015B memlock 4096B map_ids 66,239
btf_id 474
c0bpf map list
...
66: percpu_hash name cilium_metrics flags 0x1
key 8B value 16B max_entries 1024 memlock 19384B
...
239: prog_array name cilium_calls_00 flags 0x0
key 4B value 4B max_entries 50 memlock 720B
owner_prog_type sched_cls owner jited
...
[ 실행 결과 - 한 눈에 보기 ]
[ 심화 - 참고 ]
4. 서비스 통신 확인
▶ Socket-Based LoadBalancing 소개 (한글) - 링크
더보기
https://velog.io/@haruband/K8SCilium-Socket-Based-LoadBalancing-기법
https://cilium.io/blog/2020/11/10/ebpf-future-of-networking/
- 그림 왼쪽(네트워크 기반 로드밸런싱) vs 오른쪽(소켓 기반 로드밸런싱)
- Pod1 안에서 동작하는 앱이 connect() 시스템콜을 이용하여 소켓을 연결할 때 목적지 주소가 서비스 주소(10.10.8.55)이면 소켓의 목적지 주소를 바로 백엔드 주소(10.0.0.31)로 설정한다. 이후 앱에서 해당 소켓을 통해 보내는 모든 패킷의 목적지 주소는 이미 백엔드 주소(10.0.0.31)로 설정되어 있기 때문에 중간에 DNAT 변환 및 역변환 과정이 필요없어진다.
- destination NAT translation happens at the syscall level, before the packet is even built by the kernel.
- Socket operations : BPF socket operations program 은 root cgroup 에 연결되며 TCP event(ESTABLISHED) 에서 실행한다.
- 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! Magic!
더보기
- 서비스 생성
cat <<EOF | kubectl create -f -
apiVersion: v1
kind: Service
metadata:
name: svc
spec:
ports:
- name: svc-webport
port: 80
targetPort: 80
selector:
app: webpod
type: ClusterIP
EOF
- 서비스 접속 확인
# 서비스 생성 확인
kubectl get svc,ep svc
# 노드에 iptables 더이상 KUBE-SVC rule 이 생성되지 않는다!
iptables-save | grep KUBE-SVC
iptables-save | grep CILIUM
# 서비스IP를 변수에 지정
SVCIP=$(kubectl get svc svc -o jsonpath='{.spec.clusterIP}')
# Pod1 에서 Service(ClusterIP) 접속 트래픽 발생
kubectl exec netpod -- curl -s $SVCIP
kubectl exec netpod -- curl -s $SVCIP | grep Hostname
# 지속적으로 접속 트래픽 발생
SVCIP=$(kubectl get svc svc -o jsonpath='{.spec.clusterIP}')
while true; do kubectl exec netpod -- curl -s $SVCIP | grep Hostname;echo "-----";sleep 1;done
# 파드에서 SVC(ClusterIP) 접속 시 tcpdump 로 확인 >> 파드 내부 캡쳐인데, SVC(10.108.12.195)는 보이지 않고, DNAT 된 web-pod 의 IP가 확인! Magic!
kubectl exec netpod -- tcpdump -enni any -q
08:54:55.454271 eth0 Out ifindex 14 92:1a:b9:94:94:37 172.16.0.162.44718 > 172.16.1.234.80: tcp 0
08:54:55.454798 eth0 In ifindex 14 8a:0c:cc:a9:21:1a 172.16.1.234.80 > 172.16.0.162.44718: tcp 0
08:54:55.455030 eth0 Out ifindex 14 92:1a:b9:94:94:37 172.16.0.162.44718 > 172.16.1.234.80: tcp 77
...
kubectl exec netpod -- sh -c "ngrep -tW byline -d eth0 '' 'tcp port 80'"
T 2024/10/20 08:07:36.663329 172.16.0.132:59964 -> 172.16.1.53:80 [AP] #34
GET / HTTP/1.1.
Host: 10.10.124.15.
User-Agent: curl/8.7.1.
Accept: */*.
# 서비스 정보 확인
c0 service list
ID Frontend Service Type Backend
16 10.108.12.195:80 ClusterIP 1 => 172.16.2.157:80
2 => 172.16.1.234:80
c0 bpf lb list
SERVICE ADDRESS BACKEND ADDRESS
10.108.12.195:80 0.0.0.0:0 (16) [ClusterIP, non-routable]
172.16.1.234:80 (16)
172.16.2.157:80 (16)
# BPF maps
c0 map list --verbose
c0 map list --verbose | grep lb
c0 map get cilium_lb4_services_v2
c0 map get cilium_lb4_backends_v3
c0 map get cilium_lb4_reverse_nat
c0 map get cilium_lb4_reverse_sk
c0 map get cilium_lxc
c0 map get cilium_ipcache
[ 실행 결과 - 한 눈에 보기 ]
▶ Socket-Based LoadBalancing 관련 설정값 확인 및 Cgroup 관련 정보 확인
더보기
# Socket-Based LoadBalancing 관련 설정들 확인
c0 status --verbose
...
KubeProxyReplacement Details:
Status: True
Socket LB: Enabled
Socket LB Tracing: Enabled
Socket LB Coverage: Full
Devices: ens5 192.168.10.10 fe80::57:abff:fee3:da8d (Direct Routing)
Mode: SNAT
Backend Selection: Random
Session Affinity: Enabled
Graceful Termination: Enabled
NAT46/64 Support: Disabled
XDP Acceleration: Disabled
Services:
- ClusterIP: Enabled
- NodePort: Enabled (Range: 30000-32767)
- LoadBalancer: Enabled
- externalIPs: Enabled
- HostPort: Enabled
# cgroup root 경로 확인
tree /run/cilium/cgroupv2 -L 1
tree /run/cilium/cgroupv2 -L 2
cilium config view | grep cgroup
cgroup-root /run/cilium/cgroupv2
# eBPF cgroup 확인 : Socket based LB 와 관련
c0bpf cgroup tree
CgroupPath
ID AttachType AttachFlags Name
/sys/fs/cgroup
1081 cgroup_device multi
1498 tcx_ingress cil_to_host
1501 tcx_egress cil_from_host
# cilium 파드의 Init Containers 에서 cgroup 마운트!
Init Containers:
mount-cgroup:
Container ID: containerd://72e9d2ee9731e3536c893f9daaa7674809638e3d137f9eb0f46fe916c2aa2839
Image: quay.io/cilium/cilium:v1.16.3@sha256:62d2a09bbef840a46099ac4c69421c90f84f28d018d479749049011329aa7f28
Image ID: quay.io/cilium/cilium@sha256:62d2a09bbef840a46099ac4c69421c90f84f28d018d479749049011329aa7f28
Port: <none>
Host Port: <none>
Command:
sh
-ec
cp /usr/bin/cilium-mount /hostbin/cilium-mount;
nsenter --cgroup=/hostproc/1/ns/cgroup --mount=/hostproc/1/ns/mnt "${BIN_PATH}/cilium-mount" $CGROUP_ROOT;
rm /hostbin/cilium-mount
State: Terminated
Reason: Completed
Exit Code: 0
Started: Sun, 20 Oct 2024 15:45:34 +0900
Finished: Sun, 20 Oct 2024 15:45:34 +0900
Ready: True
Restart Count: 0
Environment:
CGROUP_ROOT: /run/cilium/cgroupv2
BIN_PATH: /opt/cni/bin
Mounts:
/hostbin from cni-path (rw)
/hostproc from hostproc (rw)
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-p6bcr (ro)
# mount-cgroup 로그 확인
kubetail -n kube-system -c mount-cgroup --since 12h
...
[cilium-lnwcr] time="2024-10-20T15:45:52+09:00" level=info msg="Mounted cgroupv2 filesystem at /run/cilium/cgroupv2" subsys=cgroups
[cilium-jmr7d] time="2024-10-20T15:45:33+09:00" level=info msg="Mounted cgroupv2 filesystem at /run/cilium/cgroupv2" subsys=cgroups
...▶ strace 시스템 콜 트레이싱 도구를 통해 파드 내에서 동작 확인*
더보기
# syacall 호출 확인
kubectl exec netpod -- strace -c curl -s $SVCIP
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
28.74 0.000971 12 79 mmap
16.37 0.000553 9 56 32 open
10.33 0.000349 29 12 fstat
5.83 0.000197 6 31 rt_sigaction
5.62 0.000190 7 27 munmap
5.33 0.000180 6 27 close
3.17 0.000107 3 27 read
2.81 0.000095 15 6 poll
2.69 0.000091 3 23 fcntl
2.66 0.000090 2 31 lseek
2.63 0.000089 8 10 readv
2.34 0.000079 5 14 mprotect
2.31 0.000078 78 1 1 connect
2.25 0.000076 6 12 rt_sigprocmask
1.30 0.000044 44 1 sendto
1.12 0.000038 9 4 getsockname
0.89 0.000030 7 4 setsockopt
0.50 0.000017 3 5 getrandom
0.50 0.000017 17 1 socket
0.44 0.000015 5 3 brk
0.44 0.000015 15 1 writev
0.41 0.000014 4 3 3 ioctl
0.38 0.000013 13 1 getsockopt
0.27 0.000009 9 1 recvfrom
0.27 0.000009 9 1 arch_prctl
0.21 0.000007 7 1 pipe
0.18 0.000006 6 1 set_tid_address
0.00 0.000000 0 1 execve
0.00 0.000000 0 1 getuid
0.00 0.000000 0 1 getgid
0.00 0.000000 0 2 geteuid
0.00 0.000000 0 1 getegid
------ ----------- ----------- --------- --------- ----------------
100.00 0.003379 8 389 36 total
# 출력 내용을 편집기에서 확인(검색)
kubectl exec netpod -- strace -s 65535 -f -tt curl -s $SVCIP
------------------------------------------------------------
08:19:14.846995 connect(5, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("10.10.124.15")}, 16) = -1 EINPROGRESS (Operation in progress) # 소켓 연결 시도
08:19:14.847653 getsockname(5, {sa_family=AF_INET, sin_port=htons(41312), sin_addr=inet_addr("172.16.0.132")}, [128 => 16]) = 0 # 소켓 주소 가져오기
...
08:19:14.852497 getsockopt(5, SOL_SOCKET, SO_ERROR, [0], [4]) = 0 # 소켓 연결 성공
08:19:14.852940 getsockname(5, {sa_family=AF_INET, sin_port=htons(41312), sin_addr=inet_addr("172.16.0.132")}, [128 => 16]) = 0 # 소켓 주소 한번더 확인
...
# 특정 이벤트 : -e
kubectl exec netpod -- strace -e trace=connect curl -s $SVCIP
kubectl exec netpod -- strace -e trace=getsockname curl -s $SVCIP
[ 실행 결과 - 한 눈에 보기 ]
▶ (심화) strace : 시스템 콜 트레이싱 도구(디버거) , 시스템 콜 상태(커널 모드로 실행 중이거나 대기 상태)
더보기
# 중단점 트레이싱 : -ttt(첫 열에 기준시간으로부터 흐른 시간 표시) , -T(마지막 필드 time에 시스템 콜에 걸린 시간을 표시) , -p PID(프로세스 ID가 PID 인 프로세스를 트레이싱)
strace -ttt -T -p 1884
# 시스템 콜별 통계
strace -c -p 1884
# 그냥 사용해보기
strace ls
# 옵션 사용해보기 : -s(출력 string 결과 최댓값 지정), -tt(첫 열에 기준시간으로부터 흐른 시간 표시, ms단위), -f(멀티 스레드,멀티 프로레스의 자식 프로세스의 시스템 콜 추적)
strace -s 65535 -f -T -tt -o <파일명> -p <pid>
# hostname 명령 분석하기 : -o <파일명> 출력 결과를 파일로 떨구기
strace -s 65535 -f -T -tt -o hostname_f_trace hostname -f
# 특정 이벤트 : -e
strace -e trace=connect curl ipinfo.io☞ 자원 삭제 : kubectl delete pod --all && kubectl delete svc svc
5. Running Prometheus & Grafana
▶ 설정 - Docs
더보기
# 배포
kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/1.16.3/examples/kubernetes/addons/prometheus/monitoring-example.yaml
kubectl get all -n cilium-monitoring
# 파드와 서비스 확인
kubectl get pod,svc,ep -o wide -n cilium-monitoring
# NodePort 설정
kubectl patch svc grafana -n cilium-monitoring -p '{"spec": {"type": "NodePort"}}'
kubectl patch svc prometheus -n cilium-monitoring -p '{"spec": {"type": "NodePort"}}'
# Grafana 웹 접속
GPT=$(kubectl get svc -n cilium-monitoring grafana -o jsonpath={.spec.ports[0].nodePort})
echo -e "Grafana URL = http://$(curl -s ipinfo.io/ip):$GPT"
# Prometheus 웹 접속 정보 확인
PPT=$(kubectl get svc -n cilium-monitoring prometheus -o jsonpath={.spec.ports[0].nodePort})
echo -e "Prometheus URL = http://$(curl -s ipinfo.io/ip):$PPT"
grafana , prometheus NodePort 로 웹 접속 후 확인
[ 실행 결과 - 한 눈에 보기 ]
6. Network Policy
☞ Cilium Docs 링크모음 : Security 참조
▶ Cilium Security Intro : Cilium provides security on multiple levels - Docs
더보기
https://docs.cilium.io/en/stable/security/network/identity/
출처 : https://docs.cilium.io/en/stable/security/network/proxy/envoy/
- 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=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.
- Proxy Injection : Envoy - Docs , Envoy
- 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).
- Proxy Injection : Envoy - Docs , Envoy
▶ 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 generate appropriate reject messages based on the configured L7 policy.
→ L7 정책는 커널 hookpoint 와 Userspace Proxy 사용으로 성능이 조금 떨어질 수 있다
▶ Deploy the Demo Application - Docs
더보기
- 스타워즈에서 영감 받은 예제 : 디플로이먼트(웹 서버, deathstar, replicas 2), 파드(xwing, tiefighter), 서비스(ClusterIP, service/deathstar)
# 배포
kubectl create -f https://raw.githubusercontent.com/cilium/cilium/1.16.3/examples/minikube/http-sw-app.yaml
kubectl get all
# 파드 라벨 확인
kubectl get pod --show-labels
NAME READY STATUS RESTARTS AGE LABELS
deathstar-689f66b57d-4rwkf 1/1 Running 0 113s app.kubernetes.io/name=deathstar,class=deathstar,org=empire,pod-template-hash=689f66b57d
deathstar-689f66b57d-8p2l5 1/1 Running 0 113s app.kubernetes.io/name=deathstar,class=deathstar,org=empire,pod-template-hash=689f66b57d
tiefighter 1/1 Running 0 113s app.kubernetes.io/name=tiefighter,class=tiefighter,org=empire
xwing 1/1 Running 0 113s app.kubernetes.io/name=xwing,class=xwing,org=alliance
# cilium endpoint 확인
kubectl get ciliumendpoints
c1 endpoint list
c2 endpoint list
# 데스스타 SVC(ClusterIP) 접속하여 웹 파드 연결 확인 >> Hubble UI 에서 실시간 확인해보자!
kubectl exec xwing -- curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing
Ship landed
kubectl exec tiefighter -- curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing
Ship landed
# 확인
hubble observe[ 실행 결과 - 한 눈에 보기 ]
▶ Identity-Aware and HTTP-Aware Policy Enforcement Apply an L3/L4 Policy - Link & Hubble CLI - 링크
더보기
- Cilium 에서는 Endpoint IP 대신, 파드의 **Labels(라벨)**을 사용(기준)하여 보안 정책을 적용합니다
- IP/Port 필터링을 L3/L4 네트워크 정책이라고 한다
- 아래 처럼 'org=empire' Labels(라벨) 부착된 파드만 허용해보자
- Cilium performs stateful connection tracking 이므로 리턴 트래픽은 자동으로 허용됨
# L3/L4 정책 생성
cat <<EOF | kubectl apply -f -
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
name: "rule1"
spec:
description: "L3-L4 policy to restrict deathstar access to empire ships only"
endpointSelector:
matchLabels:
org: empire
class: deathstar
ingress:
- fromEndpoints:
- matchLabels:
org: empire
toPorts:
- ports:
- port: "80"
protocol: TCP
EOF
# 정책 확인
kubectl get cnp
kc describe cnp rule1
c0 policy get
# 파드 curl 접속 시도 시 파드 sh 접속 후 curl 시도하자!
# 데스스타 SVC(ClusterIP) 접속하여 웹 파드 연결 확인 >> Hubble UI 에서 drop 확인!
kubectl exec tiefighter -- curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing
Ship landed
kubectl exec xwing -- curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing
drop
# hubble cli 모니터링
hubble observe --pod xwing
hubble observe --pod tiefighter
hubble observe --pod deathstar
Dec 2 05:36:24.490: default/xwing:55464 <> default/deathstar-c74d84667-t7msh:80 Policy denied DROPPED (TCP Flags: SYN)
Dec 2 05:36:24.490: default/xwing:55464 <> default/deathstar-c74d84667-t7msh:80 Policy denied DROPPED (TCP Flags: SYN)
hubble observe --pod deathstar --verdict DROPPED
Nov 30 15:23:47.721: default/xwing:60086 <> default/deathstar-c74d84667-ksnbd:80 Policy denied DROPPED (TCP Flags: SYN)
Nov 30 15:23:47.721: default/xwing:60086 <> default/deathstar-c74d84667-ksnbd:80 Policy denied DROPPED (TCP Flags: SYN)
Nov 30 15:27:40.250: default/tiefighter:41656 -> default/deathstar-c74d84667-ksnbd:80 http-request DROPPED (HTTP/1.1 PUT http://deathstar.default.svc.cluster.local/v1/exhaust-port)
Nov 30 15:28:00.707: default/tiefighter:41666 -> default/deathstar-c74d84667-ksnbd:80 http-request DROPPED (HTTP/1.1 PUT http://deathstar.default.svc.cluster.local/v1/exhaust-port)
Inspecting the Policy
# If we run cilium endpoint list again we will see that the pods with the label org=empire and class=deathstar
# now have ingress policy enforcement enabled as per the policy above.
# endpoint list 에서 정책 적용 확인
c1 endpoint list | grep deathstar
c2 endpoint list
ENDPOINT POLICY (ingress) POLICY (egress) IDENTITY LABELS (source:key[=value]) IPv6 IPv4 STATUS
ENFORCEMENT ENFORCEMENT
312 Disabled Disabled 18300 k8s:class=xwing 172.16.2.161 ready
k8s:io.cilium.k8s.namespace.labels.kubernetes.io/metadata.name=default
k8s:io.cilium.k8s.policy.cluster=default
k8s:io.cilium.k8s.policy.serviceaccount=default
k8s:io.kubernetes.pod.namespace=default
k8s:org=alliance
1972 Enabled Disabled 21144 k8s:class=deathstar 172.16.2.66 ready
k8s:io.cilium.k8s.namespace.labels.kubernetes.io/metadata.name=default
k8s:io.cilium.k8s.policy.cluster=default
k8s:io.cilium.k8s.policy.serviceaccount=default
k8s:io.kubernetes.pod.namespace=default
k8s:org=empirec2 endpoint list
[ 실행 결과 - 한 눈에 보기 ]
▶ Identity-Aware and HTTP-Aware Policy Enforcement Apply and Test HTTP-aware L7 Policy - Docs
더보기
- HTTP L7 필터링을 적용 : 아래 처럼 PUT /v1/exhaust-port 요청을 차단!
# 데스스타 SVC(ClusterIP) 접속
kubectl exec tiefighter -- curl -s -XPUT deathstar.default.svc.cluster.local/v1/exhaust-port
Panic: deathstar exploded
...
# POST /v1/request-landing API 호출만 허용 정책으로 기존 정책 내용을 업데이트(configured)!
cat <<EOF | kubectl apply -f -
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
name: "rule1"
spec:
description: "L7 policy to restrict access to specific HTTP call"
endpointSelector:
matchLabels:
org: empire
class: deathstar
ingress:
- fromEndpoints:
- matchLabels:
org: empire
toPorts:
- ports:
- port: "80"
protocol: TCP
rules:
http:
- method: "POST"
path: "/v1/request-landing"
EOF
# 정책 확인
kc describe ciliumnetworkpolicies
c0 policy get
# 모니터링
c1 monitor -v --type l7
c2 monitor -v --type l7
<- Request http from 0 ([k8s:io.cilium.k8s.policy.cluster=default k8s:io.cilium.k8s.policy.serviceaccount=default k8s:io.kubernetes.pod.namespace=default k8s:org=empire k8s:class=tiefighter k8s:io.cilium.k8s.namespace.labels.kubernetes.io/metadata.name=default]) to 1972 ([k8s:class=deathstar k8s:org=empire k8s:io.cilium.k8s.namespace.labels.kubernetes.io/metadata.name=default k8s:io.kubernetes.pod.namespace=default k8s:io.cilium.k8s.policy.serviceaccount=default k8s:io.cilium.k8s.policy.cluster=default]), identity 42720->21144, verdict Denied PUT http://deathstar.default.svc.cluster.local/v1/exhaust-port => 403
=> 403
hubble observe --pod deathstar
hubble observe --pod deathstar --verdict DROPPED
# 접근 테스트
kubectl exec tiefighter -- curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing
Ship landed
kubectl exec tiefighter -- curl -s -XPUT deathstar.default.svc.cluster.local/v1/exhaust-port
Access denied
## hubble cli 에 차단 로그 확인
hubble observe --pod deathstar --verdict DROPPED
Feb 28 11:39:59.078: default/tiefighter:33762 -> default/deathstar-c74d84667-lf2wl:80 http-request DROPPED (HTTP/1.1 PUT http://deathstar.default.svc.cluster.local/v1/exhaust-port)
hubble observe --pod deathstar --protocol http
Feb 28 12:05:22.095: default/tiefighter:40428 -> default/deathstar-6f87496b94-cvv9r:80 http-request DROPPED (HTTP/1.1 PUT http://deathstar.default.svc.cluster.local/v1/exhaust-port)
# 삭제
kubectl delete -f https://raw.githubusercontent.com/cilium/cilium/1.16.3/examples/minikube/http-sw-app.yaml
kubectl delete cnp rule1
[ 실행 결과 - 한 눈에 보기 ]
▶ [도전과제2] 공식문서 Securing Networks with Cilium 에 다양한 통제 기능을 테스트 후 정리 - Link
더보기
[ 추후 업데이트 예정 ]
☞ envoy 로그 level 상향 후 L7 통제 동작 시 로그 출력 확인 해보자.
8. Bandwidth Manager
▶ Bandwidth Manager : Bandwidth and Latency Optimization - Link , Home , Youtube
더보기
출처 : https://cilium.io/use-cases/bandwidth-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.
- ~~kubernetes.io/ingress-bandwidth~~ annotation is not supported
- direct routing mode, tunneling mode 둘 다 지원
- Limitations : L7 Cilium Network Policies
▶ 설정 및 확인
더보기
# 인터페이스 tc qdisc 확인
tc qdisc show dev ens5
qdisc mq 0: root
qdisc fq_codel 0: parent :4 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64
qdisc fq_codel 0: parent :3 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64
qdisc fq_codel 0: parent :2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64
qdisc fq_codel 0: parent :1 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64
# 설정
helm upgrade cilium cilium/cilium --namespace kube-system --reuse-values --set bandwidthManager.enabled=true
# 적용 확인
cilium config view | grep bandwidth
enable-bandwidth-manager true
# egress bandwidth limitation 동작하는 인터페이스 확인
c0 status | grep BandwidthManager
BandwidthManager: EDT with BPF [CUBIC] [ens5]
# 인터페이스 tc qdisc 확인 : 설정 전후 옵션값들이 상당히 추가된다
tc qdisc
tc qdisc show dev ens5
qdisc mq 8002: root
qdisc fq 8005: parent 8002:2 limit 10000p flow_limit 100p buckets 32768 orphan_mask 1023 quantum 18030b initial_quantum 90150b low_rate_threshold 550Kbit refill_delay 40ms timer_slack 10us horizon 2s horizon_drop
qdisc fq 8003: parent 8002:4 limit 10000p flow_limit 100p buckets 32768 orphan_mask 1023 quantum 18030b initial_quantum 90150b low_rate_threshold 550Kbit refill_delay 40ms timer_slack 10us horizon 2s horizon_drop
qdisc fq 8004: parent 8002:3 limit 10000p flow_limit 100p buckets 32768 orphan_mask 1023 quantum 18030b initial_quantum 90150b low_rate_threshold 550Kbit refill_delay 40ms timer_slack 10us horizon 2s horizon_drop
qdisc fq 8006: parent 8002:1 limit 10000p flow_limit 100p buckets 32768 orphan_mask 1023 quantum 18030b initial_quantum 90150b low_rate_threshold 550Kbit refill_delay 40ms timer_slack 10us horizon 2s horizon_drop
[ 실행 결과 - 한 눈에 보기 ]
▶ 동작 및 확인
더보기
# 테스트를 위한 트래픽 발생 서버/클라이언트 파드 생성
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
[ 실행 결과 - 한 눈에 보기 ]
[ 실습 종료 후 리소스 삭제 ]
☞ 모든 실습 종료 후, 자원을 정리합시다 !!
더보기
# CloudFormation 스택 삭제
aws cloudformation delete-stack --stack-name mylab
# [모니터링] CloudFormation 스택 상태 : 삭제 확인
while true; do
date
AWS_PAGER="" aws cloudformation list-stacks \
--stack-status-filter CREATE_IN_PROGRESS CREATE_COMPLETE CREATE_FAILED DELETE_IN_PROGRESS DELETE_FAILED \
--query "StackSummaries[*].{StackName:StackName, StackStatus:StackStatus}" \
--output table
sleep 1
done[ 마무리 ]
이번 클래스 실습을 통해 eBPF 기반의 Cilium 도구에 대해서 알게 되었고, 과정 실습을 통해 Traffic 의 제어와 흐름, 모니터링 등 다양한 테스트를 해 보면서, k8s의 관리 업무 상 powerful 한 도구를 알게 된 것 같아 매우 유익한 시간 이었습니다.
xwing 테스트 시나리오를 통해 Traffic 통제에 대한 기능을 간접적으로 확인해 볼 수 있었고, 특히 hubble 이라는 막강한 모니터링 도구와 grafana 및 Prometheus 등 의 시각화 도구와도 결합하여 이론적인 내용들을 보다 쉽게 이해 할 수 있는 접점을 갖게 되어 좋았습니다.
실무 적용에 있어서는 추가 테스트 및 공부가 필요할 것 같습니다.
[ 도움이 되는 링크 모음 ]
더보기
[ Cillium & eBPF 관련 ]
▷ Cilium - Home , Blog* , Docs** , Case Study - Kakao , Samsung
- Isovalent - Home , Blog* , Learning-tracks // eCHO - eBPF & Cilium Office Hours - 링크
▷ eBPF - Home , What?* , Blog , Labs , Applications (LoxiLB..)
- [Blog] First eBPF program - Link
- [Blog] How Cloudflare auto-mitigated world record 3.8 Tbps DDoS attack - Link
▷ haruband CodeBook (갓! 블로그) - 링크
▷ arthurchiao : CheatSheet* Cni-Create
▷ [카카오] 기존 100여대희 gateway 역할 서버를 k8s cliium egress gateway 를 통해서 40여대의 서버로 줄여서,
서버 비용과 운영 비용 감소 - Blog
▷ Integrating Cilium with Gateway API, IPv6, and BGP for Advanced Networking Solutions - Blog
▷ Cloudflare ebpf exporter https://github.com/cloudflare/ebpf_exporter , https://blog.cloudflare.com/introducing-ebpf_exporter/
Kubernetes Networking & Cilium for Network Engineers - An Instruction Manual.pdf
10.17MB
[ Youtube ]
▷ Coping with Zero Days with Cilium Tetragon* - Liz Rice, Isovalent - Link
▷ Using the Network Policy Editor - Link
▷ eBPF: Unlocking the Kernel [OFFICIAL DOCUMENTARY] - Link
▷ Panel Discussion: eBPF: A New Era in Cloud Infrastructure Tools - Link
[ OLD 문서 ]
▷ SKB - skbuff TCP/IP 네트워크스택 Packet flow
▷ Youtube - Networking and BPF Summit , Martynas Pumputis Cilium
▷ BPF / XDP 8월 세미나 KossLab* - 링크
[ 자격증 관련 ]
▷ CKS에 도전해 보시겠는가?! - 공식 사이트
[ eBPF 관련 ]
▷ 추천!! eBPF 다큐멘터리 : https://youtu.be/Wb_vD3XZYOA?si=KTpFkPGFFEDLD7VE
[ 기술 동향 ]
▷ Istio Ambient VS. Cilium : Link
▷ Kakao 기술세미나 관련 : Link
▷ LearnK8s : Link
[ Observability 관련 ]
▷ Network Observability with Hubble - Link
- Setting up Hubble Observability - Link
- Inspecting Network Flows with the CLI - Link
- Service Map & Hubble UI - Link
- Configuring Hubble exporter - Link
- Configure TLS with Hubble - Link
▷ Running Prometheus & Grafana - Link
▷ Monitoring & Metrics - Link
▷ Layer 7 Protocol Visibility - Link
▷ Hubble for Network Observability and Security (Part 3): Leveraging Hubble Data for Network Security - Link
▷ Hubble for Network Observability and Security (Part 2): Utilizing Hubble for Network Observability - Link
▷ Hubble for Network Observability and Security (Part 1): Introduction to Cilium and Hubble - Link
[ Cilium(Isovalent) Blog ]
더보기
2024
- Hubble for Network Observability and Security (Part 3): Leveraging Hubble Data for Network Security - Link
- Hubble for Network Observability and Security (Part 2): Utilizing Hubble for Network Observability - Link
- Hubble for Network Observability and Security (Part 1): Introduction to Cilium and Hubble - Link
- Demystifying the CNI by Writing One From Scratch : kind 실습(코드 제공) - Link
- Cilium 1.16 – High-Performance Networking With Netkit, Gateway API Gamma Support, BGPV2 and More! - Link
- Cilium netkit: container-network throughput and latency as fast as host-network
- Local ExternalTrafficPolicy support for Ingress/Gateway API preserving the client source IP address
- L7 Envoy Proxy as dedicated DaemonSet
- K8S event generation on packet drop
- [External] Exploring Cilium Network Integration with AWS EKS - Link
- [External] Making Damn Vulnerable Web Application (DVWA) almost unhackable with Cilium and Tetragon - Link
- [External] eBPF - Cilium on FHIR® - A Star Wars Story : kind 실습 - Link
- Cilium netkit: The Final Frontier in Container Networking Performance - Link
- [External] Cilium BGP Lab, locally! : kind 실습(코드 제공) - Link
- [External] Cilium: Installing Cilium in GKE with no Kube-Proxy - Link
- [External] Multi cluster networking with Cilium Cluster Mesh - Link
- Cilium Cheat Sheet - Link
- Isovalent - Cilium Cheat Sheet.pdf
- [External] Benchmark results of Kubernetes network plugins (CNI) over 40Gbit/s network [2024] - Link
- eBPF & Tetragon: Tools for Detecting XZ Utils CVE 2024-3094 Exploit - Link
- [External] Cilium: Installing Cilium in EKS with no Kube-Proxy - Link
- Tutorial: Using The Network Policy Editor (Part 3) - Link
- Tutorial: Cilium Network Policy in Practice (Part 2) - Link
- Introduction to Cilium Network Policies (Part 1) - Link
- [External] Kubernetes Networking by Using Cilium – Advanced Level – eBPF Routing - Link
- [External] Play with Cilium native routing in Kind cluster : kind 실습- Link
- [External] Bootstrapping K3s with Cilium : LB-IPAM, L2 announcements, IngressController - Link
- Cilium 1.15 – Gateway API 1.0 Support, Cluster Mesh Scale Increase, Security Optimizations and more! - Link
- Cilium now supports Gateway API 1.0
- Annotation Propagation from GW to LB
- Migrating from MetalLB to Cilium - Link
- Tutorial: Redirect, Rewrite, and Mirror HTTP with Cilium Gateway API - Link
- [External] Pure Cilium : A Guide for Local Load Balancing and BGP - Link
- The value of Cilium backports - Link
- [External] Demystifying Cilium: Learn How to Build an eBPF CNI Plugin from Scratch - Link
- [External] Scaling Cilium to New Heights With xDS - Link
- Networking and eBPF Predictions for 2024 and Beyond - Link
2023
- [External] Gateway API with Cilium and Cert-manager - Link
- [External] A Quick Glance at Cilium CNI - Link
- [External] Migrating from MetaLB to Cilium - Link
- Connecting your Kubernetes island to your network with Cilium BGP - Link
- eBPF’s Journey – Unlocking The Kernel - Link
- https://www.youtube.com/watch?v=Wb_vD3XZYOA
- Tetragon 1.0: Kubernetes Security Observability & Runtime Enforcement with eBPF - Link
- [External] Migrating Cilium from Legacy iptables Routing to Native eBPF Routing in Production - Link
- Isovalent Enterprise for Cilium 1.14: introducing Cilium Multi-Network* - Link
- [External] Kubernetes multi-cluster implementation in under 10 minutes - Link
- [External] Get started with eBPF log analytics in your Kubernetes cluster - Link
- Tutorial: Setting Up a Cybersecurity Honeypot with Tetragon to Trigger Canary Tokens - Link
- [External] Deep Dive — Inspect Deployment Network Traffic in Kubernetes - Link
- [External] eBPF Summit 2023 CTF Writeup - Link
- Tutorial: How to Use Cilium Hubble for Observability in CNI Chaining Mode (Part 1) - Link
- Can I Use Tetragon without Cilium? Yes! - Link
- [External] Cilium: ENI Prefix Delegation in EKS - Link
- Top 20 Cilium Use Cases - Link
- [External] A Quick Tour of Cilium 1.14 with Istio : kind 실습 - Link
- Cilium 1.14 – Effortless Mutual Authentication, Service Mesh, Networking Beyond K8S, High-Scale Multi-Cluster - Link
- Cilium Mesh: consistent networking across clouds and heterogeneous workloads
- L2 Announcements: Cilium can now natively advertise External IPs to local networks over Layer 2
- BIG TCP for IPv4: after the introduction of BIG TCP support for IPv6 in Cilium 1.13
- Migrating to Cilium: it’s never been easier to migrate to Cilium with the CiliumNodeConfig resource
- Tutorial: How to Migrate to Cilium - Link
- Cilium Hubble Series (Part 1): Re-introducing Hubble - Link
- [External] Race condition between kube-proxy and cilium - Link
- Tutorial: Cross-Namespace Routing with Cilium Gateway API - Link
- Cilium Mesh – One Mesh to Connect Them All - Link
- A Deep Dive into Cilium Gateway API: The Future of Ingress Traffic Routing - Link
- Tutorial: Getting Started with the Cilium Gateway API - Link
- [External] [K8S/Cilium] eBPF 기반 서비스 메쉬 분석 (Per-Node Proxy) - Link
- BIG Performances with BIG TCP on Cilium : IPv4 Linux Kernel 6.3 BIG TCP Support - Link , Youtube
- Cilium 1.13 – Gateway API, mTLS datapath, Service Mesh, BIG TCP, SBOM, SNI NetworkPolicy - Link
- L7 Load-Balancing for Kubernetes Services with annotations
- Shared LoadBalancer for Ingress Resources
- veth replacement
- IPAM for LoadBalancer Services and BGP Services Advertisement
- Introductory support for SCTP on Kubernetes
- Tutorial: Tips and Tricks to install Cilium - Link
2022
- [External] WSL2+Cilium: The rise of eBPF - Link
- Tutorial: Transparent Encryption with IPsec and WireGuard : kind 실습 - Link
- [External] Grafana and Cilium: Deep eBPF-powered observability for Kubernetes and cloud native infrastructure - Link
- Topology Aware Routing and Service Mesh across Clusters with Cluster Mesh - Link
- Accelerate network performance with Cilium BBR (Bottleneck Bandwidth and Round-trip propagation time) - Link
- Addressing Bandwidth Exhaustion with Cilium Bandwidth Manager - Link
- Cilium Service Mesh – Everything You Need to Know - Link
- Cilium 1.12 – Ingress, Multi-Cluster, Service Mesh, External Workloads, and much more - Link
- Integrated Ingress Controller: A fully compliant Kubernetes Ingress controller embedded into Cilium
- Envoy CRD: A new Kubernetes CRD making the full power of Envoy available whereever Cilium runs
- Egress Gateway promoted to Stable
- Network policies for ICMP
- L7 Load-balancing: With the addition of Ingress support, Cilium has become capable of performing L7 load-balancing.
- Bandwidth Manager promoted to Stable
- Dynamic Allocation of Pod CIDRs (beta)
- Cilium Standalone Layer 4 Load Balancer XDP - Link
- Tetragon – eBPF-based Security Observability & Runtime Enforcement - Link
- [External] Kind cluster with Cilium and no kube-proxy : kind 실습 - Link2022
- [External] WSL2+Cilium: The rise of eBPF - Link
- Tutorial: Transparent Encryption with IPsec and WireGuard : kind 실습 - Link
- [External] Grafana and Cilium: Deep eBPF-powered observability for Kubernetes and cloud native infrastructure - Link
- Topology Aware Routing and Service Mesh across Clusters with Cluster Mesh - Link
- Accelerate network performance with Cilium BBR (Bottleneck Bandwidth and Round-trip propagation time) - Link
- Addressing Bandwidth Exhaustion with Cilium Bandwidth Manager - Link
- Cilium Service Mesh – Everything You Need to Know - Link
- Cilium 1.12 – Ingress, Multi-Cluster, Service Mesh, External Workloads, and much more - Link
- Integrated Ingress Controller: A fully compliant Kubernetes Ingress controller embedded into Cilium
- Envoy CRD: A new Kubernetes CRD making the full power of Envoy available whereever Cilium runs
- Egress Gateway promoted to Stable
- Network policies for ICMP
- L7 Load-balancing: With the addition of Ingress support, Cilium has become capable of performing L7 load-balancing.
- Bandwidth Manager promoted to Stable
- Dynamic Allocation of Pod CIDRs (beta)
- Cilium Standalone Layer 4 Load Balancer XDP - Link
- Tetragon – eBPF-based Security Observability & Runtime Enforcement - Link
- [External] Kind cluster with Cilium and no kube-proxy : kind 실습 - Link
2021
- [External] First Step towards Cloud Native Security - Link
- What’s new in Cilium 1.11? Service Mesh Beta, Topology Aware Routing, OpenTelemetry - Link
- OpenTelemetry Support: Ability to export Hubble’s L3-L7 observability data
- Topology Aware Routing: Enhanced load-balancing with support for topology-aware hints to route traffic
- BGP Pod CIDR Announcement: Advertise PodCIDR IP routes to your network using BGP
- Graceful Service Backend Termination
- Kubernetes Cgroup Enhancements: Enhancements to Cilium’s kube-proxy replacement integration for runtimes operating in pure cgroup v2 mode as well as Linux kernel improvements for Kubernetes mixed mode cgroup v1/v2 environments
- Cilium Endpoint Slices: Cilium is now more efficient in CRD mode with its control-plane interactions with Kubernetes
- Cilium 1.10: WireGuard, BGP Support, Egress IP Gateway, New Cilium CLI, XDP Load Balancer - Link
- Egress IP Gateway
- Integrated BGP Support
- WireGuard® Support:
- CNI Benchmark: Understanding Cilium Network Performance - Link
- NetworkPolicy Editor: Create, Visualize, and Share Kubernetes NetworkPolicies - Link
NetworkPolicy Editor: Create, Visualize, and Share Kubernetes NetworkPolicies
Implementing Network Policy is a critical part of building a secure Kubernetes-based platform, but the learning curve from simple exa...
cilium.io
2020 이전
- Cilium 1.9: Maglev, Deny Policies, Hubble mTLS, Bandwidth Manager, eBPF Node-Local Redirect - Link
- Bandwidth Manager
- eBPF-Based Node-Local DNS and KIAM
- Datapath Optimizations (iptables bypass)
- eBPF - The Future of Networking & Security - Link
eBPF - The Future of Networking & Security
Today is an exciting day for the Cilium community: Isovalent, the company behind Cilium, is announcing its $29M Series A financing ro...
cilium.io
- Cilium 1.8: XDP Load Balancing, Cluster-wide Flow Visibility, Host Network Policy, Session Affinity - Link
- Cilium 1.7: Hubble UI, Cluster-wide Network Policies, eBPF-based Direct Server Return, TLS visibility - Link
- Announcing Hubble - Network, Service & Security Observability for Kubernetes - Link
- Cilium 1.5: Scaling to 5k nodes and 100k pods, BPF-based SNAT, and Rolling Key Updates for Transparent Encryption - Link
- Cilium 1.4: Multi-Cluster Service Routing, DNS Authorization, IPVLAN support, Transparent Encryption - Link
- Cilium 1.3: Go extensions for Envoy, Cassandra & Memcached Support - Link
- Cilium 1.2: DNS Security Policies, EKS Support, ClusterMesh, kube-router integration - Link
- Cilium 1.1: Istio sidecar mode, cri-o/containerd support, improved efficiency & scale, init policies - Link
- Cilium 1.0: Bringing the BPF Revolution to Kubernetes Networking and Security - Link2020 이전
- Cilium 1.9: Maglev, Deny Policies, Hubble mTLS, Bandwidth Manager, eBPF Node-Local Redirect - Link
- Bandwidth Manager
- eBPF-Based Node-Local DNS and KIAM
- Datapath Optimizations (iptables bypass)
- eBPF - The Future of Networking & Security - Link
- Cilium 1.8: XDP Load Balancing, Cluster-wide Flow Visibility, Host Network Policy, Session Affinity - Link
- Cilium 1.7: Hubble UI, Cluster-wide Network Policies, eBPF-based Direct Server Return, TLS visibility - Link
- Announcing Hubble - Network, Service & Security Observability for Kubernetes - Link
- Cilium 1.5: Scaling to 5k nodes and 100k pods, BPF-based SNAT, and Rolling Key Updates for Transparent Encryption - Link
- Cilium 1.4: Multi-Cluster Service Routing, DNS Authorization, IPVLAN support, Transparent Encryption - Link
- Cilium 1.3: Go extensions for Envoy, Cassandra & Memcached Support - Link
- Cilium 1.2: DNS Security Policies, EKS Support, ClusterMesh, kube-router integration - Link
- Cilium 1.1: Istio sidecar mode, cri-o/containerd support, improved efficiency & scale, init policies - Link
- Cilium 1.0: Bringing the BPF Revolution to Kubernetes Networking and Security - Link2020 이전
- Cilium 1.9: Maglev, Deny Policies, Hubble mTLS, Bandwidth Manager, eBPF Node-Local Redirect - Link
- Bandwidth Manager
- eBPF-Based Node-Local DNS and KIAM
- Datapath Optimizations (iptables bypass)
- eBPF - The Future of Networking & Security - Link
- Cilium 1.8: XDP Load Balancing, Cluster-wide Flow Visibility, Host Network Policy, Session Affinity - Link
- Cilium 1.7: Hubble UI, Cluster-wide Network Policies, eBPF-based Direct Server Return, TLS visibility - Link
- Announcing Hubble - Network, Service & Security Observability for Kubernetes - Link
- Cilium 1.5: Scaling to 5k nodes and 100k pods, BPF-based SNAT, and Rolling Key Updates for Transparent Encryption - Link
- Cilium 1.4: Multi-Cluster Service Routing, DNS Authorization, IPVLAN support, Transparent Encryption - Link
- Cilium 1.3: Go extensions for Envoy, Cassandra & Memcached Support - Link
- Cilium 1.2: DNS Security Policies, EKS Support, ClusterMesh, kube-router integration - Link
- Cilium 1.1: Istio sidecar mode, cri-o/containerd support, improved efficiency & scale, init policies - Link
- Cilium 1.0: Bringing the BPF Revolution to Kubernetes Networking and Security - Link2020 이전
- Cilium 1.9: Maglev, Deny Policies, Hubble mTLS, Bandwidth Manager, eBPF Node-Local Redirect - Link
- Bandwidth Manager
- eBPF-Based Node-Local DNS and KIAM
- Datapath Optimizations (iptables bypass)
- eBPF - The Future of Networking & Security - Link
- Cilium 1.8: XDP Load Balancing, Cluster-wide Flow Visibility, Host Network Policy, Session Affinity - Link
- Cilium 1.7: Hubble UI, Cluster-wide Network Policies, eBPF-based Direct Server Return, TLS visibility - Link
- Announcing Hubble - Network, Service & Security Observability for Kubernetes - Link
- Cilium 1.5: Scaling to 5k nodes and 100k pods, BPF-based SNAT, and Rolling Key Updates for Transparent Encryption - Link
- Cilium 1.4: Multi-Cluster Service Routing, DNS Authorization, IPVLAN support, Transparent Encryption - Link
- Cilium 1.3: Go extensions for Envoy, Cassandra & Memcached Support - Link
- Cilium 1.2: DNS Security Policies, EKS Support, ClusterMesh, kube-router integration - Link
- Cilium 1.1: Istio sidecar mode, cri-o/containerd support, improved efficiency & scale, init policies - Link
- Cilium 1.0: Bringing the BPF Revolution to Kubernetes Networking and Security - Link
- Cilium 1.9: Maglev, Deny Policies, Hubble mTLS, Bandwidth Manager, eBPF Node-Local Redirect - Link
- Cilium 1.9: Maglev, Deny Policies, Hubble mTLS, Bandwidth Manager, eBPF Node-Local Redirect - Link
- Cilium 1.9: Maglev, Deny Policies, Hubble mTLS, Bandwidth Manager, eBPF Node-Local Redirect - Link
eBPF - The Future of Networking & Security
Today is an exciting day for the Cilium community: Isovalent, the company behind Cilium, is announcing its $29M Series A financing ro...
cilium.io
[ Cilium Docs : Intro - Link , Component - Link ]
더보기
- Getting Started
- Advanced Installation
- Networking
- Networking Concepts
- K8S Networking
- Intro - Link
- Concepts - Link
- Requirements : k8s v1.27~1.30 - Link
- System Requirements : Kernel 5.10 이상 권장 - Link
- Configuration : ConfigMap, CNI , CRI - Link
- Network Policy : NetworkPolicy(L3/L4) , CiliumNetworkPolicy(L3-7) - Link
- Kubernetes Compatibility - Link
- Kubernetes Without kube-proxy : 단계적 기능별 실습 예시 포함 - Link
- Endpoint CRD : CiliumEndpoint - Link
- CiliumEndpointSlice - Link
- Troubleshooting - Link
- Bandwidth Manager - Link , Home
- Configuring IPAM Modes - Link
- Local Redirect Policy - Link
- BGP
- eBPF Datapath - Link
- Multi-cluster Networking - Link
- External networking (beta) : VM 등 외부 통신 - Link
- Egress Gateway
- Service Mesh
- VXLAN Tunnel Endpoint (VTEP) Integration (beta) - Link
- L2 Announcements / L2 Aware LB (Beta) - Link
- Node IPAM LB : k3s의 ‘ServiceLB’와 같은 기능 - Link
- Use a Specific MAC Address for a Pod - Link
- Multicast Support in Cilium (Beta) - Link
- Security
- Securing Networks with Cilium - Link
- Identity-Aware and HTTP-Aware Policy Enforcement - Link
- Locking Down External Access with DNS-Based Policies - Link
- Inspecting TLS Encrypted Connections with Cilium - Link
- Securing a Kafka Cluster - Link
- Securing gRPC - Link
- Securing Elasticsearch - Link
- Securing a Cassandra Database - Link
- Securing Memcached - Link
- Locking Down External Access Using AWS Metadata - Link
- Creating Policies from Verdicts - Link
- Host Firewall - Link
- Restricting privileged Cilium pod access - Link
- Overview of Network Security - Link
- Overview of Network Policy - Link
- Threat Model - Link
- Securing Networks with Cilium - Link
- Observability
- Operations
- Roadmap - Link
- Relaase Magement : 6개월마다 버전 출시- Link
- API Reference - Link
- Reference
- BPF and XDP Reference Guide - Link
'KANS3 - k8s Advanced Networking Study' 카테고리의 다른 글
| 9주차 - AWS EKS : VPC CNI (3) | 2024.10.27 |
|---|---|
| 7주차 - Service Mesh : Istio-Mode (Sidecar, Ambient) (1) | 2024.10.15 |
| 6주차 - Ingress & Gateway API (3) | 2024.10.07 |
| 5주차 - LoadBalancer(MetalLB), IPVS + LoxiLB (0) | 2024.10.01 |
| 4주차 : Service : ClusterIP, NodePort (0) | 2024.09.26 |
'KANS3 - k8s Advanced Networking Study' Related Articles
more
