시스템 요구사항

시스템 요구사항 (System Requirements)

Cilium을 설치하기 전에 시스템이 아래 최소 요구사항을 충족하는지 확인하세요. 대부분의 현대 Linux 배포판은 이미 충족합니다.

출처: System Requirements

본문

요약 (Summary)

cilium/cilium 컨테이너 이미지를 사용해 Cilium을 실행할 때 호스트 시스템은 다음 요구사항을 충족해야 해요:

AMD64 또는 AArch64 아키텍처의 호스트
Linux 커널 >= 5.10 또는 동등한 버전(예: RHEL 8.10의 4.18)

호스트에서 Cilium을 네이티브 프로세스로 실행할 때(즉 cilium/cilium 컨테이너 이미지를 실행하지 않을 때) 다음 추가 요구사항이 충족되어야 합니다:

clang+LLVM >= 18.1

Kubernetes 없이 Cilium을 실행할 때 다음 추가 요구사항이 충족되어야 합니다:

키-값 스토어 etcd >= 3.1.0

| 요구사항 | 최소 버전 | cilium 컨테이너 내부 | | Linux 커널 | >= 5.10 또는 RHEL 8.10에서 >= 4.18 | 아니요 | | 키-값 스토어 (etcd) | >= 3.1.0 | 아니요 | | clang+LLVM | >= 18.1 | 예 |

아키텍처 지원 (Architecture Support)

Cilium 이미지는 다음 플랫폼을 위해 빌드됩니다:

AMD64
AArch64

Linux 배포판 호환성 및 고려사항

다음 표는 Cilium과 잘 동작하는 것으로 알려진 Linux 배포판을 나열해요. 일부 배포판은 초기 몇 가지 조정이 필요합니다. Cilium을 실행하기 전에 각 배포판의 특정 주의사항을 반드시 읽어보세요.

| 배포판 | 최소 버전 | | Amazon Linux 2 | all | | Bottlerocket OS | all | | CentOS | >= 8.6 | | Container-Optimized OS | >= 85 | | Debian | >= 10 Buster | | Fedora CoreOS | >= 31.20200108.3.0 | | Flatcar | all | | LinuxKit | all | | Opensuse | Tumbleweed, >=Leap 15.4 | | RedHat Enterprise Linux | >= 8.6 | | RedHat CoreOS | >= 4.12 | | Talos Linux | >= 1.5.0 | | Ubuntu | >= 20.04 |

Note

위 목록은 사용자 피드백을 기반으로 해요. 나열되지 않았지만 잘 동작하는 Linux 배포판을 찾으면 GitHub 이슈를 열거나 이 가이드를 업데이트하는 풀 리퀘스트를 만들어 알려주세요.

AWS EKS의 ENI 모드에서 Flatcar

Flatcar는 Cilium이 생성·관리하는 네트워크 인터페이스를 조작하는 것으로 알려져 있어요. ENI 모드의 AWS EKS 노드용 공식 Flatcar 이미지를 실행할 때 이로 인해 연결 문제가 발생하고 잠재적으로 Cilium 에이전트 부팅을 막을 수 있습니다. 이를 피하려면 ENI 인터페이스에서 DHCP를 비활성화하고 다음을 추가해 unmanaged로 표시하세요:

[Match]
Name=eth[1-9]*

[Network]
DHCP=no

[Link]
Unmanaged=yes

이것을 /etc/systemd/network/01-no-dhcp.network에 추가한 후:

systemctl daemon-reload
systemctl restart systemd-networkd

Raspberry Pi의 Ubuntu 22.04

Raspberry Pi의 Ubuntu 22.04에서 Cilium을 실행하기 전에 다음 패키지를 설치하세요:

sudo apt install linux-modules-extra-raspi

Linux 커널 (Linux Kernel)

기본 요구사항 (Base Requirements)

Cilium은 커널 eBPF 기능과 eBPF와 통합하는 다양한 하위 시스템을 활용·구축합니다. 따라서 호스트 시스템은 Cilium 에이전트를 실행하기 위해 최신 Linux 커널을 실행해야 해요. 더 최신 커널은 Cilium이 에이전트 시작 시 자동으로 감지·사용하는 추가 eBPF 기능을 제공할 수 있습니다. 이 버전의 Cilium에서는 커널 5.10 이상(또는 RHEL 8.10의 4.18 같은 동등 버전)을 사용하는 것이 권장됩니다. 최신 커널이 필요한 기능 목록은 고급 기능에 필요한 커널 버전을 참고하세요.

eBPF 기능이 올바르게 활성화되려면 다음 커널 구성 옵션이 활성화되어야 해요. 배포판 커널에서는 보통 이렇습니다. 옵션을 모듈로 빌드하거나 정적으로 링크하는 경우 둘 중 어느 쪽도 유효합니다.

CONFIG_BPF=y
CONFIG_BPF_EVENTS=y
CONFIG_BPF_SYSCALL=y
CONFIG_NET_CLS_BPF=y
CONFIG_BPF_JIT=y
CONFIG_NET_CLS_ACT=y
CONFIG_NET_SCH_INGRESS=y
CONFIG_DEBUG_INFO_BTF=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CGROUPS=y
CONFIG_CGROUP_BPF=y
CONFIG_PERF_EVENTS=y
CONFIG_SCHEDSTATS=y

iptables 기반 masquerading을 위한 요구사항

masquerading에 BPF를 사용하지 않는 경우(enable-bpf-masquerade=false, 기본값) 다음 커널 구성 옵션이 필요해요.

CONFIG_NETFILTER_XT_SET=m
CONFIG_IP_SET=m
CONFIG_IP_SET_HASH_IP=m
CONFIG_NETFILTER_XT_MATCH_COMMENT=m

터널링과 라우팅을 위한 요구사항

Cilium은 노드 간 파드 간 통신을 위해 VXLAN 같은 터널링 프로토콜을 기본적으로 사용하고, 다양한 트래픽 관리 기능을 위해 정책 라우팅(policy routing)을 사용해요. 올바른 동작을 위해 다음 커널 구성 옵션이 필요합니다:

CONFIG_VXLAN=y
CONFIG_GENEVE=y
CONFIG_FIB_RULES=y

Note

일부 임베디드 또는 커스텀 Linux 시스템, 특히 ARM용 크로스 컴파일 시에는 커널 .config에서 CONFIG_FIB_RULES=y를 직접 활성화하는 것만으로는 충분하지 않습니다. 다른 라우팅 관련 커널 옵션에 의존하기 때문입니다.

권장 접근 방식은 다음을 사용하는 것입니다:
scripts/config --enable CONFIG_FIB_RULES
make olddefconfig
커널 빌드 시스템은 의존성을 검증·관리하기 위해 Kconfig 로직을 사용하므로, .config를 직접 편집하면 무시되거나 조용히 덮어쓸 수 있어요.

L7 및 FQDN 정책을 위한 요구사항

L7 프록시 리다이렉션은 현재 TPROXY iptables 액션과 socket 매치를 사용합니다. L7 리다이렉션이 의도대로 동작하려면 커널 구성에 다음 모듈이 포함되어야 합니다:

CONFIG_NETFILTER_XT_TARGET_TPROXY=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_CT=m
CONFIG_NETFILTER_XT_MATCH_MARK=m
CONFIG_NETFILTER_XT_MATCH_SOCKET=m

xt_socket 커널 모듈이 없으면 비터널링 데이터패스 모드에서 리다이렉트된 L7 트래픽의 포워딩이 동작하지 않아요. COS 같은 일부 주목할 만한 커널이 xt_socket 모듈 없이 배포되므로, Cilium은 해당 커널에서 L7 정책과 가시성을 사용할 수 있게 하는 폴백 호환 모드를 구현합니다. 현재 이 폴백은 비터널링 데이터패스 모드에서 ip_early_demux 커널 기능을 비활성화하며, 이는 시스템 네트워킹 성능을 떨어뜨릴 수 있어요. 이는 HTTP 리다이렉션이 의도대로 동작함을 보장합니다. 하지만 HTTP 적용 정책을 전혀 사용하지 않는다면, helm 구성 커맨드라인에 다음을 추가해 이 동작을 끌 수 있습니다:

Helm Repository

helm install cilium cilium/cilium --version 1.20.2 \
   --namespace kube-system \
   ... \
   --set enableXTSocketFallback=false

OCI Registry

helm install cilium oci://quay.io/cilium/charts/cilium 1.20.2 \
   --namespace kube-system \
   ... \
   --set enableXTSocketFallback=false

IPsec을 위한 요구사항

IPsec 투명 암호화 기능은 많은 커널 구성 옵션을 요구하며, 대부분 실제 암호화를 활성화합니다. 필요한 특정 옵션은 알고리즘에 따라 다릅니다. 아래 목록은 GCM-128-AES에 대한 요구사항입니다.

CONFIG_XFRM=y
CONFIG_XFRM_OFFLOAD=y
CONFIG_XFRM_STATISTICS=y
CONFIG_XFRM_ALGO=m
CONFIG_XFRM_USER=m
CONFIG_INET{,6}_ESP=m
CONFIG_INET{,6}_IPCOMP=m
CONFIG_INET{,6}_XFRM_TUNNEL=m
CONFIG_INET{,6}_TUNNEL=m
CONFIG_CRYPTO_AEAD=m
CONFIG_CRYPTO_AEAD2=m
CONFIG_CRYPTO_GCM=m
CONFIG_CRYPTO_SEQIV=m
CONFIG_CRYPTO_CBC=m
CONFIG_CRYPTO_HMAC=m
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_AES=m

Bandwidth Manager를 위한 요구사항

Bandwidth Manager는 패킷 스케줄링 알고리즘을 변경하려면 다음 커널 구성 옵션이 필요합니다.

CONFIG_NET_SCH_FQ=m

Netkit 디바이스 모드를 위한 요구사항

netkit 디바이스 모드는 netkit 디바이스를 만들기 위해 다음 커널 구성 옵션이 필요합니다.

CONFIG_NETKIT=y

고급 기능에 필요한 커널 버전

커널의 추가 기능은 Linux 커뮤니티에서 계속 발전하고 있어요. Cilium의 일부 기능은 더 새로운 커널 버전에 의존하므로 아래에 자세히 설명된 것처럼 더 최신 커널 버전으로 업그레이드하면 활성화됩니다.

| Cilium 기능 | 최소 커널 버전 | | Cilium의 멀티캐스트 지원 (Beta) (AMD64) | >= 5.10 | | IPv6 BIG TCP 지원 | >= 5.19 | | Cilium의 멀티캐스트 지원 (Beta) (AArch64) | >= 6.0 | | IPv4 BIG TCP 지원 | >= 6.3 | | netkit 디바이스 모드 | >= 6.8 |

키-값 스토어 (Key-Value store)

Cilium은 선택적으로 분산 키-값 스토어를 사용해 모든 클러스터 노드에 보안 identity를 관리·동기화·배포합니다. 현재 지원되는 키-값 스토어:

etcd >= 3.1.0

Kubernetes와 함께 CRD 기반 상태 관리를 사용하면 키-값 스토어 없이 Cilium을 사용할 수 있어요. 이는 새 Cilium 설치의 기본값입니다. 더 큰 클러스터는 대신 키-값 스토어 기반 identity 관리에서 더 잘 동작합니다. 자세한 내용은 Cilium 빠른 설치를 참고하세요.

cilium-agent가 키-값 스토어를 사용하도록 구성하는 방법은 키-값 스토어를 참고하세요.

clang+LLVM

Note

이 요구사항은 cilium-agent를 네이티브로 실행할 때만 필요해요. Cilium 컨테이너 이미지 cilium/cilium을 사용한다면 clang+LLVM이 컨테이너 이미지에 포함되어 있습니다.

LLVM은 Cilium이 Linux 커널에 로드할 eBPF 바이트코드 프로그램을 생성하는 데 사용하는 컴파일러 스위트예요. cilium-agent에서 사용할 수 있는 LLVM의 최소 지원 버전은 >=18.1입니다. 설치된 clang 버전은 eBPF 백엔드가 활성화된 상태로 컴파일되어야 합니다.

LLVM 다운로드·설치 방법은 https://releases.llvm.org/를 참고하세요.

방화벽 규칙 (Firewall Rules)

연결을 활성화하기 위해 방화벽 규칙이 요구되는 환경에서 Cilium을 실행한다면, Cilium이 제대로 동작하도록 다음 규칙을 추가해야 해요.

클러스터에서 Cilium을 실행하는 모든 노드가 서로 핑할 수 있는 것이 권장되지만 선택 사항입니다. 그래야 cilium-health가 노드 간 연결을 보고·모니터링할 수 있기 때문입니다. 이를 위해서는 모든 노드에서 ICMP Type 0/8, Code 0이 열려 있어야 합니다. health 모니터링을 위해 모든 노드에서 TCP 4240도 열려 있어야 해요. health 모니터링을 활성화하려면 이 두 방법 중 하나만 사용해도 됩니다. 방화벽이 두 방법 모두 허용하지 않으면 Cilium은 여전히 정상 동작하지만 health 정보는 제공할 수 없습니다.

IPsec이 활성화된 Cilium 배포의 경우 방화벽이 ESP 트래픽을 허용해야 해요. 예를 들어 AWS 보안 그룹은 기본적으로 ESP 트래픽을 허용하지 않습니다.

WireGuard를 사용한다면 UDP 포트 51871을 허용해야 합니다.

VXLAN 오버레이 네트워크 모드를 사용한다면 Cilium은 Linux가 달리 구성되지 않는 한 UDP의 Linux 기본 VXLAN 포트 8472를 사용합니다. 이 경우 VXLAN 오버레이 모드를 활성화하려면 모든 노드에서 UDP 8472가 열려 있어야 합니다. Geneve 오버레이 네트워크 모드도 마찬가지이며, 포트는 UDP 6081입니다.

직접 라우팅(direct routing) 모드로 실행한다면 네트워크가 파드 IP의 라우팅을 허용해야 합니다.

예를 들어 AWS에서 VXLAN 오버레이 네트워킹으로 실행한다면 최소한의 AWS 보안 그룹(SG) 규칙은 다음과 같습니다. 마스터 노드의 SG(master-sg)와 워커 노드의 SG(worker-sg)가 분리되어 있다고 가정하고, etcd가 마스터 노드에서 실행 중이라고 가정합니다.

마스터 노드(master-sg) 규칙:

워커 노드(worker-sg):

Note

마스터와 워커에 공유 SG를 사용한다면 이 규칙들을 자신에 대한 인그레스/이그레스로 압축할 수 있어요. 직접 라우팅(Direct Routing) 모드를 사용한다면 모든 규칙을 자신에 대한/자신으로부터의 모든 포트/프로토콜 인그레스/이그레스로 압축할 수 있습니다.

각 노드에서도 다음 포트를 사용할 수 있어야 합니다:

| 포트 범위 / 프로토콜 | 설명 | | 4240/tcp | 클러스터 health checks (cilium-health) | | 4244/tcp | Hubble server | | 4245/tcp | Hubble Relay | | 4250/tcp | Mutual Authentication 포트 | | 4251/tcp | Spire Agent health check 포트 (127.0.0.1 또는 ::1에서 수신) | | 6060/tcp | cilium-agent pprof 서버 (127.0.0.1에서 수신) | | 6061/tcp | cilium-operator pprof 서버 (127.0.0.1에서 수신) | | 6062/tcp | Hubble Relay pprof 서버 (127.0.0.1에서 수신) | | 9878/tcp | cilium-envoy health listener (127.0.0.1에서 수신) | | 9879/tcp | cilium-agent health 상태 API (127.0.0.1 및/또는 ::1에서 수신) | | 9890/tcp | cilium-agent gops 서버 (127.0.0.1에서 수신) | | 9891/tcp | operator gops 서버 (127.0.0.1에서 수신) | | 9893/tcp | Hubble Relay gops 서버 (127.0.0.1에서 수신) | | 9901/tcp | cilium-envoy Admin API (127.0.0.1에서 수신) | | 9962/tcp | cilium-agent Prometheus 메트릭 | | 9963/tcp | cilium-operator Prometheus 메트릭 | | 9964/tcp | cilium-envoy Prometheus 메트릭 | | 51871/udp | WireGuard 암호화 터널 엔드포인트 |

마운트된 eBPF 파일시스템

Note

일부 배포판은 bpf 파일시스템을 자동으로 마운트합니다. 다음 명령으로 bpf 파일시스템이 마운트되어 있는지 확인하세요.

# mount | grep /sys/fs/bpf
$ # if present should output, e.g. "none on /sys/fs/bpf type bpf"...

eBPF 파일시스템이 호스트 파일시스템에 마운트되어 있지 않으면 Cilium이 자동으로 마운트합니다.

이 BPF 파일시스템을 마운트하면 cilium-agent가 에이전트 재시작을 거쳐 eBPF 리소스를 유지할 수 있어 이후 에이전트가 재시작되거나 업그레이드되는 동안 데이터패스가 계속 동작합니다.

선택적으로 Cilium이 클러스터에 배포되기 전에 eBPF 파일시스템을 마운트할 수도 있습니다. 다음 명령은 호스트 마운트 네임스페이스에서 실행해야 하며, 머신 부팅 과정 동안 한 번만 실행해야 합니다.

# mount bpffs /sys/fs/bpf -t bpf

영속화와 함께 이를 달성하는 이식 가능한 방법은 /etc/fstab에 다음 줄을 추가하고 mount /sys/fs/bpf를 실행하는 것입니다. 그러면 노드 부팅 시 파일시스템이 자동으로 마운트됩니다.

bpffs                      /sys/fs/bpf             bpf     defaults 0 0

systemd로 kubelet을 관리한다면 systemd로 BPFFS 마운트 섹션을 참고하세요.

라우팅 테이블 (Routing Tables)

AWS ENI IPAM 모드로 실행할 때 Cilium은 파드 IP 할당에 사용되는 각 ENI에 대해 per-ENI 라우팅 테이블을 설치합니다. 이 라우팅 테이블은 호스트 네트워크 네임스페이스에 추가되며 시스템에서 달리 사용하면 안 됩니다. 이 per-ENI 라우팅 테이블의 인덱스는 10 + <eni-interface-index>로 계산됩니다. 기본 오프셋 10은 253-255 사이인 메인 라우팅 테이블과 충돌할 가능성이 매우 낮기 때문에 선택되었습니다.

Cilium은 다음 라우팅 테이블 ID를 사용합니다:

| 라우트 테이블 ID | 용도 | | 200 | IPsec 라우팅 규칙 | | 202 | VTEP 라우팅 규칙 | | 2004 | 프록시로의 라우팅 규칙 | | 2005 | 프록시에서의 라우팅 규칙 |

Cilium은 관련 기능이 하나도 사용되지 않더라도 이 라우팅 테이블 ID를 관리합니다.

권한 (Privileges)

Cilium을 실행하려면 다음 권한이 필요해요. 표준 Kubernetes DaemonSet을 실행할 때 권한은 Cilium에 자동으로 부여됩니다.

Cilium은 Linux 커널과 상호작용하여 네트워킹 작업을 수행하고 보안 규칙을 구현할 eBPF 프로그램을 설치합니다. 시스템 전반에 eBPF 프로그램을 설치하려면 CAP_SYS_ADMIN 권한이 필요합니다. 이 권한은 cilium-agent에 부여되어야 해요.

가장 빠른 방법은 cilium-agent를 root로 및/또는 privileged 컨테이너로 실행하는 것입니다.
Cilium은 호스트 네트워킹 네임스페이스 접근이 필요합니다. 이를 위해 Cilium 파드는 호스트 네트워킹 네임스페이스에서 직접 실행되도록 스케줄됩니다.

시스템 요구사항