クイズ: サービスとネットワーキング

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번 포트)는 항상 자동으로 허용되므로 별도 규칙이 필요 없다
• 들어오는 트래픽은 규칙에 명시된 것만 허용되고, 나가는 트래픽은 제한되지 않는다
• 들어오고 나가는 트래픽이 모두 화이트리스트가 된다
• 정책이 걸려도 다른 파드가 정책을 갖지 않으면 아무 효과가 없다