LabHub

CKAD — 쿠버네티스 애플리케이션 개발자 · 서비스와 네트워킹 · 퀴즈

퀴즈: 서비스와 네트워킹

LabHub 에서 이어서 보기

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

  1. `port: 80`, `targetPort: 8080`, `nodePort: 30080` 인 NodePort Service 가 있다. 각 포트의 의미로 옳은 것은?

    1. 세 포트 모두 파드에 열려 있어야 한다
    2. 클라이언트는 ClusterIP 의 80 또는 노드의 30080 으로 붙고, 트래픽은 파드의 8080 으로 전달된다
    3. nodePort 는 컨테이너 포트이고 targetPort 는 노드 포트다
    4. 클라이언트는 노드의 8080 으로 붙고, 파드는 80 을 듣고, 30080 은 ClusterIP 포트다
  2. 컨테이너에 `ports: [{containerPort: 8080, name: api}]` 를 주고 Service 의 `targetPort: api` 로 지정했다. 이 구성의 장점은?

    1. targetPort 를 이름으로 쓰면 kube-proxy 를 거치지 않고 직접 연결된다
    2. Service 가 자동으로 헤드리스가 되어 DNS 로 파드 IP 를 반환한다
    3. 파드마다 실제 포트 번호가 달라도 Service 를 고치지 않고 그대로 쓸 수 있다
    4. 포트 이름이 DNS SRV 레코드로 노출되어 클라이언트가 포트를 조회할 수 있다는 점이 유일한 효과다
  3. 헤드리스 Service `cache-hs` 와 StatefulSet `cache`(레플리카 3)를 네임스페이스 `ckad-net` 에 만들었다. 첫 번째 파드의 완전한 DNS 이름은?

    1. `cache-0.ckad-net.cache-hs.svc.cluster.local`
    2. `cache-0.cache-hs.svc.ckad-net.cluster.local`
    3. `cache-hs.cache-0.ckad-net.svc.cluster.local`
    4. `cache-0.cache-hs.ckad-net.svc.cluster.local`
  4. `kubectl get endpoints backend` 결과가 `<none>` 이다. 가장 가능성이 높은 원인은?

    1. Service 타입이 ClusterIP 라 엔드포인트가 만들어지지 않는다
    2. NetworkPolicy 가 걸려 엔드포인트 등록이 차단됐다
    3. targetPort 를 이름으로 지정했기 때문이다
    4. Service 셀렉터가 파드 라벨과 일치하지 않거나, 파드가 Ready 상태가 아니다
  5. Ingress 규칙에 `path: /api`, `pathType: Prefix` 를 주었다. 매칭되는 요청은?

    1. `/api` 와 `/api/users` 는 매칭되지만 `/apixyz` 는 매칭되지 않는다
    2. 정규식으로 해석되어 `/a`, `/ap` 도 매칭된다
    3. `/api` 만 매칭된다
    4. `/api`, `/api/users`, `/apixyz` 모두 매칭된다
  6. `podSelector: {app: backend}`, `policyTypes: [Ingress]` 만 지정한 NetworkPolicy 를 적용했다. backend 파드의 동작으로 옳은 것은?

    1. DNS(53번 포트)는 항상 자동으로 허용되므로 별도 규칙이 필요 없다
    2. 들어오는 트래픽은 규칙에 명시된 것만 허용되고, 나가는 트래픽은 제한되지 않는다
    3. 들어오고 나가는 트래픽이 모두 화이트리스트가 된다
    4. 정책이 걸려도 다른 파드가 정책을 갖지 않으면 아무 효과가 없다