태그 보관물: kubernetes

K8S

Kubernetes cluster name 지정 생성

댓글 남기기

개요

kubeadm init을 추가 옵션 없이 실행하면 기본 클러스터 이름인 kubernetes로 생성됩니다. Kubernetes cluster name을 원하는 이름으로 지정하려면 kubeadm 설정 파일에 clusterName을 명시하고 --config 옵션으로 초기화해야 합니다. 이 글에서는 kubeadm config 파일을 사용해 원하는 cluster name으로 Kubernetes를 초기화하는 방법을 정리합니다.

클러스터 이름이 중요한 이유

kubeadm으로 Kubernetes를 초기화하면 기본 cluster name인 kubernetes가 kubeconfig(~/.kube/config)에 등록됩니다. 단일 클러스터만 운영할 때는 문제가 없지만, 여러 클러스터를 동시에 관리하는 환경에서는 cluster name이 동일하면 kubeconfig 병합 시 충돌이 발생합니다. 개발(dev), 스테이징(staging), 운영(prod) 클러스터를 각각 의미있는 이름으로 구분하면 kubectl config use-context로 쉽게 전환하고 실수를 방지할 수 있습니다.

클러스터 이름은 kubeconfig의 clusters[].name, contexts[].context.cluster 필드에 반영됩니다. 이미 초기화된 클러스터에서 내부 cluster name을 변경하는 것은 etcd 데이터 수정이 필요하므로 매우 복잡합니다. 처음 kubeadm init 시점에 올바른 이름을 지정하는 것이 중요합니다.

kubeadm으로 Kubernetes를 초기화하면 기본 cluster name인 kubernetes가 kubeconfig(~/.kube/config)에 등록됩니다. 단일 클러스터만 운영할 때는 문제가 없지만, 여러 클러스터를 동시에 관리하는 환경에서는 cluster name이 동일하면 kubeconfig 병합 시 충돌이 발생합니다. 개발(dev), 스테이징(staging), 운영(prod) 클러스터를 각각 의미있는 이름으로 구분하면 kubectl config use-context로 쉽게 전환하고 실수를 방지할 수 있습니다.

kubeadm config 파일 작성

ClusterConfiguration의 clusterName 필드에 원하는 이름을 지정합니다. 이름에는 영소문자, 숫자, 하이픈(-)만 사용하는 것이 권장됩니다. cri-dockerd를 사용하는 환경에서는 InitConfiguration의 criSocket을 함께 선언합니다. cri-dockerd를 사용하는 환경에서는 InitConfiguration에 criSocket을 함께 선언합니다.

# cluster-config.yaml 생성
# criSocket 옵션이 필요한 경우 InitConfiguration을 추가합니다. 불필요 시 ClusterConfiguration만 선언하면 됩니다.
cat << EOF > cluster-config.yaml
apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
nodeRegistration:
  criSocket: /var/run/cri-dockerd.sock
---
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
clusterName: my-cluster
kubernetesVersion: stable
controlPlaneEndpoint: "<master-node>:6443"
networking:
  podSubnet: "10.244.0.0/16"
EOF

Kubernetes 클러스터 초기화

작성한 config 파일을 --config 옵션으로 지정하여 kubeadm init을 실행합니다.

sudo kubeadm init --config=cluster-config.yaml

결과 확인

초기화 완료 후 kubectl config get-clusters로 cluster name이 지정한 이름으로 생성되었는지 확인합니다.

kubectl config get-clusters
NAME
my-cluster

멀티 클러스터 kubeconfig 병합

여러 클러스터의 kubeconfig를 하나의 파일로 병합하면 kubectl config use-context <name>으로 클러스터를 전환할 수 있습니다. 각 클러스터의 kubeconfig를 별도 파일로 저장한 뒤 KUBECONFIG 환경변수에 콜론으로 구분하여 나열하면 kubectl이 자동으로 병합하여 처리합니다.

# 두 kubeconfig 파일을 병합하여 새 파일 생성
KUBECONFIG=~/.kube/config-dev:~/.kube/config-prod   kubectl config view --flatten > ~/.kube/config-merged

# 병합된 config에서 context 목록 확인
kubectl --kubeconfig ~/.kube/config-merged config get-contexts

클러스터 이름을 처음부터 고유하게 설정해두면 이 병합 과정에서 충돌 없이 깔끔하게 합쳐집니다. 반면 기본값인 kubernetes를 그대로 사용하면 병합 시 cluster, context, user 항목이 모두 덮어써지는 문제가 발생합니다.

기존 클러스터의 Context name 변경 방법

이미 생성된 클러스터에서 context 이름을 변경하려면 kubectl config rename-context를 사용합니다. 이 방법은 kubeconfig 상의 context 이름만 변경하며, 클러스터 자체의 내부 이름은 변경되지 않습니다.

# 현재 context 목록 확인
kubectl config get-contexts

# context 이름 변경 (kubernetes → my-cluster)
kubectl config rename-context kubernetes my-cluster

# 변경 확인
kubectl config current-context

참고

참고 문서: kubeadm ClusterConfiguration API 레퍼런스 · kubectl config rename-context 공식 문서

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