LabHub
배우기 러닝패스 코스

ICA — 이스티오 인증 어소시에이트 · 설치 맞춤과 업그레이드 두 방식 · 퀴즈

퀴즈: 설치 맞춤과 업그레이드 두 방식

LabHub 에서 이어서 보기

문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

  1. istioctl 의 configuration profile 과 Helm 의 profile 이 다른 점을 바르게 설명한 것은?

    1. istioctl 의 profile 은 어떤 구성요소를 설치할지 목록까지 포함하지만 Helm 의 profile 은 values 묶음일 뿐이라 구성요소를 각각 설치해야 한다
    2. Helm 의 profile 은 구성요소 목록까지 포함하지만 istioctl 의 profile 은 MeshConfig 값만 바꾸므로 게이트웨이는 따로 설치해야 한다
    3. 두 도구의 profile 은 이름만 같고 내용은 전혀 다른 values 파일이라 istioctl 로 만든 설정을 Helm 에서 쓸 수 없다
    4. istioctl 의 profile 은 플랫폼별 값(gke, eks)만 담고 Helm 의 profile 은 배포 형태별 값(default, demo)만 담는다

  2. MeshConfig 의 여러 값 중 바꾼 뒤 파드를 재시작해야 반영되는 것은?

    1. accessLogFile — 프록시가 로그 파일을 시작 시점에 한 번만 연다
    2. outboundTrafficPolicy — 사이드카의 리스너 구조를 통째로 바꾼다
    3. defaultConfig(ProxyConfig) — 주입 시점에 한 번 적용되어 파드가 사는 동안 유지된다
    4. enableTracing — 스팬 수집기 연결은 프록시 기동 때만 이루어진다

  3. canary 업그레이드에서 네임스페이스를 새 revision 으로 옮길 때 istio-injection=enabled 라벨을 반드시 지워야 하는 이유는?

    1. istio-injection 라벨이 있으면 새 revision 의 웹훅이 네임스페이스 자체를 삭제하려고 시도하기 때문
    2. istio-injection 라벨이 하위 호환을 위해 istio.io/rev 보다 우선하므로 지우지 않으면 옛 컨트롤 플레인이 계속 주입하기 때문
    3. 두 라벨이 함께 있으면 사이드카가 두 개 주입되어 파드가 CrashLoopBackOff 에 빠지기 때문
    4. istio.io/rev 라벨은 istio-injection 라벨이 없는 네임스페이스에만 붙일 수 있도록 API 서버가 검증하기 때문

  4. revision tag prod-stable 을 쓰는 모든 네임스페이스를 한 번에 1-31-0 으로 옮기는 올바른 방법은?

    1. 각 네임스페이스의 istio.io/rev 라벨을 1-31-0 으로 하나씩 고친 뒤 파드를 재시작한다
    2. istioctl install --set revision=1-31-0 을 다시 실행하면 태그가 자동으로 새 revision 을 가리킨다
    3. kubectl label ns --all istio.io/rev=1-31-0 --overwrite 로 라벨을 통째로 덮어쓴다
    4. istioctl tag set prod-stable --revision 1-31-0 --overwrite 로 태그가 가리키는 revision 만 바꾼 뒤 워크로드를 재시작한다

  5. istioctl upgrade(in-place) 에 대한 설명으로 문서와 맞는 것은?

    1. 설치 때 쓴 -f 파일이나 --set 값을 그대로 넘기지 않으면 맞춤 설정이 기본 profile 값으로 되돌아간다
    2. 컨트롤 플레인이 바뀌면 사이드카도 자동으로 새 버전으로 교체되므로 파드 재시작이 필요 없다
    3. --revision 으로 설치한 컨트롤 플레인도 istioctl upgrade 로 그 자리에서 올릴 수 있다
    4. 마이너 버전을 두 단계 건너뛰는 업그레이드(1.15 → 1.17)는 in-place 에서만 지원된다

  6. Helm 으로 Istio 를 설치할 때 차트를 올리는 순서와 그 이유로 옳은 것은?

    1. gateway → istiod → base 순서다. 게이트웨이가 먼저 있어야 istiod 가 리스너를 만들 수 있기 때문이다
    2. istiod → base → gateway 순서다. istiod 가 CRD 를 직접 생성하므로 base 는 검증 웹훅만 담당한다
    3. base → istiod → gateway 순서다. base 가 클러스터 범위 CRD 를 담고 있어 컨트롤 플레인보다 먼저 있어야 하기 때문이다
    4. 순서는 상관없다. Helm 4 의 server-side apply 가 의존 관계를 해석해 CRD 를 먼저 적용하기 때문이다