용어

용어 (Terminology)

Cilium을 이해하기 위한 핵심 개념인 라벨(Label), 엔드포인트(Endpoint), 신원(Identity), 노드(Node)를 설명할게요. 옆에서 강의하듯 하나씩 짚어볼게요.

출처: Terminology

본문

라벨 (Labels)

라벨은 많은 자원 집합을 다루기 위한 범용적이고 유연하며 확장성이 뛰어난 방식이에요. 임의의 그룹핑과 집합 생성을 허용하기 때문이죠. 어떤 것을 설명하거나 주소를 지정하거나 선택해야 할 때, 항상 라벨을 기준으로 이루어져요.

  • 엔드포인트에는 Kubernetes, Cilium-예약(reserved) 신원, 또는 다른 Cilium이 관리하는 소스에서 파생된 라벨이 할당돼요.

  • 네트워크 정책 개요에서 라벨을 기반으로 통신이 허용되는 엔드포인트 쌍을 선택해요. 정책 자체도 라벨로 식별돼요.

라벨이란 무엇인가?

라벨은 key와 value로 구성된 문자열 쌍이에요. 라벨은 key=value 형식의 단일 문자열로 표현할 수 있어요. key 부분은 필수이고 고유해야 해요. 일반적으로 역방향 도메인 이름 표기법을 사용해 이렇게 달성해요 (예: io.cilium.mykey=myvalue). value 부분은 선택 사항이며 생략할 수 있어요 (예: io.cilium.mykey).

key 이름은 일반적으로 [a-z0-9-.] 문자 집합으로 구성돼야 해요.

라벨을 사용해 자원을 선택할 때는 key와 value가 모두 일치해야 해요. 예를 들어 my.corp.foo 라벨이 있는 모든 엔드포인트에 정책을 적용해야 한다면, my.corp.foo=bar 라벨은 그 셀렉터와 일치하지 않아요.

라벨 소스 (Label Source)

라벨은 다양한 소스에서 파생될 수 있어요. 예를 들어 엔드포인트는 연관된 Kubernetes 파드에서 라벨을 파생할 수 있어요. 서로 다른 소스는 겹치는 라벨 key를 사용할 수 있어요.

이 잠재적 충돌을 해결하기 위해 Cilium은 라벨을 가져올 때 모든 라벨 key 앞에 source: 접두사를 붙여 라벨의 소스를 나타내요 (예: k8s:role=frontend). foo: bar 라벨로 시작된 Kubernetes 파드는 k8s:foo=bar 라벨과 연관된 Cilium 엔드포인트로 표현돼요. 각 잠재적 소스에는 고유한 이름이 할당돼요. 현재 지원되는 라벨 소스는 다음과 같아요.

  • Kubernetes에서 파생된 라벨의 k8s:

  • 특별한 예약 라벨용 reserved: — Special Identities 참고.

  • 소스가 지정되지 않은 라벨용 unspec:

라벨을 사용해 다른 자원을 식별할 때, 소스를 포함시켜 특정 유형으로 라벨 매칭을 제한할 수 있어요. 소스가 제공되지 않으면 라벨 소스는 기본적으로 any:가 되며, 이는 소스와 무관하게 모든 라벨과 일치해요. 소스가 제공되면 선택하는 라벨과 일치하는 라벨의 소스가 일치해야 해요.

엔드포인트 (Endpoint)

Cilium은 애플리케이션 컨테이너에 IP 주소를 할당해 네트워크에서 사용 가능하게 만들어요. 여러 애플리케이션 컨테이너가 같은 IP 주소를 공유할 수 있으며, 이 모델의 전형적인 예가 Kubernetes 파드예요. 공통 주소를 공유하는 모든 애플리케이션 컨테이너는 Cilium이 엔드포인트라고 부르는 것으로 그룹화돼요.

개별 IP 주소를 할당하면 각 엔드포인트가 Layer 4 포트 범위 전체를 사용할 수 있어요. 이는 본질적으로 같은 클러스터 노드에서 실행되는 여러 애플리케이션 컨테이너가 80 같은 잘 알려진 포트에 모두 바인딩해도 충돌이 발생하지 않게 해줘요.

Cilium의 기본 동작은 모든 엔드포인트에 IPv6와 IPv4 주소를 모두 할당하는 거예요. 하지만 이 동작을 구성해 --enable-ipv4=false 옵션으로 IPv6 주소만 할당하게 할 수도 있어요. IPv6와 IPv4 주소가 모두 할당되면 어느 주소로든 엔드포인트에 도달할 수 있어요. 정책 규칙, 로드밸런싱 등에 관해서도 동일한 동작이 적용돼요. 자세한 내용은 IP Address Management (IPAM)을 참고하세요.

식별 (Identification)

식별 목적으로 Cilium은 클러스터 노드의 모든 엔드포인트에 내부 엔드포인트 ID를 할당해요. 엔드포인트 ID는 개별 클러스터 노드의 맥락 안에서 고유해요.

엔드포인트 메타데이터 (Endpoint Metadata)

엔드포인트는 엔드포인트와 연관된 워크로드에서 메타데이터를 자동으로 파생해요. 이 메타데이터는 보안/정책, 로드밸런싱, 라우팅 목적으로 엔드포인트를 식별하는 데 사용될 수 있어요.

현재 지원되는 메타데이터 검색 메커니즘은 다음과 같아요.

System Description
Kubernetes Pod labels (via k8s API)

메타데이터는 라벨 형태로 엔드포인트에 부착돼요.

예를 들어 app=benchmark 라벨로 시작된 Kubernetes 파드는 k8s:app=benchmark 라벨과 연관된 Cilium 엔드포인트로 표현돼요.

신원 (Identity)

모든 엔드포인트에는 신원이 할당돼요. 엔드포인트 간의 기본 연결성을 강제하는 데 사용되는 것이 바로 이 신원이에요. 전통적인 네트워킹 용어로는 Layer 3 강제와 동등하다고 볼 수 있어요.

신원은 라벨로 식별되며 클러스터 전역 고유 식별자를 부여받아요. 엔드포인트에는 엔드포인트의 보안 관련 라벨(Security Relevant Labels)과 일치하는 신원이 할당돼요. 즉, 동일한 보안 관련 라벨 집합을 공유하는 모든 엔드포인트는 동일한 신원을 공유해요. 이 개념 덕분에 애플리케이션이 확장됨에 따라 많은 개별 엔드포인트가 일반적으로 동일한 보안 라벨 집합을 공유하므로, 정책 강제를 방대한 수의 엔드포인트로 확장할 수 있어요.

신원이란 무엇인가?

엔드포인트의 신원은 엔드포인트가 나타내는 파드나 워크로드에 연관된 라벨을 기반으로 파생돼요. 파드나 워크로드가 시작되면 Cilium은 오케스트레이션 시스템에서 받은 이벤트를 기반으로 엔드포인트를 만들어 네트워크에서 그것을 표현해요. 다음 단계로, Cilium은 생성된 엔드포인트의 신원을 해석(resolve)해요. 파드나 워크로드의 라벨이 바뀔 때마다 신원은 재확인되고 필요에 따라 자동으로 수정돼요.

보안 관련 라벨 (Security Relevant Labels)

파드나 워크로드에 연관된 모든 라벨이 신원을 파생할 때 의미 있는 것은 아니에요. 라벨은 워크로드가 시작된 타임스탬프 같은 메타데이터를 저장하는 데 사용될 수 있어요. Cilium은 어떤 라벨이 의미 있고 신원 파생 시 고려 대상인지 알아야 해요. 이를 위해 사용자는 의미 있는 라벨의 문자열 접두사 목록을 지정해야 해요. 표준 동작은 id. 접두사로 시작하는 모든 라벨을 포함하는 거예요 (예: id.service1, id.service2, id.groupA.service44). 의미 있는 라벨 접두사 목록은 에이전트 시작 시 지정할 수 있어요.

특수 신원 (Special Identities)

Cilium이 관리하는 모든 엔드포인트에는 신원이 할당돼요. Cilium이 관리하지 않는 네트워크 엔드포인트와의 통신을 허용하기 위해, 그것들을 나타내는 특수 신원이 존재해요. 특별히 예약된 신원은 reserved: 문자열로 접두사가 붙어요.

Identity Numeric ID Description
reserved:unknown 0 신원을 파생할 수 없음.
reserved:host 1 로컬 호스트. 로컬 호스트 IP 중 하나에서 시작되거나 그쪽으로 향하는 모든 트래픽.
reserved:world 2 클러스터 밖의 모든 네트워크 엔드포인트
reserved:unmanaged 3 Cilium이 관리하지 않는 엔드포인트. 예: Cilium이 설치되기 전에 시작된 Kubernetes 파드.
reserved:health 4 Cilium 에이전트가 생성하는 헬스 체크 트래픽.
reserved:init 5 신원이 아직 해석되지 않은 엔드포인트는 init 신원을 할당받음. 이는 보안 신원을 파생하는 데 필요한 메타데이터 중 일부가 아직 없는 엔드포인트 단계를 나타냄. 주로 부트스트래핑 단계에서 나타남. init 신원은 엔드포인트의 라벨이 생성 시점에 알려지지 않은 경우에만 할당됨.
reserved:remote-node 6 모든 원격 클러스터 호스트의 집합. 로컬 노드가 아닌 연결된 클러스터의 모든 호스트 IP 중 하나에서 시작되거나 그쪽으로 향하는 모든 트래픽.
reserved:kube-apiserver 7 kube-apiserver를 서빙하는 백엔드가 실행 중인 원격 노드.
reserved:ingress 8 Ingress 프록시의 연결 소스 주소로 사용되는 IP에 부여됨.

잘 알려진 신원 (Well-known Identities)

다음은 Cilium이 자동으로 알고 있으며, kvstore 같은 외부 의존성에 접촉하지 않고도 보안 신원을 발급하는 잘 알려진 신 identity 목록이에요. 그 목적은 Cilium을 부트스트래핑하고, 클러스터에서 정책 강제와 함께 네트워크 연결성을 필수 서비스에 대해 어떤 의존성에도 의존하지 않고 활성화하는 것입니다.

Deployment Namespace ServiceAccount Cluster Name Numeric ID Labels
kube-dns kube-system kube-dns 102 k8s-app=kube-dns
kube-dns (EKS) kube-system kube-dns 103 k8s-app=kube-dns , eks.amazonaws.com/component=kube-dns
core-dns kube-system coredns 104 k8s-app=kube-dns
core-dns (EKS) kube-system coredns 106 k8s-app=kube-dns , eks.amazonaws.com/component=coredns
cilium-operator cilium-operator 105 name=cilium-operator , io.cilium/app=operator

참고: cilium-cluster가 cluster-name 옵션으로 정의되지 않으면 기본값은 "default"로 설정돼요.

클러스터에서의 신원 관리 (Identity Management in the Cluster)

신원은 전체 클러스터에서 유효해요. 즉, 여러 클러스터 노드에서 여러 파드나 컨테이너가 시작되면, 그것들이 신원 관련 라벨을 공유한다면 모두 하나의 신원을 해석하고 공유해요. 이는 클러스터 노드 간의 조정을 필요로 해요.

엔드포인트 신원을 해석하는 작업은 분산 키-값 저장소의 도움으로 수행돼요. 이 저장소는 "다음 값이 이전에 본 적이 없으면 새 고유 식별자를 생성"하는 형태의 원자적 연산을 수행할 수 있어요. 이를 통해 각 클러스터 노드는 신원 관련 라벨 부분집합을 만들고 키-값 저장소를 조회해 신원을 파생할 수 있어요. 라벨 집합이 이전에 조회됐는지 여부에 따라 새 신원이 생성되거나, 초기 조회의 신원이 반환돼요.

노드 (Node)

Cilium은 클러스터의 개별 구성원을 노드라고 불러요. 각 노드는 cilium-agent를 실행해야 하며 대부분 자율적으로 동작해요. 다른 노드에서 실행되는 Cilium 에이전트 간의 상태 동기화는 단순성과 확장을 위해 최소한으로 유지돼요. 이 동기화는 오직 Key-Value 저장소나 패킷 메타데이터를 통해서만 발생해요.

노드 주소 (Node Address)

Cilium은 노드의 IPv4와 IPv6 주소를 자동으로 감지해요. 감지된 노드 주소는 cilium-agent가 시작될 때 출력돼요.

Local node-name: worker0
Node-IPv6: f00d::ac10:14:0:1
External-Node IPv4: 172.16.0.20
Internal-Node IPv4: 10.200.28.238

더 알아보기 (Learn more)