Local Redirect Policy

Local Redirect Policy (로컬 리다이렉트 정책)

Local Redirect Policy는 파드 트래픽(IP 주소와 포트/프로토콜 튜플 또는 Kubernetes 서비스로 향하는 트래픽)을 eBPF를 사용해 노드 안의 로컬 백엔드 파드로 리다이렉트할 수 있게 해줘요. 노드 로컬 DNS 캐시 같은 사용 사례에 유용해요.

출처: Local Redirect Policy

본문

이 문서는 Cilium의 Local Redirect Policy를 구성하는 방법을 설명해요. 이 기능은 IP 주소와 포트/프로토콜 튜플 또는 Kubernetes 서비스로 향하는 파드 트래픽을 eBPF를 사용해 노드 안의 로컬 백엔드 파드로 리다이렉트할 수 있게 해줘요. 백엔드 파드의 네임스페이스는 정책의 네임스페이스와 일치해야 해요. CiliumLocalRedirectPolicy는 CustomResourceDefinition으로 구성돼요.

Video 이 문서 외에도 eCHO episode 39: Local Redirect Policy에서 Cilium의 Local Redirect Policy에 대한 비디오 설명을 볼 수 있어요.

지원되는 두 가지 유형의 Local Redirect Policy가 있어요. Kubernetes 서비스에 대한 트래픽을 리다이렉트해야 할 때는 ServiceMatcher 유형을 사용하세요. 서비스는 clusterIP 타입이어야 해요. 어떤 Kubernetes 서비스에도 속하지 않는 IP 주소와 포트/프로토콜과 매칭되는 트래픽을 리다이렉트해야 할 때는 AddressMatcher 유형을 사용하세요.

정책은 Kubernetes 역할 기반 접근 제어(RBAC) 프레임워크로 게이트할 수 있어요. 공식 RBAC 문서를 참고하세요.

정책이 적용되면 매칭된 파드 트래픽이 리다이렉트돼요. 원한다면 애플리케이션 개발자가 리다이렉션을 벗어날 수 없도록 RBAC 구성을 사용할 수 있어요.

사전 요구 사항 (Prerequisites)

Helm 저장소를 설정하세요:

Helm Repository OCI Registry

helm repo add cilium https://helm.cilium.io/

Cilium 차트는 OCI 레지스트리(Quay.io 및 Docker Hub)에서도 사용할 수 있어요. 설정이 필요 없으며 oci:// URL로 직접 설치할 수 있어요.

차트 서명 검증과 digest 기반 설치를 포함한 자세한 내용은 OCI Registry section을 참고하세요.

localRedirectPolicies.enabled 값을 true로 설정해 기능을 활성화하세요.

Helm Repository OCI Registry

helm upgrade cilium cilium/cilium --version 1.20.2 \
   --namespace kube-system \
   --reuse-values \
   --set localRedirectPolicies.enabled=true

helm upgrade cilium oci://quay.io/cilium/charts/cilium 1.20.2 \
   --namespace kube-system \
   --reuse-values \
   --set localRedirectPolicies.enabled=true

변경 사항을 적용하려면 operator와 agent 파드를 롤아웃하세요:

$ kubectl rollout restart deploy cilium-operator -n kube-system
$ kubectl rollout restart ds cilium -n kube-system

Cilium agent와 operator 파드가 실행 중인지 확인하세요.

$ kubectl -n kube-system get pods -l k8s-app=cilium
NAME           READY   STATUS    RESTARTS   AGE
cilium-5ngzd   1/1     Running   0          3m19s

$ kubectl -n kube-system get pods -l name=cilium-operator
NAME                               READY   STATUS    RESTARTS   AGE
cilium-operator-544b4d5cdd-qxvpv   1/1     Running   0          3m19s

Cilium Local Redirect Policy CRD가 등록됐는지 검증하세요.

$ kubectl get crds
NAME                              CREATED AT
[...]
ciliumlocalredirectpolicies.cilium.io              2020-08-24T05:31:47Z

Note Local Redirect Policy는 socket-level loadbalancer 또는 tc loadbalancer를 지원해요. 구성은 특정 사용 사례와 필요한 서비스 처리 유형에 따라 달라져요. 아래는 localRedirectPolicies.enabled=true와 함께 동작하는 Helm 설정들이에요:

전체 kube-proxy replacement 활성화:

kube-proxy를 Cilium의 eBPF 구현으로 교체하고 Local Redirect Policy를 활용하려는 사용자를 위한 설정이에요.
kubeProxyReplacement: true
localRedirectPolicies:
  enabled: true
파드 네임스페이스에서 socket-level loadbalancer 우회:

파드 네임스페이스에서 socket-level loadbalancer를 비활성화하려는 사용자를 위한 설정이에요. 예를 들어 socket-level load balancer와 충돌하는 파드 네임스페이스의 커스텀 리다이렉션 규칙이 있다면 필요할 수 있어요.
kubeProxyReplacement: true
socketLB:
  hostNamespaceOnly: true
localRedirectPolicies:
  enabled: true
socket-level loadbalancer만 활성화:

전체 서비스 처리를 위해 kube-proxy를 유지하면서도 Cilium의 Local Redirect Policy를 활용하려는 사용자를 위한 설정이에요.
kubeProxyReplacement: false
socketLB:
  enabled: true
localRedirectPolicies:
  enabled: true
파드에서 접근하는 ClusterIP 서비스를 제외한 모든 서비스 처리를 비활성화:

서비스 처리를 전적으로 kube-proxy에 맡기려면, 파드 네임스페이스에서 접근하는 ClusterIP 서비스를 제외한 모든 kube-proxy replacement 기능을 비활성화할 수 있어요. 이 설정에서는 호스트 네임스페이스에서 오는 파드 트래픽은 Local Redirect Policy로 처리되지 않는다는 점에 주의하세요.
kubeProxyReplacement: false
localRedirectPolicies:
  enabled: true

백엔드 및 클라이언트 파드 생성 (Create backend and client pods)

CiliumLocalRedirectPolicy에 지정된 구성에 따라 트래픽이 리다이렉트될 백엔드 파드를 배포하세요. 메타데이터 라벨과 컨테이너 포트 및 프로토콜은 각각 다음 단계에서 생성할 CiliumLocalRedirectPolicy 커스텀 리소스에 지정된 라벨, 포트 및 프로토콜 필드와 일치해요.

apiVersion: v1
kind: Pod
metadata:
  name: lrp-pod
  labels:
    app: proxy
spec:
  containers:
    - name: lrp-pod
      image: nginx
      ports:
        - containerPort: 80
          name: tcp
          protocol: TCP

$ kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/1.20.2/examples/kubernetes-local-redirect/backend-pod.yaml

파드가 실행 중인지 확인하세요.

$ kubectl get pods | grep lrp-pod
lrp-pod                      1/1     Running   0          46s

CiliumLocalRedirectPolicy에 지정된 구성에 따라 리다이렉트될 트래픽을 생성할 클라이언트 파드를 배포하세요.

$ kubectl create -f https://raw.githubusercontent.com/cilium/cilium/1.20.2/examples/kubernetes-dns/dns-sw-app.yaml
$ kubectl wait pod/mediabot --for=condition=Ready
$ kubectl get pods
NAME                             READY   STATUS    RESTARTS   AGE
pod/mediabot                     1/1     Running   0          14s

Cilium Local Redirect Policy 커스텀 리소스 생성 (Create Cilium Local Redirect Policy Custom Resources)

리다이렉트할 트래픽을 매칭하기 위해 CiliumLocalRedirectPolicy에서 지원되는 두 가지 유형의 구성이 있어요.

AddressMatcher

이 유형의 구성은 IP 주소와 Layer 4 포트/프로토콜로 지정돼요. toPorts에서 frontend에 대해 여러 포트가 지정되면 포트에 이름을 지정해야 해요. 포트 이름은 frontend 포트와 backend 포트를 매핑하는 데 사용돼요.

redirectBackend 아래 toPorts에 지정된 포트가 백엔드 파드 spec에 존재하는지 확인하세요.

예제는 IP 주소 169.254.169.254와 프로토콜 TCP의 Layer 4 포트 8080과 매칭되는 트래픽을, 라벨 app=proxy와 프로토콜 TCP의 Layer 4 포트 80으로 배포된 백엔드 파드로 리다이렉트하는 방법을 보여줘요. 정책에서 app=proxy로 설정된 localEndpointSelector는 트래픽이 리다이렉트될 백엔드 파드를 선택하는 데 사용돼요.

addressMatcher 구성으로 type CiliumLocalRedirectPolicy의 커스텀 리소스를 생성하세요.

apiVersion: "cilium.io/v2"
kind: CiliumLocalRedirectPolicy
metadata:
  name: "lrp-addr"
spec:
  redirectFrontend:
    addressMatcher:
      ip: "169.254.169.254"
      toPorts:
        - port: "8080"
          protocol: TCP
  redirectBackend:
    localEndpointSelector:
      matchLabels:
        app: proxy
    toPorts:
      - port: "80"
        protocol: TCP

$ kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/1.20.2/examples/kubernetes-local-redirect/lrp-addrmatcher.yaml

커스텀 리소스가 생성됐는지 확인하세요.

$ kubectl get ciliumlocalredirectpolicies | grep lrp-addr
NAME           AGE
lrp-addr       20h

Cilium의 eBPF kube-proxy replacement가 정책이 선택한 lrp-pod의 백엔드 IP 주소로 LocalRedirect 서비스 항목을 생성했는지 확인하세요. cilium-dbg service list를 lrp-pod와 같은 노드에서 실행 중인 Cilium pod에서 실행해야 해요.

$ kubectl describe pod lrp-pod  | grep 'IP:'
IP:           10.16.70.187

$ kubectl exec -it -n kube-system cilium-5ngzd -- cilium-dbg service list
ID   Frontend               Service Type       Backend
[...]
4    172.20.0.51:80         LocalRedirect      1 => 10.16.70.187:80

클라이언트 파드에서 위 lrp-addr 커스텀 리소스에 지정된 IP 주소와 포트 구성으로 curl 명령을 호출하세요.

$ kubectl exec mediabot -- curl -I -s http://169.254.169.254:8080/index.html
HTTP/1.1 200 OK
Server: nginx/1.19.2
Date: Fri, 28 Aug 2020 01:33:34 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Tue, 11 Aug 2020 14:50:35 GMT
Connection: keep-alive
ETag: "5f32b03b-264"
Accept-Ranges: bytes

트래픽이 배포된 lrp-pod로 리다이렉트됐는지 확인하세요. tcpdump는 lrp-pod가 실행 중인 노드에서 실행해야 해요.

$ sudo tcpdump -i any -n port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
01:36:24.608566 IP 10.16.215.55.60876 > 10.16.70.187.80: Flags [S], seq 2119454273, win 28200, options [mss 1410,sackOK,TS val 2541637677 ecr 0,nop,wscale 7], length 0
01:36:24.608600 IP 10.16.70.187.80 > 10.16.215.55.60876: Flags [S.], seq 1315636594, ack 2119454274, win 27960, options [mss 1410,sackOK,TS val 2962246962 ecr 2541637677,nop,wscale 7], length 0
01:36:24.608638 IP 10.16.215.55.60876 > 10.16.70.187.80: Flags [.], ack 1, win 221, options [nop,nop,TS val 2541637677 ecr 2962246962], length 0
01:36:24.608867 IP 10.16.215.55.60876 > 10.16.70.187.80: Flags [P.], seq 1:96, ack 1, win 221, options [nop,nop,TS val 2541637677 ecr 2962246962], length 95: HTTP: HEAD /index.html HTTP/1.1
01:36:24.608876 IP 10.16.70.187.80 > 10.16.215.55.60876: Flags [.], ack 96, win 219, options [nop,nop,TS val 2962246962 ecr 2541637677], length 0
01:36:24.609007 IP 10.16.70.187.80 > 10.16.215.55.60876: Flags [P.], seq 1:239, ack 96, win 219, options [nop,nop,TS val 2962246962 ecr 2541637677], length 238: HTTP: HTTP/1.1 200 OK
01:36:24.609052 IP 10.16.215.55.60876 > 10.16.70.187.80: Flags [.], ack 239, win 229, options [nop,nop,TS val 2541637677 ecr 2962246962], length 0

허용된 주소는 localRedirectPolicies.addressMatcherCIDRs helm 옵션으로 클러스터 전체에서 제한할 수 있어요:

localRedirectPolicies:
  enabled: true
  addressMatchCIDRs:
      - 169.254.169.254/32

위 설정은 169.254.169.254로 가는 트래픽만 AddressMatcher 규칙으로 리다이렉트되도록 허용해요. 허용되지 않은 주소가 있는 정책은 거부되고 cilium-agent가 경고 로그 메시지를 내보내요.

Note AddressMatcher는 Kubernetes Service에 속하지 않는 IP를 위한 것이에요. redirectFrontend.addressMatcher의 IP와 포트/프로토콜이 기존 ClusterIP Service frontend와 일치하면 그 정책은 그 주소에 적용되지 않아요. Cilium은 다른 Service가 소유한 frontend를 재정의하기를 거부하고 다음을 로그해요:
LocalRedirectPolicy matches an address owned by an existing service => refusing to override
Service로 향하는 트래픽을 리다이렉트하려면 대신 ServiceMatcher를 사용하세요.

ServiceMatcher

이 유형의 구성은 트래픽을 리다이렉트할 Kubernetes 서비스 이름과 네임스페이스로 지정돼요. 서비스는 clusterIP 타입이어야 해요. redirectFrontend 아래 toPorts를 지정하지 않으면 모든 서비스 포트에 대한 트래픽이 리다이렉트돼요. 그러나 포트의 하위 집합으로 향하는 트래픽만 리다이렉트해야 한다면 그 포트들을 spec에 지정해야 해요. 또한 spec에 여러 서비스 포트가 지정되면 이름을 지정해야 해요. 포트 이름은 frontend 포트와 backend 포트를 매핑하는 데 사용돼요. redirectBackend 아래 toPorts에 지정된 포트가 백엔드 파드 spec에 존재하는지 확인하세요. 정책에서 app=proxy로 설정된 localEndpointSelector는 트래픽이 리다이렉트될 백엔드 파드를 선택하는 데 사용돼요.

이 유형의 정책이 적용되면 Cilium의 eBPF kube-proxy replacement가 생성한 기존 서비스 항목이 LocalRedirect 타입의 새 서비스 항목으로 교체돼요. 이 항목은 노드 로컬 백엔드 파드만 가질 수 있어요.

예제는 my-service와 매칭되는 트래픽을, 라벨 app=proxy와 프로토콜 TCP의 Layer 4 포트 80으로 배포된 백엔드 파드로 리다이렉트하는 방법을 보여줘요. 정책에서 app=proxy로 설정된 localEndpointSelector는 트래픽이 리다이렉트될 백엔드 파드를 선택하는 데 사용돼요.

트래픽을 리다이렉트할 Kubernetes 서비스를 배포하세요.

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
    - name: tcp
      protocol: TCP
      port: 80

$ kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/1.20.2/examples/kubernetes-local-redirect/k8s-svc.yaml

서비스가 생성됐는지 확인하세요.

$ kubectl get service | grep 'my-service'
my-service   ClusterIP   172.20.0.51   <none>        80/TCP     2d7h

Cilium의 eBPF kube-proxy replacement가 ClusterIP 서비스 항목을 생성했는지 확인하세요.

$ kubectl exec -it -n kube-system ds/cilium -- cilium-dbg service list
ID   Frontend               Service Type   Backend
[...]
4    172.20.0.51:80         ClusterIP

serviceMatcher 구성으로 type CiliumLocalRedirectPolicy의 커스텀 리소스를 생성하세요.

apiVersion: "cilium.io/v2"
kind: CiliumLocalRedirectPolicy
metadata:
  name: "lrp-svc"
spec:
  redirectFrontend:
    serviceMatcher:
      serviceName: my-service
      namespace: default
  redirectBackend:
    localEndpointSelector:
      matchLabels:
        app: proxy
    toPorts:
      - port: "80"
        protocol: TCP

$ kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/1.20.2/examples/kubernetes-local-redirect/lrp-svcmatcher.yaml

커스텀 리소스가 생성됐는지 확인하세요.

$ kubectl get ciliumlocalredirectpolicies | grep svc
NAME               AGE
lrp-svc   20h

Cilium의 eBPF kube-proxy replacement가 서비스 항목을 LocalRedirect 타입과 정책이 선택한 노드 로컬 백엔드로 업데이트했는지 확인하세요. cilium-dbg service list를 lrp-pod와 같은 노드에서 실행 중인 Cilium pod에서 실행해야 해요.

$ kubectl exec -it -n kube-system cilium-5ngzd -- cilium-dbg service list
ID   Frontend               Service Type       Backend
[...]
4    172.20.0.51:80         LocalRedirect      1 => 10.16.70.187:80

클라이언트 파드에서 위 lrp-svc 커스텀 리소스에 지정된 my-service의 Cluster IP 주소와 포트로 curl 명령을 호출하세요.

$ kubectl exec mediabot -- curl -I -s http://172.20.0.51/index.html
HTTP/1.1 200 OK
Server: nginx/1.19.2
Date: Fri, 28 Aug 2020 01:50:50 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Tue, 11 Aug 2020 14:50:35 GMT
Connection: keep-alive
ETag: "5f32b03b-264"
Accept-Ranges: bytes

트래픽이 배포된 lrp-pod로 리다이렉트됐는지 확인하세요. tcpdump는 lrp-pod가 실행 중인 노드에서 실행해야 해요.

$ kubectl describe pod lrp-pod  | grep 'IP:'
IP:           10.16.70.187

$ sudo tcpdump -i any -n port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
01:36:24.608566 IP 10.16.215.55.60186 > 10.16.70.187.80: Flags [S], seq 2119454273, win 28200, options [mss 1410,sackOK,TS val 2541637677 ecr 0,nop,wscale 7], length 0
01:36:24.608600 IP 10.16.70.187.80 > 10.16.215.55.60876: Flags [S.], seq 1315636594, ack 2119454274, win 27960, options [mss 1410,sackOK,TS val 2962246962 ecr 2541637677,nop,wscale 7], length 0
01:36:24.608638 IP 10.16.215.55.60876 > 10.16.70.187.80: Flags [.], ack 1, win 221, options [nop,nop,TS val 2541637677 ecr 2962246962], length 0
01:36:24.608867 IP 10.16.215.55.60876 > 10.16.70.187.80: Flags [P.], seq 1:96, ack 1, win 221, options [nop,nop,TS val 2541637677 ecr 2962246962], length 95: HTTP: HEAD /index.html HTTP/1.1
01:36:24.608876 IP 10.16.70.187.80 > 10.16.215.55.60876: Flags [.], ack 96, win 219, options [nop,nop,TS val 2962246962 ecr 2541637677], length 0
01:36:24.609007 IP 10.16.70.187.80 > 10.16.215.55.60876: Flags [P.], seq 1:239, ack 96, win 219, options [nop,nop,TS val 2962246962 ecr 2541637677], length 238: HTTP: HTTP/1.1 200 OK
01:36:24.609052 IP 10.16.215.55.60876 > 10.16.70.187.80: Flags [.], ack 239, win 229, options [nop,nop,TS val 2541637677 ecr 2962246962], length 0

제한 사항 (Limitations)

Local Redirect Policy를 만들면 정책이 집행된 이후에 수립되는 모든 새 연결에 대한 트래픽이 리다이렉트돼요. 그러나 정책에 지정된 구성과 매칭되는 원격 파드에 대한 기존 활성 연결이 있다면 그것들은 리다이렉트되지 않을 수 있어요. 모든 그러한 연결이 로컬로 리다이렉트되도록 하려면 CiliumLocalRedirectPolicy를 구성한 후 클라이언트 파드를 재시작하세요.

Local Redirect Policy 업데이트는 현재 지원되지 않아요. 변경할 사항이 있으면 기존 정책을 삭제하고 새 정책을 다시 생성하세요.

사용 사례 (Use Cases)

Local Redirect Policy를 사용하면 Cilium이 다음 사용 사례를 지원할 수 있어요:

노드 로컬 DNS 캐시 (Node-local DNS cache)

파드 네임스페이스에 DNS node-cache를 배포하세요.

Quick Deployment Manual Configuration DNS node-cache를 배포하세요.

Note
- 예제 yaml은 __PILLAR_LOCAL_DNS__와 __PILLAR_DNS_DOMAIN__에 대한 기본값으로 채워져 있어요.
- 다른 배포라면 공식 NodeLocal DNSCache Configuration을 따라 yaml을 적용하기 전에 필수 템플릿 변수 __PILLAR__LOCAL__DNS__, __PILLAR__DNS__DOMAIN__, __PILLAR__DNS__SERVER__를 채우세요.
```
$ wget https://raw.githubusercontent.com/cilium/cilium/1.20.2/examples/kubernetes-local-redirect/node-local-dns.yaml
```

$ kubedns=$(kubectl get svc kube-dns -n kube-system -o jsonpath={.spec.clusterIP}) && sed -i "s/PILLAR__DNS__SERVER/$kubedns/g;" node-local-dns.yaml

$ kubectl apply -f node-local-dns.yaml


 - 공식 [NodeLocal DNSCache Configuration](https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/#configuration)을 따라 yaml을 적용하기 전에 필수 템플릿 변수 `__PILLAR__LOCAL__DNS__`, `__PILLAR__DNS__DOMAIN__`, `__PILLAR__DNS__SERVER__`를 채우세요.
 - 릴리즈 버전 >= 1.15.16인 Node-local DNS 이미지를 사용해야 해요. 이는 Node-local DNS를 non-host 네임스페이스에 배포할 때 더미 네트워크 인터페이스 생성/삭제를 비활성화하는 노브가 있는지 확인하기 위해서예요.
 - Node-local DNS cache의 deployment yaml을 수정해 node-cache에 추가 인자를 전달하세요: `-skipteardown=true`, `-setupinterface=false`, `-setupiptables=false`.
 - Node-local DNS cache의 deployment yaml을 수정해 daemonset의 `hostNetwork: false`를 설정해 non-host 네임스페이스에 두세요.
 - Corefile에서 정적 IP 대신 `0.0.0.0`에 바인딩하세요.
 - Corefile에서 health 플러그인 뒤의 호스트 IP 문자열을 제거해 CoreDNS가 정적 IP 대신 자신의 IP에서 health-check를 제공하게 하세요.
 - Node-local DNS cache의 deployment yaml을 수정해 `readinessProbe` 아래의 `host` 필드를 제거해서 readiness probe를 자신의 IP로 가리키게 하세요.

- DNS 트래픽을 노드 로컬 dns cache로 보내도록 Local Redirect Policy(LRP)를 배포하세요.

$ kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/1.20.2/examples/kubernetes-local-redirect/node-local-dns-lrp.yaml


> **Note**
- 위 LRP는 클러스터 DNS 서비스로 `kube-dns`를 사용해요. 그러나 클러스터 DNS 서비스가 다르다면 이 예제 LRP를 수정해 그 서비스를 지정해야 해요.
- 위 LRP에 지정된 네임스페이스는 클러스터의 dns 서비스와 같은 네임스페이스로 설정돼요.
- 위 LRP는 예제 quick deployment yaml과 같은 포트 이름 `dns`와 `dns-tcp`를 사용해요. 다르다면 배포와 일치하도록 수정해야 해요.

모든 `node-local-dns` 파드가 ready 상태가 되면 DNS 트래픽은 이제 로컬 node-cache로 먼저 가요. `<node-local-dns pod IP>:9253/metrics`를 curl해 DNS cache의 메트릭 `coredns_dns_requests_total`을 확인해 검증할 수 있어요. 애플리케이션 파드에서 새 DNS 요청이 발행되면 `node-local-dns` 파드로 리다이렉트되므로 이 메트릭이 증가해야 해요.

node-local DNS cache가 없을 때 애플리케이션 파드의 DNS 쿼리는 `kube-dns` 서비스가 백업하는 클러스터 DNS 파드로 전달돼요.

- 트러블슈팅

> DNS 요청이 해석에 실패하면 다음을 확인하세요:
> - node-local DNS cache 파드가 실행 중이고 ready인지 확인하세요.
>
> ```
> $ kubectl --namespace kube-system get pods --selector=k8s-app=node-local-dns
> NAME                   READY   STATUS    RESTARTS   AGE
> node-local-dns-72r7m   1/1     Running   0          2d2h
> node-local-dns-gc5bx   1/1     Running   0          2d2h
> ```
> - local redirect policy가 모든 cilium agent 파드에 올바르게 적용됐는지 확인하세요.
>
> ```
> $ kubectl exec -it cilium-mhnhz -n kube-system -- cilium-dbg lrp list
> LRP namespace   LRP name       FrontendType                Matching Service
> kube-system     nodelocaldns   clusterIP + all svc ports   kube-system/kube-dns
>                 |              10.96.0.10:53/UDP -> 10.244.1.49:53(kube-system/node-local-dns-72r7m),
>                 |              10.96.0.10:53/TCP -> 10.244.1.49:53(kube-system/node-local-dns-72r7m),
> ```
> - 해당 local redirect service 항목이 생성됐는지 확인하세요. 서비스 항목이 없으면 정책과 node-local DNS DaemonSet pod 리소스를 적용할 때 경쟁 조건(race condition)이 있었을 수 있어요. 해결 방법으로 node-local DNS DaemonSet 파드를 재시작할 수 있어요. 문제가 지속되면 [sysdump](../../../operations/troubleshooting/#sysdump)와 함께 [GitHub issue](https://github.com/cilium/cilium/issues/new/choose)를 제기하세요.
>
> ```
> $ kubectl exec -it cilium-mhnhz -n kube-system -- cilium-dbg service list | grep LocalRedirect
> 11   10.96.0.10:53      LocalRedirect   1 => 10.244.1.49:53 (active)
> ```

### 고급 구성 (Advanced configurations)

local redirect policy가 적용되면 cilium BPF 데이터 경로가 정책 frontend(ip/port/protocol 튜플로 식별) 주소로 가는 트래픽을 정책이 선택한 노드 로컬 백엔드 파드로 리다이렉트해요. 그러나 노드 로컬 백엔드 파드에서 시작되어 정책 frontend로 향하는 트래픽에 대해서는, 사용자가 트래픽을 노드 로컬 백엔드 파드로 다시 리다이렉트하는 것을 건너뛰고 대신 원래 frontend로 전달하고 싶을 수 있어요. 이 동작은 local redirect policy spec에서 `skipRedirectFromBackend` 플래그를 `true`로 설정하면 활성화할 수 있어요. 이 구성은 Linux 커널 버전 >= 5.12에서 사용 가능한 `SO_NETNS_COOKIE` 옵션과 함께 `getsockopt()`를 사용해야 해요. `SO_NETNS_COOKIE`는 5.7에서 도입됐고(BPF 프로그램에 사용 가능) >= 5.12 버전에서 사용자 공간에 노출됐다는 점에 주의하세요.

> **Note**
> Cilium 버전 1.16.0부터 이 구성을 활성화하려면 이전에 적용된 local redirect policies와 정책이 선택한 백엔드 파드를 삭제하고 다시 생성해야 해요.

## 더 알아보기 (Learn more)

- [kube-proxy 없이 Kubernetes 운영](https://docs.cilium.io/en/stable/network/kubernetes/kubeproxy-free/)
- [Cilium 네트워크 정책](https://docs.cilium.io/en/stable/network/kubernetes/policy/)
- [NodeLocal DNSCache 구성](https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/)