CKAD — 쿠버네티스 애플리케이션 개발자 · 서비스와 네트워킹 · 퀴즈
퀴즈: 서비스와 네트워킹
문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.
`port: 80`, `targetPort: 8080`, `nodePort: 30080` 인 NodePort Service 가 있다. 각 포트의 의미로 옳은 것은?
- 세 포트 모두 파드에 열려 있어야 한다
- 클라이언트는 ClusterIP 의 80 또는 노드의 30080 으로 붙고, 트래픽은 파드의 8080 으로 전달된다
- nodePort 는 컨테이너 포트이고 targetPort 는 노드 포트다
- 클라이언트는 노드의 8080 으로 붙고, 파드는 80 을 듣고, 30080 은 ClusterIP 포트다
컨테이너에 `ports: [{containerPort: 8080, name: api}]` 를 주고 Service 의 `targetPort: api` 로 지정했다. 이 구성의 장점은?
- targetPort 를 이름으로 쓰면 kube-proxy 를 거치지 않고 직접 연결된다
- Service 가 자동으로 헤드리스가 되어 DNS 로 파드 IP 를 반환한다
- 파드마다 실제 포트 번호가 달라도 Service 를 고치지 않고 그대로 쓸 수 있다
- 포트 이름이 DNS SRV 레코드로 노출되어 클라이언트가 포트를 조회할 수 있다는 점이 유일한 효과다
헤드리스 Service `cache-hs` 와 StatefulSet `cache`(레플리카 3)를 네임스페이스 `ckad-net` 에 만들었다. 첫 번째 파드의 완전한 DNS 이름은?
- `cache-0.ckad-net.cache-hs.svc.cluster.local`
- `cache-0.cache-hs.svc.ckad-net.cluster.local`
- `cache-hs.cache-0.ckad-net.svc.cluster.local`
- `cache-0.cache-hs.ckad-net.svc.cluster.local`
`kubectl get endpoints backend` 결과가 `<none>` 이다. 가장 가능성이 높은 원인은?
- Service 타입이 ClusterIP 라 엔드포인트가 만들어지지 않는다
- NetworkPolicy 가 걸려 엔드포인트 등록이 차단됐다
- targetPort 를 이름으로 지정했기 때문이다
- Service 셀렉터가 파드 라벨과 일치하지 않거나, 파드가 Ready 상태가 아니다
Ingress 규칙에 `path: /api`, `pathType: Prefix` 를 주었다. 매칭되는 요청은?
- `/api` 와 `/api/users` 는 매칭되지만 `/apixyz` 는 매칭되지 않는다
- 정규식으로 해석되어 `/a`, `/ap` 도 매칭된다
- `/api` 만 매칭된다
- `/api`, `/api/users`, `/apixyz` 모두 매칭된다
`podSelector: {app: backend}`, `policyTypes: [Ingress]` 만 지정한 NetworkPolicy 를 적용했다. backend 파드의 동작으로 옳은 것은?
- DNS(53번 포트)는 항상 자동으로 허용되므로 별도 규칙이 필요 없다
- 들어오는 트래픽은 규칙에 명시된 것만 허용되고, 나가는 트래픽은 제한되지 않는다
- 들어오고 나가는 트래픽이 모두 화이트리스트가 된다
- 정책이 걸려도 다른 파드가 정책을 갖지 않으면 아무 효과가 없다