Kubernetes(쿠버네티즈)

열공하는웅2·2025년 11월 11일

클라우드

목록 보기

8/13

vagrant up
vagrant ssh
minikube start

minikube

nano -c nginx.yml

1->3

kubectl run -it nginx --image:nginx -- /bin/sh
kubectl run -it nginx --image=nginx:latest -- /bin/sh

🧩 쿠버네티스 기본 개념 정리

🔹 Pod

하나 이상의 컨테이너로 구성된 쿠버네티스의 최소 실행 단위.
같은 Pod 내부의 컨테이너들은 네임스페이스(Namespace) 를 공유하여 내부 IP로 직접 통신 가능.
외부와 연결할 때는 Service 리소스의 ClusterIP 등을 통해 접근한다.
서로 다른 Pod은 네트워크적으로 분리되어 있다.

🔹 Deployment

애플리케이션의 배포 및 버전 관리를 담당하는 리소스.
파드를 자동으로 생성하고, replicas에서 지정한 개수만큼 파드를 유지.
Rolling Update로 이미지 버전 변경 시 순차적으로 업데이트하며,
필요시 Rollback으로 이전 버전으로 복구 가능.
파드가 죽으면 자동으로 새 파드를 생성해 가용성을 보장.

🔹 Namespace

클러스터 내 리소스들을 논리적으로 구분하는 공간.
프로젝트, 작업 환경(개발/운영) 등에 따라 리소스를 분리해 충돌을 방지.
한 클러스터 안에 여러 Namespace를 둘 수 있으며,
Namespace별로 동일한 이름의 리소스(예: Deployment, Pod)도 존재 가능.

🔹 Pod 내부 컨테이너 간 통신

Pod 내 컨테이너들은 localhost로 서로 접근 가능하며 볼륨(volume)을 공유할 수 있다.
예:
- nginx 컨테이너: 웹 서버 역할
- mysql 컨테이너: 데이터 저장소 역할
  → 하나의 Pod 안에서 실행되면 nginx가 mysql에 localhost로 접근 가능.
Pod 단위로 IP가 부여되므로, 동일 Pod 내에서는 --link 같은 설정이 필요 없다.

📘 정리 예시

개념	역할	특징
Pod	컨테이너 집합의 실행 단위	내부 통신 가능, IP 공유
Deployment	Pod 관리 및 배포 자동화	롤링 업데이트, 자동 복구
Namespace	리소스 논리적 구분	프로젝트·환경별 격리 가능
Service	외부 통신을 위한 엔드포인트	ClusterIP, NodePort, LoadBalancer 등

원문에서 언급된 핵심은 이거예요:

“Pod 안 컨테이너들은 같은 네임스페이스를 공유해 내부 IP로 통신하며,
외부 접근은 Service로, 버전 관리와 파드 생성/복구는 Deployment가 담당한다.”

🧩 1️⃣ Docker cAdvisor (Container Advisor)

📘 개요

Google이 개발한 오픈소스 도구로,
각 노드 단위(container runtime 레벨) 에서 컨테이너의 실시간 자원 사용량을 모니터링하는 툴입니다.
주로 Docker 엔진이나 containerd가 설치된 서버에서 직접 구동됩니다.

⚙️ 기능

항목	설명
CPU, Memory, Disk, Network 모니터링	컨테이너 단위로 실시간 자원 사용량을 수집
웹 UI 제공	`http://<호스트IP>:8080` 으로 접근 가능
Prometheus와 통합	수집 데이터를 Prometheus metric 형태로 노출
노드 로컬 모니터링	클러스터 전체가 아니라 “이 노드의 컨테이너”만 관리

📌 예시

docker run \
  --volume=/:/rootfs:ro \
  --volume=/var/run:/var/run:rw \
  --volume=/sys:/sys:ro \
  --volume=/var/lib/docker/:/var/lib/docker:ro \
  --publish=8080:8080 \
  --detach=true \
  --name=cadvisor \
  google/cadvisor:latest

→ 브라우저에서 http://<서버IP>:8080 접속하면 컨테이너별 리소스 그래프 표시됨.

🧩 2️⃣ Kubernetes Dashboard

📘 개요

쿠버네티스 클러스터 전체를 관리·모니터링하는 공식 웹 UI.
단순 모니터링뿐 아니라 리소스 생성, 로그 조회, 스케일링, 삭제 등 관리 기능까지 포함.

⚙️ 기능

항목	설명
리소스 관리	Pod, Deployment, ReplicaSet, Service, ConfigMap 등 생성/삭제/수정
클러스터 모니터링	네임스페이스별 파드 상태, 노드 상태 확인
로그 확인 및 명령 실행	Pod 로그 보기 및 컨테이너 내 쉘 실행 가능
권한 인증 필요	ServiceAccount + Token 기반 로그인 필요
웹 기반 인터페이스	`https://<MasterIP>:<NodePort>/` 로 접근 가능

📌 설치 예시

kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.7.0/aio/deploy/recommended.yaml
kubectl -n kubernetes-dashboard get pods
kubectl -n kubernetes-dashboard get svc

로그인 시에는 토큰 발급:

kubectl -n kubernetes-dashboard create token admin-user

🔍 비교 정리

구분	cAdvisor	Kubernetes Dashboard
기능 범위	노드 단위 컨테이너 모니터링	클러스터 전체 리소스 관리 및 모니터링
관리 주체	Docker/Containerd 엔진	Kubernetes API Server
설치 위치	각 노드마다 (DaemonSet 형태도 가능)	마스터(또는 노드)에 Pod 형태로 배포
주요 목적	자원 사용량 실시간 수집	쿠버네티스 리소스 생성·관리·시각화
UI 접근 방식	`http://<node-ip>:8080`	`https://<master-ip>:<port>` (토큰 필요)
데이터 수집 단위	컨테이너별	Pod, Node, Namespace, Cluster 전체
연계 도구	Prometheus, Grafana	kubectl, API Server, ServiceAccount

💡 요약 결론

🔸 cAdvisor → “컨테이너 리소스 사용량”에 초점
(CPU, Memory, Disk, I/O 등 노드 로컬 수준 모니터링)
🔸 Kubernetes Dashboard → “클러스터 전체 관리 및 시각화”
(Pod/Service/Namespace 등 쿠버네티스 오브젝트 중심 관리)

🧩 Kubernetes 주요 구성요소 정리

구성요소	역할 및 설명
kubelet	- 각 노드(Node) 에서 실행되는 에이전트(Agent). - Pod와 컨테이너의 실행 상태를 API 서버에 보고. - 컨테이너의 livenessProbe, readinessProbe 를 통해 상태 확인. - 내부적으로 cAdvisor 를 이용해 CPU·메모리 등 메트릭 수집. → 노드 단위에서 Pod의 “생명주기(Lifecycle)”를 관리하는 핵심 구성요소.
kube-proxy	- 각 노드에서 실행되며, Service 와 Pod 간의 통신을 관리. - iptables / IPVS 규칙을 설정해 클러스터 내부 트래픽을 로드밸런싱. - Service의 ClusterIP 변화를 감지하고, 최신 상태로 유지.
coredns	- 클러스터 내부 DNS 서비스. - Pod가 다른 Service나 Pod를 이름(`svc.cluster.local`)으로 접근할 수 있게 DNS를 제공. - 기존 `kube-dns`를 대체하여 v1.11 이후 기본 채택.

🧩 추가적인 구성요소

구성요소	설명
calico-kube-controllers	Calico 네트워크 드라이버용 컨트롤러. `etcd`를 사용해 네트워크 정책 관리 및 라우팅 제어 수행.
calico-node	모든 노드에서 실행되며, Pod 간 통신·라우팅·네트워크 접근 제어 등 SDN(Software Defined Network) 기능 수행.
kubernetes-dashboard	웹 기반 Kubernetes 관리 콘솔. CLI(`kubectl`) 없이 Pod, Deployment, Service 등 리소스를 GUI로 관리 가능. → 클러스터 상태, 로그 확인, 배포 작업까지 가능.
kube-flannel	간단한 오버레이 네트워크 플러그인. 모든 노드에 Pod 네트워크를 구성하여, 서로 다른 노드 간 Pod 통신을 가능하게 함. 기본적으로 IPv4 기반 VXLAN 방식을 사용. Calico보다 설정이 간단하지만, 네트워크 정책 제어는 지원하지 않음.
Calico	고급형 CNI 플러그인. IP 라우팅 기반으로 네트워크를 구성하며, 네트워크 정책(NetworkPolicy) 기능을 통해 보안 제어 가능. 필요시 Flannel 대신 Calico 사용.

💡 핵심 비교 요약

분류	주요 기능	비고
kubelet	노드에서 Pod 실행·상태 관리	노드 에이전트
kube-proxy	Service 트래픽 라우팅	iptables/IPVS 기반
coredns	클러스터 내부 DNS 제공	Pod·Service 이름 해석
calico	고급 네트워크·보안 정책	SDN 방식, 네트워크 정책 지원
flannel	단순 네트워크 연결	설정 간단, 정책 기능 없음
dashboard	클러스터 GUI 관리 도구	웹 기반 관리 인터페이스

📘 요약 문장

kubelet은 노드에서 Pod를 실행하고 상태를 보고하며,
kube-proxy는 Service 트래픽을 관리하고,
coredns는 클러스터 내부 이름 해석을 담당한다.
네트워크 플러그인으로는 flannel(간단)과 calico(정교한 보안 정책 가능)가 있으며,
kubernetes-dashboard는 웹 기반으로 클러스터를 시각적으로 관리한다.

🧩 쿠버네티스 주요 리소스 개념 정리

분류	역할 및 설명
컨트롤러 (Controller)	Pod의 실행을 제어하는 관리 객체. 여러 종류가 있으며 목적에 따라 사용 가능. 예: • Deployment(배포) → 서버-클라이언트 모델 등에서 일정 개수의 Pod를 유지하도록 자동 조정. • Job(잡) → 한 번만 실행되는 배치 작업(batch job) 처리용. • CronJob → 주기적 실행 작업용. → 컨트롤러는 Pod를 직접 실행하지 않고, 원하는 상태(Desired State) 를 유지하도록 지속적으로 조정(Reconcile)하는 역할.
설정 (Configuration)	Pod/컨테이너 내 애플리케이션이 사용할 환경 설정 데이터를 저장하고 관리. • ConfigMap → 일반 설정 정보(Key-Value 형태). • Secret → 비밀번호, 인증서, API 키 등 보안 민감 데이터 저장. 이들은 네임스페이스 단위로 관리되며, Pod 내부에서 환경 변수나 파일로 마운트되어 사용됨.
Service (서비스)	클러스터 내·외부의 Pod 간 통신을 연결하는 객체. Pod는 동적으로 생성/삭제되므로 IP가 바뀌는데, Service는 고정된 IP(ClusterIP)를 부여해 안정적인 접근이 가능. • ClusterIP → 클러스터 내부 통신용(기본). • NodePort → 외부에서 특정 포트로 접근 가능. • LoadBalancer → 클라우드 외부 로드밸런서 연결. • Ingress → HTTP/HTTPS 트래픽 라우팅 제어. → 클러스터 내부 DNS에 자동 등록되어 Pod 간 이름 기반 접근이 가능.
스토리지 (Storage)	컨테이너는 기본적으로 비휘발성 저장소가 없기 때문에, 데이터가 유지되지 않음. → 지속 저장을 위해 Persistent Volume (PV) 과 Persistent Volume Claim (PVC) 개념 사용. • PV: 실제 스토리지(NFS, NAS, AWS EBS 등). • PVC: Pod에서 요청하는 스토리지 용량 정의. → 외부 스토리지 시스템(NAS, NFS 등)과 연동 가능하며, 컨테이너가 재시작되어도 데이터 유지 가능.

🧠 핵심 요약

분류	핵심 키워드
Controller	Pod 자동 관리, 배포, 스케줄링, 유지 (Deployment, Job, CronJob 등)
Configuration	설정값 관리, 민감정보 분리 (ConfigMap, Secret)
Service	Pod 간 통신 연결, 고정 IP 제공 (ClusterIP, NodePort, LoadBalancer, Ingress)
Storage	영속 데이터 저장 (PV, PVC, 외부 NAS 연동)

💬 정리 문장

쿠버네티스는 컨트롤러로 파드를 자동 생성·관리하고,
ConfigMap과 Secret으로 설정을 분리하며,
Service로 안정적인 네트워크 접근을 제공하고,
Persistent Volume으로 데이터를 영구적으로 저장한다.

=>최근에는 다음처럼 수행하라고 보인다.
a) apt –y install snap ; snap install helm —classic 해주고
#Add kubernetes-dashboard repository
b) helm repo add kubernetes-dashboard https://kubernetes.github.io/dashboard/
#Deploy a Helm Release named "kubernetes-dashboard" using the kubernetes- dashboard chart
c) helm upgrade --install kubernetes-dashboard kubernetes-dashboard/kubernetes- dashboard --create-namespace —namespace kubernetes-dashboard 해준 뒤,
d) kubectl -n kubernetes-dashboard port-forward svc/kubernetes-dashboard-kong –proxy 8443:443 하면>창이 대기상태가 된다.
e) 다른 창에서 kubectl –n kubernetes-dashboard get svc 해보고
f) 이어서 https://localhost:8443으로 접속하라고 보인다. 연결해보면 https 키가 없으므로>Advanced...로 가서>다음창 Accept the Risk and Continue를 클릭하면>Kubernetes Dashboard가 보인다.

🧩 핵심 요약 — Pod의 특징 및 IP 구조

1️⃣ Pod는 호스트(노드) 입장에서 보면 “Docker 프로세스처럼” 임시적으로 존재

Pod 내부의 컨테이너는 실제로는 Linux 프로세스 형태로 실행됩니다.
즉, Pod = 여러 컨테이너를 하나의 묶음으로 관리하는 단위이며, 컨테이너들이 같은 네임스페이스(Network, IPC, Volume 등) 를 공유합니다.

2️⃣ Pod의 생명주기와 IP 주소의 변화

Pod는 한 번 생성되면 삭제되거나 재시작될 때마다 새로운 IP 주소를 부여받습니다.
따라서 Pod의 IP는 고정되지 않으며, 재시작하면 바뀝니다.
새로운 Pod가 생성될 때마다 이전 Pod와는 다른 컨테이너 프로세스가 새로 실행되기 때문이에요.

📘 예시

Pod1 → IP 10.244.1.5

Pod 재시작 → Pod2 생성, IP 10.244.1.6
→ 즉, IP가 바뀌므로 클라이언트가 Pod IP로 직접 접근하면 안정적이지 않음.

3️⃣ 그래서 Service가 필요함

Pod IP가 계속 바뀌니까, 고정된 IP (ClusterIP) 를 제공해주는 Service가 등장합니다.
Service는 내부적으로 Pod들의 집합을 라벨 셀렉터로 감시하며,
→ Pod가 새로 생겨도 자동으로 라우팅을 업데이트합니다.

4️⃣ Pod의 기본 구조

Pod는 내부적으로 사용 가능한 IP 주소를 가집니다.
한 Pod 안에 여러 컨테이너를 포함할 수 있습니다.
단, 컨테이너들은 같은 네트워크 네임스페이스를 공유하므로, 같은 IP를 사용합니다.

5️⃣ Pod는 일시적이지만, 지속적으로 동작하는 형태로 관리됨

Pod 자체는 ephemeral(일시적) 하지만,
Deployment, ReplicaSet, StatefulSet 같은 상위 리소스가 자동으로 다시 생성해줍니다.
즉, “Pod는 죽더라도 서비스는 계속 살아있게” 만들어주는 구조예요.

🧭 정리 요약표

구분	설명
Pod의 본질	컨테이너 실행 단위 (하나 이상의 컨테이너 포함)
IP 변화	Pod가 재시작될 때마다 IP 변경됨
Service 필요성	Pod의 IP가 바뀌므로 Service로 고정 IP(ClusterIP) 제공
내부 구조	같은 네임스페이스 공유 (IP, Volume 등)
생명주기 관리	Deployment/ReplicaSet이 자동으로 재생성
호스트 관점	Docker 컨테이너처럼 독립된 프로세스로 보임

💡 즉, 이 문서가 말하는 핵심 요약:

“Pod는 일시적이므로 직접 접근하지 말고, Service를 통해 접근해야 한다.”

🌿 Kubernetes 리소스 연결 흐름

1️⃣ Pod

실제 컨테이너가 실행되는 가장 작은 단위.
각각의 Pod는 하나 이상의 컨테이너를 포함하고, 실행 중인 애플리케이션(예: nginx, mysql 등)을 담당함.
Pod는 일시적이므로, 언제든 삭제·재생성될 수 있음.

예시:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx

→ 여기서 labels가 붙은 이유는 다른 리소스가 이 Pod를 식별할 수 있도록 하기 위해서입니다.

2️⃣ Label

Pod(또는 다른 리소스)에 부착하는 식별용 키-값 쌍.
쿠버네티스는 “이 Pod가 어떤 그룹에 속하는가”를 Label로 구분함.

예시:

app: nginx
env: production
tier: frontend

이런 label을 붙여두면,
Service나 Deployment가 “app이 nginx인 Pod만 관리”하도록 선택할 수 있습니다.

3️⃣ Selector

Label을 기반으로 Pod를 선택하는 기준.
예를 들어 Service나 Deployment는 selector로 연결 대상을 결정합니다.

예시:

selector:
  matchLabels:
    app: nginx

이 경우, app=nginx 라벨이 붙은 Pod들만 대상으로 트래픽을 보냅니다.

⚙️ 전체 흐름 요약

단계	역할	핵심 포인트
Pod	실제 컨테이너 실행 단위	라벨(label)을 가지고 있음
Label	Pod의 속성을 표시하는 태그	그룹핑, 선택의 기준 제공
Selector	특정 label이 붙은 Pod를 선택	Service, Deployment 등이 사용

🔗 시각적 흐름

[ Service or Deployment ]
          │
          ▼
    (Selector)
      app=nginx
          │
          ▼
 [ Pod1: label app=nginx ]
 [ Pod2: label app=nginx ]

즉,

Service → Selector → Label → Pod

이 흐름을 통해 쿠버네티스가 “어떤 Pod에 요청을 보낼지”를 자동으로 결정하는 거예요.

좋아요 👍
이 부분은 쿠버네티스의 Service 개념과 로드밸런싱(load balancing) 동작 방식을 설명하고 있어요.
아래처럼 흐름으로 정리해볼게요 👇

🌐 Service의 역할 정리

1️⃣ Pod는 IP가 계속 바뀐다

Pod는 컨테이너처럼 일시적으로 존재합니다.
(죽었다가 새로 생성되면 새로운 IP를 받음)
따라서 Pod의 IP는 고정되지 않음 → 외부에서 직접 접근 불가능
→ 이걸 해결하는 게 Service입니다.

2️⃣ Service의 핵심 기능

내부 Pod들의 IP 변화와 관계없이 고정된 IP(ClusterIP) 를 제공합니다.
외부에서 Service의 IP로 접근하면, Service가 자동으로 해당 Pod 중 하나로 트래픽을 전달합니다.
→ 즉, Pod 앞단의 ‘가상 IP + 로드밸런서’ 역할

3️⃣ Label & Selector 연결

Service는 Selector를 사용해서 특정 Label이 붙은 Pod들을 자동으로 찾아 연결합니다.
예:
```
selector:
  app: nginx
```
→ app=nginx 라벨을 가진 Pod들에 연결.

4️⃣ Load Balancing & Round Robin

Service는 연결된 여러 Pod 중 하나로 요청을 분배합니다.
분배 방식은 기본적으로 Round Robin (순환 방식) 을 사용.
결과적으로, 여러 Pod에 부하가 고르게 분산됩니다.
이로 인해 fault tolerance(장애 대응) 기능도 자연스럽게 수행됩니다.

✅ 한 줄 요약

Service는 Pod의 IP가 바뀌어도 고정된 접속점을 제공하며,
Label/Selector로 Pod들을 연결하고
Load Balancing (Round Robin 방식) 으로 트래픽을 분산시켜
클러스터의 안정성과 가용성을 높여준다.

원하신다면 이 구조를 “Client → Service → Pod(3개)” 형태로 네트워크 구조도로 시각화해드릴까요?
(load balancing 흐름 포함해서)

🧩 올바른 접근 방식
(1) NodePort의 접근 구조

NodePort는 클러스터의 각 노드 IP + 지정된 포트를 통해 접근합니다.

즉,
❌ 10.109.99.192:32655 → (ClusterIP, 외부 불가)
✅ 워커노드의 실제 IP:32655 → (NodePort, 외부 가능)

클러스터 내부 Pod 간 통신용으로만 쓰이는 IP

열공하는웅2

훌륭한 it 엔지니어 꿈나무

이전 포스트

클라우드 정리(Docker4,5)

다음 포스트

Kubernetes(쿠버네티즈)

클라우드

🧩 쿠버네티스 기본 개념 정리

🔹 Pod

🔹 Deployment

🔹 Namespace

🔹 Pod 내부 컨테이너 간 통신

📘 정리 예시

🧩 1️⃣ Docker cAdvisor (Container Advisor)

📘 개요

⚙️ 기능

📌 예시

🧩 2️⃣ Kubernetes Dashboard

📘 개요

⚙️ 기능

📌 설치 예시

🔍 비교 정리

💡 요약 결론

🧩 Kubernetes 주요 구성요소 정리

🧩 추가적인 구성요소

💡 핵심 비교 요약

🧩 쿠버네티스 주요 리소스 개념 정리

🧠 핵심 요약

💬 정리 문장

🧩 핵심 요약 — Pod의 특징 및 IP 구조

1️⃣ Pod는 호스트(노드) 입장에서 보면 “Docker 프로세스처럼” 임시적으로 존재

2️⃣ Pod의 생명주기와 IP 주소의 변화

3️⃣ 그래서 Service가 필요함

4️⃣ Pod의 기본 구조

5️⃣ Pod는 일시적이지만, 지속적으로 동작하는 형태로 관리됨

🧭 정리 요약표

🌿 Kubernetes 리소스 연결 흐름

1️⃣ Pod

2️⃣ Label

3️⃣ Selector

⚙️ 전체 흐름 요약

🔗 시각적 흐름

🌐 Service의 역할 정리

1️⃣ Pod는 IP가 계속 바뀐다

2️⃣ Service의 핵심 기능

3️⃣ Label & Selector 연결

4️⃣ Load Balancing & Round Robin

✅ 한 줄 요약

클라우드 정리(Docker4,5)

쿠버네티즈3

0개의 댓글