K8S

Kubernetes cluster name 지정 생성

2025년 7월 31일 Jason 댓글 남기기

개요

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 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 공식 문서

Cisco, MikroTik

Mikrotik router & Cisco L2 Switch Trunking

2025년 7월 31일 Jason 댓글 남기기

개요

VLAN Trunking은 하나의 물리 링크에서 여러 VLAN 트래픽을 IEEE 802.1Q 태그로 구분해 전달하는 기술입니다. 이 글에서는 MikroTik RouterOS와 Cisco IOS 스위치를 혼용하는 환경에서 trunk 포트를 설정하여 VLAN 간 통신을 구성하는 방법을 정리합니다.

Scenario

Mikrotik router 와 Cisco L2 스위치 이기종간에 회선 이중화(bonding, etherchannel) 후 두 장비 모두 vlan 100(192.168.100.0/24), vlan 200(192.168.200.0/24)의 통신이 가능하도록 구성

# Mikrotik router side
# bridge 생성
/interface bridge
add name=bridge-lan vlan-filtering=yes

# vlan 생성 및 bridge 할당
/interface vlan
add interface=bridge-lan name=vlan100 vlan-id=100
add interface=bridge-lan name=vlan200 vlan-id=200

# bonding 생성(ether2, ether3 포트 대상)
/interface bonding
add mode=802.3ad name=bonding1 slaves=ether2,ether3 transmit-hash-policy=\
    layer-2-and-3

# trunk 처리, bridge-lan에 포함된 port 중 trunk 대상 아닌 경우 untagged port 처리
/interface bridge port
add bridge=bridge-lan frame-types=admit-only-vlan-tagged interface=bonding1
add bridge=bridge-lan tagged=bonding1,bridge-lan untagged=\
    ether4,ether5,ether6 vlan-ids=100,200

# vlan IP 및 대역 할당
/ip address
add address=192.168.100.1/24 interface=vlan100 network=192.168.100.0
add address=192.168.200.1/24 interface=vlan200 network=192.168.200.0

# Cisco L2 switch side

configure terminal

# vlan IP 및 대역 할당
interface Vlan100
 ip address 192.168.100.2 255.255.255.0
interface Vlan200
 ip address 192.168.200.2 255.255.255.0

# etherchannel 구성(GigabitEthernet0/1, GigabitEthernet0/2 포트 대상)
interface range GigabitEthernet0/1-2
 channel-protocol lacp
 channel-group 1 mode active

# 생성된 etherchannel에 trunk 모드 및 trunking할 vlan 적용
interface Port-channel1
 switchport trunk allowed vlan 100,200
 switchport mode trunk

end
write

링크 이중화(LACP) 방식 비교

이 구성에서는 MikroTik 측의 Bonding(802.3ad LACP)과 Cisco 측의 EtherChannel(LACP)을 상호 연결합니다. 두 장비 모두 LACP 프로토콜을 사용하여 물리 링크를 하나의 논리 인터페이스로 묶어 대역폭 확장과 링크 이중화를 동시에 달성합니다.

MikroTik은 mode=802.3ad로 LACP를 활성화하고 transmit-hash-policy=layer-2-and-3으로 로드밸런싱 해시를 L2+L3 기반으로 설정합니다. Cisco는 channel-protocol lacp와 channel-group 1 mode active로 LACP 협상을 능동적으로 시작합니다. 양쪽 모두 LACP active 모드로 설정하면 협상이 정상적으로 진행됩니다.

VLAN Trunk 트러블슈팅

이기종 장비 간 VLAN Trunk 구성 시 통신 오류가 발생하면 아래 항목을 순서대로 확인합니다.

# MikroTik: LACP 협상 상태 및 bonding 멤버 확인
/interface bonding monitor bonding1

# MikroTik: bridge VLAN 설정 확인
/interface bridge vlan print

# MikroTik: bridge port frame-type 확인
/interface bridge port print

# Cisco: EtherChannel 상태 확인
show etherchannel summary
show interfaces port-channel 1 trunk

# Cisco: VLAN trunk 허용 목록 확인
show interfaces trunk

가장 흔한 오류는 MikroTik의 bridge VLAN filtering이 비활성화된 경우와 Cisco trunk의 allowed VLAN 목록이 일치하지 않는 경우입니다. 또한 LACP 협상이 실패하면 단일 링크만 활성화되거나 링크 자체가 down될 수 있으므로 양쪽의 LACP 상태를 동시에 확인하는 것이 중요합니다.

VLAN 구성 검증 절차

MikroTik과 Cisco 이기종 VLAN Trunk 구성 완료 후에는 단계적으로 통신을 검증합니다. 먼저 각 VLAN 인터페이스에 IP를 할당하고 동일 VLAN 내에서 핑이 통하는지 확인합니다. 다음으로 VLAN 간 통신은 MikroTik의 라우팅 또는 Cisco L3 스위치의 인터 VLAN 라우팅을 통해 확인합니다.

VLAN 100과 VLAN 200 사이의 통신이 필요한 경우 MikroTik에서 두 VLAN 인터페이스 간 라우팅이 활성화되어 있어야 합니다. MikroTik은 기본적으로 인터페이스 간 포워딩이 활성화되어 있어 별도 라우팅 설정 없이 VLAN 간 통신이 가능하지만, 방화벽 규칙에 따라 차단될 수 있습니다. /ip firewall filter print로 방화벽 규칙을 확인하고 필요한 경우 forward 체인에 허용 규칙을 추가합니다.

Cisco 측에서는 show interfaces trunk로 trunk 포트에서 허용된 VLAN 목록을 확인하고, show mac address-table로 각 VLAN의 MAC 주소가 올바른 포트에 학습되었는지 검증합니다. 링크 다운이나 VLAN 통신 오류 발생 시 양쪽 장비의 로그를 동시에 확인하면 원인 파악이 빠릅니다.

참고

참고 문서: MikroTik VLAN 공식 문서 · Cisco VLAN/VTP 설정 가이드

K8S

CKAD briefing – 20250618

2025년 7월 29일 Jason 댓글 남기기

개요

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)

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

출제 문제 목록

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

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

IT Garage