13. [istio-internals] Pilot-agent - 사이드카 컨테이너

1. 서론

 
이번 포스팅에서는 이전 포스팅 내용에 이어서 Sidecar Injector에 의해 주입된 사이드카 컨테이너에 대해서 살펴보겠습니다. 
 

---

2. 사이드카 컨테이너

 
이전 포스팅에서 Application Pod에 주입된 init-container에 대해서 살펴봤습니다. init-container는 말 그대로 원래 기동하고자하는 컨테이너 기동 전에 사전 작업 설정을 위해서 잠시 실행되는 임시 컨테이너입니다. 따라서 iptables 등을 조작해서 Application 컨테이너가 기동할 수 있는 환경을 만든 이후 해당 컨테이너는 종료됩니다.
 
이번에는 본격적으로 주입된 사이드카 컨테이너의 Yaml 내용을 살펴보면서, 어떤 설정이 추가되었는지 살펴보겠습니다.
 

  - args:
    - proxy
    - sidecar
    - --domain
    - $(POD_NAMESPACE).svc.cluster.local
    - --proxyLogLevel=warning
    - --proxyComponentLogLevel=misc:error
    - --log_output_level=default:info
    - --concurrency
    - "2"
    env:
    - name: JWT_POLICY
      value: third-party-jwt
    - name: PILOT_CERT_PROVIDER
      value: istiod
    - name: CA_ADDR
      value: istiod.istio-system.svc:15012
    - name: POD_NAME
      valueFrom:
        fieldRef:
          fieldPath: metadata.name
    - name: POD_NAMESPACE
      valueFrom:
        fieldRef:
          fieldPath: metadata.namespace
    - name: INSTANCE_IP
      valueFrom:
        fieldRef:
          fieldPath: status.podIP
    - name: SERVICE_ACCOUNT
      valueFrom:
        fieldRef:
          fieldPath: spec.serviceAccountName
    - name: HOST_IP
      valueFrom:
        fieldRef:
          fieldPath: status.hostIP
    - name: PROXY_CONFIG
      value: |
        {}          
    - name: ISTIO_META_POD_PORTS
      value: |-
        [
        ]
    - name: ISTIO_META_APP_CONTAINERS
      value: nginx
    - name: ISTIO_META_CLUSTER_ID
      value: Kubernetes
    - name: ISTIO_META_INTERCEPTION_MODE
      value: REDIRECT
    - name: ISTIO_META_WORKLOAD_NAME
      value: nginx
    - name: ISTIO_META_OWNER
      value: kubernetes://apis/v1/namespaces/default/pods/nginx
    - name: ISTIO_META_MESH_ID
      value: cluster.local
    - name: TRUST_DOMAIN
      value: cluster.local
    image: docker.io/istio/proxyv2:1.14.2
    name: istio-proxy
    ports:
    - containerPort: 15090
      name: http-envoy-prom
      protocol: TCP
    readinessProbe:
      failureThreshold: 30
      httpGet:
        path: /healthz/ready
        port: 15021
      initialDelaySeconds: 1
      periodSeconds: 2
      timeoutSeconds: 3
    resources:
      limits:
        cpu: "2"
        memory: 1Gi
      requests:
        cpu: 10m
        memory: 40Mi
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
        - ALL
      privileged: false
      readOnlyRootFilesystem: true
      runAsGroup: 1337
      runAsNonRoot: true
      runAsUser: 1337

 
위 코드는 사이드카로 추가된 istio-proxy 부분만 발췌한 코드입니다.  해당 코드에서 중요한 내용만 추려가면서 살펴보겠습니다.
 

    image: docker.io/istio/proxyv2:1.14.2
    name: istio-proxy

 
먼저 살펴볼 부분은 해당 컨테이너의 이미지입니다. 이는 이전에 init-container에서 사용했던 이미지와 동일함을 알 수 있습니다. 따라서 기동 시점에 pilot-agent 프로그램이 수행되는 것을 알 수 있습니다.
 

---

    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
        - ALL
      privileged: false
      readOnlyRootFilesystem: true
      runAsGroup: 1337
      runAsNonRoot: true
      runAsUser: 1337

 
두 번째로 살펴볼 것은 securityContext입니다.
 
init-container에는 iptables를 조작해야했기 때문에 root와 NET_ADMIN, NET_RAW와 같은 capability가 필요했는데, 사이드카 컨테이너에서는 이미 iptables 변경이 완료되었기 때문에 더 이상 root로 실행시키지 않으며, capabilities도 모두 삭제하도록 되어있음을 확인할 수 있습니다.
 

---

  - args:
    - proxy
    - sidecar
    - --domain
    - $(POD_NAMESPACE).svc.cluster.local
    - --proxyLogLevel=warning
    - --proxyComponentLogLevel=misc:error
    - --log_output_level=default:info
    - --concurrency
    - "2"

 
세 번째로 살펴볼 것은 argument입니다. 인자를 통해서 해당 프로그램이 proxy로 기동됨을 전달합니다. 여기서 살펴볼 점은 argument를 통해서 sidecar 인자를 넘겨줌에 따라 해당 Container가 sidecar proxy로 기동될 것임을 전달합니다.
 
두번째 중요한 정보는 --concurrency입니다. 이전에 envoy 아키텍처 포스팅에서 확인하였듯이. conccurency는 Worker 쓰레드의 개수를 의미합니다. 즉 해당 envoy proxy는 Master와 2개의 Worker 쓰레드가 구성되어 동작함을 유추할 수 있습니다.

---

3. Pilot-Agent 기동 과정

 
지금까지 YAML 내용을 살펴보면서 sidecar injector에 의해 주입된 사이드카 컨테이너의 주요 설정에 대해서 알아봤습니다. 이번에는 주입된 컨테이너 내부를 살펴보면서 어떻게 동작하는지를 살펴보고자 합니다.
 

 
 
사이드카 컨테이너 내부에는 pilot-agent 프로그램이 존재합니다. 따라서 해당 프로그램이 먼저 기동됩니다. 이때 pilot-agent 내부에는 여러가지 컴포넌트가 존재하는데, 그 중 가장 핵심은 XDS Proxy 입니다.
 
 

 
XDS Proxy는 Envoy Proxy와 istiod의 pilot-discovery의 통신을 중개하는 역할을 담당하는 컴포넌트로써 Envoy에서의 요청사항을 pilot-discovery에 전달하고 pilot-discovery로부터 전달되는 응답값을 Envoy에게 다시 전달하는 역할을 수행합니다. 이때 내부 Envoy와의 통신은 Unix Domain Socket으로 수행하며 pilot-discovery와는 gRPC를 통해 요청을 주고 받는 것이 특징입니다.
 
Local DNS Server는 istio의 ServiceEntry에서 DNS에 등록되지 않은 host명으로 입력한 경우 올바르게 Resolution되지 않습니다. 이때 내부 Local DNS Server를 둠으로써 Kubernetes 외부에 위치한 Service에 대해서도 DNS 결과를 제공하기 위해 제공되는 서버입니다. 해당 서버는 ISTIO_META_DNS_CAPTURE 환경 변수 여부에 따라 기동 여부가 결정되며, 기본적으로는 false이므로 기동되지 않습니다. 이와 관련한 자세한 내용은 아래 공식문서를 참고하시기 바랍니다.
 
https://istio.io/latest/docs/ops/configuration/traffic-management/dns-proxy/

DNS Proxying

 
SDS Server는 istio에서 제공하는 mTLS 기능 구현을 위해 CA에게 인증서를 요청하고 제공된 인증서를 관리하기 위한 서버입니다. 해당 컴포넌트에 대해서는 추후 다른 포스팅을 통해 다루어보겠습니다.
 
Pilot-Agent 내부에 속한 주요 컴포넌트에 대해 간략하게 살펴봤습니다. 지금부터는 envoy와 xds proxy를 중점으로 구동 과정을 살펴보겠습니다.
 

3-1 Proxy 초기화

 

 
pilot-agent가 기동될 때 가장 먼저 수행하는 것은 Proxy 생성을 위한 초기화 작업입니다. 사이드카 컨테이너의 YAML을 살펴보면 위 그림과 같이 Pod의 IP와 이름 그리고 namespace가 환경변수로 주입된 것을 확인할 수 있는데, 해당 값등을 조합하여 Proxy 설정을 진행합니다.
 

  - args:
    - proxy
    - sidecar
    - --domain
    - $(POD_NAMESPACE).svc.cluster.local
    - --proxyLogLevel=warning
    - --proxyComponentLogLevel=misc:error
    - --log_output_level=default:info
    - --concurrency
    - "2"

 
Proxy 초기화 과정에서는 입력된 IP와 namespace를 지정하는 것 외에도 ID와 DNS Domain을 수행하는데, ID는 입력된 POD_NAME + "." + POD_NAMESPACE로 지정됩니다. 반면 DNS Domain의 경우 위와 같이 Argument에 --domain 인자로 값이 입력되었으면, 해당 값이 사용되고 입력되지 않았을 경우에는 POD_NAMESPACE + ".svc.cluster.loocal" 이 사용됩니다.
 
 

---

3-2 Proxy Config 설정

 

 
Proxy 초기화 이후 수행 작업은 Proxy Config를 설정하는 것입니다. 이때 Proxy Config를 구성하기 위해 세 군데에서 입력되는 정보들을 조합하기 위해 값을 읽어들입니다. 
 
Pod에 입력한 annotation 정보들은 kubernetes의 downwardAPI에 의하여 Pod 내부 /etc/istio/pod/annotations 경로에 Mount 됩니다. 해당 정보는 pilot-agent가 기동하면서 참조할 수 있으며, 이를 통해 annotation 정보를 추출할 수 있습니다. 여기서 annotation 중 proxy.istio.io/config 값은 Pod의 Proxy Config를 설정할 수 있습니다. 따라서 Proxy Config를 구성하는 과정에서 해당 정보를 참고합니다.
 
두 번째는 Pod 내부에 /etc/istio/config/mesh에 Proxy Config 정보를 위한 파일을 mount 했다면, 해당 정보를 읽어들여서 Proxy Config를 구성합니다.
 
세 번째는 환경 변수로 입력한 PROXY_CONFIG 정보를 참조하는 것입니다. 해당 정보는 sidecar injector에 의해서 주입된 정보이며, Global Proxy Config 설정을 했다면, sidecar injector가 Pod의 YAML을 조작하는 과정에서 해당 정보가 주입됩니다.
 

 
위 세 정보를 추출한 이후에는 Proxy Config를 구성합니다. 이때 pilot-agent 내부에 별도 Default Config가 존재하며, Default Config 외에 입력된 세 가지 Config 정보를 차례 차례로 merge 하여 구성합니다. 이때 위 그림과 같은 순서대로 merge 작업을 수행하며, 같은 값이 존재하는 경우에는 덮어씁니다. 따라서 우선순위 기준으로 보면 Pod에 부착된 어노테이션이 가장 높습니다.
 

---