测验：向离线集群导入镜像

폐쇄망 k3s 에서 image: registry.k8s.io/e2e-test-images/busybox:1.36.1-1 파드가 ImagePullBackOff 다. 정책을 적지 않았다면 이 파드의 imagePullPolicy 와 실패 이유로 맞는 것은?

• 태그가 고정이라 IfNotPresent 이고, 노드의 런타임 저장소에 그 이미지가 없어 레지스트리로 받으러 가다 막혔다
• 정책을 적지 않으면 늘 Always 라서, 이미지가 있어도 매번 레지스트리에 물어보다 막혔다
• 정책을 적지 않으면 Never 라서 kubelet 이 받으러 가지 않고 곧바로 백오프에 들어갔다
• 태그에 하이픈이 있어 다이제스트로 해석되고, 다이제스트 이미지는 반드시 레지스트리에서 검증된다

busybox.tar 를 반입한 직후인데도 shop-api 파드가 한동안 ImagePullBackOff 에 머물렀다. 가장 그럴듯한 설명은?

• 반입한 이미지는 k3s 를 재시작해야 kubelet 의 이미지 목록에 반영된다
• ctr 로 반입한 이미지는 서명이 없어 kubelet 이 검증을 마칠 때까지 쓰지 않는다
• 실패가 거듭되면 다시 시도하는 간격이 늘어나(최대 300초) 다음 시도 전까지 기다리고 있다
• 파드의 이미지 이름이 캐시에 고정되어 같은 파드는 다시 끌어오기를 시도하지 않는다

k3s 이미지 디렉터리 /var/lib/rancher/k3s/agent/images/ 에 대한 문서의 설명으로 맞는 것은?

• 이 디렉터리의 tar 는 처음 설치할 때 한 번만 들이고, 이후로는 ctr 로만 반입할 수 있다
• 아카이브는 k3s 가 시작할 때마다 들이며, 실행 중에 넣은 tar 도 들이는 기능은 2025년 1월 릴리스부터다
• tar 를 넣으면 k3s 가 내장 사설 레지스트리로 올려 registries.yaml 없이도 다른 노드가 받아 간다
• 이미지 이름을 적은 텍스트 파일만 읽고, tar 는 무시하므로 반드시 사설 레지스트리를 거쳐야 한다

이미지를 반입해 두었는데 imagePullPolicy: Always 인 파드가 폐쇄망에서 실패했다. 그 이유와 알맞은 조치는?

• Always 는 로컬 이미지를 지우고 새로 받으므로, 반입을 한 번 더 한 뒤 파드를 재시작한다
• Always 는 k8s.io 가 아닌 네임스페이스만 보므로, 기본 네임스페이스에도 반입해 준다
• Always 는 레지스트리 인증을 요구하므로, 폐쇄망용 빈 imagePullSecrets 를 붙여 준다
• Always 는 매번 레지스트리에 태그의 다이제스트를 물으므로, 정책을 IfNotPresent 로 고쳐 파드를 다시 만든다

k3s 의 registries.yaml 에 사내 미러만 엔드포인트로 적었다. 문서에 비추어 조심해야 할 점은?

• containerd 의 기본 엔드포인트가 마지막 수단으로 늘 시도되므로, 미러가 실패하면 원래 레지스트리로 나가려 한다
• registries.yaml 은 파일을 저장하는 즉시 반영되므로 적용 중인 끌어오기가 중간에 끊긴다
• 미러를 적으면 docker.io 로 간주되던 짧은 이름도 자동으로 사내 미러 이름으로 바뀌어 매니페스트를 고칠 필요가 없다
• 엔드포인트를 하나만 적으면 containerd 가 인증서 검증을 끄므로 configs 섹션이 무시된다

고객 폐쇄망을 흉내 내려고 VM 의 바깥 송신을 iptables 로 막는다. 이 실습 환경에서 반드시 살려야 하는 것으로 가장 알맞은 묶음은?

• UDP 123(NTP)과 apt 저장소 주소 — 이 둘이 없으면 k3s 가 멈춘다
• registry.k8s.io 의 주소 대역 — 반입 도구가 서명 검증을 위해 계속 연락한다
• 루프백·이미 맺은 연결·k3s 파드와 서비스 대역 — 채점 연결과 API·파드 통신이 여기에 걸려 있다
• 들어오는 8899 연결만 — 나가는 것은 모두 막아도 채점 응답은 따로 경로가 있다