태그 보관물: CKAD

K8S

CKAD briefing – 20250618

댓글 남기기

개요

2025년 6월 18일 CKAD(Certified Kubernetes Application Developer) 시험을 응시하였습니다. 이 글은 기억에 의존해 복기한 출제 문제 브리핑입니다. 오류가 있을 수 있으므로 참고 자료로만 활용하시기 바랍니다.

CKAD 시험의 주요 특징은 다음과 같습니다.

  • 시험 시간: 2시간
  • 문제 형식: 실습형(Hands-on) — 브라우저 기반 터미널에서 직접 kubectl 명령어 실행
  • 합격 기준: 66점 이상 (100점 만점)
  • 공식 문서 참조 허용: 시험 중 kubernetes.io/docs와 kubernetes.io/blog 접속 허용
  • 주요 출제 영역: Workloads(Deployment, CronJob), Configuration(ConfigMap, Secret), Services & Networking(Ingress, NetworkPolicy), RBAC, Storage(PVC)

아래 출제 문제 목록은 해당 시험 회차의 기억 기반 복기이며, 실제 시험은 회차마다 문제가 다르게 출제됩니다.

출제 문제 목록

아래는 해당 시험 회차에서 출제된 주요 문제 목록입니다.

  1. RBAC(deployment scraper, namespace cute-panda) sa scraper 생성 > clusterrole(resource pod, list) > clusterrole bind > deployment sa 할당
  2. serviceaccount ※ system:serviceaccount:gorilla:gorilla-sa – 권한 있는 sa로 deployment 할당
  3. postgre deployment의 ENV를 참고해서 secret을 생성 하는 문제
  4. pod resource requests pod에 적용
  5. pod resource requests 적용, limitrange max memory 사이즈의 1/2을 limit에 적용하라 였음
  6. readiness httpget /healthz port 8081, initialdelayseconds, periodseconds 수정 문제
  7. Cronjob – activedeadline: 8, restartPolicy: Never, .spec.successfulJobsHistoryLimit and .spec.failedJobsHistoryLimit 나옴, grep-test job 도 생성 해야 되는 것 같음
  8. 구버전 kube yaml 수정 문제, namespace 도 수정하라고 했음
  9. rolling update 문제
  10. pod security – user id, allowPrivilegeEscalation: false 수정
  11. network policy 라벨 추가 문제 db-access, front-access
  12. canary – 8:2 조정하라고 나옴
  13. docker…
  14. maxSurge, maxUnavailable 수정 후 nginx 버전 변경 후 rollout undo
  15. deployment 레이블 추가, replicas 변경 후 k expose deployment [deployment] –type NodePort –name alice? 생성 문제
  16. deployment의 컨테이너 포트 참고해서 ingress, service yaml 포트, path 변경
  17. ingress 도메인 적용 생성 문제

출제 주제 분류

위 17개 문제를 출제 주제별로 분류하면 다음과 같습니다.

  • RBAC / ServiceAccount — 문제 1, 2 (권한 부여, ServiceAccount 할당)
  • Secret / ConfigMap — 문제 3 (ENV → Secret 분리)
  • Resource 관리 — 문제 4, 5 (requests, LimitRange)
  • Probe / 헬스체크 — 문제 6 (readinessProbe HTTP GET)
  • CronJob / Job — 문제 7 (activeDeadlineSeconds, historyLimit)
  • 구 버전 YAML 수정 — 문제 8 (deprecated spec 수정)
  • 롤링 업데이트 / 롤백 — 문제 9, 14 (rolling update, rollout undo)
  • Pod Security — 문제 10 (userId, allowPrivilegeEscalation)
  • NetworkPolicy — 문제 11 (ingress/egress 레이블 기반)
  • Canary 배포 — 문제 12 (replica 비율 조정)
  • Deployment / Service — 문제 15 (레이블, replicas, NodePort 생성)
  • Ingress — 문제 16, 17 (포트/path 수정, 도메인 Ingress 생성)

RBAC, Secret, CronJob, Ingress, NetworkPolicy, 롤링 업데이트가 핵심 출제 영역임을 알 수 있습니다. 각 주제별 상세 풀이는 개별 포스트를 참고하세요.

참고

참고 문서: CKAD 시험 공식 정보 · Kubernetes 공식 문서

K8S

CKAD RBAC 문제 후기 – 20250618

댓글 남기기

개요

CKAD 시험에서 출제된 RBAC(Role-Based Access Control) 문제 풀이를 기록합니다. ServiceAccount를 생성하고 ClusterRole과 ClusterRoleBinding으로 권한을 부여한 후 Deployment에 ServiceAccount를 할당하는 절차를 다룹니다.

출제 문제

※ 기억에 의존해 복기하는 문제라 오류가 있을 수 있습니다.
참고만 부탁 드립니다.

  • namespace가 cute-panda 이고 deployment가 scraper인 pod에서 error log를 확인할 것
  • “system:serviceaccount:cute-panda:scraper” cannot Iist resource “pods” error log 처리를 위해 필요한 처리와 적절한 role를 적용할 것

해결 방법

# scraper deployment가 생성한 pod 명 확인 후 *에 적용
$ k pod -n cute-panda
$ k logs -n cute-panda scraper-*
# error log 확인

# Service Account 생성
$ k create sa -n cute-panda scraper

# 결과값 no 확인
$ k auth can-i list pods –as=system:serviceaccount:cute-panda:scraper -n scraper

# clusterrole 생성 및 clusterrolebinding 생성 처리
k create clusterrole cr –verbs=list –resource=pods -n cute-panda
k create clusterrolebinding crb –clusterrole=cr –serviceaccount=cute-panda:scraper

# scraper deployment에 scraper service account 적용
$ k set serviceaccount deployment -n cute-panda scraper scraper

# 결과값 yes 확인
$ k auth can-i list pods –as=system:serviceaccount:cute-panda:scraper -n scraper

# pod 재생성 확인 및 생성된 pod 명 확인 후 *에 적용
$ k pod -n cute-panda
$ k logs -n cute-panda scraper-*
# error log 미발생 확인

RBAC 핵심 개념

Kubernetes RBAC(Role-Based Access Control)는 누가(ServiceAccount/User), 어떤 리소스(pods/services/deployments)에, 어떤 동작(get/list/create/delete)을 할 수 있는지를 세밀하게 제어하는 접근 권한 시스템입니다. 시험과 실무에서 자주 쓰이는 네 가지 핵심 리소스를 이해하면 대부분의 RBAC 문제를 해결할 수 있습니다.

Role은 특정 네임스페이스 내에서만 유효한 권한 집합이고, ClusterRole은 클러스터 전체 또는 모든 네임스페이스에서 유효합니다. RoleBinding은 Role(또는 ClusterRole)을 특정 네임스페이스의 ServiceAccount/User에 바인딩하며, ClusterRoleBinding은 ClusterRole을 클러스터 전체 범위로 바인딩합니다. 이 문제처럼 모든 네임스페이스의 pod를 list할 권한이 필요하면 ClusterRole + ClusterRoleBinding 조합이 적합합니다.

# 현재 ServiceAccount의 권한 확인 (auth can-i)
kubectl auth can-i list pods   --as=system:serviceaccount:cute-panda:scraper -n cute-panda

# Deployment에 적용된 ServiceAccount 확인
kubectl get deployment scraper -n cute-panda   -o jsonpath='{.spec.template.spec.serviceAccountName}'

# ClusterRole이 부여하는 권한 상세 확인
kubectl describe clusterrole cr

CKAD 시험에서는 명령형(imperative) 방식으로 빠르게 생성하는 것이 시간 단축에 유리합니다. kubectl create clusterrole, kubectl create clusterrolebinding, kubectl set serviceaccount 명령어를 숙지해두면 YAML 파일 없이도 신속하게 구성할 수 있습니다.

kubectl 명령형 방식으로 빠르게 생성하기

CKAD 시험에서는 YAML 파일 작성보다 kubectl의 명령형(imperative) 명령어로 빠르게 리소스를 생성하는 방법이 시간 절약에 유리합니다. ClusterRole, ClusterRoleBinding, ServiceAccount 모두 단일 명령으로 생성이 가능하며, kubectl auth can-i로 권한 부여 결과를 즉시 확인할 수 있습니다.

RBAC에서 자주 혼동하는 점은 ClusterRoleBinding으로 ClusterRole을 특정 네임스페이스의 ServiceAccount에 바인딩하더라도 그 권한은 클러스터 전체에 적용된다는 것입니다. 이 문제에서 k auth can-i list pods -n scraper를 통해 cute-panda 네임스페이스의 ServiceAccount가 다른 네임스페이스인 scraper에서도 pod를 list할 수 있음을 확인할 수 있습니다. 반면 RoleBinding은 해당 네임스페이스 내에서만 권한을 부여하므로 단일 네임스페이스 범위 제어에는 Role + RoleBinding 조합을 사용합니다.

CKAD 시험에서 RBAC 문제는 kubectl create clusterrole, kubectl create clusterrolebinding, kubectl set serviceaccount 세 명령어의 옵션을 정확히 숙지하면 YAML 없이도 빠르게 해결할 수 있습니다.

참고

참고 문서: kubectl create clusterrole · kubectl create clusterrolebinding

K8S

CKAD Ingress 문제 후기 – 20250618

댓글 남기기

개요

CKAD 시험에서 출제된 Ingress 문제 풀이를 기록합니다. 기존 Service를 백엔드로 연결하는 Ingress를 YAML 파일로 작성하여 도메인 기반 라우팅을 구성하는 문제입니다.

출제 문제

※ 기억에 의존해 복기하는 문제라 오류가 있을 수 있습니다.
참고만 부탁 드립니다.

  • 사용자가 www.example.com URL로 접속할 때 라우팅이 가능하도록 Ingress를 생성
  • 기생성 Service 의 name과 port를 참고 하여 Ingress 반영
    service name : service1
    port : 80
  • Ingress name은 ingressWeb으로 할 것
  • YAML파일을 작성하여 생성할 것

해결 방법

# ingress.yaml 생성

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingressWeb
spec:
  rules:
  - host: "www.example.com"
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: service1
            port:
              number: 80

# Ingress 생성 및 상태 확인
$ kubectl apply -f ingress.yaml
$ kubectl get ingress
$ kubectl describe ingress ingressWeb

Ingress 개념 — NodePort/LoadBalancer와 비교

Kubernetes에서 외부 트래픽을 Pod로 전달하는 방법으로 NodePort, LoadBalancer, Ingress 세 가지가 있습니다. NodePort는 노드 IP + 고정 포트로 직접 접근하며 관리가 번거롭고, LoadBalancer는 서비스마다 외부 IP를 하나씩 할당하므로 클라우드 환경에서 비용이 발생합니다. Ingress는 단일 진입점(IngressController)에서 도메인 이름과 경로 기반으로 여러 서비스를 라우팅할 수 있어 HTTP/HTTPS 트래픽 관리에 가장 적합합니다.

Ingress 리소스 자체는 라우팅 규칙을 정의하는 API 오브젝트이며, 실제 트래픽 처리는 클러스터에 배포된 IngressController(Nginx, Traefik, HAProxy 등)가 담당합니다. IngressController가 설치되지 않은 환경에서는 Ingress를 생성해도 동작하지 않습니다.

# 클러스터에 설치된 IngressClass 확인
kubectl get ingressclass

# Ingress 상태 확인 (ADDRESS 할당 여부)
kubectl get ingress -A

# Ingress 이벤트 및 백엔드 상태 확인
kubectl describe ingress ingressWeb

CKAD 시험에서 Ingress 문제는 대부분 기존 Service에 연결하는 YAML 작성 문제입니다. spec.rules[].host에 도메인, spec.rules[].http.paths[].backend.service.name/port에 Service 정보를 정확히 기입하는 것이 핵심이며, pathType: Prefix와 pathType: Exact의 차이도 숙지해두면 좋습니다.

경로 기반 라우팅과 TLS 설정

Ingress는 도메인 기반 라우팅 외에도 URL 경로 기반 라우팅을 지원합니다. 동일한 도메인에서 /api는 백엔드 서비스로, /static은 프런트엔드 서비스로 각각 라우팅하는 구성이 가능합니다. pathType: Prefix는 지정된 경로로 시작하는 모든 URL을 매칭하고, pathType: Exact는 정확히 일치하는 경우만 처리합니다.

HTTPS를 적용하려면 spec.tls 섹션에 도메인과 TLS Secret을 지정합니다. TLS Secret은 kubernetes.io/tls 타입으로 인증서(tls.crt)와 개인키(tls.key)를 포함해야 합니다. IngressController가 TLS Termination을 처리하면 백엔드 서비스는 HTTP로 통신하면서 외부에는 HTTPS로 노출됩니다. cert-manager와 연동하면 Let’s Encrypt 인증서를 자동으로 발급하고 갱신하는 파이프라인을 구성할 수 있습니다.

CKAD 시험에서는 기존 Service를 IngressClass가 지정된 클러스터에 연결하는 Ingress YAML 작성 문제가 자주 출제됩니다. ingressClassName 필드를 누락하면 IngressController가 Ingress를 처리하지 않을 수 있으므로, 시험 환경에서 kubectl get ingressclass로 사용 가능한 IngressClass 이름을 먼저 확인하는 습관을 들이는 것이 좋습니다.

참고

참고 문서: kubectl create ingress · ingress-nginx → Traefik 마이그레이션 — Traefik v3.7.5 구성