1) Static Pod · kubelet 부트스트랩 핵심(매니페스트/설정 주입)
--pod-manifest-path=<PATH>
kubelet이 Static Pod 매니페스트를 읽는 디렉터리를 지정합니다. 이 디렉터리에 YAML을 두면 kubelet이 API Server 없이도(로컬 파일 기반) Pod를 띄웁니다.
실전에서는 kubeadm 기본 경로(/etc/kubernetes/manifests)를 많이 씁니다./etc/kubernetes/manifests/
kubeadm 클러스터에서 control-plane 컴포넌트가 Static Pod로 올라오는 기본 디렉터리입니다.
여기 파일을 수정하면 kubelet이 감지하고 자동으로 재생성(재시작)합니다.
대표 파일:kube-apiserver.yaml,kube-controller-manager.yaml,kube-scheduler.yaml,etcd.yaml--config=<CONFIG_FILE>
kubelet의 구성 파일 기반 설정을 지정합니다. 플래그로 다 주는 대신, YAML 하나로 kubelet 동작을 통합 관리합니다./var/lib/kubelet/config.yaml
kubeadm 환경에서 kubelet이 실제로 참조하는 kubelet config 파일로 자주 등장합니다.
예:clusterDNS,clusterDomain,cgroupDriver,authentication/authorization등./etc/systemd/system/kubelet.service.d/10-kubeadm.conf
kubeadm이 systemd drop-in 형태로 kubelet 실행 옵션(환경변수/플래그)을 주입하는 파일입니다.
“kubelet이 어떤 옵션으로 떠있지?”가 문제일 때 여기서 단서를 찾는 경우가 많습니다./usr/lib/systemd/system/kubelet.service또는/lib/systemd/system/kubelet.service
배포판에 따라 kubelet systemd unit 위치가 다릅니다. drop-in과 함께 “최종 실행 커맨드”를 추적할 때 확인합니다.
2) kubeconfig · 인증서(PKI) 경로(누가 어떤 권한으로 접속하는지)
~/.kube/config
사용자의 기본 kubeconfig 경로입니다. 시험/실무에서kubectl이 기본으로 읽습니다./etc/kubernetes/admin.conf
control-plane 노드에서 kubeadm이 생성하는 관리자 kubeconfig입니다.
보통 이 파일을~/.kube/config로 복사해서 kubectl을 편하게 씁니다./etc/kubernetes/kubelet.conf
kubelet이 API Server에 접속할 때 사용하는 kubeconfig입니다(노드가 클러스터에 자신을 등록/상태보고).
“kubelet 인증 문제” 유형에서 자주 언급됩니다./etc/kubernetes/controller-manager.conf
kube-controller-manager용 kubeconfig(컨트롤러가 API Server에 접근할 때)./etc/kubernetes/scheduler.conf
kube-scheduler용 kubeconfig(스케줄러가 API Server에 접근할 때)./etc/kubernetes/pki/
kubeadm이 생성/관리하는 클러스터 PKI(인증서/키) 기본 디렉터리입니다.
apiserver 인증서, CA, 프론트 프록시 CA 등 다양한 키/인증서가 존재합니다./etc/kubernetes/pki/etcd/
etcd 전용 PKI 디렉터리입니다. etcd 백업/상태확인 시--cacert/--cert/--key로 자주 참조합니다.
3) API Server 주요 옵션 · 데이터 암호화(Encryption at Rest)
--encryption-provider-config
kube-apiserver 옵션으로, Secret 등 리소스를 etcd에 저장할 때 암호화 정책 파일을 지정합니다.
시험에서는 “encryption config 파일 위치/적용 여부 확인” 형태로 나올 수 있습니다./etc/kubernetes/encryption-config.yaml
위 옵션이 가리키는 암호화 설정 파일을 이 경로로 두는 예시가 가장 흔합니다(환경에 따라 다를 수 있음)./etc/kubernetes/manifests/kube-apiserver.yaml
kube-apiserver가 static pod라면, 실제 플래그(--service-cluster-ip-range,--encryption-provider-config등)는 여기서 확인/수정합니다.
“서비스 CIDR가 뭔지”, “암호화 설정이 적용됐는지” 같은 문제는 이 파일을 보는 흐름이 많습니다.--service-cluster-ip-range
Service(ClusterIP)가 할당되는 가상 IP 대역(CIDR) 을 지정합니다.
이 값은 클러스터 네트워킹의 기반이라, 잘못 잡으면 서비스 IP 충돌/라우팅 혼선이 생길 수 있습니다.
4) Controller Manager · Pod CIDR 할당(노드별 Pod 대역)
kube-controller-manager --allocate-node-cidrs=true
controller-manager가 각 노드에spec.podCIDR를 자동 할당하도록 합니다.
CNI가 “노드별 Pod CIDR”을 전제로 하는 구성에서 중요합니다.kube-controller-manager --cluster-cidr=<CIDR>
노드에 나눠줄 Pod CIDR 풀입니다.--allocate-node-cidrs=true와 사실상 세트로 같이 봅니다./etc/kubernetes/manifests/kube-controller-manager.yaml
위 플래그들이 어디서 설정됐는지 확인/수정하는 대표 위치입니다.
5) etcd 백업/복구에 직결되는 경로
/etc/kubernetes/manifests/etcd.yaml
kubeadm 기본에서 etcd도 static pod로 올라옵니다. 데이터 디렉터리, 인증서 경로, listen/advertise URL 등이 여기에 있습니다./var/lib/etcd
etcd의 데이터 디렉터리로 가장 흔한 기본값입니다. 복구(restore) 시 새 데이터 디렉터리로 바꿔치기하는 유형이 자주 나옵니다./etc/kubernetes/pki/etcd/etcdctl로 health/status/snapshot 작업할 때 참조하는 CA/서버/클라이언트 인증서가 보통 여기 있습니다.
6) CNI 구성/플러그인 바이너리/상태 파일(네트워크 문제 풀이 핵심)
/opt/cni/bin
CNI 플러그인 바이너리들이 위치합니다(bridge, host-local, loopback, calico/flannel 관련 바이너리 등).
“CNI 바이너리가 없어서 Pod 네트워크가 안됨” 같은 문제에서 확인 포인트입니다./etc/cni/net.d
CNI 네트워크 설정 파일(예:10-bridge.conf,calico.conflist)이 들어갑니다.
어떤 CNI가 동작 중인지, IPAM이 무엇인지 이 디렉터리에서 단서를 얻습니다./var/lib/cni/networks
CNI 플러그인이 유지하는 할당된 IP 상태(로컬 DB) 가 저장되는 위치로 흔합니다(IPAM/할당 충돌 문제에서 확인)./var/run/netns
리눅스 네트워크 네임스페이스 핸들이 보이는 경로로 자주 사용됩니다. 네트워크 디버깅 시 존재 여부만으로도 단서가 됩니다./run/flannel/subnet.env
Flannel 사용 시 노드별 서브넷/MTU 등 환경값이 기록되는 대표 파일입니다(Flannel 환경에서 자주 참조)./etc/calico/,/var/lib/calico/
Calico 계열 설치에서 구성/상태가 위치할 수 있는 흔한 경로들입니다(배포 방식에 따라 달라질 수 있음).
7) ServiceAccount 토큰/CA 주입 경로(Pod 내부 인증)
/var/run/secrets/kubernetes.io/serviceaccount
Pod에 기본으로 마운트되는 ServiceAccount 관련 파일 경로입니다(설정에 따라 projected volume 형태로도 제공).
여기서token,ca.crt,namespace를 읽어 Pod가 API Server에 인증/통신합니다.
“Pod 내부에서 kubectl 없이 API 호출” 같은 문제에서 이 경로를 사용합니다.
8) 리눅스 네트워킹 필수 파일(클러스터 네트워크가 깨질 때)
/proc/sys/net/ipv4/ip_forward
IP 포워딩 활성화 여부(0/1)를 확인/조정하는 커널 파라미터입니다.
노드가 라우팅을 해야 하는 상황(CNI/브리지/노드간 통신)에서 중요합니다./proc/sys/net/bridge/bridge-nf-call-iptables
브리지 트래픽을 iptables가 볼지 여부입니다. NetworkPolicy/iptables 기반 CNI에서 문제를 일으키는 단골 포인트입니다./proc/sys/net/bridge/bridge-nf-call-ip6tables
위와 동일한 IPv6 버전입니다./etc/hosts
로컬 호스트 네임 해석에 영향. 특정 노드에서만 이름 해석이 이상할 때 확인합니다./etc/resolv.conf
DNS resolver 설정 파일입니다. Pod DNS 문제를 볼 때는 “노드의 resolv.conf”와 “Pod의 resolv.conf”가 다를 수 있어 비교가 유용합니다.
9) 컨테이너 런타임(노드 레벨 디버깅에 유용)
/etc/containerd/config.toml
containerd 설정 파일(환경에 따라 기본값 사용으로 파일이 없을 수도 있음). 런타임 문제/미러 레지스트리/샌드박스 이미지 관련 이슈에서 포인트가 됩니다./run/containerd/containerd.sock또는/var/run/containerd/containerd.sock
containerd 소켓 경로입니다.crictl/kubelet이 런타임과 통신하는 통로라 “런타임이 죽었나?”를 판단하는 단서가 됩니다./etc/crictl.yaml
crictl이 어떤 런타임 엔드포인트를 볼지 설정하는 파일입니다(환경마다 존재/경로가 다를 수 있음).
10) kube-proxy / Service 동작 확인 포인트(옵션보다는 ConfigMap로 많이 봄)
kube-system네임스페이스의kube-proxyConfigMap
kube-proxy는 많은 환경에서 ConfigMap 기반으로 설정합니다(IPVS/iptables 모드 등).
“Service가 동작하는데 룰이 안 생긴다/모드가 뭐지” 같은 문제에서 확인 포인트입니다.
원하면 다음 단계로, 위 챕터를 기반으로 “CKA 문제에서 실제로 어디를 먼저 열어보는지(우선순위 체크리스트)” 형태로도 재정리해줄 수 있습니다.
'CKA' 카테고리의 다른 글
| CKA 시험 팁 (0) | 2026.02.09 |
|---|---|
| CKA 명령어 시험 (0) | 2026.01.15 |
| CKA 명령어 정리 (1) | 2026.01.15 |
| CKA 시험 대비 - Scheduling (0) | 2026.01.09 |
| Kustomize - 총 정리 (0) | 2026.01.08 |