들어가며

EKS 환경에서 Helm Chart를 이용해 여러 애플리케이션을 배포하다 보면, Docker Hub(registry-1.docker.io)의 이미지를 그대로 사용하는 경우가 많습니다.

그런데 NAT IP가 고정된 상태에서 노드가 자주 추가/삭제 되는 스케일 아웃/인을 반복하는 환경이라면 Docker Hub 의 Image Pull Rate Limit 에 걸릴 우려가 있습니다.

특히, 2024년 6월 30일부터 시행된 기존 규정에 따르면 인증되지 않은 사용자(anonymous)에 대해서는 6시간 동안 최대 100회의 Pull만 허용되었습니다.

2025년 4월 1일부터는 인증되지 않은 사용자의 Pull 횟수가 ‘시간당 10번’으로 제한되고, 무료 사용자(로그인 상태)도 시간당 100번까지만 이미지를 Pull할 수 있도록 제한이 더욱 강화될 예정입니다.

이런 변화는 Kubernetes 클러스터에서 노드 교체가 잦은 EKS 환경에 큰 영향을 줄 수밖에 없으며, 결과적으로 애플리케이션 배포 및 스케일링 과정에서 이미지 Pull 실패 위험을 한층 높이게 됩니다.

Pulls

Learn about pull usage and limits for Docker Hub.

Docker Documentation

따라서 개인 용도로 사용하는 케이스가 아닌 실제 프로덕션에서 Kubernetes 클러스터를 이용 중이며, Docker Hub 에 퍼블리싱된 이미지를 인증(Docker 계정)없이 사용하는 경우에는 Image Pull Rate Limit 을 마주할 확률이 더욱 커진다고 볼 수 있습니다.

이미지 캐싱에 대한 오해

"Kubernetes에서는 한 번 Pull한 이미지를 노드 레벨에서 캐싱하기 때문에, 굳이 Rate Limit 걱정을 할 필요가 없지 않을까?"라는 의문이 들 수 있습니다.

실제로 Kubelet은 기존에 Pull된 이미지를 재사용하며(imagePullPolicy 가 Always 가 아닌 이상), 설정에 따라 특정 주기에 오래된 이미지를 정리(pruning)하거나 디스크 공간이 부족하면 이미지를 제거할 수 있습니다.

다만, EKS 환경에서 Karpenter와 같은 오토스케일링 도구를 사용하는 경우 노드 자체의 생명 주기가 짧아집니다.

스팟 인스턴스가 자주 교체되거나 부하 변화에 따라 노드가 빠르게 추가/삭제되면서, 이전에 캐싱해둔 이미지를 재활용할 기회가 크게 줄어들 수밖에 없습니다. 결국 이러한 이유로 인해, Rate Limit에 걸릴 위험성이 더욱 높아지게 됩니다.

그렇다면 Docker Hub의 Rate Limit을 우회하기 위한 방법은 무엇이 있을까요?

해당 문제를 겪었을 때 들었던 방법은 몇가지가 있었습니다.

1. Docker Hub 무료 계정 사용 + imagePullSecrets 적용
   1. Docker Hub의 무료 계정을 생성하고, 이를 Kubernetes에 imagePullSecrets로 등록해 인증된 Pull을 시도하는 방법입니다.
      • 하지만 무료 계정 역시 Rate Limit이 존재하며, 장기적으로 안정적인 해결책이 아니라 판단되어 제외하였습니다.
2. 직접 ECR Private Repository에 이미지를 업로드
   1. 우리가 사용하는 이미지를 ECR Private Repository에 일일이 Push해두고, Helm Chart나 매니페스트에서 해당 Private Repository를 사용하도록 변경하는 방법입니다.
   2. 클러스터 컴포넌트나 애드온 이미지를 자주 교체하지는 않으나, 여전히 수동으로 매번 업로드·업데이트해야 한다는 점이 번거로웠습니다.
3. Docker Hub를 미러링하는 서드파티 레지스트리 사용
   1. 외부에서 Docker Hub 이미지를 미러링해주는 레지스트리를 찾아서, 해당 레지스트리를 대신 사용합니다.
   2. 하지만 서드파티 레지스트리에 대한 신뢰 문제, 장애나 중단 발생 시 치명적인 영향을 받을 수 있다는 점이 우려되었습니다.
   3. 신뢰 문제가 아니더라도 모든 퍼블릭 레지스트리에 대해서 미러링하는 서비스는 찾지 못하였습니다.

세가지 방법 중 2번(직접 업로드)를 자동화 한 형태에 가장 가까운 ECR Pull-Through Cache 가 가장 적합하다고 판단하였습니다.

ECR Pull-Through Cache 를 사용하면 ECR에서 퍼블릭 레지스트리마다 캐싱 정책을 설정한 뒤, 퍼블릭 레지스트리별로 생성된 ECR 레포지토리 주소를 통해 이미지를 Pull 할 수 있습니다.

이렇게 하면 처음 이미지를 가져올 때 ECR이 자동으로 원본 퍼블릭 레지스트리에서 이미지를 받아 ECR Private Repository에 저장하고, 이후에는 캐싱된 이미지를 통해 간편하게 운영할 수 있게 됩니다.

ECR Pull-Through Cache 의 개념 및 동작 방식

ECR Pull-Through Cache 는 특정 퍼블릭 레지스트리(예: Docker Hub)에 대해 프록시(Proxy) 처럼 동작합니다.

ECR에 이미지 요청이 들어오면 먼저 ECR 레포지토리 내부에 해당 이미지가 캐싱되어 있는지 확인하고, 없다면 퍼블릭 레지스트리에서 이미지를 자동으로 가져와 ECR에 저장합니다.

따라서 우리는 퍼블릭 레지스트리에 직접 접근 할 필요 없이 항상 ECR 레포지토리를 통해 이미지를 Pull할 수 있게 됩니다.

2025년 2월 기준, ECR Pull-Through Cache 가 지원하는 퍼블릭 레지스트리

• ECR Public Registry
• Quay (quay.io)
• Docker Hub (registry.docker.io)
• GitHub Container Registry (ghcr)
• Azure Container Registry
• GitLab Container Registry

일반적으로 대부분의 Helm Chart가 Quay, Docker Hub, GitHub Container Registry 등을 자주 사용하므로 대부분의 유즈케이스를 충분히 커버 할 수 있습니다.

ECR Pull-Through Cache 설정 방법 (웹 콘솔)

우선 웹 콘솔에서의 사용 방법을 간단히 소개합니다.

AWS ECR 서비스의 Private Registry -> Features & Settings 에서 Pull-Through Cache 규칙 설정을 접근합니다.

이후 규칙 추가를 선택합니다.

어떤 퍼블릭 레지스트리(업스트림)에 대해 규칙을 생성할지 선택 할 수 있습니다.

Docker Hub 과 GitHub Container Registry 의 경우 Public Image 에 접근하더라도 인증 정보를 사용해야하는것에 유의해야 합니다.

우선 인증이 필요하지 않은 quay.io 에 대해 먼저 설정해봅니다.

위와 같이 네임스페이스를 지정 할 수 있습니다. 웹콘솔로 진행하는경우 위와같이 quay.io 에 대한 네임스페이스는 quay 로 지정됩니다.

위와 같이 사용해도 무방하지만, 실제 업스트림 레지스트리의 네이밍을 그대로 따라가는것을 추천합니다. (예: ghcr.io , quay.io , registry.k8s.io / docker.io -> 실제 업스트림 레지스트리url 은 registry-1.docker.io 입니다)

생성을 하고 나면 위와 같이 캐시 네임스페이스가 생성됩니다.

{ACCOUNT_ID}.dkr.ecr.ap-northeast-2.amazonaws.com/quay.io/{repository}/{image}:{tag} 와 같은 형태로 이미지 Pull 요청을 하면 실제 업스트림인 quay.io/{repository}/{image}:{tag} 에서 이미지를 갖고와 캐싱해서 사용할 수 있게 됩니다.

예를들어 quay.io 레지스트리를 사용하는 argo-cd 를 테스트해보겠습니다.

캐시 규칙을 설정해두었지만 현재 ECR Private Repository 에 아무것도 없는 상태입니다.

$ aws ecr get-login-password --region ap-northeast-2 | docker login --username AWS --password-stdin {ACCOUNT_ID}.dkr.ecr.ap-northeast-2.amazonaws.com 와 같은 형태로 docker 에 ecr을 통해 인증을 하고나서

$ docker pull {ACCOUNT_ID}.dkr.ecr.ap-northeast-1.amazonaws.com/quay.io/argoproj/argocd:v2.5.6 와 같이 ECR Private Repository 를 통해 image pull 을 요청합니다. 우리가 아까 정의한 캐시 네임스페이스를 사용하는것에 유의합니다.

이렇게 하면 실제로는 해당 경로에 아직 이미지가 없지만, 설정한 캐시 규칙을 통해 업스트림 레지스트리에서 이미지를 자동으로 가져와 캐싱 네임스페이스 기반의 ECR Private Repository에 저장하게 됩니다.

이후에는 그 이미지를 곧바로 사용할 수 있습니다.

실제로 우리가 ECR Private Repository 를 직접 생성하지 않았지만. 캐시 규칙에 의해 자동으로 Private Repository 를 생성하고, 이미지를 해당 레포지토리에 저장하게됩니다.

아까 처음에 Docker Hub 및 GitHub Container Registry 는 ECR Pull-Through Cache 정책을 사용하기 위해 인증 정보가 필요하다고 이야기 했었습니다.

Docker Hub 이나 GitHub Container Registry 를 업스트림으로 하는 캐시를 웹콘솔에서 생성하려고 하면 볼 수 있는 화면입니다.

ecr-pullthroughcache/ 를 접두사로 하는 암호를 AWS Secrets Manager 에 생성하고 사용해야 하는것만 더 추가됩니다.

이 때 AWS Secrets Manager 에 생성하는 암호에는 username 과 accessToken 이라는 키를 사용합니다.

ECR Pull-Through Cache 설정 방법(Terraform)

위와 같이 aws_ecr_pull_through_cache_rule 리소스를 사용 할 수 있습니다.

Docker Hub 와 GitHub Container Registry 에 대해서는 AWS Secrets Manager 에 정의된 암호를 사용해야하며, 해당 부분을 어떻게 설정하는지는 이 글의 범위를 벗어나니 생략하겠습니다.

EKS 환경에서 사용하기

위에서 docker pull 로 이미지를 pull 할 때에는, 제가 사용한 IAM User 의 역할(IAM Role)에 ECR 관련된 정책이 이미 연결되어 있었기 때문에 별다른 문제 없이 사용이 가능했습니다.

다만 우리가 실제로 사용하게 될 EKS 워커노드 환경에서는 해당 권한들이 기본적으로 세팅되어있지 않기 때문에 아래와 같은 권한을 worker node 가 사용하는 IAM Role 에 추가해야 합니다.

statement {
  effect = "Allow"
  actions = [
    "ecr:BatchImportUpstreamImage",
    "ecr:CreateRepository",
    "ecr:ReplicateImage"
  ]
  resources = ["*"]
}

Terraform EKS 모듈을 사용하고 self managed node group 을 사용한다면 아래와 같이 사용할 수 있습니다.

Helm Chart에서의 이미지 경로 설정

대부분의 Helm Chart에서는 values.yaml 내의 image.repository 또는 image.registry 값을 조합해 최종 Pull 경로를 결정합니다. 이 로직은 보통

1. _helpers.tpl 파일에서 템플릿 함수로 구현되어 있거나
2. deployment.yaml, statefulset.yaml, daemonset.yaml 등 워크로드 매니페스트 내부의 containers[].image 항목에 인라인으로 정의되어 있습니다.

예를 들어 ArgoCD Helm Chart(예: argo-cd 차트의 argocd-server 부분) deployment.yaml 에서 deployment.yaml을 보면 (link)

      containers:
      - name: {{ .Values.server.name }}
        image: {{ default .Values.global.image.repository .Values.server.image.repository }}:{{ default (include "argo-cd.defaultTag" .) .Values.server.image.tag }}
        imagePullPolicy: {{ default .Values.global.image.imagePullPolicy .Values.server.image.imagePullPolicy }}

여기서 default A B라는 Helm 함수는 “B가 설정되어 있으면 B를, 없다면 A를 사용”한다는 의미입니다. 즉,

• .Values.server.image.repository가 있으면 그 값을 사용,
• 없으면 .Values.global.image.repository를 사용하게 됩니다.

## Globally shared configuration
global:
  # -- Default domain used by all components
  ## Used for ingresses, certificates, SSO, notifications, etc.
  domain: argocd.example.com

  # -- Common labels for the all resources
  additionalLabels: {}
    # app: argo-cd

  # -- Number of old deployment ReplicaSets to retain. The rest will be garbage collected.
  revisionHistoryLimit: 3

  # Default image used by all components
  image:
    # -- If defined, a repository applied to all Argo CD deployments
    repository: quay.io/argoproj/argocd

따라서 global.image.repository 값을 수정하면, ArgoCD 컴포넌트 전반에 걸친 이미지 레포지토리를 일괄적으로 변경할 수 있습니다.

또한 Dex와 Redis는 서브차트가 아닌, ArgoCD 차트의 템플릿 일부로 포함되어 있는데, 이들은 global.image.repository를 참조하도록 구현되어 있지 않으므로 별도로 dex.image.repository, redis.image.repository 등을 설정해줘야 합니다.

이 포스트에서 다룰 예시 차트들

아래 Helm Chart들을 예시로 들어, 이미지 레지스트리를 ECR Pull-Through Cache 주소로 바꾸는 과정을 살펴보겠습니다. (괄호 안은 테스트 시점의 Chart 버전)

• argo-cd (7.8.5)
• cert-manager(v1.15.3)
• external-secrets(0.9.16)
• keda(2.14.0)
• istiod(1.21.2)
• fluentd(0.5.2)
• kube-prometheus-stack(58.3.1)
• external-dns(7.2.0)

argocd

global.image.repository 를 통해 argocd 애플리케이션들의 이미지 레포지토리를 일괄 지정합니다. repository 라는 이름으로 쓰이면 pull-path 로 정의해야 합니다. ({registry}/{repository}/{image} -> {ACCOUNT-ID}.dkr.ecr.ap-northeast-2.amazonaws.com/quay.io/argoproj/argocd)

global.image.tag 값을 정의하지 않는 이유는 argocd helm chart 내부에서 처리하기 때문에 정의하지 않았습니다. (링크 참고)

dex 와 redis 는 Helm 의 sub chart 기능을 활용한것은 아니고 argocd 차트의 템플릿중 일부로 포함되어있습니다. dex 와 redis 는 global.image.repository 의 영향을 받지 않고 별도로 지정하도록 되어있습니다. (링크 참고)

cert-manager

cert-manager 의 helm chart 를 보면 controller 자체는 image.registry 로 레지스트리만 변경 할 수 있습니다. (values.yaml 에는 image.registry 항목이 없는데 사실 _helpers.tpl 쪽에 받아서 처리 할 수 있게 구성되어있다 / 링크 참고)

webhook 과 cainjector 의 경우는 webhook.image.registry 와 같은것으로 레지스트리만 변경이 불가능하고 repository 를 변경해야 합니다.

여기서도 느끼겠지만 보통 registry 의 경우 레지스트리 정보만 주입하면 되는 반면, repository 의 경우 registry 를 포함해서 레포지토리/이미지 값까지 포함해야 한다는 점이 차이가 있습니다.

external-secrets

image.repository 는 external-secrets 메인 컴포넌트의 이미지 레포지토리를 지정하고, webhook , certController 또한 각각 별도로 지정해줘야 합니다.

external-dns

registry 만 변경할 수 있도록 되어있고, external-dns 자체가 여러 컴포넌트가 없기 때문에 매우 단순하게 변경 할 수 있습니다.

keda

keda 의 모든 컴포넌트의 이미지 레지스트리를 일괄 변경 할 수 있도록 global.image.registry 값이 존재하므로 그대로 사용하면 됩니다.

istiod

defaults.pilot.hub 의 경우 istiod 가 사용할 이미지에 대한 registry 를 지정하는 값입니다.

defaults.global.hub 의 경우 sidecar injection 을 수행할 때 사용할 registry 및 defaults.pilot.hub 값이 정의되어있지 않을 때 사용할 기본 값(istiod 의 이미지)입니다.

fluentd

kube-prometheus-stack

kube-prometheus-stack 은 여러 helm sub chart 가 함께 사용 되는 형태입니다.

따라서 values.yaml 에서도 서브차트 / kube-prometheus-stack 자체의 차트 각각에 쓰이는 값들이 혼재되어있습니다.

서브차트의 경우 서브차트의 이름을 통해서 values 값을 전달해야 합니다.(예: kube-state-metrics 에 전달할 값은 kube-state-metrics.image.registry -> 해당 서브 차트의 .Values.image.registry)

alertmanager , prometheusOperator , prometheus 는 모두 kube-prometheus-stack 의 자체 템플릿이고. prometheusOperator 는 자체 deployment 로 뜨기 때문에 prometheusOperator.image.registry 형태로 직접 전달하고. alertmanager 와 prometheus 는 모두 CustomResource 로 생성되기때문에 Spec 이라는 postfix 로 value 를 처리합니다.

여기서 유의할점은. grafana , prometheusOperator 와 같이 하나의 추상적인 컴포넌트도 서브 이미지(사이드카 등)들이 각각 다른 레지스트리를 쓸 수도 있으므로 values.yaml 에서 모든 이미지 부분을 확인하는 것이 중요합니다.

Helm Chart 예시들을 보고 나서

앞서 살펴본 바와 같이, Helm Chart에서 이미지 레지스트리(또는 레포지토리)를 설정하는 방식은 차트마다 제각각입니다.

1. image.registry vs. image.repository
   1. 어떤 차트는 단순히 image.registry를 변경하면 나머지 경로(리포지토리/이미지명)는 템플릿이 자동으로 붙여주는 구조를 갖습니다.
   2. 반면 다른 차트는 image.repository 자체에 레지스트리+조직+이미지명을 전부 넣도록 설계되어 있을 수 있습니다.
2. global 설정
   1. 일부 차트는 global.image.repository(or global.image.registry)만 설정하면 여러 컴포넌트가 일괄적으로 해당 값을 참조하도록 만들어졌습니다.
   2. 하지만 서브차트(혹은 같은 차트 내 여러 템플릿)마다 별도의 image.repository 값을 사용하도록 구현되어 있으면, 각각 별도로 오버라이드해야 합니다.
3. 서브차트 & 사이드카
   1. kube-prometheus-stack처럼 복잡한 차트는 서브차트, CRD, 사이드카 이미지가 섞여 있어, 여러 위치에 레지스트리 설정이 흩어져 있을 수 있습니다.
   2. 따라서 values.yaml 파일에서 모든 이미지 관련 파라미터를 빠짐없이 확인하고, 필요하다면 각각 ECR Pull-Through Cache 경로로 바꿔줘야 합니다.

결론

결국 Docker Hub의 이미지 Pull Rate Limit 이슈는, 스팟 인스턴스나 Karpenter 같은 오토스케일링 환경에서 노드가 자주 교체되는 EKS 클러스터에 특히 취약하게 작용합니다.

이러한 문제를 해결하기 위해 직접 이미지를 업로드하거나, 외부 미러링 레지스트리에 의존하기보다는 AWS ECR Pull-Through Cache를 활용하여 퍼블릭 레지스트리의 이미지를 ECR 프라이빗 레포지토리에 캐싱하는것이 가장 안정적이고 간단한 방법이라고 생각합니다.

물론 Helm Chart마다 image.registry, image.repository, global.image.* 등의 설정 방식이 다르므로, 필요한 컴포넌트·서브차트별로 꼼꼼히 레지스트리 경로를 변경해야 합니다.

하지만 이 작업을 한 번 진행하고 나면, 대부분 Helm Chart에서 image 와 관련된 템플릿 부분이 변경되지는 않기 때문에 더 이상 신경쓰지 않고 여러분의 ECR 프라이빗 레포지토리에 퍼블릭 이미지를 캐싱해서 사용할 수 있습니다.

이를 통해 퍼블릭 레지스트리의 정책 변화에 영향을 받지 않고 안정적으로 프로덕션 환경에서 이미지를 관리할 수 있습니다.

EMR on EKS

EMR on EKS 란 EKS 에서 오픈소스 빅데이터 프레임워크를 실행 할 수 있는 아마존의 서비스를 의미한다. EKS 클러스터에서 Amazon EMR 기반 애플리케이션을 실행 할 수 있는데. AWS EMR 에 Spark Job 을 submit 하면 가상클러스터라고 불리는 EKS 환경에 Spark driver 와 Spark Executor 를 실행 할 수 있다.

Karpenter 와 함께 사용하면 그 편리함이 극대화 되는데, 무거운 Spark Job 이 수행되는 경우 Karpenter 에 의해 Node 가 자동으로 프로비저닝되고, 작업이 끝난 이후에는 해당 노드를 내리는 등의 작업을 자동화 할 수 있기 때문에 매우 비용 효율적이다.

현재 우리는 Airflow 와 함께 EMR on EKS 를 사용중인데. Airflow 의 EMROperator 클래스를 사용해서 필요한 Spark Job 을 주기적으로 실행하는 형태로 구성하였다. 현재 우리의 구성을 간략하게 그리면 아래와 같다.

EMROperator 클래스를 통해 (정확히는 그것을 상속하여 별도로 구현한 Operator 를 사용중이다.) Spark Job context 와 함께 AWS EMR 에 job 을 submit 하면, AWS EMR 을 통해 EKS 클러스터 내에 Spark Driver Pod 와 Spark Executor Pod 가 생성되게 된다. (Job Submitter Pod 도 존재하는데 이 글에서는 해당 내용을 생략한다)

문제 상황

Spark Job 은 대부분 컴퓨팅 리소스(CPU, 메모리 둘다)를 많이 사용하는 작업이므로, Karpenter 를 통해 필요할때만 동적으로 컴퓨팅 리소스를 생성한다고 하더라도 EC2 비용이 매우 많이 발생하게 된다.

따라서 비용 효율성 개선을 위해 Spark Driver Pod 는 on-demand 머신에, Spark Executor Pod 는 spot 머신에 프로비저닝 하도록 podTemplate (https://spark.apache.org/docs/latest/running-on-kubernetes.html#pod-template)을 통해 설정하였다

위와 같은 PodTemplate 를 AWS EMR 에 job submit 할 때 제출하면, 우리가 지정한 properties (e.g spec.nodeSelector)를 갖고, 그 외 값들을 채워서 EKS 환경에 driver 와 executor 가 생성된다.

Spark Driver 의 경우 실패하면 모든 작업을 다시 시작해야 하지만 (executor 도 모두 종료), Spark Executor 의 경우 종료되더라도 전체 작업에 영향을 끼치지 않기 때문에 spot 인스턴스 환경에서 수행하는것이 훨씬 비용 효율적이였다.

문제는, 위와 같이 구성하였을 경우, 그리고 (당연히도) EKS 클러스터 환경의 노드가 여러 가용영역(AZ)에 존재하는 경우. AWS EMR 을 통해 생성되는 driver pod 와 executor pod 가 서로 다른 AZ 에 스케쥴링 되는 경우가 발생하고, 이러한 상황에서는 driver pod 와 executor pod 간의 통신이 모두 비용으로 발생하게 된다. (한국 리전 기준 $0.01 per GB)

https://aws.github.io/aws-emr-containers-best-practices/node-placement/docs/eks-node-placement/

아마존이 제공하는 AWS EMR 환경에 대한 Best Practice 문서를 보면 AWS EKS 기반의 쿠버네티스 클러스터의 워커노드가 여러 AZ 에 걸쳐서 있는 경우, Driver 와 Executor 가 서로 다른 AZ 에 프로비저닝 될 수 있고, 이런 경우 비용이 발생한다는 내용이 나와있다.

여기서 제공하는 솔루션은 spark job submit parameter 에 nodeSelector를 topology.kubernetes.io/zone 등을 설정하여 job 을 submit 하고 job submitter, driver, executor 등을 단일 AZ 에서 스케쥴링 되도록 하는 내용이다.

당연히 동작하긴 할것이다. 그렇지만 이 문서에서 나와있듯이 특정 AZ 를 하드코딩해서 사용하는 경우 해당 AZ 에 on-demand, spot 인스턴스가 부족한 경우에는 pending 상태에 빠질것이다. (karpenter 도 어떻게 해줄 수 없다. 실제 해당 AZ에 인스턴스가 부족한거니까)

그래서 오히려 job submitter, driver pod 는 아무 AZ 에 존재하는 노드에 프로비저닝 되도록 하고 (Kubernetes Scheduler 에게 전적으로 위임하고), executor pod 만 driver pod 와 동일한 AZ 에 있는 노드에 프로비저닝 되도록 하는것이 더 가용성 향상이 된다고 판단했다.

해결 방법

driver pod 가 떠있는 노드의 topology.kubernetes.io/zone 레이블을 갖는 노드에 executor pod 가 스케쥴링 되면 되는 상황이기때문에, 스케쥴러가 이런 상황을 처리 할 수 있는 inter-pod-affinity 를 사용하면 된다고 생각했다. (https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)

inter-pod-affinity 란 해당 노드에서 이미 실행중인 파드의 레이블 을 기반으로 파드를 스케줄링 할 수 있는 노드를 제한 할 수 있는 기능이다.

driver pod 가 스케쥴링된 node 의 topology.kubernetes.io/zone 레이블의 값을 갖는 노드에 executor pod 를 프로비저닝 하고자 할 때 inter-pod-affinity 를 통해서 구현이 가능한 것이다.

inter-pod-affinity 는 상당한 처리량을 필요로 하는 작업이라 수백대 이상의 노드를 운영하는 클러스터에서는 사용이 권장되지 않는다. 파드가 스케쥴링되기 까지 (이 조건을 계산하느라) 오래 걸릴 수 있다고 한다.

위와 같이 구성하면 spark-app 이라는 driver pod 의 label 을 기반으로, 해당 파드가 떠있는 노드의 topology.kubernetes.io/zone 레이블의 값과 동일한 Node 에 스케쥴링 하도록 강제 할 수 있다. (topologyKey 참고)

이론적으로는 간단한 접근이였지만 현실적으로 아래와 같은 문제가 있었다.

1. spark job 을 submit 하기 전에는 각 job 별로 고유한 job id 를 알 수 없다. 따라서 PodTemplate 은 spark job submit 하기전에 이미 있어야 하기 때문에 job id 기반의 레이블을 선택 할 수 없다.
2. 그렇다면 각 Job 별로 (Airflow 환경에서는 DAG / Task) static 하게 app name 등을 지정하고, 그것을 통해서 레이블을 선택하도록 하면 되지 않을까? → 만약 같은 시간에 중복 실행되고있다면 문제가 발생 할 수 있다.

AWS EMR 에 job 을 submit 하기전에 driver 와 pod 에 대한 PodTemplate 을 전달해야 하는데, 즉 이 시점에서 driver 와 pod 를 고유하게 매칭시켜줄 수 있는 키/값을 고정해야만 우리가 하고자 했던 동작을 정확하게 구현 할 수 있다.

따라서 Airflow EMROperator 를 사용하는 우리 환경에, AWS EMR 에 job 을 submit 하기 이전에 해당 작업의 이름(e.g etl-foo-bar )과 timestamp 를 조합해서 affinity 를 사용하기 위한 label 과 value 를 고정하였다.

그리고 EMROperator 가 job 을 submit 하기 이전에 PodTemplate 을 동적으로 생성하여 S3 에 업로드하고, 그 S3 오브젝트의 경로를 AWS EMR 에 submit 할 때 같이 넘겨주는 방식으로 구현하였다.

spark.kubernetes.driver.label 형식으로 spark driver pod 의 레이블을 지정해줄 수 있고. 이것을 사전에 지정하고, PodTemplate 에는 지정된 label 의 value 를 inter-pod-affinity 에서 사용 할 수 있게 구현하였다. 동적으로 생성된 PodTemplate 은 S3 에 업로드하고, 그것에 대한 경로를 spark.kubernetes.executor.podTemplateFile , spark.kubernetes.driver.podTemplateFile 형태로 넘겨주어서 처리하였다.

이렇게 하여서 driver pod 에 대한 고유한 label key:value 를 job submit 하기 전에 핸들링 할 수 있고, 이것을 통해서 PodTemplate 을 생성하면 우리가 원하는 동작을 구현 할 수 있다.

이 케이스에서 label 의 key, value 는 어떤것을 사용해도 상관없다. 다만 value 는 동일한 작업에 대해서 여러번 submit 되거나 동시에 실행되는 상황이 발생해도 conflict 이 나지 않을 수 있게만 지정하면 된다.

쉽게 해결 할 수 없을까?

이렇게 특정 파드를 다양한 조건으로 스케쥴링 하는 방법은 Kubernetes 에서의 스케쥴러가 판단 할 수 있는 nodeSelector, affinity , topology spread constraints 등을 상황에 맞게 잘 조합해서 사용해야 한다.

이번 문제상황과 같은 경우에는 inter-pod-affinity 를 이용해서 쉽게 해결은 가능했지만. AWS EKS 뿐만 아니라 AWS EMR 이라는 중간 layer 가 들어가 있기 때문에 어느정도 우회법을 찾아서 해결을 해야 했다.

만약 spark on kuberentes 에서 podTemplate 에 대한 템플리팅 변수를 지원해주거나, AWS EMR 에서 그러한 기능을 지원해줬다면 지금과 같이 Airflow Operator (혹은 그외 다양한 여러분의 환경)레벨에서 구현할 필요가 없었을 내용이다.

예를들어

위와 같은 {JOB_ID} 등을 spark on kuberentes 혹은 AWS EMR 에서 처리를 해준다면

위와 같은 형태로 PodTemplate 만 간단하게 만들어서 구현 할 수 있었을 것이다.

하지만 안타깝게도 spark on kuberentes , AWS EMR 모두 이러한 기능은 제공되지 않기 때문에 환경에 맞게 적절한 우회법을 찾아서 구현해야 한다.

지금 상황의 경우도 mutatingWebhook 등을 커스텀하게 구현해서 affinity 부분을 동적으로 생성되게 구현한다면 더 우아하게 처리 될 수 있다.

Spark driver 와 executor Pod 가 생성 될 때 에는 downward API 를 사용 할 수 없기 때문에 AWS EMR 이 EKS 클러스터에 생성을 요청한 request 를 mutatingWebhook 에서 한번 가로채서, metadata 혹은 환경변수에 설정된 driver / executor 모두 동일하게 갖고있는 고유한 값(높은 카디널리티를 가지는 id 와 같은 값들이 두 파드 모두 설정되도록 생성된다)을 executor pod 의 labelSelector.matchLabels 에서 사용 할 수 있게 Pod Spec 을 조작하는 방식으로 구현도 가능하다.

결론

결론적으로 EMR on EKS 환경에서 동일 리전 / 다른 AZ 간 통신 비용을 줄이기 위해서는 driver pod 와 executor pod 가 같은 AZ 에서 실행되면 된다.

만약 정말 고가용성이 필요하지 않다면 자신의 EKS 환경에서 하나의 AZ 를 선택해서 driver / executor pod 의 nodeSelector 에 해당 AZ 를 하드코딩해서 사용하면 쉽게 해결이 가능하다.

하지만 만약 해당 AZ 가 어떠한 이유에서든 문제가 발생한다면 이런 상황에서 자동으로 처리가 되지 않기 때문에, driver pod (job submitter pod 포함) 해서 가능한 아무 AZ 에 스케쥴링 되도록 하고, executor 만 driver pod 가 스케쥴링된 노드의 AZ 와 동일하게 스케쥴링 되도록 하고 싶다면.

1. 동적으로 PodTemplate 을 생성하는 전략
2. mutatingWebhook 을 구현해서 처리하는 전략

두가지 방법이 있고, 이 글에서는 1번을 소개했다.

최근 EKS 클러스터 버전 업그레이드를, 노드별로 in-place 업그레이드 하는것이 아닌, 새로운 버전의 EKS 를 준비해서 기존버전 -> 신규버전으로 일종의 rolling update를 하는 작업을 진행하게 되었다.

이 때 여러 Addon(Istio, Argocd 등등), 애플리케이션들을 이전했는데, 특히 Airflow 를 무중단으로 이전하는 방법에 대해서 고민하고, 실제로 무중단로 이전한 과정에 대해서 공유해보고자 한다.

Airflow 컴포넌트

Airflow 무중단 이전 작업을 설계하기 앞서서, 정확히 Airflow 의 각 컴포넌트가 어떤 역할을 하는지 파악해보았다.

Airflow 는 아래와 같은 컴포넌트들로 구성되는데

1. Scheduler : 예약된 워크플로우를 트리거하고, 실행할 작업을 executor 로 제출하는 작업을 처리하는 컴포넌트
2. Webserver : DAG 와 작업의 동작을 확인하고, 실행시키거나, 디버깅 할 수 있는 인터페이스
3. Metadata database : Airflow 의 컴포넌트가 워크플로우 및 작업의 상태를 저장하는데 사용하는 데이터베이스

위 컴포넌트들은 필수적으로 필요한 컴포넌트들이고, 이 외에 triggerer 등이 추가적으로 필요 할 수 있다.

여기서 scheduler 는 예약된 작업들을 트리거하고, executor 가 실행 할 수 있도록 하는 중요한 역할을 하는데, 이것은 Metadata database 를 바라보며 작업을 예약하거나, queued 된 예약된 작업을 executor 에 제출하는 역할을 한다.

무중단 이전 설계

따라서, 기존 버전의 EKS 와, 신규 버전의 EKS 양쪽에 동일한 Airflow 구성 (Metadata database 포함)을 하고, 점진적으로 기존 버전 EKS의 Airflow 에는 executor 에 작업을 submit 하지 않도록 하면서, 신규 버전 EKS 의 Airflow 에는 executor 에 작업을 submit 하도록 하는 형태로 작업하면 될 것이라고 구상했다.

위와 같이 구성을 하기 전에, 몇가지 우려되는 점이 있었는데.

1. 동일한 구성, 동일한 Metadata database 를 바라보는 두 Airflow 가 있을 때, 한쪽 클러스터에만 워크플로우가 실행되어야 하는데, 양쪽에 동시에 실행되지 않을까?
2. 기존 버전 EKS 에 존재하는 Airflow 인스턴스들을 내릴경우, 해당 클러스터 안에 존재하는 워크플로우들이 실패하게 될까?

결론부터 이야기하면 1번, 2번 모두 그렇지 않았다.

1번의 경우, Metadata database 의 테이블중 public.task_instance 를 보면 scheduled 된 워크플로우나, 수동으로 트리거한 워크플로우는 모두 해당 테이블에 queued 상태로 들어가게 되는데, 이 때 양쪽에 존재하는 스케쥴러중 하나가 queued 된 작업을 executor 에 제출하게 된다. 이 때 두 스케쥴러가 동시에 같은 데이터를 수정하지 않기 때문에 (Lock) 두 스케쥴러중 하나만이 작업을 가져가게 된다.

2번의 경우 실제로 테스트해본결과, Airflow 인스턴스들을 내린다고해서 기존 작업들에 SIGTERM 신호가 전달되거나 하지 않았다.

실제 작업 중 겪은 장애

양쪽 클러스터에 동일한 Airflow 인스턴스 (정확히는 동일한 helmchart 와 values 를 사용했다)를 세팅하고 DAG 들이 스케쥴링되고, 실행되는데 문제 없음을 확인했지만. Airflow 에서 사용할 전역 변수를 한쪽 인스턴스(웹서버)에서 수정하면, 반대편 웹서버에서는 해당 변수를 찾지 못하고, 반대로 해도 한쪽은 찾고 한쪽은 못찾는 장애가 발생하였다.

이것은 Airflow 가 데이터를 metadata database 에 저장할때, 특정 데이터들 (전역 변수)을 암호화 해서 저장하는데, Airflow 에서는 fernet key 를 사용한다.

Fernet — Airflow Documentation

따라서 기존 Airflow 에서 자동으로 생성된 fernet key 를 양쪽 helm value 에 동일하게 적용하고 실행하니, 완전하게 두 벌의 Airflow 가 문제없이 동작하는걸 확인 할 수 있었다.

장애 인 줄 알았던 것

이렇게 두벌의 Airflow 를 구성하고, 어느 한 쪽의 Airflow webserver 를 접근해서 DAG 실행 로그를 확인 할 때, 간헐적으로 로그가 확인이 되지 않아서 설정에 문제가 있나? 장애가 발생한건가? 라는 생각을 하기도 했었다.

결론적으로(당연하게도) 접근한 Airflow 가 속해있는 쿠버네티스 클러스터에 executor 가 실행중인 DAG 의 경우는 로그가 보이지만, 그렇지 않은경우에는 로그가 보이지 않는것에 불과했다.

당연한 동작이기 때문에 Airflow 를 양쪽에 생성하고, 한쪽 Airflow 를 내리고 신규 버전의 EKS 내의 새로 생성한 Airflow 쪽에만 모든 워크플로우가 실행되도록 하고 나서 당연하게도 해당 문제는 해결되었다.

결론

Airflow 를 무중단으로 이전하는 방법에 대해서 검색해보고, 적절한 접근법이 있으면 반영해서 작업하려고 했지만 딱히 내가 원하는 정보가 나오지 않아서 결국 뇌피셜(?)로 설계하고, 실제로 프로덕션 작업 이전에 개발 환경에서 Airflow 를 이것저것 만져보고 문제가 없음을 확인하고 프로덕션 Airflow 까지 원활하게 이전 작업을 완료했다.

처음에는 두 벌의 Airflow 를 동시에 존재하게 하는것이 문제가 없는가? 라는 의문이 계속 들었지만, 테스트를 해보니 결국 그런 설정에도 동일한 Metadata database 를 쓰고있다면 스케쥴러가 작업을 가져갈 때 두 스케쥴러중 오직 하나만이 작업을 가져가게 되는 (DB Lock 으로 인하여)구조라는것을 확인할 수 있었다.

그럼에도 (이론적으로) 문제가 없음을 확인했지만 혹시나 중복실행되면 어떡하지? 라는 걱정에 데이터 엔지니어분들과 이야기를 나눠봤는데, DAG 라는것이 결국 멱등성이 보장되어야 하는것이고, 그렇게 구성을 했다고 해서 중복실행되는 것에 대해서도 크게 걱정을 하지 않고 작업을 했다. (물론 중복실행 되지도 않지만!)

검색해서 좋은 레퍼런스를 찾아서 해결하는것도 좋지만, 해당 시스템이 어떤 구성을 갖고있고, 추상적인 레벨에서 어떻게 동작하는지를 확인하고 실제로 테스트해보면서 작업하면 충분히 무리없이 할 수 있다는걸 느끼게 되었다.

최근 많은 파일들 (버킷 자체로 따지면 천만개 이상, Prefix 나 날짜별로 분리해도 수천~수만 이상)들을 다운로드받고 그것을 tar.gz 으로 아카이브 및 압축을 해서 특정 버킷에 glacier 클래스로 밀어넣어야 하는 요구사항을 처리하게 되었다.

이 때 파일을 다운로드 받아야 아카이브 및 압축을 할 수 있기 때문에 처음에는 aws cli 를 통해 다운로드 받고, tar 명령어를 통해 아카이브해서 밀어넣는 최대한 단순한 방법을 고려해보았다. 하지만 c7g.16xlarge 와 같은 네트워크 성능이 최대 30Gbps(=3750 MB/s) 나오는 인스턴스로도 다운로드 되는 속도는 최대 250MB/s 에 불과했었는데. 다양한 원인이 있겠지만

1. 일단 하나의 aws cli 요청 (하지만 내부적으로 스레드 풀을 사용하기때문에 여러 요청을 병렬적으로 하고는 있다)이 EC2 인스턴스 내의 NIC 가 처리 가능한 네트워크 대역폭을 모두 포화시키지는 못한다.
2. gp3 스토리지를 기본값 (IOPS 3000, 처리량 125MB)으로 생성해서 연결한 경우 Disk 쓰기 속도의 제한으로 인해서 병목현상이 발생하기도 한다.

Transfer data between Amazon S3 bucket and Amazon EC2

I want to improve the speed when transferring data from my Amazon Elastic Compute Cloud (Amazon EC2) instance to my Amazon Simple Storage Service (Amazon S3) bucket.

Amazon Web Services, Inc.AWS Official

위 글을 참고하면 S3 ↔︎ EC2 간 성능 향상을 위해서는 “병렬” 적인 작업 부하, 업로드시에는 멀티파트 업로드 설정 최적화, 그리고 가능한 경우 VPC Endpoint 를 사용하라는 등의 내용을 볼 수 있다.

여기서 일단 다른 설정들은 제외하고 “병렬”적인 작업부하와 같은 병렬적인 접근 방식이나, 혹은 비동기 처리등을 통해서 S3 로부터 EC2 까지 데이터를 받아오는데 성능을 올리는 방법을 적용해보고자 테스트 해봤다. 이 때 모든 파일은 “메모리”에 저장해서 SSD 의 쓰기 속도의 제한을 받지 않도록 작업하였다.

접근 방법들

우선 크게 아래와 같은 4개의 접근 방법을 고려해보았다.

1. 동기 코드
2. 비동기 모듈 기반 코드 (aioboto3, aiobotocore..)
3. 멀티스레드 코드 (concurrent.future 에서의 ThreadPoolExectutor)
4. 멀티프로세스 코드 (concurrent.future 에서의 ProcessPoolExecutor)

각각의 코드는 아래와 같다.

동기 코드

비동기 코드

멀티 스레드 코드

멀티 프로세스 코드

테스트 방법

$ dd if=/dev/urandom of=50MB.file bs=1M count=50 와 같은 형태로 여러 용량의 더미 데이터를 생성하고.

$ seq 1 1000 > object_ids 과 같은 형태로 버킷의 키로 사용할 문자를 미리 생성한다.

$ time parallel --will-cite -a object_ids -j 10 aws s3 cp 50MB.file s3://YOUT_TEST_BUCKET/{} 형태로 aws s3 cp 명령어를 병렬적으로 (동시에 10개) 수행하는 방식으로 테스트 할 데이터를 업로드한다.

레퍼런스 : https://github.com/aws-samples/maximizing-storage-throughput-and-performance

이렇게 테스트 할 데이터를 버킷에 올리고 동기, 비동기, 멀티 스레드, 멀티 프로세스 코드로 S3 로부터 파일을 다운로드 받는 테스트를 진행해보았다.

테스트 with profiler (viztracer)

각 코드가 실제로 어떤 흐름으로 동작하는지 이해하기 위해서 viztracer 라는 프로파일링 툴을 이용해서 각 코드를 테스트해보았다.

동기 코드

동기 코드의 경우 각 파일 다운로드에 대해서 프로그램의 메인 실행 흐름에서 순차적으로 진행됨을 알 수 있다.

비동기 코드

aioboto3(aiobotocore)를 사용한 코드의 프로파일링 결과다.

aioboto3(aiobotocore)는 aiohttp를 래핑해서 사용하는 패키지로 S3 작업에 대해 비동기 작업을 할 수 있다. 위 스크린샷에서 메인 스레드(이벤트 루프)에서 초기에 여러 파일 다운로드에 대한 Future 객체들을 모두 등록하고 await 동작에 따라서 처리 완료된 Network I/O 작업에 대해 메인스레드에서 비동기적으로 처리하게 된다.

위 스크린샷은 프로그램 실행 초기에 비동기 작업들을 등록하는 작업이다.

이후 처리가 된 HTTP Request 결과에 대해서 메인 스레드에서 준비된 비동기 Task 로부터 데이터를 받는 부분을 확대한 스크린샷이다.

이렇게 메인 스레드에서 Network I/O 작업이 블로킹되지 않고. select / epoll / kqueue 와 같은 비동기 메커니즘을 사용해서 처리된다.

이 작업은 “단일 스레드” 에서 동작하므로 당연하게도 “하나의 CPU 코어” 에만 부하가 발생한다.

멀티 스레드

멀티스레드 (ThreadPoolExecutor) 를 사용하는 경우. 메인 스레드는 제어 흐름만 관리하고 실제 S3로부터 데이터를 다운로드 받는 작업은 worker thread 에서 병렬적으로 수행된다.

이 때 멀티코어 CPU 환경에서는 이 작업이 “여러 CPU” 에서 발생 할 수 있고. 또한 스레드간 작업 전환에는 “컨텍스트 스위칭”을 필요로 하기 때문에 특정 상황에서는 이 컨텍스트 스위칭 오버헤드에 의해서 원하는 성능이 나오지 않을 수 있다.

멀티 프로세스

멀티프로세스 (ProcessPoolExecutor)를 사용하는 경우 스레드가 아닌 “프로세스를” 워커로서 사용하는 방법으로 CPU bound 작업 또한 성능 개선을 노려볼 수 있다. 다만 프로세스별로 별도의 메모리 공간을 가져야 하므로 메모리 사용량이 더 크다는 점도 있기 때문에, 머신의 자원이 널널한 경우에만 사용하는게 좋아보인다.

상황 별 테스트

테스트를 하기 위한 인스턴스로 c7g.16xlarge EC2 인스턴스를 사용했고. 네트워크 성능은 최대 30Gbps 인 인스턴스다.

1KB, 1MB, 50MB 파일에 대해서 각각 10개, 50개, 100개, 500개, 1000개를 받을 때 소요시간을 체크해보았고. 3GB 단일 파일에 대해서도 소요시간을 체크해보았다.

1KB 파일

전체적으로 동기 방식은 선형적으로 처리 시간이 늘어난다. 비동기의 경우 전체 케이스에 거쳐서 좋은 성능을 보인다.

멀티 스레드 방식의 경우 그렇게 좋은 성능을 내진 않고, 멀티프로세스 방식의 경우 특정 케이스에서는 더 낫지만 어떤 경우 아니기도 하다. (오버헤드에 의한 부분 차이로 느껴짐)

1MB 파일

50MB 파일

파일 크기가 큰 경우에. 파일 다운로드 자체 I/O 가 긴 작업이기때문에 “비동기”를 이용해 동시성으로 성능을 끌어올리려고 해도. 오히려 I/O 에 의한 오버헤드가 발생해서 동기식 코드보다 느려지는 경향이 있다. 이럴 때에는 병렬 실행이 오히려 네트워크 대역폭도 잘 쓰고 , 네트워크 I/O에 대한 처리가 더 나아진다.

3GB 파일 1개

동기 : 0.13s

비동기 : 35s

멀티 스레드 : 0.15s

멀티 프로세스 : 0.2s

전반적으로 작은 파일이 여러개 있는 경우에는 비동기 로직이 더 나은 성능을 보인다.

파일 개수가 많고 각 파일이 큰 경우(크다 라는것이 너무 추상적이지만 대충 수십MB 이상인 경우라고 생각 할 수 있다), 혹은 큰 파일(수 GB 이상의 파일) 하나를 받아오는데에는 비동기 로직이 성능이 나빠진다.

아래는 각 테스트 결과에 대한 그래프로 나타낸 자료이다.

높이가 낮을수록 성능이 좋은것 (소요 시간이 짧은 것)이다.

결론

위 테스트 결과를 통해 동기, 비동기, 멀티스레드, 멀티프로세스 어느 하나 “모든”상황에 좋은 성능을 내는 접근 법은 없다라는 결론을 얻었다.

다만 작은 파일이 여러개 있다 → 비동기가 유리하다

파일이 각각이 크기가 크다 → 멀티스레드/프로세스가 유리하다.

그리고 그것과 별개로 S3 Prefix 구조를 잘 짜놨다 → 병렬 실행해서 성능을 끌어 올릴 수 있다.

멀티스레드/멀티프로세스가 성능이 향상되는 케이스가 있지만. 그 대가로 자원을 더 많이 사용하게 된다 (여러 CPU 코어에 한 실행시간을 더 쓰게 됨)

위와 같은 인사이트를 얻을 수 있었다.

결국 모든것이 trade-off 라고 볼 수 있고, 상황에 맞게 끔 적절한 접근 방식을 취해야 하고 결국 어떤 상황에서 퍼포먼스가 가장 나은지를 실제 테스트해보고 결정해야 한다.

번외

GitHub - peak/s5cmd: Parallel S3 and local filesystem execution tool.

Parallel S3 and local filesystem execution tool. Contribute to peak/s5cmd development by creating an account on GitHub.

GitHubpeak

s5cmd 라는 툴은 Go 로 작성되어있고 동시성과 병렬성을 모두 가져가서 40Gbps(~4.3GB/s) 정도의 대역폭도 포화 시킬 수 있는 성능을 갖고있다고 한다. Disk 의 I/O 성능이 충분하거나, 그 외 여러 상황에서 직접 코드로 구현하는것보다 나은 성능을 얻을 수 있다.

테스트를 위해 c7g.16xlarge 인스턴스에 Ramdisk 를 80GB 할당하고 테스트해보았다. 램디스크의 읽기/쓰기 성능은 약 5.83GB/s 이므로 s5cmd 로 네트워크를 통해 데이터를 받고 디스크에 쓰더라도 병목현상이 크게 생기지 않을 것으로 판단했다. (fio 명령어를 통해 ramdisk 성능을 EC2 인스턴스 내에서 측정한 결과)

50MB 파일 1000개 (총 50GB)를 다운로드 받는것을 아래와 같은 명령어로 테스트해보았다.

$ time s5cmd cp s3://MY_TEST_BUCKET/test/* /mnt/ramdisk

15초 정도가 소요되었다. 50GB 를 15초만에 다운로드 받았다는것은 네트워크 성능이 약 27.31Gbps 정도였다는것을 의미하고 별다른 설정 없이 s5cm5d 명령어 하나만으로 인스턴스(c7.16xlarge)의 최대 네트워크 성능정도를 포화시킬 수 있었다.

파이썬 멀티 프로세스 코드를 통해서 똑같이 테스트를 해보았다. (다만 기존 코드와 다르게 램디스크에 동기적으로 파일을 쓰도록 수정해서 테스트 하였다)

이때는 15.48초 정도 소요되었다. s5cmd 와 거의 비슷한 성능을 얻을 수 있었다.

s5cmd 는 동시성 + 병렬성을 모두 반영했다고 하고, 위에서 본 멀티 프로세스 코드 또한 가용한 모든 CPU 를 사용해서 병렬적으로 수행했고. s5cmd 및 멀티프로세스 코드 모두 인스턴스의 최대 네트워크 성능에 가깝게 대역폭을 포화 시킬 수 있었다고 추측된다.

s5cmd 는 큰 노력 없이 가용한 자원을 모두 사용해서 S3 를 이용 할 수 있는것으로 판단된다. 다만 주의할 점은 네트워크 성능과 별개로 파일시스템에 파일을 쓰는 경우 Disk I/O 성능(IOPS) 을 고려해야 할 것이다.

Network Policy

기본적으로 쿠버네티스에서 파드 - 파드 , 파드 - 서비스 등의 모든 통신은 기본적으로 허용이 되어있다.

이 때 Kubernetes 에서 네이티브하게 지원하는 Network Policy 로 아래와 같은 네트워크 정책을 잡아 파드-파드 등의 호출을 불가능하도록 막을 수 있다.

1. 다른 파드 의 요청을 허용할지 여부 (파드 자체의 트래픽, 즉 파드 안의 컨테이너간의 요청을 제어 할 수는 없음)
2. 다른 네임스페이스에 존재하는 워크로드로부터의 요청을 허용할지 여부
3. IP 블록 기반의 허용 여부 (이 설정과 관계없이 파드가 실행중인 노드와의 트래픽은 항상 허용됨)

아래는 Network Policy 오브젝트의 예시이다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

ingress 와 egress 로 들어가고 나가는 트래픽에 대해서 파드를 선택하거나, 네임스페이스를 선택하거나, ip 대역을 지정해서 허용 여부를 결정 할 수 있다.

다만 Network Policy 로는 다음과 같은 것을 할 수 없다.

1. 내부 클러스터 트래픽이 특정 게이트웨이를 통과하도록 강제 (서비스 메시나 기타 프록시를 사용하는것을 권장)
2. TLS 와 관련된 모든것 (서비스 메시나 Ingress Controller 사용 권장)
3. 노드 별 정책
4. 서비스 네임(도메인 네임)을 타게팅한 정책
5. 모든 네임스페이스 또는 파드에 반영되는 "기본" 정책

기본적으로 쿠버네티스 환경에서 내부 서비스간 호출은 "서비스" 오브젝트의 도메인을 호출해서 사용하는것이 보편적이다. (e.g example-service.example.svc.cluster.local)

하지만 위에서 알 수 있듯이 서비스 네임 기반의 네트워크 트래픽 정책을 Network Policy 로는 구성 할 수 없다 이 때 Istio 를 쓰고있다면 이런 구성을 할 수 있다

Istio Sidecar

예를들어서 A 애플리케이션은 오직 B 데이터베이스와, C 서비스(애플리케이션)과만 통신을 하면 되고, 그 외에 것들과는 통신을 할 필요가 없다고 했을 때. Istio Sidecar 를 별도로 설정하지 않은 경우 B 데이터베이스, C서비스를 포함해서 그 외 D,E,F,G,…. 등의 같은 쿠버네티스 클러스터 안에 있는 다른 서비스들을 호출 할 수 있는 상태가 된다.

따라서 Sidecar 설정을 통해서 Egress 트래픽을 제한함으로서 특정 서비스가 허용된 서비스만 호출 할 수 있도록 강제 할 수 있다.

어떻게 설정 할 수 있나요?

일단 Istio 의 MeshConfig 부터 손을 봐야하는데.

Global Mesh Options

Istio 의 서비스 메시 글로벌 옵션인 outboundTrafficPolicy 가 기본적으로는 ALLOW_ANY로 되어있다. 이것은 대상 포트에 대한 서비스 또는 서비스 엔트리가 없는 경우 무조건적으로 아웃바운드 트래픽을 허용한다는 의미이다.

쉽게 생각해서 내부 서비스를 포함해서 외부 엔드포인트(e.g www.google.com)에 대해서 모두 다 아웃바운드 트래픽을 허용한다는 의미이다.

REGISTRY_ONLY 옵션의 경우 아웃바운트 트래픽으로 서비스 엔트리로 관리하고있거나, 서비스 레지스트리에 등록된 서비스만 아웃바운드 트래픽을 허용한다는 의미이다.

여기서 Sidecar 옵션을 활용하기 위해서는 outboundTrafficPolicy 를 REGISTRY_ONLY 로 수정하고 진행해야 한다.

meshConfig:
  outboundTrafficPolicy:
    mode: REGISTRY_ONLY

위와 같이 Istio 의 meshConfig 의 outboundTrafficPolicy mode 를 수정한다. (디폴트는 ALLOW_ANY)

apiVersion: v1
kind: Namespace
metadata:
  name: red
  labels:
    istio-injection: enabled
---
apiVersion: v1
kind: Namespace
metadata:
  name: blue
  labels:
    istio-injection: enabled
---
apiVersion: v1
kind: Namespace
metadata:
  name: green
  labels:
    istio-injection: enabled
---
apiVersion: v1
kind: Pod
metadata:
  name: nginx-red-1
  namespace: red
  labels:
    name: nginx-red-1
    app: nginx-red-1
spec:
  containers:
  - name: nginx
    image: nginx:latest
---
apiVersion: v1
kind: Pod
metadata:
  name: nginx-blue-1
  namespace: blue
  labels:
    name: nginx-blue-1
    app: nginx-blue-1
spec:
  containers:
  - name: nginx
    image: nginx:latest
---
apiVersion: v1
kind: Pod
metadata:
  name: nginx-green-1
  namespace: green
  labels:
    name: nginx-green-1
    app: nginx-green-1
spec:
  containers:
  - name: nginx
    image: nginx:latest

테스트를위해 red, green, blue 라는 세 네임스페이스에, nginx 파드를 각각 띄우도록 위 yaml 을 반영한다. 이 때 sidecar 는 모두 inject 되도록 Namespace 레벨에서 istio-injection: enabled 레이블이 붙어있다.

apiVersion: v1
kind: Service
metadata:
  name: nginx-red-svc
  namespace: red
spec:
  selector:
    name: nginx-red-1
  ports:
  - port: 80
    targetPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-blue-svc
  namespace: blue
spec:
  selector:
    app: nginx-blue-1
  ports:
  - port: 80
    targetPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-green-svc
  namespace: green
spec:
  selector:
    app: nginx-green-1
  ports:
  - port: 80
    targetPort: 80

이후 각 파드에 대한 서비스 오브젝트를 생성한다.

이 상태에서 red 네임스페이스의 파드에서 green 네임스페이스의 파드로, red 네임스페이스 파드에서 blue 네임스페이스의 파드로 HTTP 요청을 아래와 같이 해본다.

$ kubectl exec -it -n red nginx-red-1 -- curl -XGET -v nginx-green-svc.green.svc.cluster.local

$ kubectl exec -it -n red nginx-red-1 -- curl -XGET -v nginx-blue-svc.blue.svc.cluster.local

Istio Sidecar 리소스를 생성해서 egress 를 강제하지 않았기 때문에 요청에 대한 응답이 잘 들어오게 된다.

apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
  name: red-sidecar
  namespace: red
spec:
  egress:
  - hosts:
    - "istio-system/*"

이 때 red 네임스페이스에 대해서 egress 항목에 hosts 를 istio-system/* 로 지정하여 Sidecar 리소스를 생성해보자.

이것은 istio-system 을 제외한 나머지 네임스페이스에 존재하는 서비스 로 트래픽을 outbound 하지 않도록 하겠다는 설정을 의미한다.

이후

$ kubectl exec -it -n red nginx-red-1 -- curl -XGET -v nginx-green-svc.green.svc.cluster.local

$ kubectl exec -it -n red nginx-red-1 -- curl -XGET -v nginx-blue-svc.blue.svc.cluster.local

을 통해 red 네임스페이스에서 green , blue 네임스페이스의 서비스를 호출 해보면 502 BadGateway 가 뜨면서 트래픽이 넘어가지 않는 것을 확인 할 수 있다.

apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
  name: red-sidecar
  namespace: red
spec:
  egress:
  - hosts:
    - "istio-system/*"
    - "green/*"
    - "blue/*"

위와 같이 사이드카 오브젝트를 수정하고 반영한뒤 요청하면, 이 때는 응답이 잘 들어온다.

REGISTRY_ONLY 로 meshConfig 내 설정을 변경했더니 외부 도메인에 대한 트래픽 처리가 안되요!

위와 같이 Sidecar 리소스를 설정하고, outboundTrafficPolicy.mode 가 REGISTRY_ONLY 인 경우 egress 에 등록된 호스트(서비스) 외에는 트래픽이 넘어가지 않게 된다.

만약 red nginx 앱에서 www.google.com 을 호출하고 싶다면 아래와 같이 설정해야한다.

apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
  name: red-sidecar
  namespace: red
spec:
  egress:
  - hosts:
    - "istio-system/*"
    - "green/*" # green 네임스페이스로 넘어가는 outbound 트래픽 허용
    - "blue/*" # blue 네임스페이스로 넘어가는 outbound 트래픽 허용
    - "red/*" # 자기 자신의 네임스페이스에 대한 모든 호스트 허용 -> service entry 추가 항목 반영 (ServiceEntry 를 red 네임스페이스에 생성했기 때문에)
---
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: svc-entry
  namespace: red
spec:
  hosts:
  - www.google.com
  ports:
  - number: 443
    name: https
    protocol: TLS
  - number: 80
    name: http
    protocol: HTTP
  location: MESH_EXTERNAL
  resolution: DNS

위와 같이 ServiceEntry 오브젝트를 생성하고, Sidecar 오브젝트 또한 자기 자신의 네임스페이스를 지정하면 www.google.com 에 대한 egress 트래픽도 허용되게 된다.

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: google
  namespace: entries
spec:
  hosts:
  - www.google.com
  ports:
  - number: 443
    name: https
    protocol: TLS
  - number: 80
    name: http
    protocol: HTTP
  location: MESH_EXTERNAL
  resolution: DNS

위와 같이 entries 라는 네임스페이스에 ServiceEntry 를 생성했다면.

apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
...
spec:
  egress:
  - hosts:
    - "istio-system/*"
    - "entries/www.google.com"

과 같은 형태로 네임스페이스/FQDN 으로 지정해서 www.google.com 에 대한 egress 트래픽을 허용 할 수 있다.

Kubelet 은 kube-apiserver 를 호출하는 그저 클라이언트 아니였나요?

kubelet 은 컨트롤플레인 노드, 워커 노드 관계없이 쿠버네티스의 노드라면 무조건 실행되어야 하는 컴포넌트로, 컨테이너 런타임과 통신하여 컨테이너를 실행하고 관리하는데 이는 static pod 뿐 아니라 API 서버로부터 받은 PodSpec 에 기반해서 컨테이너를 실행하기도 합니다.

이 kubelet 은 기본적으로 kube-apiserver 를 호출하여 노드의 상태를 컨트롤 플레인에 알려주는 역할을 하는데. 이 때 Kubelet 이 kube-apiserver 에 인증하기 위해서는 특별한 인증 모드인 Node Authorizer 라는 모드의 인증을 사용합니다. (Using Node Authorization )

이 때 사용하는 x.509(TLS) 인증서는 CN 에 system:node:<nodename> 형태로 각 kubelet 이 떠있는 노드의 이름이 각 인증서별로 존재합니다.

이렇게 kubelet 이 kube-apiserver 를 호출하고, 인증처리를 하기 위해 사용하는 x.509 인증서는 /var/lib/kubelet/pki 디렉터리 내에 kubelet-client-current.pem (심볼릭 링크) 형태로 존재합니다.

kubelet.conf 등의 kubelet 이 사용할 kubeconfig 파일을 확인해보시면 아시겠지만, kubeconfig 파일은 해당 심볼릭 링크를 인증서로 바라보도록 되어있고, 실제 인증서는 kubelet-client-2024-05-27-17-07-20.pem 과 같은 형태로 datetime 이 뒤쪽에 붙는 형태로 되어있습니다.

이건 실제로 kubelet 이 이 인증서를 필요시에 rotate 하기 위함이고. kubeconfig 는 심볼릭 링크만 바라보도록 해서 실제 심볼릭 링크만을 인증서가 업데이트 되었을 때 바라보는 경로를 업데이트 하여서 kubeconfig 파일의 수정이 필요하지 않도록 설계가 되었습니다.

kubelet 은 기본적으로 로 10250/10255 번 포트로 서버 를 띄우고 Listen 을 하도록 되어있습니다.

이 kubelet 서버의 엔드포인트 정보는 아래와 같습니다.

kubernetes/pkg/kubelet/server/server.go at 68091805a53c6fdd42553f8ccdbf932ab263fbdd · kubernetes/kubernetes

Production-Grade Container Scheduling and Management - kubernetes/kubernetes

GitHubkubernetes

이 엔드포인트를 호출하는 대표적인 케이스가 metrics-server 입니다. metrics-server 는 K8s 내의 Pod 의 메트릭을 실시간으로 수집해서 kube-apiserver 에 전달하게되는데요, 이것을 통해 HPA(Horizontal Pod Autocaling), VPA(Vertical Pod Autoscaling) 등을 사용가능하게 됩니다.

metrics-server 는 각 노드에 있는 kubelet 의 10250 번 포트로 메트릭을 수집하기위해 kubelet 서버에 HTTP Request 를 하게 됩니다. 

kubelet 은 kube-apiserver 에 대한 클라이언트이자, 파드를 관리하는 오퍼레이터이자, metrics 및 기타 기능을 노출하는 서버로서 동작을 하는 셈입니다.

Kubelet 의 서버 인증서 (x.509)

 kubernetes/cmd/kubelet/app/server.go at 4bb434501d9ee5edda6faf52a9d6d32a969ae183 · kubernetes/kubernetes

kubelet 서버에 대한 TLS 인증서/키를 따로 지정하지 않았을 경우 self-signed certs 를 생성해서 Kubelet 의 서버(10250 번 포트)를 TLS 를 enable 한 서버로 실행합니다. 

/var/lib/kubelet/pki 디렉터리 내의 kubelet.crt , kubelet.key 는 kubelet self-signed 키, 인증서 입니다.

/var/lib/kubelet/pki 에는 두가지 종류의 인증서가 들어가게 되는데요.

kubelet-client-xxx.pem 은 kubelet → kube-apiserver 인증시 Node Authorizer 인증 모드를 사용해 (이건 x509 인증서 내의 CN이 system:nodes:<node-name> 형태로 서명된 인증서를 사용하는거) apiserver 에 인증하기 위한 인증서입니다.

kubelet.crt 는 kubelet 서버가 TLS 서버를 오픈하기 위한 인증서입니다.

이 글에서는 후자를 다루겠습니다.

앞서 이야기 한 것 처럼 kubelet-client-current.pem 의 경우 kubelet -> kube-apiserver 인증을 위한 인증서입니다.

$ openssl x509 -text -noout -in kubelet-client-current.pem 을 해보면

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 2796500698555846452 (0x26cf2a919f8d8f34)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = kubernetes
        Validity
            Not Before: May 27 08:02:17 2024 GMT
            Not After : May 27 08:07:19 2025 GMT
        Subject: O = system:nodes, CN = system:node:node1
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:b6:9d:8f:31:03:12:47:b6:b9:83:62:ef:96:ba:
                    ...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Authority Key Identifier:
                8F:3C:69:8E:62:01:95:BF:FB:D8:8B:41:4A:D7:B8:CF:0F:9C:36:9F
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        9d:38:83:5b:78:2c:56:53:90:02:cb:e3:1e:b4:b0:d3:61:07:
        ...

위와 같이 CN 이 system:node:<node-name> 인 node-authorizer 인증을 위한 인증서임을 알 수 있습니다.  

그러면 kubelet의 TLS 서버를 위한 kubelet.crt 는 어떨까요?

$ openssl x509 -text -noout -in kubelet.crt 를 해보면

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 8001362879639973410 (0x6f0a8d255fefee22)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = node1-ca@1716797154
        Validity
            Not Before: May 27 07:05:54 2024 GMT
            Not After : May 27 07:05:54 2025 GMT
        Subject: CN = node1@1716797154
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:c3:19:c5:5e:71:3f:3c:0e:8b:dc:56:85:2e:7a:
                    ...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Authority Key Identifier:
                CC:87:5A:94:20:C4:F3:11:C6:06:90:A7:A4:C1:B9:1E:FE:51:CE:9F
            X509v3 Subject Alternative Name:
                DNS:node1
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        60:7d:e4:4e:23:2d:50:92:1d:78:51:22:43:ab:38:75:82:93:
        ...

Issuer 의 Common Name을 보면 알겠지만 self-sigend 인증서임을 알 수 있습니다.

이 인증서는 kubelet 을 실행 할 때 kubelet configuration에 tlsPrivateKeyFile , tlsCertFile 을 지정하지 않은 경우 자동 으로 생성됩니다.

https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration 참고.

만약 /var/lib/pki/kubelet.crt , /var/lib/pki/kubelet.key 를 삭제하고 kubelet 을 재실행 하더라도 다시 생성하게 됩니다.

대부분의 케이스에서 이 동작이 크게 문제 될일은 없지만.

metrics-server 의 경우 kubelet 서버의 (10250) 엔드포인트를 찔러서 데이터를 수집하는데, 이 때 10250 포트로 열린 kubelet 의 인증서가 self-signed 인증서 이기 때문에 metrics server 를 설치 한 경우 아래와 같은 에러가 발생하게 될것입니다.

"Failed to scrape node" err="Get \"https://192.168.207.7:10250/metrics/resource\\": x509: cannot validate certificate for 192.168.207.7 because it doesn't contain any IP SANs" node="node5"

kubelet TLS 서버를 띄우기 위한 kubelet self-signed 인증서 내에 SANs 필드에 DNS 정보는 있지만, 해당 kubelet이 떠있는 노드에 대한 IP 정보가 없기 때문에 발생하는 문제입니다. 위쪽에서 kubelet.crt 인증서 내용을 확인해본 내용을 다시 보면. DNS:node1 과 같은 정보는 있지만, IP 정보는 없기 때문에 그렇습니다. 

이 때 보통 찾아보면 나오는 방법이. metrics-server 내에 --kubelet-insecure-tls 를 실행인자로 주는 방법이 있습니다.

하지만 더 올바른 접근법은 아래와 같습니다.

kubelet 의 TLS 인증서를 kube-apiserver 로 부터 받아오기 (TLS Bootstrap)

이것은 kubelet 실행 인자, 혹은 kubelet configuration 에서

serverTLSBootstrap: true

을 추가해서 사용 할 수 있는 방법입니다.

kube-apiserver / controller-manager 에게 TLS 인증서를 요청하는 방법이 있습니다. 그것을 TLSBootstrap 이라고 부릅니다.

우선 기존 kubelet configuration 에 serverTLSBootstrap: true 를 추가합니다.

/etc/kubernetes/kubelet-config.yaml 에 보통 KubeletConfiguration 이 설정되어있을것입니다.

수정 한 이후

$ systemctl stop kubelet

$ systemctl restart kubelet

$ kubectl get csr -A

해당 명령어들을 수행해보면 아래와 같을것입니다.

위와 같이 system:node:<node-name> 으로부터 kubernetes.io/kubelet-serving 형태의 서명 요청이 생겼습니다. 여기서 $ kubectl certificate approve csr-bvbnx 와 같이 해당 서명 요청에대해서 approve 해봅니다.

이렇게 하면 이제 kubelet-server-current.pem 이라는 인증서가 보이게 됩니다. (kubelet.crt , kubelet.key 는 삭제해도 됩니다.)

이제 해당 인증서로 해당 노드의 kubelet 은 10250 번 포트로 TLS 서버를 오픈합니다.

$ openssl x509 -text -noout -in kubelet-server-current.pem 을 확인해보면

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            21:24:58:0f:29:01:0d:ab:45:c4:10:a1:3b:d3:fc:7d
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = kubernetes
        Validity
            Not Before: May 27 09:19:33 2024 GMT
            Not After : May 27 09:19:33 2025 GMT
        Subject: O = system:nodes, CN = system:node:node1
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:e1:30:d0:21:06:29:4b:0d:5e:4e:45:04:9f:d1:
                    ...
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Authority Key Identifier:
                8F:3C:69:8E:62:01:95:BF:FB:D8:8B:41:4A:D7:B8:CF:0F:9C:36:9F
            X509v3 Subject Alternative Name:
                DNS:node1, IP Address:192.168.207.3
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        ca:a1:b9:79:7a:8e:9e:83:89:ad:01:4b:d7:34:ea:f2:6d:13:
        ...

위와 같이 Issuer 의 CN 이 kubernetes 임을 알 수 있습니다.

이건 우리가 쿠버네티스 클러스터를 생성하고 인증서를 만들 때, 자체적으로 사용하는 CA 를 의미합니다( /etc/kubernetes/ssl/{ca.crt,ca.key} ). 쿠버네티스 내의 각종 인증서의 CA 는 이것입니다. (etcd 및 front-proxy 는 별도의 CA를 두는 편입니다)

또한 기존에 self-signed 인증서에는 없었던 IP Address 항목이 SAN 필드에 들어가있는것을 확인 할 수 있습니다. 이로써 metrics-server 가 해당 https://해당IP:10250 로 접근 했을 때 클라이언트 측에서 문제가 생길 것은 없어졌습니다. (기존에는 https://해당IP:10250 으로 접근하지만, 정작 인증서 정보에는 DNS 정보만 있어서 문제가 생겼습니다.)

이제 이상태에서 metrics-server 를 insecure 옵션 없이 써보면 오류 없이 metrics-server 가 잘 kubelet 의 메트릭을 수집하는 것을 확인 할 수 있습니다.

 여기서 부가적으로 얻을 수 있는 장점은. kubelet 의 rotateCerts 기능에 이제 current-server-pem 이 들어오게 되는것입니다. (self-signed 인증서는 kubelet 의 해당 기능이 통제하지 않음. 관련한 다양한 이슈 또한 존재. kubeadm 도 그것을 처리하지 않음)

이렇게 수동으로 approve 해야 하나요? 노드가 계속 늘어나면 어떻게하죠?

우리가 방금 한 방식은 TLS Bootstrap 요청, CSR 요청에 대해서 수동으로 approve 를 하는 방식입니다.

쿠버네티스는 이런 인증서 서명 요청에 대해 자동화 하기 위해 Approver 라는 개념을 두고있습니다.

우리가 컨트롤플레인/워커노드 join 을 할때, 바닐라 혹은 kubeadm 을 써보면 token 을 만들어서 join 하는 방법을 해본적이 있을것입니다.

이것은 token 을 기반으로 인증된 요청에 대해서 TLS Bootstrap 요청을(CSR) 자동으로 수락하는 Approver 를 설정한 것입니다.

kube-controller-manager 에서 controllers 로 default 로 추가되어있지 않아서 (정확히는 Default 로 disable 되어있어서) 추가해줘야 합니다.

kubeadm 으로 클러스터를 프로비저닝 했다면 자동으로 되어있는 사항입니다. (kube-controller-manager )

이렇게 클러스터 조인시 사용되는 TLS Bootstrap 요청에 대해서 승인 할 수 있는 컨트롤러는 사전에 구현되어있지만.

kubelet 의 Server TLS 인증서 요청에 대한 자동 승인 컨트롤러는 kube-controller-manager 에 구현되어있지는 않습니다. 그래서 과거에는

GitHub - kontena/kubelet-rubber-stamp: Simple CSR approver for Kubernetes

Simple CSR approver for Kubernetes. Contribute to kontena/kubelet-rubber-stamp development by creating an account on GitHub.

GitHubkontena

kubelet-rubber-stamp 라는 것이 사용되었었지만, 현재 유지보수 되고있는 프로젝트가 아니고, 또한 몇가지 보안 허점이 있는것으로 알려져있습니다.

GitHub - postfinance/kubelet-csr-approver: Kubernetes controller to enable automatic kubelet CSR validation after a series of (configurable) security checks

Kubernetes controller to enable automatic kubelet CSR validation after a series of (configurable) security checks - postfinance/kubelet-csr-approver

GitHubpostfinance

이것을 위한 대안으로 kubelet-csr-approver 라는 것이 있고 kubespray 또한 kubelet 의 serverTLSBootstrap 옵션을 활성화 하면 이것을 함께 배포하는것으로 개선되었습니다.

그럼 kubespray 에서 저친구 어떻게 쓸 수 있어요?

우선 전역변수에 kubelet_rotate_server_certificates: true 를 넣어줘야 하고

kubespray/roles/kubernetes-apps/kubelet-csr-approver/defaults/main.yml at 5616a4a3eedf3462d25346f02afe57bf36ae77c3 · kubernetes-sigs/kubespray

Deploy a Production Ready Kubernetes Cluster. Contribute to kubernetes-sigs/kubespray development by creating an account on GitHub.

GitHubkubernetes-sigs

여기의 kubelet-csr-approver 의 변수를 설정하는 defaults/main.yml 내에 kubelet_csr_approver_values 를 자신의 상황에 맞게 적절하게 채워줘야합니다.

현재 테스트하는 환경의 경우 모든 노드는 node1, node2 와 같이 node 라는 이름을 prefix 로 갖게하고, 모든 노드는 192.168.207.0/24 CIDR 블록 안에서 프로비저닝 했었기 때문에 아래와 같이 설정했습니다.

이렇게 하면 우리가 수동으로 approve 하지 않고 kubelet-csr-appover 가 설정에 맞는 요청에 대해서 자동으로 approve 하도록 사용 할 수 있습니다.

Kubespray 안쓰면 어떻게 써요?

GitHub - postfinance/kubelet-csr-approver: Kubernetes controller to enable automatic kubelet CSR validation after a series of (configurable) security checks

Kubernetes controller to enable automatic kubelet CSR validation after a series of (configurable) security checks - postfinance/kubelet-csr-approver

GitHubpostfinance

kubelet-csr-approver 는 helm 으로 패키징되어있기 때문에 해당 레포를 참조해서 helm 으로 설치하는것을 권장합니다.

helm repo add kubelet-csr-approver https://postfinance.github.io/kubelet-csr-approver
helm install kubelet-csr-approver kubelet-csr-approver/kubelet-csr-approver -n kube-system \
  --set providerRegex='^node-\w*\.int\.company\.ch$' \
  --set providerIpPrefixes='192.168.8.0/22' \
  --set maxExpirationSeconds='86400'
  --set bypassDnsResolution='false'

여기서도 역시나 위에서 이야기한대로 providerRegex , providerIpPrefixes 등을 여러분의 환경에 맞게 설정하면 됩니다.

Wrapping up

Kubelet 은 10250 번 포트에 TLS 기반의 HTTP 서버(HTTPS)를 열어두고 있습니다. Kubelet 은 kube-apiserver 를 호출하고, 컨테이너 런타임 인터페이스를 통해 파드(컨테이너)를 관리하는것 이외에도 metrics, log 등을 위해 10250번 포트로 서버를 열어두고 있습니다.

이때 별다른 설정을 하지 않고 kubelet 을 실행하면 kubelet.crt , kubelet.key 와 같은 형태의 self-signed 인증서가 /var/lib/kubelet/pki 디렉터리 내에 생성되고, 그것을 기반으로 TLS 서버를 실행합니다.

크게 문제될일은 없지만 metrics-server 를 실행하는 경우에 self-signed 인증서의 문제점으로 인해 metrics-server 가 kubelet metrics 를 긁어올 수 없는 문제가 있습니다. 이 때 보통은 --kubelet-insecure-tls 옵션을 metrics-server 에 추가하여 문제를 해결하기도 하지만 근본적인 문제를 해결한것은 아닙니다.

kubelet 이 kubernetes-ca 를 통해 서명된 인증서를 kubelet 서버에 사용하기 위해서는 serverTLSBootstrap 옵션을 KubeletConfiguration (혹은 kubelet 실행 인자에도 넣을 수 있지만 depracted 되어가고있습니다.)에 추가할 수 있습니다. 다만 이 때에도 해당 CSR(Certificate Signing Request)를 자동으로 수락하는 별도의 애드온등을 사용하지 않는 경우에 수동으로 해당 요청에 대해서 approve 해줘야 합니다.

들어가며

Kubeadm 의 경우 CoreDNS 및 kube-proxy 를 addon 으로 부르며, 클러스터 프로비저닝 시점에서 자동으로 설치합니다. Kubeadm 을 wrapping 한 Kubespray 또한 마찬가지입니다.

만약 Kubeadm 과 같은 프로비저닝 툴을 사용하지 않고 클러스터를 프로비저닝 했다면 CNI 설치, CoreDNS , kube-proxy의 설치같은 작업은 관리자가 직접 해야합니다.

바닐라 쿠버네티스 프로비저닝 툴 작업을 진행하면서 Kubeadm 은 과연 어떻게 CoreDNS 를 설치하고, 또 어떻게 10.96.0.10 등의 ClusterIP 를 고정해서 사용하게 되는지 궁금하여 Kubeadm 의 코드를 확인해가면서 그 동작을 확인해보았습니다.

그 이후 과연 파드들은 어떻게 nameserver 설정을 디폴트로 갖고 오게 되는지 확인해보고, PodSpec 내의 dnsPolicy, dnsConfig 등의 내용을 확인해보았습니다.

마지막으로는 NodeLocal DNSCache 라는 각 노드별로 설치되는 DNS 캐싱 에이전트에 대해서 설명하고, 설치하는 방법에 대해서 소개합니다.

Kubespary로 클러스터를 프로비저닝 하게 되면 NodeLocal DNSCache 는 디폴트로 설치하게 됩니다. 하지만 Kubeadm 으로 클러스터를 프로비저닝하면 수동으로 설치해야합니다.

CoreDNS

CoreDNS 는 Go 로 작성된 DNS 서버입니다. 다양한 환경에서 사용 가능한 DNS 서버로 보통은 쿠버네티스 클러스터에 설치되어서 클러스터내에서 도메인 네임 resolving 을 위해 사용됩니다.(cluster.local)

Kubernetes Pod 의 쿠버네티스 서비스 디스커버리를 위한 nameserver 설정

쿠버네티스 파드를 띄우면 모든 파드에는 /etc/resolv.conf 파일이 있고. 이 파일에는 nameserver 정보가 들어있습니다. kubeadm 으로 프로비저닝 한 클러스터 내의 파드의 /etc/resolv.conf 를 한번 확인해보겠습니다.

$ kubectl run -i -t --rm nginx --image=nginx --restart=Never – sh

확인해보면 nameserver 10.96.0.10 이라는 값이 들어가있는 것을 볼 수 있습니다. 이 네임서버는 어디에 있는 것일까요?

클러스터 내에 설치된 coreDNS 의 서비스 오브젝트를 확인해보겠습니다.

$ kubectl get svc -n kube-system

위 서비스 오브젝트의 ClusterIP 를 확인해보면 아까 nameserver 10.96.0.10 에서 본것과 동일하다는 것을 알 수 있습니다.

그럼 이 파드별로 들어가게 될 /etc/resolv.conf 는 어떻게 지정이 되었고, kubeadm 을 사용하면서 별도로 지정한적도 없는 coreDNS(혹은 kube-dns)의 ClusterIP 는 어떻게 10.96.0.10 으로 고정이 되었을까요?

Kubelet 의 clusterDNS 설정

각 파드별로 생성될 /etc/resolv.conf 의 정보는 kubelet configuration 에서의 clusterDNS 항목을 통해 설정이 됩니다. kubelet config 파일을 확인해보면

clusterDNS 항목에 클러스터 Domain Name 을 처리하기 위한 nameserver 리스트를 넣을 수 있도록 되어있음을 확인 할 수 있습니다. (Customizing DNS Service )

기본적으로 node 의 kubelet 의 clusterDNS 항목을 상속하지만, 파드별로 별도로 수정해야 할 필요가 있다면 podSpec 내의 dnsPolicy 및 dnsConfig 를 이용해 변경 가능합니다.

DNS for Services and Pods

Pod 의 DNS Policy 는 파드별로 설정이 가능합니다. 여기에 설정 가능한 값으로는 Default, ClusterFirst , ClusterFirstWithHostNet , None 등이 설정 가능합니다. 기본적으로 명시하지 않고 파드를 생성하면 ClusterFirst 로 설정됩니다.

ClusterFirst 로 지정하면 cluster.local 과 같은 suffix 가 아닌 www.google.com 과 같은 DNS 쿼리는 DNS 서버의 업스트림 네임서버로 넘어가도록 하는, 기본적으로 CoreDNS(kube-dns) 를 사용하는 옵션입니다.

Default 로 지정하면 해당 파드가 떠있는 노드의 /etc/resolv.conf 설정을 그대로 사용합니다. 따라서 이렇게 지정하고 cluster.local suffix 를 가진 DNS 쿼리를 하게 되었을 때, 노드 에 적절한 네임서버가 설정되지 않은경우 처리되지 않을 수 있습니다.

ClusterFirstWithHostNet 은 파드의 hostNetwork: true 설정을 했을 때 사용해야하며, 만약 hostNetwork: true 설정을 했지만 , ClusterFirst 로 설정하거나, 명시적으로 설정하지 않으면 Default 설정으로 fallback 하게 됩니다.

None 의 경우는 해당 파드가 떠있는 쿠버네티스 환경에서 상속받는 모든 DNS 설정을 무시하고, dnsConfig 를 통해 DNS 설정을 커스텀 할 때 사용합니다.

만약 Pod 내의 DNS 설정을 직접 하고 싶다면, dnsConfig 를 통해 namserver , searches, options 등을 지정 할 수 있습니다.

apiVersion: v1
kind: Pod
metadata:
  name: dnsutils
  namespace: hayden
spec:
  containers:
  - name: dnsutils
    image: registry.k8s.io/e2e-test-images/jessie-dnsutils:1.3
    command:
      - sleep
      - "infinity"
    imagePullPolicy: IfNotPresent
  restartPolicy: Always
  dnsConfig:
    nameservers:
      - 10.96.0.10
      - 123.123.123.123
      - 8.8.8.8
    searches: 
      - consul.local

위와 같이 dnsConfig 를 설정하고 실제 생성된 Pod 내에서 /etc/resolv.conf 를 확인해보면

CoreDNS(kube-dns)의 IP 주소는 어떻게 결정되었을까요?

kubeadm 에서는 kubernetes/cmd/kubeadm/app/phases/addons/dns/manifests.go at 1d5589e4910ed859a69b3e57c25cbbd3439cd65f · kubernetes/kubernetes 여기서 .DNSIP 라는 변수를 통해서 받아서 CoreDNS 의 ClusterIP 주소를 지정하는데요.

kubernetes/cmd/kubeadm/app/constants/constants.go at 5732a8bbb44113f7fba40721f0f2e03051999da0 · kubernetes/kubernetes

위 코드부분을 보면 알겠지만, Service Object 의 CIDR 블록에서 10번째의 IP 주소를 사용하도록 하고있습니다. 그래서 kubeadm 으로 클러스터를 프로비저닝하면 DNS 를 위한 서비스 오브젝트의 ClusterIP 주소는 10.96.0.10 과 같이 10번째 IP 주소로 고정이 되는것입니다.

이것을 kubelet 의 clusterDNS 항목에도, CoreDNS 의 ClusterIP 항목에도 넣어서 일치시켜주는것입니다.

kubeadm 을 사용하지 않고 쿠버네티스 클러스터를 프로비저닝 한 경우(Vanilia) 위와 같은 형태로 사전에 CoreDNS(혹은 kube-dns) 서비스에 대한 ClusterIP 를 미리 계획하고, Kubelet 의 clusterDNS 항목에 설정해줘야 별다른 설정을 하지 않은 파드들이 올바르게 서비스 도메인에 대한 DNS 쿼리 Resolve 를 수행 할 수 있습니다.

Kubeadm 은 어떻게 CoreDNS 를 설치하나요?

$ kubeadm init 으로 컨트롤 플레인 노드를 최초로 생성하는 시점에서 https://github.com/kubernetes/kubernetes/blob/bce55b94cdc3a4592749aa919c591fa7df7453eb/cmd/kubeadm/app/cmd/init.go#L106-L192

혹은 $ kubeadm init phase addon 명령을 수행하는 시점에서 (https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-addon)

kubeadm workflow runner 에 아래 코드와 같은 명령어를 등록하게 됩니다.

https://github.com/kubernetes/kubernetes/blob/1d5589e4910ed859a69b3e57c25cbbd3439cd65f/cmd/kubeadm/app/cmd/phases/init/addons.go#L49-L85

여기서 runCoreDNSAddon 은 아래 코드와 같은것을 수행하고

https://github.com/kubernetes/kubernetes/blob/bce55b94cdc3a4592749aa919c591fa7df7453eb/cmd/kubeadm/app/cmd/phases/init/addons.go#L108-L114

여기에서의 EnsureDNSAddon는 아래쪽 코드에 정의되어있고

https://github.com/kubernetes/kubernetes/blob/bce55b94cdc3a4592749aa919c591fa7df7453eb/cmd/kubeadm/app/phases/addons/dns/dns.go#L90-L170

전반적으로 사용하는 템플릿 manifests 는 아래에 정의되어있습니다.

https://github.com/kubernetes/kubernetes/blob/1d5589e4910ed859a69b3e57c25cbbd3439cd65f/cmd/kubeadm/app/phases/addons/dns/manifests.go

쉽게 추상화해보면, kubeadm init 을 수행하면 여러 phases 를 수행하는데, 그 중 addon phase 가 있고, 별도로 kubeadm init phase addon 으로 해당 phase 만 수행이 가능하기도 합니다.

addon phase 에서는 사전에 정의된 manifests 를 템플리팅하여서 kubeadm 설정에 맞게 manifests를 렌더링하고 그것을 쿠버네티스 클러스터에 반영하는 형태로 CoreDNS를 설치하고있습니다. (kube-proxy 도 마찬가지입니다.)

NodeLocal DNSCache

Using NodeLocal DNSCache in Kubernetes Clusters

kubeadm 으로 프로비저닝 한 클러스터는 CoreDNS 정도만 설치하는 반면, kubeadm 을 wrapping 한 kubespray 의 경우 기본적으로 NodeLocal DNSCache 를 설치하도록 되어있습니다.

NodeLocal DNSCache 는 각 노드별로 DNS 캐싱 에이전트를 DaemonSet 으로 실행하여 클러스터의 DNS 성능을 향상시키기 위해 사용합니다.

쿠버네티스에서 내부 파드간 통신은 대부분 서비스 오브젝트를 통해서 하게 되는데, 이 때 DNS Query 과정은 Pod 가 로컬의 /etc/resolv.conf 설정을 보고 네임서버에 DNS Query 를 하게 되고. 해당 설정에는 보통 CoreDNS 에 대한 서비스 오브젝트 ClusterIP 가 지정되어있습니다. 이 ClusterIP 에 대해서 요청하게되면 내부적으로는 kube-proxy 가 추가한 iptables rule 에 의해 실제 CoreDNS(kube-dns) 엔드포인트로 변환되는 과정을 거치게 됩니다.

만약 각 노드별로 쿠버네티스 클러스터 도메인에 대한 DNS 정보를 캐싱한 데몬셋이 있는 경우 이 iptables 의 DNAT 규칙, connection tracking 을 피하고 단순히 각 노드의 로컬에 있는 DNS 캐시 서버에 질의를 하는 방식으로 단순화 되고, 만약 각 로컬에 있는 DNS 캐싱 에이전트가 Cache Miss 되는 경우에만 CoreDNS(kube-dns)에 캐싱 에이전트가 대신 DNS 정보를 업데이트 하는 식으로 구조가 간단하게 바뀝니다.

NodeLocal DNSCache 설치 방법

Using NodeLocal DNSCache in Kubernetes Clusters

만약 기존 클러스터에 NodeLocal DNSCache 를 설치하고 싶다면 아래와 같은 방식으로 구성해야 합니다.

우선 kubernetes/cluster/addons/dns/nodelocaldns/nodelocaldns.yaml at master · kubernetes/kubernetes 주소의 yaml 파일을 내려받습니다.

# Copyright 2018 The Kubernetes Authors.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#

apiVersion: v1
kind: ServiceAccount
metadata:
  name: node-local-dns
  namespace: kube-system
  labels:
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile
---
apiVersion: v1
kind: Service
metadata:
  name: kube-dns-upstream
  namespace: kube-system
  labels:
    k8s-app: kube-dns
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile
    kubernetes.io/name: "KubeDNSUpstream"
spec:
  ports:
  - name: dns
    port: 53
    protocol: UDP
    targetPort: 53
  - name: dns-tcp
    port: 53
    protocol: TCP
    targetPort: 53
  selector:
    k8s-app: kube-dns
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: node-local-dns
  namespace: kube-system
  labels:
    addonmanager.kubernetes.io/mode: Reconcile
data:
  Corefile: |
    __PILLAR__DNS__DOMAIN__:53 {
        errors
        cache {
                success 9984 30
                denial 9984 5
        }
        reload
        loop
        bind __PILLAR__LOCAL__DNS__ __PILLAR__DNS__SERVER__
        forward . __PILLAR__CLUSTER__DNS__ {
                force_tcp
        }
        prometheus :9253
        health __PILLAR__LOCAL__DNS__:8080
        }
    in-addr.arpa:53 {
        errors
        cache 30
        reload
        loop
        bind __PILLAR__LOCAL__DNS__ __PILLAR__DNS__SERVER__
        forward . __PILLAR__CLUSTER__DNS__ {
                force_tcp
        }
        prometheus :9253
        }
    ip6.arpa:53 {
        errors
        cache 30
        reload
        loop
        bind __PILLAR__LOCAL__DNS__ __PILLAR__DNS__SERVER__
        forward . __PILLAR__CLUSTER__DNS__ {
                force_tcp
        }
        prometheus :9253
        }
    .:53 {
        errors
        cache 30
        reload
        loop
        bind __PILLAR__LOCAL__DNS__ __PILLAR__DNS__SERVER__
        forward . __PILLAR__UPSTREAM__SERVERS__
        prometheus :9253
        }
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-local-dns
  namespace: kube-system
  labels:
    k8s-app: node-local-dns
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile
spec:
  updateStrategy:
    rollingUpdate:
      maxUnavailable: 10%
  selector:
    matchLabels:
      k8s-app: node-local-dns
  template:
    metadata:
      labels:
        k8s-app: node-local-dns
      annotations:
        prometheus.io/port: "9253"
        prometheus.io/scrape: "true"
    spec:
      priorityClassName: system-node-critical
      serviceAccountName: node-local-dns
      hostNetwork: true
      dnsPolicy: Default  # Don't use cluster DNS.
      tolerations:
      - key: "CriticalAddonsOnly"
        operator: "Exists"
      - effect: "NoExecute"
        operator: "Exists"
      - effect: "NoSchedule"
        operator: "Exists"
      containers:
      - name: node-cache
        image: registry.k8s.io/dns/k8s-dns-node-cache:1.23.0
        resources:
          requests:
            cpu: 25m
            memory: 5Mi
        args: [ "-localip", "__PILLAR__LOCAL__DNS__,__PILLAR__DNS__SERVER__", "-conf", "/etc/Corefile", "-upstreamsvc", "kube-dns-upstream" ]
        securityContext:
          capabilities:
            add:
            - NET_ADMIN
        ports:
        - containerPort: 53
          name: dns
          protocol: UDP
        - containerPort: 53
          name: dns-tcp
          protocol: TCP
        - containerPort: 9253
          name: metrics
          protocol: TCP
        livenessProbe:
          httpGet:
            host: __PILLAR__LOCAL__DNS__
            path: /health
            port: 8080
          initialDelaySeconds: 60
          timeoutSeconds: 5
        volumeMounts:
        - mountPath: /run/xtables.lock
          name: xtables-lock
          readOnly: false
        - name: config-volume
          mountPath: /etc/coredns
        - name: kube-dns-config
          mountPath: /etc/kube-dns
      volumes:
      - name: xtables-lock
        hostPath:
          path: /run/xtables.lock
          type: FileOrCreate
      - name: kube-dns-config
        configMap:
          name: kube-dns
          optional: true
      - name: config-volume
        configMap:
          name: node-local-dns
          items:
            - key: Corefile
              path: Corefile.base
---
# A headless service is a service with a service IP but instead of load-balancing it will return the IPs of our associated Pods.
# We use this to expose metrics to Prometheus.
apiVersion: v1
kind: Service
metadata:
  annotations:
    prometheus.io/port: "9253"
    prometheus.io/scrape: "true"
  labels:
    k8s-app: node-local-dns
  name: node-local-dns
  namespace: kube-system
spec:
  clusterIP: None
  ports:
    - name: metrics
      port: 9253
      targetPort: 9253
  selector:
    k8s-app: node-local-dns

파일 명은 nodelocaldns.yaml 로 합니다. (아래쪽의 sed 명령어의 타겟 파일명으로 사용합니다)

kubedns=`kubectl get svc kube-dns -n kube-system -o jsonpath={.spec.clusterIP}`
domain=<cluster-domain>
localdns=<node-local-address>

위와 같은 명령어를 수행해서 올바른 값을 넣습니다. 대부분의 경우

kubedns=10.96.0.10 (서비스 오브젝트의 CIDR 대역에서의 10번째 값)

domain=cluster.local

localdns=169.254.25.10

으로 설정하면 됩니다.

만약 kube-proxy 가 IPTABLES 모드로 실행되고있다면

sed -i "s/__PILLAR__LOCAL__DNS__/$localdns/g; s/__PILLAR__DNS__DOMAIN__/$domain/g; s/__PILLAR__DNS__SERVER__/$kubedns/g" nodelocaldns.yaml

IPVS 모드로 실행되고 있다면

sed -i "s/__PILLAR__LOCAL__DNS__/$localdns/g; s/__PILLAR__DNS__DOMAIN__/$domain/g; s/,__PILLAR__DNS__SERVER__//g; s/__PILLAR__CLUSTER__DNS__/$kubedns/g" nodelocaldns.yaml

위 명령어들은 ConfigMap 을 수정하기 위한 명령어입니다.

apiVersion: v1
kind: ConfigMap
metadata:
  name: node-local-dns
  namespace: kube-system
  labels:
    addonmanager.kubernetes.io/mode: Reconcile
data:
  Corefile: |
    __PILLAR__DNS__DOMAIN__:53 {
        errors
        cache {
                success 9984 30
                denial 9984 5
        }
        reload
        loop
        bind __PILLAR__LOCAL__DNS__ __PILLAR__DNS__SERVER__
        forward . __PILLAR__CLUSTER__DNS__ {
                force_tcp
        }
        prometheus :9253
        health __PILLAR__LOCAL__DNS__:8080
        }
    in-addr.arpa:53 {
        errors
        cache 30
        reload
        loop
        bind __PILLAR__LOCAL__DNS__ __PILLAR__DNS__SERVER__
        forward . __PILLAR__CLUSTER__DNS__ {
                force_tcp
        }
        prometheus :9253
        }
    ip6.arpa:53 {
        errors
        cache 30
        reload
        loop
        bind __PILLAR__LOCAL__DNS__ __PILLAR__DNS__SERVER__
        forward . __PILLAR__CLUSTER__DNS__ {
                force_tcp
        }
        prometheus :9253
        }
    .:53 {
        errors
        cache 30
        reload
        loop
        bind __PILLAR__LOCAL__DNS__ __PILLAR__DNS__SERVER__
        forward . __PILLAR__UPSTREAM__SERVERS__
        prometheus :9253
        }

여기서 __PILLAR__LOCAL__DNS__ 는 각 노드에서 이 DNS Cache 에이전트가 어떤 IP 로 바인딩 될지를 결정하는 부분이고. 우리는 여기서 169.254.25.10 으로 대치하게 됩니다.

__PILLAR__DNS__SERVER__ 의 경우 CoreDNS(kube-dns) 의 ClusterIP 로 대치됩니다.

__PILLAR__CLUSTER__DNS__ 및 __PILLAR__UPSTREAM__SERVERS__ 는 node-local-dns-cache 데몬셋 파드 내부에서 동적으로 대치하는 영역인데, __PILLAR__CLUSTER__DNS__ 는 이 yaml 파일을 사용해서 생성하는 kube-dns-upstream 서비스 오브젝트의 ClusterIP 입니다.

여기서 유의해야하는점은 kube-dns-upstream 서비스 오브젝트의 레이블 셀렉터로 k8s-app=kube-dns 로 되어있기 때문에 CoreDNS 를 수동으로 설치한 경우 레이블에 k8s-app=kube-dns 를 추가해줘야합니다.

(만약 CoreDNS 를 helm 으로 설치했다면 values 에 k8sAppLabelOverride: "kube-dns" 라는 값을 사용하면 됩니다)

__PILLAR__UPSTREAM__SERVERS__ 의 경우 __PILLAR__LOCAL__DNS__ 값과 CoreDNS(kube-dns) ClusterIP 값으로 평가되어서 들어가게 됩니다.

sed 명령어를 사용하지 않고 직접 수정할 경우 아래 값들을 직접 대치하면 됩니다.

__PILLAR__DNS__DOMAIN__ : cluster.local 등의 클러스터 도메인

__PILLAR__LOCAL__DNS__ : 169.254.25.10 등의 node local dns cache 데몬셋 파드가 Listen 할 IP 지정

__PILLAR__DNS__SERVER__ : CoreDNS(kube-dns) 의 ClusterIP

이렇게 해서 node-local-dns 라는 이름의 데몬셋이 성공적으로 배포되고 나면, 실제 파드들이 node-local-dns 파드로 DNS 쿼리를 하도록 변경해야 합니다.

KubeletConfiguration 의 clusterDNS 정보를 업데이트하고, kubelet 재시작을 함으로서 새로 생성되는 파드들에 대해서 node-local-dns 에 클러스터 도메인에 대한 DNS 쿼리를 하도록 설정 할 수 있습니다.

Wrapping up

쿠버네티스의 Pod 가 어떻게 클러스터 도메인에 대한 DNS Query Resolve 를 하는지 알아보면서, CoreDNS 에 대해서 알아보고, kubeadm 은 그것을 어떻게 설치하는지, 그리고 각 파드별 DNS 설정은 어떻게 하는지, 더 나아가서 NodeLocal DNSCache 까지 다양하게 다루게 되었습니다.  

kubadm / kubespray 등의 프로비저닝 툴은 기본적으로 kube-proxy, CoreDNS 등의 애드온을 알아서 설치하고 처리해줍니다. 하지만 Vanilia Kubernetes 클러스터를 구축하는 경우에는 그런것들을 모두 직접 설정해줘야 합니다.

kubeadm 에서 CoreDNS 를 어떻게 설치하고, CoreDNS 의 ClusterIP 는 어떻게 설정된것인지 알아보면서 왜 10.96.0.10 과 같은 IP 주소가 설정되었는지 알 수 있었고. 더 나아가서 kubelet 과도 긴밀히 연계되어있음을 알 수 있었습니다.

최근 packer 를 이용하여 golden image 를 생성해서 Kubernetes 클러스터를 생성하는 작업을, 별다른 프로비저닝 툴의 도움 없이 (kubeadm 조차도 쓰지 않고)진행하고 있습니다.

이 작업을 하는 이유는 Virtual Machine 들로 이루어진 쿠버네티스 클러스터를 프로비저닝/운영 하기 위함이고. 전반적인 모습은 아마도 EKS 와 매우 비슷한 모습일겁니다.

EKS 는 각 쿠버네티스 컴포넌트(바이너리)가 사전에 설치된 쿠버네티스용 ami 기반으로 가상머신(ec2)를 생성하고, 그것들을 클러스터에 join 시키며, 컨트롤 플레인은 AWS가 managed 로 처리해주는 컨셉입니다.

여기서 Virtual Machine 기반의 쿠버네티스 클러스터를 만들어보고 테스트하는 과정에서, 가상머신을 한번 껐다가 켰더니 kubelet 이 아래와 같은 에러 로그를 발생시키고 있었습니다.

May 02 03:05:49 control1 kubelet[1295]: E0502 03:05:49.409568 1295
kubelet.go:1542] "Failed to start ContainerManager" err="[invalid kernel flag: kernel/panic, expected value: 10, actual value: 0, invalid kernel flag: vm/overcommit_memory, expected value: 1, actual value: 0]"

위 에러 로그를 해석해보자면 kubelet 이 컨테이너 매니저를 실행시키는데 실패했고, 그 이유는 kernal/panic 커널 파라미터와 vm/overcommit_memory 커널 파라미터가 kubelet 이 “예상” 한 값과 다르기 때문에 kubelet 의 실행이 실패한것입니다.

우선 잘 알려진 해결 방법은 kubelet 을 실행 할 때 --protect-kernel-defaults=false 실행 인자를 추가해주는 방법이 소개되고 있습니다. 사실 --protect-kernel-defaults=true 가 기본값이기 때문에 위 에러 로그가 발생한것이라고 다시 해석이 가능한데요.

이 실행 인자는 kubelet 이 권장/원하는 커널 파라미터와 실제 커널 파라미터 설정값이 차이가 있을 경우 kubelet 이 오버라이드 할것이냐 말것이냐를 지정하는 옵션으로. 말 그대로 커널 파라미터 설정값을 보호 하겠냐, 보호하지 않겠냐의 의미로 해석하시면 됩니다.

따라서 --protect-kernel-defaults=false 인자를 kubelet 에 실행 인자로 주는 경우 커널 파라미터가 변경되면서 잘 동작하게 됩니다.

kubelet 의 실행 인자 추가/변경하는 방법

Kubelet systemd 서비스 파일을 직접 만들어서 클러스터 프로비저닝 한 경우

우선 kubelet 에 대한 systemd drop-in 파일이 없는 구조에서, 환경변수를 사용하지 않고 kubelet 실행인자를 직접 service 파일에 지정한 경우에는 아래와 같습니다.

[Install]
WantedBy=multi-user.target
[Unit]
Description=Kubernetes Kubelet Server
Documentation=https://github.com/GoogleCloudPlatform/kubernetes
After=containerd.service
Wants=containerd.service
[Service]
ExecStart=/usr/local/bin/kubelet \
  --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubeconfig \
  --config=/etc/kubernetes/kubelet-config.yaml \
  --kubeconfig=/etc/kubernetes/kubelet.kubeconfig \
  --register-node=true \
  --v=2 \
  --protect-kernel-defaults=false
Restart=always
RestartSec=10s
[Install]
WantedBy=multi-user.target

위와 같이 실행 인자에 직접 protect-kernel-defaults=false 를 넣어주면 됩니다.

Kubeadm 을 통해 프로비저닝한 클러스터

만약 systemctl status kubelet 을 했을 때 drop-in 파일이 있는경우 해당 파일을 확인합니다.

위 케이스의 경우 kubeadm 을 통해 프로비저닝한 클러스터이고. /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf 파일에 지정된 systemd 파일의 선언 블록들이 오버라이드 됩니다. 따라서 해당 파일을 확인해봅니다.

# Note: This dropin only works with kubeadm and kubelet v1.11+
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
# This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating the KUBELET_KUBEADM_ARGS variable dynamically
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, the user should use
# the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. KUBELET_EXTRA_ARGS should be sourced from this file.
EnvironmentFile=-/etc/sysconfig/kubelet
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS

위 항목에 여러 환경변수를 지정하는데. $KUBELET_EXTRA_ARGS 의 경우/etc/sysconfig/kubelet 파일을 통해 로드하고. 해당 파일을 열어보면

KUBELET_EXTRA_ARGS=

위와 같이 KUBELET_EXTRA_ARGS 를 볼수 있습니다. 여기서

KUBELET_EXTRA_ARGS="--protect-kernel-defaults=false"

를 넣어주면 됩니다.

Kubespray 를 통해 프로비저닝한 클러스터

kubespray 를 통해 프로비저닝한 클러스터는 단일 systemd service 파일로 구성되어있습니다.

[Unit]
Description=Kubernetes Kubelet Server
Documentation=https://github.com/GoogleCloudPlatform/kubernetes
After=containerd.service
Wants=containerd.service
[Service]
EnvironmentFile=-/etc/kubernetes/kubelet.env
ExecStart=/usr/local/bin/kubelet \
                $KUBE_LOGTOSTDERR \
                $KUBE_LOG_LEVEL \
                $KUBELET_API_SERVER \
                $KUBELET_ADDRESS \
                $KUBELET_PORT \
                $KUBELET_HOSTNAME \
                $KUBELET_ARGS \
                $DOCKER_SOCKET \
                $KUBELET_NETWORK_PLUGIN \
                $KUBELET_VOLUME_PLUGIN \
                $KUBELET_CLOUDPROVIDER
Restart=always
RestartSec=10s
[Install]
WantedBy=multi-user.target

환경변수를 /etd/kubernetes/kubelet.env 를 통해 로드합니다.

해당 파일을 열어보면

KUBE_LOG_LEVEL="--v=2"
KUBELET_ADDRESS="--node-ip=192.168.207.3"
KUBELET_HOSTNAME="--hostname-override=node1"
KUBELET_ARGS="--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf \
--config=/etc/kubernetes/kubelet-config.yaml \
--kubeconfig=/etc/kubernetes/kubelet.conf \
--container-runtime-endpoint=unix:///var/run/containerd/containerd.sock \
--runtime-cgroups=/system.slice/containerd.service \
 "
KUBELET_CLOUDPROVIDER=""
PATH=/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

위와 같이 되어있기 때문에, 아래와 같이 수정해서 저장하면 된다.

KUBE_LOG_LEVEL="--v=2"
KUBELET_ADDRESS="--node-ip=192.168.207.3"
KUBELET_HOSTNAME="--hostname-override=node1"
KUBELET_ARGS="--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf \
--config=/etc/kubernetes/kubelet-config.yaml \
--kubeconfig=/etc/kubernetes/kubelet.conf \
--container-runtime-endpoint=unix:///var/run/containerd/containerd.sock \
--runtime-cgroups=/system.slice/containerd.service \
--protect-kernel-defaults=false \
 "
KUBELET_CLOUDPROVIDER=""
PATH=/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

kubelet 이 어떤 커널 파라미터들이 어떻게 설정되있기를 예상하나요?

위 트러블 슈팅을 하면서 궁금했던건, kubelet 은 그럼 어떤 커널 파라미터가 어떻게 설정되있기를 원하느냐가 궁금했습니다.

단순히 kubelet 이 커널 파라미터를 오버라이드 하도록 두는것보다, 애초에 VM 의 커널 설정을 그렇게 하는것이 좋겠다고 생각했습니다.

거기다가 kubelet 이 해당 커널 파라미터를 원하는데에는 kubernetes 클러스터를 안정적으로 운영하기 위함이라는 추측이 있었고, 커널 파라미터가 어떻게 설정되있기를 바라는지 아는것 또한 충분히 의미가 있을 것이라고 생각했습니다.

kubernetes/pkg/kubelet/cm/container_manager_linux.go at 82cd82aa15aeb5e5ac1201c3b800b8134eb51cb9 · kubernetes/kubernetes

Production-Grade Container Scheduling and Management - kubernetes/kubernetes

GitHubkubernetes

// setupKernelTunables validates kernel tunable flags are set as expected
// depending upon the specified option, it will either warn, error, or modify the kernel tunable flags
func setupKernelTunables(option KernelTunableBehavior) error {
	desiredState := map[string]int{
		utilsysctl.VMOvercommitMemory: utilsysctl.VMOvercommitMemoryAlways,
		utilsysctl.VMPanicOnOOM:       utilsysctl.VMPanicOnOOMInvokeOOMKiller,
		utilsysctl.KernelPanic:        utilsysctl.KernelPanicRebootTimeout,
		utilsysctl.KernelPanicOnOops:  utilsysctl.KernelPanicOnOopsAlways,
		utilsysctl.RootMaxKeys:        utilsysctl.RootMaxKeysSetting,
		utilsysctl.RootMaxBytes:       utilsysctl.RootMaxBytesSetting,
	}

	sysctl := utilsysctl.New()

	errList := []error{}
	for flag, expectedValue := range desiredState {
		val, err := sysctl.GetSysctl(flag)
		if err != nil {
			errList = append(errList, err)
			continue
		}
		if val == expectedValue {
			continue
		}

		switch option {
		case KernelTunableError:
			errList = append(errList, fmt.Errorf("invalid kernel flag: %v, expected value: %v, actual value: %v", flag, expectedValue, val))
		case KernelTunableWarn:
			klog.V(2).InfoS("Invalid kernel flag", "flag", flag, "expectedValue", expectedValue, "actualValue", val)
		case KernelTunableModify:
			klog.V(2).InfoS("Updating kernel flag", "flag", flag, "expectedValue", expectedValue, "actualValue", val)
			err = sysctl.SetSysctl(flag, expectedValue)
			if err != nil {
				if inuserns.RunningInUserNS() {
					if utilfeature.DefaultFeatureGate.Enabled(kubefeatures.KubeletInUserNamespace) {
						klog.V(2).InfoS("Updating kernel flag failed (running in UserNS, ignoring)", "flag", flag, "err", err)
						continue
					}
					klog.ErrorS(err, "Updating kernel flag failed (Hint: enable KubeletInUserNamespace feature flag to ignore the error)", "flag", flag)
				}
				errList = append(errList, err)
			}
		}
	}
	return utilerrors.NewAggregate(errList)
}

kubelet 의 linux 컨테이너 매니저 코드인 pkg/kubelet/cm/container_manager_linux.go 코드를 확인해보면

VMOvercommitMemory , VMPanicOnOOM 과 같은 값을 볼 수 있는데 이것은 utilsysctl 쪽에 아래와 같이 정의되어있습니다.

kubernetes/staging/src/k8s.io/component-helpers/node/util/sysctl/sysctl.go at 82cd82aa15aeb5e5ac1201c3b800b8134eb51cb9 · kubernetes/kubernetes

Production-Grade Container Scheduling and Management - kubernetes/kubernetes

GitHubkubernetes

const (
	sysctlBase = "/proc/sys"
	// VMOvercommitMemory refers to the sysctl variable responsible for defining
	// the memory over-commit policy used by kernel.
	VMOvercommitMemory = "vm/overcommit_memory"
	// VMPanicOnOOM refers to the sysctl variable responsible for defining
	// the OOM behavior used by kernel.
	VMPanicOnOOM = "vm/panic_on_oom"
	// KernelPanic refers to the sysctl variable responsible for defining
	// the timeout after a panic for the kernel to reboot.
	KernelPanic = "kernel/panic"
	// KernelPanicOnOops refers to the sysctl variable responsible for defining
	// the kernel behavior when an oops or BUG is encountered.
	KernelPanicOnOops = "kernel/panic_on_oops"
	// RootMaxKeys refers to the sysctl variable responsible for defining
	// the maximum number of keys that the root user (UID 0 in the root user namespace) may own.
	RootMaxKeys = "kernel/keys/root_maxkeys"
	// RootMaxBytes refers to the sysctl variable responsible for defining
	// the maximum number of bytes of data that the root user (UID 0 in the root user namespace)
	// can hold in the payloads of the keys owned by root.
	RootMaxBytes = "kernel/keys/root_maxbytes"
	// VMOvercommitMemoryAlways represents that kernel performs no memory over-commit handling.
	VMOvercommitMemoryAlways = 1
	// VMPanicOnOOMInvokeOOMKiller represents that kernel calls the oom_killer function when OOM occurs.
	VMPanicOnOOMInvokeOOMKiller = 0
	// KernelPanicOnOopsAlways represents that kernel panics on kernel oops.
	KernelPanicOnOopsAlways = 1
	// KernelPanicRebootTimeout is the timeout seconds after a panic for the kernel to reboot.
	KernelPanicRebootTimeout = 10
	// RootMaxKeysSetting is the maximum number of keys that the root user (UID 0 in the root user namespace) may own.
	// Needed since docker creates a new key per container.
	RootMaxKeysSetting = 1000000
	// RootMaxBytesSetting is the maximum number of bytes of data that the root user (UID 0 in the root user namespace)
	// can hold in the payloads of the keys owned by root.
	// Allocate 25 bytes per key * number of MaxKeys.
	RootMaxBytesSetting = RootMaxKeysSetting * 25
)

위 코드의 내용들을 정리해보면 kubelet 이 검증( --protect-kernel-defaults=false 인자가 들어온다면 수정)하는 커널 파라미터는 아래와 같았습니다.

vm.overcommit_memory = 1
vm.panic_on_oom = 0
kernel.panic = 10
kernel.panic_on_oops = 1
kernel.keys.root_maxkeys = 1000000
kernel.keys.root_maxbytes = 25000000 # root_maxkeys * 25

제가 작업하는 환경에서는 packer 를 통해 쿠버네티스 노드(컨트롤 플레인 노드, 워커노드 모두)의 이미지를 만들기 때문에, 이미지를 빌드할 때에 아래와 같은 ansible task 를 추가하여서 반영했습니다.

- name: kubelet이 원하는 커널 파라미터 변경
  ansible.posix.sysctl:
    sysctl_file: /etc/sysctl.d/k8s.conf
    name: "{{ item.name }}"
    value: "{{ item.value }}"
    state: present
    reload: yes
  with_items:
    - { name: kernel.keys.root_maxbytes, value: 25000000 }
    - { name: kernel.keys.root_maxkeys, value: 1000000 }
    - { name: kernel.panic, value: 10 }
    - { name: kernel.panic_on_oops, value: 1 }
    - { name: vm.overcommit_memory, value: 1 }
    - { name: vm.panic_on_oom, value: 0 }

실제로 kubespray 또한 비슷한 작업을 하는데요.

kubespray/roles/kubernetes/preinstall/tasks/0080-system-configurations.yml at e01355834b461cf6e5578088ac377be2b6f70e6a · kubernetes-sigs/kubespray

Deploy a Production Ready Kubernetes Cluster. Contribute to kubernetes-sigs/kubespray development by creating an account on GitHub.

GitHubkubernetes-sigs

위 코드를 통해 볼 수 있습니다.

다만, task 이름이 명확하지 않아서 관련한 이슈/PR 까지도 남겼습니다.

Change a task name in preinstall tasks (in 0080-system-configurations.yml ) · Issue #11170 · kubernetes-sigs/kubespray

What would you like to be added I think that change the task name Ensure kube-bench parameters are set in kubernetes/preinstall/tasks/0080-system-configurations.yml into Ensure kubelet expected par…

GitHubkubernetes-sigs

Change a task name in preinstall/0080-system-configurations.yml by kimsehwan96 · Pull Request #11171 · kubernetes-sigs/kubespray

What type of PR is this? /kind documentation What this PR does / why we need it: These kernel parameters are the expected values for kubelet to operate(not the kube-bench), so it would be good to c…

GitHubkubernetes-sigs

Wrapping up

이렇게 해서 가상머신이 부팅 된 이후에 발생하는 kubelet 에러의 원인이 무엇인지 확인했고, 더 나아가서 kubelet 코드 내부에서 이것들을 어떻게 처리하고있고, 어떤 커널 파라미터들을 expect 하고 있는지 확인 할 수 있었습니다.

--protect-kernel-defaults=false 옵션을 kubelet 실행인자에 주면 위 에러는 쉽게 해결됩니다. 해당 커널 파라미터들을 kubelet 이 덮어씌우기 때문이죠.

위와 같은 방법으로 쉽게 해결되는 문제이지만, 근본적으로 kubelet 이 예상하는(expect)커널 파라미터에 무엇이 있으며, 어떤 값으로 설정되어야하는지. 더 나아가서는 그 커널 파라미터, 값들이 어떤 의미를 갖는지까지 알아보는것이 좋다고 생각합니다.

Raft 알고리즘 논문 : https://raft.github.io/raft.pdf

더 자세한 버전의 논문 : https://web.stanford.edu/~ouster/cgi-bin/papers/OngaroPhD.pdf

Raft는 복제된 로그들을 관리하기 위한 합의 알고리즘 입니다. Paxos 와 비슷한 결과를 낼 수 있으며, Paxos 만큼이나 효율적인 알고리즘입니다. 하지만 Paxos 보다는 더 이해하기 쉬운 알고리즘이기도 합니다. Raft 의 이해도를 높이기 위해서, Raft 는 리더 선출, 로그 복제, 안전과 같은 합의 알고리즘의 핵심 요소를 분리하고 고려해야하는 상태의 수를 줄이기 위해 더 높은 수준의 일관성을 적용합니다.

Raft 는 다른 합의 알고리즘 (Oki, Liskov’s Viewstamped Replication..)과 비슷하지만, 몇가지 주목할만한 기능들이 있습니다.

• Strong Leader : Raft 는 다른 합의 알고리즘에 비해 더 강력한 형태의 리더십을 사용합니다. 예를들자면 로그 항목은 오직 leader 에서 다른 서버로만 전달됩니다. 이를 통해 복제된 로그 관리를 간단하게 하며, Raft 를 더 이해하기 쉬운 알고리즘으로 만들어줍니다.
• Leader election : Raft는 리더를 선출하기 위해 랜덤화된 타이머를 사용합니다. 다른 합의 알고리즘에서 필요한 heaatbeat 에 아주 작은 부분만 추가한것이고, 복잡성을 줄이고 신속하게 리더를 선출 할 수 있게 합니다.
• Membership changes : 클러스터의 서버 집합(set)을 변경하는 작동 방식은 새로운 방식의 joint consensus 방식을 사용합니다. 두 개의 서로 다른 구성이 전환중이더라도 클러스터가 계속 정상 동작 할 수 있습니다.

Replicated state machine

합의 알고리즘은 Replicated state machine 개념으로부터 출발했습니다. 이러한 접근법을 통해 여러 서버에 존재하는 상태머신은 명확하게 같은 상태를 복제하고, 일부 서버가 중단되더라도 정상적으로 동작하도록 합니다.

Replicated state machine 는 분산 시스템에서의 다양한 내결함성 문제를 해결하기위해 사용됩니다.

Replicated state machine 은 일반적으로 복제된 로그를 기반으로 구현됩니다.(위 사진 참조)

각 서버는 상태 머신이 순서태로 처리한 일련의 command 를 포함한 복제된 로그를 갖고 있고. 각 복제된 로그는 같은 command 를 같은 순서로 갖고 있어서 각 상태머신은 같은 command 들을 같은 순서로 처리합니다. 각 상태머신은 결정론적이므로 같은 상태를 계산하고, 같은 순서의 결과들을 반환합니다.

복제된 로그를 일관성 있게 유지하는것이 합의 알고리즘이 하는 일입니다. 서버에 있는 합의 모듈(Consensus Module) 클라이언트로부터 command를 수신하고, 그것을 log 에 추가합니다. 그리고 합의 모듈은 이룹 서버가 문제가 생기더라도 모든 로그가 같은 요청을 같은 순서로 저장하도록 보장하기 위해서 다른 서버에 있는 합의모듈과 통신합니다.

command들이 정상적으로 복제되었다면(로그로 잘 쌓였다면) 모든 서버의 상태머신은 로그를 순서대로 처리하게 되고, 모든 서버의 요청에대한 결과는 동일하게 됩니다. 결과적으로 서버들은 하나의 매우 안정적인 상태머신처럼 보이게 됩니다. (어떤 서버에 요청을 해도 동일한 응답을 받을 수 있으니까, 게다가 그 서버들중 몇개가 죽더라도 문제가 없으니까)

실제 시스템에 사용하기위한 합의 알고리즘은 아래과 같은 속성을 갖습니다.

• 네트워크 딜레이, 네트워크 패킷 유실 과 같은 모든 비잔틴 장애 조건이 아닌 상황에서 결함이 없어야(safety 해야)합니다.
• 서버의 대부분이 작동하고 클라이언트와 서로 통신 할 수 있는 한 기능적으로 완벽히 동작해야합니다. 따라서, 일반적인 5대의 서버로 구성된 클러스터는 어떤 서버가 장애가 발생하든 2개의 서버까지 장애는 견뎌 낼 수 있습니다. 서버는 중지됨으로써 장애가 발생하는것으로 가정되고, 장애가 발생한 서버들은 추후에 안정적인 스토리지에서 상태를 복구하고, 클러스터에 다시 join 할 수 있어야 합니다.
• 로그의 일관성을 유지하기 위해 타이밍에 의존하지 않습니다. 고장난 클럭과 심각한 메시지의 지연은 심각한 상황에서 가용성 문제를 발생시킬 수 있습니다.
• 일반적으로 클러스터의 과반수가 단일 RPC 호출에 응답하면 command를 완료 할 수 있습니다. 소수의 느린 서버가 클러스터 전체 성능에 영향을 미치지 않아야 합니다.

이해하기 쉽게 설계

Raft 를 설계할 때 몇가지 목표가 있었습니다.

하나는 개발자들이 설계를 하는데 시간을 확실히 줄일 수 있도록, 시스템을 만들기 위한 완벽하고 실질적으로 사용 가능한 기초(뼈대)를 제공하는 것이였고, 다른 하나는 일반적인 운영 상황에서는 효율적으로 동작하면서, 모든 조건에서 안전하게 동작하고, 특정한 조건의 운영 상황에서도 사용 가능하도록 하는것이 목표였습니다.

하지만 가장 큰 목표는 (그리고 제일 어려웠던) 바로 이해하기 쉽게 만들기였습니다.

많은 청중들이 알고리즘을 편안하게 이해할 수 있게 해야 했고, 시스템을 구축하려는 사람들이 실제 구현에서 불가피하지만 필요한 확장을 할 수 있도록, 이 알고리즘에 대한 직관을 얻을 수 있게 해야 했습니다.

결론적으로 Raft 알고리즘을 설계하면서 아래와 같은 두가지 기법을 사용하게 되었는데.

1. Problem decomposition (문제 분해) : Raft 의 설계에서 복잡한 문제를 더 작고 독립적으로 설명하고 해결 할 수 있는 부분들로 나누어 접근하는 방식입니다. 예를들어서 리더 선출, 로그 복제, 안정성 검증, 멤버십 변경등과 같은 부분을 별도의 구성요소(문제)로 분해해서 설명합니다.
2. Smplify the state space (상태 공간 단순화): 시스템이 가질 수 있는 가능한 상태의 수를 줄임으로써 시스템을 더 일관성 있게 만들고 비결정성(nondeterminism)을 가능한한 제거합니다.

예를들어서 로그는 비어있는 데이터를 저장할 수 없고 Raft는 로그들이 서로 일치하지 않도록 하는 작업/방법을 제한합니다.

하지만 가끔은 비결정성이 이해도를 더 높이기도 하는데. 예를들자면 무작위화(Randomization)가 그랬습니다.

무작위화는 비결정성을 오히려 도입하기는 하지만, 모든 가능한 선택을 비슷한 방식으로 처리하기 때문에 오히려 상태공간을 줄일 수 있었는데.(아무거나 선택해도 상관 없다 라는 관점) Raft 의 리더 선출 알고리즘에서의 무작위화가 상태공간을 줄일 수 있는 케이스였습니다.

Raft는 복제된 로그를 관리하기 위한 알고리즘입니다. 우선 Raft는 하나의 단일 리더를 선출하고, 리더에게 복제된 로그들을 관리할 책임을 주는것으로부터 합의 알고리즘 구현을 시작합니다.

리더는 클라이언트로부터의 로그 생성을 허용하고, 다른 서버들에게 로그를 복제해줍니다, 그리고 상태 머신에 언제 로그 생성을 적용해야 안전한지도 전달합니다.

리더는 복제된 로그를 관리하는것을 간단하게 만듭니다. 예를들어 리더는 다른 서버들과 의견을 주고받을 필요 없이 새로운 로그 생성을 언제, 어디에 해야할지 정합니다.

따라서 데이터는 리더로부터 다른 서버로 간단하게 흐르게 됩니다. 리더가 실패하거나 다른 서버들과의 연결이 끊어 질 수 있는데 이 경우에는 새로운 리더가 선출됩니다.

이러한 접근법을 통해 Raft 는 합의 문제를 아래와같은 세개의 독립적인 하위 문제로 분리합니다.

• 리더 선출 : 새로운 리더는 기존에 존재하는 리더가 실패하는 경우에만 선출합니다.
• 로그 복제 : 리더만 클라이언트가 요청하는 로그 생성을 허용하고 전체 클러스터에 거쳐 로그를 복제합니다. 또한 다른 로그들이 자신의 로그와 일치하도록 강제합니다.
• 안정성 : Raft에 있어서 핵심적인 안정성은 바로 상태 머신이라는 점인데, 만약 어떤 서버가 특정 로그 항목을 자신의 상태머신에 적용했다면, 다른 서버는 동일한 로그 인덱스에 대해서 다른 command(명령/항목)을 적용 할 수 없습니다. 뒷 부분에서 어떻게 이것을 보장하는지 설명합니다.

• 선출 안정성 : term 을 임기라고 앞으로 이야기하겠습니다. 단일 임기동안 오직 하나의 리더만이 선출됩니다.
• 리더는 Append only : 리더는 절대로 로그항목을 덮어쓰거나 삭제하지 않습니다. 오직 생성만 합니다.
• 로그 일치 : 만약 두 로그가 동일한 인덱스와 항목을 갖고 있다면, 그 로그들은 주어진 인덱스를 통해 모든 항목에 있어서 동일합니다.
• 리더 Completeness : 어떤 로그 항목이 특정 임기(어떤 리더가 존재할 때) 커밋되었다면, 그 항목은 더 높은 번호의 임기(term)을 가진 모든 리더들의 로그에 존재합니다.
• 상태 머신 안정성 : 만약 서버가 로그 항목을 특정 인덱스에서 자신의 상태머신에 적용했다면, 다른 서버는 그 인덱스에 대해서 다른 로그 항목을 적용 할 수 없습니다. (그러니까 애초에 데이터에 대한 conflict이 나지 않는것)

Raft 의 근간

Raft 클러스터에는 여러 서버가 포함되어있고, 일반적으로 5대를 사용하고, 이런 경우에는 2대의 서버 고장을 버틸 수 있습니다. 어떤 상황속에서도 각 서버는 세가지 상태 중 하나인데, 각 상태는 리더, 팔로워, 혹은 후보자(candidate)입니다.

정상 동작중에는 오직 하나의 리더가 있고, 다른 모든 서버는 팔로워입니다. 팔로워는 수동적이라서 단순히 리더와 후보로 부터 온 요청에만 응답합니다. 리더는 모든 클라이언트의 요청을 처리합니다. (논문에는 이렇게 적혀있지만, etcd 의 경우는 그렇지 않기 때문에 더 확인 해 볼 필요가 있음)

세번째 상태인 후보자는 새로운 리더를 뽑기 위해서 사용됩니다. 아래 그림은 이러한 리더, 팔로워, 후보 상태 변화를 간략하게 보여줍니다. 뒤에서 리더 선출에 대해서 자세히 다룹니다.

아래 그림에서 보여지는 것 처럼 임의의 길이의 임기로 시간을 나눕니다. 이 임기는 연속정인 정수로 번호가 매겨집니다. 각 임기는 선거로 시작되며, 하나 이상의 후보가 리더가 위해서 서로 경쟁합니다.

한 후보가 리더 선출 선거에서 과반수 이상 득표하면, 그 임기동안 리더로서 역할을 합니다. 어떤 상황에서는 선거가 실패하는데, 이런 경우 리더 없이 해당 임기를 끝내고, 새로운 임기(새로운 리더 선출 선거 시작과 함께)가 시작됩니다.

이렇게 해서 Raft 는 한 임기에 오직 하나의 리더만 존재할 수 있도록 보장합니다.

각 서버는 단순하게 증가하는 정수로된 임기 번호를 저장합니다. 임기는 서버들이 통신 할 때 마다 서로 정보를 교환하며, 만약 한 서버의 임기가 다른 서버의 임기보다 작다면 작은 임기를 더 큰 값으로 업데이트 합니다.

만약 후보자나 리더가 자신의 임기가 구식이라는걸 발견하면 그 즉시 팔로워 상태로 되돌아갑니다. 또한 구식 임기 번호를 가진 요청을 받으면 그 요청을 거부합니다.

Raft 서버들은 원격 프로시저 호출(RPC)를 사용해 통신하고. 기본적인 합의 알고리즘은 오직 두종류의 RPC만이 필요한데. RequestVote RPC 와 AppendEntries RPC가 그것입니다.

RequestVoteRPC 는 리더 선출 선거 기간 중에 후보자들에 의해서 발생되고, AppendEntries RPC는 리더들이 로그 항목을 복제하고 하트비트 형태를 제공하기 위해 시작됩니다.

InstallSnapshot RPC 라는 추가적인 확장 RPC도 존재하는데 이는 뒤에서 다루겠습니다.

서버들이 응답을 못받는 경우 RPC를 재시도하고, 성능을 위해 병렬로 요청합니다.

리더 선출

Raft는 리더 선출을 발생시키기 위해서 heatbeat 메커니즘을 사용합니다. 서버들이 최초에 시작되었을 때, 팔로워 상태로 시작합니다.

서버는 유효한 RPC를 리더나 후보자로부터 수신하기 전까지 팔로워 상태로 남아있습니다.

리더는 주기적으로 heatbeat(정확히는 로그 항목을 포함하지 않는 AppendEntries RPC를 보냅니다)를 팔로워들이 그들의 우선순위를 유지하도록 보냅니다.

만약 팔로워가 election timeout 이 끝나기 전까지 아무 정보를 받지 못한다면, 살아있는 리더가 없다고 판단하고 새로운 리더를 선출하기 위한 선거를 시작합니다.

선거를 시작하기 위해서 팔로워는 자신의 현재 임기(term) 숫자를 증가시키고(1 증가시킵니다) 자신을 후보자 상태로 바꿉니다. 그리고 해당 후보자는 자기 자신에게 투표하고, RequestVote RPC 를 병렬적으로 다른 모든 서버들에 보냅니다.

그리고 후보자는 아래 세개의 일중 하나가 발생하기 전까지 자신의 상태를 유지합니다.

1. 선거에서 승리(정족수 이상 득표)
2. 다른 서버가 리더가 되는 경우
3. 리더 선출에서 아무도 승리하지 못하고 특정 시간이 지난 경우

만약 같은 임기(term)에서 전체 클러스터에 대해서 정족수 이상을 득표하면 후보자는 리더 선출 선거에서 승리하게 됩니다. 모든 서버들은 같은 임기 내에서 선착순으로 오직 하나의 후보자에게만 투표합니다.

그리고 정족수 이상 득표해야 리더 선출 선거에서 승리하는 규칙은 적어도 하나의 후보자만 특정 임기 내에서 승리 할 수 있음을 보장하기도 합니다.

후보자가 선거에서 승리하는 경우 후보자는 리더가 됩니다. 그리고 모든 서버들에게 자신들의 우선순위를 설정하도록(팔로워 상태로 유지하라고), 그리고 새로운 선거를 시작하지 않도록 heartbeat 메시지를 남은 모든 서버에게 보냅니다.

투표를 기다리는 동안, 후보자는 AppendEntries RPC 를 다른 서버로부터 해당 서버가 리더라고 이야기하는 정보를 받을수 있습니다. 만약 RPC에 들어있는 해당 리더의 임기(term)가 자신의 term 보다 적어도 같거나, 크다면 후보자는 해당 리더를 정상적인 리더라고 인지하고 팔로워 상태로 변환됩니다.

만약 RPC 안에 있는 임기(term)이 후보자의 현재 임기(term)보다 작다면, 후보자는 그 RPC 를 거부하고 계속해서 후보자 상태를 유지합니다.

세번째 가능한 결과는, 후보자가 선거에서 이기지도, 지지도 않는 상황입니다. 만약 많은 팔로워들이 동시에 후보자가 된다면 어떤 후보자도 정족수 이상 득표를 할 수 없을겁니다.

이런 상황이 발생하면 각 후보자는 timeout 상태가 되고, 현재 임기 값을 1 늘리고 난 뒤 새로운 선거를 시작하고, RequestVote RPC 요청을 보냅니다. 어쨌든 추가적인 조치 없이는 이런 상황이 계속해서 발생 할 수도 있습니다. (만약 모든 서버의 타임아웃 설정이 동일하다면 ..)

Raft는 랜덤화된 election timeout 을 통해 이런 표가 분산되는 상황을 거의 없애고, 그런 일이 발생하더라도 빠르게 해결하도록 하였습니다. 이런 득표 분산상황을 막기위해서 election timeout은 고정된 범위의 시간대 안에서 랜덤하게 결정됩니다. (예를들어 150 ~ 300ms).

이런 조치는 대부분의 상황에서 오직 하나의 서버만 타임아웃 상태가 되도록 할 수 있고. 타임아웃 상태가 된 서버가 빠르게 리더가 되고 다른 서버가 timeout이 되기전에 heartbeat을 보낼 수 있게 합니다.

이와 동일한 메커니즘이 득표 분산을 막기 위해서 사용됩니다. 모든 후보자들은 선거가 시작되는 시점에서 랜덤화된 election timeout 을 설정하고 재시작하고, 다음 선거를 시작하기 전에 해당하는 timeout 까지 경과를 지켜봅니다.

로그 복제

리더가 한번 선출되고 나면, 리더는 클라이언트의 요청을 처리하기 시작합니다. 각 클라이언트 요청은 모든 복제된 상태머신에서 처리되어야 하는 command 를 포함하고 있습니다. (논문에서는 command로 지칭하지만, 단적으로 etcd를 생각한다면 저장할 데이터라고 생각해도 무방합니다.)

리더는 새로운 항목으로 해당 command 를 append 하고, AppendEntries RPC를 각 모든 서버에 병렬적으로 요청해서 해당 항목을 복제하도록 합니다. 만약 해당 항목이 안전하게 복제되었다면, 리더는 해당 항목을 상태머신에 반영하고 클라이언트에게 처리 결과를 반환합니다.

만약 팔로워가 충돌이 나거나 느리게 동작하는경우, 혹은 네트워크 패킷이 유실되는 경우 리더는 모든 팔로워가 모든 로그 항목을 저장할 때 까지 AppendEntries RPC를 무한히 재시도 합니다. (처리 결과가 클라이언트에 응답되었다고 하더라도)

로그는 위 그림에서 보는 것 처럼 정리됩니다. 각 로그 항목은 리더로부터 전달받은 항목들을 상태머신의 command를 임기(term)숫자와 함께 저장합니다. 각 로그 항목은 로그안에서의 위치를 지정하기 위해서 정수형태의 index를 갖고 있습니다.

리더는 언제 로그 항목을 상태 머신에 반영해야 안전한지 결정합니다. 그런 로그 항목을 committed 되었다고 부르겠습니다. Raft는 커밋된 항목이 안정적이고, 결국에는 모든 가용한 상태 머신들에 의해 실행될 것임을 보장합니다.

로그 항목은 정족수 이상의 상태머신에 복제된 항목을 리더가 한번 커밋합니다. 이전 리더에 의해 생성된 항목을 포함하여 리더의 로그에 있는 모든 선행 항목도 모두 커밋합니다.

리더는 계속해서 커밋되어야할 가장 최신(높은)값의 index를 계속해서 추적합니다, 그리고 이 값은 AppendEntries RPC (hearthbeat 포함)내에 포함되어서 다른 서버들이 알 수 있게 합니다. 팔로워가 로그 항목이 커밋되었다는걸 알게 되면, 팔로워 자기 자신의 로컬 상태 머신에 해당 항목을 반영합니다. (순서대로)

Raft는 아래의 속성을 유지합니다.

• 만약 서로 다른 로그에서의 두개의 항목이 같은 index 와 같은 term 을 갖고있다면, 그것들은 같은 command를 저장합니다.
• 만약 서로 다른 로그에서의 두개의 항목이 같은 index와 term 을 갖고있다면, 그것들은 모든 선행 항목에서 동일합니다.

첫번째 속성은 리더가 주어진 로그 index와 term에서 오직 하나의 항목만 생성한다는 사실을 통해 이뤄지고, 로그 항목은 절대로 로그 안에서의 위치(index)를 바꾸지 않습니다.

두번째 속성은 AppendEntires RPC를 통해 이뤄지는 간단한 일관성 체크를 통해서 보장됩니다. AppendEntries RPC가 보내질 때, 리더는 새로운 항목들 바로 앞에 있는 자신의 로그 내 항목의 index와 term 을 포함시킵니다.

만약 팔로워가 같은 index와 term을 포함하는 해당 로그의 항목을 찾지 못하는 경우, 새로운 항목을 거부합니다.

이런 일관성 검사는 귀납적으로 작용합니다. 로그의 초기 빈 상태는 로그 일치 속성을 만족시키고, 일관성 검사는 로그가 확장 될 때 마다 로그 일치 속성을 보존합니다. 그 결과로 AppendEntries 가 성공적으로 반환 될 때 마다 리더는 팔로워의 로그가 새 항목을 통해 자신의 로그와 동일하다는 것을 알게 됩니다.

정상적인 운영 상황에서는 리더와 팔로워들의 로그가 일관성 있게 유지되므로, AppendEntries 의 일관성 체크는 절대로 실패하지 않습니다. 그러나 리더의 crash 는 로그 일관성을 깰 수 있습니다. (이전 리더가 자신의 로그에 있는 항목을 모두 복제 못했다면).

이런 비일관성은 여러차례의 리더와 팔로워의 crash 로 발생 될 수 있습니다. 팔로워는 리더에게는 있는데 자신에게 없는 항목을 누락 할 수도 있고, 리더에게 없는 추가 항목을 가질 수 도 있고, 둘다 그럴수도 있습니다. (위 그림들 참고)

Raft 에서는 리더가 팔로워들의 로그를 자신의 로그를 복제하도록 강제함으로써 이런 일관성이 깨지는 문제를 처리합니다. 즉, 팔로워 로그의 충돌하는 항목들은 리더의 로그로 덮여쓰여진다는 것을 의미합니다.

팔로워의 로그를 리더의 로그와 일치시키기 위해서, 리더는 팔로워와 자신이 일치하는 가장 최근의 로그를 찾아야 합니다. 그리고 그 지점 이후의 팔로워의 로그의 모든 항목을 삭제하고, 팔로워에게 그 시점 이후의 모든 리더의 로그를 보내야 합니다.

이런 모든 일들은 AppendEntries RPC의 일관성 체크가 수행됨으로써 이루어 집니다.

리더는 각 팔로워의 nextIndex 를 관리합니다. 이 값은 팔로워에게 리더가 보내야하는 다음 로그 항목의 index 값을 의미합니다. 리더가 처음으로 본인의 임기가 시작되었을 때, 모든 팔로워의 nextIndex 값 (리더 내부적으로 관리하는 각 서버들에 대한 메타 데이터입니다.) 을 자신의 마직 로그 index의 다음 값으로 초기화 합니다.

만약 팔로워의 로그가 리더의 것과 일치하지 않는다면 AppendEntries RPC 에서의 일관성 체크가 실패할 것이고. 팔로워가 AppendEntries RPC 에 대한 응답을 거부하고, matchIndex 0 을 전달하면, 리더는 해당 팔로워의 nextIndex 값을 감소시키고 AppendEntries RPC 를 재시도 합니다. 이 과정이 반복되면 결국에 리더와 팔로워의 nextIndex 값이 일치하는 지점에 도달합니다.

결국 이렇게 nextIndex 값이 일치하는 지점에서 팔로워는 충돌되는 모든 해당 시점 이후의 로그를 제거하고, 리더의 로그에서 새로운 항목들을(있다면) 추가합니다.

이런 메커니즘을 통해 리더가 부임되었을 때 로그 일관성을 복원하기 위해 특별한 조치를 할 게 없습니다. AppendEntries의 일관성 검사의 실패가 누적되다 보면, 불일치 지점을 찾고, 복원하는 방향으로 로그들이 수렴됩니다.

리더는 절대로 자신의 로그에서 로그 항목을 덮어쓰거나 삭제하지 않습니다. 이러한 로그 복제 메커니즘은 서버의 정족수 이상이 작동중인 한 Raft 는 새로운 로그를 수락하고, 복제하며, 반영 할 수 있게 됩니다.

정상적인 클러스터는 정족수 이상의 서버에 단 한번의 RPC로 새 항목을 복제 할 수 있습니다. 또한 단 하나의 느린 팔로워가 성능에 영향을 미치지 않습니다. (리더는 정족수 이상의 서버에 로그가 복제되면 commit 하기 때문에 !!!)

안정성

앞선 섹션들에서는 Raft가 어떻게 리더를 선출하고, 로그 항목을 복제하는지 설명했습니다. 그러나 지금까지 설명한 메커니즘만으로는 각 상태머신이 정확히 같은 command 들을 같은 순서로 실행한다는 것을 충분히 보장하진 못합니다.

예를들어서, 리더가 여러 로그 항목을 커밋하는 동안 팔로워가 사용 할 수 없게 되었다가, 그 후에 리더로 선출되어 이 항목을 새로운 것들로 덮어 쓸 수도 있습니다.

결과적으로 다른 상태머신들은 다른 시퀀스의 command를 수행하게 됩니다.

이제 부터는 리더로 선출 될 수 있는 서버에 대한 제한을 추가함으로써 Raft 알고리즘을 완성하는 내용을 설명합니다.

주어진 term 의 리더가 이전 term에서 커밋된 모든 항목을 포함하고 있음을 보장해야 한다는 제한을 추가합니다. 이러한 제한을 고려해서 커밋 규칙을 더 정확하게 만들어야 합니다.

선거 제한

리더 기반의 합의 알고리즘에서, 리더는 결국에는 모든 커밋된 로그의 항목을 반드시 저장하고 있어야 합니다. Viewstamped Replication 같은 일부 합의 알고리즘에서는, 모든 커밋된 항목을 갖고있지 않더라도 리더로 선출 될 수 있습니다.

이러한 알고리즘들은 선거 프로세스가 진행중이거나, 리더 선출 바로 직후에 누락된 항목을 파악하고, 새로운 리더에게 전달하는 추가적인 알고리즘을 포함하고 있습니다. 불행히도, 이런것들은 복잡한 알고리즘을 추가합니다.

Raft는 리더에게 커밋되었지만 누락된 항목을 새로운 리더에게 보낼 필요 없이, 이전 임기에서 커밋된 모든 로그 항목이 새로운 선거 시점에서 존재하는 리더만 선출하도록 보장하는 더 쉬운 접근법을 사용합니다.

이건, 로그 항목은 오직 한 방향으로, 리더에서 팔로워로만 흐르는것을 의미하고, 리더는 절대로 자신이 기존에 갖고있던 항목을 덮어쓰지 않는다는것을 의미합니다.

Raft는 모든 커밋된 로그 항목을 갖고있지 않은 후보자가 선거에서 이기는것을 막는 선거 프로세스를 사용합니다. 후보자는 반드시 클러스터 내의 과반수 이상과 통신하여서 뽑힙니다.

그 뜻은 모든 커밋된 항목은 반드시 연락했던 이 서버들중 최소한 하나에는 있다는 것입니다. (추가: 로그의 커밋은 과반수 이상의 클러스터 멤버에게 복제되었을 때 수행됨)

만약 후보자의 로그가 클러스터의 과반수 멤버들 중 어떤 로그보다 최신이라면, 그건 모든 커밋된 항목을 포함했다는 의미입니다. RequestVote RPC는 이러한 제한을 구현합니다.

RequestVote RPC 는 후보의 로그에 대한 정보를 포함하고, 투표자는 자신의 로그가 후보자의 것보다 더 최신이라면 해당 투표 요청을 거절합니다.

Raft는 두 로그 중 어느것이 더 최신인지를 로그의 마지막 항목의 인덱스와 임기를 비교해서 결정합니다. 만약 로그가 서로 다른 임기의 마지막 항목을 갖고있다면, 더 높은 숫자의 임기가 더 최신 로그입니다.

로그가 같은 임기로 끝나면, 더 긴 로그가 더 최신입니다. (같은 임기에 대한 로그가 더 많은쪽이 더 최신 로그까지 갖고 있는것)

이전 임기의 항목들을 커밋

리더는 현재 임기의 항목이 서버 과반수에 저장되면 그 항목이 커밋되었다고 알고 있습니다. 리더가 항목을 커밋하기 전에 크래시가 발생하면, 미래의 리더들은 그 항목의 복제를 완료하려고 시도할 것입니다.

그러나, 리더는 항목이 서버 과반수에 저장되었다고 해서 곧바로 이전 임기의 항목이 커밋되었다고 결론지을 수 없습니다. 앞서 표현한 그림에서는 오래된 로그 항목이 서버 과반수에 저장되었지만, 여전히 미래의 리더에 의해 덮어쓰여질 수 있는 상황을 보여줍니다.

Raft는 이전 임기의 로그 항목을 복제 수를 계산하여 절대 커밋하지 않습니다. 오직 리더의 현재 임기에서 온 로그 항목만이 복제 수를 계산하여 커밋됩니다. 현재 임기에서 온 항목이 이런 식으로 커밋되면, 그 이전의 모든 항목들은 로그 일치 속성 때문에 간접적으로 커밋됩니다.

어떤 상황에서는 리더가 오래된 로그 항목이 커밋되었다고 안전하게 결론지을 수 있습니다(예를 들어, 그 항목이 모든 서버에 저장되어 있는 경우), 그러나 Raft는 단순함을 위해 보다 보수적인 접근 방식을 취합니다.

Raft는 커밋 규칙에서 이 추가적인 복잡성을 감수하는데, 이는 리더가 이전 임기의 항목들을 복제할 때, 로그 항목이 원래의 임기 번호를 유지하기 때문입니다.

Raft의 접근 방식은 로그 항목들이 시간이 지나도 같은 임기 번호를 유지하고 로그 전체에서 유지되기 때문에 로그 항목에 대해 추론하기가 더 쉽습니다.

또한, Raft의 새로운 리더들은 다른 알고리즘보다 이전 임기의 로그 항목들을 더 적게 보냅니다(다른 알고리즘은 커밋하기 전에 재번호를 매기기 위해 중복 로그 항목들을 보내야 합니다).

팔로워와 후보자의 충돌

지금까지는 리더의 실패에 대해서만 설명했는데, 팔로워와 후보자의 충돌은 더 처리하기 간단하고, 둘 다 같은 방식으로 처리 됩니다. 팔로워와 후보가 충돌한다면 그것들에게 보내진 미래의 RequestVote RPC , AppendEntires RPC 모두 실패 할 것입니다.

Raft 는 이러한 실패를 무한히 재시도 함으로써 처리합니다. 크래시한 서버가 재시작 되면 RPC 는 성공적으로 처리 될 것입니다. 예를들어 팔로워가 이미 자신의 로그에 존재하는 로그 항목을 포함하는 AppendEntries RPC 요청을 받는다면, 새 요청에서 그 항목을 무시합니다.

타이밍 그리고 가용성

Raft 의 요구사항중 하나는 타이밍에 의존해서는 안된다는 점입니다. 몇몇 이벤트가 예상보다 빠르거나, 느리게 처리된다고 해서 올바르지 않은 결과를 발생시키면 안됩니다.

어쨌든 가용성은 타이밍에 의존하게 될 수 밖에 없습니다. 예를 들어서, 메시지 교환이 일반적인 서버 크래시 시간보다 길게 걸린다면, 후보자는 선거에 이기기에 충분한 시간동안 유지되지 못 할 것입니다. (안정적인 리더 없이 Raft는 계속해서 진행 될 수 없음)

리더 선출은 Raft 에서 타이밍이 가장 중요한 부분인데. 시스템이 다음 요구사항을 만족하면 안정적인 리더를 선출하고 유지 할 수 있습니다.

broadcastTime << electionTimeout << MTBF

이 부등식에서 broadcastTime 은 서버가 클러스터 내의 모든 서버에게 병렬로 RPC 요청을 보내고, 그들의 응답을 받는데 걸리는 평균 시간입니다. 그리고 MTBF 는 단일 서버에 대한 평균 고장 사이 시간입니다.

만약 RPC 레이턴시 (broadcastTime)을 election timeout 보다 크게 잡는다면 어떻게 될까요?

여기서 broadcastTime 과 MTBF 는 우리가 설정 할 수 있는 속성이 아닌, 시스템이 가진 기본 속성입니다. 우리는 electionTimeout 을 설정 할 수 있습니다.

일반적인 서버에 대한 MTBF(평균 고장 간 시간)은 몇달 이상이고, broadcastTime 은 환경에 따라 다르지만 몇ms 에서 길게는 수십 ms 일 것입니다. (만약 etcd 멤버가 대륙간으로 멀리 떨어져있다면 수백ms 가 넘을 수 있겠지만).

일반적인 상황에서는 electionTimeout 은 아마도 10ms ~ 500ms 사이가 될 가능성이 높습니다. 따라서 이 타이밍 요구사항을 만족하는것은 크게 어려운 일은 아닐 것입니다.

클러스터 멤버쉽 변경 (멤버 추가 / 제거)

지금까지 우리는 클러스터의 configuration (합의 알고리즘에 참여하고있는 서버의 집합)이 고정되어있다고 가정했습니다. 실무에서는, 설정을 변경 할는것이 종종 필요합니다. 예를 들어서 장애가 발생한 서버를 대체하기 위해서나, 합의 알고리즘에 참여하는 서버의 개수를 변경할 때 필요합니다.

이런 작업은 전체 클러스터를 오프라인으로 만들고, configuration(설정)을 업데이트하고, 전체 클러스터를 재시작하는 형태로도 동작 할 수 있겠지만, 이 과정에서 클러스터 전체를 사용 불가능한 시점이 발생하게 됩니다.

게다가 그런 작업에 수동 작업 절차가 있다면, 오퍼레이터(운영자)가 에러를 발생시킬 리스크를 높이게 됩니다. 이러한 문제를을 피하기 위해서, Raft 합의 알고리즘에 자동화된 설정 방식을 포함하기로 했습니다.

클러스터의 설정을 안전하게 변경하기 위해서는, 설정을 변경하는 시점에서 반드시 같은 임기에 두 리더가 선출되는 가능성이 없어야 합니다. 불행하게도, 과거 설정에서 새로운 설정으로 서버가 직접 설정을 바꾸는 접근법에서는 안전한 방법이 없습니다. 모든 서버를 원자적으로 전환 할 수 없기 때문에, 전환중에 클러스터는 두개의 독립적인 과반수로 분리될 수 있습니다.

안정성을 확보하기 위해서는 설정의 변경은 두단계 절차를 통한 접근법을 사용해야 합니다. 예를 들어서, 일부 시스템은 과거 설정을 사용하지 않기 위해 첫번째 절차 들어가고, 그 시스템은 클라이언트의 요청을 처리하지 못합니다. 이후에 두번째 절차에서는 새로운 설정을 활성화시킵니다.

Raft에서 클러스터는 공동 합의라고 부르는 전환 설정으로 전환합니다. 공동 합의가 커밋되면, 시스템은 새로운 설정으로 전환합니다. 공동 합의는 오래된 설정과 새 설정을 모두 결합합니다.

• 로그 항목은 두 설정의 모든 서버에 복제됩니다.
• 어느 설정의 서버든 리더가 될 수 있습니다.
• 합의(리더 선출 및 항목 커밋)는 과거 설정과 새로운 설정 모든 쪽에서 각각 과반수 이상의 합의가 필요합니다.

이러한 공동 합의는 각각의 서버들이 서로 다른 시간에 설정 전환을 할 수 있게 함으로써 안전성을 해치지 않습니다. 게다가, 공동 합의는 이런 설정이 전환되는 과정에서도 클라이언트 요청을 지속적으로 처리 할 수 있게 합니다.

클러스터 구성은 복제된 로그에 특별한 항목을 사용해서 저장되고 통신됩니다. 위 그림은 설정 변경 과정을 나타내는 그림입니다. 리더가 C_old 에서 C_new로 설정을 바꾸라는 요청을 받았을 때, 리더는 공동 합의를 위해 설정을 저장하고(C_old,new) 이 항목들을 복제합니다.

특정 서버가 자신의 로그에 새로운 설정 항목을 추가하면, 향후의 모든 결정에 대해 해당 설정을 사용합니다. (서버는 항상 로그에있는 최신 설정을 사용하고, 설정 정보가 커밋되었는지 여부에 상관없이 사용합니다.) 이는 리더가 C_old,new 규칙을 사용해서 언제 C_old,new 로그 항목이 커밋 될 지를 정한다는것을 의미합니다.

쉽게 정리하자면, 클러스터의 설정(구성) 정보가 변경 될 때, 구성 정보 변경하는 시점에서 일시적으로 분리(C_old,new)되는 클러스터가 독립적으로 각각 결정권을 갖는 시점이 없기 때문에 이 시점에서의 분리된(C_old,new) 클러스터간 데이터가 불일치하는 문제같은건 발생하지 않는다는 의미입니다.

로그 압축(Compaction)

Raft의 로그는 클라이언트의 요청이 포함된 정상적인 운영 상황에서 계속해서 늘어나게 됩니다.

하지만 실제 시스템에서는 경계(한계)없이 늘어날 수 없습니다. 로그가 더 길어지면 길어질수록, 더 많은 공간을 차지하게 되고, 응답을 하기위해 더 많은 시간을 사용하게 됩니다.

쓸모없는 정보가 로그에 계속 누적되었다는것을 인지하기 위한 메커니즘이 따로 없다면 결국 가용성 문제가 발생하게 됩니다.

Snapshotting(스냅샷)은 압축을 위한 가장 쉬운 방법입니다. 스냅샷을 찍게되면 현재의 모든 시스템의 상태가 안정적인 저장공간에 스냅샷 형태로 저장되고, 스냅샷을 찍는 시점 이전의 로그를 버립니다.

위 그림은 Raft 에서 스냅샷 생성의 기본 개념을 보여줍니다. 각 서버는 로그에 커밋된 항목들만 포함하여 독립적으로 스냅샷을 생성합니다. Raft 는 스냅샷에 소량의 메타데이터도 포함하는데, 스냅샷이 대체하는 로그의 마지막 항목의 인덱스, 그 항목의 임기(마지막 임기)를 포함합니다.

이 정보는 스냅샷 다음에 오는 첫번째 로그 항목에 대한 AppendEntries RPC의 일관성 검사를 지원하기 위해 보존되는 것입니다. 클러스터 멤버십 변경또한 지원하기 위해 마지막 서버 구성도 포함합니다. 스냅샷을 만들고 나면 그 이전 항목들을 삭제 할 수 있습니다.

리더는 InstallSnapshot RPC를 너무 멀리 뒤떨어진 팔로워들에게 스냅샷을 보내기 위해 요청합니다. 팔로워가 이 RPC 를 수신했을 때, 기존 로그 항목들을 어떻게 처리할지 결정해야 합니다. 보통은 팔로워가 갖고있는 로그 항목에 대한 정보보다 스냅샷에 있는 정보가 더 최신 정보입니다.

이런 케이스에서는 팔로워는 자신의 기존 로드 항목을 모두 버립니다. 만약 팔로워가 자신의 로그 항목의 앞부분을 설명하는 스냅샷을 받게 된다면 (재전송, 혹은 실수로 인해), 스냅샷으로 커버되는 앞선 로그항목은 삭제되더라도, 그 이후에 따르는 항목은 여전히 보존되어야 합니다.

이 스냅샷 접근 방식은 팔로워가 리더에 대한 정보 없이 스냅샷을 생성 할 수 있기 때문에 Raft 의 강한 리더 원칙을 벗어납니다.

하지만, 이러한 부분은 정당화가 된다고 생각합니다. 리더를 두는것은 합의에 도달할 때에 충돌하는 결정을 피하는데에 도움은 되지만, 스냅샷을 찍는 시점에서는 이미 합의가 된 상태기 때문에 어떤 결정도 충돌되지 않습니다. 데이터는 여전히 리더에서 팔로워로 한 방향으로만 흐릅니다.

Wrapping up

이렇게해서 Raft 알고리즘이 어떻게 동작하는지 논문을 기반으로 알아보았습니다.

이해하기 쉬우면서도(?) 잘 동작하는 합의 알고리즘을 구현하기 위해 어떤 요소들이 필요하고 일부 머신에 장애가 발생했을 때 어떻게 장애를 극복하는지 알아 볼 수 있었습니다.

Raft Consensus Algorithm

Raft is a consensus algorithm that is designed to be easy to understand.

위 사이트의 맨 아래쪽 부분에는 어떤 소프트웨어들이 Raft 알고리즘을 "구현" 하여 사용중인지 확인 가능합니다.

Maintenance

Periodic etcd cluster maintenance guide

.cls-1{fill:#419eda}etcdTerms

etcd 에서는 compaction 을 진행하기 이전에, 인메모리에 보관할 Raft 항목의 수를 --snapshot-count 라는 인자로 지정 할 수 있습니다. 로그 항목의 수가 snapshot-count 에 도달하면, 서버는 스냅샷 데이터를 디스크에 저장한 다음, 오래된 항목을 잘라내는 작업을 합니다. 또한 느린 팔로워(랙)가 압축된 이전의 로그를 요청하면 리더는 팔로워가 상태를 덮어쓰도록 스냅샷을 보내게 됩니다.

이 스냅샷은 인메모리에 저장할 로그 항목의 수를 지정하는것으로, 이 값이 크면 클수록 더 많은 로그 항목을 인메모리에 저장하기때문에, 메모리 사용량이 반복적으로 증가하게됩니다.

따라서 snapshot-count 는 메모리 사용량의 증가와, 느린 팔로워의 가용성 사이에서 절충안을 찾아 설정해야 합니다.v3.2 이후부터는 기본 값이 100,000 으로 변경되었습니다. (인메모리에 100,000 개의 로그 항목을 저장하도록)

여기서 DefaultSnapshotCatchupEntries 라는 값이 5000 으로 하드코딩 되어있습니다.

const (
	DefaultSnapshotCount = 10000
	// DefaultSnapshotCatchUpEntries is the number of entries for a slow follower
	// to catch-up after compacting the raft storage entries.
	// We expect the follower has a millisecond level latency with the leader.
	// The max throughput is around 10K. Keep a 5K entries is enough for helping
	// follower to catch up.
	DefaultSnapshotCatchUpEntries uint64 = 5000
	...
	)

(https://github.com/etcd-io/etcd/blob/e513b1a6b759a75d077f2d52f1429035697ceb52/server/etcdserver/server.go#L75-L83)

이 값은, Raft 스토리지의 항목을 압축 한 이후에, 느린 팔로워가 따라잡을 수 있는 항목의 개수를 의미하는데. 스냅샷을 찍은 이후에 인메모리에 우선 5000개의 항목만을 메모리에 들고있고, 만약 느린 팔로워가 5천개 이상 Lag을 갖고있다면 리더가 스냅샷을 보내서 따라오도록 하는 설정이라고 볼 수 있습니다.

// etcd/server/storage/storage.go
// SaveSnap saves the snapshot file to disk and writes the WAL snapshot entry.
func (st *storage) SaveSnap(snap raftpb.Snapshot) error {
	st.mux.RLock()
	defer st.mux.RUnlock()
	walsnap := walpb.Snapshot{
		Index:     snap.Metadata.Index,
		Term:      snap.Metadata.Term,
		ConfState: &snap.Metadata.ConfState,
	}
	// save the snapshot file before writing the snapshot to the wal.
	// This makes it possible for the snapshot file to become orphaned, but prevents
	// a WAL snapshot entry from having no corresponding snapshot file.
	err := st.s.SaveSnap(snap)
	if err != nil {
		return err
	}
	// gofail: var raftBeforeWALSaveSnaphot struct{}
	return st.w.SaveSnapshot(walsnap)
}

(https://github.com/etcd-io/etcd/blob/e513b1a6b759a75d077f2d52f1429035697ceb52/server/storage/storage.go#L58-L77)

// etcd/server/storage/wal/wal.go
func (w *WAL) SaveSnapshot(e walpb.Snapshot) error {
	if err := walpb.ValidateSnapshotForWrite(&e); err != nil {
		return err
	}
	b := pbutil.MustMarshal(&e)
	w.mu.Lock()
	defer w.mu.Unlock()
	rec := &walpb.Record{Type: SnapshotType, Data: b}
	if err := w.encoder.encode(rec); err != nil {
		return err
	}
	// update enti only when snapshot is ahead of last index
	if w.enti < e.Index {
		w.enti = e.Index
	}
	return w.sync()
}

(https://github.com/etcd-io/etcd/blob/e513b1a6b759a75d077f2d52f1429035697ceb52/server/storage/wal/wal.go#L964-L983)

이 시점에서 etcd 는 두가지의 동작을 하게 됩니다. (위 코드를 보면 알겠지만)

1. 현재의 메타 데이터를 .snap 파일로 저장
2. 1번 데이터를 포함한 현재 상태(state)를 wal 파일에 저장 

따라서 .snap 파일은 데이터베이스가 얼마나 크건, 얼마나 많이 만들었건에 관련 없이 일정한 크기를 갖게 됩니다.

그리고 메모리에서 제거한 데이터(스냅샷)는 wal 파일에 저장합니다.

따라서 느린 팔로워가 compact-index - snapshot-index 사이에 last-applied-index 를 갖고있는 경우에는 스냅샷을 받아서 리더를 따라가는게 아니라, 리더와 AppendEntries RPC 를 주고 받으면서 따라가고, 그렇지 않은 경우에는 스냅샷을 받아서 처리하게 됩니다. 그리고 snapshot-index - compact-index 의 값의 차이는 5000으로 고정되어있다고 생각하면 됩니다.

WAL 에 저장되는 데이터들 (Write Ahead Log)

앞서서, Raft Snapshot 도 궁극적으로 WAL 에 저장된다고 했습니다. 여기서는 WAL 에 어떤 데이터들이 어떤 형식으로 저장되는지 설명합니다.

물리적 요소

WAL 로그 파일은 프레임 의 연속적인 내용을 저장하는데, 각 프레임은 아래를 포함하고있습니다.

• LittleEndian : 인코딩된 uint64 형태의 마샬링된(직렬화와 비슷한 개념이라고 생각하면 됩니다) walpb.Record 의 길이
• Padding : 전체 프레임이 정렬된 크기가 되도록 하는 0 바이트의 패딩
• 마샬링된 walpb.Record 의 데이터

이 파일은 64*10^6 바이트(64MB) 마다 잘라집니다.

논리적인 요소

WAL 로그 파일은 아래와 같은 논리적 계층의 내용을 포함합니다.

• Raftpb.Entry : Raft 의 리더에 의해 복제된 제안(로그 항목 추가하라는 제안). 일부 제안은 커밋된것으로 간주됩니다.
• Raftpb.HardState(term,commit,vote) : 커밋되어(과반수 이상에 복제되어서 커밋된) 변경/재정의 되지 않도록 보장되고, 백엔드에 적용 될 수 있는 로그 항목의 index 에 대한 정보, term 정보, 투표 정보
• walpb.Snapshot(term, index) : Raft 상태에 대한 주기적인 스냅샷 (DB 내용은 하나도 없고, 스냅샷 로그 인덱스와 Raft 임기 정보만 있습니다.) etcd v3 store 의 경우 데이터는 bbolt 파일에 유지되고, Snapshot 에 임기/인덱스 정보가 반영되면 암시적인 스냅샷이 됩니다. (데이터에 대한 스냅샷 파일을 따로 만드는게 아님)
• crc32 체크섬
• etcdserverpb.Metadata(node_id, cluster_id) : 로그가 나타내는 클러스터 및 복제를 표현 

각각의 WAL-log 파일은 아래 순서대로 빌드됩니다.

1. CRC-32 프레임
2. 메타데이터 프레임(클러스터, 복제본 IDs)
3. 최초의 WAL 파일인 경우
   1. 빈 Snapshot 프레임 (인덱스, 임기 모두 0 인)
4. 최초가 아닌 WAL 파일
   1. Hardstate 프레임 (임기, 커밋, 투표 정보)
5. 항목, hard-state, snapshot record 의 조합

WAL 로그의 인덱스는 아래와 같이 생성, 유지됩니다.

1. snapshot 의 인덱스로부터 시작
2. 같은 임기(term)에 있는 경우 해당 스냅샷 이후로 순차적으로 증가
3. 임기가 변경되면 인덱스가 감소 할 수 있지만, 최신 Hardstate.commit 보다 높은 새로운 값으로 변경 가능
4. 새 스냅샷은 반드시 index >= Hardstate.commit 에서 발생해야 하며, 인덱스에 대한 새로운 시퀀스를 생성

정리

WAL 파일은 Write Ahead Log 의 약자로, B-Tree 에서의 보통 쓰기 전 임시로 저장하여 쓰기 실패시 복구하기 위한 용도로 사용되는데, etcd 는 한 단계 더 확장해서, Raft 로 부터 제안된 로그 항목 임시 저장 + Snapshot 정보 저장, 기타 메타데이터 저장(임기, 커밋, 인덱스) 용도로 사용되는 파일입니다.

etcd 의 --snapshot-count 도달시 생기는 000000-000000.snap 형태의 스냅 파일은 일종의 메타데이터를 저장하고 있는 파일이고, 실제로는 WAL에도 저장되며, 이 시점에서의 DB 에 대한 스냅샷 파일을 명시적으로 만드는것이 아닌(만들어서 Disk 에 별도로 저장하는게 아니라) 암시적으로 스냅샷 시점의 임기, 인덱스 값을 기반으로 스냅샷을 논리적으로 갖고있는 것이라고 볼 수 있습니다.

실제로 스냅샷이 필요한 시점 (느린 팔로워의 동기화를 위해서)에서는 암시적인 스냅샷을 실제 물리적인 파일 형태로 만들어서 (*.snap.db) 팔로워에게 파일을 전달하고 동기화 된 이후에는 삭제하게 됩니다.

쿠버네티스 고가용성 토폴리지 (etcd)

고가용성 토폴로지 선택

이 페이지는 고가용성(HA) 쿠버네티스 클러스터의 토플로지를 구성하는 두 가지 선택 사항을 설명한다. 다음과 같이 HA 클러스터를 구성할 수 있다. etcd 노드와 컨트롤 플레인 노드를 함께 위치시키는 중첩된(stacked) 컨트롤 플레인 노드 방식 etcd와 컨트롤 플레인이 분리된 노드에서 운영되는 외부 etcd 노드 방식 HA 클러스터를 구성하기 전에 각 토플로지의 장단점을 주의 깊게 고려해야 한다. 참고: kubeadm은 etcd 클러스터를 정적으로 부트스트랩한다. 자세한 내용은 etcd 클러스터 구성 가이드 를 읽는다. 중첩된 etcd 토플로지 중첩된 HA 클러스터는 etcd에서 제공하는 분산 데이터 저장소 클러스터를, 컨트롤 플레인 구성 요소를 실행하는 kubeadm으로 관리되는 노드에 의해서 형성된 클러스터 상단에 중첩하는 토플로지이다.

Kubernetes

위 문서는 쿠버네티스 공식 문서에서 고가용성이 확보된 쿠버네티스 클러스터를 구축하는 두가지 토폴로지에 대해서 서술하고 있습니다. 위 문서에서의 초점은 etcd 이며. etcd 를 컨트롤 플레인 노드(머신)과 중첩시켜서 구축할지, 아니면 외부 다른 노드(머신)에 구축할지에 대한 내용입니다.

이 문서는 etcd 를 초점으로 한 문서는 아니지만 간략하게 요약하자면.

Stacked etcd 토폴로지

Stacked etcd 토폴로지의 경우 컨트롤 플레인 노드(머신)에 etcd 를 같이 설치하는 형태로.

kube-apiserver 와 etcd 간에 Network I/O 가 없다는 장점이 있지만. RAFT 알고리즘을 사용하는 etcd 의 특성, 그리고 그 etcd 를 컨트롤 플레인 노드에 같이 설치한다는 구성상의 특징으로 컨트롤 플레인 노드의 개수는 etcd 클러스터 멤버의 개수와 동일하며. 그에 따라서 고가용성 유지를 위한 Quorum 개수를 맞추려고 할 때 컨트롤 플레인 노드의 개수도 etcd 와 동일하게 맞춰줘야 한다는 단점이 있을 수 있습니다.

etcd 클러스터는 etcd 멤버를 3대 이상 유지했을 때 1개의 etcd 멤버가 다운되더라도 정상 동작이 가능하고, 5대로 구성하는경우 최대 2개의 멤버가 다운되더라도 정상 동작이 가능합니다.

참조 : https://etcd.io/docs/v3.5/faq/#what-is-failure-tolerance

따라서 고가용성을 유지하기 위해 etcd 를 5개를 설치하기로 선택 했을 때, 컨트롤 플레인의 개수 자체도 5개가 되어야 한다는것이 단점이 될 수 있습니다.

External etcd 토폴로지

External etcd 토폴로지의 경우 컨트롤 플레인 노드와 별도로 etcd 를 설치해서 사용하는 형태로. kube-apiserver 와 etcd 가 물리적으로 다른 머신에 설치되어있는 경우 Network I/O 를 염두해서 사용해야 합니다. 다만 이 케이스에서는 컨트롤 플레인의 개수는 etcd 의 개수와 전혀 상관없이 구성이 가능하다는 점이 장점입니다.

컨트롤 플레인 노드는 2대, etcd 멤버는 5개로 설치하거나, 컨트롤 플레인은 3대 , etcd 멤버는 3개 등으로도 설치 가능합니다. 이렇게 컨트롤 플레인의 개수와 etcd 개수간의 디펜던시가 없는것이 장점이 될 수 있습니다. 다만 etcd 멤버 수 만큼 추가적인 노드(머신)이 필요 한 것이 단점이 될 수 있습니다.

kube-apiserver 앞단의 로드밸런서 (software LB)

앞서서 HA 쿠버네티스를 구성하는 두가지 토폴로지를 보면서 확인 가능했겠지만. 워커노드들이 kube-apiserver 에 접근 할 때 로드밸런서를 통해 접근하는것은 동일하다는 것을 볼 수 있었습니다.

kubeadm 을 통해 HA 쿠버네티스 클러스터를 구성하는 아래와 같은 문서에서도 kube-apsierver 용 로드밸런서를 생성하라는 이야기가 나와있습니다.

Creating Highly Available Clusters with kubeadm

또한 위 문서에서 소프트웨어를 통한 부하 분산에 대한 내용이 아래와 같이 링크 되어있는데요.

https://github.com/kubernetes/kubeadm/blob/main/docs/ha-considerations.md#options-for-software-load-balancing

위 문서에서는 VIP(Virtual IP)를 통해 로드밸런싱을 제공하는 keepalived + haproxy 조합이 오래동안 사용되어왔고, 충분한 테스트를 거친 조합이라고 설명하고있습니다.

위 그림에서의 IP 주소는 이해를 돕기위해 임의로 설정한 주소입니다.

아래쪽의 각 컨트롤 플레인 노드는 각각 192.168.100.2 , 192.168.100.3 , 192.168.100.4 주소를 갖고 있다고 할 때. kube-apiserver 는 각 컨트롤 플레인 노드에서 6443(기본적으로 설정되는 포트이며 변경될 수 있음) 포트로 listen 하고 있는 상태일 것입니다.

이러한 kube-apiserver 들에 부하를 분산해서, 그리고 문제가 생겼을때 문제가 없는 서버로 트래픽을 틀어주기 위해서 HAProxy 를 통해 각 kube-apiserver 에 round-robin 형태로 트래픽을 틀어주도록 설정하고. 이 때 각 HAProxy 는 192.168.100.10 , 192.168.100.20 주소를 갖고 있다고 가정합니다.

이때 각 LB(HAProxy) 간의 HA 구성을 위해 Keepalived 를 두고. VIP 를 192.168.100.100 으로 두고. 설정을 통해 한쪽 LB를 마스터, 한쪽 LB 를 백업으로 두는 Active-Standby 조합으로 구성하면

클라이언트나 워커노드는 192.168.100.100:6443 혹은 도메인을 192.168.100.100 에 연결했다고 하고, 그 도메인이 foo.bar.com 이라고 하면 https://foo.bar.com:6443 으로 요청을 보낼 수 있습니다.

그렇게 요청을 보내면 Keepalived 를 통해 한쪽 LB 로 요청이 넘어가고. 해당 LB 는 round-robin 형태로 세 컨트롤 플레인 노드의 kube-apiserver 중 하나로 트래픽을 틀어주게 됩니다.

이것이 일반적인 Keepalived + HAProxy 조합의 HA 쿠버네티스 클러스터 구성입니다.

이렇게 하게 되면 kube-apiserver , LB(HAProxy) 중 하나가 장애가 생기더라도 정상적인 kube-apiserver, LB 로 트래픽을 틀어 줄 수 있기 때문에 고가용성이 확보되는 것입니다.

물론 뒷단의 Control Plane Node 를 Stacked etcd 토폴로지 로 했냐, External etcd 토폴로지 로 했냐에 따라서 고가용성 확보 여부가 달라질 수 있고. Keepalived 에 장애가 생겼냐에 따라서도 고가용성 확보 여부가 달라 질 수는 있습니다. 여기서는 단편적인 케이스에 대해서만 설명하였습니다.

위 구성에서 VIP(Virtual IP) 그리고 Keepalived 를 사용해서 LB(HAProxy) 에 대한 고가용성을 확보했기 때문에 두 LB(HAProxy) 중 하나는 유휴상태(Standby) 상태로 남아있게 되는 것 단점으로 남습니다.

위 부분을 해결하기 위해서는 별도의 Keepalived 를 하나 더 추가하고. 2개의 VIP(Virtual IP) 를 구성하고. Round Robin DNS , 그리고 Health Check 까지 겸해서 사용하거나, 두개의 LB 에 대해서 Round Robin DNS 그리고 Health Check 를 겸해서 사용하는 등의 추가적인 방법을 사용해야 할 것입니다.

Round-Robin DNS 로 해보자!

Round-robin DNS 는 DNS 요청에 대한 IP 주소들의 응답을 여러 주소를 반환하고 그와 더불어서 첫번째 레코드를 순회(round-robin)하면서 DNS 응답을 하는 방법입니다.

일반적인 상황에서 S/W , H/W LB 를 두지 않고 가장 간단하게 부하 분산을 할 수 있는 방법에 그 이점이 있습니다. 다만 고려해야할 아래와 같은 단점이 있습니다.

1. DNS 쿼리 정보를 캐싱하는 주체가 다양하다. (OS, 애플리케이션, 기타 클라이언트 등등)
2. DNS 쿼리 캐싱 문제로 인해 문제가 발생했을 때 바로 반영이 되지 않을 수 있다. 기존 쿼리해서 받은 IP 주소로 계속해서 애플리케이션/클라이언트 등이 호출을 하려 할 것이다.
3. DNS 서버에 Health Check 기능이 존재하지 않으면 비정상적인 IP 주소를 계속 담아서 보내줄 수도 있다.

우선 1, 2번 문제를 제외하고 3번 부분을 처리하기 위해서 AWS Route53 의 다중 응답 기능 + 상태 검사 기능을 사용해서 테스트를 해보기로 하였습니다.

테스트 환경

테스트를 하고자 하는 환경 구성은 아래와 같습니다.

2개의 Control Plane Node (172.xx.xx.31 , 172.xx.xx.32) 와 1개의 Worker Node (172.xx.xx.33) 이 존재하고. 이 노드들은 모두 사설 대역대에 존재합니다. 이 사설망과 연결된 게이트웨이는 xx.xx.xx.xx 라는 공인 ip 주소를 갖고 있고 Route53 의 헬스체크 요청이 도달할 수 있도록 포트포워딩을 아래와 같이 하였습니다.

xx.xx.xx.xx:16443 → 172.xx.xx.31:6443 (kube-apiserver)

xx.xx.xx.xx:26443 → 172.xx.xx.32:6443 (kube-apiserver)

xx.xx.xx.xx 를 public_ip 라고 지칭하겠습니다.

Route53 설정

위와 같이 public_ip:16443 , public_ip:26443 에 대해서 상태검사를 생성합니다.

이후 A Record 에 위와 같이 다중값 응답 및 상태확인을 연결하여 생성합니다.

172.xx.xx.31:6443 , 172.xx.xx.32:6443 으로 떠있는 각 kube-apiserver 가 정상 상태라면 두 상태 검사도 정상이고, 이에 따라서 DNS 쿼리시 두 IP 주소를 번갈아가면서 응답해주게 됩니다.

DNS 테스트

kube-apiserver 는 static pod 로 띄워져있기때문에 ,한번 172.xx.xx.31 쪽에 있는 kube-apiserver 를 제거해보고 DNS 응답이 어떻게 나오는지 확인해봅니다.

$ mv /etc/kubernetes/manifests/kube-apiserver.yaml /root/kube-apiserver.yaml

위와 같이 kube-apiserver.yaml 을 잠시 /etc/kubernetes/manifests 경로에서 빼내줍니다.

cat /etc/kubernetes/kubelet-config.yaml | grep staticPodPath
staticPodPath: /etc/kubernetes/manifests

잠시 기다리면 kubelet 이 kube-apiserver.yaml 파일이 제거됨을 인지하고, kube-apsierver static pod 를 제거합니다. 위 사진처럼 node1 (172.xx.xx.31) 에는 kube-apiserver 가 제거되었습니다.

이렇게 상태 검사 + Rotue53 다중 응답(Round Robin DNS)을 동작하도록 했다. 172.xx.xx.31 에서 잠깐 제거한 kube-apiserver.yaml 을 다시 아래 명령어를 통해 정상화 한다.

$ mv /root/kube-apiserver.yaml /etc/kubernetes/manifests/

 kube-apiserver 인증서 재발급

이제 kube.xxx.com 과 같은 도메인으로(host header) kube-apiserver를 요청하더라도 처리가 되도록 기존에 프로비저닝 된 kube-apiserver 인증서를 재발급 해줘야한다.

172.xx.xx.31 서버에서 아래와 같이 kube-apiserver 가 사용하는 기존 인증서를 확인해보자.

$ openssl x509 -text -noout -in /etc/kubernetes/ssl/apiserver.crt

kubeadm 을 통해 다시 인증서를 발급하기 위해서 우선 /etc/kubernetes/kubeadm-config.yaml 파일의 certSANs 항목에 도메인을 추가해야 한다.

$ vi /etc/kubernetes/kubeadm-config.yaml

위는 kubeadm-config.yaml 파일의 certSANS 항목의 일부이다. 해당 부분의 아무 라인에서 kube.xxx.com 과 같은 도메인을 추가해줘야 한다.

이후 기존 kube-apiserver 인증서, 키파일을 제거한다.

$ rm -rf /etc/kubernetes/ssl/{apiserver.crt,apiserver.key}

이후 kubeadm 을 통해 kube-apiserver 인증서를 업데이트된 kubeadm-config.yaml 파일 기반으로 재생성한다.

$ /usr/local/bin/kubeadm init phase certs apiserver --config=/etc/kubernetes/kubeadm-config.yaml

위 명령어를 수행하면 apiserver.crt , apiserver.key 가 새롭게 /etc/kubernetes/ssl 디렉터리에 생성된다.

이후 제대로 생성이 되었는지 $ openssl x509 -text -noout -in /etc/kubernetes/ssl/apiserver.crt 명령어를 통해 확인한다.

이후 172.xx.xx.31 에서 생성된 인증서를 다른 모든 컨트롤플레인(현재 테스트 환경에서는 172.xx.xx.32)에도 반영해준다. (기존 인증서 제거 및 172.xx.xx.31 에서 생성한 인증서 복사)

워커노드에서의 kubelet 설정

이제 172.xx.xx.33 (워커노드) 에서 본격적인 테스트를 진행해보자.

워커노드에서 $ vi /etc/kubernetes/kubelet.conf 을 통해 kubelet 이 사용할 kubeconfig 파일을 열어봅니다.

위와 같이 server 항목에 도메인(kube.xxx.com:6443) 을 입력해줍니다.

이로써 워커노드의kubelet 은 kube.xxx.com 도메인 네임을 resolve 하기 위해 DNS Query를 하게 되고. 그 응답으로 돌아오는 IP 주소를 통해 kube-apiserver 에 호출하게됩니다.

kubelet 의 동작을 자세하게 확인하기 위해서 kubelet 의 로그레벨을 잠시 올려봅니다. kubelet 은 systemd 서비스로 설치되었고. 로그는 journald 에 기록되기때문에 로그를 확인하기 위해서는

$ journalctl -xeu kubelet -f 형태로 확인 가능합니다.

로그 레벨 변경은 $ vi /etc/kubernetes/kubelet.env 을 통해 kubelet.env 파일을 수정해야합니다.

기본적으로 위와 같이 KUBE_LOG_LEVEL 은 --v=2 로 되어있습니다. 이것을 잠시 9로 올려봅니다.

위 환경변수를 반영하기 위해서 $ systemctl restart kubelet 으로 kubelet 을 재실행합니다.

워커노드에서의 테스트

현재 환경에서는 2개의 kube-apiserver 가 있는데. 두 kube-apiserver 를 죽여봅니다. 각각의 컨트롤 플레인에서

$ mv /etc/kubernetes/manifests/kube-apiserver.yaml /root/kube-apiserver.yaml 를 통해 kube-apiserver static pod 를 제거해봅니다.

위와 같은 상황일때. Route53 은 kube.xxx.com 에 대한 DNS 쿼리 응답으로. kube.xxx.com 에 등록한 모든 A Record 를 반환합니다.

현재 172.xx.xx.31 , 172.xx.xx.32 두 컨트롤 플레인 노드에 떠있는 kube-apiserver 가 모두 없는 상황입니다.

이 때 워커노드의 kubelet 은 어떤지 로그를 살펴보면 ($ journalctl -xeu kubelet -f)

노란색 박스 친 부분을 보면 round_trippers 코드 부분에서 DNS Loookup 을 진행해서 두개의 IP 주소를 받아오고. 이후 앞쪽에 있는 IP 주소에 먼저 TCP 커넥션 맺기를 시도해보고, 이후 다른 IP 주소로도 TCP 커넥션을 맺어보려고 한다. 이 round_trippers 는 DNS 쿼리 결과에 따른 IP 주소들에 대해서 성공하는 IP 주소로 DNS Query 결과를 kubelet 이 캐싱해서 해당 IP 주소로 계속해서 요청하기 위한 로직입니다.

https://github.com/kubernetes/client-go/blob/7ebe0ea60e0a6bea3e8280871c1241d0405cdb32/transport/round_trippers.go#L459-L586

실제 kubernetes 컴포넌트들의 클라이언트 모듈인 client-go 레포 내의 round_trippers 코드를 보면 도메인을 DNS Query 하고, IP 주소로 커넥션을 맺어보려고 시도하는 로직들이 들어있습니다.  

여기서 172.xx.xx.31 서버의 kube-apiserver 를 복구하고 kubelet 로그를 다시 확인해보겠습니다.

172.xx.xx.31 에 떠있는 kube-apiserver 로의 TCP 커넥션 맺기가 성공했다는 로그를 확인 할 수 있습니다. 이러한 로그가 생긴 시점 이후로는 kube.xxx.com 도메인으로 kube-apiserver 접근 요청을 하더라도 클라이언트 내부적으로 172.xx.xx.31 로 계속해서 요청을 보내게 됩니다.

추가적으로172.xx.xx.32 의 kube-apiserver 를 복구하더라도 더이상 DNS Query 를 하지 않고 계속해서 기존에 정상적으로 호출했던 172.xx.xx.31 쪽으로 요청을 하는것도 확인 할 수 있었습니다.

그럼 잘 동작하는거 아닌가요? kube-apiserver 앞단에 로드밸런서 이제 걷어내도 되나요?

위 테스트를 간단하게 했을때는 kube-apiserver의 일부가 장애가 발생했더라도, 정상적인 kube-apiserver 로 쿠버네티스 컴포넌트들(kubelet 포함한 kube-scheduler, kube-controller-manager 등)이 Round Robin DNS 를 통해서 정상적으로 동작하는 것 처럼 보입니다.

여기서 중요한 점은, kubelet 을 포함한 쿠버네티스 컴포넌트들은 아까 kubelet 이 사용했던 kubernetes/client-go 를 사용하는데. 이 클라이언트 코드는 DNS 쿼리를 하고, 반환된 IP 주소에 TCP 커넥션을 맺어보고 성공한 IP:Port 조합으로 계속해서 요청을 보내는 코드입니다.

따라서 172.xx.xx.31 , 172.xx.xx.32 에 존재하는 두개의 kube-apiserver 가 모두 장애가 발생했다가, 한쪽이 복구되었을 때, 복구된 한 쪽으로 kubelet 같은 쿠버네티스 컴포넌트들, 그리고 클라이언트들이 잘 호출 할 수 있겠지만, 클라이언트 코드쪽의 DNS 캐싱정책으로 인해서, 장애가 있었던 나머지 한쪽이 복구가 되더라도 트래픽이 Load Balancing 되는 것이 아니라, 여전히 한쪽으로만 흘러가게 되는 현상을 겪을 수 밖에 없습니다.

이는 Round Robin DNS 자체의 문제점으로, 불특정 다수의 다양한, 수많은 클라이언트가 동일 도메인으로 접속하는 경우에 대해서는 어느정도의 Load Balancing 이 가능하지만. 소수의 일부 클라이언트가 지속해서 접속해야하는 케이스에서는 적절한 Load Balancing 을 기대하긴 어렵습니다.

Wrapping up

Round Robin DNS 를 통해 kube-apiserver 앞단의 로드밸런서를 대체 할 수 있는지 테스트해보았는데 결론적으로는 반은 되고 반은 안되는 구성이라고 볼 수 있습니다.

kube-apiserver 의 앞단 LB 를 대체 할 수 있는 부분은 일부 kube-apiserver 장애시 장애에 대한 복구(fail over)는 어느정도 가능하지만 대체 할 수 없는 부분이 일부 존재해 정말 진정한 Load Balancing 을 수행하기는 어렵다는 부분이 있습니다.

일반적인 LB의 경우 들어온 요청을 자신이 관리하는 뒷단의 백엔드 서버들로 로드밸런싱 정책에 맞춰 부하를 분산해줍니다.

하지만 지금과 같은 설정 케이스(RR-DNS)는 별도의 서버가 트래픽을 중계(proxy)해서 처리하는 형태가 아닌. 각각의 클라이언트들이 Domain 에 대한 IP 주소를 Resolve하고. 그 IP 주소가 여러대의 백엔드 서버(머신)주소 일 때 진정한 부하 분산이 되는 케이스라고 볼 수 있습니다.

여기서 클라이언트의 DNS Query 캐싱 동작으로 인해, 여러 클라이언트들이 여러 IP주소의 백엔드로 호출하고 있다가, 장애가 발생해서 일부 백엔드로 호출하고, 다시 모든 백엔드 서버가 정상이 되어서 여러 IP 주소의 백엔드로 호출하는 (부하분산) 형태가 아닌점이 문제가 됩니다.

대부분의 클라이언트들은 한번 DNS Query 를 하고 정상 동작중이라면 계속해서 동일한 IP주소의 백엔드에 요청을 보낸다는 점이 문제가 됩니다. 따라서 장애 발생 후 복구가 되었더라도, 장애 발생시 정상적으로 처리했던 백엔드에만 클라이언트가 요청을 하게 되는것입니다.

이렇게 되면 일부 서버에만 부하가 몰리게 됩니다.

물론 kubelet 같은 것들을 임의로 재시작해서(kubelet 프로세스의 재시작에 의미가 있는 건 아니고 DNS 캐싱을 초기화 하는 부분에 의미가 있음) Round Robin DNS 를 통해 어느정도의 강제적인 로드밸런싱을 수행 할 수도 있겠지만 그렇게 하는것이 과연 H/W, S/W LB 를 kube-apiserver 앞단에 두는것보다 얼마나 더 장점이 있을지를 고려해보고, 사용 자체는 해볼 수 있을 것으로 판단은 됩니다.

오퍼레이터 디자인 패턴

오퍼레이터는 Introducing Operators: Putting Operational Knowledge into Software CoreOS 블로그에서 공개된 디자인 패턴으로 운영자의 역할을 소프트웨어에 새긴 개념입니다. SRE / DevOps 엔지니어는 애플리케이션을 운영하는 엔지니어로서 운영 노하우, 도메인 지식등이 수반되어야 소프트웨어 개발/운영이 가능한데. 이러한 애플리케이션 운용에 있어서 가용성이 유지되도록 할 때 엔지니어가 수동으로 작업하는 부분이 꽤나 있습니다.

https://github.com/cncf/tag-app-delivery/blob/eece8f7307f2970f46f100f51932db106db46968/operator-wg/whitepaper/Operator-WhitePaper_v1-0.md

CNCF에서 소개한 위 자료에서는 상태를 수동적으로 관리해주어야 하는 한계를 극복하기 위해 고안된 오퍼레이터 패턴의 역할과 기능에 대해 자세하게 설명되어있습니다.

이 오퍼레이터 패턴은 세 가지의 구성요소로 구성되는데

• 관리하려는 애플리케이션 또는 인프라
• 사용자가 선언적 방식으로 애플리케이션의 원하는 상태로 지정할 수 있게 해주는 도메인 특화 언어
• 지속적으로 실행되는 컨트롤러
  • 상태를 읽고 인식
  • 자동화된 방식으로 애플리케이션에 대한 작업을 실행
  • 선언적 방식으로 애플리케이션의 상태를 보고

쿠버네티스의 오퍼레이터 구성요소

• 쿠버네티스 컨트롤러
• Custom Resource / Custom Resource Definition
• 컨트롤 루프

컨트롤러는 하나 이상의 여러 오브젝트를 감시 할 수 있으며, 이 객체는 Deployment, Service 같은 쿠버네티스의 기본 요소일 수도 있고, 가상머신, 데이터베이스와 같은 클러스터 외부에 있는 객체일수도 있습니다. 컨트롤러는 감시중인 객체가 정의된 방식으로 원하는 상태(Desired State)로 전환되도록 보장하는 컨트롤 루프를 사용해서 원하는 상태를 현재 상태와 지속적으로 비교합니다. Desired state는 하나 이상의 Kubernetes Custom Resource Definition에 캡슐화 되고, 컨트롤러에는 객체를 Desired state로 만드는 운영 지식이 포함되어있습니다.

쿠버네티스 컨트롤러

쿠버네티스 컨트롤러는 특정 리소스 유형으로 표현되는 Desired state로 실제(현재)상태가 일치되도록 관리합니다. 예를들자면 Deployment 컨트롤러는 하나의 파드가 삭제되거나 실패 할 때 원하는 양의 파드 복제본이 실행되고 새 파드가 가동되도록 관리합니다.

Custom Resource / Custom Resource Definition

Custom Resource는 Kubernetes API 를 확장하는 방식입니다. Kubernetes API 에서 리소스는 특정 종류의 API 오브젝트 모음을 저장하는 엔드포인트라고 할 수 있습니다.

예를들어서 Kuberentes 에 내장된 Pod 리소스에는 Pod 오브젝트의 모음이 포함되어있습니다.

Custom Resource Definition은 고유한 객체 종류를 정의하고, API 서버가 전체 라이프 사이클을 처리 할 수 있도록 합니다. (파드의 라이프사이클을 API 서버가 관리하듯)

이것을 통해 사용자가 정의한 리소스를 만들어서 Desired State(원하는 상태)를 선언 할 수 있고, Operator 패턴과 함께 사용해서 Desired State 로 유지하도록 하는것이 보통의 유즈케이스입니다.

컨트롤 루프

컨트롤 루프는 쿠버네티스 컨트롤러 내에서 운영 지식을 기반으로 사용자 정의 리소스, 혹은 기존 K8s 리소스, 혹은 이벤트등을 감지해서 Desired State 로 만드는 반복되는 루프라고 할 수 있습니다.

정리

오퍼레이터는 운영 지식을 담아 운영을 자동화하는 소프트웨어의 디자인 패턴이라고 볼 수 있고. 파드를 재배치하거나, 원하는 상태로 되도록 조정하고, Custom Resource Definition & Custom Resource 를 통해 도메인지식/운영지식을 담아서 쿠버네티스 API를 확장하고, Custom Controller (CRD / CR 을 감시하고, 동작하도록 하기 위한 구성요소)는 그것들을 보고 실제 쿠버네티스 오브젝트를 배치하거나, 각종 조작등을하게 됩니다.

다만 Keel 같은 쿠버네티스 오퍼레이터는 CRD / CR 및 Custom Controller를 따로 두지 않고 primitive 쿠버네티스 오브젝트(Deployment / Stateful Set / Daemon Set)등을 관리해주는 역할을 하게 됩니다.

그러니까 CRD/CR , Custom Controller 는 필수 사항은 아니지만, 대부분의 오퍼레이터(Datadog Operator, ECK operator, Istiod그외 다양한 오퍼레이터들)들은 CRD/CR 을 통해 Kubenernets API 를 확장하고, CR 을 사용해 선언한 Deisred State 로 유지하도록 동작하게 됩니다.

간단하게 예를 들자면 Datadog 오퍼레이터를 사용하지 않을 경우 Helm을 통해 혹은 직접 Deployment, ConfigMap, Service Object, Service Account 등을(primitive k8s object)를 생성해서 구성해야겠지만, Datadog 오퍼레이터를 사용하면 Datadog 에서 제공하는 CR 을 통해 간단하게 구성을 할 수 있게 됩니다.

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  global:
    credentials:
      apiSecret:
        secretName: datadog-secret
        keyName: api-key
      appSecret:
        secretName: datadog-secret
        keyName: app-key
  features:
    apm:
      enabled: true
    logCollection:
      enabled: true

개인적인 의견으로는, 설정이 복잡한 애플리케이션의 경우 대부분 Operator 도 제공해주고 있고 해당 Operator 가 업데이트가 잘 되고 있다면 사용하는데 크게 문제가 없다고 생각이 들긴 합니다. 그렇지만 그럼에도 Operator 를 사용하지 않고 구성 할 수 있는 경우에는 Operator 를 사용하지 않고 구성하는것이 장애포인트를 한단계 낮추는 작업이 된다고도 생각합니다.

그럼에도 Operator 패턴을 거의 무조건 써야한다고 생각이 들 때가 있는데, Istiod 처럼 Istio 의 확장 API (Istio 에서는 Gateway, VirtualSerice, DestionationRule 등등)를 수도 없이 많이 써야 할 경우와, primitive k8s 오브젝트로 커버 할 수 없는 정보를 저장하고, 그 정보를 토대로 오퍼레이터가 동작해야하는 경우가 그 경우라고 생각합니다.(물론 ConfigMap, Secrets 같은것들로 정보 자체를 넘겨 줄 수야 있겠지만, 가독성 측면에서 CR이 더 낫지 않을까요?)

예시로 Istio 를 들긴 했지만 해당 시스템에서, 해당 시스템 컨텍스트(추상적으로 이야기했지만..)안에서 돌아가야하는 리소스가 매우매우 많은 경우에는 오히려 primitive k8s 오브젝트를 쓰는것보다 나을거라고 생각합니다. (ArgoCD 도 이런 케이스라고 생각됩니다.)

잘못 된 정보를 수정해주시거나 피드백을 주실 것이 있으면 댓글은 언제든 환영입니다.

You can increase pod number limit in eks worker node by adding environment variable in terraform-aws-modules.

In terraform-aws-modules you can use cluster-addons for installing cluster addons for your eks cluster, and you can inject some environment variable in cluster-addons member object.

So we can inject environment variable in vpc-cni addon like following code snippet. You should read the attached amazon-vpc-cni-k8s link and you need to decide WARM_PREFIX_TARGET WARM_IP_TARGET, MINIMUM_IP_TARGET values.

amazon-vpc-cni-k8s document : https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/prefix-and-ip-target.md

cluster-addons 에서의 vpc-cni 영역에 환경변수 설정을 주입해서 ENABLE_PREFIX_DELEGATION=true 로, WARM_IP_TARGET , MINIMUM_IP_TARGET 등은 각자 상황에 맞게 (https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/prefix-and-ip-target.md 참고)

Failures in distributed systems (분산 시스템에서의 Failures)

etcd 는 Raft 합의 알고리즘을 사용하고 있기 때문에, 클러스터링 된 etcd 중 하나가 장애가 발생하더라도 최소한의 Quorum(정족수)이상의 클러스터 멤버가 정상적이라면 문제가 발생하지 않습니다.

Raft 알고리즘은 여러 concurrent request 를 하나의 조직화된 상태로 만들어서 그것을 모든 Cluster 멤버에게 동기화 시킬 수 있는 알고리즘이라고 이야기 할 수도 있습니다. 이 알고리즘을 통해 모든 멤버는 동일한 데이터를 갖고, 동일한 상태로 유지하도록 할 수 있습니다.

Raft 알고리즘의 특성으로, 하나의 애플리케이션이나 클라이언트에서 들어오는 잘못된 요청이나, 예기치않고 문제가 되는 데이터나, 행동들(많은 데이터를 미친듯이 박아넣는다던지) 역시나 모든 멤버에게 그런 잘못된 데이터나, 많은 데이터들이 뿌려지게 되어서 모든 멤버에게 영향을 끼칠수도 있기도 합니다.

Kubernetes events explosion (K8s 이벤트 오브젝트의 폭발적인 발생으로 인한 문제라고 생각하시면 되는..)

쿠버네티스는 2가지 타입의 리소스를 etcd에 저장하는데, 하나는 Objects 이고 하나는 Events 입니다.

Objects 는 우리가 잘 알고있는 Pod / Deplyoment / StatefulSet / Secret / ConfigMap 과 같은 리소스들로서, 쿠버네티스 클러스터 내의 워크로드들의 상태를 표현하는 것으로 생각 할 수 있습니다. 우리가 Pod 를 선언적으로든, 명령적으로든 쿠버네티스 클러스터에 apply 요청을하면 우리는 Desired State 를 쿠버네티스에 알려준셈입니다. 쿠버네티스는 Desired State 를 유지하기 위해서 kube-schedueler , kube-controller-manager , kubelet 등의 컴포넌트들이 열심히 일을 합니다.

따라서 Objects 들은 매우 매우 중요하며 (그것들 자체가 쿠버네티스 워크로드와 밀접한 관련이 있으니까), 삭제 하지 않는 한 etcd 에 영구히 남아있는 데이터들입니다. 또한 이러한 Objects 들은 쿠버네티스 관리자 / 백엔드 개발자 등 쿠버네티스를 접근하는 관리자들이 선언하는 리소스니까 당연하게도 예측 가능한 사이즈로 존재하게 됩니다. (봇/오퍼레이터 같은 자동화 된 쿠버네티스 요소가 갑자기 Pod 나 ConfigMap 을 1000개, 10000개 씩 만드는 이상한 일을 하지 않는 이상)

Events 는 쿠버네티스 오브젝트의 상태 변화를 기록한것으로, API 를 통한 로그또한 확인이 가능한 리소스입니다. Best effort 로 생성되며, 해당 이벤트가 쿠버네티스 관리자에게 전달되었든지, 안되었든지등을 판단하지 않고 상태가 변할 때 마다 계속해서 생성되는 리소스입니다. 또한 이 데이터들은 etcd Leases 기능을 사용해서 1시간 뒤에는 삭제되는 데이터들입니다. 보통 설정의 오류나 클러스터의 일부 소프트웨어 설정 오류로 인해서 failures 가 발생하는 경우 발생하게 됩니다.

etcd 의 leases 기능은 짧은 시간 저장할 데이터 (Time To Live 기반)를 위해 설계되었습니다.

• 오직 etcd 리더만이 TTL 만료 카운트를 처리하고
• TTL 카운트의 진행상태에 대해서는 멤버간에 공유되지 않습니다.
• 이 상황에서 리더가 변경되면 처음부터 다시 TTL 처리를 위한 카운트가 재시작됩니다.(초기화)

쿠버네티스는 Events 리소스에 대한 TTL 을 1시간으로 설정해두었습니다. (PPT 에는 2시간으로 되어있는데. kube-apiserver 의 --event-ttl 값을 명시적으로 주지 않을 경우 Default 가 1시간입니다. / kube-apiserver 참조)

• Event 를 위한 etcd 인스턴스(클러스터)를 분리하는 것. (kubespray 에서 이것을 쉽게 활성화해서 event 용 etcd 를 분리해서 프로비저닝 할 수 있음. 직접하는것도 크게 문제 될 요소가 아님. kube-apiserver 에 event 용 etcd 서버를 --etcd-servers-overrides 인자를 통해서 별도 지정하면 됨.)
• etcd 이벤트를 persistent 하게 만들지 말고 별도의 로깅 백엔드로 전달하기. (e.g Loki / ElasticSearch, etcs..)
• 만약 Event 리소스때문에 etcd 로드가 계속해서 늘어난다면 TTL 을 줄이기. (kube-apiserver)
• 리더의 TTL 만료를 확인하기 위한 count 체크를 아래 두가지 인자를 활성화해서 더 안전하게 만들기. (카운트 리셋을 방지하기)
  • -experimental-enable-lease-checkpoint → 리더 변경시 TTL 리셋을 방지
  • -experimental-enable-lease-checkpoint-persist → 재시작시 TTL 리셋 방지

(Leases may be auto-renewed indefinitely due to leader elections · Issue #9888 · etcd-io/etcd )

etcd quota deadlock

etcd는 아래와 같은것을 저장

• 특정 키에 대한 최신 상태
• compaction(압축) 이후의 키의 모든 변경사항 (revision)

etcd 는 아래와 같은 quota 존재

• Disk 에 저장되는 db 파일 사이즈의 limit (디폴트 2GB)
• db 파일사이즈 리밋에 도달하면 etcd member 는 알람을 발생시킴
• 이 알람은 etcd 관리자의 개입이 필요함 (compaction and Defragmentation)

kube-apiserver 의 --etcd-compaction-interval 알고리즘에 대한 간단한 설명인데. 가장 큰 문제는 etcd 가 out of quota 상황일 경우 동작하지 않는 다는 점이 있습니다.

• Compaction(압축)
  • etcd 의 빌트인 compaction 매커니즘을 활용하기 (--auto-compaction-retention=5m)
    • etcd 가 할당량(db 파일 사이즈 리밋)을 넘어섰을 때도 동작 함
    • Reduces overhead of window
      • kube-apiserver 의 --etcd-compaction-interval 옵션보다 etcd 의 --auto-compaction-retention 이 오버헤드가 상대적으로 적다는 메인테이너의 발언이 있음. 즉 kube-apiserver 의 --etcd-compaction-interval 을 0으로 설정하여 비활성화하고, etcd 측에서 --auto-compaction-retention 을 설정하는 편이 오버헤드가 훨씬 적다고 함. kube-apiserver 의 로직은 필요한 etcd 데이터 용량의 2배정도를 상용하는 반면, etcd 의 로직은 10% 의 오버헤드만 가진다고 함
  • etcd 할당 대비 사용량(db size) 모니터링
  • Exclude out of quota alarm from health probes
• Deframentation(조각모음)
  • X 분마다 Cronjob 형태로 수행하기 + 일부 jitter 시간을 둬서 동시에 여러 etcd 멤버가 Defrag 수행하는것을 방지하기
  • Defrag 를 아래 컨디션에서만 수행하기
    • At least xxx MB of data to recover AND
    • Quota utilization over 75%
  • Disalarm out of quota alarm

etcd watch starvation

다양한 쿠버네티스 컴포넌트 (kube-scheduler / kube-controller-manager 등)은 kube-apiserver 를 통해 통신하는데. 결국 각 리소스 유형 별로 별도의 스토리지와 Go 스트럭쳐 구조가 있고, 각 클라이언트는 etcd에 독립적인 gRPC 커넥션을 맺습니다. 그래서 특정 리소스(Deployment / Pods / Nodes)에 대한 트래픽이 몰리면 그 많은 트래픽이 단일 커넥션으로 몰리게 됩니다.

TLS 활성화를 위한 작업을 진행하던 도중 리소스 watch 에 대해서 starvation 이 발생했던 경험 공유

(Etcd watch stream starvation under high read response load when sharing same connection and TLS is enabled · Issue #15402 · etcd-io/etcd )

어느 한 클러스터에서만 문제가 생겼는데. 그 클러스터는 다수의 데몬셋 컨트롤러(데몬셋)가 실행중이였다는 것. 해당 클러스터에는 Fluentd / Fluentbit 과 같이 로깅과 관련된 데몬셋이 많이 떠있었습니다. 이런 데몬셋 컨트롤러들은 로깅과 관련된 메타데이터를 수정한다든지(Fluentbit 설정?) 할 때 kube-apiserver 와 커넥션을 맺어야 하는데. 이 때 다수의 노드에 짧은 다운 타임이 있다면 정말 많은 동시 다발적인 LIST 요청이 들어가고, 단일 리소스 타입에 대해서 하나의 gRPC 커넥션에 엄청난 트래픽이 몰렸습니다.

거기에 더해 알고리즘이 Watch 보다 List 에 우선순위가 더 높아서 List 응답만 계속 하다가 Watch 는 응답을 몇분동안 못받는 포화(starvation)상태가 되어버렸습니다.

이 문제가 발생한 이유는 HTTP2 표준에서 TLS커넥션에 대해서 Multiplexing를 허용하지 않았다는것.

non-TLS 트래픽인경우 HTTP 요청은 HTTP 서버로, gRPC 요청인경우 gRPC 서버로 커넥션 레벨에서 체크해서 트래픽을 틀어줄 수 있는데, TLS 트래픽인경우에는 커넥션 레벨에서 HTTP 요청인지, gRPC 요청인지 구분을 할 수 없기 때문에 일단 HTTP 서버에 넘겨주고 gRPC 헤더가 있는경우에 gRPC 핸들러(서버)로 넘겨주는 구조로 되어있었습니다.

즉, non-TLS 트래픽은 gRPC 요청(stream) 을 gRPC handler 로 곧바로 넘겨 줄 수 있었기 때문에 stream 요청에 대한 우선순위가 밀리는등의 처리가 없이 잘 동작했지만. TLS 트래픽의 경우는 일단 HTTP 서버로 넘어간 이후에 처리되었고, 이 때 stream 요청에 대한 우선순위 처리가 제대로 되지 않아 문제가 생겼었던것으로 정리 할 수 있습니다.

gRPC 는 HTTP 서버를 통해 실행하는것을 지원하지만

• 성능과 기능이 좀 다를 수 있고
• grpc-go의 HTTP/2 서버를 통해 제공되는 일부 gRPC 기능을 지원하지 않습니다.

원인은

• HTTP/2 는 writer 별 다중 스트림을 지원하고
• 어떤 스트림을 통해 응답할지 결정하는 알고리즘이 다르고
• HTTP 서버는 PriorityWriteScheduler 를 사용하는데 (golang)
  • 짧은 요청은 우선순위가 높고 처리가 잘 되었지만
  • etcd Watch 같은 gRPC 스트림은 starvation 상태
  • 정리하자면, 짧은 요청이 지속적으로 많이 발생하는동안, gRPC streams 는 완전히 차단되어버림

(net/http: Stream starvation in http2 priority write scheduler · Issue #58804 · golang/go )

결론적으로는 etcd 와 golang 팀과의 협력을 통해서 HTTP/2 server (golang) 부분이 개선되고, etcd watch 에 대한 처리 알고리즘 또한 개선되었습니다.

etcd v3.4.28, v3.5.10 에서는 이 부분이 해결되었다고 합니다. (golang.org/x/net 이 RR 알고리즘을 사용하도록 업데이트 되면서 같이 반영)

Failure Mitigation

Kubernetes가 100% 신뢰성을 제공하거나 ,개발자의 실수로부터 완전히 보호 해 줄 것이라고 가정해서는 안됩니다.

.클러스터에 변경이 발생 할 경우 발견되지 않은 문제로 이어 질 수 있고, 모든 것을 한 곳에 의존하기보다는 클러스터를 분리하고, 장애 발생시 다른 클러스터가 트래픽을 인계 받을 수 있도록 준비하는것이 좋습니다.

전체가 장애가 발생하는것보다는, 부분 적인 다운타임이 발생하거나 약간의 성능저하나 지연이 발생하는것이 낫습니다.

블루-그린 배포처럼 모든 변경 사항을 클러스터의 잠재적인 중단으로 간주하고 독립적으로 롤아웃하는것을 추천합니다. etcd 업그레이드, Kubernetes 업그레이드, 혹은 새로운 트래픽 패턴을 유발하는 애플리케이션 업그레이드 같은것 모든것을 잠재적인 중단, 장애포인트로 생각해야합니다. 이런 변경사항을 모두 블랙박스로 간주하고 독립적으로 롤아웃한다면 문제를 조기에 발견하고 장애 여파를 줄일 수 있습니다.

모든 변경을 중단, 잠재적인 장애 포인트로 간주하고 모든 변경을 검증해야 합니다. 클러스터를 다양한 중요도로 분리하고 각 각에 대해서 단계적 롤아웃을 할당함으로써 위험을 최소화 할 수 있습니다. GKE 가 그렇게 하고 있습니다.

이런 모든 해결책은 장애를 완화하기위한 표준적인 접근 방식이며, 새로 제안된 내용이 아닙니다.

What is the secret

이런 etcd 운영에 관련한 비밀, 노하우는 어딘가에 숨겨져있는것이 아니라 모두 공개적으로 논의되고있었습니다. 여러분들은 그것을 읽고 확인 할 수 있었습니다.

예를들어 Kubernetes 이벤트 이슈는 오랫동안 존재해왔고 etcd 의 이벤트 저장용 클러스터를 분리하는 것이 해결책으로 제시되었습니다. 그럼에도 불구하고 여전히 많은 사람들이 이벤트를 어떻게 다뤄야 하는지 질문하고있습니다.

사람들은 오픈소스를 완성된 해결책으로 여기고 경험을 쌓는 과정을 건너뛰고, 무료 맥주를 하나 꺼내 마시듯이 그것을 사용하려 하지만 오픈 소스는 아이디어를 교환하고 함께 배우는 자유에 관한 것입니다.

etcd 를 운영 할 때 오픈 소스 커뮤니티가 어떻게 운영되는지를 알고 오랜 시간 동안 테스트되어온 etcd 의 일반적인 사용 사례를 벗어나는 함정을 피하기 위해 시간을 투자해야 합니다. etcd 는 생산적인 key-value 스토어이지만 그것을 프로덕션 레디 상태로 만드는 것은 여러분의 몫입니다.

이 발표자가 논의한 대부분의 etcd 이슈에 대한 해결책은 오픈 소스로 구현 할 수 없었습니다. Kubernetes 클러스터를 재설계 해야하거나 재구성 해야 하는 것을 요구하기 때문입니다. (실제로 이 메인테이너가 TLS , HTTP2 관련해서 이슈를 올린 것을 살펴보면 여러 대안을 제시하고 일부는 현실적으로 어려움이 있어서 폐기하기도 하였음. / Etcd watch stream starvation under high read response load when sharing same connection and TLS is enabled · Issue #15402 · etcd-io/etcd )

여러분은 그것을 고려하고 어떻게 알고있는 흔한 함정을 피할 수 있을지 생각해야 합니다. 그러기 위해 가장 좋은 방법은 커뮤니티의 집단적인 경험을 활용하는 것입니다.

대부분의 사람들이 여전히 알려진 문제가 있는 etcd 버전을 사용하고 있으며, 그 문제에 대해 여러차례 메일이 발송되었음에도 불구하고 여전히 그것을 따르지 않다는 것을 알 고 있습니다. 저의 제안(메인테이너)은 커뮤니티가 무엇을 하고 있는지, 논의가 어떻게 진행되고 있는지를 알아보는데 시간을 투자하는 것입니다.

Wrapping up

이 세션을 발표한 etcd 메인테이너이자, 구글 소프트웨어 엔지니어인 Marek Siarkowicz는 etcd 의 잘 알려진 (그러나 많이들 따르지 않거나 모르고 있는) 문제에 대해서 발표 전체에 걸쳐서 다뤘습니다.

뒤쪽에서는 etcd를 단순히 쉽게 free beer 처럼 꺼내 쓰는 것이 아니라 정말 생산적이고, Production Ready 상태로 만드는것은 사용자(개발자)의 몫이며, 잘 알려진, 오랜시간동안 테스트되어온 사용사례를 따르기 위해서 커뮤니티를 살펴보고 이 프로젝트가 어떻게 흘러가고있는지 시간을 투자하라는 이야기를 하고 있습니다.

또한 etcd 를 사용하다 문제가 생긴 경우 커뮤니티, etcd 프로젝트를 찾아보거나 메일링 리스트를 살펴보고, 커뮤니티에 질문하고 더 나아가서는 겪은 문제에 대해서 공유하고, 혼자서 해결하려고 시도하지 말고 커뮤니티의 집단적인 경험을 잘 활용하라고 이야기 합니다.

모든 것을 혼자서 해결 하려 하지 말고, 커뮤니티의 집단적 경험을 활용하고, 대화를 나누면서 배우세요.

발표자의 발표 말미의 한 마디를 인용하면서 글을 마칩니다.

테스트 코드들

GitHub - kimsehwan96/gRPC-python-example

GitHub - kimsehwan96/istio-example

gRPC 테스트 서버

gRPC 의 경우 직렬화/역직렬화 과정에서 protobuf 를 사용합니다. 따라서 .proto 파일을 통해 주고받을 데이터의 형식을 지정해야 합니다.

// Copyright 2015 gRPC authors.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
//     http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

syntax = "proto3";

option java_multiple_files = true;
option java_package = "io.grpc.examples.helloworld";
option java_outer_classname = "HelloWorldProto";
option objc_class_prefix = "HLW";

package helloworld;

import "google/api/annotations.proto";

// The greeting service definition.
service Greeter {
  // Sends a greeting
  rpc SayHello (HelloRequest) returns (HelloReply) {
    option (google.api.http) = {
      get: "/v1/hello"
    };
  }

  // Another Method
  rpc SayHelloAgain (HelloRequest) returns (HelloReply) {}

  rpc SayHelloStreamReply (HelloRequest) returns (stream HelloReply) {}

  rpc SayHelloBidiStream (stream HelloRequest) returns (stream HelloReply) {}
}

// The request message containing the user's name.
message HelloRequest {
  string name = 1;
}

// The response message containing the greetings
message HelloReply {
  string message = 1;
}

위와 같이 간단한 proto 파일을 생성합니다. 여기서 json 트랜스코더에서 사용할 option (google.api.http) 부분을 추가하면 기존 Restful API(HTTP API) 형태로 사용이 가능합니다. 다만 이때 proto descriptor 생성을 할 때 googleapis 를 proto descriptor 빌드하는 환경에 추가해야 합니다.

굳이 위 예제에서의 gRPC 서버가 아니더라도, HTTP 엔드포인트를 노출한 protobuf + gRPC 서버라면 어찌되었든 이 예제에서 사용하려는 테스트는 진행 가능합니다.

Istio Envoy filter

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: grpc-transcoder
spec:
  workloadSelector:
    labels:
      app: grpc-python
  configPatches:
    - applyTo: HTTP_FILTER
      match:
        context: SIDECAR_INBOUND
        listener:
          portNumber: 7777 # 5xxxx 번대 포트를 지정하면 반영이 안된다. 이건 왜그런지;
          filterChain:
            filter:
              name: "envoy.filters.network.http_connection_manager"
              subFilter:
                name: "envoy.filters.http.router"
      patch:
        operation: INSERT_BEFORE
        value:
          name: envoy.filters.http.grpc_json_transcoder
          typed_config:
            "@type": type.googleapis.com/envoy.extensions.filters.http.grpc_json_transcoder.v3.GrpcJsonTranscoder
            services:
              - helloworld.Greeter
            print_options:
              add_whitespace: true
              always_print_enums_as_ints: false
              always_print_primitive_fields: true
              preserve_proto_field_names: false
            convert_grpc_status: true
            proto_descriptor_bin: CuF4ChVnb29nbGUvYXBpL2h0dHAucHJvdG8SCmdvb2dsZS5hcGkieQoESHR0cBIqCgVydWxlcxgBIAMoCzIULmdvb2dsZS5hcGkuSHR0cFJ1bGVSBXJ1bGVzEkUKH2Z1bGx5X2RlY29kZV9yZXNlcnZlZF9leHBhbnNpb24YAiABKAhSHGZ1bGx5RGVjb2RlUmVzZXJ2ZWRFeHBhbnNpb24i2gIKCEh0dHBSdWxlEhoKCHNlbGVjdG9yGAEgASgJUghzZWxlY3RvchISCgNnZXQYAiABKAlIAFIDZ2V0EhIKA3B1dBgDIAEoCUgAUgNwdXQSFAoEcG9zdBgEIAEoCUgAUgRwb3N0EhgKBmRlbGV0ZRgFIAEoCUgAUgZkZWxldGUSFgoFcGF0Y2gYBiABKAlIAFIFcGF0Y2gSNwoGY3VzdG9tGAggASgLMh0uZ29vZ2xlLmFwaS5DdXN0b21IdHRwUGF0dGVybkgAUgZjdXN0b20SEgoEYm9keRgHIAEoCVIEYm9keRIjCg1yZXNwb25zZV9ib2R5GAwgASgJUgxyZXNwb25zZUJvZHkSRQoTYWRkaXRpb25hbF9iaW5kaW5ncxgLIAMoCzIULmdvb2dsZS5hcGkuSHR0cFJ1bGVSEmFkZGl0aW9uYWxCaW5kaW5nc0IJCgdwYXR0ZXJuIjsKEUN1c3RvbUh0dHBQYXR0ZXJuEhIKBGtpbmQYASABKAlSBGtpbmQSEgoEcGF0aBgCIAEoCVIEcGF0aEJqCg5jb20uZ29vZ2xlLmFwaUIJSHR0cFByb3RvUAFaQWdvb2dsZS5nb2xhbmcub3JnL2dlbnByb3RvL2dvb2dsZWFwaXMvYXBpL2Fubm90YXRpb25zO2Fubm90YXRpb25z+AEBogIER0FQSUqycwoHEgUOAPoCAQq8BAoBDBIDDgASMrEEIENvcHlyaWdodCAyMDIzIEdvb2dsZSBMTEMKCiBMaWNlbnNlZCB1bmRlciB0aGUgQXBhY2hlIExpY2Vuc2UsIFZlcnNpb24gMi4wICh0aGUgIkxpY2Vuc2UiKTsKIHlvdSBtYXkgbm90IHVzZSB0aGlzIGZpbGUgZXhjZXB0IGluIGNvbXBsaWFuY2Ugd2l0aCB0aGUgTGljZW5zZS4KIFlvdSBtYXkgb2J0YWluIGEgY29weSBvZiB0aGUgTGljZW5zZSBhdAoKICAgICBodHRwOi8vd3d3LmFwYWNoZS5vcmcvbGljZW5zZXMvTElDRU5TRS0yLjAKCiBVbmxlc3MgcmVxdWlyZWQgYnkgYXBwbGljYWJsZSBsYXcgb3IgYWdyZWVkIHRvIGluIHdyaXRpbmcsIHNvZnR3YXJlCiBkaXN0cmlidXRlZCB1bmRlciB0aGUgTGljZW5zZSBpcyBkaXN0cmlidXRlZCBvbiBhbiAiQVMgSVMiIEJBU0lTLAogV0lUSE9VVCBXQVJSQU5USUVTIE9SIENPTkRJVElPTlMgT0YgQU5ZIEtJTkQsIGVpdGhlciBleHByZXNzIG9yIGltcGxpZWQuCiBTZWUgdGhlIExpY2Vuc2UgZm9yIHRoZSBzcGVjaWZpYyBsYW5ndWFnZSBnb3Zlcm5pbmcgcGVybWlzc2lvbnMgYW5kCiBsaW1pdGF0aW9ucyB1bmRlciB0aGUgTGljZW5zZS4KCggKAQISAxAAEwoICgEIEgMSAB8KCQoCCB8SAxIAHwoICgEIEgMTAFgKCQoCCAsSAxMAWAoICgEIEgMUACIKCQoCCAoSAxQAIgoICgEIEgMVACoKCQoCCAgSAxUAKgoICgEIEgMWACcKCQoCCAESAxYAJwoICgEIEgMXACIKCQoCCCQSAxcAIgrNAQoCBAASBBwAKQEawAEgRGVmaW5lcyB0aGUgSFRUUCBjb25maWd1cmF0aW9uIGZvciBhbiBBUEkgc2VydmljZS4gSXQgY29udGFpbnMgYSBsaXN0IG9mCiBbSHR0cFJ1bGVdW2dvb2dsZS5hcGkuSHR0cFJ1bGVdLCBlYWNoIHNwZWNpZnlpbmcgdGhlIG1hcHBpbmcgb2YgYW4gUlBDIG1ldGhvZAogdG8gb25lIG9yIG1vcmUgSFRUUCBSRVNUIEFQSSBtZXRob2RzLgoKCgoDBAABEgMcCAwKogEKBAQAAgASAyACHhqUASBBIGxpc3Qgb2YgSFRUUCBjb25maWd1cmF0aW9uIHJ1bGVzIHRoYXQgYXBwbHkgdG8gaW5kaXZpZHVhbCBBUEkgbWV0aG9kcy4KCiAqKk5PVEU6KiogQWxsIHNlcnZpY2UgY29uZmlndXJhdGlvbiBydWxlcyBmb2xsb3cgImxhc3Qgb25lIHdpbnMiIG9yZGVyLgoKDAoFBAACAAQSAyACCgoMCgUEAAIABhIDIAsTCgwKBQQAAgABEgMgFBkKDAoFBAACAAMSAyAcHQqUAgoEBAACARIDKAIrGoYCIFdoZW4gc2V0IHRvIHRydWUsIFVSTCBwYXRoIHBhcmFtZXRlcnMgd2lsbCBiZSBmdWxseSBVUkktZGVjb2RlZCBleGNlcHQgaW4KIGNhc2VzIG9mIHNpbmdsZSBzZWdtZW50IG1hdGNoZXMgaW4gcmVzZXJ2ZWQgZXhwYW5zaW9uLCB3aGVyZSAiJTJGIiB3aWxsIGJlCiBsZWZ0IGVuY29kZWQuCgogVGhlIGRlZmF1bHQgYmVoYXZpb3IgaXMgdG8gbm90IGRlY29kZSBSRkMgNjU3MCByZXNlcnZlZCBjaGFyYWN0ZXJzIGluIG11bHRpCiBzZWdtZW50IG1hdGNoZXMuCgoMCgUEAAIBBRIDKAIGCgwKBQQAAgEBEgMoByYKDAoFBAACAQMSAygpKgq7UwoCBAESBrsCAPECARqsUyAjIGdSUEMgVHJhbnNjb2RpbmcKCiBnUlBDIFRyYW5zY29kaW5nIGlzIGEgZmVhdHVyZSBmb3IgbWFwcGluZyBiZXR3ZWVuIGEgZ1JQQyBtZXRob2QgYW5kIG9uZSBvcgogbW9yZSBIVFRQIFJFU1QgZW5kcG9pbnRzLiBJdCBhbGxvd3MgZGV2ZWxvcGVycyB0byBidWlsZCBhIHNpbmdsZSBBUEkgc2VydmljZQogdGhhdCBzdXBwb3J0cyBib3RoIGdSUEMgQVBJcyBhbmQgUkVTVCBBUElzLiBNYW55IHN5c3RlbXMsIGluY2x1ZGluZyBbR29vZ2xlCiBBUElzXShodHRwczovL2dpdGh1Yi5jb20vZ29vZ2xlYXBpcy9nb29nbGVhcGlzKSwKIFtDbG91ZCBFbmRwb2ludHNdKGh0dHBzOi8vY2xvdWQuZ29vZ2xlLmNvbS9lbmRwb2ludHMpLCBbZ1JQQwogR2F0ZXdheV0oaHR0cHM6Ly9naXRodWIuY29tL2dycGMtZWNvc3lzdGVtL2dycGMtZ2F0ZXdheSksCiBhbmQgW0Vudm95XShodHRwczovL2dpdGh1Yi5jb20vZW52b3lwcm94eS9lbnZveSkgcHJveHkgc3VwcG9ydCB0aGlzIGZlYXR1cmUKIGFuZCB1c2UgaXQgZm9yIGxhcmdlIHNjYWxlIHByb2R1Y3Rpb24gc2VydmljZXMuCgogYEh0dHBSdWxlYCBkZWZpbmVzIHRoZSBzY2hlbWEgb2YgdGhlIGdSUEMvUkVTVCBtYXBwaW5nLiBUaGUgbWFwcGluZyBzcGVjaWZpZXMKIGhvdyBkaWZmZXJlbnQgcG9ydGlvbnMgb2YgdGhlIGdSUEMgcmVxdWVzdCBtZXNzYWdlIGFyZSBtYXBwZWQgdG8gdGhlIFVSTAogcGF0aCwgVVJMIHF1ZXJ5IHBhcmFtZXRlcnMsIGFuZCBIVFRQIHJlcXVlc3QgYm9keS4gSXQgYWxzbyBjb250cm9scyBob3cgdGhlCiBnUlBDIHJlc3BvbnNlIG1lc3NhZ2UgaXMgbWFwcGVkIHRvIHRoZSBIVFRQIHJlc3BvbnNlIGJvZHkuIGBIdHRwUnVsZWAgaXMKIHR5cGljYWxseSBzcGVjaWZpZWQgYXMgYW4gYGdvb2dsZS5hcGkuaHR0cGAgYW5ub3RhdGlvbiBvbiB0aGUgZ1JQQyBtZXRob2QuCgogRWFjaCBtYXBwaW5nIHNwZWNpZmllcyBhIFVSTCBwYXRoIHRlbXBsYXRlIGFuZCBhbiBIVFRQIG1ldGhvZC4gVGhlIHBhdGgKIHRlbXBsYXRlIG1heSByZWZlciB0byBvbmUgb3IgbW9yZSBmaWVsZHMgaW4gdGhlIGdSUEMgcmVxdWVzdCBtZXNzYWdlLCBhcyBsb25nCiBhcyBlYWNoIGZpZWxkIGlzIGEgbm9uLXJlcGVhdGVkIGZpZWxkIHdpdGggYSBwcmltaXRpdmUgKG5vbi1tZXNzYWdlKSB0eXBlLgogVGhlIHBhdGggdGVtcGxhdGUgY29udHJvbHMgaG93IGZpZWxkcyBvZiB0aGUgcmVxdWVzdCBtZXNzYWdlIGFyZSBtYXBwZWQgdG8KIHRoZSBVUkwgcGF0aC4KCiBFeGFtcGxlOgoKICAgICBzZXJ2aWNlIE1lc3NhZ2luZyB7CiAgICAgICBycGMgR2V0TWVzc2FnZShHZXRNZXNzYWdlUmVxdWVzdCkgcmV0dXJucyAoTWVzc2FnZSkgewogICAgICAgICBvcHRpb24gKGdvb2dsZS5hcGkuaHR0cCkgPSB7CiAgICAgICAgICAgICBnZXQ6ICIvdjEve25hbWU9bWVzc2FnZXMvKn0iCiAgICAgICAgIH07CiAgICAgICB9CiAgICAgfQogICAgIG1lc3NhZ2UgR2V0TWVzc2FnZVJlcXVlc3QgewogICAgICAgc3RyaW5nIG5hbWUgPSAxOyAvLyBNYXBwZWQgdG8gVVJMIHBhdGguCiAgICAgfQogICAgIG1lc3NhZ2UgTWVzc2FnZSB7CiAgICAgICBzdHJpbmcgdGV4dCA9IDE7IC8vIFRoZSByZXNvdXJjZSBjb250ZW50LgogICAgIH0KCiBUaGlzIGVuYWJsZXMgYW4gSFRUUCBSRVNUIHRvIGdSUEMgbWFwcGluZyBhcyBiZWxvdzoKCiBIVFRQIHwgZ1JQQwogLS0tLS18LS0tLS0KIGBHRVQgL3YxL21lc3NhZ2VzLzEyMzQ1NmAgIHwgYEdldE1lc3NhZ2UobmFtZTogIm1lc3NhZ2VzLzEyMzQ1NiIpYAoKIEFueSBmaWVsZHMgaW4gdGhlIHJlcXVlc3QgbWVzc2FnZSB3aGljaCBhcmUgbm90IGJvdW5kIGJ5IHRoZSBwYXRoIHRlbXBsYXRlCiBhdXRvbWF0aWNhbGx5IGJlY29tZSBIVFRQIHF1ZXJ5IHBhcmFtZXRlcnMgaWYgdGhlcmUgaXMgbm8gSFRUUCByZXF1ZXN0IGJvZHkuCiBGb3IgZXhhbXBsZToKCiAgICAgc2VydmljZSBNZXNzYWdpbmcgewogICAgICAgcnBjIEdldE1lc3NhZ2UoR2V0TWVzc2FnZVJlcXVlc3QpIHJldHVybnMgKE1lc3NhZ2UpIHsKICAgICAgICAgb3B0aW9uIChnb29nbGUuYXBpLmh0dHApID0gewogICAgICAgICAgICAgZ2V0OiIvdjEvbWVzc2FnZXMve21lc3NhZ2VfaWR9IgogICAgICAgICB9OwogICAgICAgfQogICAgIH0KICAgICBtZXNzYWdlIEdldE1lc3NhZ2VSZXF1ZXN0IHsKICAgICAgIG1lc3NhZ2UgU3ViTWVzc2FnZSB7CiAgICAgICAgIHN0cmluZyBzdWJmaWVsZCA9IDE7CiAgICAgICB9CiAgICAgICBzdHJpbmcgbWVzc2FnZV9pZCA9IDE7IC8vIE1hcHBlZCB0byBVUkwgcGF0aC4KICAgICAgIGludDY0IHJldmlzaW9uID0gMjsgICAgLy8gTWFwcGVkIHRvIFVSTCBxdWVyeSBwYXJhbWV0ZXIgYHJldmlzaW9uYC4KICAgICAgIFN1Yk1lc3NhZ2Ugc3ViID0gMzsgICAgLy8gTWFwcGVkIHRvIFVSTCBxdWVyeSBwYXJhbWV0ZXIgYHN1Yi5zdWJmaWVsZGAuCiAgICAgfQoKIFRoaXMgZW5hYmxlcyBhIEhUVFAgSlNPTiB0byBSUEMgbWFwcGluZyBhcyBiZWxvdzoKCiBIVFRQIHwgZ1JQQwogLS0tLS18LS0tLS0KIGBHRVQgL3YxL21lc3NhZ2VzLzEyMzQ1Nj9yZXZpc2lvbj0yJnN1Yi5zdWJmaWVsZD1mb29gIHwKIGBHZXRNZXNzYWdlKG1lc3NhZ2VfaWQ6ICIxMjM0NTYiIHJldmlzaW9uOiAyIHN1YjogU3ViTWVzc2FnZShzdWJmaWVsZDoKICJmb28iKSlgCgogTm90ZSB0aGF0IGZpZWxkcyB3aGljaCBhcmUgbWFwcGVkIHRvIFVSTCBxdWVyeSBwYXJhbWV0ZXJzIG11c3QgaGF2ZSBhCiBwcmltaXRpdmUgdHlwZSBvciBhIHJlcGVhdGVkIHByaW1pdGl2ZSB0eXBlIG9yIGEgbm9uLXJlcGVhdGVkIG1lc3NhZ2UgdHlwZS4KIEluIHRoZSBjYXNlIG9mIGEgcmVwZWF0ZWQgdHlwZSwgdGhlIHBhcmFtZXRlciBjYW4gYmUgcmVwZWF0ZWQgaW4gdGhlIFVSTAogYXMgYC4uLj9wYXJhbT1BJnBhcmFtPUJgLiBJbiB0aGUgY2FzZSBvZiBhIG1lc3NhZ2UgdHlwZSwgZWFjaCBmaWVsZCBvZiB0aGUKIG1lc3NhZ2UgaXMgbWFwcGVkIHRvIGEgc2VwYXJhdGUgcGFyYW1ldGVyLCBzdWNoIGFzCiBgLi4uP2Zvby5hPUEmZm9vLmI9QiZmb28uYz1DYC4KCiBGb3IgSFRUUCBtZXRob2RzIHRoYXQgYWxsb3cgYSByZXF1ZXN0IGJvZHksIHRoZSBgYm9keWAgZmllbGQKIHNwZWNpZmllcyB0aGUgbWFwcGluZy4gQ29uc2lkZXIgYSBSRVNUIHVwZGF0ZSBtZXRob2Qgb24gdGhlCiBtZXNzYWdlIHJlc291cmNlIGNvbGxlY3Rpb246CgogICAgIHNlcnZpY2UgTWVzc2FnaW5nIHsKICAgICAgIHJwYyBVcGRhdGVNZXNzYWdlKFVwZGF0ZU1lc3NhZ2VSZXF1ZXN0KSByZXR1cm5zIChNZXNzYWdlKSB7CiAgICAgICAgIG9wdGlvbiAoZ29vZ2xlLmFwaS5odHRwKSA9IHsKICAgICAgICAgICBwYXRjaDogIi92MS9tZXNzYWdlcy97bWVzc2FnZV9pZH0iCiAgICAgICAgICAgYm9keTogIm1lc3NhZ2UiCiAgICAgICAgIH07CiAgICAgICB9CiAgICAgfQogICAgIG1lc3NhZ2UgVXBkYXRlTWVzc2FnZVJlcXVlc3QgewogICAgICAgc3RyaW5nIG1lc3NhZ2VfaWQgPSAxOyAvLyBtYXBwZWQgdG8gdGhlIFVSTAogICAgICAgTWVzc2FnZSBtZXNzYWdlID0gMjsgICAvLyBtYXBwZWQgdG8gdGhlIGJvZHkKICAgICB9CgogVGhlIGZvbGxvd2luZyBIVFRQIEpTT04gdG8gUlBDIG1hcHBpbmcgaXMgZW5hYmxlZCwgd2hlcmUgdGhlCiByZXByZXNlbnRhdGlvbiBvZiB0aGUgSlNPTiBpbiB0aGUgcmVxdWVzdCBib2R5IGlzIGRldGVybWluZWQgYnkKIHByb3RvcyBKU09OIGVuY29kaW5nOgoKIEhUVFAgfCBnUlBDCiAtLS0tLXwtLS0tLQogYFBBVENIIC92MS9tZXNzYWdlcy8xMjM0NTYgeyAidGV4dCI6ICJIaSEiIH1gIHwgYFVwZGF0ZU1lc3NhZ2UobWVzc2FnZV9pZDoKICIxMjM0NTYiIG1lc3NhZ2UgeyB0ZXh0OiAiSGkhIiB9KWAKCiBUaGUgc3BlY2lhbCBuYW1lIGAqYCBjYW4gYmUgdXNlZCBpbiB0aGUgYm9keSBtYXBwaW5nIHRvIGRlZmluZSB0aGF0CiBldmVyeSBmaWVsZCBub3QgYm91bmQgYnkgdGhlIHBhdGggdGVtcGxhdGUgc2hvdWxkIGJlIG1hcHBlZCB0byB0aGUKIHJlcXVlc3QgYm9keS4gIFRoaXMgZW5hYmxlcyB0aGUgZm9sbG93aW5nIGFsdGVybmF0aXZlIGRlZmluaXRpb24gb2YKIHRoZSB1cGRhdGUgbWV0aG9kOgoKICAgICBzZXJ2aWNlIE1lc3NhZ2luZyB7CiAgICAgICBycGMgVXBkYXRlTWVzc2FnZShNZXNzYWdlKSByZXR1cm5zIChNZXNzYWdlKSB7CiAgICAgICAgIG9wdGlvbiAoZ29vZ2xlLmFwaS5odHRwKSA9IHsKICAgICAgICAgICBwYXRjaDogIi92MS9tZXNzYWdlcy97bWVzc2FnZV9pZH0iCiAgICAgICAgICAgYm9keTogIioiCiAgICAgICAgIH07CiAgICAgICB9CiAgICAgfQogICAgIG1lc3NhZ2UgTWVzc2FnZSB7CiAgICAgICBzdHJpbmcgbWVzc2FnZV9pZCA9IDE7CiAgICAgICBzdHJpbmcgdGV4dCA9IDI7CiAgICAgfQoKCiBUaGUgZm9sbG93aW5nIEhUVFAgSlNPTiB0byBSUEMgbWFwcGluZyBpcyBlbmFibGVkOgoKIEhUVFAgfCBnUlBDCiAtLS0tLXwtLS0tLQogYFBBVENIIC92MS9tZXNzYWdlcy8xMjM0NTYgeyAidGV4dCI6ICJIaSEiIH1gIHwgYFVwZGF0ZU1lc3NhZ2UobWVzc2FnZV9pZDoKICIxMjM0NTYiIHRleHQ6ICJIaSEiKWAKCiBOb3RlIHRoYXQgd2hlbiB1c2luZyBgKmAgaW4gdGhlIGJvZHkgbWFwcGluZywgaXQgaXMgbm90IHBvc3NpYmxlIHRvCiBoYXZlIEhUVFAgcGFyYW1ldGVycywgYXMgYWxsIGZpZWxkcyBub3QgYm91bmQgYnkgdGhlIHBhdGggZW5kIGluCiB0aGUgYm9keS4gVGhpcyBtYWtlcyB0aGlzIG9wdGlvbiBtb3JlIHJhcmVseSB1c2VkIGluIHByYWN0aWNlIHdoZW4KIGRlZmluaW5nIFJFU1QgQVBJcy4gVGhlIGNvbW1vbiB1c2FnZSBvZiBgKmAgaXMgaW4gY3VzdG9tIG1ldGhvZHMKIHdoaWNoIGRvbid0IHVzZSB0aGUgVVJMIGF0IGFsbCBmb3IgdHJhbnNmZXJyaW5nIGRhdGEuCgogSXQgaXMgcG9zc2libGUgdG8gZGVmaW5lIG11bHRpcGxlIEhUVFAgbWV0aG9kcyBmb3Igb25lIFJQQyBieSB1c2luZwogdGhlIGBhZGRpdGlvbmFsX2JpbmRpbmdzYCBvcHRpb24uIEV4YW1wbGU6CgogICAgIHNlcnZpY2UgTWVzc2FnaW5nIHsKICAgICAgIHJwYyBHZXRNZXNzYWdlKEdldE1lc3NhZ2VSZXF1ZXN0KSByZXR1cm5zIChNZXNzYWdlKSB7CiAgICAgICAgIG9wdGlvbiAoZ29vZ2xlLmFwaS5odHRwKSA9IHsKICAgICAgICAgICBnZXQ6ICIvdjEvbWVzc2FnZXMve21lc3NhZ2VfaWR9IgogICAgICAgICAgIGFkZGl0aW9uYWxfYmluZGluZ3MgewogICAgICAgICAgICAgZ2V0OiAiL3YxL3VzZXJzL3t1c2VyX2lkfS9tZXNzYWdlcy97bWVzc2FnZV9pZH0iCiAgICAgICAgICAgfQogICAgICAgICB9OwogICAgICAgfQogICAgIH0KICAgICBtZXNzYWdlIEdldE1lc3NhZ2VSZXF1ZXN0IHsKICAgICAgIHN0cmluZyBtZXNzYWdlX2lkID0gMTsKICAgICAgIHN0cmluZyB1c2VyX2lkID0gMjsKICAgICB9CgogVGhpcyBlbmFibGVzIHRoZSBmb2xsb3dpbmcgdHdvIGFsdGVybmF0aXZlIEhUVFAgSlNPTiB0byBSUEMgbWFwcGluZ3M6CgogSFRUUCB8IGdSUEMKIC0tLS0tfC0tLS0tCiBgR0VUIC92MS9tZXNzYWdlcy8xMjM0NTZgIHwgYEdldE1lc3NhZ2UobWVzc2FnZV9pZDogIjEyMzQ1NiIpYAogYEdFVCAvdjEvdXNlcnMvbWUvbWVzc2FnZXMvMTIzNDU2YCB8IGBHZXRNZXNzYWdlKHVzZXJfaWQ6ICJtZSIgbWVzc2FnZV9pZDoKICIxMjM0NTYiKWAKCiAjIyBSdWxlcyBmb3IgSFRUUCBtYXBwaW5nCgogMS4gTGVhZiByZXF1ZXN0IGZpZWxkcyAocmVjdXJzaXZlIGV4cGFuc2lvbiBuZXN0ZWQgbWVzc2FnZXMgaW4gdGhlIHJlcXVlc3QKICAgIG1lc3NhZ2UpIGFyZSBjbGFzc2lmaWVkIGludG8gdGhyZWUgY2F0ZWdvcmllczoKICAgIC0gRmllbGRzIHJlZmVycmVkIGJ5IHRoZSBwYXRoIHRlbXBsYXRlLiBUaGV5IGFyZSBwYXNzZWQgdmlhIHRoZSBVUkwgcGF0aC4KICAgIC0gRmllbGRzIHJlZmVycmVkIGJ5IHRoZSBbSHR0cFJ1bGUuYm9keV1bZ29vZ2xlLmFwaS5IdHRwUnVsZS5ib2R5XS4gVGhleQogICAgYXJlIHBhc3NlZCB2aWEgdGhlIEhUVFAKICAgICAgcmVxdWVzdCBib2R5LgogICAgLSBBbGwgb3RoZXIgZmllbGRzIGFyZSBwYXNzZWQgdmlhIHRoZSBVUkwgcXVlcnkgcGFyYW1ldGVycywgYW5kIHRoZQogICAgICBwYXJhbWV0ZXIgbmFtZSBpcyB0aGUgZmllbGQgcGF0aCBpbiB0aGUgcmVxdWVzdCBtZXNzYWdlLiBBIHJlcGVhdGVkCiAgICAgIGZpZWxkIGNhbiBiZSByZXByZXNlbnRlZCBhcyBtdWx0aXBsZSBxdWVyeSBwYXJhbWV0ZXJzIHVuZGVyIHRoZSBzYW1lCiAgICAgIG5hbWUuCiAgMi4gSWYgW0h0dHBSdWxlLmJvZHldW2dvb2dsZS5hcGkuSHR0cFJ1bGUuYm9keV0gaXMgIioiLCB0aGVyZSBpcyBubyBVUkwKICBxdWVyeSBwYXJhbWV0ZXIsIGFsbCBmaWVsZHMKICAgICBhcmUgcGFzc2VkIHZpYSBVUkwgcGF0aCBhbmQgSFRUUCByZXF1ZXN0IGJvZHkuCiAgMy4gSWYgW0h0dHBSdWxlLmJvZHldW2dvb2dsZS5hcGkuSHR0cFJ1bGUuYm9keV0gaXMgb21pdHRlZCwgdGhlcmUgaXMgbm8gSFRUUAogIHJlcXVlc3QgYm9keSwgYWxsCiAgICAgZmllbGRzIGFyZSBwYXNzZWQgdmlhIFVSTCBwYXRoIGFuZCBVUkwgcXVlcnkgcGFyYW1ldGVycy4KCiAjIyMgUGF0aCB0ZW1wbGF0ZSBzeW50YXgKCiAgICAgVGVtcGxhdGUgPSAiLyIgU2VnbWVudHMgWyBWZXJiIF0gOwogICAgIFNlZ21lbnRzID0gU2VnbWVudCB7ICIvIiBTZWdtZW50IH0gOwogICAgIFNlZ21lbnQgID0gIioiIHwgIioqIiB8IExJVEVSQUwgfCBWYXJpYWJsZSA7CiAgICAgVmFyaWFibGUgPSAieyIgRmllbGRQYXRoIFsgIj0iIFNlZ21lbnRzIF0gIn0iIDsKICAgICBGaWVsZFBhdGggPSBJREVOVCB7ICIuIiBJREVOVCB9IDsKICAgICBWZXJiICAgICA9ICI6IiBMSVRFUkFMIDsKCiBUaGUgc3ludGF4IGAqYCBtYXRjaGVzIGEgc2luZ2xlIFVSTCBwYXRoIHNlZ21lbnQuIFRoZSBzeW50YXggYCoqYCBtYXRjaGVzCiB6ZXJvIG9yIG1vcmUgVVJMIHBhdGggc2VnbWVudHMsIHdoaWNoIG11c3QgYmUgdGhlIGxhc3QgcGFydCBvZiB0aGUgVVJMIHBhdGgKIGV4Y2VwdCB0aGUgYFZlcmJgLgoKIFRoZSBzeW50YXggYFZhcmlhYmxlYCBtYXRjaGVzIHBhcnQgb2YgdGhlIFVSTCBwYXRoIGFzIHNwZWNpZmllZCBieSBpdHMKIHRlbXBsYXRlLiBBIHZhcmlhYmxlIHRlbXBsYXRlIG11c3Qgbm90IGNvbnRhaW4gb3RoZXIgdmFyaWFibGVzLiBJZiBhIHZhcmlhYmxlCiBtYXRjaGVzIGEgc2luZ2xlIHBhdGggc2VnbWVudCwgaXRzIHRlbXBsYXRlIG1heSBiZSBvbWl0dGVkLCBlLmcuIGB7dmFyfWAKIGlzIGVxdWl2YWxlbnQgdG8gYHt2YXI9Kn1gLgoKIFRoZSBzeW50YXggYExJVEVSQUxgIG1hdGNoZXMgbGl0ZXJhbCB0ZXh0IGluIHRoZSBVUkwgcGF0aC4gSWYgdGhlIGBMSVRFUkFMYAogY29udGFpbnMgYW55IHJlc2VydmVkIGNoYXJhY3Rlciwgc3VjaCBjaGFyYWN0ZXJzIHNob3VsZCBiZSBwZXJjZW50LWVuY29kZWQKIGJlZm9yZSB0aGUgbWF0Y2hpbmcuCgogSWYgYSB2YXJpYWJsZSBjb250YWlucyBleGFjdGx5IG9uZSBwYXRoIHNlZ21lbnQsIHN1Y2ggYXMgYCJ7dmFyfSJgIG9yCiBgInt2YXI9Kn0iYCwgd2hlbiBzdWNoIGEgdmFyaWFibGUgaXMgZXhwYW5kZWQgaW50byBhIFVSTCBwYXRoIG9uIHRoZSBjbGllbnQKIHNpZGUsIGFsbCBjaGFyYWN0ZXJzIGV4Y2VwdCBgWy1fLn4wLTlhLXpBLVpdYCBhcmUgcGVyY2VudC1lbmNvZGVkLiBUaGUKIHNlcnZlciBzaWRlIGRvZXMgdGhlIHJldmVyc2UgZGVjb2RpbmcuIFN1Y2ggdmFyaWFibGVzIHNob3cgdXAgaW4gdGhlCiBbRGlzY292ZXJ5CiBEb2N1bWVudF0oaHR0cHM6Ly9kZXZlbG9wZXJzLmdvb2dsZS5jb20vZGlzY292ZXJ5L3YxL3JlZmVyZW5jZS9hcGlzKSBhcwogYHt2YXJ9YC4KCiBJZiBhIHZhcmlhYmxlIGNvbnRhaW5zIG11bHRpcGxlIHBhdGggc2VnbWVudHMsIHN1Y2ggYXMgYCJ7dmFyPWZvby8qfSJgCiBvciBgInt2YXI9Kip9ImAsIHdoZW4gc3VjaCBhIHZhcmlhYmxlIGlzIGV4cGFuZGVkIGludG8gYSBVUkwgcGF0aCBvbiB0aGUKIGNsaWVudCBzaWRlLCBhbGwgY2hhcmFjdGVycyBleGNlcHQgYFstXy5+LzAtOWEtekEtWl1gIGFyZSBwZXJjZW50LWVuY29kZWQuCiBUaGUgc2VydmVyIHNpZGUgZG9lcyB0aGUgcmV2ZXJzZSBkZWNvZGluZywgZXhjZXB0ICIlMkYiIGFuZCAiJTJmIiBhcmUgbGVmdAogdW5jaGFuZ2VkLiBTdWNoIHZhcmlhYmxlcyBzaG93IHVwIGluIHRoZQogW0Rpc2NvdmVyeQogRG9jdW1lbnRdKGh0dHBzOi8vZGV2ZWxvcGVycy5nb29nbGUuY29tL2Rpc2NvdmVyeS92MS9yZWZlcmVuY2UvYXBpcykgYXMKIGB7K3Zhcn1gLgoKICMjIFVzaW5nIGdSUEMgQVBJIFNlcnZpY2UgQ29uZmlndXJhdGlvbgoKIGdSUEMgQVBJIFNlcnZpY2UgQ29uZmlndXJhdGlvbiAoc2VydmljZSBjb25maWcpIGlzIGEgY29uZmlndXJhdGlvbiBsYW5ndWFnZQogZm9yIGNvbmZpZ3VyaW5nIGEgZ1JQQyBzZXJ2aWNlIHRvIGJlY29tZSBhIHVzZXItZmFjaW5nIHByb2R1Y3QuIFRoZQogc2VydmljZSBjb25maWcgaXMgc2ltcGx5IHRoZSBZQU1MIHJlcHJlc2VudGF0aW9uIG9mIHRoZSBgZ29vZ2xlLmFwaS5TZXJ2aWNlYAogcHJvdG8gbWVzc2FnZS4KCiBBcyBhbiBhbHRlcm5hdGl2ZSB0byBhbm5vdGF0aW5nIHlvdXIgcHJvdG8gZmlsZSwgeW91IGNhbiBjb25maWd1cmUgZ1JQQwogdHJhbnNjb2RpbmcgaW4geW91ciBzZXJ2aWNlIGNvbmZpZyBZQU1MIGZpbGVzLiBZb3UgZG8gdGhpcyBieSBzcGVjaWZ5aW5nIGEKIGBIdHRwUnVsZWAgdGhhdCBtYXBzIHRoZSBnUlBDIG1ldGhvZCB0byBhIFJFU1QgZW5kcG9pbnQsIGFjaGlldmluZyB0aGUgc2FtZQogZWZmZWN0IGFzIHRoZSBwcm90byBhbm5vdGF0aW9uLiBUaGlzIGNhbiBiZSBwYXJ0aWN1bGFybHkgdXNlZnVsIGlmIHlvdQogaGF2ZSBhIHByb3RvIHRoYXQgaXMgcmV1c2VkIGluIG11bHRpcGxlIHNlcnZpY2VzLiBOb3RlIHRoYXQgYW55IHRyYW5zY29kaW5nCiBzcGVjaWZpZWQgaW4gdGhlIHNlcnZpY2UgY29uZmlnIHdpbGwgb3ZlcnJpZGUgYW55IG1hdGNoaW5nIHRyYW5zY29kaW5nCiBjb25maWd1cmF0aW9uIGluIHRoZSBwcm90by4KCiBFeGFtcGxlOgoKICAgICBodHRwOgogICAgICAgcnVsZXM6CiAgICAgICAgICMgU2VsZWN0cyBhIGdSUEMgbWV0aG9kIGFuZCBhcHBsaWVzIEh0dHBSdWxlIHRvIGl0LgogICAgICAgICAtIHNlbGVjdG9yOiBleGFtcGxlLnYxLk1lc3NhZ2luZy5HZXRNZXNzYWdlCiAgICAgICAgICAgZ2V0OiAvdjEvbWVzc2FnZXMve21lc3NhZ2VfaWR9L3tzdWIuc3ViZmllbGR9CgogIyMgU3BlY2lhbCBub3RlcwoKIFdoZW4gZ1JQQyBUcmFuc2NvZGluZyBpcyB1c2VkIHRvIG1hcCBhIGdSUEMgdG8gSlNPTiBSRVNUIGVuZHBvaW50cywgdGhlCiBwcm90byB0byBKU09OIGNvbnZlcnNpb24gbXVzdCBmb2xsb3cgdGhlIFtwcm90bzMKIHNwZWNpZmljYXRpb25dKGh0dHBzOi8vZGV2ZWxvcGVycy5nb29nbGUuY29tL3Byb3RvY29sLWJ1ZmZlcnMvZG9jcy9wcm90bzMjanNvbikuCgogV2hpbGUgdGhlIHNpbmdsZSBzZWdtZW50IHZhcmlhYmxlIGZvbGxvd3MgdGhlIHNlbWFudGljcyBvZgogW1JGQyA2NTcwXShodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjU3MCkgU2VjdGlvbiAzLjIuMiBTaW1wbGUgU3RyaW5nCiBFeHBhbnNpb24sIHRoZSBtdWx0aSBzZWdtZW50IHZhcmlhYmxlICoqZG9lcyBub3QqKiBmb2xsb3cgUkZDIDY1NzAgU2VjdGlvbgogMy4yLjMgUmVzZXJ2ZWQgRXhwYW5zaW9uLiBUaGUgcmVhc29uIGlzIHRoYXQgdGhlIFJlc2VydmVkIEV4cGFuc2lvbgogZG9lcyBub3QgZXhwYW5kIHNwZWNpYWwgY2hhcmFjdGVycyBsaWtlIGA/YCBhbmQgYCNgLCB3aGljaCB3b3VsZCBsZWFkCiB0byBpbnZhbGlkIFVSTHMuIEFzIHRoZSByZXN1bHQsIGdSUEMgVHJhbnNjb2RpbmcgdXNlcyBhIGN1c3RvbSBlbmNvZGluZwogZm9yIG11bHRpIHNlZ21lbnQgdmFyaWFibGVzLgoKIFRoZSBwYXRoIHZhcmlhYmxlcyAqKm11c3Qgbm90KiogcmVmZXIgdG8gYW55IHJlcGVhdGVkIG9yIG1hcHBlZCBmaWVsZCwKIGJlY2F1c2UgY2xpZW50IGxpYnJhcmllcyBhcmUgbm90IGNhcGFibGUgb2YgaGFuZGxpbmcgc3VjaCB2YXJpYWJsZSBleHBhbnNpb24uCgogVGhlIHBhdGggdmFyaWFibGVzICoqbXVzdCBub3QqKiBjYXB0dXJlIHRoZSBsZWFkaW5nICIvIiBjaGFyYWN0ZXIuIFRoZSByZWFzb24KIGlzIHRoYXQgdGhlIG1vc3QgY29tbW9uIHVzZSBjYXNlICJ7dmFyfSIgZG9lcyBub3QgY2FwdHVyZSB0aGUgbGVhZGluZyAiLyIKIGNoYXJhY3Rlci4gRm9yIGNvbnNpc3RlbmN5LCBhbGwgcGF0aCB2YXJpYWJsZXMgbXVzdCBzaGFyZSB0aGUgc2FtZSBiZWhhdmlvci4KCiBSZXBlYXRlZCBtZXNzYWdlIGZpZWxkcyBtdXN0IG5vdCBiZSBtYXBwZWQgdG8gVVJMIHF1ZXJ5IHBhcmFtZXRlcnMsIGJlY2F1c2UKIG5vIGNsaWVudCBsaWJyYXJ5IGNhbiBzdXBwb3J0IHN1Y2ggY29tcGxpY2F0ZWQgbWFwcGluZy4KCiBJZiBhbiBBUEkgbmVlZHMgdG8gdXNlIGEgSlNPTiBhcnJheSBmb3IgcmVxdWVzdCBvciByZXNwb25zZSBib2R5LCBpdCBjYW4gbWFwCiB0aGUgcmVxdWVzdCBvciByZXNwb25zZSBib2R5IHRvIGEgcmVwZWF0ZWQgZmllbGQuIEhvd2V2ZXIsIHNvbWUgZ1JQQwogVHJhbnNjb2RpbmcgaW1wbGVtZW50YXRpb25zIG1heSBub3Qgc3VwcG9ydCB0aGlzIGZlYXR1cmUuCgoLCgMEAQESBLsCCBAKjwEKBAQBAgASBMACAhYagAEgU2VsZWN0cyBhIG1ldGhvZCB0byB3aGljaCB0aGlzIHJ1bGUgYXBwbGllcy4KCiBSZWZlciB0byBbc2VsZWN0b3JdW2dvb2dsZS5hcGkuRG9jdW1lbnRhdGlvblJ1bGUuc2VsZWN0b3JdIGZvciBzeW50YXgKIGRldGFpbHMuCgoNCgUEAQIABRIEwAICCAoNCgUEAQIAARIEwAIJEQoNCgUEAQIAAxIEwAIUFQrQAQoEBAEIABIGxQIC2wIDGr8BIERldGVybWluZXMgdGhlIFVSTCBwYXR0ZXJuIGlzIG1hdGNoZWQgYnkgdGhpcyBydWxlcy4gVGhpcyBwYXR0ZXJuIGNhbiBiZQogdXNlZCB3aXRoIGFueSBvZiB0aGUge2dldHxwdXR8cG9zdHxkZWxldGV8cGF0Y2h9IG1ldGhvZHMuIEEgY3VzdG9tIG1ldGhvZAogY2FuIGJlIGRlZmluZWQgdXNpbmcgdGhlICdjdXN0b20nIGZpZWxkLgoKDQoFBAEIAAESBMUCCA8KXAoEBAECARIEyAIEExpOIE1hcHMgdG8gSFRUUCBHRVQuIFVzZWQgZm9yIGxpc3RpbmcgYW5kIGdldHRpbmcgaW5mb3JtYXRpb24gYWJvdXQKIHJlc291cmNlcy4KCg0KBQQBAgEFEgTIAgQKCg0KBQQBAgEBEgTIAgsOCg0KBQQBAgEDEgTIAhESCkAKBAQBAgISBMsCBBMaMiBNYXBzIHRvIEhUVFAgUFVULiBVc2VkIGZvciByZXBsYWNpbmcgYSByZXNvdXJjZS4KCg0KBQQBAgIFEgTLAgQKCg0KBQQBAgIBEgTLAgsOCg0KBQQBAgIDEgTLAhESClgKBAQBAgMSBM4CBBQaSiBNYXBzIHRvIEhUVFAgUE9TVC4gVXNlZCBmb3IgY3JlYXRpbmcgYSByZXNvdXJjZSBvciBwZXJmb3JtaW5nIGFuIGFjdGlvbi4KCg0KBQQBAgMFEgTOAgQKCg0KBQQBAgMBEgTOAgsPCg0KBQQBAgMDEgTOAhITCkIKBAQBAgQSBNECBBYaNCBNYXBzIHRvIEhUVFAgREVMRVRFLiBVc2VkIGZvciBkZWxldGluZyBhIHJlc291cmNlLgoKDQoFBAECBAUSBNECBAoKDQoFBAECBAESBNECCxEKDQoFBAECBAMSBNECFBUKQQoEBAECBRIE1AIEFRozIE1hcHMgdG8gSFRUUCBQQVRDSC4gVXNlZCBmb3IgdXBkYXRpbmcgYSByZXNvdXJjZS4KCg0KBQQBAgUFEgTUAgQKCg0KBQQBAgUBEgTUAgsQCg0KBQQBAgUDEgTUAhMUCpgCCgQEAQIGEgTaAgQhGokCIFRoZSBjdXN0b20gcGF0dGVybiBpcyB1c2VkIGZvciBzcGVjaWZ5aW5nIGFuIEhUVFAgbWV0aG9kIHRoYXQgaXMgbm90CiBpbmNsdWRlZCBpbiB0aGUgYHBhdHRlcm5gIGZpZWxkLCBzdWNoIGFzIEhFQUQsIG9yICIqIiB0byBsZWF2ZSB0aGUKIEhUVFAgbWV0aG9kIHVuc3BlY2lmaWVkIGZvciB0aGlzIHJ1bGUuIFRoZSB3aWxkLWNhcmQgcnVsZSBpcyB1c2VmdWwKIGZvciBzZXJ2aWNlcyB0aGF0IHByb3ZpZGUgY29udGVudCB0byBXZWIgKEhUTUwpIGNsaWVudHMuCgoNCgUEAQIGBhIE2gIEFQoNCgUEAQIGARIE2gIWHAoNCgUEAQIGAxIE2gIfIArEAgoEBAECBxIE4wICEhq1AiBUaGUgbmFtZSBvZiB0aGUgcmVxdWVzdCBmaWVsZCB3aG9zZSB2YWx1ZSBpcyBtYXBwZWQgdG8gdGhlIEhUVFAgcmVxdWVzdAogYm9keSwgb3IgYCpgIGZvciBtYXBwaW5nIGFsbCByZXF1ZXN0IGZpZWxkcyBub3QgY2FwdHVyZWQgYnkgdGhlIHBhdGgKIHBhdHRlcm4gdG8gdGhlIEhUVFAgYm9keSwgb3Igb21pdHRlZCBmb3Igbm90IGhhdmluZyBhbnkgSFRUUCByZXF1ZXN0IGJvZHkuCgogTk9URTogdGhlIHJlZmVycmVkIGZpZWxkIG11c3QgYmUgcHJlc2VudCBhdCB0aGUgdG9wLWxldmVsIG9mIHRoZSByZXF1ZXN0CiBtZXNzYWdlIHR5cGUuCgoNCgUEAQIHBRIE4wICCAoNCgUEAQIHARIE4wIJDQoNCgUEAQIHAxIE4wIQEQqZAgoEBAECCBIE6wICHBqKAiBPcHRpb25hbC4gVGhlIG5hbWUgb2YgdGhlIHJlc3BvbnNlIGZpZWxkIHdob3NlIHZhbHVlIGlzIG1hcHBlZCB0byB0aGUgSFRUUAogcmVzcG9uc2UgYm9keS4gV2hlbiBvbWl0dGVkLCB0aGUgZW50aXJlIHJlc3BvbnNlIG1lc3NhZ2Ugd2lsbCBiZSB1c2VkCiBhcyB0aGUgSFRUUCByZXNwb25zZSBib2R5LgoKIE5PVEU6IFRoZSByZWZlcnJlZCBmaWVsZCBtdXN0IGJlIHByZXNlbnQgYXQgdGhlIHRvcC1sZXZlbCBvZiB0aGUgcmVzcG9uc2UKIG1lc3NhZ2UgdHlwZS4KCg0KBQQBAggFEgTrAgIICg0KBQQBAggBEgTrAgkWCg0KBQQBAggDEgTrAhkbCrsBCgQEAQIJEgTwAgItGqwBIEFkZGl0aW9uYWwgSFRUUCBiaW5kaW5ncyBmb3IgdGhlIHNlbGVjdG9yLiBOZXN0ZWQgYmluZGluZ3MgbXVzdAogbm90IGNvbnRhaW4gYW4gYGFkZGl0aW9uYWxfYmluZGluZ3NgIGZpZWxkIHRoZW1zZWx2ZXMgKHRoYXQgaXMsCiB0aGUgbmVzdGluZyBtYXkgb25seSBiZSBvbmUgbGV2ZWwgZGVlcCkuCgoNCgUEAQIJBBIE8AICCgoNCgUEAQIJBhIE8AILEwoNCgUEAQIJARIE8AIUJwoNCgUEAQIJAxIE8AIqLApHCgIEAhIG9AIA+gIBGjkgQSBjdXN0b20gcGF0dGVybiBpcyB1c2VkIGZvciBkZWZpbmluZyBjdXN0b20gSFRUUCB2ZXJiLgoKCwoDBAIBEgT0AggZCjIKBAQCAgASBPYCAhIaJCBUaGUgbmFtZSBvZiB0aGlzIGN1c3RvbSBIVFRQIHZlcmIuCgoNCgUEAgIABRIE9gICCAoNCgUEAgIAARIE9gIJDQoNCgUEAgIAAxIE9gIQEQo1CgQEAgIBEgT5AgISGicgVGhlIHBhdGggbWF0Y2hlZCBieSB0aGlzIGN1c3RvbSB2ZXJiLgoKDQoFBAICAQUSBPkCAggKDQoFBAICAQESBPkCCQ0KDQoFBAICAQMSBPkCEBFiBnByb3RvMwriwgMKIGdvb2dsZS9wcm90b2J1Zi9kZXNjcmlwdG9yLnByb3RvEg9nb29nbGUucHJvdG9idWYiTQoRRmlsZURlc2NyaXB0b3JTZXQSOAoEZmlsZRgBIAMoCzIkLmdvb2dsZS5wcm90b2J1Zi5GaWxlRGVzY3JpcHRvclByb3RvUgRmaWxlIv4EChNGaWxlRGVzY3JpcHRvclByb3RvEhIKBG5hbWUYASABKAlSBG5hbWUSGAoHcGFja2FnZRgCIAEoCVIHcGFja2FnZRIeCgpkZXBlbmRlbmN5GAMgAygJUgpkZXBlbmRlbmN5EisKEXB1YmxpY19kZXBlbmRlbmN5GAogAygFUhBwdWJsaWNEZXBlbmRlbmN5EicKD3dlYWtfZGVwZW5kZW5jeRgLIAMoBVIOd2Vha0RlcGVuZGVuY3kSQwoMbWVzc2FnZV90eXBlGAQgAygLMiAuZ29vZ2xlLnByb3RvYnVmLkRlc2NyaXB0b3JQcm90b1ILbWVzc2FnZVR5cGUSQQoJZW51bV90eXBlGAUgAygLMiQuZ29vZ2xlLnByb3RvYnVmLkVudW1EZXNjcmlwdG9yUHJvdG9SCGVudW1UeXBlEkEKB3NlcnZpY2UYBiADKAsyJy5nb29nbGUucHJvdG9idWYuU2VydmljZURlc2NyaXB0b3JQcm90b1IHc2VydmljZRJDCglleHRlbnNpb24YByADKAsyJS5nb29nbGUucHJvdG9idWYuRmllbGREZXNjcmlwdG9yUHJvdG9SCWV4dGVuc2lvbhI2CgdvcHRpb25zGAggASgLMhwuZ29vZ2xlLnByb3RvYnVmLkZpbGVPcHRpb25zUgdvcHRpb25zEkkKEHNvdXJjZV9jb2RlX2luZm8YCSABKAsyHy5nb29nbGUucHJvdG9idWYuU291cmNlQ29kZUluZm9SDnNvdXJjZUNvZGVJbmZvEhYKBnN5bnRheBgMIAEoCVIGc3ludGF4EhgKB2VkaXRpb24YDSABKAlSB2VkaXRpb24iuQYKD0Rlc2NyaXB0b3JQcm90bxISCgRuYW1lGAEgASgJUgRuYW1lEjsKBWZpZWxkGAIgAygLMiUuZ29vZ2xlLnByb3RvYnVmLkZpZWxkRGVzY3JpcHRvclByb3RvUgVmaWVsZBJDCglleHRlbnNpb24YBiADKAsyJS5nb29nbGUucHJvdG9idWYuRmllbGREZXNjcmlwdG9yUHJvdG9SCWV4dGVuc2lvbhJBCgtuZXN0ZWRfdHlwZRgDIAMoCzIgLmdvb2dsZS5wcm90b2J1Zi5EZXNjcmlwdG9yUHJvdG9SCm5lc3RlZFR5cGUSQQoJZW51bV90eXBlGAQgAygLMiQuZ29vZ2xlLnByb3RvYnVmLkVudW1EZXNjcmlwdG9yUHJvdG9SCGVudW1UeXBlElgKD2V4dGVuc2lvbl9yYW5nZRgFIAMoCzIvLmdvb2dsZS5wcm90b2J1Zi5EZXNjcmlwdG9yUHJvdG8uRXh0ZW5zaW9uUmFuZ2VSDmV4dGVuc2lvblJhbmdlEkQKCm9uZW9mX2RlY2wYCCADKAsyJS5nb29nbGUucHJvdG9idWYuT25lb2ZEZXNjcmlwdG9yUHJvdG9SCW9uZW9mRGVjbBI5CgdvcHRpb25zGAcgASgLMh8uZ29vZ2xlLnByb3RvYnVmLk1lc3NhZ2VPcHRpb25zUgdvcHRpb25zElUKDnJlc2VydmVkX3JhbmdlGAkgAygLMi4uZ29vZ2xlLnByb3RvYnVmLkRlc2NyaXB0b3JQcm90by5SZXNlcnZlZFJhbmdlUg1yZXNlcnZlZFJhbmdlEiMKDXJlc2VydmVkX25hbWUYCiADKAlSDHJlc2VydmVkTmFtZRp6Cg5FeHRlbnNpb25SYW5nZRIUCgVzdGFydBgBIAEoBVIFc3RhcnQSEAoDZW5kGAIgASgFUgNlbmQSQAoHb3B0aW9ucxgDIAEoCzImLmdvb2dsZS5wcm90b2J1Zi5FeHRlbnNpb25SYW5nZU9wdGlvbnNSB29wdGlvbnMaNwoNUmVzZXJ2ZWRSYW5nZRIUCgVzdGFydBgBIAEoBVIFc3RhcnQSEAoDZW5kGAIgASgFUgNlbmQirQQKFUV4dGVuc2lvblJhbmdlT3B0aW9ucxJYChR1bmludGVycHJldGVkX29wdGlvbhjnByADKAsyJC5nb29nbGUucHJvdG9idWYuVW5pbnRlcnByZXRlZE9wdGlvblITdW5pbnRlcnByZXRlZE9wdGlvbhJZCgtkZWNsYXJhdGlvbhgCIAMoCzIyLmdvb2dsZS5wcm90b2J1Zi5FeHRlbnNpb25SYW5nZU9wdGlvbnMuRGVjbGFyYXRpb25CA4gBAlILZGVjbGFyYXRpb24SaAoMdmVyaWZpY2F0aW9uGAMgASgOMjguZ29vZ2xlLnByb3RvYnVmLkV4dGVuc2lvblJhbmdlT3B0aW9ucy5WZXJpZmljYXRpb25TdGF0ZToKVU5WRVJJRklFRFIMdmVyaWZpY2F0aW9uGrMBCgtEZWNsYXJhdGlvbhIWCgZudW1iZXIYASABKAVSBm51bWJlchIbCglmdWxsX25hbWUYAiABKAlSCGZ1bGxOYW1lEhIKBHR5cGUYAyABKAlSBHR5cGUSIwoLaXNfcmVwZWF0ZWQYBCABKAhCAhgBUgppc1JlcGVhdGVkEhoKCHJlc2VydmVkGAUgASgIUghyZXNlcnZlZBIaCghyZXBlYXRlZBgGIAEoCFIIcmVwZWF0ZWQiNAoRVmVyaWZpY2F0aW9uU3RhdGUSDwoLREVDTEFSQVRJT04QABIOCgpVTlZFUklGSUVEEAEqCQjoBxCAgICAAiLBBgoURmllbGREZXNjcmlwdG9yUHJvdG8SEgoEbmFtZRgBIAEoCVIEbmFtZRIWCgZudW1iZXIYAyABKAVSBm51bWJlchJBCgVsYWJlbBgEIAEoDjIrLmdvb2dsZS5wcm90b2J1Zi5GaWVsZERlc2NyaXB0b3JQcm90by5MYWJlbFIFbGFiZWwSPgoEdHlwZRgFIAEoDjIqLmdvb2dsZS5wcm90b2J1Zi5GaWVsZERlc2NyaXB0b3JQcm90by5UeXBlUgR0eXBlEhsKCXR5cGVfbmFtZRgGIAEoCVIIdHlwZU5hbWUSGgoIZXh0ZW5kZWUYAiABKAlSCGV4dGVuZGVlEiMKDWRlZmF1bHRfdmFsdWUYByABKAlSDGRlZmF1bHRWYWx1ZRIfCgtvbmVvZl9pbmRleBgJIAEoBVIKb25lb2ZJbmRleBIbCglqc29uX25hbWUYCiABKAlSCGpzb25OYW1lEjcKB29wdGlvbnMYCCABKAsyHS5nb29nbGUucHJvdG9idWYuRmllbGRPcHRpb25zUgdvcHRpb25zEicKD3Byb3RvM19vcHRpb25hbBgRIAEoCFIOcHJvdG8zT3B0aW9uYWwitgIKBFR5cGUSDwoLVFlQRV9ET1VCTEUQARIOCgpUWVBFX0ZMT0FUEAISDgoKVFlQRV9JTlQ2NBADEg8KC1RZUEVfVUlOVDY0EAQSDgoKVFlQRV9JTlQzMhAFEhAKDFRZUEVfRklYRUQ2NBAGEhAKDFRZUEVfRklYRUQzMhAHEg0KCVRZUEVfQk9PTBAIEg8KC1RZUEVfU1RSSU5HEAkSDgoKVFlQRV9HUk9VUBAKEhAKDFRZUEVfTUVTU0FHRRALEg4KClRZUEVfQllURVMQDBIPCgtUWVBFX1VJTlQzMhANEg0KCVRZUEVfRU5VTRAOEhEKDVRZUEVfU0ZJWEVEMzIQDxIRCg1UWVBFX1NGSVhFRDY0EBASDwoLVFlQRV9TSU5UMzIQERIPCgtUWVBFX1NJTlQ2NBASIkMKBUxhYmVsEhIKDkxBQkVMX09QVElPTkFMEAESEgoOTEFCRUxfUkVRVUlSRUQQAhISCg5MQUJFTF9SRVBFQVRFRBADImMKFE9uZW9mRGVzY3JpcHRvclByb3RvEhIKBG5hbWUYASABKAlSBG5hbWUSNwoHb3B0aW9ucxgCIAEoCzIdLmdvb2dsZS5wcm90b2J1Zi5PbmVvZk9wdGlvbnNSB29wdGlvbnMi4wIKE0VudW1EZXNjcmlwdG9yUHJvdG8SEgoEbmFtZRgBIAEoCVIEbmFtZRI/CgV2YWx1ZRgCIAMoCzIpLmdvb2dsZS5wcm90b2J1Zi5FbnVtVmFsdWVEZXNjcmlwdG9yUHJvdG9SBXZhbHVlEjYKB29wdGlvbnMYAyABKAsyHC5nb29nbGUucHJvdG9idWYuRW51bU9wdGlvbnNSB29wdGlvbnMSXQoOcmVzZXJ2ZWRfcmFuZ2UYBCADKAsyNi5nb29nbGUucHJvdG9idWYuRW51bURlc2NyaXB0b3JQcm90by5FbnVtUmVzZXJ2ZWRSYW5nZVINcmVzZXJ2ZWRSYW5nZRIjCg1yZXNlcnZlZF9uYW1lGAUgAygJUgxyZXNlcnZlZE5hbWUaOwoRRW51bVJlc2VydmVkUmFuZ2USFAoFc3RhcnQYASABKAVSBXN0YXJ0EhAKA2VuZBgCIAEoBVIDZW5kIoMBChhFbnVtVmFsdWVEZXNjcmlwdG9yUHJvdG8SEgoEbmFtZRgBIAEoCVIEbmFtZRIWCgZudW1iZXIYAiABKAVSBm51bWJlchI7CgdvcHRpb25zGAMgASgLMiEuZ29vZ2xlLnByb3RvYnVmLkVudW1WYWx1ZU9wdGlvbnNSB29wdGlvbnMipwEKFlNlcnZpY2VEZXNjcmlwdG9yUHJvdG8SEgoEbmFtZRgBIAEoCVIEbmFtZRI+CgZtZXRob2QYAiADKAsyJi5nb29nbGUucHJvdG9idWYuTWV0aG9kRGVzY3JpcHRvclByb3RvUgZtZXRob2QSOQoHb3B0aW9ucxgDIAEoCzIfLmdvb2dsZS5wcm90b2J1Zi5TZXJ2aWNlT3B0aW9uc1IHb3B0aW9ucyKJAgoVTWV0aG9kRGVzY3JpcHRvclByb3RvEhIKBG5hbWUYASABKAlSBG5hbWUSHQoKaW5wdXRfdHlwZRgCIAEoCVIJaW5wdXRUeXBlEh8KC291dHB1dF90eXBlGAMgASgJUgpvdXRwdXRUeXBlEjgKB29wdGlvbnMYBCABKAsyHi5nb29nbGUucHJvdG9idWYuTWV0aG9kT3B0aW9uc1IHb3B0aW9ucxIwChBjbGllbnRfc3RyZWFtaW5nGAUgASgIOgVmYWxzZVIPY2xpZW50U3RyZWFtaW5nEjAKEHNlcnZlcl9zdHJlYW1pbmcYBiABKAg6BWZhbHNlUg9zZXJ2ZXJTdHJlYW1pbmcikQkKC0ZpbGVPcHRpb25zEiEKDGphdmFfcGFja2FnZRgBIAEoCVILamF2YVBhY2thZ2USMAoUamF2YV9vdXRlcl9jbGFzc25hbWUYCCABKAlSEmphdmFPdXRlckNsYXNzbmFtZRI1ChNqYXZhX211bHRpcGxlX2ZpbGVzGAogASgIOgVmYWxzZVIRamF2YU11bHRpcGxlRmlsZXMSRAodamF2YV9nZW5lcmF0ZV9lcXVhbHNfYW5kX2hhc2gYFCABKAhCAhgBUhlqYXZhR2VuZXJhdGVFcXVhbHNBbmRIYXNoEjoKFmphdmFfc3RyaW5nX2NoZWNrX3V0ZjgYGyABKAg6BWZhbHNlUhNqYXZhU3RyaW5nQ2hlY2tVdGY4ElMKDG9wdGltaXplX2ZvchgJIAEoDjIpLmdvb2dsZS5wcm90b2J1Zi5GaWxlT3B0aW9ucy5PcHRpbWl6ZU1vZGU6BVNQRUVEUgtvcHRpbWl6ZUZvchIdCgpnb19wYWNrYWdlGAsgASgJUglnb1BhY2thZ2USNQoTY2NfZ2VuZXJpY19zZXJ2aWNlcxgQIAEoCDoFZmFsc2VSEWNjR2VuZXJpY1NlcnZpY2VzEjkKFWphdmFfZ2VuZXJpY19zZXJ2aWNlcxgRIAEoCDoFZmFsc2VSE2phdmFHZW5lcmljU2VydmljZXMSNQoTcHlfZ2VuZXJpY19zZXJ2aWNlcxgSIAEoCDoFZmFsc2VSEXB5R2VuZXJpY1NlcnZpY2VzEjcKFHBocF9nZW5lcmljX3NlcnZpY2VzGCogASgIOgVmYWxzZVIScGhwR2VuZXJpY1NlcnZpY2VzEiUKCmRlcHJlY2F0ZWQYFyABKAg6BWZhbHNlUgpkZXByZWNhdGVkEi4KEGNjX2VuYWJsZV9hcmVuYXMYHyABKAg6BHRydWVSDmNjRW5hYmxlQXJlbmFzEioKEW9iamNfY2xhc3NfcHJlZml4GCQgASgJUg9vYmpjQ2xhc3NQcmVmaXgSKQoQY3NoYXJwX25hbWVzcGFjZRglIAEoCVIPY3NoYXJwTmFtZXNwYWNlEiEKDHN3aWZ0X3ByZWZpeBgnIAEoCVILc3dpZnRQcmVmaXgSKAoQcGhwX2NsYXNzX3ByZWZpeBgoIAEoCVIOcGhwQ2xhc3NQcmVmaXgSIwoNcGhwX25hbWVzcGFjZRgpIAEoCVIMcGhwTmFtZXNwYWNlEjQKFnBocF9tZXRhZGF0YV9uYW1lc3BhY2UYLCABKAlSFHBocE1ldGFkYXRhTmFtZXNwYWNlEiEKDHJ1YnlfcGFja2FnZRgtIAEoCVILcnVieVBhY2thZ2USWAoUdW5pbnRlcnByZXRlZF9vcHRpb24Y5wcgAygLMiQuZ29vZ2xlLnByb3RvYnVmLlVuaW50ZXJwcmV0ZWRPcHRpb25SE3VuaW50ZXJwcmV0ZWRPcHRpb24iOgoMT3B0aW1pemVNb2RlEgkKBVNQRUVEEAESDQoJQ09ERV9TSVpFEAISEAoMTElURV9SVU5USU1FEAMqCQjoBxCAgICAAkoECCYQJyK7AwoOTWVzc2FnZU9wdGlvbnMSPAoXbWVzc2FnZV9zZXRfd2lyZV9mb3JtYXQYASABKAg6BWZhbHNlUhRtZXNzYWdlU2V0V2lyZUZvcm1hdBJMCh9ub19zdGFuZGFyZF9kZXNjcmlwdG9yX2FjY2Vzc29yGAIgASgIOgVmYWxzZVIcbm9TdGFuZGFyZERlc2NyaXB0b3JBY2Nlc3NvchIlCgpkZXByZWNhdGVkGAMgASgIOgVmYWxzZVIKZGVwcmVjYXRlZBIbCgltYXBfZW50cnkYByABKAhSCG1hcEVudHJ5ElYKJmRlcHJlY2F0ZWRfbGVnYWN5X2pzb25fZmllbGRfY29uZmxpY3RzGAsgASgIQgIYAVIiZGVwcmVjYXRlZExlZ2FjeUpzb25GaWVsZENvbmZsaWN0cxJYChR1bmludGVycHJldGVkX29wdGlvbhjnByADKAsyJC5nb29nbGUucHJvdG9idWYuVW5pbnRlcnByZXRlZE9wdGlvblITdW5pbnRlcnByZXRlZE9wdGlvbioJCOgHEICAgIACSgQIBBAFSgQIBRAGSgQIBhAHSgQICBAJSgQICRAKIoUJCgxGaWVsZE9wdGlvbnMSQQoFY3R5cGUYASABKA4yIy5nb29nbGUucHJvdG9idWYuRmllbGRPcHRpb25zLkNUeXBlOgZTVFJJTkdSBWN0eXBlEhYKBnBhY2tlZBgCIAEoCFIGcGFja2VkEkcKBmpzdHlwZRgGIAEoDjIkLmdvb2dsZS5wcm90b2J1Zi5GaWVsZE9wdGlvbnMuSlNUeXBlOglKU19OT1JNQUxSBmpzdHlwZRIZCgRsYXp5GAUgASgIOgVmYWxzZVIEbGF6eRIuCg91bnZlcmlmaWVkX2xhenkYDyABKAg6BWZhbHNlUg51bnZlcmlmaWVkTGF6eRIlCgpkZXByZWNhdGVkGAMgASgIOgVmYWxzZVIKZGVwcmVjYXRlZBIZCgR3ZWFrGAogASgIOgVmYWxzZVIEd2VhaxIoCgxkZWJ1Z19yZWRhY3QYECABKAg6BWZhbHNlUgtkZWJ1Z1JlZGFjdBJLCglyZXRlbnRpb24YESABKA4yLS5nb29nbGUucHJvdG9idWYuRmllbGRPcHRpb25zLk9wdGlvblJldGVudGlvblIJcmV0ZW50aW9uEkoKBnRhcmdldBgSIAEoDjIuLmdvb2dsZS5wcm90b2J1Zi5GaWVsZE9wdGlvbnMuT3B0aW9uVGFyZ2V0VHlwZUICGAFSBnRhcmdldBJICgd0YXJnZXRzGBMgAygOMi4uZ29vZ2xlLnByb3RvYnVmLkZpZWxkT3B0aW9ucy5PcHRpb25UYXJnZXRUeXBlUgd0YXJnZXRzElgKFHVuaW50ZXJwcmV0ZWRfb3B0aW9uGOcHIAMoCzIkLmdvb2dsZS5wcm90b2J1Zi5VbmludGVycHJldGVkT3B0aW9uUhN1bmludGVycHJldGVkT3B0aW9uIi8KBUNUeXBlEgoKBlNUUklORxAAEggKBENPUkQQARIQCgxTVFJJTkdfUElFQ0UQAiI1CgZKU1R5cGUSDQoJSlNfTk9STUFMEAASDQoJSlNfU1RSSU5HEAESDQoJSlNfTlVNQkVSEAIiVQoPT3B0aW9uUmV0ZW50aW9uEhUKEVJFVEVOVElPTl9VTktOT1dOEAASFQoRUkVURU5USU9OX1JVTlRJTUUQARIUChBSRVRFTlRJT05fU09VUkNFEAIijAIKEE9wdGlvblRhcmdldFR5cGUSFwoTVEFSR0VUX1RZUEVfVU5LTk9XThAAEhQKEFRBUkdFVF9UWVBFX0ZJTEUQARIfChtUQVJHRVRfVFlQRV9FWFRFTlNJT05fUkFOR0UQAhIXChNUQVJHRVRfVFlQRV9NRVNTQUdFEAMSFQoRVEFSR0VUX1RZUEVfRklFTEQQBBIVChFUQVJHRVRfVFlQRV9PTkVPRhAFEhQKEFRBUkdFVF9UWVBFX0VOVU0QBhIaChZUQVJHRVRfVFlQRV9FTlVNX0VOVFJZEAcSFwoTVEFSR0VUX1RZUEVfU0VSVklDRRAIEhYKElRBUkdFVF9UWVBFX01FVEhPRBAJKgkI6AcQgICAgAJKBAgEEAUicwoMT25lb2ZPcHRpb25zElgKFHVuaW50ZXJwcmV0ZWRfb3B0aW9uGOcHIAMoCzIkLmdvb2dsZS5wcm90b2J1Zi5VbmludGVycHJldGVkT3B0aW9uUhN1bmludGVycHJldGVkT3B0aW9uKgkI6AcQgICAgAIimAIKC0VudW1PcHRpb25zEh8KC2FsbG93X2FsaWFzGAIgASgIUgphbGxvd0FsaWFzEiUKCmRlcHJlY2F0ZWQYAyABKAg6BWZhbHNlUgpkZXByZWNhdGVkElYKJmRlcHJlY2F0ZWRfbGVnYWN5X2pzb25fZmllbGRfY29uZmxpY3RzGAYgASgIQgIYAVIiZGVwcmVjYXRlZExlZ2FjeUpzb25GaWVsZENvbmZsaWN0cxJYChR1bmludGVycHJldGVkX29wdGlvbhjnByADKAsyJC5nb29nbGUucHJvdG9idWYuVW5pbnRlcnByZXRlZE9wdGlvblITdW5pbnRlcnByZXRlZE9wdGlvbioJCOgHEICAgIACSgQIBRAGIp4BChBFbnVtVmFsdWVPcHRpb25zEiUKCmRlcHJlY2F0ZWQYASABKAg6BWZhbHNlUgpkZXByZWNhdGVkElgKFHVuaW50ZXJwcmV0ZWRfb3B0aW9uGOcHIAMoCzIkLmdvb2dsZS5wcm90b2J1Zi5VbmludGVycHJldGVkT3B0aW9uUhN1bmludGVycHJldGVkT3B0aW9uKgkI6AcQgICAgAIinAEKDlNlcnZpY2VPcHRpb25zEiUKCmRlcHJlY2F0ZWQYISABKAg6BWZhbHNlUgpkZXByZWNhdGVkElgKFHVuaW50ZXJwcmV0ZWRfb3B0aW9uGOcHIAMoCzIkLmdvb2dsZS5wcm90b2J1Zi5VbmludGVycHJldGVkT3B0aW9uUhN1bmludGVycHJldGVkT3B0aW9uKgkI6AcQgICAgAIi4AIKDU1ldGhvZE9wdGlvbnMSJQoKZGVwcmVjYXRlZBghIAEoCDoFZmFsc2VSCmRlcHJlY2F0ZWQScQoRaWRlbXBvdGVuY3lfbGV2ZWwYIiABKA4yLy5nb29nbGUucHJvdG9idWYuTWV0aG9kT3B0aW9ucy5JZGVtcG90ZW5jeUxldmVsOhNJREVNUE9URU5DWV9VTktOT1dOUhBpZGVtcG90ZW5jeUxldmVsElgKFHVuaW50ZXJwcmV0ZWRfb3B0aW9uGOcHIAMoCzIkLmdvb2dsZS5wcm90b2J1Zi5VbmludGVycHJldGVkT3B0aW9uUhN1bmludGVycHJldGVkT3B0aW9uIlAKEElkZW1wb3RlbmN5TGV2ZWwSFwoTSURFTVBPVEVOQ1lfVU5LTk9XThAAEhMKD05PX1NJREVfRUZGRUNUUxABEg4KCklERU1QT1RFTlQQAioJCOgHEICAgIACIpoDChNVbmludGVycHJldGVkT3B0aW9uEkEKBG5hbWUYAiADKAsyLS5nb29nbGUucHJvdG9idWYuVW5pbnRlcnByZXRlZE9wdGlvbi5OYW1lUGFydFIEbmFtZRIpChBpZGVudGlmaWVyX3ZhbHVlGAMgASgJUg9pZGVudGlmaWVyVmFsdWUSLAoScG9zaXRpdmVfaW50X3ZhbHVlGAQgASgEUhBwb3NpdGl2ZUludFZhbHVlEiwKEm5lZ2F0aXZlX2ludF92YWx1ZRgFIAEoA1IQbmVnYXRpdmVJbnRWYWx1ZRIhCgxkb3VibGVfdmFsdWUYBiABKAFSC2RvdWJsZVZhbHVlEiEKDHN0cmluZ192YWx1ZRgHIAEoDFILc3RyaW5nVmFsdWUSJwoPYWdncmVnYXRlX3ZhbHVlGAggASgJUg5hZ2dyZWdhdGVWYWx1ZRpKCghOYW1lUGFydBIbCgluYW1lX3BhcnQYASACKAlSCG5hbWVQYXJ0EiEKDGlzX2V4dGVuc2lvbhgCIAIoCFILaXNFeHRlbnNpb24ipwIKDlNvdXJjZUNvZGVJbmZvEkQKCGxvY2F0aW9uGAEgAygLMiguZ29vZ2xlLnByb3RvYnVmLlNvdXJjZUNvZGVJbmZvLkxvY2F0aW9uUghsb2NhdGlvbhrOAQoITG9jYXRpb24SFgoEcGF0aBgBIAMoBUICEAFSBHBhdGgSFgoEc3BhbhgCIAMoBUICEAFSBHNwYW4SKQoQbGVhZGluZ19jb21tZW50cxgDIAEoCVIPbGVhZGluZ0NvbW1lbnRzEisKEXRyYWlsaW5nX2NvbW1lbnRzGAQgASgJUhB0cmFpbGluZ0NvbW1lbnRzEjoKGWxlYWRpbmdfZGV0YWNoZWRfY29tbWVudHMYBiADKAlSF2xlYWRpbmdEZXRhY2hlZENvbW1lbnRzItACChFHZW5lcmF0ZWRDb2RlSW5mbxJNCgphbm5vdGF0aW9uGAEgAygLMi0uZ29vZ2xlLnByb3RvYnVmLkdlbmVyYXRlZENvZGVJbmZvLkFubm90YXRpb25SCmFubm90YXRpb24a6wEKCkFubm90YXRpb24SFgoEcGF0aBgBIAMoBUICEAFSBHBhdGgSHwoLc291cmNlX2ZpbGUYAiABKAlSCnNvdXJjZUZpbGUSFAoFYmVnaW4YAyABKAVSBWJlZ2luEhAKA2VuZBgEIAEoBVIDZW5kElIKCHNlbWFudGljGAUgASgOMjYuZ29vZ2xlLnByb3RvYnVmLkdlbmVyYXRlZENvZGVJbmZvLkFubm90YXRpb24uU2VtYW50aWNSCHNlbWFudGljIigKCFNlbWFudGljEggKBE5PTkUQABIHCgNTRVQQARIJCgVBTElBUxACQn4KE2NvbS5nb29nbGUucHJvdG9idWZCEERlc2NyaXB0b3JQcm90b3NIAVotZ29vZ2xlLmdvbGFuZy5vcmcvcHJvdG9idWYvdHlwZXMvZGVzY3JpcHRvcnBi+AEBogIDR1BCqgIaR29vZ2xlLlByb3RvYnVmLlJlZmxlY3Rpb25K/fsCCgcSBSYAgwgBCqoPCgEMEgMmABIywQwgUHJvdG9jb2wgQnVmZmVycyAtIEdvb2dsZSdzIGRhdGEgaW50ZXJjaGFuZ2UgZm9ybWF0CiBDb3B5cmlnaHQgMjAwOCBHb29nbGUgSW5jLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4KIGh0dHBzOi8vZGV2ZWxvcGVycy5nb29nbGUuY29tL3Byb3RvY29sLWJ1ZmZlcnMvCgogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0CiBtb2RpZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMgYXJlCiBtZXQ6CgogICAgICogUmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWluIHRoZSBhYm92ZSBjb3B5cmlnaHQKIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4KICAgICAqIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUKIGNvcHlyaWdodCBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIKIGluIHRoZSBkb2N1bWVudGF0aW9uIGFuZC9vciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUKIGRpc3RyaWJ1dGlvbi4KICAgICAqIE5laXRoZXIgdGhlIG5hbWUgb2YgR29vZ2xlIEluYy4gbm9yIHRoZSBuYW1lcyBvZiBpdHMKIGNvbnRyaWJ1dG9ycyBtYXkgYmUgdXNlZCB0byBlbmRvcnNlIG9yIHByb21vdGUgcHJvZHVjdHMgZGVyaXZlZCBmcm9tCiB0aGlzIHNvZnR3YXJlIHdpdGhvdXQgc3BlY2lmaWMgcHJpb3Igd3JpdHRlbiBwZXJtaXNzaW9uLgoKIFRISVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkgVEhFIENPUFlSSUdIVCBIT0xERVJTIEFORCBDT05UUklCVVRPUlMKICJBUyBJUyIgQU5EIEFOWSBFWFBSRVNTIE9SIElNUExJRUQgV0FSUkFOVElFUywgSU5DTFVESU5HLCBCVVQgTk9UCiBMSU1JVEVEIFRPLCBUSEUgSU1QTElFRCBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IKIEEgUEFSVElDVUxBUiBQVVJQT1NFIEFSRSBESVNDTEFJTUVELiBJTiBOTyBFVkVOVCBTSEFMTCBUSEUgQ09QWVJJR0hUCiBPV05FUiBPUiBDT05UUklCVVRPUlMgQkUgTElBQkxFIEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwKIFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IgQ09OU0VRVUVOVElBTCBEQU1BR0VTIChJTkNMVURJTkcsIEJVVCBOT1QKIExJTUlURUQgVE8sIFBST0NVUkVNRU5UIE9GIFNVQlNUSVRVVEUgR09PRFMgT1IgU0VSVklDRVM7IExPU1MgT0YgVVNFLAogREFUQSwgT1IgUFJPRklUUzsgT1IgQlVTSU5FU1MgSU5URVJSVVBUSU9OKSBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZCiBUSEVPUlkgT0YgTElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJQ1QgTElBQklMSVRZLCBPUiBUT1JUCiAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBBUklTSU5HIElOIEFOWSBXQVkgT1VUIE9GIFRIRSBVU0UKIE9GIFRISVMgU09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YgU1VDSCBEQU1BR0UuCjLbAiBBdXRob3I6IGtlbnRvbkBnb29nbGUuY29tIChLZW50b24gVmFyZGEpCiAgQmFzZWQgb24gb3JpZ2luYWwgUHJvdG9jb2wgQnVmZmVycyBkZXNpZ24gYnkKICBTYW5qYXkgR2hlbWF3YXQsIEplZmYgRGVhbiwgYW5kIG90aGVycy4KCiBUaGUgbWVzc2FnZXMgaW4gdGhpcyBmaWxlIGRlc2NyaWJlIHRoZSBkZWZpbml0aW9ucyBmb3VuZCBpbiAucHJvdG8gZmlsZXMuCiBBIHZhbGlkIC5wcm90byBmaWxlIGNhbiBiZSB0cmFuc2xhdGVkIGRpcmVjdGx5IHRvIGEgRmlsZURlc2NyaXB0b3JQcm90bwogd2l0aG91dCBhbnkgb3RoZXIgaW5mb3JtYXRpb24gKGUuZy4gd2l0aG91dCByZWFkaW5nIGl0cyBpbXBvcnRzKS4KCggKAQISAygAGAoICgEIEgMqAEQKCQoCCAsSAyoARAoICgEIEgMrACwKCQoCCAESAysALAoICgEIEgMsADEKCQoCCAgSAywAMQoICgEIEgMtADcKCQoCCCUSAy0ANwoICgEIEgMuACEKCQoCCCQSAy4AIQoICgEIEgMvAB8KCQoCCB8SAy8AHwoICgEIEgMzABwKfwoCCAkSAzMAHBp0IGRlc2NyaXB0b3IucHJvdG8gbXVzdCBiZSBvcHRpbWl6ZWQgZm9yIHNwZWVkIGJlY2F1c2UgcmVmbGVjdGlvbi1iYXNlZAogYWxnb3JpdGhtcyBkb24ndCB3b3JrIGR1cmluZyBib290c3RyYXBwaW5nLgoKagoCBAASBDcAOQEaXiBUaGUgcHJvdG9jb2wgY29tcGlsZXIgY2FuIG91dHB1dCBhIEZpbGVEZXNjcmlwdG9yU2V0IGNvbnRhaW5pbmcgdGhlIC5wcm90bwogZmlsZXMgaXQgcGFyc2VzLgoKCgoDBAABEgM3CBkKCwoEBAACABIDOAIoCgwKBQQAAgAEEgM4AgoKDAoFBAACAAYSAzgLHgoMCgUEAAIAARIDOB8jCgwKBQQAAgADEgM4JicKLwoCBAESBDwAXgEaIyBEZXNjcmliZXMgYSBjb21wbGV0ZSAucHJvdG8gZmlsZS4KCgoKAwQBARIDPAgbCjkKBAQBAgASAz0CGyIsIGZpbGUgbmFtZSwgcmVsYXRpdmUgdG8gcm9vdCBvZiBzb3VyY2UgdHJlZQoKDAoFBAECAAQSAz0CCgoMCgUEAQIABRIDPQsRCgwKBQQBAgABEgM9EhYKDAoFBAECAAMSAz0ZGgoqCgQEAQIBEgM+Ah4iHSBlLmcuICJmb28iLCAiZm9vLmJhciIsIGV0Yy4KCgwKBQQBAgEEEgM+AgoKDAoFBAECAQUSAz4LEQoMCgUEAQIBARIDPhIZCgwKBQQBAgEDEgM+HB0KNAoEBAECAhIDQQIhGicgTmFtZXMgb2YgZmlsZXMgaW1wb3J0ZWQgYnkgdGhpcyBmaWxlLgoKDAoFBAECAgQSA0ECCgoMCgUEAQICBRIDQQsRCgwKBQQBAgIBEgNBEhwKDAoFBAECAgMSA0EfIApRCgQEAQIDEgNDAigaRCBJbmRleGVzIG9mIHRoZSBwdWJsaWMgaW1wb3J0ZWQgZmlsZXMgaW4gdGhlIGRlcGVuZGVuY3kgbGlzdCBhYm92ZS4KCgwKBQQBAgMEEgNDAgoKDAoFBAECAwUSA0MLEAoMCgUEAQIDARIDQxEiCgwKBQQBAgMDEgNDJScKegoEBAECBBIDRgImGm0gSW5kZXhlcyBvZiB0aGUgd2VhayBpbXBvcnRlZCBmaWxlcyBpbiB0aGUgZGVwZW5kZW5jeSBsaXN0LgogRm9yIEdvb2dsZS1pbnRlcm5hbCBtaWdyYXRpb24gb25seS4gRG8gbm90IHVzZS4KCgwKBQQBAgQEEgNGAgoKDAoFBAECBAUSA0YLEAoMCgUEAQIEARIDRhEgCgwKBQQBAgQDEgNGIyUKNgoEBAECBRIDSQIsGikgQWxsIHRvcC1sZXZlbCBkZWZpbml0aW9ucyBpbiB0aGlzIGZpbGUuCgoMCgUEAQIFBBIDSQIKCgwKBQQBAgUGEgNJCxoKDAoFBAECBQESA0kbJwoMCgUEAQIFAxIDSSorCgsKBAQBAgYSA0oCLQoMCgUEAQIGBBIDSgIKCgwKBQQBAgYGEgNKCx4KDAoFBAECBgESA0ofKAoMCgUEAQIGAxIDSissCgsKBAQBAgcSA0sCLgoMCgUEAQIHBBIDSwIKCgwKBQQBAgcGEgNLCyEKDAoFBAECBwESA0siKQoMCgUEAQIHAxIDSywtCgsKBAQBAggSA0wCLgoMCgUEAQIIBBIDTAIKCgwKBQQBAggGEgNMCx8KDAoFBAECCAESA0wgKQoMCgUEAQIIAxIDTCwtCgsKBAQBAgkSA04CIwoMCgUEAQIJBBIDTgIKCgwKBQQBAgkGEgNOCxYKDAoFBAECCQESA04XHgoMCgUEAQIJAxIDTiEiCvQBCgQEAQIKEgNUAi8a5gEgVGhpcyBmaWVsZCBjb250YWlucyBvcHRpb25hbCBpbmZvcm1hdGlvbiBhYm91dCB0aGUgb3JpZ2luYWwgc291cmNlIGNvZGUuCiBZb3UgbWF5IHNhZmVseSByZW1vdmUgdGhpcyBlbnRpcmUgZmllbGQgd2l0aG91dCBoYXJtaW5nIHJ1bnRpbWUKIGZ1bmN0aW9uYWxpdHkgb2YgdGhlIGRlc2NyaXB0b3JzIC0tIHRoZSBpbmZvcm1hdGlvbiBpcyBuZWVkZWQgb25seSBieQogZGV2ZWxvcG1lbnQgdG9vbHMuCgoMCgUEAQIKBBIDVAIKCgwKBQQBAgoGEgNUCxkKDAoFBAECCgESA1QaKgoMCgUEAQIKAxIDVC0uCqUBCgQEAQILEgNaAh4alwEgVGhlIHN5bnRheCBvZiB0aGUgcHJvdG8gZmlsZS4KIFRoZSBzdXBwb3J0ZWQgdmFsdWVzIGFyZSAicHJvdG8yIiwgInByb3RvMyIsIGFuZCAiZWRpdGlvbnMiLgoKIElmIGBlZGl0aW9uYCBpcyBwcmVzZW50LCB0aGlzIHZhbHVlIG11c3QgYmUgImVkaXRpb25zIi4KCgwKBQQBAgsEEgNaAgoKDAoFBAECCwUSA1oLEQoMCgUEAQILARIDWhIYCgwKBQQBAgsDEgNaGx0KSAoEBAECDBIDXQIfGjsgVGhlIGVkaXRpb24gb2YgdGhlIHByb3RvIGZpbGUsIHdoaWNoIGlzIGFuIG9wYXF1ZSBzdHJpbmcuCgoMCgUEAQIMBBIDXQIKCgwKBQQBAgwFEgNdCxEKDAoFBAECDAESA10SGQoMCgUEAQIMAxIDXRweCigKAgQCEgVhAIEBARobIERlc2NyaWJlcyBhIG1lc3NhZ2UgdHlwZS4KCgoKAwQCARIDYQgXCgsKBAQCAgASA2ICGwoMCgUEAgIABBIDYgIKCgwKBQQCAgAFEgNiCxEKDAoFBAICAAESA2ISFgoMCgUEAgIAAxIDYhkaCgsKBAQCAgESA2QCKgoMCgUEAgIBBBIDZAIKCgwKBQQCAgEGEgNkCx8KDAoFBAICAQESA2QgJQoMCgUEAgIBAxIDZCgpCgsKBAQCAgISA2UCLgoMCgUEAgICBBIDZQIKCgwKBQQCAgIGEgNlCx8KDAoFBAICAgESA2UgKQoMCgUEAgICAxIDZSwtCgsKBAQCAgMSA2cCKwoMCgUEAgIDBBIDZwIKCgwKBQQCAgMGEgNnCxoKDAoFBAICAwESA2cbJgoMCgUEAgIDAxIDZykqCgsKBAQCAgQSA2gCLQoMCgUEAgIEBBIDaAIKCgwKBQQCAgQGEgNoCx4KDAoFBAICBAESA2gfKAoMCgUEAgIEAxIDaCssCgwKBAQCAwASBGoCbwMKDAoFBAIDAAESA2oKGAobCgYEAgMAAgASA2sEHSIMIEluY2x1c2l2ZS4KCg4KBwQCAwACAAQSA2sEDAoOCgcEAgMAAgAFEgNrDRIKDgoHBAIDAAIAARIDaxMYCg4KBwQCAwACAAMSA2sbHAobCgYEAgMAAgESA2wEGyIMIEV4Y2x1c2l2ZS4KCg4KBwQCAwACAQQSA2wEDAoOCgcEAgMAAgEFEgNsDRIKDgoHBAIDAAIBARIDbBMWCg4KBwQCAwACAQMSA2wZGgoNCgYEAgMAAgISA24ELwoOCgcEAgMAAgIEEgNuBAwKDgoHBAIDAAICBhIDbg0iCg4KBwQCAwACAgESA24jKgoOCgcEAgMAAgIDEgNuLS4KCwoEBAICBRIDcAIuCgwKBQQCAgUEEgNwAgoKDAoFBAICBQYSA3ALGQoMCgUEAgIFARIDcBopCgwKBQQCAgUDEgNwLC0KCwoEBAICBhIDcgIvCgwKBQQCAgYEEgNyAgoKDAoFBAICBgYSA3ILHwoMCgUEAgIGARIDciAqCgwKBQQCAgYDEgNyLS4KCwoEBAICBxIDdAImCgwKBQQCAgcEEgN0AgoKDAoFBAICBwYSA3QLGQoMCgUEAgIHARIDdBohCgwKBQQCAgcDEgN0JCUKqgEKBAQCAwESBHkCfAMamwEgUmFuZ2Ugb2YgcmVzZXJ2ZWQgdGFnIG51bWJlcnMuIFJlc2VydmVkIHRhZyBudW1iZXJzIG1heSBub3QgYmUgdXNlZCBieQogZmllbGRzIG9yIGV4dGVuc2lvbiByYW5nZXMgaW4gdGhlIHNhbWUgbWVzc2FnZS4gUmVzZXJ2ZWQgcmFuZ2VzIG1heQogbm90IG92ZXJsYXAuCgoMCgUEAgMBARIDeQoXChsKBgQCAwECABIDegQdIgwgSW5jbHVzaXZlLgoKDgoHBAIDAQIABBIDegQMCg4KBwQCAwECAAUSA3oNEgoOCgcEAgMBAgABEgN6ExgKDgoHBAIDAQIAAxIDehscChsKBgQCAwECARIDewQbIgwgRXhjbHVzaXZlLgoKDgoHBAIDAQIBBBIDewQMCg4KBwQCAwECAQUSA3sNEgoOCgcEAgMBAgEBEgN7ExYKDgoHBAIDAQIBAxIDexkaCgsKBAQCAggSA30CLAoMCgUEAgIIBBIDfQIKCgwKBQQCAggGEgN9CxgKDAoFBAICCAESA30ZJwoMCgUEAgIIAxIDfSorCoMBCgQEAgIJEgSAAQIlGnUgUmVzZXJ2ZWQgZmllbGQgbmFtZXMsIHdoaWNoIG1heSBub3QgYmUgdXNlZCBieSBmaWVsZHMgaW4gdGhlIHNhbWUgbWVzc2FnZS4KIEEgZ2l2ZW4gbmFtZSBtYXkgb25seSBiZSByZXNlcnZlZCBvbmNlLgoKDQoFBAICCQQSBIABAgoKDQoFBAICCQUSBIABCxEKDQoFBAICCQESBIABEh8KDQoFBAICCQMSBIABIiQKDAoCBAMSBoMBALUBAQoLCgMEAwESBIMBCB0KTwoEBAMCABIEhQECOhpBIFRoZSBwYXJzZXIgc3RvcmVzIG9wdGlvbnMgaXQgZG9lc24ndCByZWNvZ25pemUgaGVyZS4gU2VlIGFib3ZlLgoKDQoFBAMCAAQSBIUBAgoKDQoFBAMCAAYSBIUBCx4KDQoFBAMCAAESBIUBHzMKDQoFBAMCAAMSBIUBNjkKDgoEBAMDABIGhwECnwEDCg0KBQQDAwABEgSHAQoVCksKBgQDAwACABIEiQEEHho7IFRoZSBleHRlbnNpb24gbnVtYmVyIGRlY2xhcmVkIHdpdGhpbiB0aGUgZXh0ZW5zaW9uIHJhbmdlLgoKDwoHBAMDAAIABBIEiQEEDAoPCgcEAwMAAgAFEgSJAQ0SCg8KBwQDAwACAAESBIkBExkKDwoHBAMDAAIAAxIEiQEcHQp6CgYEAwMAAgESBI0BBCIaaiBUaGUgZnVsbHktcXVhbGlmaWVkIG5hbWUgb2YgdGhlIGV4dGVuc2lvbiBmaWVsZC4gVGhlcmUgbXVzdCBiZSBhIGxlYWRpbmcKIGRvdCBpbiBmcm9udCBvZiB0aGUgZnVsbCBuYW1lLgoKDwoHBAMDAAIBBBIEjQEEDAoPCgcEAwMAAgEFEgSNAQ0TCg8KBwQDAwACAQESBI0BFB0KDwoHBAMDAAIBAxIEjQEgIQqhAQoGBAMDAAICEgSSAQQdGpABIFRoZSBmdWxseS1xdWFsaWZpZWQgdHlwZSBuYW1lIG9mIHRoZSBleHRlbnNpb24gZmllbGQuIFVubGlrZQogTWV0YWRhdGEudHlwZSwgRGVjbGFyYXRpb24udHlwZSBtdXN0IGhhdmUgYSBsZWFkaW5nIGRvdCBmb3IgbWVzc2FnZXMKIGFuZCBlbnVtcy4KCg8KBwQDAwACAgQSBJIBBAwKDwoHBAMDAAICBRIEkgENEwoPCgcEAwMAAgIBEgSSARQYCg8KBwQDAwACAgMSBJIBGxwKNAoGBAMDAAIDEgSVAQQ2GiQgRGVwcmVjYXRlZC4gUGxlYXNlIHVzZSAicmVwZWF0ZWQiLgoKDwoHBAMDAAIDBBIElQEEDAoPCgcEAwMAAgMFEgSVAQ0RCg8KBwQDAwACAwESBJUBEh0KDwoHBAMDAAIDAxIElQEgIQoPCgcEAwMAAgMIEgSVASI1ChAKCAQDAwACAwgDEgSVASM0Cs4BCgYEAwMAAgQSBJoBBB8avQEgSWYgdHJ1ZSwgaW5kaWNhdGVzIHRoYXQgdGhlIG51bWJlciBpcyByZXNlcnZlZCBpbiB0aGUgZXh0ZW5zaW9uIHJhbmdlLAogYW5kIGFueSBleHRlbnNpb24gZmllbGQgd2l0aCB0aGUgbnVtYmVyIHdpbGwgZmFpbCB0byBjb21waWxlLiBTZXQgdGhpcwogd2hlbiBhIGRlY2xhcmVkIGV4dGVuc2lvbiBmaWVsZCBpcyBkZWxldGVkLgoKDwoHBAMDAAIEBBIEmgEEDAoPCgcEAwMAAgQFEgSaAQ0RCg8KBwQDAwACBAESBJoBEhoKDwoHBAMDAAIEAxIEmgEdHgqKAQoGBAMDAAIFEgSeAQQfGnogSWYgdHJ1ZSwgaW5kaWNhdGVzIHRoYXQgdGhlIGV4dGVuc2lvbiBtdXN0IGJlIGRlZmluZWQgYXMgcmVwZWF0ZWQuCiBPdGhlcndpc2UgdGhlIGV4dGVuc2lvbiBtdXN0IGJlIGRlZmluZWQgYXMgb3B0aW9uYWwuCgoPCgcEAwMAAgUEEgSeAQQMCg8KBwQDAwACBQUSBJ4BDREKDwoHBAMDAAIFARIEngESGgoPCgcEAwMAAgUDEgSeAR0eCoUCCgQEAwIBEgSlAQJGGvYBIGdvL3Byb3RvYnVmLXN0cmlwcGluZy1leHRlbnNpb24tZGVjbGFyYXRpb25zCiBMaWtlIE1ldGFkYXRhLCBidXQgd2UgdXNlIGEgcmVwZWF0ZWQgZmllbGQgdG8gaG9sZCBhbGwgZXh0ZW5zaW9uCiBkZWNsYXJhdGlvbnMuIFRoaXMgc2hvdWxkIGF2b2lkIHRoZSBzaXplIGluY3JlYXNlcyBvZiB0cmFuc2Zvcm1pbmcgYSBsYXJnZQogZXh0ZW5zaW9uIHJhbmdlIGludG8gc21hbGwgcmFuZ2VzIGluIGdlbmVyYXRlZCBiaW5hcmllcy4KCg0KBQQDAgEEEgSlAQIKCg0KBQQDAgEGEgSlAQsWCg0KBQQDAgEBEgSlARciCg0KBQQDAgEDEgSlASUmCg0KBQQDAgEIEgSlASdFCg4KBgQDAgEIERIEpQEoRApACgQEAwQAEgaoAQKsAQMaMCBUaGUgdmVyaWZpY2F0aW9uIHN0YXRlIG9mIHRoZSBleHRlbnNpb24gcmFuZ2UuCgoNCgUEAwQAARIEqAEHGApDCgYEAwQAAgASBKoBBBQaMyBBbGwgdGhlIGV4dGVuc2lvbnMgb2YgdGhlIHJhbmdlIG11c3QgYmUgZGVjbGFyZWQuCgoPCgcEAwQAAgABEgSqAQQPCg8KBwQDBAACAAISBKoBEhMKDgoGBAMEAAIBEgSrAQQTCg8KBwQDBAACAQESBKsBBA4KDwoHBAMEAAIBAhIEqwEREgqaAQoEBAMCAhIEsQECRRqLASBUaGUgdmVyaWZpY2F0aW9uIHN0YXRlIG9mIHRoZSByYW5nZS4KIFRPRE8oYi8yNzg3ODM3NTYpOiBmbGlwIHRoZSBkZWZhdWx0IHRvIERFQ0xBUkFUSU9OIG9uY2UgYWxsIGVtcHR5IHJhbmdlcwogYXJlIG1hcmtlZCBhcyBVTlZFUklGSUVELgoKDQoFBAMCAgQSBLEBAgoKDQoFBAMCAgYSBLEBCxwKDQoFBAMCAgESBLEBHSkKDQoFBAMCAgMSBLEBLC0KDQoFBAMCAggSBLEBLkQKDQoFBAMCAgcSBLEBOUMKWgoDBAMFEgS0AQIZGk0gQ2xpZW50cyBjYW4gZGVmaW5lIGN1c3RvbSBvcHRpb25zIGluIGV4dGVuc2lvbnMgb2YgdGhpcyBtZXNzYWdlLiBTZWUgYWJvdmUuCgoMCgQEAwUAEgS0AQ0YCg0KBQQDBQABEgS0AQ0RCg0KBQQDBQACEgS0ARUYCjMKAgQEEga4AQCcAgEaJSBEZXNjcmliZXMgYSBmaWVsZCB3aXRoaW4gYSBtZXNzYWdlLgoKCwoDBAQBEgS4AQgcCg4KBAQEBAASBrkBAtgBAwoNCgUEBAQAARIEuQEHCwpTCgYEBAQAAgASBLwBBBQaQyAwIGlzIHJlc2VydmVkIGZvciBlcnJvcnMuCiBPcmRlciBpcyB3ZWlyZCBmb3IgaGlzdG9yaWNhbCByZWFzb25zLgoKDwoHBAQEAAIAARIEvAEEDwoPCgcEBAQAAgACEgS8ARITCg4KBgQEBAACARIEvQEEEwoPCgcEBAQAAgEBEgS9AQQOCg8KBwQEBAACAQISBL0BERIKdwoGBAQEAAICEgTAAQQTGmcgTm90IFppZ1phZyBlbmNvZGVkLiAgTmVnYXRpdmUgbnVtYmVycyB0YWtlIDEwIGJ5dGVzLiAgVXNlIFRZUEVfU0lOVDY0IGlmCiBuZWdhdGl2ZSB2YWx1ZXMgYXJlIGxpa2VseS4KCg8KBwQEBAACAgESBMABBA4KDwoHBAQEAAICAhIEwAEREgoOCgYEBAQAAgMSBMEBBBQKDwoHBAQEAAIDARIEwQEEDwoPCgcEBAQAAgMCEgTBARITCncKBgQEBAACBBIExAEEExpnIE5vdCBaaWdaYWcgZW5jb2RlZC4gIE5lZ2F0aXZlIG51bWJlcnMgdGFrZSAxMCBieXRlcy4gIFVzZSBUWVBFX1NJTlQzMiBpZgogbmVnYXRpdmUgdmFsdWVzIGFyZSBsaWtlbHkuCgoPCgcEBAQAAgQBEgTEAQQOCg8KBwQEBAACBAISBMQBERIKDgoGBAQEAAIFEgTFAQQVCg8KBwQEBAACBQESBMUBBBAKDwoHBAQEAAIFAhIExQETFAoOCgYEBAQAAgYSBMYBBBUKDwoHBAQEAAIGARIExgEEEAoPCgcEBAQAAgYCEgTGARMUCg4KBgQEBAACBxIExwEEEgoPCgcEBAQAAgcBEgTHAQQNCg8KBwQEBAACBwISBMcBEBEKDgoGBAQEAAIIEgTIAQQUCg8KBwQEBAACCAESBMgBBA8KDwoHBAQEAAIIAhIEyAESEwriAQoGBAQEAAIJEgTNAQQUGtEBIFRhZy1kZWxpbWl0ZWQgYWdncmVnYXRlLgogR3JvdXAgdHlwZSBpcyBkZXByZWNhdGVkIGFuZCBub3Qgc3VwcG9ydGVkIGluIHByb3RvMy4gSG93ZXZlciwgUHJvdG8zCiBpbXBsZW1lbnRhdGlvbnMgc2hvdWxkIHN0aWxsIGJlIGFibGUgdG8gcGFyc2UgdGhlIGdyb3VwIHdpcmUgZm9ybWF0IGFuZAogdHJlYXQgZ3JvdXAgZmllbGRzIGFzIHVua25vd24gZmllbGRzLgoKDwoHBAQEAAIJARIEzQEEDgoPCgcEBAQAAgkCEgTNARETCi0KBgQEBAACChIEzgEEFiIdIExlbmd0aC1kZWxpbWl0ZWQgYWdncmVnYXRlLgoKDwoHBAQEAAIKARIEzgEEEAoPCgcEBAQAAgoCEgTOARMVCiMKBgQEBAACCxIE0QEEFBoTIE5ldyBpbiB2ZXJzaW9uIDIuCgoPCgcEBAQAAgsBEgTRAQQOCg8KBwQEBAACCwISBNEBERMKDgoGBAQEAAIMEgTSAQQVCg8KBwQEBAACDAESBNIBBA8KDwoHBAQEAAIMAhIE0gESFAoOCgYEBAQAAg0SBNMBBBMKDwoHBAQEAAINARIE0wEEDQoPCgcEBAQAAg0CEgTTARASCg4KBgQEBAACDhIE1AEEFwoPCgcEBAQAAg4BEgTUAQQRCg8KBwQEBAACDgISBNQBFBYKDgoGBAQEAAIPEgTVAQQXCg8KBwQEBAACDwESBNUBBBEKDwoHBAQEAAIPAhIE1QEUFgonCgYEBAQAAhASBNYBBBUiFyBVc2VzIFppZ1phZyBlbmNvZGluZy4KCg8KBwQEBAACEAESBNYBBA8KDwoHBAQEAAIQAhIE1gESFAonCgYEBAQAAhESBNcBBBUiFyBVc2VzIFppZ1phZyBlbmNvZGluZy4KCg8KBwQEBAACEQESBNcBBA8KDwoHBAQEAAIRAhIE1wESFAoOCgQEBAQBEgbaAQLfAQMKDQoFBAQEAQESBNoBBwwKKgoGBAQEAQIAEgTcAQQXGhogMCBpcyByZXNlcnZlZCBmb3IgZXJyb3JzCgoPCgcEBAQBAgABEgTcAQQSCg8KBwQEBAECAAISBNwBFRYKDgoGBAQEAQIBEgTdAQQXCg8KBwQEBAECAQESBN0BBBIKDwoHBAQEAQIBAhIE3QEVFgoOCgYEBAQBAgISBN4BBBcKDwoHBAQEAQICARIE3gEEEgoPCgcEBAQBAgICEgTeARUWCgwKBAQEAgASBOEBAhsKDQoFBAQCAAQSBOEBAgoKDQoFBAQCAAUSBOEBCxEKDQoFBAQCAAESBOEBEhYKDQoFBAQCAAMSBOEBGRoKDAoEBAQCARIE4gECHAoNCgUEBAIBBBIE4gECCgoNCgUEBAIBBRIE4gELEAoNCgUEBAIBARIE4gERFwoNCgUEBAIBAxIE4gEaGwoMCgQEBAICEgTjAQIbCg0KBQQEAgIEEgTjAQIKCg0KBQQEAgIGEgTjAQsQCg0KBQQEAgIBEgTjAREWCg0KBQQEAgIDEgTjARkaCpwBCgQEBAIDEgTnAQIZGo0BIElmIHR5cGVfbmFtZSBpcyBzZXQsIHRoaXMgbmVlZCBub3QgYmUgc2V0LiAgSWYgYm90aCB0aGlzIGFuZCB0eXBlX25hbWUKIGFyZSBzZXQsIHRoaXMgbXVzdCBiZSBvbmUgb2YgVFlQRV9FTlVNLCBUWVBFX01FU1NBR0Ugb3IgVFlQRV9HUk9VUC4KCg0KBQQEAgMEEgTnAQIKCg0KBQQEAgMGEgTnAQsPCg0KBQQEAgMBEgTnARAUCg0KBQQEAgMDEgTnARcYCrcCCgQEBAIEEgTuAQIgGqgCIEZvciBtZXNzYWdlIGFuZCBlbnVtIHR5cGVzLCB0aGlzIGlzIHRoZSBuYW1lIG9mIHRoZSB0eXBlLiAgSWYgdGhlIG5hbWUKIHN0YXJ0cyB3aXRoIGEgJy4nLCBpdCBpcyBmdWxseS1xdWFsaWZpZWQuICBPdGhlcndpc2UsIEMrKy1saWtlIHNjb3BpbmcKIHJ1bGVzIGFyZSB1c2VkIHRvIGZpbmQgdGhlIHR5cGUgKGkuZS4gZmlyc3QgdGhlIG5lc3RlZCB0eXBlcyB3aXRoaW4gdGhpcwogbWVzc2FnZSBhcmUgc2VhcmNoZWQsIHRoZW4gd2l0aGluIHRoZSBwYXJlbnQsIG9uIHVwIHRvIHRoZSByb290CiBuYW1lc3BhY2UpLgoKDQoFBAQCBAQSBO4BAgoKDQoFBAQCBAUSBO4BCxEKDQoFBAQCBAESBO4BEhsKDQoFBAQCBAMSBO4BHh8KfgoEBAQCBRIE8gECHxpwIEZvciBleHRlbnNpb25zLCB0aGlzIGlzIHRoZSBuYW1lIG9mIHRoZSB0eXBlIGJlaW5nIGV4dGVuZGVkLiAgSXQgaXMKIHJlc29sdmVkIGluIHRoZSBzYW1lIG1hbm5lciBhcyB0eXBlX25hbWUuCgoNCgUEBAIFBBIE8gECCgoNCgUEBAIFBRIE8gELEQoNCgUEBAIFARIE8gESGgoNCgUEBAIFAxIE8gEdHgqRAgoEBAQCBhIE+AECJBqCAiBGb3IgbnVtZXJpYyB0eXBlcywgY29udGFpbnMgdGhlIG9yaWdpbmFsIHRleHQgcmVwcmVzZW50YXRpb24gb2YgdGhlIHZhbHVlLgogRm9yIGJvb2xlYW5zLCAidHJ1ZSIgb3IgImZhbHNlIi4KIEZvciBzdHJpbmdzLCBjb250YWlucyB0aGUgZGVmYXVsdCB0ZXh0IGNvbnRlbnRzIChub3QgZXNjYXBlZCBpbiBhbnkgd2F5KS4KIEZvciBieXRlcywgY29udGFpbnMgdGhlIEMgZXNjYXBlZCB2YWx1ZS4gIEFsbCBieXRlcyA+PSAxMjggYXJlIGVzY2FwZWQuCgoNCgUEBAIGBBIE+AECCgoNCgUEBAIGBRIE+AELEQoNCgUEBAIGARIE+AESHwoNCgUEBAIGAxIE+AEiIwqEAQoEBAQCBxIE/AECIRp2IElmIHNldCwgZ2l2ZXMgdGhlIGluZGV4IG9mIGEgb25lb2YgaW4gdGhlIGNvbnRhaW5pbmcgdHlwZSdzIG9uZW9mX2RlY2wKIGxpc3QuICBUaGlzIGZpZWxkIGlzIGEgbWVtYmVyIG9mIHRoYXQgb25lb2YuCgoNCgUEBAIHBBIE/AECCgoNCgUEBAIHBRIE/AELEAoNCgUEBAIHARIE/AERHAoNCgUEBAIHAxIE/AEfIAr6AQoEBAQCCBIEggICIRrrASBKU09OIG5hbWUgb2YgdGhpcyBmaWVsZC4gVGhlIHZhbHVlIGlzIHNldCBieSBwcm90b2NvbCBjb21waWxlci4gSWYgdGhlCiB1c2VyIGhhcyBzZXQgYSAianNvbl9uYW1lIiBvcHRpb24gb24gdGhpcyBmaWVsZCwgdGhhdCBvcHRpb24ncyB2YWx1ZQogd2lsbCBiZSB1c2VkLiBPdGhlcndpc2UsIGl0J3MgZGVkdWNlZCBmcm9tIHRoZSBmaWVsZCdzIG5hbWUgYnkgY29udmVydGluZwogaXQgdG8gY2FtZWxDYXNlLgoKDQoFBAQCCAQSBIICAgoKDQoFBAQCCAUSBIICCxEKDQoFBAQCCAESBIICEhsKDQoFBAQCCAMSBIICHiAKDAoEBAQCCRIEhAICJAoNCgUEBAIJBBIEhAICCgoNCgUEBAIJBhIEhAILFwoNCgUEBAIJARIEhAIYHwoNCgUEBAIJAxIEhAIiIwqzCQoEBAQCChIEmwICJRqkCSBJZiB0cnVlLCB0aGlzIGlzIGEgcHJvdG8zICJvcHRpb25hbCIuIFdoZW4gYSBwcm90bzMgZmllbGQgaXMgb3B0aW9uYWwsIGl0CiB0cmFja3MgcHJlc2VuY2UgcmVnYXJkbGVzcyBvZiBmaWVsZCB0eXBlLgoKIFdoZW4gcHJvdG8zX29wdGlvbmFsIGlzIHRydWUsIHRoaXMgZmllbGQgbXVzdCBiZSBiZWxvbmcgdG8gYSBvbmVvZiB0bwogc2lnbmFsIHRvIG9sZCBwcm90bzMgY2xpZW50cyB0aGF0IHByZXNlbmNlIGlzIHRyYWNrZWQgZm9yIHRoaXMgZmllbGQuIFRoaXMKIG9uZW9mIGlzIGtub3duIGFzIGEgInN5bnRoZXRpYyIgb25lb2YsIGFuZCB0aGlzIGZpZWxkIG11c3QgYmUgaXRzIHNvbGUKIG1lbWJlciAoZWFjaCBwcm90bzMgb3B0aW9uYWwgZmllbGQgZ2V0cyBpdHMgb3duIHN5bnRoZXRpYyBvbmVvZikuIFN5bnRoZXRpYwogb25lb2ZzIGV4aXN0IGluIHRoZSBkZXNjcmlwdG9yIG9ubHksIGFuZCBkbyBub3QgZ2VuZXJhdGUgYW55IEFQSS4gU3ludGhldGljCiBvbmVvZnMgbXVzdCBiZSBvcmRlcmVkIGFmdGVyIGFsbCAicmVhbCIgb25lb2ZzLgoKIEZvciBtZXNzYWdlIGZpZWxkcywgcHJvdG8zX29wdGlvbmFsIGRvZXNuJ3QgY3JlYXRlIGFueSBzZW1hbnRpYyBjaGFuZ2UsCiBzaW5jZSBub24tcmVwZWF0ZWQgbWVzc2FnZSBmaWVsZHMgYWx3YXlzIHRyYWNrIHByZXNlbmNlLiBIb3dldmVyIGl0IHN0aWxsCiBpbmRpY2F0ZXMgdGhlIHNlbWFudGljIGRldGFpbCBvZiB3aGV0aGVyIHRoZSB1c2VyIHdyb3RlICJvcHRpb25hbCIgb3Igbm90LgogVGhpcyBjYW4gYmUgdXNlZnVsIGZvciByb3VuZC10cmlwcGluZyB0aGUgLnByb3RvIGZpbGUuIEZvciBjb25zaXN0ZW5jeSB3ZQogZ2l2ZSBtZXNzYWdlIGZpZWxkcyBhIHN5bnRoZXRpYyBvbmVvZiBhbHNvLCBldmVuIHRob3VnaCBpdCBpcyBub3QgcmVxdWlyZWQKIHRvIHRyYWNrIHByZXNlbmNlLiBUaGlzIGlzIGVzcGVjaWFsbHkgaW1wb3J0YW50IGJlY2F1c2UgdGhlIHBhcnNlciBjYW4ndAogdGVsbCBpZiBhIGZpZWxkIGlzIGEgbWVzc2FnZSBvciBhbiBlbnVtLCBzbyBpdCBtdXN0IGFsd2F5cyBjcmVhdGUgYQogc3ludGhldGljIG9uZW9mLgoKIFByb3RvMiBvcHRpb25hbCBmaWVsZHMgZG8gbm90IHNldCB0aGlzIGZsYWcsIGJlY2F1c2UgdGhleSBhbHJlYWR5IGluZGljYXRlCiBvcHRpb25hbCB3aXRoIGBMQUJFTF9PUFRJT05BTGAuCgoNCgUEBAIKBBIEmwICCgoNCgUEBAIKBRIEmwILDwoNCgUEBAIKARIEmwIQHwoNCgUEBAIKAxIEmwIiJAoiCgIEBRIGnwIAogIBGhQgRGVzY3JpYmVzIGEgb25lb2YuCgoLCgMEBQESBJ8CCBwKDAoEBAUCABIEoAICGwoNCgUEBQIABBIEoAICCgoNCgUEBQIABRIEoAILEQoNCgUEBQIAARIEoAISFgoNCgUEBQIAAxIEoAIZGgoMCgQEBQIBEgShAgIkCg0KBQQFAgEEEgShAgIKCg0KBQQFAgEGEgShAgsXCg0KBQQFAgEBEgShAhgfCg0KBQQFAgEDEgShAiIjCicKAgQGEgalAgC/AgEaGSBEZXNjcmliZXMgYW4gZW51bSB0eXBlLgoKCwoDBAYBEgSlAggbCgwKBAQGAgASBKYCAhsKDQoFBAYCAAQSBKYCAgoKDQoFBAYCAAUSBKYCCxEKDQoFBAYCAAESBKYCEhYKDQoFBAYCAAMSBKYCGRoKDAoEBAYCARIEqAICLgoNCgUEBgIBBBIEqAICCgoNCgUEBgIBBhIEqAILIwoNCgUEBgIBARIEqAIkKQoNCgUEBgIBAxIEqAIsLQoMCgQEBgICEgSqAgIjCg0KBQQGAgIEEgSqAgIKCg0KBQQGAgIGEgSqAgsWCg0KBQQGAgIBEgSqAhceCg0KBQQGAgIDEgSqAiEiCq8CCgQEBgMAEgayAgK1AgMangIgUmFuZ2Ugb2YgcmVzZXJ2ZWQgbnVtZXJpYyB2YWx1ZXMuIFJlc2VydmVkIHZhbHVlcyBtYXkgbm90IGJlIHVzZWQgYnkKIGVudHJpZXMgaW4gdGhlIHNhbWUgZW51bS4gUmVzZXJ2ZWQgcmFuZ2VzIG1heSBub3Qgb3ZlcmxhcC4KCiBOb3RlIHRoYXQgdGhpcyBpcyBkaXN0aW5jdCBmcm9tIERlc2NyaXB0b3JQcm90by5SZXNlcnZlZFJhbmdlIGluIHRoYXQgaXQKIGlzIGluY2x1c2l2ZSBzdWNoIHRoYXQgaXQgY2FuIGFwcHJvcHJpYXRlbHkgcmVwcmVzZW50IHRoZSBlbnRpcmUgaW50MzIKIGRvbWFpbi4KCg0KBQQGAwABEgSyAgobChwKBgQGAwACABIEswIEHSIMIEluY2x1c2l2ZS4KCg8KBwQGAwACAAQSBLMCBAwKDwoHBAYDAAIABRIEswINEgoPCgcEBgMAAgABEgSzAhMYCg8KBwQGAwACAAMSBLMCGxwKHAoGBAYDAAIBEgS0AgQbIgwgSW5jbHVzaXZlLgoKDwoHBAYDAAIBBBIEtAIEDAoPCgcEBgMAAgEFEgS0Ag0SCg8KBwQGAwACAQESBLQCExYKDwoHBAYDAAIBAxIEtAIZGgqqAQoEBAYCAxIEugICMBqbASBSYW5nZSBvZiByZXNlcnZlZCBudW1lcmljIHZhbHVlcy4gUmVzZXJ2ZWQgbnVtZXJpYyB2YWx1ZXMgbWF5IG5vdCBiZSB1c2VkCiBieSBlbnVtIHZhbHVlcyBpbiB0aGUgc2FtZSBlbnVtIGRlY2xhcmF0aW9uLiBSZXNlcnZlZCByYW5nZXMgbWF5IG5vdAogb3ZlcmxhcC4KCg0KBQQGAgMEEgS6AgIKCg0KBQQGAgMGEgS6AgscCg0KBQQGAgMBEgS6Ah0rCg0KBQQGAgMDEgS6Ai4vCmwKBAQGAgQSBL4CAiQaXiBSZXNlcnZlZCBlbnVtIHZhbHVlIG5hbWVzLCB3aGljaCBtYXkgbm90IGJlIHJldXNlZC4gQSBnaXZlbiBuYW1lIG1heSBvbmx5CiBiZSByZXNlcnZlZCBvbmNlLgoKDQoFBAYCBAQSBL4CAgoKDQoFBAYCBAUSBL4CCxEKDQoFBAYCBAESBL4CEh8KDQoFBAYCBAMSBL4CIiMKMQoCBAcSBsICAMcCARojIERlc2NyaWJlcyBhIHZhbHVlIHdpdGhpbiBhbiBlbnVtLgoKCwoDBAcBEgTCAgggCgwKBAQHAgASBMMCAhsKDQoFBAcCAAQSBMMCAgoKDQoFBAcCAAUSBMMCCxEKDQoFBAcCAAESBMMCEhYKDQoFBAcCAAMSBMMCGRoKDAoEBAcCARIExAICHAoNCgUEBwIBBBIExAICCgoNCgUEBwIBBRIExAILEAoNCgUEBwIBARIExAIRFwoNCgUEBwIBAxIExAIaGwoMCgQEBwICEgTGAgIoCg0KBQQHAgIEEgTGAgIKCg0KBQQHAgIGEgTGAgsbCg0KBQQHAgIBEgTGAhwjCg0KBQQHAgIDEgTGAiYnCiQKAgQIEgbKAgDPAgEaFiBEZXNjcmliZXMgYSBzZXJ2aWNlLgoKCwoDBAgBEgTKAggeCgwKBAQIAgASBMsCAhsKDQoFBAgCAAQSBMsCAgoKDQoFBAgCAAUSBMsCCxEKDQoFBAgCAAESBMsCEhYKDQoFBAgCAAMSBMsCGRoKDAoEBAgCARIEzAICLAoNCgUECAIBBBIEzAICCgoNCgUECAIBBhIEzAILIAoNCgUECAIBARIEzAIhJwoNCgUECAIBAxIEzAIqKwoMCgQECAICEgTOAgImCg0KBQQIAgIEEgTOAgIKCg0KBQQIAgIGEgTOAgsZCg0KBQQIAgIBEgTOAhohCg0KBQQIAgIDEgTOAiQlCjAKAgQJEgbSAgDgAgEaIiBEZXNjcmliZXMgYSBtZXRob2Qgb2YgYSBzZXJ2aWNlLgoKCwoDBAkBEgTSAggdCgwKBAQJAgASBNMCAhsKDQoFBAkCAAQSBNMCAgoKDQoFBAkCAAUSBNMCCxEKDQoFBAkCAAESBNMCEhYKDQoFBAkCAAMSBNMCGRoKlwEKBAQJAgESBNcCAiEaiAEgSW5wdXQgYW5kIG91dHB1dCB0eXBlIG5hbWVzLiAgVGhlc2UgYXJlIHJlc29sdmVkIGluIHRoZSBzYW1lIHdheSBhcwogRmllbGREZXNjcmlwdG9yUHJvdG8udHlwZV9uYW1lLCBidXQgbXVzdCByZWZlciB0byBhIG1lc3NhZ2UgdHlwZS4KCg0KBQQJAgEEEgTXAgIKCg0KBQQJAgEFEgTXAgsRCg0KBQQJAgEBEgTXAhIcCg0KBQQJAgEDEgTXAh8gCgwKBAQJAgISBNgCAiIKDQoFBAkCAgQSBNgCAgoKDQoFBAkCAgUSBNgCCxEKDQoFBAkCAgESBNgCEh0KDQoFBAkCAgMSBNgCICEKDAoEBAkCAxIE2gICJQoNCgUECQIDBBIE2gICCgoNCgUECQIDBhIE2gILGAoNCgUECQIDARIE2gIZIAoNCgUECQIDAxIE2gIjJApFCgQECQIEEgTdAgI3GjcgSWRlbnRpZmllcyBpZiBjbGllbnQgc3RyZWFtcyBtdWx0aXBsZSBjbGllbnQgbWVzc2FnZXMKCg0KBQQJAgQEEgTdAgIKCg0KBQQJAgQFEgTdAgsPCg0KBQQJAgQBEgTdAhAgCg0KBQQJAgQDEgTdAiMkCg0KBQQJAgQIEgTdAiU2Cg0KBQQJAgQHEgTdAjA1CkUKBAQJAgUSBN8CAjcaNyBJZGVudGlmaWVzIGlmIHNlcnZlciBzdHJlYW1zIG11bHRpcGxlIHNlcnZlciBtZXNzYWdlcwoKDQoFBAkCBQQSBN8CAgoKDQoFBAkCBQUSBN8CCw8KDQoFBAkCBQESBN8CECAKDQoFBAkCBQMSBN8CIyQKDQoFBAkCBQgSBN8CJTYKDQoFBAkCBQcSBN8CMDUKrw4KAgQKEgaCAwD2AwEyTiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09CiBPcHRpb25zCjLQDSBFYWNoIG9mIHRoZSBkZWZpbml0aW9ucyBhYm92ZSBtYXkgaGF2ZSAib3B0aW9ucyIgYXR0YWNoZWQuICBUaGVzZSBhcmUKIGp1c3QgYW5ub3RhdGlvbnMgd2hpY2ggbWF5IGNhdXNlIGNvZGUgdG8gYmUgZ2VuZXJhdGVkIHNsaWdodGx5IGRpZmZlcmVudGx5CiBvciBtYXkgY29udGFpbiBoaW50cyBmb3IgY29kZSB0aGF0IG1hbmlwdWxhdGVzIHByb3RvY29sIG1lc3NhZ2VzLgoKIENsaWVudHMgbWF5IGRlZmluZSBjdXN0b20gb3B0aW9ucyBhcyBleHRlbnNpb25zIG9mIHRoZSAqT3B0aW9ucyBtZXNzYWdlcy4KIFRoZXNlIGV4dGVuc2lvbnMgbWF5IG5vdCB5ZXQgYmUga25vd24gYXQgcGFyc2luZyB0aW1lLCBzbyB0aGUgcGFyc2VyIGNhbm5vdAogc3RvcmUgdGhlIHZhbHVlcyBpbiB0aGVtLiAgSW5zdGVhZCBpdCBzdG9yZXMgdGhlbSBpbiBhIGZpZWxkIGluIHRoZSAqT3B0aW9ucwogbWVzc2FnZSBjYWxsZWQgdW5pbnRlcnByZXRlZF9vcHRpb24uIFRoaXMgZmllbGQgbXVzdCBoYXZlIHRoZSBzYW1lIG5hbWUKIGFjcm9zcyBhbGwgKk9wdGlvbnMgbWVzc2FnZXMuIFdlIHRoZW4gdXNlIHRoaXMgZmllbGQgdG8gcG9wdWxhdGUgdGhlCiBleHRlbnNpb25zIHdoZW4gd2UgYnVpbGQgYSBkZXNjcmlwdG9yLCBhdCB3aGljaCBwb2ludCBhbGwgcHJvdG9zIGhhdmUgYmVlbgogcGFyc2VkIGFuZCBzbyBhbGwgZXh0ZW5zaW9ucyBhcmUga25vd24uCgogRXh0ZW5zaW9uIG51bWJlcnMgZm9yIGN1c3RvbSBvcHRpb25zIG1heSBiZSBjaG9zZW4gYXMgZm9sbG93czoKICogRm9yIG9wdGlvbnMgd2hpY2ggd2lsbCBvbmx5IGJlIHVzZWQgd2l0aGluIGEgc2luZ2xlIGFwcGxpY2F0aW9uIG9yCiAgIG9yZ2FuaXphdGlvbiwgb3IgZm9yIGV4cGVyaW1lbnRhbCBvcHRpb25zLCB1c2UgZmllbGQgbnVtYmVycyA1MDAwMAogICB0aHJvdWdoIDk5OTk5LiAgSXQgaXMgdXAgdG8geW91IHRvIGVuc3VyZSB0aGF0IHlvdSBkbyBub3QgdXNlIHRoZQogICBzYW1lIG51bWJlciBmb3IgbXVsdGlwbGUgb3B0aW9ucy4KICogRm9yIG9wdGlvbnMgd2hpY2ggd2lsbCBiZSBwdWJsaXNoZWQgYW5kIHVzZWQgcHVibGljbHkgYnkgbXVsdGlwbGUKICAgaW5kZXBlbmRlbnQgZW50aXRpZXMsIGUtbWFpbCBwcm90b2J1Zi1nbG9iYWwtZXh0ZW5zaW9uLXJlZ2lzdHJ5QGdvb2dsZS5jb20KICAgdG8gcmVzZXJ2ZSBleHRlbnNpb24gbnVtYmVycy4gU2ltcGx5IHByb3ZpZGUgeW91ciBwcm9qZWN0IG5hbWUgKGUuZy4KICAgT2JqZWN0aXZlLUMgcGx1Z2luKSBhbmQgeW91ciBwcm9qZWN0IHdlYnNpdGUgKGlmIGF2YWlsYWJsZSkgLS0gdGhlcmUncyBubwogICBuZWVkIHRvIGV4cGxhaW4gaG93IHlvdSBpbnRlbmQgdG8gdXNlIHRoZW0uIFVzdWFsbHkgeW91IG9ubHkgbmVlZCBvbmUKICAgZXh0ZW5zaW9uIG51bWJlci4gWW91IGNhbiBkZWNsYXJlIG11bHRpcGxlIG9wdGlvbnMgd2l0aCBvbmx5IG9uZSBleHRlbnNpb24KICAgbnVtYmVyIGJ5IHB1dHRpbmcgdGhlbSBpbiBhIHN1Yi1tZXNzYWdlLiBTZWUgdGhlIEN1c3RvbSBPcHRpb25zIHNlY3Rpb24gb2YKICAgdGhlIGRvY3MgZm9yIGV4YW1wbGVzOgogICBodHRwczovL2RldmVsb3BlcnMuZ29vZ2xlLmNvbS9wcm90b2NvbC1idWZmZXJzL2RvY3MvcHJvdG8jb3B0aW9ucwogICBJZiB0aGlzIHR1cm5zIG91dCB0byBiZSBwb3B1bGFyLCBhIHdlYiBzZXJ2aWNlIHdpbGwgYmUgc2V0IHVwCiAgIHRvIGF1dG9tYXRpY2FsbHkgYXNzaWduIG9wdGlvbiBudW1iZXJzLgoKCwoDBAoBEgSCAwgTCvQBCgQECgIAEgSIAwIjGuUBIFNldHMgdGhlIEphdmEgcGFja2FnZSB3aGVyZSBjbGFzc2VzIGdlbmVyYXRlZCBmcm9tIHRoaXMgLnByb3RvIHdpbGwgYmUKIHBsYWNlZC4gIEJ5IGRlZmF1bHQsIHRoZSBwcm90byBwYWNrYWdlIGlzIHVzZWQsIGJ1dCB0aGlzIGlzIG9mdGVuCiBpbmFwcHJvcHJpYXRlIGJlY2F1c2UgcHJvdG8gcGFja2FnZXMgZG8gbm90IG5vcm1hbGx5IHN0YXJ0IHdpdGggYmFja3dhcmRzCiBkb21haW4gbmFtZXMuCgoNCgUECgIABBIEiAMCCgoNCgUECgIABRIEiAMLEQoNCgUECgIAARIEiAMSHgoNCgUECgIAAxIEiAMhIgrxAgoEBAoCARIEjwMCKxriAiBDb250cm9scyB0aGUgbmFtZSBvZiB0aGUgd3JhcHBlciBKYXZhIGNsYXNzIGdlbmVyYXRlZCBmb3IgdGhlIC5wcm90byBmaWxlLgogVGhhdCBjbGFzcyB3aWxsIGFsd2F5cyBjb250YWluIHRoZSAucHJvdG8gZmlsZSdzIGdldERlc2NyaXB0b3IoKSBtZXRob2QgYXMKIHdlbGwgYXMgYW55IHRvcC1sZXZlbCBleHRlbnNpb25zIGRlZmluZWQgaW4gdGhlIC5wcm90byBmaWxlLgogSWYgamF2YV9tdWx0aXBsZV9maWxlcyBpcyBkaXNhYmxlZCwgdGhlbiBhbGwgdGhlIG90aGVyIGNsYXNzZXMgZnJvbSB0aGUKIC5wcm90byBmaWxlIHdpbGwgYmUgbmVzdGVkIGluc2lkZSB0aGUgc2luZ2xlIHdyYXBwZXIgb3V0ZXIgY2xhc3MuCgoNCgUECgIBBBIEjwMCCgoNCgUECgIBBRIEjwMLEQoNCgUECgIBARIEjwMSJgoNCgUECgIBAxIEjwMpKgqmAwoEBAoCAhIElwMCOxqXAyBJZiBlbmFibGVkLCB0aGVuIHRoZSBKYXZhIGNvZGUgZ2VuZXJhdG9yIHdpbGwgZ2VuZXJhdGUgYSBzZXBhcmF0ZSAuamF2YQogZmlsZSBmb3IgZWFjaCB0b3AtbGV2ZWwgbWVzc2FnZSwgZW51bSwgYW5kIHNlcnZpY2UgZGVmaW5lZCBpbiB0aGUgLnByb3RvCiBmaWxlLiAgVGh1cywgdGhlc2UgdHlwZXMgd2lsbCAqbm90KiBiZSBuZXN0ZWQgaW5zaWRlIHRoZSB3cmFwcGVyIGNsYXNzCiBuYW1lZCBieSBqYXZhX291dGVyX2NsYXNzbmFtZS4gIEhvd2V2ZXIsIHRoZSB3cmFwcGVyIGNsYXNzIHdpbGwgc3RpbGwgYmUKIGdlbmVyYXRlZCB0byBjb250YWluIHRoZSBmaWxlJ3MgZ2V0RGVzY3JpcHRvcigpIG1ldGhvZCBhcyB3ZWxsIGFzIGFueQogdG9wLWxldmVsIGV4dGVuc2lvbnMgZGVmaW5lZCBpbiB0aGUgZmlsZS4KCg0KBQQKAgIEEgSXAwIKCg0KBQQKAgIFEgSXAwsPCg0KBQQKAgIBEgSXAxAjCg0KBQQKAgIDEgSXAyYoCg0KBQQKAgIIEgSXAyk6Cg0KBQQKAgIHEgSXAzQ5CikKBAQKAgMSBJoDAkUaGyBUaGlzIG9wdGlvbiBkb2VzIG5vdGhpbmcuCgoNCgUECgIDBBIEmgMCCgoNCgUECgIDBRIEmgMLDwoNCgUECgIDARIEmgMQLQoNCgUECgIDAxIEmgMwMgoNCgUECgIDCBIEmgMzRAoOCgYECgIDCAMSBJoDNEMK5gIKBAQKAgQSBKIDAj4a1wIgSWYgc2V0IHRydWUsIHRoZW4gdGhlIEphdmEyIGNvZGUgZ2VuZXJhdG9yIHdpbGwgZ2VuZXJhdGUgY29kZSB0aGF0CiB0aHJvd3MgYW4gZXhjZXB0aW9uIHdoZW5ldmVyIGFuIGF0dGVtcHQgaXMgbWFkZSB0byBhc3NpZ24gYSBub24tVVRGLTgKIGJ5dGUgc2VxdWVuY2UgdG8gYSBzdHJpbmcgZmllbGQuCiBNZXNzYWdlIHJlZmxlY3Rpb24gd2lsbCBkbyB0aGUgc2FtZS4KIEhvd2V2ZXIsIGFuIGV4dGVuc2lvbiBmaWVsZCBzdGlsbCBhY2NlcHRzIG5vbi1VVEYtOCBieXRlIHNlcXVlbmNlcy4KIFRoaXMgb3B0aW9uIGhhcyBubyBlZmZlY3Qgb24gd2hlbiB1c2VkIHdpdGggdGhlIGxpdGUgcnVudGltZS4KCg0KBQQKAgQEEgSiAwIKCg0KBQQKAgQFEgSiAwsPCg0KBQQKAgQBEgSiAxAmCg0KBQQKAgQDEgSiAykrCg0KBQQKAgQIEgSiAyw9Cg0KBQQKAgQHEgSiAzc8CkwKBAQKBAASBqUDAqoDAxo8IEdlbmVyYXRlZCBjbGFzc2VzIGNhbiBiZSBvcHRpbWl6ZWQgZm9yIHNwZWVkIG9yIGNvZGUgc2l6ZS4KCg0KBQQKBAABEgSlAwcTCkQKBgQKBAACABIEpgMEDiI0IEdlbmVyYXRlIGNvbXBsZXRlIGNvZGUgZm9yIHBhcnNpbmcsIHNlcmlhbGl6YXRpb24sCgoPCgcECgQAAgABEgSmAwQJCg8KBwQKBAACAAISBKYDDA0KRwoGBAoEAAIBEgSoAwQSGgYgZXRjLgoiLyBVc2UgUmVmbGVjdGlvbk9wcyB0byBpbXBsZW1lbnQgdGhlc2UgbWV0aG9kcy4KCg8KBwQKBAACAQESBKgDBA0KDwoHBAoEAAIBAhIEqAMQEQpHCgYECgQAAgISBKkDBBUiNyBHZW5lcmF0ZSBjb2RlIHVzaW5nIE1lc3NhZ2VMaXRlIGFuZCB0aGUgbGl0ZSBydW50aW1lLgoKDwoHBAoEAAICARIEqQMEEAoPCgcECgQAAgICEgSpAxMUCgwKBAQKAgUSBKsDAjsKDQoFBAoCBQQSBKsDAgoKDQoFBAoCBQYSBKsDCxcKDQoFBAoCBQESBKsDGCQKDQoFBAoCBQMSBKsDJygKDQoFBAoCBQgSBKsDKToKDQoFBAoCBQcSBKsDNDkK4gIKBAQKAgYSBLIDAiIa0wIgU2V0cyB0aGUgR28gcGFja2FnZSB3aGVyZSBzdHJ1Y3RzIGdlbmVyYXRlZCBmcm9tIHRoaXMgLnByb3RvIHdpbGwgYmUKIHBsYWNlZC4gSWYgb21pdHRlZCwgdGhlIEdvIHBhY2thZ2Ugd2lsbCBiZSBkZXJpdmVkIGZyb20gdGhlIGZvbGxvd2luZzoKICAgLSBUaGUgYmFzZW5hbWUgb2YgdGhlIHBhY2thZ2UgaW1wb3J0IHBhdGgsIGlmIHByb3ZpZGVkLgogICAtIE90aGVyd2lzZSwgdGhlIHBhY2thZ2Ugc3RhdGVtZW50IGluIHRoZSAucHJvdG8gZmlsZSwgaWYgcHJlc2VudC4KICAgLSBPdGhlcndpc2UsIHRoZSBiYXNlbmFtZSBvZiB0aGUgLnByb3RvIGZpbGUsIHdpdGhvdXQgZXh0ZW5zaW9uLgoKDQoFBAoCBgQSBLIDAgoKDQoFBAoCBgUSBLIDCxEKDQoFBAoCBgESBLIDEhwKDQoFBAoCBgMSBLIDHyEK1AQKBAQKAgcSBL4DAjsaxQQgU2hvdWxkIGdlbmVyaWMgc2VydmljZXMgYmUgZ2VuZXJhdGVkIGluIGVhY2ggbGFuZ3VhZ2U/ICAiR2VuZXJpYyIgc2VydmljZXMKIGFyZSBub3Qgc3BlY2lmaWMgdG8gYW55IHBhcnRpY3VsYXIgUlBDIHN5c3RlbS4gIFRoZXkgYXJlIGdlbmVyYXRlZCBieSB0aGUKIG1haW4gY29kZSBnZW5lcmF0b3JzIGluIGVhY2ggbGFuZ3VhZ2UgKHdpdGhvdXQgYWRkaXRpb25hbCBwbHVnaW5zKS4KIEdlbmVyaWMgc2VydmljZXMgd2VyZSB0aGUgb25seSBraW5kIG9mIHNlcnZpY2UgZ2VuZXJhdGlvbiBzdXBwb3J0ZWQgYnkKIGVhcmx5IHZlcnNpb25zIG9mIGdvb2dsZS5wcm90b2J1Zi4KCiBHZW5lcmljIHNlcnZpY2VzIGFyZSBub3cgY29uc2lkZXJlZCBkZXByZWNhdGVkIGluIGZhdm9yIG9mIHVzaW5nIHBsdWdpbnMKIHRoYXQgZ2VuZXJhdGUgY29kZSBzcGVjaWZpYyB0byB5b3VyIHBhcnRpY3VsYXIgUlBDIHN5c3RlbS4gIFRoZXJlZm9yZSwKIHRoZXNlIGRlZmF1bHQgdG8gZmFsc2UuICBPbGQgY29kZSB3aGljaCBkZXBlbmRzIG9uIGdlbmVyaWMgc2VydmljZXMgc2hvdWxkCiBleHBsaWNpdGx5IHNldCB0aGVtIHRvIHRydWUuCgoNCgUECgIHBBIEvgMCCgoNCgUECgIHBRIEvgMLDwoNCgUECgIHARIEvgMQIwoNCgUECgIHAxIEvgMmKAoNCgUECgIHCBIEvgMpOgoNCgUECgIHBxIEvgM0OQoMCgQECgIIEgS/AwI9Cg0KBQQKAggEEgS/AwIKCg0KBQQKAggFEgS/AwsPCg0KBQQKAggBEgS/AxAlCg0KBQQKAggDEgS/AygqCg0KBQQKAggIEgS/Ays8Cg0KBQQKAggHEgS/AzY7CgwKBAQKAgkSBMADAjsKDQoFBAoCCQQSBMADAgoKDQoFBAoCCQUSBMADCw8KDQoFBAoCCQESBMADECMKDQoFBAoCCQMSBMADJigKDQoFBAoCCQgSBMADKToKDQoFBAoCCQcSBMADNDkKDAoEBAoCChIEwQMCPAoNCgUECgIKBBIEwQMCCgoNCgUECgIKBRIEwQMLDwoNCgUECgIKARIEwQMQJAoNCgUECgIKAxIEwQMnKQoNCgUECgIKCBIEwQMqOwoNCgUECgIKBxIEwQM1OgrzAQoEBAoCCxIExwMCMhrkASBJcyB0aGlzIGZpbGUgZGVwcmVjYXRlZD8KIERlcGVuZGluZyBvbiB0aGUgdGFyZ2V0IHBsYXRmb3JtLCB0aGlzIGNhbiBlbWl0IERlcHJlY2F0ZWQgYW5ub3RhdGlvbnMKIGZvciBldmVyeXRoaW5nIGluIHRoZSBmaWxlLCBvciBpdCB3aWxsIGJlIGNvbXBsZXRlbHkgaWdub3JlZDsgaW4gdGhlIHZlcnkKIGxlYXN0LCB0aGlzIGlzIGEgZm9ybWFsaXphdGlvbiBmb3IgZGVwcmVjYXRpbmcgZmlsZXMuCgoNCgUECgILBBIExwMCCgoNCgUECgILBRIExwMLDwoNCgUECgILARIExwMQGgoNCgUECgILAxIExwMdHwoNCgUECgILCBIExwMgMQoNCgUECgILBxIExwMrMAp/CgQECgIMEgTLAwI3GnEgRW5hYmxlcyB0aGUgdXNlIG9mIGFyZW5hcyBmb3IgdGhlIHByb3RvIG1lc3NhZ2VzIGluIHRoaXMgZmlsZS4gVGhpcyBhcHBsaWVzCiBvbmx5IHRvIGdlbmVyYXRlZCBjbGFzc2VzIGZvciBDKysuCgoNCgUECgIMBBIEywMCCgoNCgUECgIMBRIEywMLDwoNCgUECgIMARIEywMQIAoNCgUECgIMAxIEywMjJQoNCgUECgIMCBIEywMmNgoNCgUECgIMBxIEywMxNQqSAQoEBAoCDRIEzwMCKRqDASBTZXRzIHRoZSBvYmplY3RpdmUgYyBjbGFzcyBwcmVmaXggd2hpY2ggaXMgcHJlcGVuZGVkIHRvIGFsbCBvYmplY3RpdmUgYwogZ2VuZXJhdGVkIGNsYXNzZXMgZnJvbSB0aGlzIC5wcm90by4gVGhlcmUgaXMgbm8gZGVmYXVsdC4KCg0KBQQKAg0EEgTPAwIKCg0KBQQKAg0FEgTPAwsRCg0KBQQKAg0BEgTPAxIjCg0KBQQKAg0DEgTPAyYoCkkKBAQKAg4SBNIDAigaOyBOYW1lc3BhY2UgZm9yIGdlbmVyYXRlZCBjbGFzc2VzOyBkZWZhdWx0cyB0byB0aGUgcGFja2FnZS4KCg0KBQQKAg4EEgTSAwIKCg0KBQQKAg4FEgTSAwsRCg0KBQQKAg4BEgTSAxIiCg0KBQQKAg4DEgTSAyUnCpECCgQECgIPEgTYAwIkGoICIEJ5IGRlZmF1bHQgU3dpZnQgZ2VuZXJhdG9ycyB3aWxsIHRha2UgdGhlIHByb3RvIHBhY2thZ2UgYW5kIENhbWVsQ2FzZSBpdAogcmVwbGFjaW5nICcuJyB3aXRoIHVuZGVyc2NvcmUgYW5kIHVzZSB0aGF0IHRvIHByZWZpeCB0aGUgdHlwZXMvc3ltYm9scwogZGVmaW5lZC4gV2hlbiB0aGlzIG9wdGlvbnMgaXMgcHJvdmlkZWQsIHRoZXkgd2lsbCB1c2UgdGhpcyB2YWx1ZSBpbnN0ZWFkCiB0byBwcmVmaXggdGhlIHR5cGVzL3N5bWJvbHMgZGVmaW5lZC4KCg0KBQQKAg8EEgTYAwIKCg0KBQQKAg8FEgTYAwsRCg0KBQQKAg8BEgTYAxIeCg0KBQQKAg8DEgTYAyEjCn4KBAQKAhASBNwDAigacCBTZXRzIHRoZSBwaHAgY2xhc3MgcHJlZml4IHdoaWNoIGlzIHByZXBlbmRlZCB0byBhbGwgcGhwIGdlbmVyYXRlZCBjbGFzc2VzCiBmcm9tIHRoaXMgLnByb3RvLiBEZWZhdWx0IGlzIGVtcHR5LgoKDQoFBAoCEAQSBNwDAgoKDQoFBAoCEAUSBNwDCxEKDQoFBAoCEAESBNwDEiIKDQoFBAoCEAMSBNwDJScKvgEKBAQKAhESBOEDAiUarwEgVXNlIHRoaXMgb3B0aW9uIHRvIGNoYW5nZSB0aGUgbmFtZXNwYWNlIG9mIHBocCBnZW5lcmF0ZWQgY2xhc3Nlcy4gRGVmYXVsdAogaXMgZW1wdHkuIFdoZW4gdGhpcyBvcHRpb24gaXMgZW1wdHksIHRoZSBwYWNrYWdlIG5hbWUgd2lsbCBiZSB1c2VkIGZvcgogZGV0ZXJtaW5pbmcgdGhlIG5hbWVzcGFjZS4KCg0KBQQKAhEEEgThAwIKCg0KBQQKAhEFEgThAwsRCg0KBQQKAhEBEgThAxIfCg0KBQQKAhEDEgThAyIkCsoBCgQECgISEgTmAwIuGrsBIFVzZSB0aGlzIG9wdGlvbiB0byBjaGFuZ2UgdGhlIG5hbWVzcGFjZSBvZiBwaHAgZ2VuZXJhdGVkIG1ldGFkYXRhIGNsYXNzZXMuCiBEZWZhdWx0IGlzIGVtcHR5LiBXaGVuIHRoaXMgb3B0aW9uIGlzIGVtcHR5LCB0aGUgcHJvdG8gZmlsZSBuYW1lIHdpbGwgYmUKIHVzZWQgZm9yIGRldGVybWluaW5nIHRoZSBuYW1lc3BhY2UuCgoNCgUECgISBBIE5gMCCgoNCgUECgISBRIE5gMLEQoNCgUECgISARIE5gMSKAoNCgUECgISAxIE5gMrLQrCAQoEBAoCExIE6wMCJBqzASBVc2UgdGhpcyBvcHRpb24gdG8gY2hhbmdlIHRoZSBwYWNrYWdlIG9mIHJ1YnkgZ2VuZXJhdGVkIGNsYXNzZXMuIERlZmF1bHQKIGlzIGVtcHR5LiBXaGVuIHRoaXMgb3B0aW9uIGlzIG5vdCBzZXQsIHRoZSBwYWNrYWdlIG5hbWUgd2lsbCBiZSB1c2VkIGZvcgogZGV0ZXJtaW5pbmcgdGhlIHJ1YnkgcGFja2FnZS4KCg0KBQQKAhMEEgTrAwIKCg0KBQQKAhMFEgTrAwsRCg0KBQQKAhMBEgTrAxIeCg0KBQQKAhMDEgTrAyEjCnwKBAQKAhQSBO8DAjoabiBUaGUgcGFyc2VyIHN0b3JlcyBvcHRpb25zIGl0IGRvZXNuJ3QgcmVjb2duaXplIGhlcmUuCiBTZWUgdGhlIGRvY3VtZW50YXRpb24gZm9yIHRoZSAiT3B0aW9ucyIgc2VjdGlvbiBhYm92ZS4KCg0KBQQKAhQEEgTvAwIKCg0KBQQKAhQGEgTvAwseCg0KBQQKAhQBEgTvAx8zCg0KBQQKAhQDEgTvAzY5CocBCgMECgUSBPMDAhkaeiBDbGllbnRzIGNhbiBkZWZpbmUgY3VzdG9tIG9wdGlvbnMgaW4gZXh0ZW5zaW9ucyBvZiB0aGlzIG1lc3NhZ2UuCiBTZWUgdGhlIGRvY3VtZW50YXRpb24gZm9yIHRoZSAiT3B0aW9ucyIgc2VjdGlvbiBhYm92ZS4KCgwKBAQKBQASBPMDDRgKDQoFBAoFAAESBPMDDREKDQoFBAoFAAISBPMDFRgKCwoDBAoJEgT1AwIOCgwKBAQKCQASBPUDCw0KDQoFBAoJAAESBPUDCw0KDQoFBAoJAAISBPUDCw0KDAoCBAsSBvgDAMUEAQoLCgMECwESBPgDCBYK2AUKBAQLAgASBIsEAj4ayQUgU2V0IHRydWUgdG8gdXNlIHRoZSBvbGQgcHJvdG8xIE1lc3NhZ2VTZXQgd2lyZSBmb3JtYXQgZm9yIGV4dGVuc2lvbnMuCiBUaGlzIGlzIHByb3ZpZGVkIGZvciBiYWNrd2FyZHMtY29tcGF0aWJpbGl0eSB3aXRoIHRoZSBNZXNzYWdlU2V0IHdpcmUKIGZvcm1hdC4gIFlvdSBzaG91bGQgbm90IHVzZSB0aGlzIGZvciBhbnkgb3RoZXIgcmVhc29uOiAgSXQncyBsZXNzCiBlZmZpY2llbnQsIGhhcyBmZXdlciBmZWF0dXJlcywgYW5kIGlzIG1vcmUgY29tcGxpY2F0ZWQuCgogVGhlIG1lc3NhZ2UgbXVzdCBiZSBkZWZpbmVkIGV4YWN0bHkgYXMgZm9sbG93czoKICAgbWVzc2FnZSBGb28gewogICAgIG9wdGlvbiBtZXNzYWdlX3NldF93aXJlX2Zvcm1hdCA9IHRydWU7CiAgICAgZXh0ZW5zaW9ucyA0IHRvIG1heDsKICAgfQogTm90ZSB0aGF0IHRoZSBtZXNzYWdlIGNhbm5vdCBoYXZlIGFueSBkZWZpbmVkIGZpZWxkczsgTWVzc2FnZVNldHMgb25seQogaGF2ZSBleHRlbnNpb25zLgoKIEFsbCBleHRlbnNpb25zIG9mIHlvdXIgdHlwZSBtdXN0IGJlIHNpbmd1bGFyIG1lc3NhZ2VzOyBlLmcuIHRoZXkgY2Fubm90CiBiZSBpbnQzMnMsIGVudW1zLCBvciByZXBlYXRlZCBtZXNzYWdlcy4KCiBCZWNhdXNlIHRoaXMgaXMgYW4gb3B0aW9uLCB0aGUgYWJvdmUgdHdvIHJlc3RyaWN0aW9ucyBhcmUgbm90IGVuZm9yY2VkIGJ5CiB0aGUgcHJvdG9jb2wgY29tcGlsZXIuCgoNCgUECwIABBIEiwQCCgoNCgUECwIABRIEiwQLDwoNCgUECwIAARIEiwQQJwoNCgUECwIAAxIEiwQqKwoNCgUECwIACBIEiwQsPQoNCgUECwIABxIEiwQ3PArrAQoEBAsCARIEkAQCRhrcASBEaXNhYmxlcyB0aGUgZ2VuZXJhdGlvbiBvZiB0aGUgc3RhbmRhcmQgImRlc2NyaXB0b3IoKSIgYWNjZXNzb3IsIHdoaWNoIGNhbgogY29uZmxpY3Qgd2l0aCBhIGZpZWxkIG9mIHRoZSBzYW1lIG5hbWUuICBUaGlzIGlzIG1lYW50IHRvIG1ha2UgbWlncmF0aW9uCiBmcm9tIHByb3RvMSBlYXNpZXI7IG5ldyBjb2RlIHNob3VsZCBhdm9pZCBmaWVsZHMgbmFtZWQgImRlc2NyaXB0b3IiLgoKDQoFBAsCAQQSBJAEAgoKDQoFBAsCAQUSBJAECw8KDQoFBAsCAQESBJAEEC8KDQoFBAsCAQMSBJAEMjMKDQoFBAsCAQgSBJAENEUKDQoFBAsCAQcSBJAEP0QK7gEKBAQLAgISBJYEAjEa3wEgSXMgdGhpcyBtZXNzYWdlIGRlcHJlY2F0ZWQ/CiBEZXBlbmRpbmcgb24gdGhlIHRhcmdldCBwbGF0Zm9ybSwgdGhpcyBjYW4gZW1pdCBEZXByZWNhdGVkIGFubm90YXRpb25zCiBmb3IgdGhlIG1lc3NhZ2UsIG9yIGl0IHdpbGwgYmUgY29tcGxldGVseSBpZ25vcmVkOyBpbiB0aGUgdmVyeSBsZWFzdCwKIHRoaXMgaXMgYSBmb3JtYWxpemF0aW9uIGZvciBkZXByZWNhdGluZyBtZXNzYWdlcy4KCg0KBQQLAgIEEgSWBAIKCg0KBQQLAgIFEgSWBAsPCg0KBQQLAgIBEgSWBBAaCg0KBQQLAgIDEgSWBB0eCg0KBQQLAgIIEgSWBB8wCg0KBQQLAgIHEgSWBCovCgsKAwQLCRIEmAQCEwoMCgQECwkAEgSYBAsMCg0KBQQLCQABEgSYBAsMCg0KBQQLCQACEgSYBAsMCgwKBAQLCQESBJgEDg8KDQoFBAsJAQESBJgEDg8KDQoFBAsJAQISBJgEDg8KDAoEBAsJAhIEmAQREgoNCgUECwkCARIEmAQREgoNCgUECwkCAhIEmAQREgqgBgoEBAsCAxIErwQCHhqRBiBOT1RFOiBEbyBub3Qgc2V0IHRoZSBvcHRpb24gaW4gLnByb3RvIGZpbGVzLiBBbHdheXMgdXNlIHRoZSBtYXBzIHN5bnRheAogaW5zdGVhZC4gVGhlIG9wdGlvbiBzaG91bGQgb25seSBiZSBpbXBsaWNpdGx5IHNldCBieSB0aGUgcHJvdG8gY29tcGlsZXIKIHBhcnNlci4KCiBXaGV0aGVyIHRoZSBtZXNzYWdlIGlzIGFuIGF1dG9tYXRpY2FsbHkgZ2VuZXJhdGVkIG1hcCBlbnRyeSB0eXBlIGZvciB0aGUKIG1hcHMgZmllbGQuCgogRm9yIG1hcHMgZmllbGRzOgogICAgIG1hcDxLZXlUeXBlLCBWYWx1ZVR5cGU+IG1hcF9maWVsZCA9IDE7CiBUaGUgcGFyc2VkIGRlc2NyaXB0b3IgbG9va3MgbGlrZToKICAgICBtZXNzYWdlIE1hcEZpZWxkRW50cnkgewogICAgICAgICBvcHRpb24gbWFwX2VudHJ5ID0gdHJ1ZTsKICAgICAgICAgb3B0aW9uYWwgS2V5VHlwZSBrZXkgPSAxOwogICAgICAgICBvcHRpb25hbCBWYWx1ZVR5cGUgdmFsdWUgPSAyOwogICAgIH0KICAgICByZXBlYXRlZCBNYXBGaWVsZEVudHJ5IG1hcF9maWVsZCA9IDE7CgogSW1wbGVtZW50YXRpb25zIG1heSBjaG9vc2Ugbm90IHRvIGdlbmVyYXRlIHRoZSBtYXBfZW50cnk9dHJ1ZSBtZXNzYWdlLCBidXQKIHVzZSBhIG5hdGl2ZSBtYXAgaW4gdGhlIHRhcmdldCBsYW5ndWFnZSB0byBob2xkIHRoZSBrZXlzIGFuZCB2YWx1ZXMuCiBUaGUgcmVmbGVjdGlvbiBBUElzIGluIHN1Y2ggaW1wbGVtZW50YXRpb25zIHN0aWxsIG5lZWQgdG8gd29yayBhcwogaWYgdGhlIGZpZWxkIGlzIGEgcmVwZWF0ZWQgbWVzc2FnZSBmaWVsZC4KCg0KBQQLAgMEEgSvBAIKCg0KBQQLAgMFEgSvBAsPCg0KBQQLAgMBEgSvBBAZCg0KBQQLAgMDEgSvBBwdCiQKAwQLCRIEsQQCDSIXIGphdmFsaXRlX3NlcmlhbGl6YWJsZQoKDAoEBAsJAxIEsQQLDAoNCgUECwkDARIEsQQLDAoNCgUECwkDAhIEsQQLDAofCgMECwkSBLIEAg0iEiBqYXZhbmFub19hc19saXRlCgoMCgQECwkEEgSyBAsMCg0KBQQLCQQBEgSyBAsMCg0KBQQLCQQCEgSyBAsMCuoDCgQECwIEEgS+BAJQGtsDIEVuYWJsZSB0aGUgbGVnYWN5IGhhbmRsaW5nIG9mIEpTT04gZmllbGQgbmFtZSBjb25mbGljdHMuICBUaGlzIGxvd2VyY2FzZXMKIGFuZCBzdHJpcHMgdW5kZXJzY29yZWQgZnJvbSB0aGUgZmllbGRzIGJlZm9yZSBjb21wYXJpc29uIGluIHByb3RvMyBvbmx5LgogVGhlIG5ldyBiZWhhdmlvciB0YWtlcyBganNvbl9uYW1lYCBpbnRvIGFjY291bnQgYW5kIGFwcGxpZXMgdG8gcHJvdG8yIGFzCiB3ZWxsLgoKIFRoaXMgc2hvdWxkIG9ubHkgYmUgdXNlZCBhcyBhIHRlbXBvcmFyeSBtZWFzdXJlIGFnYWluc3QgYnJva2VuIGJ1aWxkcyBkdWUKIHRvIHRoZSBjaGFuZ2UgaW4gYmVoYXZpb3IgZm9yIEpTT04gZmllbGQgbmFtZSBjb25mbGljdHMuCgogVE9ETyhiLzI2MTc1MDE5MCkgVGhpcyBpcyBsZWdhY3kgYmVoYXZpb3Igd2UgcGxhbiB0byByZW1vdmUgb25jZSBkb3duc3RyZWFtCiB0ZWFtcyBoYXZlIGhhZCB0aW1lIHRvIG1pZ3JhdGUuCgoNCgUECwIEBBIEvgQCCgoNCgUECwIEBRIEvgQLDwoNCgUECwIEARIEvgQQNgoNCgUECwIEAxIEvgQ5OwoNCgUECwIECBIEvgQ8TwoOCgYECwIECAMSBL4EPU4KTwoEBAsCBRIEwQQCOhpBIFRoZSBwYXJzZXIgc3RvcmVzIG9wdGlvbnMgaXQgZG9lc24ndCByZWNvZ25pemUgaGVyZS4gU2VlIGFib3ZlLgoKDQoFBAsCBQQSBMEEAgoKDQoFBAsCBQYSBMEECx4KDQoFBAsCBQESBMEEHzMKDQoFBAsCBQMSBMEENjkKWgoDBAsFEgTEBAIZGk0gQ2xpZW50cyBjYW4gZGVmaW5lIGN1c3RvbSBvcHRpb25zIGluIGV4dGVuc2lvbnMgb2YgdGhpcyBtZXNzYWdlLiBTZWUgYWJvdmUuCgoMCgQECwUAEgTEBA0YCg0KBQQLBQABEgTEBA0RCg0KBQQLBQACEgTEBBUYCgwKAgQMEgbHBADTBQEKCwoDBAwBEgTHBAgUCpIDCgQEDAIAEgTOBAIuGoMDIFRoZSBjdHlwZSBvcHRpb24gaW5zdHJ1Y3RzIHRoZSBDKysgY29kZSBnZW5lcmF0b3IgdG8gdXNlIGEgZGlmZmVyZW50CiByZXByZXNlbnRhdGlvbiBvZiB0aGUgZmllbGQgdGhhbiBpdCBub3JtYWxseSB3b3VsZC4gIFNlZSB0aGUgc3BlY2lmaWMKIG9wdGlvbnMgYmVsb3cuICBUaGlzIG9wdGlvbiBpcyBvbmx5IGltcGxlbWVudGVkIHRvIHN1cHBvcnQgdXNlIG9mCiBbY3R5cGU9Q09SRF0gYW5kIFtjdHlwZT1TVFJJTkddICh0aGUgZGVmYXVsdCkgb24gbm9uLXJlcGVhdGVkIGZpZWxkcyBvZgogdHlwZSAiYnl0ZXMiIGluIHRoZSBvcGVuIHNvdXJjZSByZWxlYXNlIC0tIHNvcnJ5LCB3ZSdsbCB0cnkgdG8gaW5jbHVkZQogb3RoZXIgdHlwZXMgaW4gYSBmdXR1cmUgdmVyc2lvbiEKCg0KBQQMAgAEEgTOBAIKCg0KBQQMAgAGEgTOBAsQCg0KBQQMAgABEgTOBBEWCg0KBQQMAgADEgTOBBkaCg0KBQQMAgAIEgTOBBstCg0KBQQMAgAHEgTOBCYsCg4KBAQMBAASBs8EAtwEAwoNCgUEDAQAARIEzwQHDAofCgYEDAQAAgASBNEEBA8aDyBEZWZhdWx0IG1vZGUuCgoPCgcEDAQAAgABEgTRBAQKCg8KBwQMBAACAAISBNEEDQ4KlgMKBgQMBAACARIE2QQEDRqFAyBUaGUgb3B0aW9uIFtjdHlwZT1DT1JEXSBtYXkgYmUgYXBwbGllZCB0byBhIG5vbi1yZXBlYXRlZCBmaWVsZCBvZiB0eXBlCiAiYnl0ZXMiLiBJdCBpbmRpY2F0ZXMgdGhhdCBpbiBDKyssIHRoZSBkYXRhIHNob3VsZCBiZSBzdG9yZWQgaW4gYSBDb3JkCiBpbnN0ZWFkIG9mIGEgc3RyaW5nLiAgRm9yIHZlcnkgbGFyZ2Ugc3RyaW5ncywgdGhpcyBtYXkgcmVkdWNlIG1lbW9yeQogZnJhZ21lbnRhdGlvbi4gSXQgbWF5IGFsc28gYWxsb3cgYmV0dGVyIHBlcmZvcm1hbmNlIHdoZW4gcGFyc2luZyBmcm9tIGEKIENvcmQsIG9yIHdoZW4gcGFyc2luZyB3aXRoIGFsaWFzaW5nIGVuYWJsZWQsIGFzIHRoZSBwYXJzZWQgQ29yZCBtYXkgdGhlbgogYWxpYXMgdGhlIG9yaWdpbmFsIGJ1ZmZlci4KCg8KBwQMBAACAQESBNkEBAgKDwoHBAwEAAIBAhIE2QQLDAoOCgYEDAQAAgISBNsEBBUKDwoHBAwEAAICARIE2wQEEAoPCgcEDAQAAgICEgTbBBMUCtoCCgQEDAIBEgTiBAIbGssCIFRoZSBwYWNrZWQgb3B0aW9uIGNhbiBiZSBlbmFibGVkIGZvciByZXBlYXRlZCBwcmltaXRpdmUgZmllbGRzIHRvIGVuYWJsZQogYSBtb3JlIGVmZmljaWVudCByZXByZXNlbnRhdGlvbiBvbiB0aGUgd2lyZS4gUmF0aGVyIHRoYW4gcmVwZWF0ZWRseQogd3JpdGluZyB0aGUgdGFnIGFuZCB0eXBlIGZvciBlYWNoIGVsZW1lbnQsIHRoZSBlbnRpcmUgYXJyYXkgaXMgZW5jb2RlZCBhcwogYSBzaW5nbGUgbGVuZ3RoLWRlbGltaXRlZCBibG9iLiBJbiBwcm90bzMsIG9ubHkgZXhwbGljaXQgc2V0dGluZyBpdCB0bwogZmFsc2Ugd2lsbCBhdm9pZCB1c2luZyBwYWNrZWQgZW5jb2RpbmcuCgoNCgUEDAIBBBIE4gQCCgoNCgUEDAIBBRIE4gQLDwoNCgUEDAIBARIE4gQQFgoNCgUEDAIBAxIE4gQZGgqaBQoEBAwCAhIE7wQCMxqLBSBUaGUganN0eXBlIG9wdGlvbiBkZXRlcm1pbmVzIHRoZSBKYXZhU2NyaXB0IHR5cGUgdXNlZCBmb3IgdmFsdWVzIG9mIHRoZQogZmllbGQuICBUaGUgb3B0aW9uIGlzIHBlcm1pdHRlZCBvbmx5IGZvciA2NCBiaXQgaW50ZWdyYWwgYW5kIGZpeGVkIHR5cGVzCiAoaW50NjQsIHVpbnQ2NCwgc2ludDY0LCBmaXhlZDY0LCBzZml4ZWQ2NCkuICBBIGZpZWxkIHdpdGgganN0eXBlIEpTX1NUUklORwogaXMgcmVwcmVzZW50ZWQgYXMgSmF2YVNjcmlwdCBzdHJpbmcsIHdoaWNoIGF2b2lkcyBsb3NzIG9mIHByZWNpc2lvbiB0aGF0CiBjYW4gaGFwcGVuIHdoZW4gYSBsYXJnZSB2YWx1ZSBpcyBjb252ZXJ0ZWQgdG8gYSBmbG9hdGluZyBwb2ludCBKYXZhU2NyaXB0LgogU3BlY2lmeWluZyBKU19OVU1CRVIgZm9yIHRoZSBqc3R5cGUgY2F1c2VzIHRoZSBnZW5lcmF0ZWQgSmF2YVNjcmlwdCBjb2RlIHRvCiB1c2UgdGhlIEphdmFTY3JpcHQgIm51bWJlciIgdHlwZS4gIFRoZSBiZWhhdmlvciBvZiB0aGUgZGVmYXVsdCBvcHRpb24KIEpTX05PUk1BTCBpcyBpbXBsZW1lbnRhdGlvbiBkZXBlbmRlbnQuCgogVGhpcyBvcHRpb24gaXMgYW4gZW51bSB0byBwZXJtaXQgYWRkaXRpb25hbCB0eXBlcyB0byBiZSBhZGRlZCwgZS5nLgogZ29vZy5tYXRoLkludGVnZXIuCgoNCgUEDAICBBIE7wQCCgoNCgUEDAICBhIE7wQLEQoNCgUEDAICARIE7wQSGAoNCgUEDAICAxIE7wQbHAoNCgUEDAICCBIE7wQdMgoNCgUEDAICBxIE7wQoMQoOCgQEDAQBEgbwBAL5BAMKDQoFBAwEAQESBPAEBw0KJwoGBAwEAQIAEgTyBAQSGhcgVXNlIHRoZSBkZWZhdWx0IHR5cGUuCgoPCgcEDAQBAgABEgTyBAQNCg8KBwQMBAECAAISBPIEEBEKKQoGBAwEAQIBEgT1BAQSGhkgVXNlIEphdmFTY3JpcHQgc3RyaW5ncy4KCg8KBwQMBAECAQESBPUEBA0KDwoHBAwEAQIBAhIE9QQQEQopCgYEDAQBAgISBPgEBBIaGSBVc2UgSmF2YVNjcmlwdCBudW1iZXJzLgoKDwoHBAwEAQICARIE+AQEDQoPCgcEDAQBAgICEgT4BBARCv8NCgQEDAIDEgSZBQIrGvANIFNob3VsZCB0aGlzIGZpZWxkIGJlIHBhcnNlZCBsYXppbHk/ICBMYXp5IGFwcGxpZXMgb25seSB0byBtZXNzYWdlLXR5cGUKIGZpZWxkcy4gIEl0IG1lYW5zIHRoYXQgd2hlbiB0aGUgb3V0ZXIgbWVzc2FnZSBpcyBpbml0aWFsbHkgcGFyc2VkLCB0aGUKIGlubmVyIG1lc3NhZ2UncyBjb250ZW50cyB3aWxsIG5vdCBiZSBwYXJzZWQgYnV0IGluc3RlYWQgc3RvcmVkIGluIGVuY29kZWQKIGZvcm0uICBUaGUgaW5uZXIgbWVzc2FnZSB3aWxsIGFjdHVhbGx5IGJlIHBhcnNlZCB3aGVuIGl0IGlzIGZpcnN0IGFjY2Vzc2VkLgoKIFRoaXMgaXMgb25seSBhIGhpbnQuICBJbXBsZW1lbnRhdGlvbnMgYXJlIGZyZWUgdG8gY2hvb3NlIHdoZXRoZXIgdG8gdXNlCiBlYWdlciBvciBsYXp5IHBhcnNpbmcgcmVnYXJkbGVzcyBvZiB0aGUgdmFsdWUgb2YgdGhpcyBvcHRpb24uICBIb3dldmVyLAogc2V0dGluZyB0aGlzIG9wdGlvbiB0cnVlIHN1Z2dlc3RzIHRoYXQgdGhlIHByb3RvY29sIGF1dGhvciBiZWxpZXZlcyB0aGF0CiB1c2luZyBsYXp5IHBhcnNpbmcgb24gdGhpcyBmaWVsZCBpcyB3b3J0aCB0aGUgYWRkaXRpb25hbCBib29ra2VlcGluZwogb3ZlcmhlYWQgdHlwaWNhbGx5IG5lZWRlZCB0byBpbXBsZW1lbnQgaXQuCgogVGhpcyBvcHRpb24gZG9lcyBub3QgYWZmZWN0IHRoZSBwdWJsaWMgaW50ZXJmYWNlIG9mIGFueSBnZW5lcmF0ZWQgY29kZTsKIGFsbCBtZXRob2Qgc2lnbmF0dXJlcyByZW1haW4gdGhlIHNhbWUuICBGdXJ0aGVybW9yZSwgdGhyZWFkLXNhZmV0eSBvZiB0aGUKIGludGVyZmFjZSBpcyBub3QgYWZmZWN0ZWQgYnkgdGhpcyBvcHRpb247IGNvbnN0IG1ldGhvZHMgcmVtYWluIHNhZmUgdG8KIGNhbGwgZnJvbSBtdWx0aXBsZSB0aHJlYWRzIGNvbmN1cnJlbnRseSwgd2hpbGUgbm9uLWNvbnN0IG1ldGhvZHMgY29udGludWUKIHRvIHJlcXVpcmUgZXhjbHVzaXZlIGFjY2Vzcy4KCiBOb3RlIHRoYXQgaW1wbGVtZW50YXRpb25zIG1heSBjaG9vc2Ugbm90IHRvIGNoZWNrIHJlcXVpcmVkIGZpZWxkcyB3aXRoaW4KIGEgbGF6eSBzdWItbWVzc2FnZS4gIFRoYXQgaXMsIGNhbGxpbmcgSXNJbml0aWFsaXplZCgpIG9uIHRoZSBvdXRlciBtZXNzYWdlCiBtYXkgcmV0dXJuIHRydWUgZXZlbiBpZiB0aGUgaW5uZXIgbWVzc2FnZSBoYXMgbWlzc2luZyByZXF1aXJlZCBmaWVsZHMuCiBUaGlzIGlzIG5lY2Vzc2FyeSBiZWNhdXNlIG90aGVyd2lzZSB0aGUgaW5uZXIgbWVzc2FnZSB3b3VsZCBoYXZlIHRvIGJlCiBwYXJzZWQgaW4gb3JkZXIgdG8gcGVyZm9ybSB0aGUgY2hlY2ssIGRlZmVhdGluZyB0aGUgcHVycG9zZSBvZiBsYXp5CiBwYXJzaW5nLiAgQW4gaW1wbGVtZW50YXRpb24gd2hpY2ggY2hvb3NlcyBub3QgdG8gY2hlY2sgcmVxdWlyZWQgZmllbGRzCiBtdXN0IGJlIGNvbnNpc3RlbnQgYWJvdXQgaXQuICBUaGF0IGlzLCBmb3IgYW55IHBhcnRpY3VsYXIgc3ViLW1lc3NhZ2UsIHRoZQogaW1wbGVtZW50YXRpb24gbXVzdCBlaXRoZXIgKmFsd2F5cyogY2hlY2sgaXRzIHJlcXVpcmVkIGZpZWxkcywgb3IgKm5ldmVyKgogY2hlY2sgaXRzIHJlcXVpcmVkIGZpZWxkcywgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB0aGUgbWVzc2FnZSBoYXMKIGJlZW4gcGFyc2VkLgoKIEFzIG9mIE1heSAyMDIyLCBsYXp5IHZlcmlmaWVzIHRoZSBjb250ZW50cyBvZiB0aGUgYnl0ZSBzdHJlYW0gZHVyaW5nCiBwYXJzaW5nLiAgQW4gaW52YWxpZCBieXRlIHN0cmVhbSB3aWxsIGNhdXNlIHRoZSBvdmVyYWxsIHBhcnNpbmcgdG8gZmFpbC4KCg0KBQQMAgMEEgSZBQIKCg0KBQQMAgMFEgSZBQsPCg0KBQQMAgMBEgSZBRAUCg0KBQQMAgMDEgSZBRcYCg0KBQQMAgMIEgSZBRkqCg0KBQQMAgMHEgSZBSQpCq8BCgQEDAIEEgSeBQI3GqABIHVudmVyaWZpZWRfbGF6eSBkb2VzIG5vIGNvcnJlY3RuZXNzIGNoZWNrcyBvbiB0aGUgYnl0ZSBzdHJlYW0uIFRoaXMgc2hvdWxkCiBvbmx5IGJlIHVzZWQgd2hlcmUgbGF6eSB3aXRoIHZlcmlmaWNhdGlvbiBpcyBwcm9oaWJpdGl2ZSBmb3IgcGVyZm9ybWFuY2UKIHJlYXNvbnMuCgoNCgUEDAIEBBIEngUCCgoNCgUEDAIEBRIEngULDwoNCgUEDAIEARIEngUQHwoNCgUEDAIEAxIEngUiJAoNCgUEDAIECBIEngUlNgoNCgUEDAIEBxIEngUwNQroAQoEBAwCBRIEpAUCMRrZASBJcyB0aGlzIGZpZWxkIGRlcHJlY2F0ZWQ/CiBEZXBlbmRpbmcgb24gdGhlIHRhcmdldCBwbGF0Zm9ybSwgdGhpcyBjYW4gZW1pdCBEZXByZWNhdGVkIGFubm90YXRpb25zCiBmb3IgYWNjZXNzb3JzLCBvciBpdCB3aWxsIGJlIGNvbXBsZXRlbHkgaWdub3JlZDsgaW4gdGhlIHZlcnkgbGVhc3QsIHRoaXMKIGlzIGEgZm9ybWFsaXphdGlvbiBmb3IgZGVwcmVjYXRpbmcgZmllbGRzLgoKDQoFBAwCBQQSBKQFAgoKDQoFBAwCBQUSBKQFCw8KDQoFBAwCBQESBKQFEBoKDQoFBAwCBQMSBKQFHR4KDQoFBAwCBQgSBKQFHzAKDQoFBAwCBQcSBKQFKi8KPwoEBAwCBhIEpwUCLBoxIEZvciBHb29nbGUtaW50ZXJuYWwgbWlncmF0aW9uIG9ubHkuIERvIG5vdCB1c2UuCgoNCgUEDAIGBBIEpwUCCgoNCgUEDAIGBRIEpwULDwoNCgUEDAIGARIEpwUQFAoNCgUEDAIGAxIEpwUXGQoNCgUEDAIGCBIEpwUaKwoNCgUEDAIGBxIEpwUlKgqXAQoEBAwCBxIEqwUCNBqIASBJbmRpY2F0ZSB0aGF0IHRoZSBmaWVsZCB2YWx1ZSBzaG91bGQgbm90IGJlIHByaW50ZWQgb3V0IHdoZW4gdXNpbmcgZGVidWcKIGZvcm1hdHMsIGUuZy4gd2hlbiB0aGUgZmllbGQgY29udGFpbnMgc2Vuc2l0aXZlIGNyZWRlbnRpYWxzLgoKDQoFBAwCBwQSBKsFAgoKDQoFBAwCBwUSBKsFCw8KDQoFBAwCBwESBKsFEBwKDQoFBAwCBwMSBKsFHyEKDQoFBAwCBwgSBKsFIjMKDQoFBAwCBwcSBKsFLTIKxQEKBAQMBAISBrAFArQFAxq0ASBJZiBzZXQgdG8gUkVURU5USU9OX1NPVVJDRSwgdGhlIG9wdGlvbiB3aWxsIGJlIG9taXR0ZWQgZnJvbSB0aGUgYmluYXJ5LgogTm90ZTogYXMgb2YgSmFudWFyeSAyMDIzLCBzdXBwb3J0IGZvciB0aGlzIGlzIGluIHByb2dyZXNzIGFuZCBkb2VzIG5vdCB5ZXQKIGhhdmUgYW4gZWZmZWN0IChiLzI2NDU5MzQ4OSkuCgoNCgUEDAQCARIEsAUHFgoOCgYEDAQCAgASBLEFBBoKDwoHBAwEAgIAARIEsQUEFQoPCgcEDAQCAgACEgSxBRgZCg4KBgQMBAICARIEsgUEGgoPCgcEDAQCAgEBEgSyBQQVCg8KBwQMBAICAQISBLIFGBkKDgoGBAwEAgICEgSzBQQZCg8KBwQMBAICAgESBLMFBBQKDwoHBAwEAgICAhIEswUXGAoMCgQEDAIIEgS2BQIqCg0KBQQMAggEEgS2BQIKCg0KBQQMAggGEgS2BQsaCg0KBQQMAggBEgS2BRskCg0KBQQMAggDEgS2BScpCq0CCgQEDAQDEga8BQLHBQManAIgVGhpcyBpbmRpY2F0ZXMgdGhlIHR5cGVzIG9mIGVudGl0aWVzIHRoYXQgdGhlIGZpZWxkIG1heSBhcHBseSB0byB3aGVuIHVzZWQKIGFzIGFuIG9wdGlvbi4gSWYgaXQgaXMgdW5zZXQsIHRoZW4gdGhlIGZpZWxkIG1heSBiZSBmcmVlbHkgdXNlZCBhcyBhbgogb3B0aW9uIG9uIGFueSBraW5kIG9mIGVudGl0eS4gTm90ZTogYXMgb2YgSmFudWFyeSAyMDIzLCBzdXBwb3J0IGZvciB0aGlzIGlzCiBpbiBwcm9ncmVzcyBhbmQgZG9lcyBub3QgeWV0IGhhdmUgYW4gZWZmZWN0IChiLzI2NDU5MzQ4OSkuCgoNCgUEDAQDARIEvAUHFwoOCgYEDAQDAgASBL0FBBwKDwoHBAwEAwIAARIEvQUEFwoPCgcEDAQDAgACEgS9BRobCg4KBgQMBAMCARIEvgUEGQoPCgcEDAQDAgEBEgS+BQQUCg8KBwQMBAMCAQISBL4FFxgKDgoGBAwEAwICEgS/BQQkCg8KBwQMBAMCAgESBL8FBB8KDwoHBAwEAwICAhIEvwUiIwoOCgYEDAQDAgMSBMAFBBwKDwoHBAwEAwIDARIEwAUEFwoPCgcEDAQDAgMCEgTABRobCg4KBgQMBAMCBBIEwQUEGgoPCgcEDAQDAgQBEgTBBQQVCg8KBwQMBAMCBAISBMEFGBkKDgoGBAwEAwIFEgTCBQQaCg8KBwQMBAMCBQESBMIFBBUKDwoHBAwEAwIFAhIEwgUYGQoOCgYEDAQDAgYSBMMFBBkKDwoHBAwEAwIGARIEwwUEFAoPCgcEDAQDAgYCEgTDBRcYCg4KBgQMBAMCBxIExAUEHwoPCgcEDAQDAgcBEgTEBQQaCg8KBwQMBAMCBwISBMQFHR4KDgoGBAwEAwIIEgTFBQQcCg8KBwQMBAMCCAESBMUFBBcKDwoHBAwEAwIIAhIExQUaGwoOCgYEDAQDAgkSBMYFBBsKDwoHBAwEAwIJARIExgUEFgoPCgcEDAQDAgkCEgTGBRkaCgwKBAQMAgkSBMkFAjwKDQoFBAwCCQQSBMkFAgoKDQoFBAwCCQYSBMkFCxsKDQoFBAwCCQESBMkFHCIKDQoFBAwCCQMSBMkFJScKDQoFBAwCCQgSBMkFKDsKDgoGBAwCCQgDEgTJBSk6CgwKBAQMAgoSBMoFAikKDQoFBAwCCgQSBMoFAgoKDQoFBAwCCgYSBMoFCxsKDQoFBAwCCgESBMoFHCMKDQoFBAwCCgMSBMoFJigKTwoEBAwCCxIEzQUCOhpBIFRoZSBwYXJzZXIgc3RvcmVzIG9wdGlvbnMgaXQgZG9lc24ndCByZWNvZ25pemUgaGVyZS4gU2VlIGFib3ZlLgoKDQoFBAwCCwQSBM0FAgoKDQoFBAwCCwYSBM0FCx4KDQoFBAwCCwESBM0FHzMKDQoFBAwCCwMSBM0FNjkKWgoDBAwFEgTQBQIZGk0gQ2xpZW50cyBjYW4gZGVmaW5lIGN1c3RvbSBvcHRpb25zIGluIGV4dGVuc2lvbnMgb2YgdGhpcyBtZXNzYWdlLiBTZWUgYWJvdmUuCgoMCgQEDAUAEgTQBQ0YCg0KBQQMBQABEgTQBQ0RCg0KBQQMBQACEgTQBRUYChwKAwQMCRIE0gUCDSIPIHJlbW92ZWQganR5cGUKCgwKBAQMCQASBNIFCwwKDQoFBAwJAAESBNIFCwwKDQoFBAwJAAISBNIFCwwKDAoCBA0SBtUFANsFAQoLCgMEDQESBNUFCBQKTwoEBA0CABIE1wUCOhpBIFRoZSBwYXJzZXIgc3RvcmVzIG9wdGlvbnMgaXQgZG9lc24ndCByZWNvZ25pemUgaGVyZS4gU2VlIGFib3ZlLgoKDQoFBA0CAAQSBNcFAgoKDQoFBA0CAAYSBNcFCx4KDQoFBA0CAAESBNcFHzMKDQoFBA0CAAMSBNcFNjkKWgoDBA0FEgTaBQIZGk0gQ2xpZW50cyBjYW4gZGVmaW5lIGN1c3RvbSBvcHRpb25zIGluIGV4dGVuc2lvbnMgb2YgdGhpcyBtZXNzYWdlLiBTZWUgYWJvdmUuCgoMCgQEDQUAEgTaBQ0YCg0KBQQNBQABEgTaBQ0RCg0KBQQNBQACEgTaBRUYCgwKAgQOEgbdBQD4BQEKCwoDBA4BEgTdBQgTCmAKBAQOAgASBOEFAiAaUiBTZXQgdGhpcyBvcHRpb24gdG8gdHJ1ZSB0byBhbGxvdyBtYXBwaW5nIGRpZmZlcmVudCB0YWcgbmFtZXMgdG8gdGhlIHNhbWUKIHZhbHVlLgoKDQoFBA4CAAQSBOEFAgoKDQoFBA4CAAUSBOEFCw8KDQoFBA4CAAESBOEFEBsKDQoFBA4CAAMSBOEFHh8K5QEKBAQOAgESBOcFAjEa1gEgSXMgdGhpcyBlbnVtIGRlcHJlY2F0ZWQ/CiBEZXBlbmRpbmcgb24gdGhlIHRhcmdldCBwbGF0Zm9ybSwgdGhpcyBjYW4gZW1pdCBEZXByZWNhdGVkIGFubm90YXRpb25zCiBmb3IgdGhlIGVudW0sIG9yIGl0IHdpbGwgYmUgY29tcGxldGVseSBpZ25vcmVkOyBpbiB0aGUgdmVyeSBsZWFzdCwgdGhpcwogaXMgYSBmb3JtYWxpemF0aW9uIGZvciBkZXByZWNhdGluZyBlbnVtcy4KCg0KBQQOAgEEEgTnBQIKCg0KBQQOAgEFEgTnBQsPCg0KBQQOAgEBEgTnBRAaCg0KBQQOAgEDEgTnBR0eCg0KBQQOAgEIEgTnBR8wCg0KBQQOAgEHEgTnBSovCh8KAwQOCRIE6QUCDSISIGphdmFuYW5vX2FzX2xpdGUKCgwKBAQOCQASBOkFCwwKDQoFBA4JAAESBOkFCwwKDQoFBA4JAAISBOkFCwwK1QIKBAQOAgISBPEFAk8axgIgRW5hYmxlIHRoZSBsZWdhY3kgaGFuZGxpbmcgb2YgSlNPTiBmaWVsZCBuYW1lIGNvbmZsaWN0cy4gIFRoaXMgbG93ZXJjYXNlcwogYW5kIHN0cmlwcyB1bmRlcnNjb3JlZCBmcm9tIHRoZSBmaWVsZHMgYmVmb3JlIGNvbXBhcmlzb24gaW4gcHJvdG8zIG9ubHkuCiBUaGUgbmV3IGJlaGF2aW9yIHRha2VzIGBqc29uX25hbWVgIGludG8gYWNjb3VudCBhbmQgYXBwbGllcyB0byBwcm90bzIgYXMKIHdlbGwuCiBUT0RPKGIvMjYxNzUwMTkwKSBSZW1vdmUgdGhpcyBsZWdhY3kgYmVoYXZpb3Igb25jZSBkb3duc3RyZWFtIHRlYW1zIGhhdmUKIGhhZCB0aW1lIHRvIG1pZ3JhdGUuCgoNCgUEDgICBBIE8QUCCgoNCgUEDgICBRIE8QULDwoNCgUEDgICARIE8QUQNgoNCgUEDgICAxIE8QU5OgoNCgUEDgICCBIE8QU7TgoOCgYEDgICCAMSBPEFPE0KTwoEBA4CAxIE9AUCOhpBIFRoZSBwYXJzZXIgc3RvcmVzIG9wdGlvbnMgaXQgZG9lc24ndCByZWNvZ25pemUgaGVyZS4gU2VlIGFib3ZlLgoKDQoFBA4CAwQSBPQFAgoKDQoFBA4CAwYSBPQFCx4KDQoFBA4CAwESBPQFHzMKDQoFBA4CAwMSBPQFNjkKWgoDBA4FEgT3BQIZGk0gQ2xpZW50cyBjYW4gZGVmaW5lIGN1c3RvbSBvcHRpb25zIGluIGV4dGVuc2lvbnMgb2YgdGhpcyBtZXNzYWdlLiBTZWUgYWJvdmUuCgoMCgQEDgUAEgT3BQ0YCg0KBQQOBQABEgT3BQ0RCg0KBQQOBQACEgT3BRUYCgwKAgQPEgb6BQCGBgEKCwoDBA8BEgT6BQgYCvcBCgQEDwIAEgT/BQIxGugBIElzIHRoaXMgZW51bSB2YWx1ZSBkZXByZWNhdGVkPwogRGVwZW5kaW5nIG9uIHRoZSB0YXJnZXQgcGxhdGZvcm0sIHRoaXMgY2FuIGVtaXQgRGVwcmVjYXRlZCBhbm5vdGF0aW9ucwogZm9yIHRoZSBlbnVtIHZhbHVlLCBvciBpdCB3aWxsIGJlIGNvbXBsZXRlbHkgaWdub3JlZDsgaW4gdGhlIHZlcnkgbGVhc3QsCiB0aGlzIGlzIGEgZm9ybWFsaXphdGlvbiBmb3IgZGVwcmVjYXRpbmcgZW51bSB2YWx1ZXMuCgoNCgUEDwIABBIE/wUCCgoNCgUEDwIABRIE/wULDwoNCgUEDwIAARIE/wUQGgoNCgUEDwIAAxIE/wUdHgoNCgUEDwIACBIE/wUfMAoNCgUEDwIABxIE/wUqLwpPCgQEDwIBEgSCBgI6GkEgVGhlIHBhcnNlciBzdG9yZXMgb3B0aW9ucyBpdCBkb2Vzbid0IHJlY29nbml6ZSBoZXJlLiBTZWUgYWJvdmUuCgoNCgUEDwIBBBIEggYCCgoNCgUEDwIBBhIEggYLHgoNCgUEDwIBARIEggYfMwoNCgUEDwIBAxIEggY2OQpaCgMEDwUSBIUGAhkaTSBDbGllbnRzIGNhbiBkZWZpbmUgY3VzdG9tIG9wdGlvbnMgaW4gZXh0ZW5zaW9ucyBvZiB0aGlzIG1lc3NhZ2UuIFNlZSBhYm92ZS4KCgwKBAQPBQASBIUGDRgKDQoFBA8FAAESBIUGDREKDQoFBA8FAAISBIUGFRgKDAoCBBASBogGAJoGAQoLCgMEEAESBIgGCBYK2QMKBAQQAgASBJMGAjIa3wEgSXMgdGhpcyBzZXJ2aWNlIGRlcHJlY2F0ZWQ/CiBEZXBlbmRpbmcgb24gdGhlIHRhcmdldCBwbGF0Zm9ybSwgdGhpcyBjYW4gZW1pdCBEZXByZWNhdGVkIGFubm90YXRpb25zCiBmb3IgdGhlIHNlcnZpY2UsIG9yIGl0IHdpbGwgYmUgY29tcGxldGVseSBpZ25vcmVkOyBpbiB0aGUgdmVyeSBsZWFzdCwKIHRoaXMgaXMgYSBmb3JtYWxpemF0aW9uIGZvciBkZXByZWNhdGluZyBzZXJ2aWNlcy4KMugBIE5vdGU6ICBGaWVsZCBudW1iZXJzIDEgdGhyb3VnaCAzMiBhcmUgcmVzZXJ2ZWQgZm9yIEdvb2dsZSdzIGludGVybmFsIFJQQwogICBmcmFtZXdvcmsuICBXZSBhcG9sb2dpemUgZm9yIGhvYXJkaW5nIHRoZXNlIG51bWJlcnMgdG8gb3Vyc2VsdmVzLCBidXQKICAgd2Ugd2VyZSBhbHJlYWR5IHVzaW5nIHRoZW0gbG9uZyBiZWZvcmUgd2UgZGVjaWRlZCB0byByZWxlYXNlIFByb3RvY29sCiAgIEJ1ZmZlcnMuCgoNCgUEEAIABBIEkwYCCgoNCgUEEAIABRIEkwYLDwoNCgUEEAIAARIEkwYQGgoNCgUEEAIAAxIEkwYdHwoNCgUEEAIACBIEkwYgMQoNCgUEEAIABxIEkwYrMApPCgQEEAIBEgSWBgI6GkEgVGhlIHBhcnNlciBzdG9yZXMgb3B0aW9ucyBpdCBkb2Vzbid0IHJlY29nbml6ZSBoZXJlLiBTZWUgYWJvdmUuCgoNCgUEEAIBBBIElgYCCgoNCgUEEAIBBhIElgYLHgoNCgUEEAIBARIElgYfMwoNCgUEEAIBAxIElgY2OQpaCgMEEAUSBJkGAhkaTSBDbGllbnRzIGNhbiBkZWZpbmUgY3VzdG9tIG9wdGlvbnMgaW4gZXh0ZW5zaW9ucyBvZiB0aGlzIG1lc3NhZ2UuIFNlZSBhYm92ZS4KCgwKBAQQBQASBJkGDRgKDQoFBBAFAAESBJkGDREKDQoFBBAFAAISBJkGFRgKDAoCBBESBpwGALkGAQoLCgMEEQESBJwGCBUK1gMKBAQRAgASBKcGAjIa3AEgSXMgdGhpcyBtZXRob2QgZGVwcmVjYXRlZD8KIERlcGVuZGluZyBvbiB0aGUgdGFyZ2V0IHBsYXRmb3JtLCB0aGlzIGNhbiBlbWl0IERlcHJlY2F0ZWQgYW5ub3RhdGlvbnMKIGZvciB0aGUgbWV0aG9kLCBvciBpdCB3aWxsIGJlIGNvbXBsZXRlbHkgaWdub3JlZDsgaW4gdGhlIHZlcnkgbGVhc3QsCiB0aGlzIGlzIGEgZm9ybWFsaXphdGlvbiBmb3IgZGVwcmVjYXRpbmcgbWV0aG9kcy4KMugBIE5vdGU6ICBGaWVsZCBudW1iZXJzIDEgdGhyb3VnaCAzMiBhcmUgcmVzZXJ2ZWQgZm9yIEdvb2dsZSdzIGludGVybmFsIFJQQwogICBmcmFtZXdvcmsuICBXZSBhcG9sb2dpemUgZm9yIGhvYXJkaW5nIHRoZXNlIG51bWJlcnMgdG8gb3Vyc2VsdmVzLCBidXQKICAgd2Ugd2VyZSBhbHJlYWR5IHVzaW5nIHRoZW0gbG9uZyBiZWZvcmUgd2UgZGVjaWRlZCB0byByZWxlYXNlIFByb3RvY29sCiAgIEJ1ZmZlcnMuCgoNCgUEEQIABBIEpwYCCgoNCgUEEQIABRIEpwYLDwoNCgUEEQIAARIEpwYQGgoNCgUEEQIAAxIEpwYdHwoNCgUEEQIACBIEpwYgMQoNCgUEEQIABxIEpwYrMArwAQoEBBEEABIGrAYCsAYDGt8BIElzIHRoaXMgbWV0aG9kIHNpZGUtZWZmZWN0LWZyZWUgKG9yIHNhZmUgaW4gSFRUUCBwYXJsYW5jZSksIG9yIGlkZW1wb3RlbnQsCiBvciBuZWl0aGVyPyBIVFRQIGJhc2VkIFJQQyBpbXBsZW1lbnRhdGlvbiBtYXkgY2hvb3NlIEdFVCB2ZXJiIGZvciBzYWZlCiBtZXRob2RzLCBhbmQgUFVUIHZlcmIgZm9yIGlkZW1wb3RlbnQgbWV0aG9kcyBpbnN0ZWFkIG9mIHRoZSBkZWZhdWx0IFBPU1QuCgoNCgUEEQQAARIErAYHFwoOCgYEEQQAAgASBK0GBBwKDwoHBBEEAAIAARIErQYEFwoPCgcEEQQAAgACEgStBhobCiQKBgQRBAACARIErgYEGCIUIGltcGxpZXMgaWRlbXBvdGVudAoKDwoHBBEEAAIBARIErgYEEwoPCgcEEQQAAgECEgSuBhYXCjcKBgQRBAACAhIErwYEEyInIGlkZW1wb3RlbnQsIGJ1dCBtYXkgaGF2ZSBzaWRlIGVmZmVjdHMKCg8KBwQRBAACAgESBK8GBA4KDwoHBBEEAAICAhIErwYREgoOCgQEEQIBEgaxBgKyBiYKDQoFBBECAQQSBLEGAgoKDQoFBBECAQYSBLEGCxsKDQoFBBECAQESBLEGHC0KDQoFBBECAQMSBLEGMDIKDQoFBBECAQgSBLIGBiUKDQoFBBECAQcSBLIGESQKTwoEBBECAhIEtQYCOhpBIFRoZSBwYXJzZXIgc3RvcmVzIG9wdGlvbnMgaXQgZG9lc24ndCByZWNvZ25pemUgaGVyZS4gU2VlIGFib3ZlLgoKDQoFBBECAgQSBLUGAgoKDQoFBBECAgYSBLUGCx4KDQoFBBECAgESBLUGHzMKDQoFBBECAgMSBLUGNjkKWgoDBBEFEgS4BgIZGk0gQ2xpZW50cyBjYW4gZGVmaW5lIGN1c3RvbSBvcHRpb25zIGluIGV4dGVuc2lvbnMgb2YgdGhpcyBtZXNzYWdlLiBTZWUgYWJvdmUuCgoMCgQEEQUAEgS4Bg0YCg0KBQQRBQABEgS4Bg0RCg0KBQQRBQACEgS4BhUYCosDCgIEEhIGwQYA1QYBGvwCIEEgbWVzc2FnZSByZXByZXNlbnRpbmcgYSBvcHRpb24gdGhlIHBhcnNlciBkb2VzIG5vdCByZWNvZ25pemUuIFRoaXMgb25seQogYXBwZWFycyBpbiBvcHRpb25zIHByb3RvcyBjcmVhdGVkIGJ5IHRoZSBjb21waWxlcjo6UGFyc2VyIGNsYXNzLgogRGVzY3JpcHRvclBvb2wgcmVzb2x2ZXMgdGhlc2Ugd2hlbiBidWlsZGluZyBEZXNjcmlwdG9yIG9iamVjdHMuIFRoZXJlZm9yZSwKIG9wdGlvbnMgcHJvdG9zIGluIGRlc2NyaXB0b3Igb2JqZWN0cyAoZS5nLiByZXR1cm5lZCBieSBEZXNjcmlwdG9yOjpvcHRpb25zKCksCiBvciBwcm9kdWNlZCBieSBEZXNjcmlwdG9yOjpDb3B5VG8oKSkgd2lsbCBuZXZlciBoYXZlIFVuaW50ZXJwcmV0ZWRPcHRpb25zCiBpbiB0aGVtLgoKCwoDBBIBEgTBBggbCssCCgQEEgMAEgbHBgLKBgMaugIgVGhlIG5hbWUgb2YgdGhlIHVuaW50ZXJwcmV0ZWQgb3B0aW9uLiAgRWFjaCBzdHJpbmcgcmVwcmVzZW50cyBhIHNlZ21lbnQgaW4KIGEgZG90LXNlcGFyYXRlZCBuYW1lLiAgaXNfZXh0ZW5zaW9uIGlzIHRydWUgaWZmIGEgc2VnbWVudCByZXByZXNlbnRzIGFuCiBleHRlbnNpb24gKGRlbm90ZWQgd2l0aCBwYXJlbnRoZXNlcyBpbiBvcHRpb25zIHNwZWNzIGluIC5wcm90byBmaWxlcykuCiBFLmcuLHsgWyJmb28iLCBmYWxzZV0sIFsiYmFyLmJheiIsIHRydWVdLCBbIm1vbyIsIGZhbHNlXSB9IHJlcHJlc2VudHMKICJmb28uKGJhci5iYXopLm1vbyIuCgoNCgUEEgMAARIExwYKEgoOCgYEEgMAAgASBMgGBCIKDwoHBBIDAAIABBIEyAYEDAoPCgcEEgMAAgAFEgTIBg0TCg8KBwQSAwACAAESBMgGFB0KDwoHBBIDAAIAAxIEyAYgIQoOCgYEEgMAAgESBMkGBCMKDwoHBBIDAAIBBBIEyQYEDAoPCgcEEgMAAgEFEgTJBg0RCg8KBwQSAwACAQESBMkGEh4KDwoHBBIDAAIBAxIEyQYhIgoMCgQEEgIAEgTLBgIdCg0KBQQSAgAEEgTLBgIKCg0KBQQSAgAGEgTLBgsTCg0KBQQSAgABEgTLBhQYCg0KBQQSAgADEgTLBhscCpwBCgQEEgIBEgTPBgInGo0BIFRoZSB2YWx1ZSBvZiB0aGUgdW5pbnRlcnByZXRlZCBvcHRpb24sIGluIHdoYXRldmVyIHR5cGUgdGhlIHRva2VuaXplcgogaWRlbnRpZmllZCBpdCBhcyBkdXJpbmcgcGFyc2luZy4gRXhhY3RseSBvbmUgb2YgdGhlc2Ugc2hvdWxkIGJlIHNldC4KCg0KBQQSAgEEEgTPBgIKCg0KBQQSAgEFEgTPBgsRCg0KBQQSAgEBEgTPBhIiCg0KBQQSAgEDEgTPBiUmCgwKBAQSAgISBNAGAikKDQoFBBICAgQSBNAGAgoKDQoFBBICAgUSBNAGCxEKDQoFBBICAgESBNAGEiQKDQoFBBICAgMSBNAGJygKDAoEBBICAxIE0QYCKAoNCgUEEgIDBBIE0QYCCgoNCgUEEgIDBRIE0QYLEAoNCgUEEgIDARIE0QYRIwoNCgUEEgIDAxIE0QYmJwoMCgQEEgIEEgTSBgIjCg0KBQQSAgQEEgTSBgIKCg0KBQQSAgQFEgTSBgsRCg0KBQQSAgQBEgTSBhIeCg0KBQQSAgQDEgTSBiEiCgwKBAQSAgUSBNMGAiIKDQoFBBICBQQSBNMGAgoKDQoFBBICBQUSBNMGCxAKDQoFBBICBQESBNMGER0KDQoFBBICBQMSBNMGICEKDAoEBBICBhIE1AYCJgoNCgUEEgIGBBIE1AYCCgoNCgUEEgIGBRIE1AYLEQoNCgUEEgIGARIE1AYSIQoNCgUEEgIGAxIE1AYkJQraAQoCBBMSBtwGAN0HARpqIEVuY2Fwc3VsYXRlcyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgb3JpZ2luYWwgc291cmNlIGZpbGUgZnJvbSB3aGljaCBhCiBGaWxlRGVzY3JpcHRvclByb3RvIHdhcyBnZW5lcmF0ZWQuCjJgID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KIE9wdGlvbmFsIHNvdXJjZSBjb2RlIGluZm8KCgsKAwQTARIE3AYIFgqCEQoEBBMCABIEiAcCIRrzECBBIExvY2F0aW9uIGlkZW50aWZpZXMgYSBwaWVjZSBvZiBzb3VyY2UgY29kZSBpbiBhIC5wcm90byBmaWxlIHdoaWNoCiBjb3JyZXNwb25kcyB0byBhIHBhcnRpY3VsYXIgZGVmaW5pdGlvbi4gIFRoaXMgaW5mb3JtYXRpb24gaXMgaW50ZW5kZWQKIHRvIGJlIHVzZWZ1bCB0byBJREVzLCBjb2RlIGluZGV4ZXJzLCBkb2N1bWVudGF0aW9uIGdlbmVyYXRvcnMsIGFuZCBzaW1pbGFyCiB0b29scy4KCiBGb3IgZXhhbXBsZSwgc2F5IHdlIGhhdmUgYSBmaWxlIGxpa2U6CiAgIG1lc3NhZ2UgRm9vIHsKICAgICBvcHRpb25hbCBzdHJpbmcgZm9vID0gMTsKICAgfQogTGV0J3MgbG9vayBhdCBqdXN0IHRoZSBmaWVsZCBkZWZpbml0aW9uOgogICBvcHRpb25hbCBzdHJpbmcgZm9vID0gMTsKICAgXiAgICAgICBeXiAgICAgXl4gIF4gIF5eXgogICBhICAgICAgIGJjICAgICBkZSAgZiAgZ2hpCiBXZSBoYXZlIHRoZSBmb2xsb3dpbmcgbG9jYXRpb25zOgogICBzcGFuICAgcGF0aCAgICAgICAgICAgICAgIHJlcHJlc2VudHMKICAgW2EsaSkgIFsgNCwgMCwgMiwgMCBdICAgICBUaGUgd2hvbGUgZmllbGQgZGVmaW5pdGlvbi4KICAgW2EsYikgIFsgNCwgMCwgMiwgMCwgNCBdICBUaGUgbGFiZWwgKG9wdGlvbmFsKS4KICAgW2MsZCkgIFsgNCwgMCwgMiwgMCwgNSBdICBUaGUgdHlwZSAoc3RyaW5nKS4KICAgW2UsZikgIFsgNCwgMCwgMiwgMCwgMSBdICBUaGUgbmFtZSAoZm9vKS4KICAgW2csaCkgIFsgNCwgMCwgMiwgMCwgMyBdICBUaGUgbnVtYmVyICgxKS4KCiBOb3RlczoKIC0gQSBsb2NhdGlvbiBtYXkgcmVmZXIgdG8gYSByZXBlYXRlZCBmaWVsZCBpdHNlbGYgKGkuZS4gbm90IHRvIGFueQogICBwYXJ0aWN1bGFyIGluZGV4IHdpdGhpbiBpdCkuICBUaGlzIGlzIHVzZWQgd2hlbmV2ZXIgYSBzZXQgb2YgZWxlbWVudHMgYXJlCiAgIGxvZ2ljYWxseSBlbmNsb3NlZCBpbiBhIHNpbmdsZSBjb2RlIHNlZ21lbnQuICBGb3IgZXhhbXBsZSwgYW4gZW50aXJlCiAgIGV4dGVuZCBibG9jayAocG9zc2libHkgY29udGFpbmluZyBtdWx0aXBsZSBleHRlbnNpb24gZGVmaW5pdGlvbnMpIHdpbGwKICAgaGF2ZSBhbiBvdXRlciBsb2NhdGlvbiB3aG9zZSBwYXRoIHJlZmVycyB0byB0aGUgImV4dGVuc2lvbnMiIHJlcGVhdGVkCiAgIGZpZWxkIHdpdGhvdXQgYW4gaW5kZXguCiAtIE11bHRpcGxlIGxvY2F0aW9ucyBtYXkgaGF2ZSB0aGUgc2FtZSBwYXRoLiAgVGhpcyBoYXBwZW5zIHdoZW4gYSBzaW5nbGUKICAgbG9naWNhbCBkZWNsYXJhdGlvbiBpcyBzcHJlYWQgb3V0IGFjcm9zcyBtdWx0aXBsZSBwbGFjZXMuICBUaGUgbW9zdAogICBvYnZpb3VzIGV4YW1wbGUgaXMgdGhlICJleHRlbmQiIGJsb2NrIGFnYWluIC0tIHRoZXJlIG1heSBiZSBtdWx0aXBsZQogICBleHRlbmQgYmxvY2tzIGluIHRoZSBzYW1lIHNjb3BlLCBlYWNoIG9mIHdoaWNoIHdpbGwgaGF2ZSB0aGUgc2FtZSBwYXRoLgogLSBBIGxvY2F0aW9uJ3Mgc3BhbiBpcyBub3QgYWx3YXlzIGEgc3Vic2V0IG9mIGl0cyBwYXJlbnQncyBzcGFuLiAgRm9yCiAgIGV4YW1wbGUsIHRoZSAiZXh0ZW5kZWUiIG9mIGFuIGV4dGVuc2lvbiBkZWNsYXJhdGlvbiBhcHBlYXJzIGF0IHRoZQogICBiZWdpbm5pbmcgb2YgdGhlICJleHRlbmQiIGJsb2NrIGFuZCBpcyBzaGFyZWQgYnkgYWxsIGV4dGVuc2lvbnMgd2l0aGluCiAgIHRoZSBibG9jay4KIC0gSnVzdCBiZWNhdXNlIGEgbG9jYXRpb24ncyBzcGFuIGlzIGEgc3Vic2V0IG9mIHNvbWUgb3RoZXIgbG9jYXRpb24ncyBzcGFuCiAgIGRvZXMgbm90IG1lYW4gdGhhdCBpdCBpcyBhIGRlc2NlbmRhbnQuICBGb3IgZXhhbXBsZSwgYSAiZ3JvdXAiIGRlZmluZXMKICAgYm90aCBhIHR5cGUgYW5kIGEgZmllbGQgaW4gYSBzaW5nbGUgZGVjbGFyYXRpb24uICBUaHVzLCB0aGUgbG9jYXRpb25zCiAgIGNvcnJlc3BvbmRpbmcgdG8gdGhlIHR5cGUgYW5kIGZpZWxkIGFuZCB0aGVpciBjb21wb25lbnRzIHdpbGwgb3ZlcmxhcC4KIC0gQ29kZSB3aGljaCB0cmllcyB0byBpbnRlcnByZXQgbG9jYXRpb25zIHNob3VsZCBwcm9iYWJseSBiZSBkZXNpZ25lZCB0bwogICBpZ25vcmUgdGhvc2UgdGhhdCBpdCBkb2Vzbid0IHVuZGVyc3RhbmQsIGFzIG1vcmUgdHlwZXMgb2YgbG9jYXRpb25zIGNvdWxkCiAgIGJlIHJlY29yZGVkIGluIHRoZSBmdXR1cmUuCgoNCgUEEwIABBIEiAcCCgoNCgUEEwIABhIEiAcLEwoNCgUEEwIAARIEiAcUHAoNCgUEEwIAAxIEiAcfIAoOCgQEEwMAEgaJBwLcBwMKDQoFBBMDAAESBIkHChIKiQcKBgQTAwACABIEoQcELBr4BiBJZGVudGlmaWVzIHdoaWNoIHBhcnQgb2YgdGhlIEZpbGVEZXNjcmlwdG9yUHJvdG8gd2FzIGRlZmluZWQgYXQgdGhpcwogbG9jYXRpb24uCgogRWFjaCBlbGVtZW50IGlzIGEgZmllbGQgbnVtYmVyIG9yIGFuIGluZGV4LiAgVGhleSBmb3JtIGEgcGF0aCBmcm9tCiB0aGUgcm9vdCBGaWxlRGVzY3JpcHRvclByb3RvIHRvIHRoZSBwbGFjZSB3aGVyZSB0aGUgZGVmaW5pdGlvbiBvY2N1cnMuCiBGb3IgZXhhbXBsZSwgdGhpcyBwYXRoOgogICBbIDQsIDMsIDIsIDcsIDEgXQogcmVmZXJzIHRvOgogICBmaWxlLm1lc3NhZ2VfdHlwZSgzKSAgLy8gNCwgMwogICAgICAgLmZpZWxkKDcpICAgICAgICAgLy8gMiwgNwogICAgICAgLm5hbWUoKSAgICAgICAgICAgLy8gMQogVGhpcyBpcyBiZWNhdXNlIEZpbGVEZXNjcmlwdG9yUHJvdG8ubWVzc2FnZV90eXBlIGhhcyBmaWVsZCBudW1iZXIgNDoKICAgcmVwZWF0ZWQgRGVzY3JpcHRvclByb3RvIG1lc3NhZ2VfdHlwZSA9IDQ7CiBhbmQgRGVzY3JpcHRvclByb3RvLmZpZWxkIGhhcyBmaWVsZCBudW1iZXIgMjoKICAgcmVwZWF0ZWQgRmllbGREZXNjcmlwdG9yUHJvdG8gZmllbGQgPSAyOwogYW5kIEZpZWxkRGVzY3JpcHRvclByb3RvLm5hbWUgaGFzIGZpZWxkIG51bWJlciAxOgogICBvcHRpb25hbCBzdHJpbmcgbmFtZSA9IDE7CgogVGh1cywgdGhlIGFib3ZlIHBhdGggZ2l2ZXMgdGhlIGxvY2F0aW9uIG9mIGEgZmllbGQgbmFtZS4gIElmIHdlIHJlbW92ZWQKIHRoZSBsYXN0IGVsZW1lbnQ6CiAgIFsgNCwgMywgMiwgNyBdCiB0aGlzIHBhdGggcmVmZXJzIHRvIHRoZSB3aG9sZSBmaWVsZCBkZWNsYXJhdGlvbiAoZnJvbSB0aGUgYmVnaW5uaW5nCiBvZiB0aGUgbGFiZWwgdG8gdGhlIHRlcm1pbmF0aW5nIHNlbWljb2xvbikuCgoPCgcEEwMAAgAEEgShBwQMCg8KBwQTAwACAAUSBKEHDRIKDwoHBBMDAAIAARIEoQcTFwoPCgcEEwMAAgADEgShBxobCg8KBwQTAwACAAgSBKEHHCsKEAoIBBMDAAIACAISBKEHHSoK0gIKBgQTAwACARIEqAcELBrBAiBBbHdheXMgaGFzIGV4YWN0bHkgdGhyZWUgb3IgZm91ciBlbGVtZW50czogc3RhcnQgbGluZSwgc3RhcnQgY29sdW1uLAogZW5kIGxpbmUgKG9wdGlvbmFsLCBvdGhlcndpc2UgYXNzdW1lZCBzYW1lIGFzIHN0YXJ0IGxpbmUpLCBlbmQgY29sdW1uLgogVGhlc2UgYXJlIHBhY2tlZCBpbnRvIGEgc2luZ2xlIGZpZWxkIGZvciBlZmZpY2llbmN5LiAgTm90ZSB0aGF0IGxpbmUKIGFuZCBjb2x1bW4gbnVtYmVycyBhcmUgemVyby1iYXNlZCAtLSB0eXBpY2FsbHkgeW91IHdpbGwgd2FudCB0byBhZGQKIDEgdG8gZWFjaCBiZWZvcmUgZGlzcGxheWluZyB0byBhIHVzZXIuCgoPCgcEEwMAAgEEEgSoBwQMCg8KBwQTAwACAQUSBKgHDRIKDwoHBBMDAAIBARIEqAcTFwoPCgcEEwMAAgEDEgSoBxobCg8KBwQTAwACAQgSBKgHHCsKEAoIBBMDAAIBCAISBKgHHSoKpQwKBgQTAwACAhIE2QcEKRqUDCBJZiB0aGlzIFNvdXJjZUNvZGVJbmZvIHJlcHJlc2VudHMgYSBjb21wbGV0ZSBkZWNsYXJhdGlvbiwgdGhlc2UgYXJlIGFueQogY29tbWVudHMgYXBwZWFyaW5nIGJlZm9yZSBhbmQgYWZ0ZXIgdGhlIGRlY2xhcmF0aW9uIHdoaWNoIGFwcGVhciB0byBiZQogYXR0YWNoZWQgdG8gdGhlIGRlY2xhcmF0aW9uLgoKIEEgc2VyaWVzIG9mIGxpbmUgY29tbWVudHMgYXBwZWFyaW5nIG9uIGNvbnNlY3V0aXZlIGxpbmVzLCB3aXRoIG5vIG90aGVyCiB0b2tlbnMgYXBwZWFyaW5nIG9uIHRob3NlIGxpbmVzLCB3aWxsIGJlIHRyZWF0ZWQgYXMgYSBzaW5nbGUgY29tbWVudC4KCiBsZWFkaW5nX2RldGFjaGVkX2NvbW1lbnRzIHdpbGwga2VlcCBwYXJhZ3JhcGhzIG9mIGNvbW1lbnRzIHRoYXQgYXBwZWFyCiBiZWZvcmUgKGJ1dCBub3QgY29ubmVjdGVkIHRvKSB0aGUgY3VycmVudCBlbGVtZW50LiBFYWNoIHBhcmFncmFwaCwKIHNlcGFyYXRlZCBieSBlbXB0eSBsaW5lcywgd2lsbCBiZSBvbmUgY29tbWVudCBlbGVtZW50IGluIHRoZSByZXBlYXRlZAogZmllbGQuCgogT25seSB0aGUgY29tbWVudCBjb250ZW50IGlzIHByb3ZpZGVkOyBjb21tZW50IG1hcmtlcnMgKGUuZy4gLy8pIGFyZQogc3RyaXBwZWQgb3V0LiAgRm9yIGJsb2NrIGNvbW1lbnRzLCBsZWFkaW5nIHdoaXRlc3BhY2UgYW5kIGFuIGFzdGVyaXNrCiB3aWxsIGJlIHN0cmlwcGVkIGZyb20gdGhlIGJlZ2lubmluZyBvZiBlYWNoIGxpbmUgb3RoZXIgdGhhbiB0aGUgZmlyc3QuCiBOZXdsaW5lcyBhcmUgaW5jbHVkZWQgaW4gdGhlIG91dHB1dC4KCiBFeGFtcGxlczoKCiAgIG9wdGlvbmFsIGludDMyIGZvbyA9IDE7ICAvLyBDb21tZW50IGF0dGFjaGVkIHRvIGZvby4KICAgLy8gQ29tbWVudCBhdHRhY2hlZCB0byBiYXIuCiAgIG9wdGlvbmFsIGludDMyIGJhciA9IDI7CgogICBvcHRpb25hbCBzdHJpbmcgYmF6ID0gMzsKICAgLy8gQ29tbWVudCBhdHRhY2hlZCB0byBiYXouCiAgIC8vIEFub3RoZXIgbGluZSBhdHRhY2hlZCB0byBiYXouCgogICAvLyBDb21tZW50IGF0dGFjaGVkIHRvIG1vby4KICAgLy8KICAgLy8gQW5vdGhlciBsaW5lIGF0dGFjaGVkIHRvIG1vby4KICAgb3B0aW9uYWwgZG91YmxlIG1vbyA9IDQ7CgogICAvLyBEZXRhY2hlZCBjb21tZW50IGZvciBjb3JnZS4gVGhpcyBpcyBub3QgbGVhZGluZyBvciB0cmFpbGluZyBjb21tZW50cwogICAvLyB0byBtb28gb3IgY29yZ2UgYmVjYXVzZSB0aGVyZSBhcmUgYmxhbmsgbGluZXMgc2VwYXJhdGluZyBpdCBmcm9tCiAgIC8vIGJvdGguCgogICAvLyBEZXRhY2hlZCBjb21tZW50IGZvciBjb3JnZSBwYXJhZ3JhcGggMi4KCiAgIG9wdGlvbmFsIHN0cmluZyBjb3JnZSA9IDU7CiAgIC8qIEJsb2NrIGNvbW1lbnQgYXR0YWNoZWQKICAgICogdG8gY29yZ2UuICBMZWFkaW5nIGFzdGVyaXNrcwogICAgKiB3aWxsIGJlIHJlbW92ZWQuICovCiAgIC8qIEJsb2NrIGNvbW1lbnQgYXR0YWNoZWQgdG8KICAgICogZ3JhdWx0LiAqLwogICBvcHRpb25hbCBpbnQzMiBncmF1bHQgPSA2OwoKICAgLy8gaWdub3JlZCBkZXRhY2hlZCBjb21tZW50cy4KCg8KBwQTAwACAgQSBNkHBAwKDwoHBBMDAAICBRIE2QcNEwoPCgcEEwMAAgIBEgTZBxQkCg8KBwQTAwACAgMSBNkHJygKDgoGBBMDAAIDEgTaBwQqCg8KBwQTAwACAwQSBNoHBAwKDwoHBBMDAAIDBRIE2gcNEwoPCgcEEwMAAgMBEgTaBxQlCg8KBwQTAwACAwMSBNoHKCkKDgoGBBMDAAIEEgTbBwQyCg8KBwQTAwACBAQSBNsHBAwKDwoHBBMDAAIEBRIE2wcNEwoPCgcEEwMAAgQBEgTbBxQtCg8KBwQTAwACBAMSBNsHMDEK7gEKAgQUEgbiBwCDCAEa3wEgRGVzY3JpYmVzIHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBnZW5lcmF0ZWQgY29kZSBhbmQgaXRzIG9yaWdpbmFsIHNvdXJjZQogZmlsZS4gQSBHZW5lcmF0ZWRDb2RlSW5mbyBtZXNzYWdlIGlzIGFzc29jaWF0ZWQgd2l0aCBvbmx5IG9uZSBnZW5lcmF0ZWQKIHNvdXJjZSBmaWxlLCBidXQgbWF5IGNvbnRhaW4gcmVmZXJlbmNlcyB0byBkaWZmZXJlbnQgc291cmNlIC5wcm90byBmaWxlcy4KCgsKAwQUARIE4gcIGQp4CgQEFAIAEgTlBwIlGmogQW4gQW5ub3RhdGlvbiBjb25uZWN0cyBzb21lIHNwYW4gb2YgdGV4dCBpbiBnZW5lcmF0ZWQgY29kZSB0byBhbiBlbGVtZW50CiBvZiBpdHMgZ2VuZXJhdGluZyAucHJvdG8gZmlsZS4KCg0KBQQUAgAEEgTlBwIKCg0KBQQUAgAGEgTlBwsVCg0KBQQUAgABEgTlBxYgCg0KBQQUAgADEgTlByMkCg4KBAQUAwASBuYHAoIIAwoNCgUEFAMAARIE5gcKFAqPAQoGBBQDAAIAEgTpBwQsGn8gSWRlbnRpZmllcyB0aGUgZWxlbWVudCBpbiB0aGUgb3JpZ2luYWwgc291cmNlIC5wcm90byBmaWxlLiBUaGlzIGZpZWxkCiBpcyBmb3JtYXR0ZWQgdGhlIHNhbWUgYXMgU291cmNlQ29kZUluZm8uTG9jYXRpb24ucGF0aC4KCg8KBwQUAwACAAQSBOkHBAwKDwoHBBQDAAIABRIE6QcNEgoPCgcEFAMAAgABEgTpBxMXCg8KBwQUAwACAAMSBOkHGhsKDwoHBBQDAAIACBIE6QccKwoQCggEFAMAAgAIAhIE6QcdKgpPCgYEFAMAAgESBOwHBCQaPyBJZGVudGlmaWVzIHRoZSBmaWxlc3lzdGVtIHBhdGggdG8gdGhlIG9yaWdpbmFsIHNvdXJjZSAucHJvdG8uCgoPCgcEFAMAAgEEEgTsBwQMCg8KBwQUAwACAQUSBOwHDRMKDwoHBBQDAAIBARIE7AcUHwoPCgcEFAMAAgEDEgTsByIjCncKBgQUAwACAhIE8AcEHRpnIElkZW50aWZpZXMgdGhlIHN0YXJ0aW5nIG9mZnNldCBpbiBieXRlcyBpbiB0aGUgZ2VuZXJhdGVkIGNvZGUKIHRoYXQgcmVsYXRlcyB0byB0aGUgaWRlbnRpZmllZCBvYmplY3QuCgoPCgcEFAMAAgIEEgTwBwQMCg8KBwQUAwACAgUSBPAHDRIKDwoHBBQDAAICARIE8AcTGAoPCgcEFAMAAgIDEgTwBxscCtsBCgYEFAMAAgMSBPUHBBsaygEgSWRlbnRpZmllcyB0aGUgZW5kaW5nIG9mZnNldCBpbiBieXRlcyBpbiB0aGUgZ2VuZXJhdGVkIGNvZGUgdGhhdAogcmVsYXRlcyB0byB0aGUgaWRlbnRpZmllZCBvYmplY3QuIFRoZSBlbmQgb2Zmc2V0IHNob3VsZCBiZSBvbmUgcGFzdAogdGhlIGxhc3QgcmVsZXZhbnQgYnl0ZSAoc28gdGhlIGxlbmd0aCBvZiB0aGUgdGV4dCA9IGVuZCAtIGJlZ2luKS4KCg8KBwQUAwACAwQSBPUHBAwKDwoHBBQDAAIDBRIE9QcNEgoPCgcEFAMAAgMBEgT1BxMWCg8KBwQUAwACAwMSBPUHGRoKagoGBBQDAAQAEgb5BwSACAUaWCBSZXByZXNlbnRzIHRoZSBpZGVudGlmaWVkIG9iamVjdCdzIGVmZmVjdCBvbiB0aGUgZWxlbWVudCBpbiB0aGUgb3JpZ2luYWwKIC5wcm90byBmaWxlLgoKDwoHBBQDAAQAARIE+QcJEQpGCggEFAMABAACABIE+wcGDxo0IFRoZXJlIGlzIG5vIGVmZmVjdCBvciB0aGUgZWZmZWN0IGlzIGluZGVzY3JpYmFibGUuCgoRCgkEFAMABAACAAESBPsHBgoKEQoJBBQDAAQAAgACEgT7Bw0OCjwKCAQUAwAEAAIBEgT9BwYOGiogVGhlIGVsZW1lbnQgaXMgc2V0IG9yIG90aGVyd2lzZSBtdXRhdGVkLgoKEQoJBBQDAAQAAgEBEgT9BwYJChEKCQQUAwAEAAIBAhIE/QcMDQo4CggEFAMABAACAhIE/wcGEBomIEFuIGFsaWFzIHRvIHRoZSBlbGVtZW50IGlzIHJldHVybmVkLgoKEQoJBBQDAAQAAgIBEgT/BwYLChEKCQQUAwAEAAICAhIE/wcODwoOCgYEFAMAAgQSBIEIBCMKDwoHBBQDAAIEBBIEgQgEDAoPCgcEFAMAAgQGEgSBCA0VCg8KBwQUAwACBAESBIEIFh4KDwoHBBQDAAIEAxIEgQghIgrUCAocZ29vZ2xlL2FwaS9hbm5vdGF0aW9ucy5wcm90bxIKZ29vZ2xlLmFwaRoVZ29vZ2xlL2FwaS9odHRwLnByb3RvGiBnb29nbGUvcHJvdG9idWYvZGVzY3JpcHRvci5wcm90bzpLCgRodHRwEh4uZ29vZ2xlLnByb3RvYnVmLk1ldGhvZE9wdGlvbnMYsMq8IiABKAsyFC5nb29nbGUuYXBpLkh0dHBSdWxlUgRodHRwQm4KDmNvbS5nb29nbGUuYXBpQhBBbm5vdGF0aW9uc1Byb3RvUAFaQWdvb2dsZS5nb2xhbmcub3JnL2dlbnByb3RvL2dvb2dsZWFwaXMvYXBpL2Fubm90YXRpb25zO2Fubm90YXRpb25zogIER0FQSUqpBgoGEgQOAB4BCrwECgEMEgMOABIysQQgQ29weXJpZ2h0IDIwMTUgR29vZ2xlIExMQwoKIExpY2Vuc2VkIHVuZGVyIHRoZSBBcGFjaGUgTGljZW5zZSwgVmVyc2lvbiAyLjAgKHRoZSAiTGljZW5zZSIpOwogeW91IG1heSBub3QgdXNlIHRoaXMgZmlsZSBleGNlcHQgaW4gY29tcGxpYW5jZSB3aXRoIHRoZSBMaWNlbnNlLgogWW91IG1heSBvYnRhaW4gYSBjb3B5IG9mIHRoZSBMaWNlbnNlIGF0CgogICAgIGh0dHA6Ly93d3cuYXBhY2hlLm9yZy9saWNlbnNlcy9MSUNFTlNFLTIuMAoKIFVubGVzcyByZXF1aXJlZCBieSBhcHBsaWNhYmxlIGxhdyBvciBhZ3JlZWQgdG8gaW4gd3JpdGluZywgc29mdHdhcmUKIGRpc3RyaWJ1dGVkIHVuZGVyIHRoZSBMaWNlbnNlIGlzIGRpc3RyaWJ1dGVkIG9uIGFuICJBUyBJUyIgQkFTSVMsCiBXSVRIT1VUIFdBUlJBTlRJRVMgT1IgQ09ORElUSU9OUyBPRiBBTlkgS0lORCwgZWl0aGVyIGV4cHJlc3Mgb3IgaW1wbGllZC4KIFNlZSB0aGUgTGljZW5zZSBmb3IgdGhlIHNwZWNpZmljIGxhbmd1YWdlIGdvdmVybmluZyBwZXJtaXNzaW9ucyBhbmQKIGxpbWl0YXRpb25zIHVuZGVyIHRoZSBMaWNlbnNlLgoKCAoBAhIDEAATCgkKAgMAEgMSAB8KCQoCAwESAxMAKgoICgEIEgMVAFgKCQoCCAsSAxUAWAoICgEIEgMWACIKCQoCCAoSAxYAIgoICgEIEgMXADEKCQoCCAgSAxcAMQoICgEIEgMYACcKCQoCCAESAxgAJwoICgEIEgMZACIKCQoCCCQSAxkAIgoJCgEHEgQbAB4BChwKAgcAEgMdAhsaESBTZWUgYEh0dHBSdWxlYC4KCgoKAwcAAhIDGwckCgoKAwcABhIDHQIKCgoKAwcAARIDHQsPCgoKAwcAAxIDHRIaYgZwcm90bzMKyA4KEGhlbGxvd29ybGQucHJvdG8SCmhlbGxvd29ybGQaHGdvb2dsZS9hcGkvYW5ub3RhdGlvbnMucHJvdG8iIgoMSGVsbG9SZXF1ZXN0EhIKBG5hbWUYASABKAlSBG5hbWUiJgoKSGVsbG9SZXBseRIYCgdtZXNzYWdlGAEgASgJUgdtZXNzYWdlMroCCgdHcmVldGVyEk8KCFNheUhlbGxvEhguaGVsbG93b3JsZC5IZWxsb1JlcXVlc3QaFi5oZWxsb3dvcmxkLkhlbGxvUmVwbHkiEYLT5JMCCxIJL3YxL2hlbGxvEkMKDVNheUhlbGxvQWdhaW4SGC5oZWxsb3dvcmxkLkhlbGxvUmVxdWVzdBoWLmhlbGxvd29ybGQuSGVsbG9SZXBseSIAEksKE1NheUhlbGxvU3RyZWFtUmVwbHkSGC5oZWxsb3dvcmxkLkhlbGxvUmVxdWVzdBoWLmhlbGxvd29ybGQuSGVsbG9SZXBseSIAMAESTAoSU2F5SGVsbG9CaWRpU3RyZWFtEhguaGVsbG93b3JsZC5IZWxsb1JlcXVlc3QaFi5oZWxsb3dvcmxkLkhlbGxvUmVwbHkiACgBMAFCNgobaW8uZ3JwYy5leGFtcGxlcy5oZWxsb3dvcmxkQg9IZWxsb1dvcmxkUHJvdG9QAaICA0hMV0rACgoGEgQOADIBCr8ECgEMEgMOABIytAQgQ29weXJpZ2h0IDIwMTUgZ1JQQyBhdXRob3JzLgoKIExpY2Vuc2VkIHVuZGVyIHRoZSBBcGFjaGUgTGljZW5zZSwgVmVyc2lvbiAyLjAgKHRoZSAiTGljZW5zZSIpOwogeW91IG1heSBub3QgdXNlIHRoaXMgZmlsZSBleGNlcHQgaW4gY29tcGxpYW5jZSB3aXRoIHRoZSBMaWNlbnNlLgogWW91IG1heSBvYnRhaW4gYSBjb3B5IG9mIHRoZSBMaWNlbnNlIGF0CgogICAgIGh0dHA6Ly93d3cuYXBhY2hlLm9yZy9saWNlbnNlcy9MSUNFTlNFLTIuMAoKIFVubGVzcyByZXF1aXJlZCBieSBhcHBsaWNhYmxlIGxhdyBvciBhZ3JlZWQgdG8gaW4gd3JpdGluZywgc29mdHdhcmUKIGRpc3RyaWJ1dGVkIHVuZGVyIHRoZSBMaWNlbnNlIGlzIGRpc3RyaWJ1dGVkIG9uIGFuICJBUyBJUyIgQkFTSVMsCiBXSVRIT1VUIFdBUlJBTlRJRVMgT1IgQ09ORElUSU9OUyBPRiBBTlkgS0lORCwgZWl0aGVyIGV4cHJlc3Mgb3IgaW1wbGllZC4KIFNlZSB0aGUgTGljZW5zZSBmb3IgdGhlIHNwZWNpZmljIGxhbmd1YWdlIGdvdmVybmluZyBwZXJtaXNzaW9ucyBhbmQKIGxpbWl0YXRpb25zIHVuZGVyIHRoZSBMaWNlbnNlLgoKCAoBCBIDEAAiCgkKAggKEgMQACIKCAoBCBIDEQA0CgkKAggBEgMRADQKCAoBCBIDEgAwCgkKAggIEgMSADAKCAoBCBIDEwAhCgkKAggkEgMTACEKCAoBAhIDFQATCgkKAgMAEgMXACYKLgoCBgASBBoAKAEaIiBUaGUgZ3JlZXRpbmcgc2VydmljZSBkZWZpbml0aW9uLgoKCgoDBgABEgMaCA8KIAoEBgACABIEHAIgAxoSIFNlbmRzIGEgZ3JlZXRpbmcKCgwKBQYAAgABEgMcBg4KDAoFBgACAAISAxwQHAoMCgUGAAIAAxIDHCcxCg0KBQYAAgAEEgQdBB8GChEKCQYAAgAEsMq8IhIEHQQfBgodCgQGAAIBEgMjAjoaECBBbm90aGVyIE1ldGhvZAoKDAoFBgACAQESAyMGEwoMCgUGAAIBAhIDIxUhCgwKBQYAAgEDEgMjLDYKCwoEBgACAhIDJQJHCgwKBQYAAgIBEgMlBhkKDAoFBgACAgISAyUbJwoMCgUGAAICBhIDJTI4CgwKBQYAAgIDEgMlOUMKCwoEBgACAxIDJwJNCgwKBQYAAgMBEgMnBhgKDAoFBgACAwUSAycaIAoMCgUGAAIDAhIDJyEtCgwKBQYAAgMGEgMnOD4KDAoFBgACAwMSAyc/SQo9CgIEABIEKwAtARoxIFRoZSByZXF1ZXN0IG1lc3NhZ2UgY29udGFpbmluZyB0aGUgdXNlcidzIG5hbWUuCgoKCgMEAAESAysIFAoLCgQEAAIAEgMsAhIKDAoFBAACAAUSAywCCAoMCgUEAAIAARIDLAkNCgwKBQQAAgADEgMsEBEKOwoCBAESBDAAMgEaLyBUaGUgcmVzcG9uc2UgbWVzc2FnZSBjb250YWluaW5nIHRoZSBncmVldGluZ3MKCgoKAwQBARIDMAgSCgsKBAQBAgASAzECFQoMCgUEAQIABRIDMQIICgwKBQQBAgABEgMxCRAKDAoFBAECAAMSAzETFGIGcHJvdG8z

위와 같은 EnvoyFilter 를 사용해서 HTTP + gRPC 를 동시에 사용가능한 gRPC 서버를 구축 가능합니다. 일단 위 예제에서는 애플리케이션 파드 의 사이드카에 이 필터를 삽입해서 처리를 하는 예제입니다. (context 가 SIDECAR_INBOUND 이기 때문에 .. 필요에 따라 ingress gateway 쪽에 이 필터를 삽입 할 수도 있습니다.)  

여기서 주의깊게 봐야하는것은 listener.portNumber 와 patch.value.services , patch.value.proto_descriptor_bin 부분입니다.

listener.portNumber 의 경우 gRPC 서버 이미지를 띄운 애플리케이션의 gRPC 포트번호를 지정해야 합니다.  

patch.value.services 에는 어떤 서비스들에 대해서 이 규칙을 사용해 gRPC 서버에 http json transcoder 를 적용해서 요청할지에 대한 부분이고.

patch.value.proto_descriptor_bin 의 경우 protobuf descriptor 를 base64 인코딩한 값을 넣어주었습니다.

당연하게도, 위 EnvoyFilter 를 적용하려면 gRPC 서버 애플리케이션 파드에 Istio Proxy(Enovy) 사이드카가 떠있어야 합니다!

아래는 gRPC 서버에 대한 deployment.yaml 예시입니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: grpc-python
spec:
  replicas: 1
  selector:
    matchLabels:
      app: grpc-python
  template:
    metadata:
      labels:
        app: grpc-python
        sidecar.istio.io/inject: 'true'
      annotations:
         sidecar.istio.io/rewriteAppHTTPProbers: "false"
      # 위 어노테이션을 달지 않으면 istio-sidecar-injector 가 mutatingWebhook 에서 강제로 http-get 으로 수정한다.
      # 글로벌하게 설정하고 싶으면 istio-sidecar-injector 의 configmap 을 수정하면 된다.
      # https://preliminary.istio.io/latest/docs/ops/configuration/mesh/app-health-check/#disable-the-http-probe-rewrite-for-a-pod
    spec:
      containers:
        - name: grpc-python
          image: kimsehwan96/python-grpc
          imagePullPolicy: Always
          ports:
            - containerPort: 7777
              name: grpc
          resources:
            requests:
              cpu: 500m
            limits:
              cpu: 500m
          readinessProbe:
            grpc:
              port: 7777

위와 같이 istio sidecar 를 label 을 통해 inject 하도록 명시하였고, annotations 의 sidecar.istio.io/rewriteAppHTTPProbers: "false" 은 주석에도 달려있지만, gRPC HealthCheck 프로브를 istio가 mutating Webhook 에서 강제로 덮어쓰지 않도록 방지하는 내용입니다.

(yaml 파일 예제는 https://github.com/kimsehwan96/istio-example/tree/master/grpc-python 여기에 있습니다.)

위 내용을 $ kubectl kustomize --enable-helm . | kubectl apply -f - --server-side --force-conflicts 로 배포해봅니다.

kustomize 를 통해 위 yaml 들을 하나의 yaml로 묶어서 배포하기 위해 위와 같은 명령어를 사용하였습니다. (그래서 Deployment 든, EnvoyFilter 든 네임스페이스 레이블이 빠져있는데, 실제로는 kustomization.yaml 항목에 지정되어있습니다.)

테스트

GitHub - kimsehwan96/gRPC-python-example: 테스트용

테스트용. Contribute to kimsehwan96/gRPC-python-example development by creating an account on GitHub.

GitHubkimsehwan96

 테스트를 위한 grpc 서버는 위 링크에 구현되어있고, 편의를 위해 gRPC reflection 등을 통해 어떤 메서드들이 노출되는지 볼 수 있게 세팅하고, + 기본적으로 제공되는 health check 기능을 넣어두었습니다.

(health check 기능 추가 라인 : https://github.com/kimsehwan96/gRPC-python-example/blob/266ec547524d7afb73f10ad596e8b0eb96759eea/greeter_server.py#L54-L58)

당연하게도 gRPC 요청은 잘 됩니다.

https://github.com/kimsehwan96/gRPC-python-example/blob/266ec547524d7afb73f10ad596e8b0eb96759eea/proto/helloworld.proto#L27-L33

위 코드에서 정의했듯이 /v1/hello 에 대해서 rpc SayHello (HelloRequest) returns (HelloReply) 를 호출하도록 하였는데, 정상적으로 HTTP 요청으로 호출되는것을 볼 수 있습니다. 이 때 Content-Type 헤더를 application/json 으로 명시적으로 헤더에 담아서 요청해야 처리됩니다.

EnvoyFilter 를 제거하고 호출해보면

이렇게 처리할 수 없는 헤더로 요청이 들어왔기때문에 요청이 처리되지 않습니다.

gRPC HealthCheck in K8s

k8s v1.27 부터 stable 하게 들어온 기능

Configure Liveness, Readiness and Startup Probes  

이것을 사용하기 위해서는 gRPC 서버 측에 Health Check 기능이 GRPC Health Checking Protocol 에 맞게 구현되어있으면 되고 (프로토콜 : https://github.com/grpc/grpc/blob/master/doc/health-checking.md )

각 언어별로 위 프로토콜 문서를 따른 gRPC HealthCheck 구현체가 있기때문에, 단순하게 서버에 삽입하기만 하면 사용 가능합니다.

(https://github.com/kimsehwan96/gRPC-python-example/blob/266ec547524d7afb73f10ad596e8b0eb96759eea/greeter_server.py#L54-L58)

apiVersion: apps/v1
kind: Deployment
metadata:
  ...
spec:
  ...
  template:
    ...
    spec:
      containers:
        - name: grpc-python
          ...
          readinessProbe:
            grpc:
              port: 7777

위와 같이 readinessProbe / livenessProbe 등에 grpc.port 및 grpc.service 를 지정하면 사용 가능하고. service 를 지정하지 않으면 GRPC Health Checking Protocol 에서 사용하는 기본적인 서비스.메서드로 프로브를 호출하게 됩니다. (매우 간편)

Proto Descriptor 를 base64 로 직접 envoy filter 에 넣지않고 ConfigMap 기반으로 경로를 지정해 세팅하는 방법

kustomize 의 configMapGenerator 를 사용합니다. (템플리팅 툴으로 helm 을 쓴다면 helm 에도 비슷한 기능이 있습니다. kustomize 든 helm 이든 yaml 관리를 위한 툴을 사용하지 않고서는 사용하기 어려움)

https://github.com/kimsehwan96/istio-example/blob/73f993ffead22376edbd74f5905091b575c30679/grpc-python/helloworld.pb

위 파일처럼 kustomization.yaml 이 있는 디렉터리에 바이너리로 된 proto descriptor (pb) 파일을 넣어둡니다.

namespace: grpc-python

resources:
  - ./namespace.yaml
  - ./deployment.yaml
  - ./service.yaml
  - ./mtls.yaml
  - ./grpc-virtualservice.yaml
  - ./grpc-gateway.yaml
  - ./envoy-filter.yaml

configMapGenerator:
  - name: grpc-python-proto-descriptor-configmap
    files:
      - ./helloworld.pb

generatorOptions:
  disableNameSuffixHash: true

kustomization.yaml 에 configMapGenerator 를 이용해 바이너리 파일을 configMap 으로 생성합니다.

위 사진처럼 로컬에 있는 파일이 base64 인코딩 되어서 configMap 으로 알아서 잘 들어갑니다. 이때의 configMap binary Data 의 키는 파일명과 동일(helloworld.pb)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: grpc-python
spec:
  replicas: 1
  selector:
    matchLabels:
      app: grpc-python
  template:
    metadata:
      labels:
        app: grpc-python
        sidecar.istio.io/inject: 'true'
      annotations:
        sidecar.istio.io/rewriteAppHTTPProbers: "false"
      # 위 어노테이션을 달지 않으면 istio-sidecar-injector 가 mutatingWebhook 에서 강제로 http-get 으로 수정한다.
      # 글로벌하게 설정하고 싶으면 istio-sidecar-injector 의 configmap 을 수정하면 된다.
      # https://preliminary.istio.io/latest/docs/ops/configuration/mesh/app-health-check/#disable-the-http-probe-rewrite-for-a-pod
        sidecar.istio.io/userVolumeMount: '[{"name":"proto-descriptor","mountPath":"/etc/envoy","readOnly":true}]'
        sidecar.istio.io/userVolume: '[{"name":"proto-descriptor","configMap":{"name":"grpc-python-proto-descriptor-configmap","items":[{"key":"helloworld.pb","path":"helloworld.pb"}]}}]'
...
...

Deployment 오브젝트에 istio 어노테이션을 사용해서 configMap 을 sidecar 컨테이너에 마운트 하도록 합니다. sidecar.istio.io/userVolumeMount , sidecar.istio.io/userVolume 어노테이션을 이용합니다.

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: grpc-transcoder
spec:
  workloadSelector:
    labels:
      app: grpc-python
  configPatches:
    - applyTo: HTTP_FILTER
      match:
        context: SIDECAR_INBOUND
        listener:
          portNumber: 7777 # 5xxxx 번대 포트를 지정하면 반영이 안된다. 이건 왜그런지;
          filterChain:
            filter:
              name: "envoy.filters.network.http_connection_manager"
              subFilter:
                name: "envoy.filters.http.router"
      patch:
        operation: INSERT_BEFORE
        value:
          name: envoy.filters.http.grpc_json_transcoder
          typed_config:
            "@type": type.googleapis.com/envoy.extensions.filters.http.grpc_json_transcoder.v3.GrpcJsonTranscoder
            services:
              - helloworld.Greeter
            print_options:
              add_whitespace: true
              always_print_enums_as_ints: false
              always_print_primitive_fields: true
              preserve_proto_field_names: false
            convert_grpc_status: true
            proto_descriptor: /etc/envoy/helloworld.pb

EnvoyFilter 오브젝트에서는 proto_descriptor 를 사용해서 사이드카 내에 proto descriptor 가 있는 경로를 지정해서 사용합니다.

만약 kustomize 가 아닌 helm 으로만 네이티브하게 구현한다면

# configMap.yml
kind: ConfigMap
apiVersion: v1
data:
binaryData:
  {{- $binaryFiles := $.Files }}  
  {{- range .binaryFiles }}
  {{ base .}}: |-
    {{- $binaryFiles.Get (printf "%s/%s" "configs" . ) | b64enc | nindent 6 -}}
  {{- end}}
# values.yaml
configs:
  - name: proto-descriptor
    binaryFiles:
      - api_descriptor.pb

위와 같이 helm 에서 사용 가능한 템플리팅 함수들이나 기능을 이용해서 구현하면 됩니다. 다만 kustomize 든 helm 이든 proto descriptor 파일이 helm / kustomize 명령어들을 수행하는 디렉터리와 같은 위치에 있어야 한다는게 단점? 일수도 있습니다.

위 상황에서, proto descriptor 파일이 바뀌었을 때 언제 반영이 되는가?

테스트 결과, configMap 의 바이너리( proto descriptor )를 바꾸더라도 기존에 떠있는 파드 에는 영향이 가지 않습니다. 파드를 내렸다가 올리는 경우에만 반영이 됩니다. 따라서 실제 프로덕션 환경에서는 proto descriptor 업데이트 이후 모든 Deployment / StatefulSet 의 파드를 rolloing update 하거나, canary 배포 하는등 아무튼 모든 파드가 내려갔다가 올라갈 필요가 있습니다.

참고 : https://github.com/grpc-ecosystem/grpc-gateway