아래는 CKA 시험 관점(Workloads & Scheduling 중심)에서 “자주 출제/실습으로 많이 돌리는” 주제만 최대한 촘촘하게 묶은 Scheduling 치트시트(총정리)입니다. (CKA 도메인에서 Workloads & Scheduling 비중은 공개 커리큘럼 기준 15%로 안내됩니다. (Linux Foundation - Education))

1) 스케줄러가 하는 일: Pending → Filtering → Scoring → Binding

스케줄러는 spec.nodeName이 비어있는 Pod를 스케줄링 대상으로 보고, 조건을 만족하는 노드를 고른 뒤 API Server에 “Binding”을 수행합니다. (Kubernetes)
조건에 맞는 노드가 없으면 Pod는 계속 Pending 상태로 남습니다. (Kubernetes)

시험에서 제일 많이 쓰는 디버깅 루틴

kubectl get pod -o wide
kubectl describe pod <pod>
kubectl get events --sort-by=.lastTimestamp

Pod가 Pending일 때 흔한 원인

requests(요청) 때문에 노드에 자원이 부족함
taint를 toleration이 못 견딤
nodeSelector/nodeAffinity 조건에 맞는 노드가 없음
PVC Pending(스토리지 붙기 전이라 스케줄링이 막힘)
(커스텀 스케줄러 사용 시) spec.schedulerName 잘못됨 (Kubernetes)

2) 라벨/셀렉터: 스케줄링 전반의 “필터 언어”

`-l` 과 `--selector`는 사실상 같은 용도

둘 다 label selector를 전달합니다(표현만 다름).

kubectl get pods -l app=web
kubectl get pods --selector app=web

필드 셀렉터도 자주 유용(노드에 붙은 Pod 찾기)

kubectl get pods -A -o wide --field-selector spec.nodeName=node1
kubectl get pods --field-selector status.phase=Pending

필드 셀렉터는 리소스 “필드 값” 기반 필터링입니다. (Kubernetes)

3) 수동 스케줄링(Manual Scheduling): `spec.nodeName` vs Binding

(A) 가장 쉬운 방법: 생성 시 `spec.nodeName` 지정

apiVersion: v1
kind: Pod
metadata:
  name: manual-pod
spec:
  nodeName: node01
  containers:
  - name: nginx
    image: nginx

핵심: spec.nodeName은 “생성 시점에만” 사실상 의미 있게 쓰는 방식(일반 스케줄러를 우회).
“스케줄러가 없다면?”이라는 문맥은 kube-scheduler가 죽었거나/미배포된 상황을 뜻합니다(학습/장애 상황 가정).

(B) 이미 생성된 Pod를 강제로 특정 노드에 “바인딩” (개념은 알아두기)

스케줄러가 하는 Binding을 API로 흉내내는 방식(시험에서 핵심 빈출이라고 단정하긴 어렵지만, “왜 Pending인가/바인딩이 뭔가”를 이해하는데 도움이 됩니다).
스케줄러가 API Server에 바인딩을 수행한다는 개념 자체는 공식 문서 흐름에 포함됩니다. (Kubernetes)

4) Taints & Tolerations: “노드가 거부권을 갖는다”

Taint는 Node에, Toleration은 Pod에 설정.
효과(effect) 3개가 시험 단골:
- NoSchedule: 새 Pod 스케줄링 금지(기존 Pod는 유지) (Kubernetes)
- PreferNoSchedule: 되도록 피함(보장 X) (Kubernetes)
- NoExecute: 새 Pod 금지 + 기존 Pod도 toleration 없으면 축출

노드에 taint 주기/빼기

kubectl taint node node1 app=blue:NoSchedule
kubectl taint node node1 app=blue:NoSchedule-   # 제거

Pod에 toleration 추가 예시

spec:
  tolerations:
  - key: "app"
    operator: "Equal"
    value: "blue"
    effect: "NoSchedule"

toleration에서 왜 문자열에 `"`를 쓰는가?

YAML에서 따옴표는 “필수”는 아니지만, 오해(타입 캐스팅/특수값 해석)를 방지하기 위해 교육/실무에서 자주 권장합니다.
특히 true/false, on/off, yes/no, 숫자처럼 보이는 값은 YAML이 다른 타입으로 해석할 수 있어 안전하게 문자열로 고정하려고 따옴표를 붙입니다.

자주 나오는 함정

Taint/Toleration은 “해당 노드로 가라”가 아니라 “그 노드는 이런 Pod만 받아준다”입니다.
특정 노드로 “가게” 하려면 보통 nodeAffinity(또는 nodeSelector)로 함께 묶습니다.

5) NodeSelector vs NodeAffinity: “노드 라벨 기반 스케줄링”

NodeSelector: 가장 단순(AND만 가능)

노드에 라벨

kubectl label node node1 size=large

Pod에서 지정

spec:
  nodeSelector:
    size: large

NodeAffinity: 시험에 더 자주 등장(표현력이 큼)

대표 2가지 타입(필드 이름이 길어도 의미로 기억):

requiredDuringSchedulingIgnoredDuringExecution: 스케줄링 때 반드시 만족, 실행 중 라벨 바뀌어도 유지(“IgnoredDuringExecution”) (Kubernetes)
preferredDuringSchedulingIgnoredDuringExecution: 되도록 만족(가중치 기반 선호)

예시(필수):

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: size
            operator: In
            values: ["large"]

“이거 통으로 암기해야 하나?”

통암기보다, 구조만 익혀서 시험장에서 빠르게 복원하는 게 현실적입니다.
추천 루틴:

kubectl explain pod.spec.affinity --recursive | less

그리고 자주 쓰는 스니펫(위 예시)만 손에 익히면 충분합니다.

6) DaemonSet: “각 노드에 1개씩”

DaemonSet은 각 노드에 1 Pod를 보장합니다.
대표 용도: CNI 에이전트/로그 수집기/모니터링 에이전트(노드 단위 상주).

생성/확인

kubectl get ds -A
kubectl describe ds <name> -n <ns>

imperative 생성이 왜 틀렸는지(자주 실수)

kubectl create daemonset elasticsearch --image=... -n kube-system

daemonset은 맞지만, 이미지/태그가 틀리거나(존재 X), 레지스트리 접근 문제면 실패합니다.
또 하나의 흔한 실수는 리소스 종류/명령어 오타입니다.
- Deployment: kubectl create deployment ... (deployments 아님)
- DaemonSet: kubectl create daemonset ...
- ReplicaSet은 보통 YAML로 생성(“create replicaset”류를 잘못 치는 케이스가 많음)

7) Requests/Limits: 스케줄링의 “자원 기반 필터” 핵심

스케줄러는 기본적으로 requests(요청)를 보고 “이 Pod를 올릴 수 있는 노드인지”를 판단합니다.

requests / limits 정리

requests: 최소 보장량(스케줄링 판단 기준)
limits: 최대 사용 상한
CPU:
- limit 초과 시 throttling(느려짐)
Memory:
- limit 초과 지속 시 OOMKill로 컨테이너가 죽을 수 있음 (Kubernetes)

예시:

resources:
  requests:
    cpu: "500m"
    memory: "256Mi"
  limits:
    cpu: "1"
    memory: "512Mi"

단위 함정(시험 단골)

CPU: 100m = 0.1 core
Memory: Mi/Gi(2진) vs M/G(10진) 차이 (Kubernetes)

“왜 CPU에 설정이 4개나 있어?”(요청/제한 + 기본/최대/최소)

여기서 말하는 4개는 보통 LimitRange까지 합친 그림입니다.

컨테이너 스펙 수준: requests, limits
네임스페이스 정책 수준(LimitRange): default, defaultRequest, min, max
LimitRange는 “Pod에 명시 안 하면 기본값을 채워 넣고, 범위(min/max)를 강제”합니다. (Kubernetes)

그리고 네임스페이스 전체 총량을 막는 건 ResourceQuota입니다. (Kubernetes)

8) PriorityClass & Preemption: “중요 Pod 먼저, 필요하면 밀어낸다”

PriorityClass는 네임스페이스 범위가 아닌 클러스터 범위 리소스.
Pod에 priorityClassName을 지정.
리소스가 부족하면, 더 높은 우선순위 Pod가 들어올 때 낮은 우선순위 Pod를 선점(preemption)해서 축출할 수 있음.
선점 정책:
- 기본값은 낮은 우선순위 선점(PreemptLowerPriority)
- 선점을 막고 싶으면 preemptionPolicy: Never 계열로 제어 (Kubernetes)

“critical-app을 Running으로 만들려면?”

요구사항이 “high-priority 클래스 부여 → Pod 재생성 → Running 확인”이면, 시험식 답은 다음 흐름입니다.

PriorityClass 만들기(예: high-priority)

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
preemptionPolicy: PreemptLowerPriority
globalDefault: false
description: "High priority for critical workloads"

critical-app Pod에 priorityClassName 넣기

이미 떠 있는 Pod는 대부분 스펙을 마음대로 못 고치므로, 보통 삭제 후 재생성합니다(아래 “Edit Pod” 참고).

확인

kubectl get pod critical-app -o wide
kubectl describe pod critical-app

9) Pod 스펙 편집 제한(시험 단골 실무형 문제)

기존 Pod에서 “직접 수정 가능한” 대표 필드(핵심만)

spec.containers[*].image
spec.initContainers[*].image
spec.activeDeadlineSeconds
spec.tolerations

그 외(env, serviceAccount, resource requests/limits 등)는 일반적으로 running Pod에서 직접 변경 불가.

바꾸고 싶으면 (시험에서 자주 쓰는 2가지 패턴)

패턴 1) kubectl edit pod → 저장 거부 → 임시파일로 재생성

kubectl edit pod webapp
# 저장 시 거부되면, /tmp/... 에 임시 저장된 파일 경로 확인

kubectl delete pod webapp
kubectl create -f /tmp/kubectl-edit-xxxx.yaml

패턴 2) YAML로 뽑아서 수정 후 재생성

kubectl get pod webapp -o yaml > my-new-pod.yaml
vi my-new-pod.yaml
kubectl delete pod webapp
kubectl create -f my-new-pod.yaml

Deployment는 다름(템플릿 바꾸면 롤링으로 새 Pod 뜸)

kubectl edit deployment my-deployment

10) Static Pod (manifest path): “kubelet이 파일로 직접 띄움”

Static Pod는 API Server 없이도 kubelet이 특정 디렉터리를 감시해 파일 기반으로 Pod를 생성/삭제/재생성합니다.
클러스터에 붙어있으면 API 서버에는 mirror pod(읽기 전용)로 보일 수 있습니다.
manifest 경로는 kubelet 설정에서 확인:
- kubelet 옵션에 --pod-manifest-path가 있거나
- kubelet config에 staticPodPath가 있음

실습/시험에서 자주 하는 것:

control-plane 컴포넌트가 static pod로 떠있는지 확인
manifest 위치 찾아서 수정 → kubelet이 재생성하는지 확인

11) Multiple Schedulers / schedulerName: 특정 Pod만 다른 스케줄러 사용

Pod에 spec.schedulerName을 지정하면 해당 이름의 스케줄러(또는 프로필)가 스케줄링을 담당합니다. (Kubernetes)
시험에서의 포인트는 보통:
- “Pod가 계속 Pending인데 schedulerName이 잘못됨”
- “이 Pod는 my-scheduler로 스케줄되게 하라”

예시:

spec:
  schedulerName: my-scheduler

12) 스케줄러 Config 예시(요청했던 “감 잡는” 샘플)

(A) 기본 kube-scheduler config에서 프로필 이름 주기(개념 예시)

“프로필 이름 = 스케줄러 이름처럼” Pod의 schedulerName과 매칭된다는 점이 핵심입니다. (Kubernetes)

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: default-scheduler
- schedulerName: my-scheduler
  plugins:
    score:
      disabled:
      - name: ImageLocality

13) 시험장에서 “빨리 풀기” 체크리스트

(1) Pending Pod 문제

describe 이벤트에 답이 거의 다 있음
resources(요청), taint/toleration, affinity/selector, PVC 상태부터 확인

(2) 노드에 “정확히 올려라”

nodeSelector / nodeAffinity(required)로 강제
노드가 거부권 필요하면 taint + toleration 결합

(3) “각 노드에 1개”

DaemonSet

(4) “중요한 Pod 먼저”

PriorityClass + (필요 시) preemptionPolicy 이해 (Kubernetes)

아래는 CKA 시험 스타일로 만든 **25문항(문제 + 정답)**입니다.
전부 Workloads & Scheduling 범위(라벨/셀렉터, taint/toleration, affinity, resources, priority, daemonset, static pod, schedulerName, 디버깅)를 중심으로 구성했습니다.

표기 규칙

네임스페이스가 없으면 default로 가정

노드는 예시로 node01 node02 node03 사용(실제 환경에 맞게 바꿔서 실행)

이미지/리소스 값은 예시이며, 시험장에선 요구사항대로 입력

1) (라벨) node01에 size=large 라벨 추가

문제

node01에 size=large 라벨을 추가하라.

정답

kubectl label node node01 size=large
kubectl get node node01 --show-labels

2) (NodeSelector) Pod dp를 size=large 노드에만 스케줄

문제

nginx Pod dp를 생성하되, size=large 라벨이 있는 노드에만 배치하라.

정답

# dp.yaml
apiVersion: v1
kind: Pod
metadata:
  name: dp
spec:
  nodeSelector:
    size: large
  containers:
  - name: nginx
    image: nginx

kubectl apply -f dp.yaml
kubectl get pod dp -o wide

3) (Affinity 필수) size In (large, medium)만 허용

문제

Pod api를 생성하되, size 라벨이 large 또는 medium인 노드에만 스케줄되게 하라.

정답

apiVersion: v1
kind: Pod
metadata:
  name: api
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: size
            operator: In
            values: ["large","medium"]
  containers:
  - name: nginx
    image: nginx

kubectl apply -f api.yaml
kubectl get pod api -o wide

4) (Affinity 선호) size=large를 선호하되, 없으면 아무데나

문제

Pod web는 가능하면 size=large 노드에 가게 하되, 없으면 다른 노드도 허용하라.

정답

apiVersion: v1
kind: Pod
metadata:
  name: web
spec:
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 50
        preference:
          matchExpressions:
          - key: size
            operator: In
            values: ["large"]
  containers:
  - name: nginx
    image: nginx

5) (Taint) node02에 app=blue:NoSchedule 테인트

문제

node02에 app=blue:NoSchedule 테인트를 추가하라.

정답

kubectl taint node node02 app=blue:NoSchedule
kubectl describe node node02 | sed -n '/Taints/,+3p'

6) (Toleration) 위 테인트를 견디는 Pod 만들기

문제

Pod blue-pod는 app=blue:NoSchedule 테인트가 있는 노드에도 스케줄 가능해야 한다.

정답

apiVersion: v1
kind: Pod
metadata:
  name: blue-pod
spec:
  tolerations:
  - key: "app"
    operator: "Equal"
    value: "blue"
    effect: "NoSchedule"
  containers:
  - name: nginx
    image: nginx

7) (Taint 제거) node02의 테인트 제거

문제

node02에서 app=blue:NoSchedule 테인트를 제거하라.

정답

kubectl taint node node02 app=blue:NoSchedule-
kubectl describe node node02 | sed -n '/Taints/,+3p'

8) (NoExecute) 테인트로 기존 Pod 축출 + 예외 Pod 유지

문제

node03에 dedicated=teamA:NoExecute 테인트를 추가하라.
Pod keep는 계속 남아야 하며(허용), Pod kick은 축출되어야 한다(허용 X).

정답

keep 생성(허용 포함)

apiVersion: v1
kind: Pod
metadata:
  name: keep
spec:
  nodeName: node03
  tolerations:
  - key: "dedicated"
    operator: "Equal"
    value: "teamA"
    effect: "NoExecute"
  containers:
  - name: nginx
    image: nginx

kick 생성(허용 없음)

apiVersion: v1
kind: Pod
metadata:
  name: kick
spec:
  nodeName: node03
  containers:
  - name: nginx
    image: nginx

테인트 적용

kubectl apply -f keep.yaml
kubectl apply -f kick.yaml
kubectl taint node node03 dedicated=teamA:NoExecute
kubectl get pod keep kick -o wide
kubectl describe pod kick | tail -n 30

9) (수동 스케줄) 스케줄러 우회해서 node01에 강제 배치

문제

Pod manual을 스케줄러를 거치지 않고 node01에 올려라.

정답

apiVersion: v1
kind: Pod
metadata:
  name: manual
spec:
  nodeName: node01
  containers:
  - name: nginx
    image: nginx

10) (디버깅) Pending 원인 1차 진단 커맨드만 제출

문제

Pod stuck이 Pending이다. 원인 확인을 위한 최소 커맨드 3개를 제시하라.

정답

kubectl get pod stuck -o wide
kubectl describe pod stuck
kubectl get events --sort-by=.lastTimestamp | tail -n 30

11) (Field selector) node01에 올라간 모든 Pod 조회

문제

node01에 스케줄된 Pod를 모두 조회하라(네임스페이스 전체).

정답

kubectl get pod -A -o wide --field-selector spec.nodeName=node01

12) (Label selector) app=frontend Pod만 조회

문제

라벨 app=frontend인 Pod만 조회하라.

정답

kubectl get pod -l app=frontend
# 또는
kubectl get pod --selector app=frontend

13) (Deployment imperative) 아래 명령이 실패한다. 올바르게 고쳐라

문제

사용자가 실행한 명령:

kubectl create deployments blue --image=nginx --replicas=3

올바른 명령으로 고쳐라.

정답

kubectl create deployment blue --image=nginx --replicas=3
kubectl get deploy blue

14) (DaemonSet imperative) kube-system에 DaemonSet 생성

문제

kube-system 네임스페이스에 DaemonSet log-agent를 nginx 이미지로 생성하라.

정답

daemonset은 deployment로 만들고 바꿔치기로 해야함. 아래 방법은 실제로 안되는 방법.

kubectl -n kube-system create daemonset log-agent --image=nginx
kubectl -n kube-system get ds log-agent
kubectl -n kube-system get pod -l app=log-agent -o wide

15) (DaemonSet YAML) 모든 노드에 busybox를 1개씩 상주시켜라

문제

DaemonSet bb를 만들어 모든 노드에 busybox가 1개씩 뜨게 하라(무한 대기).

정답

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: bb
spec:
  selector:
    matchLabels:
      app: bb
  template:
    metadata:
      labels:
        app: bb
    spec:
      containers:
      - name: bb
        image: busybox
        command: ["sh","-c","sleep 360000"]

kubectl apply -f bb-ds.yaml
kubectl get ds bb
kubectl get pod -l app=bb -o wide

16) (Resources) Pod에 requests/limits 설정

문제

Pod res를 생성하라:

requests: cpu 200m, memory 128Mi
limits: cpu 500m, memory 256Mi

정답

apiVersion: v1
kind: Pod
metadata:
  name: res
spec:
  containers:
  - name: app
    image: nginx
    resources:
      requests:
        cpu: "200m"
        memory: "128Mi"
      limits:
        cpu: "500m"
        memory: "256Mi"

17) (LimitRange) default requests/limits 강제

문제

네임스페이스 dev에 LimitRange를 생성하라:

defaultRequest: cpu 100m, memory 64Mi
default: cpu 200m, memory 128Mi

정답

kubectl create ns dev

apiVersion: v1
kind: LimitRange
metadata:
  name: defaults
  namespace: dev
spec:
  limits:
  - type: Container
    defaultRequest:
      cpu: "100m"
      memory: "64Mi"
    default:
      cpu: "200m"
      memory: "128Mi"

kubectl apply -f lr.yaml
kubectl -n dev describe limitrange defaults

18) (ResourceQuota) 네임스페이스 총량 제한

문제

네임스페이스 dev에 ResourceQuota를 생성하라:

requests.cpu 합: 1
requests.memory 합: 1Gi
limits.cpu 합: 2
limits.memory 합: 2Gi

정답

apiVersion: v1
kind: ResourceQuota
metadata:
  name: rq
  namespace: dev
spec:
  hard:
    requests.cpu: "1"
    requests.memory: "1Gi"
    limits.cpu: "2"
    limits.memory: "2Gi"

kubectl apply -f rq.yaml
kubectl -n dev describe quota rq

19) (Pod 수정 제한) env 변경이 안 된다 → 올바른 절차로 반영

문제

실행 중인 Pod webapp의 env를 바꾸려고 kubectl edit pod webapp을 했더니 저장이 거부된다.
올바르게 반영하라(재생성 방식).

정답(가장 시험스러운 답)

kubectl get pod webapp -o yaml > webapp-new.yaml
vi webapp-new.yaml   # env 수정
kubectl delete pod webapp
kubectl create -f webapp-new.yaml
kubectl get pod webapp -o wide

20) (Deployment는 edit 가능) deploy 템플릿 env 수정

문제

Deployment api의 Pod 템플릿 env를 수정하라. (rolling update로 새 Pod가 떠야 함)

정답

kubectl edit deployment api
# spec.template.spec.containers[0].env 수정
kubectl rollout status deployment api
kubectl get pod -l app=api -o wide

21) (PriorityClass) high-priority 생성 + critical Pod에 적용

문제

PriorityClass high-priority를 만들고 value=1000000
Pod critical-app에 이를 적용하여 Running으로 만들어라(필요 시 선점 발생)

정답

PriorityClass 생성

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
preemptionPolicy: PreemptLowerPriority
description: "High priority for critical workloads"

kubectl apply -f pc.yaml
kubectl get priorityclass high-priority

Pod에 적용(대부분 재생성)

kubectl get pod critical-app -o yaml > critical-new.yaml
vi critical-new.yaml  # spec.priorityClassName: high-priority 추가
kubectl delete pod critical-app
kubectl create -f critical-new.yaml
kubectl get pod critical-app -o wide

22) (Preemption 막기) 높은 우선순위지만 선점 금지

문제

PriorityClass high-no-preempt를 만들되, 우선순위는 높고(prefer), 선점은 금지하라.

정답

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-no-preempt
value: 900000
preemptionPolicy: Never
globalDefault: false

23) (schedulerName) 특정 Pod만 my-scheduler로 스케줄되게

문제

Pod special을 생성하되 my-scheduler가 스케줄링하도록 설정하라.

정답

apiVersion: v1
kind: Pod
metadata:
  name: special
spec:
  schedulerName: my-scheduler
  containers:
  - name: nginx
    image: nginx

검증(이벤트에서 스케줄러 출처 확인)

kubectl get events --sort-by=.lastTimestamp | tail -n 30
kubectl describe pod special | tail -n 50

24) (Static Pod) kubelet manifest 경로 찾기

문제

Static Pod 매니페스트 디렉터리를 찾아라. (kubeadm 환경일 수도 있음)

정답(대표 루트)

kubelet 프로세스/서비스 옵션에서 확인

ps -ef | grep kubelet | grep -E 'pod-manifest-path|config'

kubelet config 파일에서 staticPodPath 확인

# 예: /var/lib/kubelet/config.yaml 같은 곳이 흔함(환경마다 다름)
sudo cat /var/lib/kubelet/config.yaml | grep -n "staticPodPath"

kubeadm control plane에서 흔한 경로(검사)

ls -al /etc/kubernetes/manifests

25) (Static Pod 변경 반영) 매니페스트 수정 → 자동 재생성 확인

문제

Static Pod(예: /etc/kubernetes/manifests/xxx.yaml)의 컨테이너 이미지를 변경하고, 변경이 자동 반영되는지 확인하라.

정답(흐름)

sudo vi /etc/kubernetes/manifests/<static-pod>.yaml
# spec.containers[].image 수정

확인

kubectl get pod -n kube-system -o wide | grep <static-pod-키워드>
kubectl describe pod -n kube-system <podname> | grep -n "Image"

보너스: 실제 시험 풀이 순서(문제 풀이용 공통 루틴)

스케줄링 관련 문제는 대부분 아래 순서로 풀면 빠릅니다.

요구사항이 “어디에 배치”인지 확인
- nodeSelector/nodeAffinity?
- taint/toleration?
- daemonset?
Pending이면 describe 이벤트부터 확인
수정 문제면 Pod인지 Deployment인지 구분
- Pod면 재생성 패턴
- Deployment면 edit/patch/rollout

'CKA' 카테고리의 다른 글

CKA 명령어 시험 (0)	2026.01.15
CKA 명령어 정리 (1)	2026.01.15
Kustomize - 총 정리 (0)	2026.01.08
Kustomize - Components (0)	2026.01.08
Kustomize - Overlays (0)	2026.01.08