01 Kubernetes 실습을 EC2 master/worker 노드로 시작하는 이유 EC2 세 대는 단순 서버 세 대가 아니라 control-plane과 worker 노드 역할을 나누어 Kubernetes가 스케줄링할 물리적 경계를 만드는 준비임을 이해한다. KT AIVLE School
Kubernetes Practice
EC2 노드 준비에서 Pod, ReplicaSet, Deployment, Service, Namespace, ConfigMap, Volume까지 따라가는 Kubernetes 실습 산문
- 원고
- 12
- 8월 25일-9월 24일
- 0편
01 Kubernetes 실습을 EC2 master/worker 노드로 시작하는 이유 EC2 세 대는 단순 서버 세 대가 아니라 control-plane과 worker 노드 역할을 나누어 Kubernetes가 스케줄링할 물리적 경계를 만드는 준비임을 이해한다. 
02 Kubernetes 설치 전, 준비와 설치의 차이 이해하기 swap 비활성화, containerd 런타임, systemd cgroup, 커널 네트워크 파라미터, kubelet/kubeadm/kubectl의 역할 차이를 설치 전제 조건으로 구분한다. 
03 kubeadm init과 join: 클러스터 심장과 팔다리 연결하기 kubeadm init은 control-plane을 만들고 kubeconfig와 네트워크 애드온 준비를 요구하며, kubeadm join은 worker 노드를 그 제어면에 붙이는 명령임을 이해한다. 
04 Pod Manifest, 단순한 '생성'을 넘어선 '실행'의 여정 Pod manifest는 API 서버에 원하는 상태를 제출하는 문서이고, kubectl get/describe/curl은 그 상태가 실제 실행과 네트워크 응답으로 이어졌는지 확인하는 방법임을 이해한다. 
05 Pod 상태 진단, 'Running'을 넘어선 세 가지 시선: exec, logs, delete exec는 컨테이너 내부 관찰, logs는 표준 출력 확인, delete는 원하는 상태 제거와 수명주기 변화를 확인하는 도구임을 구분한다. 
06 Kubernetes ReplicaSet: Pod의 '주인'을 찾아 원하는 수를 유지하는 법 ReplicaSet은 desired count를 유지하는 컨트롤러이며, selector.matchLabels와 Pod template labels가 ownership 판단의 핵심임을 이해한다. 
07 Deployment: ReplicaSet을 넘어선 스마트한 배포 Deployment는 Pod template의 버전을 관리하고 ReplicaSet을 통해 rollout/rollback 가능한 변경 흐름을 만든다는 점을 이해한다. 
08 Pod 변화 속 안정적인 접속: Kubernetes Service 이해하기 Service는 selector로 Pod 집합을 잡고, type에 따라 내부 전용, 노드 포트, 외부 로드밸런서 접속 경계를 다르게 연다는 점을 이해한다. 
09 Kubernetes Namespace: 클러스터 안의 논리적 구분 Namespace는 물리 노드 분리가 아니라 API 리소스의 이름과 조회 범위를 나누는 논리 공간이며, 같은 이름의 리소스도 범위가 다르면 별도로 관리됨을 이해한다. 
10 ConfigMap/Secret과 Pod 설정 주입 메커니즘 ConfigMap/Secret은 Pod spec에서 envFrom, configMapKeyRef, volumeMounts로 참조되어 컨테이너 실행 환경에 들어가는 외부 설정임을 이해한다. 
11 emptyDir와 hostPath로 Pod 안팎의 파일 위치 구분하기 emptyDir는 한 Pod 안 컨테이너들이 공유하는 임시 공간이고, hostPath는 노드 파일시스템의 경로를 Pod에 연결하는 방식임을 구분한다. 
12 PV와 PVC: 저장소의 공급과 요청, 누가 누구인가? PV는 클러스터에 제공된 저장소이고 PVC는 Pod가 필요한 저장소를 요청하는 티켓이며, Pod는 claimName으로 PVC를 참조해 마운트한다는 구조를 이해한다.