LabHub

CCA — 실리움 인증 어소시에이트 · ClusterMesh 와 외부 워크로드 · 퀴즈

퀴즈: ClusterMesh 와 외부 워크로드

LabHub 에서 이어서 보기

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

  1. ClusterMesh 에서 클러스터 ID 로 사용할 수 있는 범위와 그 결과로 정해지는 최대 클러스터 수는?

    1. 0~127, 최대 128개
    2. 1~1024, 최대 1024개
    3. 제한 없음
    4. 1~255, 최대 255개
  2. ClusterMesh 를 구성할 때 클러스터 간 PodCIDR 이 겹치면 안 되는 이유는?

    1. 쿠버네티스 스케줄러가 중복된 PodCIDR 을 아예 거부하기 때문
    2. WireGuard 키 교환이 CIDR 기반이기 때문
    3. 같은 주소가 두 클러스터에서 서로 다른 파드를 가리켜 ipcache 의 IP-아이덴티티 매핑이 성립하지 않기 때문
    4. Hubble 이 플로우를 구분하지 못하기 때문
  3. ClusterMesh 로 연결할 모든 클러스터가 같은 CA 를 공유해야 하는 이유는?

    1. Helm 값 검증이 CA 해시를 비교하기 때문
    2. 보안 아이덴티티 번호가 CA 인증서로부터 파생되기 때문
    3. 클러스터 간 통신도 mTLS 로 상호 인증하는데 신뢰의 뿌리가 다르면 상대 인증서를 검증할 수 없기 때문
    4. etcd 복제가 같은 인증서를 요구하기 때문
  4. 글로벌 서비스에 `service.cilium.io/affinity: local` 을 붙였는데 로컬 백엔드가 고장 나도 원격으로 넘어가지 않습니다. 가장 먼저 의심할 것은?

    1. 클러스터 ID 가 중복됐는지
    2. readinessProbe 가 부실해 고장 난 백엔드가 계속 Ready 로 남아 있는지
    3. 글로벌 서비스 애너테이션 값이 문자열이 아닌지
    4. WireGuard 가 꺼져 있는지
  5. ClusterMesh 환경의 CiliumNetworkPolicy 에서 `io.cilium.k8s.policy.cluster` 라벨을 지정하지 않으면?

    1. 로컬 클러스터의 엔드포인트만 매칭된다
    2. 정책이 적용되지 않고 무시된다
    3. 양쪽 클러스터의 같은 라벨을 가진 엔드포인트가 모두 매칭된다
    4. 원격 클러스터에서만 매칭된다
  6. clustermesh-apiserver 파드가 다운됐습니다. 즉시 나타나는 영향은?

    1. 이미 동기화된 서비스와 아이덴티티로 트래픽은 계속 흐르고, 새로운 변경의 전파만 멈춘다
    2. 클러스터 간 트래픽이 즉시 끊긴다
    3. 로컬 클러스터의 네트워크 정책도 함께 초기화된다
    4. 글로벌 서비스가 로컬 서비스로 강등된다