LabHub

ICA — 이스티오 인증 어소시에이트 · 모의고사 · 실습

ICA 모의고사 A

LabHub 에서 이어서 보기

ICA 모의고사 A 입니다. 제한 시간 120분, 과제 17개, 합격선 68% 입니다.
부분 점수제이므로 막히는 과제는 건너뛰고 나중에 돌아오는 편이 낫습니다.

모의고사이므로 힌트와 정답을 보지 말고 먼저 끝까지 풀어 보십시오.
시간이 모자라 못 푼 것과 몰라서 못 푼 것은 다른 문제이고, 그 둘을 구분해야
다음에 무엇을 공부할지가 정해집니다. 다 풀고 채점한 뒤에 펼치십시오.

실제 시험 환경

시험 중에 istio.io/docs, istio.io/blog, kubernetes.io/docs 를 볼 수 있습니다.
istio.io/search/ 로 문서 사이트 안에서 검색하는 것은 허용되지만 외부 검색
결과를 클릭하면 안 됩니다. k 별칭과 bash 자동완성, 그리고 istioctl
자동완성이 이미 설정되어 있습니다. 과제마다 지정된 호스트로 ssh 해서
작업하며 중첩 ssh 는 지원되지 않습니다. 터미널 복사는 Ctrl+Shift+C,
붙여넣기는 Ctrl+Shift+V 입니다.

이 모의고사 환경

파드 안의 1인용 클러스터에서 바로 작업합니다(ssh 는 필요 없습니다).
kube-apiserver 는 진짜라서 잘못된 매니페스트는 실제로 거부되지만, 사이드카는
뜨지 않고 트래픽도 흐르지 않습니다. 채점은 여러분이 클러스터에 남긴 설정을
다시 읽어서 합니다.

1번 과제가 나머지 대부분의 전제입니다. Istio 리소스 종류가 등록되기 전에는
kubectl apply 가 VirtualService 를 받아 주지 않습니다. 먼저 끝내십시오.

---

1. 기본 프로파일의 Istio 설치 매니페스트를 만들어 /root/ica/install/manifest.yaml
에 저장하십시오. 그리고 그 매니페스트 안의 CustomResourceDefinition 만 골라
클러스터에 등록하십시오. 이 환경에서는 istiod 파드가 뜨지 않으므로 필요한 것은
API 타입뿐입니다.

2. 네임스페이스 세 개를 만들고 사이드카 주입 라벨을 붙이십시오.

3. 파드 수준에서 네임스페이스의 결정을 뒤집으십시오. 두 디플로이먼트 모두
레플리카 1, 이미지 nginx:1.27-alpine 입니다.

4. ica-shop 에 리뷰 서비스를 세 버전으로 올리고 subset 을 정의하십시오.

5. ica-shop 에 VirtualService reviews 를 만드십시오. 호스트는
reviews.ica-shop.svc.cluster.local 이고, 조건 없는 규칙 하나로 subset v1 에
80, subset v2 에 20 을 나눕니다.

6. 5번의 VirtualService reviews 앞에 규칙 두 개를 더해 모두 세 개로
만드십시오. 순서가 채점 대상입니다.

1. 헤더 end-user 가 정확히 tester 이면 subset v3
2. uri 접두사가 /api/v2 이면서 동시에 메서드가 GET 이면 subset v2
3. 5번의 가중치 규칙이 조건 없는 마지막 규칙으로 남습니다

7. 같은 VirtualService reviews 의 마지막(조건 없는) 규칙에 회복력 설정을
붙이십시오. 전체 타임아웃 2s, 재시도 3회, 시도당 타임아웃 500ms, 재시도
조건은 5xx·reset·connect-failure 입니다.

8. DestinationRule reviews 의 trafficPolicy 에 상한과 이상치 감지를
더하십시오.

9. ica-shop 에 인그레스를 세우십시오.

10. mTLS 를 메시 전역으로 강제하되 낡은 네임스페이스만 예외로 두십시오.

11. ica-legacy 의 legacy-api 워크로드만 STRICT 로 올리되 8080 포트는
예외로 두십시오. PeerAuthentication 이름은 legacy-api, selector 는
app: legacy-api, mtls.mode 는 STRICT, portLevelMtls 의 8080 은
DISABLE 입니다.

12. ica-shop 에 인가 정책 두 개를 만드십시오. 둘 다 selector 는
app: reviews 입니다.

13. ica-shop 의 app: reviews 워크로드에 JWT 검증을 붙이십시오.

14. 어떤 팀이 ica-fix 네임스페이스에 쓰겠다며 아래 VirtualService 하나만
넘겨 주었습니다. 이대로는 istioctl analyze 가 오류를 냅니다. 무엇이 빠졌는지
진단해 채워 넣고, istioctl analyze -n ica-fix 가 Error 를 하나도 내지 않게
만드십시오.

apiVersion: networking.istio.io/v1kind: VirtualServicemetadata:  name: payments  namespace: ica-fixspec:  hosts:    - payments.ica-fix.svc.cluster.local  http:    - route:        - destination:            host: payments.ica-fix.svc.cluster.local            subset: stable

채워 넣을 것의 규격은 이렇습니다. 디플로이먼트 payments 는 파드 라벨
app=payments 와 version=v1, 서비스 payments 는 포트 9090 에 포트 이름
http, DestinationRule payments 는 위와 같은 FQDN 을 host 로 두고 subset
stable 을 version: v1 로 정의합니다. 이 네임스페이스에 과제와 무관한
리소스를 남기지 마십시오. 남으면 analyze 가 그것까지 잡습니다.

15. ica-triage 네임스페이스에 아래 VirtualService 를 적용했더니
x-beta: true 헤더를 붙여도 언제나 stable 로 갑니다. 원인을 진단해 고친 것을
적용하십시오. 규칙은 두 개 그대로 둡니다.

apiVersion: networking.istio.io/v1kind: VirtualServicemetadata:  name: checkout  namespace: ica-triagespec:  hosts:    - checkout.ica-triage.svc.cluster.local  http:    - route:        - destination:            host: checkout.ica-triage.svc.cluster.local            subset: stable    - match:        - headers:            x-beta:              exact: "true"      route:        - destination:            host: checkout.ica-triage.svc.cluster.local            subset: beta

16. 아래 정책을 넣은 뒤 ica-triage 의 payments 워크로드가 모든 요청을
거부합니다. 원인을 진단하고, cluster.local/ns/ica-triage/sa/frontend 가
POST 로 /pay* 에 접근하는 것만 허용하도록 고치십시오.

apiVersion: security.istio.io/v1kind: AuthorizationPolicymetadata:  name: payments-allow  namespace: ica-triagespec:  selector:    matchLabels:      app: payments  action: ALLOW  rules: []

17. ica-triage 에 아래 두 리소스를 두었더니 orders 를 호출하는 쪽이 전부
실패합니다. 서버 쪽 요구는 그대로 두고 클라이언트 쪽을 고치십시오.

apiVersion: security.istio.io/v1kind: PeerAuthenticationmetadata:  name: default  namespace: ica-triagespec:  mtls:    mode: STRICT---apiVersion: networking.istio.io/v1kind: DestinationRulemetadata:  name: orders  namespace: ica-triagespec:  host: orders.ica-triage.svc.cluster.local  trafficPolicy:    tls:      mode: DISABLE

15번부터 17번까지의 ica-triage 에는 워크로드를 만들 필요가 없습니다. 고쳐야
할 것은 설정입니다.

단계 17개

  1. 메시 API 타입을 클러스터에 등록하기
  2. 네임스페이스별 사이드카 주입 라벨 걸기
  3. 파드 수준에서 주입 여부 뒤집기
  4. 버전별 워크로드와 subset 만들기
  5. 가중치로 80 대 20 나누기
  6. 구체적인 규칙을 catch-all 앞에 두기
  7. 타임아웃과 재시도의 관계 맞추기
  8. 커넥션 풀 상한과 이상치 감지 걸기
  9. 인그레스 게이트웨이 세우기
  10. 메시 전역 STRICT 와 네임스페이스 예외
  11. 워크로드 STRICT 에 포트 예외 두기
  12. ALLOW 와 DENY 정책 나눠 쓰기
  13. JWT 검증과 토큰 요구를 함께 걸기
  14. analyze 가 잡아 주는 것을 채워 넣기
  15. 도달하지 못하는 규칙 살려 내기
  16. 모든 요청을 막는 빈 ALLOW 정책 고치기
  17. 서버 요구와 어긋난 클라이언트 TLS 고치기