Kubernetes Ingress 지원

Kubernetes Ingress 지원 (Kubernetes Ingress Support)

Cilium은 ingressClassName이 cilium인 표준 Kubernetes Ingress 리소스 정의를 사용해요. 경로 기반 라우팅과 TLS 종료에 사용할 수 있으며, kubernetes.io/ingress.class 어노테이션도 역호환을 위해 지원해요.

출처: Kubernetes Ingress Support

본문

Cilium은 ingressClassName이 cilium인 표준 Kubernetes Ingress 리소스 정의를 사용해요. 이것은 경로 기반 라우팅과 TLS 종료에 사용할 수 있어요. 역호환을 위해 kubernetes.io/ingress.class 어노테이션에 cilium 값을 사용하는 것도 지원해요.

참고

ingress 컨트롤러는 LoadBalancer 유형의 Service를 만들므로, 환경이 이를 지원해야 해요.

Cilium은 Ingress 리소스에 대한 로드 밸런서 모드를 지정할 수 있게 해줘요:

dedicated: Ingress 컨트롤러가 Ingress 전용 로드밸런서를 만들어요.
shared: Ingress 컨트롤러가 모든 Ingress 리소스에 대해 공유 로드밸런서를 사용해요.

각 로드 밸런서 모드에는 장단점이 있어요. shared 모드는 클러스터의 모든 Ingress 리소스에서 단일 LoadBalancer 구성을 공유해 리소스를 절약하고, dedicated 모드는 리소스 사이의 잠재적 충돌(예: 경로 접두사)을 피하는 데 도움이 돼요.

참고

Ingress 리소스의 로드 밸런서 모드를 변경할 수 있어요. 모드를 변경하면 Ingress 리소스에 새 로드 밸런서 IP 주소가 할당되기 때문에, 재구성 중에 Ingress 백엔드에 대한 활성 연결이 종료될 수 있어요.

이것은 Cilium이 설치된 기존 K8s 클러스터에서 Ingress 컨트롤러를 활성화하는 방법에 대한 단계별 가이드예요.

사전 요구사항 (Prerequisites)

Cilium은 kubeProxyReplacement=true로 kube-proxy 교체가 구성되어야 해요. 자세한 내용은 kube-proxy replacement를 참고해주세요.
Cilium은 l7Proxy=true(기본 활성화)로 L7 프록시가 활성화되어야 해요.
기본적으로 Ingress 컨트롤러는 LoadBalancer 유형의 Service를 만들므로, 환경이 이를 지원해야 해요. 또는 이것을 NodePort로 바꾸거나, Cilium 1.16+부터 호스트 네트워크에서 Cilium L7 프록시를 직접 노출할 수 있어요.

설치 (Installation)

Helm으로 활성화하기 — Cilium Ingress Controller는 helm 플래그 ingressController.enabled를 true로 설정해서 활성화할 수 있어요. 새 설치에 대해서는 Installation using Helm을 참고해주세요.

helm upgrade cilium cilium/cilium --version 1.20.2 \
   --namespace kube-system \
   --reuse-values \
   --set ingressController.enabled=true \
   --set ingressController.loadbalancerMode=dedicated
kubectl -n kube-system rollout restart deployment/cilium-operator
kubectl -n kube-system rollout restart ds/cilium

helm upgrade cilium oci://quay.io/cilium/charts/cilium 1.20.2 \
   --namespace kube-system \
   --reuse-values \
   --set ingressController.enabled=true \
   --set ingressController.loadbalancerMode=dedicated
kubectl -n kube-system rollout restart deployment/cilium-operator
kubectl -n kube-system rollout restart ds/cilium

--set ingressController.default=true 플래그를 설정하면 Cilium이 기본 ingress 컨트롤러가 될 수 있어요. 그러면 ingressClass가 설정되지 않아도 ingress 항목이 생성돼요.

Ingress 지원 없이 envoy 트래픽 관리 기능만 사용하려면 --enable-envoy-config 플래그만 활성화하면 돼요.

helm upgrade cilium cilium/cilium --version 1.20.2 \
   --namespace kube-system \
   --reuse-values \
   --set envoyConfig.enabled=true
kubectl -n kube-system rollout restart deployment/cilium-operator
kubectl -n kube-system rollout restart ds/cilium

helm upgrade cilium oci://quay.io/cilium/charts/cilium 1.20.2 \
   --namespace kube-system \
   --reuse-values \
   --set envoyConfig.enabled=true
kubectl -n kube-system rollout restart deployment/cilium-operator
kubectl -n kube-system rollout restart ds/cilium

추가로 프록시 로드 밸런싱 기능은 loadBalancer.l7.backend=envoy 플래그로 구성할 수 있어요.

helm upgrade cilium cilium/cilium --version 1.20.2 \
   --namespace kube-system \
   --reuse-values \
   --set loadBalancer.l7.backend=envoy
kubectl -n kube-system rollout restart deployment/cilium-operator
kubectl -n kube-system rollout restart ds/cilium

helm upgrade cilium oci://quay.io/cilium/charts/cilium 1.20.2 \
   --namespace kube-system \
   --reuse-values \
   --set loadBalancer.l7.backend=envoy
kubectl -n kube-system rollout restart deployment/cilium-operator
kubectl -n kube-system rollout restart ds/cilium

다음으로 Cilium agent와 operator의 상태를 확인할 수 있어요:

$ cilium status

Cilium CLI로 활성화하기 — 최신 버전의 Cilium CLI를 설치해볼게요. Cilium CLI는 Cilium 설치, Cilium 설치 상태 검사, 다양한 기능(예: clustermesh, Hubble) 활성화/비활성화에 사용할 수 있어요.

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_CLI_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/cilium-cli/main/stable.txt)
CLI_ARCH=amd64
if [ "$(uname -m)" = "arm64" ]; then CLI_ARCH=arm64; fi
curl -L --fail --remote-name-all https://github.com/cilium/cilium-cli/releases/download/${CILIUM_CLI_VERSION}/cilium-darwin-${CLI_ARCH}.tar.gz{,.sha256sum}
shasum -a 256 -c cilium-darwin-${CLI_ARCH}.tar.gz.sha256sum
sudo tar xzvfC cilium-darwin-${CLI_ARCH}.tar.gz /usr/local/bin
rm cilium-darwin-${CLI_ARCH}.tar.gz{,.sha256sum}

전체 릴리스 페이지를 참고해주세요.

Cilium Ingress Controller는 아래 명령으로 활성화할 수 있어요:

$ cilium install 1.20.2 \
    --set kubeProxyReplacement=true \
    --set ingressController.enabled=true \
    --set ingressController.loadbalancerMode=dedicated

Ingress 지원 없이 envoy 트래픽 관리 기능만 사용하려면 --enable-envoy-config 플래그만 활성화하면 돼요.

$ cilium install 1.20.2 \
    --set kubeProxyReplacement=true \
    --set envoyConfig.enabled=true

추가로 프록시 로드 밸런싱 기능은 loadBalancer.l7.backend=envoy 플래그로 구성할 수 있어요.

$ cilium install 1.20.2 \
    --set kubeProxyReplacement=true \
    --set envoyConfig.enabled=true \
    --set loadBalancer.l7.backend=envoy

다음으로 Cilium agent와 operator의 상태를 확인할 수 있어요:

$ cilium status

또한 이후 단계에서 트래픽을 관찰하는 데 사용될 Hubble CLI를 설치하는 것도 권장해요.

참조 (Reference)

Cilium Ingress와 Gateway API가 다른 Ingress 컨트롤러와 다른 점 (How Cilium Ingress and Gateway API differ from other Ingress controllers)

Cilium의 Ingress 및 Gateway API 지원과 다른 Ingress 컨트롤러 사이의 가장 큰 차이점 중 하나는 구현이 CNI와 얼마나 밀접하게 연결돼 있는지예요. Cilium에서는 Ingress와 Gateway API가 네트워킹 스택의 일부이므로, 다른 Ingress나 Gateway API 컨트롤러와는 다르게 동작해요 (심지어 Cilium 클러스터에서 실행되는 다른 Ingress/Gateway API 컨트롤러라도요).

다른 Ingress/Gateway API 컨트롤러는 일반적으로 클러스터에 Deployment나 DaemonSet으로 설치되고, Loadbalancer Service 등으로 노출돼요 (물론 Cilium이 이를 활성화할 수도 있어요).

Cilium의 Ingress 및 Gateway API 구성은 Loadbalancer나 NodePort 서비스로 노출되거나, 선택적으로 호스트 네트워크에서도 노출될 수 있어요. 하지만 이 모든 경우에 트래픽이 Service의 포트에 도착하면 eBPF 코드가 트래픽을 가로채서 (TPROXY 커널 기능을 사용해) Envoy로 투명하게 전달해요.

이것은 클라이언트 IP 가시성 같은 것에 영향을 주는데, 이는 Cilium의 Ingress/Gateway API 지원에서 다른 Ingress 컨트롤러와 다르게 동작해요.

또한 Cilium의 Network Policy 엔진이 Ingress로 향하는 트래픽과 Ingress에서 나오는 트래픽에 CiliumNetworkPolicy를 적용할 수 있게 해줘요.

Cilium의 ingress 구성과 CiliumNetworkPolicy (Cilium's ingress config and CiliumNetworkPolicy)

Cilium을 통해 백엔드 서비스로 향하는 Ingress 및 Gateway API 트래픽은 노드별 Envoy 프록시를 통과해요.

노드별 Envoy 프록시에는 eBPF 정책 엔진과 상호작용하고 트래픽에 대한 정책 조회를 수행할 수 있는 특수 코드가 있어요. 이를 통해 Envoy는 Ingress(및 Gateway API) 트래픽과 GAMMA나 L7 Traffic Management를 통한 동서(east-west) 트래픽 모두에 대해 Network Policy enforcement point가 될 수 있어요.

하지만 ingress 구성에는 추가 단계가 하나 더 있어요. Ingress나 Gateway API를 위해 Envoy에 도착한 트래픽은 Cilium의 Policy 엔진에서 특별한 ingress 아이덴티티로 지정돼요.

클러스터 외부에서 온 트래픽은 (클러스터에 IP CIDR 정책이 없다면) 보통 world 아이덴티티로 지정돼요. 즉 Cilium Ingress에는 실제로 두 개의 논리적 Policy enforcement point가 있다는 뜻이에요 — 트래픽이 ingress 아이덴티티에 도착하기 전과, 노드별 Envoy를 빠져나가려는 그 이후예요.

즉, 클러스터에 Network Policy를 적용할 때는 두 단계 모두 허용되는지, 그리고 world에서 ingress로, ingress에서 클러스터 안의 아이덴티티(위 이미지의 productpage 아이덴티티 등)로 트래픽이 허용되는지 확인하는 게 중요해요.

Ingress에 대한 자세한 내용은 Ingress and Network Policy Example을 참고해주세요. 단, 같은 원칙이 Gateway API에도 적용돼요.

소스 IP 가시성 (Source IP Visibility)

참고

기본적으로 Cilium ingress 구성(Ingress와 Gateway API 모두)의 소스 IP 가시성은 대부분의 설치에서 그냥 동작해야 해요. 요구사항과 관련 설정에 대한 자세한 내용은 이 섹션을 읽어주세요.

백엔드가 실제 요청이 어떤 IP 주소에서 왔는지 추론할 수 있는 것은 대부분의 애플리케이션에서 중요해요.

기본적으로 Cilium의 Envoy 인스턴스는 일반적인 규칙을 사용해 인입 HTTP 연결의 보이는 소스 주소를 X-Forwarded-For 헤더에 추가하도록 구성돼 있어요. 즉 기본적으로 Cilium은 신뢰된 홉(hop) 수를 0으로 설정해서, Envoy가 X-Forwarded-For 목록 안의 값이 아니라 연결이 열린 주소를 사용하도록 해요. 이 개수를 늘리면 Envoy가 목록의 오른쪽에서부터 세어 n 번째 값을 사용하게 돼요.

Envoy는 또한 X-Forwarded-For를 기반으로 결정된 신뢰된 클라이언트 주소가 무엇이든 X-Envoy-External-Address 헤더로 설정해요.

기본적으로 Cilium은 Ingress를 포함한 Layer 7 기능에 대한 정책을 적용할 때 연결 클라이언트의 소스 IP를 사용해요. 트래픽의 소스가 X-Forwarded-For 헤더를 주입하는 것을 신뢰한다면(예: 클라우드 로드 밸런서 사용 시), values 파일의 gatewayAPI 또는 ingressController 섹션에서 useRemoteAddress를 false로 설정해 Envoy가 X-Forwarded-For 헤더에 인코딩된 클라이언트 IP에서 온 트래픽으로 취급하도록 강제할 수 있어요.

자세한 내용은 Envoy X-Forwarded-For headers 문서를 참고해주세요.

참고

Cilium ingress(Ingress든 Gateway API든)를 사용하는 백엔드는 X-Forwarded-For와 X-Envoy-External-Address 헤더만 보면 돼요 (많은 HTTP 라이브러리가 이를 투명하게 처리해요).

Loadbalancer 또는 NodePort Service의 `externalTrafficPolicy`

Cilium의 ingress 지원(Ingress와 Gateway API 모두)은 종종 Loadbalancer나 NodePort Service를 사용해 Envoy DaemonSet을 노출해요.

이런 경우 Service 객체에는 클라이언트 IP 가시성과 특히 관련된 필드인 externalTrafficPolicy 필드가 있어요.

TLS 패스스루와 소스 IP 가시성 (TLS Passthrough and source IP visibility)

Ingress와 Gateway API 모두 TLS 패스스루 구성을 지원해요 (Ingress는 어노테이션, Gateway API는 TLSRoute 리소스). 이 구성은 여러 TLS 패스스루 백엔드가 로드 밸런서에서 동일한 TLS 포트를 공유할 수 있게 해주며, Envoy가 TLS 핸드셰이크의 Server Name Indicator(SNI) 필드를 검사해서 그 값을 사용해 TLS 스트림을 백엔드로 전달해요.

하지만 Envoy가 TLS 스트림의 TCP 프록시를 수행하므로, 이것은 소스 IP 가시성에 문제가 돼요.

어떤 일이 벌어지냐면, TLS 트래픽이 Envoy에 도착해서 TCP 스트림을 종료하고, Envoy가 client hello를 검사해 SNI를 찾은 다음 전달할 백엔드를 선택하고, 새 TCP 스트림을 시작해 다운스트림(외부) 패킷 안의 TLS 트래픽을 업스트림(백엔드)으로 전달해요.

이것은 새 TCP 스트림이므로, 백엔드 입장에서는 소스 IP가 Envoy예요 (Cilium 구성에 따라 보통 Node IP예요).

참고

TLS 패스스루를 수행할 때 백엔드는 전달된 TLS 스트림의 소스로 Cilium Envoy의 IP 주소를 보게 돼요.

Ingress 경로 유형과 우선순위 (Ingress Path Types and Precedence)

Ingress 스펙은 세 가지 유형의 경로를 지원해요:

Exact — 주어진 경로와 정확히 일치해요.
Prefix — /로 분리한 URL 경로 접두사와 일치해요. 마지막 경로 세그먼트는 전체 세그먼트와 일치해야 해요 — /foo/bar의 Prefix 경로를 구성하면 /foo/bar/baz는 일치하지만 /foo/barbaz는 일치하지 않아요.
ImplementationSpecific — 경로 해석은 IngressClass에 달려 있어요. Cilium의 경우 ImplementationSpecific을 "Regex"로 정의해서, Cilium은 주어진 모든 경로를 정규식으로 해석하고 그에 따라 Envoy를 프로그래밍해요. 특히 일부 다른 구현은 ImplementationSpecific을 "Prefix"로 의미하는데, 이 경우 Cilium은 경로를 다르게 취급해요. (/foo/bar 같은 경로에는 정규식 문자가 없으므로 Envoy에서 정규식으로 구성되면 Exact 일치로 동작해요.)

Ingress 객체에 여러 경로 유형이 구성되면 Cilium은 Envoy를 다음 순서로 일치하도록 구성해요:

Exact
ImplementationSpecific (즉 정규식)
Prefix

/ Prefix 일치는 특수 처리가 있어 항상 마지막에 가요.

이 경로 유형 각각 내에서 경로는 문자열 길이의 내림차순으로 정렬돼요.

ImplementationSpecific 정규식 지원을 사용한다면 * 연산자 사용에 주의하세요. 정규식의 길이를 늘리지만, 더 짧은 다른 옵션과 일치할 수 있기 때문이에요.

예를 들어 /impl과 /impl.* 두 개의 ImplementationSpecific 경로가 있으면, 생성된 구성에서 두 번째가 첫 번째보다 앞에 정렬돼요. 하지만 *이 사용 중이므로 /impl 일치는 절대 발생하지 않아요. 그 경로에 대한 어떤 요청이라도 먼저 /impl.* 경로와 일치하기 때문이에요.

자세한 내용은 Ingress Path Types를 참고해주세요.

지원되는 Ingress 어노테이션 (Supported Ingress Annotations)

이름	설명	기본값
`ingress.cilium.io/loadbalancer-mode`	ingress의 로드밸런서 모드예요. Helm 값 `ingressController.loadbalancerMode`에 설정된 기본값을 ingress별로 재정의할 수 있게 해줘요. 적용 가능한 값은 `dedicated`와 `shared`예요.	`dedicated` (Helm chart에서)
`ingress.cilium.io/loadbalancer-class`	ingress의 로드밸런서 클래스예요. `loadbalancer-mode`가 `dedicated`로 설정된 경우에만 적용돼요.	미지정
`ingress.cilium.io/service-type`	전용 Ingress의 Service 유형이에요. 적용 가능한 값은 `LoadBalancer`와 `NodePort`예요.	`LoadBalancer`
`ingress.cilium.io/service-external-traffic-policy`	전용 Ingress의 Service externalTrafficPolicy예요. 적용 가능한 값은 `Cluster`와 `Local`이에요.	`Cluster`
`ingress.cilium.io/insecure-node-port`	HTTP Ingress에 사용할 NodePort예요. `ingress.cilium.io/service-type`이 `NodePort`인 경우에만 적용돼요. 미지정이면 kubernetes가 임의 NodePort를 할당해요.	미지정
`ingress.cilium.io/secure-node-port`	HTTPS Ingress에 사용할 NodePort예요. `ingress.cilium.io/service-type`이 `NodePort`인 경우에만 적용돼요. 미지정이면 kubernetes가 임의 NodePort를 할당해요.	미지정
`ingress.cilium.io/host-listener-port`	호스트 네트워크의 Envoy 리스너에 사용할 포트예요. 전용 Ingress와 호스트 네트워크 모드가 활성화된 경우에만 적용되고 필수예요.	`8080`
`ingress.cilium.io/tls-passthrough`	이 Ingress에 TLS 패스스루 모드를 활성화해요. 적용 가능한 값은 `enabled`와 `disabled`이며, boolean 스타일 값도 허용돼요. TLS 패스스루가 동작하는 방식 때문에 TLS 패스스루 Ingress에는 몇 가지 조건이 적용돼요: * Ingress에 `host` 필드가 설정되어야 해요 * 기본 백엔드는 무시돼요 * `/` 이외의 경로가 있는 규칙은 무시돼요 이런 이유로 Ingress의 모든 규칙이 무시되면 Envoy 구성이 생성되지 않고 Ingress는 효과가 없어요. 이 어노테이션은 다른 Ingress 컨트롤러의 `ssl-passthrough`와 유사하다는 점에 주목해주세요.	`disabled`
`ingress.cilium.io/force-https`	이 Ingress에 강제 HTTPS 리다이렉트를 활성화해요. 적용 가능한 값은 `enabled`와 `disabled`이며, boolean 스타일 값도 허용돼요. 어노테이션이 없으면 이 동작은 `enforce-ingress-https` 구성 파일 설정(또는 Helm의 `ingressController.enforceHttps`)으로 제어돼요. TLS 구성이 있는 모든 호스트에는 Ingress에 지정된 각 일치에 대해 HTTPS로의 리다이렉트가 구성돼요.	미지정
`ingress.cilium.io/request-timeout`	Ingress 백엔드 HTTP 요청의 요청 타임아웃(초)이에요. 어노테이션이 있으면 `ingress-default-request-timeout` operator 플래그로 설정된 값을 재정의해요. 둘 다 설정되지 않으면 `0`(제한 없음)으로 기본 설정돼요.	`0`

추가로 LoadBalancer Service에 대한 클라우드 프로바이더별 어노테이션도 지원돼요.

기본적으로 값이 다음으로 시작하는 어노테이션들은:

lbipam.cilium.io
nodeipam.cilium.io
service.beta.kubernetes.io
service.kubernetes.io
cloud.google.com

Ingress 객체에서 생성된 LoadBalancer Service 객체로 복사돼요.

이 설정은 Cilium Operator의 ingress-lb-annotation-prefixes config 플래그로 제어되며, Cilium의 Helm values.yaml에서 ingressController.ingressLBAnnotationPrefixes 설정으로 구성할 수 있어요.

자세한 내용은 Kubernetes 문서를 참고해주세요.

호스트 네트워크 모드 (Host network mode)

참고

Cilium 1.16+부터 지원돼요

호스트 네트워크 모드를 사용하면 호스트 네트워크에서 Cilium ingress 컨트롤러(Envoy 리스너)를 직접 노출할 수 있어요. 이는 LoadBalancer Service를 사용할 수 없는 경우(개발 환경이나 클러스터 외부 로드 밸런서가 있는 환경 등)에 유용해요.

참고

Cilium ingress 컨트롤러 호스트 네트워크 모드를 활성화하면 LoadBalancer/NodePort 유형 Service 모드가 자동으로 비활성화돼요. 둘은 상호 배타적이에요.

리스너는 모든 인터페이스(IPv4는 0.0.0.0, IPv6는 ::)에서 노출돼요.

호스트 네트워크 모드는 Helm으로 활성화할 수 있어요:

ingressController:
  enabled: true
  hostNetwork:
    enabled: true

활성화하면 호스트 네트워크 포트를 다음 방법으로 지정할 수 있어요:

공유 Ingress: Helm 플래그로 전역 설정
- ingressController.hostNetwork.sharedListenerPort: Cilium ingress 컨트롤러 Envoy 리스너를 노출할 호스트 네트워크 포트예요. 기본 포트는 8080이에요. 변경한다면 1023보다 높은 포트 번호를 선택해야 해요 (Bind to privileged port 참고).
- ingressController.hostNetwork.httpPort: 공유 HTTP 리스너를 노출할 호스트 네트워크 포트예요. 설정하지 않거나 0이면 sharedListenerPort가 사용돼요.
- ingressController.hostNetwork.httpsPort: 공유 HTTPS 리스너를 노출할 호스트 네트워크 포트예요. 설정하지 않거나 0이면 sharedListenerPort가 사용돼요.
- ingressController.hostNetwork.tlsPassthroughPort: 공유 TLS 패스스루 리스너를 노출할 호스트 네트워크 포트예요. 설정하지 않거나 0이면 sharedListenerPort가 사용돼요.
전용 Ingress: 어노테이션으로 Ingress 리소스별 설정
- ingress.cilium.io/host-listener-port: Cilium ingress 컨트롤러 Envoy 리스너를 노출할 호스트 네트워크 포트예요. 기본 포트는 8080이지만, Ingress 리소스마다 고유해야 하므로 단일 Ingress 리소스에만 사용할 수 있어요. 1023보다 높은 포트를 선택해야 해요 (Bind to privileged port 참고). 이 어노테이션은 전역 Cilium ingress 컨트롤러 모드가 dedicated(ingressController.loadbalancerMode)로 구성됐거나, ingress 리소스가 ingress.cilium.io/loadbalancer-mode 어노테이션을 dedicated로 설정하고 여러 Ingress 리소스가 배포된 경우 필수예요.

공유 또는 전용 ingress에 대한 기본 동작은 ingressController.loadbalancerMode로 구성할 수 있어요.

경고

잘못 구성하면 포트 충돌이 발생할 수 있다는 점을 유의해주세요. Cilium ingress 컨트롤러 Envoy 리스너가 노출되는 모든 Cilium 노드에서 아직 사용 가능한 고유 포트를 구성하세요.

특권(privileged) 포트 바인딩 (Bind to privileged port)

기본적으로 Cilium L7 Envoy 프로세스는 out-of-the-box로 Linux 능력(capabilities)이 없어서 특권 포트에서 수신할 수 없어요.

1023 이하의 포트를 선택한다면, Helm 값 envoy.securityContext.capabilities.keepCapNetBindService=true를 구성하고 해당 Cilium Envoy 컨테이너에 NET_BIND_SERVICE 능력을 추가해야 해요 (Helm values로요):

독립 DaemonSet 모드: envoy.securityContext.capabilities.envoy
임베디드 모드: securityContext.capabilities.ciliumAgent

호스트 네트워크 모드에서 특권 포트 바인딩을 허용하려면 다음 Helm 값들을 구성해주세요:

ingressController:
  enabled: true
  hostNetwork:
    enabled: true
envoy:
  enabled: true
  securityContext:
    capabilities:
      keepCapNetBindService: true
      envoy:
      # Add NET_BIND_SERVICE to the list (keep the others!)
      - NET_BIND_SERVICE

ingressController:
  enabled: true
  hostNetwork:
    enabled: true
envoy:
  securityContext:
    capabilities:
      keepCapNetBindService: true
securityContext:
  capabilities:
    ciliumAgent:
    # Add NET_BIND_SERVICE to the list (keep the others!)
    - NET_BIND_SERVICE

노드 부분 집합에 Cilium Ingress 리스너 배포하기 (Deploy Cilium Ingress listeners on subset of nodes)

Cilium ingress 컨트롤러 Envoy 리스너는 노드의 특정 부분 집합에서만 노출할 수 있어요. 이는 호스트 네트워크 모드와 결합해서만 동작하며, Helm values의 노드 레이블 셀렉터로 구성할 수 있어요:

ingressController:
  enabled: true
  hostNetwork:
    enabled: true
    nodes:
      matchLabels:
        role: infra
        component: ingress

이렇게 하면 구성된 레이블과 일치하는 Cilium 노드에서만 Ingress Controller Envoy 리스너가 배포돼요. 빈 셀렉터는 모든 노드를 선택하며 모든 Cilium 노드에서 계속 기능을 노출해요.

예제 (Examples)

Cilium의 Ingress 기능을 사용하고 활용하는 방법은 아래 예제 중 하나를 참고해주세요:

Ingress HTTP 예제
Ingress and Network Policy 예제
External Lock-down Policy
Default Deny Ingress Policy
Ingress Path Types 예제
Ingress gRPC 예제
TLS 종료가 있는 Ingress 예제
Ingress용 Defaults certificate

더 알아보기 (Learn more)

HTTP Ingress 예제 — HTTP Ingress 예제
Ingress gRPC 예제 — gRPC Ingress 예제
Ingress 참조 — Ingress 어노테이션 참조
Cilium Gateway API — Cilium Gateway API 개요

Kubernetes Ingress 지원